Ontology Reference — Complete Class and Property Catalogue

Looking for a specific class, property, or namespace? This document is the exhaustive reference for every ontology module in the Linked.Archi semantic assets repository, including their OWL classes, properties, design rationale, and dependencies on other modules.

Use this when you need to know: "what classes does the core ontology define?", "what properties link decisions to forces?", or "what's the namespace for the ArchiMate 3.2 ontology?"

---

1. Core Ontology (core/core-onto.ttl)

Namespace: https://meta.linked.archi/core# (prefix: arch:) Version: 0.3.2 Status: Draft Creator: Kalin Maldzhanski License: CC BY 4.0

The core ontology is the foundation of the entire Linked.Archi ecosystem. It defines the fundamental concepts for enterprise and IT architecture modelling, aligned with ISO/IEC/IEEE 42010.

Core SHACL Shapes (core/core-shapes.ttl)

Namespace: https://meta.linked.archi/core-shapes# (prefix: archsh:) Version: 0.1.0

Base SHACL shapes that apply to all metamodels extending the core:

Shape	Target	Constraint
archsh:QualifiedRelationshipShape	arch:QualifiedRelationship	Exactly one arch:source and one arch:target, both arch:ModelConcept
archsh:ConceptOwnerShape	arch:ModelConcept	At most one arch:conceptOwner, and it must be an arch:Stakeholder

Metamodel-specific shapes (ArchiMate, C4, Backstage) import this file and add type-specific constraints.

There is no core label shape

Requiring skos:prefLabel on every arch:Element is not a sound cross-notation rule. arch:Element means "a node in a model", and several notations have nodes that are legitimately unnamed:

Construct	Why it has no name
BPMN Gateway and Event subtypes	routing and triggering; the spec makes name optional
ArchiMate AndJunction / OrJunction	relationship connectors, drawn as dots or bars
BPMN TextAnnotation, Group	carry bpmn:text, not a name at all
BPMNDI BPMNDiagram	the spec makes the diagram name optional — hence no core arch:View rule either

Those are genuine elements: they have identity, they render on diagrams, they belong in element counts. Excluding them from arch:Element to satisfy a label rule would misstate the model.

So each metamodel owns its naming rule and states it in its own shapes, listing the classes that must be named with plain sh:targetClass:

Metamodel	Shape
BPMN 2.0.2	bpmnsh:RequiredNameShape
BPMN Lite	per-class shapes in bpmnls:
ArchiMate 4.0	am4elsh:ArchiMateElementShape
ArchiMate 3.2	amelsh:ArchiMateElementShape
C4	c4sh:C4ElementLabelShape
Structurizr	strsh:StructurizrElementLabelShape
Backstage	bssh:BackstageElementLabelShape

A metamodel shape must not target arch:Element for this purpose. In a merged multi-notation graph that would apply one notation's naming policy to every other notation's elements. Target the metamodel's own classes — its abstract domain or layer roots are usually the concise way to do it, and they also give you a natural place to leave connectors out.

The labelling contract — for converter authors

skos:prefLabel is the canonical human-readable label across every metamodel, and it must carry a language tag. Every notation label shape asserts sh:datatype rdf:langString, so "Charge card" is rejected and "Charge card"@en is accepted. This is the most common reason converter output fails validation while looking correct to a human reader.

A notation's own name attribute does not satisfy the rule. Notation ontologies retain their source attributes verbatim — bpmn:name from BPMN XML, and equivalents elsewhere — as plain xsd:string, both for round-trip fidelity and because those attributes also appear on classes that are not architecture elements. Converters emit both:

ex:t1 a bpmn:ServiceTask ;
    bpmn:name      "Charge card" ;      # source attribute, verbatim
    skos:prefLabel "Charge card"@en .   # canonical label

Do not try to bridge the two with rdfs:subPropertyOf. The entailed prefLabel inherits the plain xsd:string datatype, so a correctly named element still fails — the report merely moves from sh:MinCountConstraintComponent to sh:DatatypeConstraintComponent, pointing away from the real problem.

Full rationale in DD-24, with conformance checks P-8 and P-9.

Classes

Model Concepts (the modelling palette)

Class	Parent	Description
arch:ModelConcept	owl:Class	Base class for all concepts used in an architecture model
arch:Element	arch:ModelConcept	Elements or nodes used in models; subclasses defined in specific metamodels
arch:QualifiedRelationship	arch:ModelConcept	First-class relationship resource; subclasses form the relationship palette
arch:View	arch:ModelConcept	Representation of a system from a set of concerns
arch:Catalog	arch:View	List-based view of building blocks for governance
arch:Matrix	arch:View	Grid showing relationships between model entities
arch:Diagram	arch:View	Graphical rendering of architectural content

Architecture Description Concepts

Class	Parent	Description
arch:System	owl:Class	The subject of interest — combination of interrelated parts
arch:Architecture	owl:Class	Fundamental concepts/properties of a system in its environment
arch:Model	owl:Class	Selective representation of a system (architecture description)
arch:Metamodel	owl:Class	Definition of the modelling language (manifest aggregating all resources)
arch:Framework	schema:CreativeWork	Architecture framework (e.g., TOGAF, DoDAF, Zachman)
arch:Viewpoint	owl:Class	Specification for a kind of architecture view

Stakeholder and Concern Concepts

Class	Parent	Description
arch:Stakeholder	arch:Element	Party with interests in the system
arch:Consideration	owl:Class	Base class for concerns, aspects, perspectives
arch:Concern	arch:Consideration	Specific interest in the system
arch:Aspect	arch:Consideration	Architecture aspect (data, activity, function, etc.)
arch:Perspective	arch:Consideration	Stakeholder perspective (strategic, capability, operations)

Quality and Governance

Class	Parent	Description
arch:QualityAttribute	owl:Class	Named quality characteristic (ISO 25010/25011/25012 aligned). Subclassed by quality model roots; leaf sub-characteristics are owl:NamedIndividual instances.
arch:QualityMeasure	owl:Class	Per-component quantification of a quality attribute. Links to the measured Element and the QualityAttribute individual.
arch:PresentationFormat	owl:Class	Output format for rendering deliverables (Markdown, HTML, PDF, etc.)
arch:DeliverableTemplate	schema:CreativeWork	Template defining content structure of a deliverable (which viewpoints)
arch:TemplateSection	owl:Class	Ordered section within a DeliverableTemplate referencing a Viewpoint
arch:Purpose	owl:Class	Purpose shaping the architecture description
arch:Environment	owl:Class	Environment in which the system is situated
arch:Folder	schema:ItemList	UI/navigation container (non-semantic)

Key Properties

Relationship Properties

• arch:source / arch:target — Qualified relationship source and target elements
• arch:unqualifiedForm — Schema-level mapping from qualified form to unqualified predicate
• arch:hasQualifiedRelationship — Generic fallback qualified predicate
• arch:domainIncludes / arch:rangeIncludes — Guidance for modelling tools (not validation constraints). See Domain & Range Guide

Structural Properties

• arch:partOf / arch:hasPart — Transitive composition/traceability across models
• arch:refines / arch:refinedInto — Traceability between abstraction levels
• arch:viewConformsToViewpoint — Links a View to its governing Viewpoint
• arch:modelConformsToMetamodel — Links a Model to its Metamodel
• arch:exposedInView — Links a ModelConcept to the Views that expose it
• arch:partOfModel — Links a ModelConcept to its containing Model

Governance Properties

• arch:conceptOwner — Stakeholder responsible for a concept's governance
• arch:masterDataSource — Authoritative data source (dcat:Dataset)
• arch:isAbstract — Distinguishes ABBs (abstract) from SBBs (concrete)
• arch:basedOnFramework — Links a Metamodel to its source Framework

Quality Measurement Properties

• arch:hasQualityMeasure — Links an Element to a QualityMeasure (inverse of measuredEntity)
• arch:measuredEntity — Links a QualityMeasure to the Element it measures
• arch:measuredQualityAttribute — Links a QualityMeasure to the QualityAttribute it quantifies

Metamodel Composition Properties

• arch:modelConcepts — Ontology defining elements and relationships
• arch:architectureViewpoints — Ontology defining viewpoints
• arch:architectureViewpointsRestrictions — SHACL shapes for viewpoint constraints
• arch:formalRules — SHACL rules the model must conform to
• arch:derivationRules — Rules for deriving new facts
• arch:conceptClassification — SKOS scheme classifying model concepts
• arch:referenceData / arch:referenceModels — Reference data and architectures
• arch:standardsInformationBase — Standards, guidelines, best practices

Presentation Properties

• arch:prefVisNotation / arch:altVisNotation — Visual notation icons (SVG rendered images)
• arch:presentationContextScheme — Stakeholder-specific presentation themes (SKOS scheme)
• arch:notationSet — Links a Metamodel to its available NotationSet(s)
• arch:usesNotationSet — Links a PresentationContext to its appropriate NotationSet

Deliverable Template Properties

• arch:hasDeliverableTemplate — Links a Metamodel to its DeliverableTemplates
• arch:templateRequiresViewpoint — Links a DeliverableTemplate to required Viewpoints (flat list)
• arch:templateHasSection — Links a DeliverableTemplate to ordered TemplateSection instances
• arch:templateHasFormat — Links a DeliverableTemplate to supported PresentationFormats
• arch:templateResource — Points to the actual template file/URL for a PresentationFormat
• arch:generatorCommand — Shell command to produce the rendered output from the knowledge graph
• arch:sectionViewpoint — Links a TemplateSection to its Viewpoint
• arch:sectionOrder — Ordinal position of a section within its template
• arch:deliverableTemplateUsed — Links a Model (deliverable) to the template it was instantiated from
• arch:templateTargetsPurpose — Links a DeliverableTemplate to its supported Purpose(s)

Annotation Properties

• arch:rationale — Justification for a modelling decision
• arch:mentionedIn — Reference to where a concept is discussed
• arch:laKB — Link to Linked.Archi knowledge base

---

2. Core Viewpoints (core/core-viewpoints.ttl)

Namespace: https://meta.linked.archi/core-viewpoints# (prefix: archvp:) Version: 0.1.0 Status: Draft Imports: arch:core

Framework-agnostic architecture viewpoints derived from ISO/IEC/IEEE 42010 and common architecture practice. These are universal viewpoints that any modelling language can reference — ArchiMate, TOGAF, C4, or custom metamodels can specialize or reference them.

Purpose Individuals

Individual	Description
archvp:Deciding	Evaluating options, making trade-offs, selecting alternatives
archvp:Designing	Creating or refining architecture — defining structure and behaviour
archvp:Informing	Communicating architecture to stakeholders for understanding and alignment
archvp:Governing	Ensuring compliance, enforcing standards, managing change

Concern Individuals (10)

Structure, Behavior, Deployment, Dependencies, Governance, Evolution, Quality, Cost, Integration, Stakeholder Interests — each an instance of arch:Concern.

Viewpoints (12)

Viewpoint	Purpose	View Type	Concerns
Landscape Overview	Informing	Diagram	Structure, Dependencies
Component Catalog	Informing, Deciding	Catalog	Structure, Governance
Process Flow	Designing	Diagram	Behavior
Interface Map	Designing	Diagram	Integration, Dependencies
Deployment Map	Designing, Informing	Diagram	Deployment
Dependency Matrix	Deciding	Matrix	Dependencies
Impact Analysis	Deciding	Diagram, Matrix	Dependencies, Evolution
Decision Log	Governing	Catalog	Governance
Stakeholder Map	Informing, Deciding	Matrix	Stakeholder Interests
Standards Compliance	Governing	Matrix	Governance, Quality
Roadmap	Deciding, Informing	Diagram	Evolution
Gap Analysis	Deciding	Matrix	Evolution, Cost

---

3. Core Deliverable Templates (core/core-deliverable-templates.ttl)

Namespace: https://meta.linked.archi/core-deliverable-templates# (prefix: archdt:) Version: 0.1.0 Status: Draft Imports: arch:core, archvp:core-viewpoints

Framework-agnostic deliverable templates that define the content structure of common architecture documents. Each template specifies which viewpoints are required as sections — the actual views are created when someone instantiates the template into a concrete deliverable (arch:Model).

The vocabulary classes (arch:DeliverableTemplate, arch:TemplateSection) and properties (arch:templateRequiresViewpoint, arch:templateHasSection, etc.) are defined in the core ontology. This file contains the template instances.

Presentation Formats

Instances of arch:PresentationFormat — define the output format for rendering:

Format	Description
Markdown Document	Git-friendly docs (MkDocs, Docusaurus, Jekyll)
HTML Report	Standalone interactive page with SVG diagrams
PDF Document	Paginated, print-ready for governance and audits
Slide Deck	Presentation slides for review boards and briefings
Interactive Dashboard	Live dashboard with drill-down from the knowledge graph

Deliverable Templates

Template	Sections	Purpose
Architecture Overview Document	Landscape → Stakeholders → Components → Dependencies → Standards	Informing, Governing
Solution Design Document	Context → Process → Interface → Deployment → Decisions	Designing
Change Impact Assessment	Impact → Dependencies → Gap → Roadmap	Deciding, Governing

Usage Pattern

# Instantiate a template into a concrete deliverable
ex:MyADD a arch:Model ;
    arch:deliverableTemplateUsed archdt:ArchitectureOverviewDocument ;
    arch:contains ex:LandscapeView, ex:StakeholderView, ex:ComponentView ;
    arch:modelHasPurpose archvp:Informing .

ex:LandscapeView a arch:Diagram ;
    arch:viewConformsToViewpoint archvp:LandscapeOverview .

---

4. Diagram Interchange Ontology (core/core-vis-onto.ttl)

Namespace: https://meta.linked.archi/core-vis# (prefix: arch-vis:) Shapes: https://meta.linked.archi/core-vis-shapes# (prefix: archvissh:) Version: 0.3

Defines the vocabulary for diagram layout, visual properties, and type-level visual notation management. Supports both instance-level diagram rendering (node positions, link routing) and type-level notation definition (default shapes, colours, icons for palette generation).

Node, Link and Point are mutually disjoint (arch-vis:NodeLinkPointDisjoint). arch-vis:label has rdfs:domain arch-vis:DiagElement, not arch-vis:Node, so an edge's label is attached the same way a shape's is — a named sequence flow is the ordinary case, not an edge case.

Diagram data needs core-vis-shapes.ttl to be validated at all: neither core-shapes nor any notation's shapes target a core-vis class. See Validation.

Classes

Class	Description
arch-vis:DiagElement	Base class for all diagram elements
arch-vis:Node	A positioned element in a diagram
arch-vis:ContainerNode	A node that can contain other nodes
arch-vis:LabelNode	A text label node
arch-vis:ArchNode	A node representing an architecture element
arch-vis:Link	A connection between nodes (relationship visualization)
arch-vis:Point	A coordinate point
arch-vis:PointList	Ordered list of points (for link routing)
arch-vis:Style	Visual style (fill, line, font, shape, icon)
arch-vis:NotationSet	Named collection of VisualNotation descriptors for a modelling language
arch-vis:VisualNotation	Structured visual notation descriptor for a single ModelConcept
arch-vis:ShapeType	Enumeration of geometric shapes (RoundedRectangle, Octagon, Ellipse, etc.)
arch-vis:IconPlacement	Enumeration of icon positions within a shape (TopRight, Center, etc.)
arch-vis:RenderingMode	How shape and icon are composed (ShapeWithBadge, IconCentric, ShapeOnly)
arch-vis:LineStyle	Enumeration of line styles for relationships (Solid, Dashed, Dotted)
arch-vis:Decoration	Enumeration of endpoint decorations (arrowheads, diamonds, etc.)

Properties

• Bounds: bounds-x, bounds-y, bounds-w, bounds-h — Node positioning and size
• Points: point-x, point-y — Coordinate values
• Links: source, target, points — Link endpoints and routing
• Mapping: archElement, archRelationship — Links diagram elements to semantic elements
• Style (instance): fillColor, lineColor, fontName, fontSize, fontColor — CSS-style visual properties
• Style (structural): shapeType, iconSymbol, iconPlacement, renderingMode, defaultWidth, defaultHeight — Shape, icon, and rendering approach
• Notation: notationFor, inNotationSet, defaultStyle — Type-level notation management
• Relationships: lineStyle, sourceDecor, targetDecor — Connector visual properties
• Context: view — Links diagram elements to their containing View

Visual Notation Flow

The visual notation system connects stakeholder audiences to visual rendering through a chain of linked data:

flowchart TD
    PC["PresentationContext<br/>(who is looking)"]
    NS["NotationSet<br/>(which visual theme)"]
    VN["VisualNotation<br/>(per concept)"]
    Style["arch-vis:defaultStyle → Style<br/>(construction recipe)"]
    SVG["arch:prefVisNotation → SVG<br/>(rendered image)"]

    PC -->|"arch:usesNotationSet"| NS
    NS -->|"arch-vis:inNotationSet (inverse query)"| VN
    VN --> Style
    VN --> SVG

Palette generation algorithm:

1. Determine the active PresentationContext (from user role/preference)
2. Follow arch:usesNotationSet → get the appropriate NotationSet
3. If no context-specific set, fall back to arch:notationSet on the Metamodel
4. Query all arch-vis:VisualNotation where arch-vis:inNotationSet = active set
5. For each, read arch-vis:notationFor → the OWL class
6. Read arch-vis:defaultStyle → get shape, colour, icon, dimensions
7. Group by taxonomy (domain/aspect from the SKOS taxonomy)
8. Render the palette

---

5. Common Taxonomy (core/common-tax.ttl)

Namespace: https://meta.linked.archi/core-tax#

A SKOS concept scheme providing a high-level classification of architectural components. Used for navigation, filtering, and visual grouping across metamodels.

Top-Level Concepts

• ArchComponent — Root concept for all architectural components
• LogicalComponent, PhysicalComponent, BusinessComponent
• SoftwareComponent, HardwareComponent
• CloudComponent → SaaSComponent, PaaSComponent, IaaSComponent
• TechComponent — Technology categories
• Compute, AI_ML, Analytics, Blockchain, Containers
• Databases, DeveloperTools, DevOps, Identity, Integration
• IoT, Networking, Security, Storage, Web, and more

---

Extensions Overview

Extensions are optional modules that extend the core ontology with additional vocabulary for specific architecture concerns. They sit at the same level as core/ and can be composed into any metamodel via owl:imports. Unlike modelling languages (which define complete element/relationship palettes), extensions add cross-cutting capabilities — decision tracking, process governance, quality attributes, tactics, and reference architectures.

Each extension imports arch:core and defines its own classes and properties. Metamodels can import any combination of extensions alongside their modelling language ontology.

arch:core ← ad:arch-decision (decisions, forces, options)
         ← ap:arch-processes (governance processes, ISO 42020)
         ← refa:ref-arch (patterns, tactics, reference models)
         ← qa:quality-attributes (quality attribute individuals)
         ← tac:tactics (architectural tactics by quality attribute)

---

6. Architecture Decision Ontology (extensions/arch-decision/)

Namespace: https://meta.linked.archi/arch-decision# (prefix: ad:) Version: 0.0.6 Files: arch-decision-onto.ttl, arch-decision-shapes.ttl Derived from: Academic research on architecture decision documentation Authoritative sources: - Jansen, A. & Bosch, J. (2005) "Software Architecture as a Set of Architectural Design Decisions" — doi:10.1109/WICSA.2005.61 - Kruchten, P. et al. (2009) "Do you really know what you're building?" — doi:10.1007/978-3-540-87879-7_14 - Zimmermann, O. et al. (2015) "Architectural Decision Guidance Across Projects" — doi:10.1016/j.jss.2015.08.054 - MADR — Markdown Any Decision Records

Models the architecture decision-making process, enabling traceability from forces (drivers, requirements, quality attributes) through options to decisions. This extension is the foundation for architecture decision records (ADRs) in the knowledge graph.

When to use: Import this extension when your metamodel needs to capture architecture decisions, their rationale, the forces that influenced them, and the options that were considered. Integrates with the Quality Attributes and Tactics extensions for quality-driven decision making.

Example composition:

ex:MyMetamodel a arch:Metamodel ;
    arch:modelConcepts <https://meta.linked.archi/mymodel#>,
                       <https://meta.linked.archi/arch-decision#> .

Classes

Class	Parent	Description
ad:Decision	arch:Element	An architecture decision
ad:Issue	arch:Element	A problem requiring a decision (also: Problem, DecisionRequired)
ad:Option	arch:Element	A candidate option for a decision
ad:Force	arch:Element	An architecture driver/motivation influencing decisions
ad:Principle	ad:Force	Qualitative statement of intent with rationale
ad:Requirement	ad:Force	A requirement driving decisions
ad:FunctionalRequirement	ad:Requirement	Functional requirement
ad:QualityAttributeRequirement	ad:Requirement	Quality attribute requirement (with QAS properties)
ad:DecisionState	owl:Class	Lifecycle state of a decision record — ad:Proposed, ad:Accepted, ad:Rejected, ad:Deprecated, ad:Superseded

Quality attribute individuals themselves live outside this extension — ad:onQualityAttribute ranges over arch:QualityAttribute, populated by the Quality Attributes extension or an ISO 25010 alignment.

Key Properties

• ad:qualityAttributeMatch — Links a tactic or requirement to a quality attribute
• ad:qasDescription, ad:qasSourceOfStimulus, ad:qasStimulus, ad:qasEnvironment, ad:qasArtifact — Quality Attribute Scenario properties

Validation

Shapes namespace: https://meta.linked.archi/arch-decision-shapes# (prefix: adsh:)

arch-decision-shapes.ttl carries the constraints the ontology deliberately leaves out of OWL, per DD-2 and DD-23:

Shape	What it enforces
adsh:DecisionShape	At most one ad:decisionState, drawn from the five published individuals; single selected option; typed links to Issue, Option and Decision
adsh:AcceptedDecisionSelectionShape	An ad:Accepted decision that records candidates with ad:hasAlternative names the one it chose. Silent on a record with no candidates — a lifted document-based ADR has its options in prose (DD-26)
adsh:AcceptedDecisionRationaleShape	An ad:Accepted decision records rationale, inline or by document reference
adsh:SupersededDecisionShape	An ad:Superseded decision names its replacement — otherwise use ad:Deprecated
adsh:DecisionStateShape	Every state individual carries a label and a definition
adsh:IssueShape, adsh:OptionShape, adsh:ForceShape, adsh:RequirementShape	Labels, single-valued measures, and stakeholder links
adsh:QualityAttributeRequirementShape	Names a quality attribute and expresses the full QAS six-tuple

Run it with:

.scripts/validate.sh --shacl arch-decision

The profile validates the ontology together with examples/extensions/decisions-example.ttl, so the example doubles as the conformance fixture. Constraints marked sh:Warning flag incomplete but well-formed records; note that RDF4J's ShaclSail does not distinguish severities and fails on both.

Design Rationale

The ad:Issue class represents any problem needing a decision. It can map to abstract components where concrete implementation is needed, or to issues in tracking software. The ad:Force name was chosen over "Driver" or "Motivation" because it is more generic and avoids collision with ArchiMate's Driver concept.

---

7. Architecture Processes Extension (extensions/processes/archProcesses.ttl)

Modelling guide: Processes Modelling Guide

Namespace: https://meta.linked.archi/arch-processes# (prefix: ap:) Version: 0.1.0 Derived from: - ISO/IEC/IEEE 42020:2019 — Architecture processes - ISO/IEC/IEEE 12207:2017 — Software lifecycle processes - ISO/IEC/IEEE 15288:2023 — System lifecycle processes

Extension ontology describing architecture governance processes, activities, tasks, and their inputs/outputs. Process concepts are not subclasses of arch:Element — they are governance infrastructure that acts upon architecture elements from the outside. Architecture elements relate to processes via linking properties (ap:governs, ap:governedBy, ap:input, ap:output, ap:consumedBy).

The extension references the ISO standard vocabularies (under standards/) via rdfs:seeAlso for traceability to normative definitions, while providing the descriptive vocabulary needed for architecture governance work.

When to use: Import this extension when you need to describe architecture governance processes — what activities are performed, what inputs they consume, what outputs they produce, and who is responsible. Useful for TOGAF ADM alignment, ISO 42020 compliance, and architecture maturity assessments.

Classes

Class	Parent	Description
ap:ArchitectureProcess	(standalone)	A process within the architecture governance or lifecycle framework
ap:ProcessActivity	(standalone)	A cohesive set of tasks within a process
ap:ProcessTask	(standalone)	A specific action or work item within an activity
ap:ProcessDeliverable	(standalone)	A required output of a process delivered to a stakeholder
ap:InformationItem	ap:ProcessDeliverable	A body of information produced or consumed by a process
ap:ProcessMilestone	(standalone)	A significant checkpoint or gate in a process
ap:ProcessRole	arch:Stakeholder	A role that a stakeholder plays within a process
ap:LifecycleStage	skos:Concept	A distinct phase in the lifecycle of a system, application, or service
ap:LifecycleModel	(standalone)	A named collection of lifecycle stages defining a complete progression

Key Properties

• ap:governs / ap:governedBy — Process ↔ Element governance links
• ap:hasActivity / ap:activityOfProcess — Process ↔ Activity decomposition
• ap:hasTask / ap:taskOfActivity — Activity ↔ Task decomposition
• ap:hasSubProcess — Hierarchical process decomposition
• ap:input / ap:output — Process inputs and outputs (InformationItem, Model, Force, Decision)
• ap:producedBy / ap:consumedBy — Deliverable ↔ Process links
• ap:responsibleFor / ap:performedBy / ap:approvedBy — Role assignments
• ap:precedes / ap:follows — Sequencing of process elements
• ap:triggeredBy — Event or condition that triggers a process
• ap:hasStage / ap:partOfLifecycle — LifecycleModel ↔ LifecycleStage links
• ap:atLifecycleStage / ap:followsLifecycle — Element ↔ stage and ↔ model assignment
• ap:stageOrder — Numeric ordering of stages within a model
• ap:nextStage / ap:previousStage — Explicit stage sequencing

Canonical Lifecycle Stages

The extension defines the shared, notation-agnostic stage set as instances of ap:LifecycleStage, grouped by ap:ApplicationLifecycle. Lifecycle stages live here rather than in any modeling language's reference data because nothing about them derives from a notation — versioning them per notation release would attach a version axis with no source.

Stage	Order	ISO 12207	TIME
ap:Plan	1	closeMatch ConceptStage	closeMatch timefw:Plan
ap:PhaseIn	2	broadMatch of Development, Production	closeMatch timefw:Build
ap:Active	3	closeMatch UtilizationStage	closeMatch timefw:Run
ap:PhaseOut	4	narrowMatch of RetirementStage	narrowMatch of timefw:Retire
ap:Retired	5	narrowMatch of RetirementStage	narrowMatch of timefw:Retire

Mappings are asserted from the ISO 12207 and TIME files, which already import this extension, so the dependency direction stays consistent. ap:PhaseOut and ap:Retired are deliberately distinct where ISO 12207 and TIME each collapse withdrawal into a single stage.

Lifecycle stage is orthogonal to two neighbouring vocabularies: arch:ArchitectureState (baseline / target / transitional) classifies which temporal reality a model describes, and arch:ApprovalState (arch:Proposed, arch:Approved) classifies governance standing. An application can be arch:Approved and ap:Retired at the same time.

SHACL Shapes (arch-processes-shapes.ttl)

Namespace: https://meta.linked.archi/arch-processes-shapes# (prefix: apsh:)

Supplies the constraint DD-23 requires but which the ontology deliberately leaves out of OWL:

Shape	Target	Enforces
apsh:LifecycleStageAssignmentShape	subjects of ap:atLifecycleStage	At most one current stage, value must be an IRI typed ap:LifecycleStage
apsh:LifecycleStageShape	ap:LifecycleStage	Language-tagged label, single 1-based ap:stageOrder, single ap:nextStage; warns when a stage belongs to no model
apsh:LifecycleModelShape	ap:LifecycleModel	Language-tagged label, at least one ap:hasStage
apsh:CanonicalLifecycleStageShape	(none — opt-in)	Closes the value set to the five canonical stages

apsh:CanonicalLifecycleStageShape has no sh:target* by design, so it never fires on its own. The ISO 12207 stage model, the TIME framework states, and organisation-specific progressions are all legitimate alternatives; closing the vocabulary globally would report every one of them as a violation. Reference it via sh:node where your governance process requires the canonical set:

ex:ApplicationShape
    a sh:NodeShape ;
    sh:targetClass am4:ApplicationComponent ;
    sh:property [
        sh:path ap:atLifecycleStage ;
        sh:node apsh:CanonicalLifecycleStageShape ;
    ] .

Validate with .scripts/validate.sh --shacl arch-processes.

---

8. Reference Architecture Ontology (extensions/ref-arch/refArch.ttl)

Namespace: https://meta.linked.archi/ref-arch# (prefix: refa:) Version: 0.0.5 Authoritative sources: - Bass, L., Clements, P. & Kazman, R. — "Software Architecture in Practice" (4th ed., Addison-Wesley) - Clements, P. et al. — "Documenting Software Architectures" (2nd ed., Addison-Wesley) - SEI/CMU Software Architecture

Defines concepts for reference architectures, reference models, patterns, and tactics — the reusable building blocks of architecture. This extension provides the vocabulary for capturing architectural knowledge that transcends individual projects.

When to use: Import this extension when your metamodel needs to reference patterns (Layered, Microservices, Event-Driven), tactics (availability, security, performance), or reference architectures (BIAN, TM Forum). The Tactics extension (tac:) builds on this.

Classes

Class	Parent	Description
refa:ReferenceArchitecture	arch:Model	Abstract architectural elements independent of specific technologies
refa:ReferenceModel	arch:Metamodel	Abstract framework for understanding relationships in a domain
refa:Pattern	arch:Model	General, reusable solution to a commonly occurring problem
refa:Tactic	arch:Element	Design decision that influences a quality attribute response

Design Rationale

ReferenceModel as subclass of Metamodel: Reference models contain abstract concepts defined as classes. While they may contain individuals (universals or abstract tropes), the primary content is type-level. When used for derivation, prov:wasDerivedFrom should reference the original concept.

Pattern as subclass of Model: Patterns are composed of participants that can be any ModelConcept. Patterns are characterized as packages of design decisions (tactics), discovered in practice rather than invented, and categorized by dominant element type (Module, Integration, Deployment).

---

9. ArchiMate Ontology (modelingLanguages/archimate/)

Namespace: https://meta.linked.archi/archimate3/onto# (prefix: am:) Qualified namespace: https://meta.linked.archi/archimate3/onto# (prefix: am:) Version: 3.2.0 Derived from: ArchiMate 3.1 Specification (The Open Group) License: CC BY 4.0

A complete OWL mapping of the ArchiMate modelling language using the three-declaration qualified relationship pattern and RDF 1.2 rdf:reifies. This is not an official Open Group document.

Files

File	Version	Content
archimate3.2-onto.ttl	3.2.0	Current. Elements + relationships (three-declaration pattern)
archimate3.2-metamodel.ttl	3.2.0	Metamodel manifest — ties together all ArchiMate resources via arch:Metamodel composition properties
archimate3.2-viewpoint-shapes.ttl	3.2.0	SHACL shapes — viewpoint conformance (element/type/relationship checks)
archimate3.2-deliverable-templates.ttl	3.2.0	ArchiMate-specific deliverable templates (ADD, Requirements Spec, Principles Doc)
archimate3.2-reference-data.ttl	3.2.0	Reference data — environment types, criticality levels. Lifecycle stages live in ap: as ap:LifecycleStage instances; approval states in arch:ApprovalState
archimate3.2-reference-models.ttl	3.2.0	Reference models — architecture patterns, industry reference models
archimate3.2-presentation-contexts.ttl	3.2.0	Presentation contexts — stakeholder-specific rendering themes
archimate3.2-tax.ttl	3.2.0	SKOS taxonomy — elements by layer, by aspect; relationships by category
archimate3.2-relationship-shapes.ttl	3.2.0	SHACL shapes — per-relationship-type domain/range constraints (imports core-shapes)
archimate3.2-element-shapes.ttl	3.2.0	SHACL shapes — element/metamodel pattern constraints (24 shapes, SPARQL-based)
archimate3.2-derivation-rules.ttl	3.2.0	SHACL Rules — derivation rules DR1-DR8 + PDR1-PDR12 from Appendix B
abstracts/archimate3.2-abstracts.ttl	3.2.0	Removed. Abstract classes now live in archimate3.2-onto.ttl. Generated visualizations in .generated/archimate/.
archimate3.1-onto.ttl	3.1.0	Prior version — elements only, no relationships
archimate3-onto.ttl	3.0.0	Deprecated. Uses removed arch:Relationship, punning, rdfs:label
archimate3.1-tax.ttl	3.1	Prior taxonomy
archimate3.1-inf.ttl	3.1	Inference rules

Element Classes (62 elements across layers)

Motivation: Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint, Meaning, Value

Strategy: Resource, Capability, Value Stream, Course of Action

Business: Business Actor, Business Role, Business Collaboration, Business Interface, Business Process, Business Function, Business Interaction, Business Event, Business Service, Business Object, Contract, Representation, Product

Application: Application Component, Application Collaboration, Application Interface, Application Function, Application Interaction, Application Process, Application Event, Application Service, Data Object

Technology: Node, Device, System Software, Technology Collaboration, Technology Interface, Path, Communication Network, Technology Function, Technology Process, Technology Interaction, Technology Event, Technology Service, Artifact

Physical: Equipment, Facility, Distribution Network, Material

Implementation & Migration: Work Package, Deliverable, Implementation Event, Plateau, Gap

Composite: Grouping, Location

Connectors: And Junction, Or Junction

Relationship Types (11 types, three declarations each)

Category	Type	Unqualified Predicate	Qualified Class
Structural	Composition	am:composedOf	am:Composition
Structural	Aggregation	am:aggregates	am:Aggregation
Structural	Assignment	am:assignedTo	am:Assignment
Structural	Realization	am:realizes	am:Realization
Dependency	Serving	am:serves	am:Serving
Dependency	Access	am:accesses	am:Access
Dependency	Influence	am:influences	am:Influence
Dynamic	Triggering	am:triggers	am:Triggering
Dynamic	Flow	am:flowsTo	am:Flow
Other	Specialization	am:specializes	am:Specialization
Other	Association	am:associatedWith	am:Association

Access has am:accessType (Read/Write/ReadWrite/Access). Influence has am:influenceStrength (+/++/-/--).

Taxonomy Organization

Elements are classified along two dimensions via SKOS: - By Layer — Strategy, Business, Application, Technology, Physical, Implementation & Migration - By Aspect — Active Structure (internal/external), Passive Structure, Behavior (internal/external/events), Motivation, Composite, Strategy - By Relationship Category — Structural, Dependency, Dynamic, Other

SHACL Validation

The shapes file (archimate3.2-relationship-shapes.ttl) is generated from archimate-relationships-matrix.xml (sourced from the Archi tool, MIT licence) using .scripts/generate-archimate-shapes.py. It contains two sets of pure SHACL core shapes (no SPARQL):

• Qualified shapes (11): Validate QualifiedRelationship instances — exact source-target pair validation using sh:or + sh:and
• Unqualified shapes (62): Validate direct triples — one shape per source element class with sh:property constraints per predicate

Access and Influence shapes also validate their attribute properties (accessType, influenceStrength).

Derivation Rules

The derivation rules file (archimate3.2-derivation-rules.ttl) implements ArchiMate Appendix B using SHACL Rules (sh:SPARQLRule with sh:construct). Two confidence levels:

• Valid (DR1-DR8): Definitely correct per the spec. Covers specialization transitivity, structural chains (weakest-wins), structural+dependency combinations, structural+dynamic combinations, and triggering transitivity.
• Potential (PDR1-PDR12): Possibly correct, needs review. Covers specialization inheritance (forward/reverse/source/target), structural+dependency at source, dependency chains (weakest-wins), flow+structural, flow transitivity, and grouping element derivation.

Relationship strength determines the result when combining: - Structural: composition(4) > aggregation(3) > assignment(2) > realization(1) - Dependency: serving(4) > access(3) > influence(2) > association(1)

Derived triples are annotated with RDF 1.2 reification metadata: amderiv:derivationCertainty (:Valid or :Potential), prov:wasGeneratedBy (named prov:Activity individuals for each rule), and prov:wasDerivedFrom (the source relationships) for provenance tracking.

Validate with: .scripts/validate.sh --shacl archimate-derived

---

10. Backstage Ontology (modelingLanguages/backstage/)

Namespace: https://meta.linked.archi/backstage/onto# (prefix: bs:) Qualified namespace: https://meta.linked.archi/backstage/onto# (prefix: bs:) Version: 0.5.0 Imports: arch:core License: CC BY 4.0 (modelling work only — quoted definitions remain © the Backstage Project Authors under Apache-2.0, per dcterms:rightsHolder/dcterms:rights on the header)

Maps the Backstage developer portal catalogue model to the Linked.Archi core ontology, enabling integration of service catalogues into the architecture knowledge graph.

Scope — read this before concluding a term is missing

The ontology header carries a skos:editorialNote headed SCOPE STATEMENT. It is the authoritative list of what the document covers and what it deliberately does not, and it exists because converters are expected not to mint terms in the bs: namespace — a rule that only works if a deliberate omission is distinguishable from an oversight. The history notes accumulate per release and cannot serve that purpose.

In scope: eight of the descriptor format's nine kinds, the envelope, the reserved metadata fields, the well-known relations, the well-known annotations, the spec.type and state vocabularies, and status.items.

Deliberately out of scope, each with its reasoning and an alternative in the statement itself:

Not modelled	Why, in short	What to do instead
The Location kind	Ingestion configuration, not a node in an architecture	bs:managedByLocation / bs:managedByOriginLocation already retain the reference on the entities a location produced; drop Location entities and report the count
spec.parameters, spec.steps on a Template	Unbounded plugin-defined JSON; the template's implementation, not an architectural fact	Declare a predicate you own
status.items[].error	Shape not fixed upstream; a stack trace is a debugging artifact	The item's type, level and message are published
Per-key labels / annotations predicates	Open key spaces organisations define	Per-key subproperty of bs:label / bs:externalIdentifier in your own namespace

Files

File	Content
backstage-onto.ttl	Elements, relationships (three-declaration pattern), and value vocabularies (named individuals, DD-23)
backstage-metamodel.ttl	Metamodel manifest — ties together all Backstage resources; restates the kind coverage decision
backstage-shapes.ttl	SHACL shapes — per-relationship-type constraints, entity identity, naming, status items, kind-specific property placement, vocabulary closure (imports core-shapes)
backstage-tax.ttl	SKOS taxonomy — software entities vs organizational entities
backstage-notation.ttl	Visual notation set — one descriptor per element class (no relationship notation yet)
backstage-viewpoints.ttl	7 viewpoints (ServiceCatalog, SystemDependency, APIDependency, OwnershipMatrix, DomainOverview, OrganizationStructure, LifecyclePortfolio)
backstage-deliverable-templates.ttl	Deliverable templates — Service Catalog Document, System Architecture Document, Organization Structure Document
backstage-reference-data.ttl	Cross-module correspondences only (e.g. lifecycle ↔ Architecture Processes stages via skos:closeMatch)
backstage-presentation-contexts.ttl	Presentation contexts — Developer, Platform Engineer, Engineering Manager

Classes

Each class carries skos:notation with its exact descriptor-format kind token, publishing the token→class map a lift needs. Tokens are title-case, unlike the lowercase spec.type tokens on the value vocabularies. The map is a default, not an identity: rdf:type and the retained bs:kind are both recorded and may legitimately diverge.

Class	Parent	skos:notation	Description
bs:Component	arch:Element	Component	Deployable unit, service, library, or application
bs:System	arch:Element	System	Set of components providing business/technical value
bs:API	arch:Element	API	An API in the ecosystem
bs:Resource	arch:Element	Resource	Resource used by components (database, bucket, etc.)
bs:Domain	arch:Element	Domain	High-level business domain grouping
bs:User	arch:Element	User	Human user
bs:Group	arch:Element	Group	Group of users (team, department)
bs:Template	arch:Element	Template	Scaffolder template — the parameters and steps used to create a component

Two published classes are not arch:Element, deliberately: bs:Link and bs:StatusItem. A hyperlink and an ingestion diagnostic are metadata about a node rather than nodes, so neither appears in a viewpoint, neither carries a naming or identity obligation, and neither has a visual notation.

bs:Template is the one class the catalog model does not own — the scaffolder plugin does, and versions it separately on scaffolder.backstage.io/v1beta3 against backstage.io/v1alpha1 for the other seven. That is why bs:apiVersion is retained per entity rather than assumed constant across a catalogue.

Sources — rendered docs and repository, and which one wins

Every term cites the rendered page at backstage.io and, where a machine-readable artifact exists, the file in github.com/backstage/backstage that defines it:

Artifact	Covers
packages/catalog-model/src/schema	Entity, EntityEnvelope, EntityMeta, and one schema per catalog kind
plugins/scaffolder-common/src/Template.v1beta3.schema.json	Template — not a catalog-model kind
docs/features/software-catalog	Markdown source of the rendered pages

The two are not redundant. The rendered page is the human account and carries the section anchors dcterms:source points at; the repository file is what the catalogue actually enforces. Where they disagree the schema is authoritative, and the divergence is recorded on the term.

There is one such divergence today, and finding it is why the convention was adopted rather than assumed: the descriptor format page documents Template as backstage.io/v1beta2 and does not mention its spec.lifecycle; the schema admits only scaffolder.backstage.io/v1beta3 and declares spec.lifecycle. Modelling from the rendered page alone would have published a version string the scaffolder rejects and dropped a field real templates carry.

Entity Identity

The identity fields are retained source data (DD-24), read from the descriptor rather than computed.

Property	Role
rdf:type	How this graph classifies the entity — a modelling decision, revisable. Drives sh:targetClass/sh:class and the rdfs:subClassOf closure.
bs:apiVersion	The descriptor schema version the entity declared. maxCount 1, not required. Worth keeping per entity because Template is on scaffolder.backstage.io/v1beta3 while the rest are on backstage.io/v1alpha1.
bs:kind	What the catalogue said (kind root field), title-case. Not a duplicate of rdf:type and not derived from it; divergence is reported at sh:Info by bssh:KindTypeAlignmentShape. maxCount 1, not required — a natively authored model has no descriptor to retain.
bs:name	metadata.name. Required (Violation), maxCount 1. Half the entity reference; the cross-source join key.
bs:namespace	metadata.namespace. Absent means "default"; a lift should materialise it (Warning if missing).
bs:entityRef	The compact kind:namespace/name reference the catalogue circulates in relations, spec.owner, spec.system, spec.dependsOn and the techdocs-entity annotation. Under dcterms:identifier. bssh:EntityRefConsistencyShape checks it against bs:kind/bs:namespace/bs:name — not against rdf:type.
bs:uid	Catalog-assigned, output-only, not stable across re-registration. Provenance only; never a join key or IRI source.

Relationship Types (13 types, three declarations each)

Type	Unqualified Predicate	Qualified Class
Ownership	bs:ownedBy	bs:Ownership
System Membership	bs:partOfSystem	bs:SystemMembership
API Provision	bs:providesAPI	bs:APIProvision
API Consumption	bs:consumesAPI	bs:APIConsumption
Dependency	bs:dependsOn	bs:Dependency
Resource Usage	bs:usesResource (subproperty of bs:dependsOn)	bs:ResourceUsage
Domain Membership	bs:belongsToDomain	bs:DomainMembership
Group Membership	bs:memberOf	bs:GroupMembership
Group Parentage	bs:childOf	bs:GroupParentage
Component Composition	bs:subcomponentOf	bs:ComponentComposition
Domain Hierarchy	bs:subdomainOf	bs:DomainHierarchy
TechDocs Delegation	bs:techdocsDelegatedTo	bs:TechDocsDelegation
Scaffolding	bs:scaffoldedFrom	bs:Scaffolding

bs:scaffoldedFrom runs from the created entity to the bs:Template, lifted from backstage.io/source-template. The annotation literal stays on bs:sourceTemplate alongside the edge rather than being replaced by it — same division as bs:kind against rdf:type. Where the pull did not include the template, keep the literal and assert no edge; the absent edge then means unresolved rather than not scaffolded, and "which entities came from no approved template" becomes answerable.

Entity Status

status is read-only — descriptor files must not contain it, so items only appear in a lift of the catalog API. One node per item, because a level and a message flattened onto the entity lose which belongs to which, and the specification is explicit that several systems contribute items independently.

Term	Role
bs:StatusItem	One entry in an entity's status. Not an arch:Element.
bs:hasStatusItem	Entity → item. Multi-valued.
bs:statusType	Which system contributed the item, e.g. backstage.io/catalog-processing. A literal, not a vocabulary: it identifies a source, the set is open, and every plugin extends it. Required on an item.
bs:statusLevel	→ bs:InfoLevel / bs:WarningLevel / bs:ErrorLevel. Closed at Violation. Level suffix because the bare tokens collide with SHACL severities.
bs:statusMessage	Human-readable, not language-tagged (the catalogue emits no locale). Do not parse it.

Read an error item the right way round: where the type is backstage.io/catalog-processing, an error means the catalogue could not ingest the source and has deliberately kept the last version that did. The item says the record beside it is stale, not that the record is wrong.

Value Vocabularies (9, named individuals — DD-23, no owl:oneOf)

Vocabulary	Property	Individuals
bs:LifecycleState	bs:lifecycleState	bs:Experimental, bs:Production, bs:DeprecatedState — on Component, API and Template
bs:ApiVisibility	bs:apiVisibility	bs:Public, bs:Restricted, bs:Private
bs:StatusLevel	bs:statusLevel	bs:InfoLevel, bs:WarningLevel, bs:ErrorLevel — closed (Violation)
bs:ComponentType	bs:componentType	bs:ServiceType, bs:WebsiteType, bs:LibraryType
bs:APIType	bs:apiType	bs:OpenAPI, bs:AsyncAPI, bs:GraphQL, bs:GRPC
bs:ResourceType	bs:resourceType	bs:DatabaseResourceType, bs:S3BucketResourceType, bs:KubernetesClusterResourceType
bs:GroupType	bs:groupType	bs:TeamGroupType, bs:BusinessUnitGroupType, bs:ProductAreaGroupType, bs:RootGroupType
bs:SystemType	bs:systemType	bs:ProductSystemType, bs:ServiceSystemType, bs:FeatureSetSystemType
bs:DomainType	bs:domainType	bs:ProductAreaDomainType, bs:ProductGroupDomainType, bs:BundleDomainType

bs:componentType serves two kinds. On a Component it describes the component; on a Template it describes the component the template creates — the descriptor format defines a template's spec.type that way and says it should match the created component's own type, so one vocabulary is used from both ends. A query joining the two has to say which end it means.

bs:lifecycle (a plain xsd:string) is owl:deprecated as of 0.3.0, superseded by bs:lifecycleState.

Labels — the intended pattern

bs:label is an abstract super-property, and the pattern is one predicate per label key, in the reader's own namespace, parented on it:

acme:tier a owl:DatatypeProperty ; rdfs:subPropertyOf bs:label .

ex:payment-processor acme:tier "gold" .

That keeps "every label on this entity" a one-triple query (?e bs:label ?v) while giving each key something specific to query. A reified Label node with labelKey/labelValue is explicitly not the pattern — a label is one scalar under one key, so the key is the predicate and a node would add a hop carrying nothing. Reification is reserved for the positional structures, bs:Link and bs:StatusItem.

No shape enforces this, and the reason is worth knowing: acme:tier rdfs:subPropertyOf bs:label makes every correct per-key assertion entail a bs:label triple, so a shape reporting subjects of bs:label would pass on the malformed graph a validator ran without inference and fail on the well-formed one it ran with. The same applies to bs:externalIdentifier.

---

11a. C4 Model Ontology (modelingLanguages/c4/)

Namespace: https://meta.linked.archi/c4/onto# (prefix: c4:) Qualified namespace: https://meta.linked.archi/c4/onto# (prefix: c4:) Version: 0.2.0 Imports: arch:core License: CC BY 4.0

An RDF/OWL ontology for C4 model and Structurizr elements and relationships.

Files

File	Content
c4-onto.ttl	Elements + relationships (three-declaration pattern)
c4-metamodel.ttl	Metamodel manifest — ties together all C4 resources
c4-shapes.ttl	SHACL shapes — per-relationship-type constraints (imports core-shapes)
c4-tax.ttl	SKOS taxonomy — elements by abstraction level
c4-viewpoints.ttl	7 C4 viewpoints (4 core levels + 3 supplementary) with SKOS catalogue
c4-deliverable-templates.ttl	Deliverable templates — System Overview, Component Design
c4-reference-data.ttl	Reference data — container technologies, deployment environments
c4-presentation-contexts.ttl	Presentation contexts — Product Owner, Dev Team, Platform Team

Classes

Class	Parent	Description
c4:Person	arch:Element	A person who uses the software system
c4:SoftwareSystem	arch:Element	A software system in the C4 model
c4:Container	arch:Element	A container (application, service, database) within a software system
c4:Component	arch:Element	A component (code-level module) within a container
c4:DeploymentNode	arch:Element	Physical or virtual infrastructure element
c4:InfrastructureNode	c4:DeploymentNode	Specific infrastructure node (database server, load balancer)

Relationship Types (4 types, three declarations each)

Type	Unqualified Predicate	Qualified Class
Using	c4:uses	c4:Using
Container Containment	c4:hasContainer	c4:ContainerContainment
Component Containment	c4:hasComponent	c4:ComponentContainment
Deployment	c4:deployedOn	c4:Deployment

---

11b. LeanIX Meta Model (modelingLanguages/leanIX/)

Namespace: https://meta.linked.archi/leanix/onto# (prefix: lmm:) Qualified namespace: https://meta.linked.archi/leanix/onto# (prefix: lmm:) License: CC BY 4.0

Ontology representations of the SAP LeanIX Meta Model fact sheets and relations.

Files

File	Version	Content
leanIX-v4-onto.ttl	4.0.0	Current. v4 fact sheet types, 16 relationship types (three-declaration pattern) and the fact sheet attributes
leanIX-metamodel.ttl	0.1.0	v4 metamodel manifest, and the home of the version-free lmmmm:LeanIXFramework
leanIX-v3-metamodel.ttl	0.1.0	v3 metamodel manifest — what a v3-shaped workspace conforms to
leanIX-shapes.ttl	0.1.0	Fact sheet naming for both namespaces, v4 attribute value sets, and one endpoint shape per relationship type
leanIX-viewpoints.ttl	0.1.0	5 viewpoints (ApplicationPortfolio, TechnologyLandscape, InterfaceMap, CapabilityMap, TransformationRoadmap)
leanIX-tax.ttl	0.1.0	SKOS taxonomy — fact sheets by architecture layer (Strategy, Business, App & Data, Technical)
leanIX-notation.ttl	0.1.0	Default element and relationship appearance
leanIX-deliverable-templates.ttl	0.1.0	Application portfolio report, transformation plan document
leanIX-v3-onto.ttl	3	Prior version — v3 fact sheet types, elements only

Both meta model versions point arch:basedOnFramework at the single lmmmm:LeanIXFramework individual in leanIX-metamodel.ttl, which carries no version in its IRI or its label, per DD-25. The version lives on the arch:Metamodel individual — owl:versionInfo "4" on lmmmm:LeanIXv4, "3" on lmm3mm:LeanIXv3.

v4 Fact Sheet Types

Strategy & Transformation: Objective, Initiative

Business: Business Capability, Organization (+ Organization Unit subtype), Business Context (+ Product, Value Stream, Process subtypes)

Application & Data: Application (+ Business Application, Deployment, Microservice subtypes), Interface, Data Object

Technical: IT Component, Tech Category, Platform, Provider

Optional: System

v4 Relationship Types (16 types, three declarations each)

Type	Unqualified Predicate	Qualified Class	Domain → Range
Supporting	lmm:supports	lmm:Supporting	Application → BusinessCapability
Requiring	lmm:requires	lmm:Requiring	Application → ITComponent
Interface Ownership	lmm:hasInterface	lmm:InterfaceOwnership	Application (provider) → Interface
Interface Consumption	lmm:consumesInterface	lmm:InterfaceConsumption	Application (consumer) → Interface
Data Usage	lmm:usesData	lmm:DataUsage	Application, Interface → DataObject
Impact	lmm:impacts	lmm:Impact	Initiative → Application, Platform
Driving	lmm:drives	lmm:Driving	Objective → Initiative
Organizational Usage	lmm:usedByOrg	lmm:OrganizationalUsage	Organization → Application
Provision	lmm:providedBy	lmm:Provision	ITComponent → Provider
Categorization	lmm:categorizedBy	lmm:Categorization	ITComponent → TechCategory
Fact Sheet Hierarchy	lmm:parentOf	lmm:FactSheetHierarchy	FactSheet → FactSheet (same type)
Platform Membership	lmm:partOfPlatform	lmm:PlatformMembership	Application, BusinessCapability, ITComponent → Platform
Context Support	lmm:supportsContext	lmm:ContextSupport	Application → BusinessContext
Context Realization	lmm:contextRealizes	lmm:ContextRealization	BusinessContext → BusinessCapability
Capability Targeting	lmm:targetsCapability	lmm:CapabilityTargeting	Objective → BusinessCapability
System Composition	lmm:composedOf	lmm:SystemComposition	System → Application, ITComponent

The last five carry a skos:editorialNote recording that the name is this ontology's, not SAP's: the modeling guidelines describe these relations in prose — a Platform groups capabilities, applications and technologies — without naming them the way they name relToParent. The existence is sourced; the term is not.

Each of the sixteen has an endpoint shape in leanIX-shapes.ttl turning its declared ends into a check, since arch:domainIncludes is advisory by construction (DD-8) and core-shapes only asks that both ends be some arch:ModelConcept — which leaves a lmm:Provision between two Applications passing clean.

Interface provision and interface consumption are separate relationships because LeanIX gives an interface one provider and any number of consumers, and an integration map is unreadable without that asymmetry. lmm:parentOf covers relToParent/relToChild, the only structural relation in the meta model and the one a capability breakdown is made of; it runs parent → child, and emitting skos:broader from child to parent alongside it gives SKOS-aware consumers the tree for free.

v4 Fact Sheet Attributes

LeanIX	Term	Value
id	skos:notation	the workspace's own identifier
displayName	skos:prefLabel	language-tagged (DD-24)
name	skos:altLabel
description	skos:definition
type	dcterms:type	verbatim token, retained source data
createdAt / updatedAt	dcterms:created / dcterms:modified
status	lmm:factSheetStatus	lmm:StatusActive, lmm:StatusArchived, lmm:StatusBroken
completion	lmm:completion	xsd:decimal between 0 and 1
lifecycle.asString	ap:atLifecycleStage	an ap:LifecycleStage
lifecycle.phases[]	lmm:hasLifecyclePhase → lmm:LifecyclePhase	ap:atLifecycleStage plus lmm:phaseStart
subscriptions[]	lmm:hasSubscription → lmm:Subscription	lmm:subscriber (an arch:Stakeholder), lmm:subscriberEmail, lmm:subscriptionType, lmm:subscriptionRole
tags[]	lmm:hasTag → lmm:Tag	lmm:tagName, lmm:tagGroup
workspace-defined fields	none	per-tenant by definition — use a namespace you own

ex:app-1
    a                     lmm:Application ;
    skos:prefLabel        "Payments Platform"@en ;
    skos:notation         "0a1b2c3d" ;
    lmm:factSheetStatus   lmm:StatusActive ;
    lmm:completion        0.8 ;
    ap:atLifecycleStage   ap:Active ;
    lmm:hasLifecyclePhase ex:app-1-active ;
    lmm:hasSubscription   ex:sub-1 .

ex:app-1-active
    a                   lmm:LifecyclePhase ;
    ap:atLifecycleStage ap:Active ;
    lmm:phaseStart      "2021-04-01"^^xsd:date .

ex:sub-1
    a                    lmm:Subscription ;
    lmm:subscriber       ex:jane ;
    lmm:subscriptionType lmm:Accountable ;
    lmm:subscriptionRole "Application Owner" .

Three things a converter author should read twice. Lifecycle stages come from the Architecture Processes extension, not from lmm: — that extension's five canonical stages were derived from LeanIX's own lifecycle documentation and each carries a skos:closeMatch to the anchor it came from, so a phase token resolves by kebab-casing it (phaseIn → #phase-in). Reusing them is what makes "every asset in phase-out" one query across LeanIX, ArchiMate and Backstage data. Status and subscription type are named individuals (DD-23), so lmm:factSheetStatus "ACTIVE" fails validation; the value is lmm:StatusActive, whose skos:notation is that token. And lmm:StatusActive is not ap:Active — one says the record is live in the workspace, the other says the application is in operational use, and an archived fact sheet can describe a running application.

The value sets and cardinalities are enforced in leanIX-shapes.ttl rather than in OWL: no property is owl:FunctionalProperty and no vocabulary is closed with owl:oneOf, so a workspace that gains a status can add it without editing a published document. Run them with .scripts/validate.sh --shacl leanix, which validates examples/leanix-docs-example/ — a landscape assembled from the examples SAP's own LeanIX documentation gives for each fact sheet type, with per-element source links and an editorial note separating the documented values from the illustrative ones.

---

11c. Business Model Canvas (modelingLanguages/bmc/)

Namespace: https://meta.linked.archi/bmc/onto# (prefix: bmc:) Version: 0.2.0 License: CC BY 4.0

A SKOS vocabulary representing the nine building blocks of the Business Model Canvas by Alexander Osterwalder.

Files

File	Content
bmc.ttl	SKOS vocabulary — the nine BMC building blocks
bmc-metamodel.ttl	Metamodel manifest — minimal, links to the SKOS scheme

Concept Scheme

bmc:BMCScheme groups all nine concepts under bmc:BMCElement:

Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partners, Cost Structure.

---

11d. BPMN 2.0.2 Ontology (modelingLanguages/bpmn/)

Namespace: https://meta.linked.archi/bpmn/onto# (prefix: bpmn:) Version: 0.2-draft Derived from: OMG BPMN 2.0.2 Specification (XMI) Validated against: Semantic.xsd, BPMN20.xsd, BPMNDI.xsd, DI.xsd, DC.xsd, Infrastructure.cmof (.reference/omg/bpmn202/) Imports: arch:core/0.3.2, arch:core-vis

A comprehensive OWL mapping of the BPMN 2.0.2 specification, auto-generated from the OMG XMI source and validated against the normative XSD/CMOF artifacts. Includes semantic classes, diagram interchange (BPMNDI/DI/DC), infrastructure, and SHACL shapes.

Files

File	Content
bpmn-metamodel.ttl	Metamodel manifest — ties together all BPMN modules
bpmn-viewpoints.ttl	4 viewpoints (ProcessFlow, Collaboration, Choreography, Conversation)
bpmn-deliverable-templates.ttl	Deliverable templates for BPMN artifacts
linkedarchi-bpmn-onto.ttl	BPMN semantic classes (Activity, Event, Gateway, Flow, etc.)
linkedarchi-bpmn-shacl.ttl	SHACL shapes for BPMN semantic classes
linkedarchi-bpmn-infra-onto.ttl	BPMN infrastructure (Definitions, Import)
linkedarchi-bpmn-infra-shacl.ttl	SHACL shapes for infrastructure
linkedarchi-bpmndi-onto.ttl	BPMNDI diagram interchange classes
linkedarchi-bpmndi-shacl.ttl	SHACL shapes for BPMNDI
linkedarchi-di-onto.ttl	DI (Diagram Interchange) abstract classes
linkedarchi-di-shacl.ttl	SHACL shapes for DI
linkedarchi-dc-onto.ttl	DC (Diagram Common) datatypes (Bounds, Point, Font)
linkedarchi-dc-shacl.ttl	SHACL shapes for DC
linkedarchi-bpmn-suite-imports.ttl	Import aggregator
linkedarchi-bpmn-suite-shapes.ttl	Combined shapes aggregator

Alignment to Core

The alignment to the core ontology is declared inline in linkedarchi-bpmn-onto.ttl, on the classes themselves, as every other modelling language in this repository does it. Of the 144 classes in bpmn/onto, 49 are arch:Element, 12 are arch:QualifiedRelationship, and the remaining 83 are neither — they are serialization carriers and metamodel bookkeeping, not architecture concepts.

arch:Element is asserted on 11 roots, which reach 49 classes through rdfs:subClassOf:

• bpmn:FlowNode — activities and their 12 task/sub-process subtypes, choreography activities, and all Gateway and Event subtypes
• bpmn:Process, bpmn:Collaboration (also Choreography, GlobalChoreographyTask)
• bpmn:ConversationNode (Conversation, SubConversation, CallConversation)
• bpmn:Participant, bpmn:Lane
• bpmn:DataObject, bpmn:DataObjectReference, bpmn:DataStore, bpmn:DataStoreReference
• bpmn:Message

12 BPMN relationship classes (Association, SequenceFlow, MessageFlow, DataAssociation, etc.) are rdfs:subClassOf arch:QualifiedRelationship.

Gateways and events are elements. They have identity, they render on diagrams, and they belong in element counts. BPMN 2.0.2 makes their name optional, but that is a naming question rather than a question about what they are — see bpmnsh:RequiredNameShape, which lists only the 12 classes BPMN requires to be named and therefore does not target them.

Not arch:Element: the 12 connector classes (they are arch:QualifiedRelationship), the serialization and bookkeeping classes (bpmn:Documentation, bpmn:TextAnnotation, bpmn:Group, bpmn:ItemDefinition, bpmn:Expression, bpmn:EventDefinition, bpmn:InputSet and the rest), and bpmn:BaseElement itself.

Maintainer note: do not align bpmn:BaseElement. It is the abstract root of the whole BPMN metamodel, so aligning it makes every serialization artefact an architecture element — 130 of 144 classes — and makes bpmn:SequenceFlow both an element and a relationship. Element counts and arch:Element queries inflate accordingly.

---

12. TOGAF 9.2 (frameworks/togaf/)

Content Metamodel (togaf.ttl)

Namespace: https://meta.linked.archi/togaf/metamodel# (prefix: togaf:) Version: 9.2 Derived from: TOGAF 9.2 Chapter 30

Defines the TOGAF Content Metamodel element togaf:TogafElement (subclass of arch:Element) and togaf:Principle.

ADM Phases (TOGAF_9.2-ADM.ttl)

SKOS taxonomy of the TOGAF Architecture Development Method phases (Preliminary, A through H, Requirements Management), their steps, inputs, outputs, and deliverables.

Viewpoints (togaf-vp.ttl)

Defines TOGAF viewpoints as arch:Viewpoint individuals, e.g., togvp:PrinciplesCatalog with arch:includesConcept togaf:Principle.

---

13. DoDAF 2.02 (frameworks/dodaf/)

Ontology namespace: https://meta.linked.archi/dodaf/onto# (prefix: dodaf:) Taxonomy namespace: https://meta.linked.archi/dodaf/tax# (prefix: dodaftax:) Viewpoints namespace: https://meta.linked.archi/dodaf/viewpoints# (prefix: dodafvp:) Version: 2.02 Derived from: DoDAF V2.02 (U.S. Department of Defense, 2010)

The U.S. Department of Defense Architecture Framework. DoDAF 2.0 shifted from rigid "products" to a data-centric approach with "Fit-for-Purpose" presentation. The ontology captures the underlying data model that the 8 viewpoints and 52 DoDAF-described Models present.

Files

File	Namespace	Content
dodaf-onto.ttl	dodaf/onto#	22 entity types (Capability, OperationalActivity, System, Service, data entities, etc.) + 10 relationships
dodaf-tax.ttl	dodaf/tax#	SKOS taxonomy classifying entities by the 8 DoDAF viewpoints
dodaf-vp.ttl	dodaf/viewpoints#	28 viewpoint individuals (AV-1/2, CV-1–7, DIV-1/2/3, OV-1–6c, PV-1/2/3, StdV-1/2) + 9 stakeholders
dodaf-metamodel.ttl	dodaf/metamodel#	Metamodel manifest

Viewpoints (8 categories, 52 models)

Viewpoint	Prefix	Key Models
All (AV)	AV-1, AV-2	Overview, Integrated Dictionary
Capability (CV)	CV-1 through CV-7	Vision, Taxonomy, Phasing, Dependencies, Mappings
Data & Information (DIV)	DIV-1, DIV-2, DIV-3	Conceptual, Logical, Physical data models
Operational (OV)	OV-1 through OV-6c	Concept graphic, Resource flows, Activity models, Rules, State transitions
Project (PV)	PV-1, PV-2, PV-3	Portfolio relationships, Timelines, Capability mapping
Services (SvcV)	SvcV-1 through SvcV-10c	Service context, Flows, Functionality, Traceability, Evolution
Standards (StdV)	StdV-1, StdV-2	Standards profile, Standards forecast
Systems (SV)	SV-1 through SV-10c	System interfaces, Flows, Functionality, Traceability, Evolution

Data and Information Viewpoint (DIV)

The three-level data modelling pattern is particularly relevant for ML-enabled systems (Moin et al. 2023):

• DIV-1 (Conceptual) — High-level data concepts for non-technical stakeholders
• DIV-2 (Logical) — Attributed data entities for system architects and analysts
• DIV-3 (Physical) — Implementation-level schemas for database engineers and developers

---

14. Zachman Framework (frameworks/zachman/zachman-onto.ttl, zachman-tax.ttl)

Namespace: https://meta.linked.archi/zachman/onto# (prefix: zach:) — concepts in https://meta.linked.archi/zachman/onto# Version: 0.5.0 Derived from: Zachman International, FEAC Institute

SKOS taxonomy of the Zachman Framework 6×6 classification matrix. Models six Aspects (columns: Inventory/What, Process/How, Distribution/Where, Responsibility/Who, Timing/When, Motivation/Why), six Perspectives (rows: Executive/Identification, Business Management/Definition, Architect/Representation, Engineer/Specification, Technician/Configuration, Enterprise/Instantiation), and 36 Cells (intersections).

Interrogatives (Columns)

Concept	Description
What (Data)	Data and information entities
How (Function)	Processes and functions
Where (Network)	Locations and network topology
Who (People)	People, roles, organizational units
When (Time)	Events, cycles, schedules
Why (Motivation)	Goals, strategies, business rules

Perspectives (Rows)

Concept	Stakeholder	Level
Executive (Planner)	Strategist	Scope / Contextual
Business Management (Owner)	Domain Expert	Business Concepts
Architect (Designer)	Systems Analyst	System Logic
Engineer (Builder)	Developer	Technology Model
Technician (Implementer)	Programmer, DBA	Tool Configuration
User (Worker)	End User, Operator	Functioning Enterprise

Use Zachman concepts to tag viewpoints and artifacts with their classification:

ex:DataModelViewpoint a arch:Viewpoint ;
    arch:viewpointCoversAspect zachtax:Inventory ;
    arch:viewpointAddressesPerspective zachtax:Architect .

---

15. ADMIT Framework (frameworks/admit/)

Ontology namespace: https://meta.linked.archi/admit/onto# (prefix: admit:) Taxonomy namespace: https://meta.linked.archi/admit/tax# (prefix: admittax:) Version: 0.1.0 Derived from: ADMIT Framework — InfoQ (Prasad Rao, 2013)

Files

File	Namespace	Content
admit-onto.ttl	admit/onto#	20 design force OWL classes (rdfs:subClassOf ad:Force)
admit-tax.ttl	admit/tax#	SKOS taxonomy: architecture levels, domains, resource dimensions, design forces classification, ADLC lifecycle
admit-metamodel.ttl	admit/metamodel#	Metamodel manifest

Design Forces (Ontology)

20 OWL classes extending ad:Force from the architecture decisions extension: BusinessForce, OperationForce, AestheticismForce, FutureForce, SimplicityForce, ChangeForce, ProcessForce, IntegrationForce, ImplementationPatternForce, EnterpriseForce, ConstraintEnvironmentForce, FailureForce, ChannelForce, ContentForce, PlatformForce, InfrastructureForce, NetworkForce, StorageForce, SecurityForce, CostForce.

Taxonomy

• Architecture Levels — Enterprise, Solution, System
• Architecture Domains — Business (Why), Information/Data (What), Application/Service (How), Technology (Where)
• Resource Dimensions — Workload, Demand, Throughput, Latency, Capacity, Redundancy
• Design Forces — SKOS concepts linked to OWL classes via rdfs:seeAlso
• Architecture Development Lifecycle — 15 processes in 5 phases across 3 areas

---

16. TIME Framework (frameworks/TIME/)

Ontology namespace: https://meta.linked.archi/time-framework/onto# (prefix: timefw:) Taxonomy namespace: https://meta.linked.archi/time-framework/tax# (prefix: timetax:) Shapes namespace: https://meta.linked.archi/time-framework/shapes# (prefix: timesh:) Derivation namespace: https://meta.linked.archi/time-framework/derivation# (prefix: timederiv:) Crossmappings namespace: https://meta.linked.archi/time-framework/crossmappings# (prefix: timexm:) Version: 0.2.0 Imports: arch:core Primer: TIME Framework Primer & Modelling Guide

Models the Gartner TIME (Tolerate, Invest, Migrate, Eliminate) framework for application portfolio management.

Files

File	Namespace	Layer	Purpose
time-onto.ttl	time-framework/onto#	OWL (reasoning)	Classes, properties, enumeration types with owl:oneOf, OWL equivalent class definitions that auto-classify assessments into TIME quadrants
time-shapes.ttl	time-framework/shapes#	SHACL (validation)	Closed-world constraints — required fields, value ranges (scores 1-5), cardinalities, controlled vocabulary enforcement, disposition–rating consistency guard
time-tax.ttl	time-framework/tax#	SKOS (navigation)	7 ConceptSchemes organizing enumeration individuals for UI dropdowns, documentation, and faceted search
time-derivation.ttl	time-framework/derivation#	SHACL Rules (derivation)	Disposition movement derivation with PROV-O provenance
time-crossmappings.ttl	time-framework/crossmappings#	SKOS mappings	Editorial correspondences to ArchiMate 3.2/4.0, Backstage, TOGAF
time-metamodel.ttl	time-framework/metamodel#	Manifest	Ties together all layers into a single discoverable resource

Why multiple layers? Each answers a different question: - OWL answers: "This assessment has High/High ratings → it is an InvestAssessment" (inference) - SHACL shapes answer: "This assessment is missing a timeDisposition → validation error" (constraint) - SHACL rules answer: "This assessment's disposition changed from Tolerate to Migrate → Degraded" (derivation) - SKOS answers: "What are the valid TIME dispositions? → Tolerate, Invest, Migrate, Eliminate" (navigation)

Classes

Class	Description
timefw:Application	Application being assessed
timefw:FitAssessment	Point-in-time assessment with functional/technical fit
timefw:BusinessCapability	Business capability (SKOS concept)
timefw:TechnologyComponent	Technology dependency
timefw:Person	Assessor, business/IT owner
timefw:Evidence	Supporting evidence for assessment decisions
timefw:FitCriterion	Evaluation criterion
timefw:FitCriterionScore	Scored evaluation of one criterion
timefw:TimeAssessmentModel	Scoring model (scale, thresholds)
timefw:InvestAssessment	OWL-classified: High functional + High technical
timefw:MigrateAssessment	OWL-classified: High functional + Low technical
timefw:TolerateAssessment	OWL-classified: Low functional + High technical
timefw:EliminateAssessment	OWL-classified: Low functional + Low technical

SHACL Validation

Shape	Target	Key Constraints
ApplicationShape	timefw:Application	Required: skos:prefLabel. Warning: should have assessment. Owner must be Person.
FitAssessmentShape	timefw:FitAssessment	Required: application, date, disposition. Scores: integer 1-5. Ratings: High/Low. SPARQL guard: disposition must match ratings when both present.
EvidenceShape	timefw:Evidence	Required: label, evidence type (from 8 valid values).
FitCriterionScoreShape	timefw:FitCriterionScore	Required: criterion reference, score 1-5.
FitCriterionShape	timefw:FitCriterion	Required: label, dimension (Functional/Technical/Cost).

Controlled Vocabularies

• timefw:TimeDisposition — Tolerate, Invest, Migrate, Eliminate
• timefw:FitRating — High, Low
• timefw:FitDimension — Functional (altLabel: "Business value"), Technical (altLabel: "IT quality"), Cost
• timefw:AssessmentStatus — Draft, Approved, Superseded, Rejected
• timefw:EvidenceType — ArchitectureReview, SecurityAssessment, OperationsMetrics, CostAnalysis, BusinessStakeholderInput, VendorRoadmap, TechnicalDebtRegister, OtherEvidence
• timefw:LifecycleState — Plan, Build, Run, Retire
• timefw:DispositionMovement — Improved, Degraded, Unchanged, NewAssessment

Includes OWL class expressions for automatic TIME quadrant classification based on fit ratings, and SHACL derivation rules for disposition movement tracking with PROV-O provenance.

---

17. Platform Design Taxonomy (frameworks/platform-design/pd-tax.ttl)

Namespace: https://meta.linked.archi/vocab/platformdesign#

SKOS taxonomy for platform design concepts: stakeholder roles (consumer, producer, enabler, keystone), assets, capabilities, stories, needs, solutions, touchpoints, value, compensation, and channels.

---

18. Quality Attributes Extension (extensions/quality-attributes/quality-attributes.ttl)

Namespace: https://meta.linked.archi/quality-attributes# Version: 0.1.0 Imports: ad:arch-decision Authoritative sources: - ISO/IEC 25010:2023 — Systems and software quality models - SEI/CMU System Resilience — Quality attribute characterization - Bass, L., Clements, P. & Kazman, R. — "Software Architecture in Practice" (quality attribute scenarios)

Defines quality attribute individuals (instances of ad:QualityAttribute) for architecture decision evaluation. These are the "-ilities" that drive architecture decisions — each individual represents a named quality concern that can be linked to requirements, tactics, and decisions.

When to use: Import this extension alongside the Decisions extension when you need a controlled vocabulary of quality attributes for quality-driven design (ADD method), architecture evaluation (ATAM), or quality attribute scenario documentation.

Individuals: Evolvability, Safety, Cybersecurity, Anti-Tamper, Survivability, Capacity, Longevity, Interoperability, Adaptability, Availability, Maintainability, Performance, Reliability, Reparability

---

19. Tactics Extension (extensions/tactics/tactics.ttl)

Namespace: https://meta.linked.archi/tactics# (prefix: tac:) Version: 0.1.0 Imports: ad:arch-decision, refa:ref-arch Authoritative sources: - Bass, L., Clements, P. & Kazman, R. — "Software Architecture in Practice" (4th ed., Chapters 4–13) - SEI/CMU Tactics Catalog

Defines architectural tactics as class hierarchies under refa:Tactic, organized by quality attribute. Tactics are proven design decisions that influence a specific quality attribute response. Each tactic class is linked to its target quality attribute via ad:qualityAttributeMatch.

When to use: Import this extension alongside the Decisions and Quality Attributes extensions when you need to document which tactics were applied to achieve specific quality goals. Useful for ADD (Attribute-Driven Design), architecture evaluation, and pattern documentation.

Availability Tactics

• DetectFaults, RecoverFromFaults (PreparationAndRepair, Reintroduction), PreventFaults

Interoperability Tactics

• Locate, ManageInterfaces

Modifiability Tactics

• ReduceSizeOfAModule, IncreaseCohesion, ReduceCoupling, DeferBinding

Performance Tactics

• ControlResourceDemand, ManageResources

Security Tactics

• DetectAttacks, ResistAttacks, ReactToAttacks, RecoverFromAttacks

Each tactic class is linked to its target quality attribute via ad:qualityAttributeMatch.

---

20. Examples

Basic Metamodel (examples/basic/basic-onto.ttl)

Minimal metamodel demonstrating core patterns: Node, SpecialNode, GroupNode with association (punning), QualifiedAssociation, and aggregation relationships. Shows arch:domainIncludes/arch:rangeIncludes usage.

Component-and-Connector (examples/CnC/CnC.ttl)

Rich C&C vocabulary with Component, Connector hierarchies (MessagingConnector → PubSub/MessageQueue, RequestResponse → HTTPAPI/RPC/gRPC/SOAP, DataFlowConnector → Pipe/Batch/SharedData/DB/FileShare/FTP/GIT) and port/role relationships with directional specializations (inPort/outPort, subscribedTo/publishTo, enqueue/dequeue, etc.).

Simple Example (examples/simple-onto.ttl)

Simplest possible example: one Element subclass and one Relationship subclass.