Ontology Reference¶

This document provides a detailed description of every ontology in the Linked.Archi semantic assets repository, including their classes, properties, design rationale, and relationships to other modules.

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 modeling, 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
`ModelConceptShape`	`arch:ModelConcept`	At least one `skos:prefLabel` required
`QualifiedRelationshipShape`	`arch:QualifiedRelationship`	Exactly one `arch:source` and one `arch:target`, both `arch:ModelConcept`
`ConceptOwnerShape`	`arch:ModelConcept`	`arch:conceptOwner` must be a `arch:Stakeholder`

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

Classes¶

Model Concepts (the modeling 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 modeling 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 modeling 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 modeling 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 modeling 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 behavior
`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:) Version: 0.2

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, colors, icons for palette generation).

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 modeling 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:

Determine the active PresentationContext (from user role/preference)
Follow arch:usesNotationSet → get the appropriate NotationSet
If no context-specific set, fall back to arch:notationSet on the Metamodel
Query all arch-vis:VisualNotation where arch-vis:inNotationSet = active set
For each, read arch-vis:notationFor → the OWL class
Read arch-vis:defaultStyle → get shape, color, icon, dimensions
Group by taxonomy (domain/aspect from the SKOS taxonomy)
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 modeling 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 modeling 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/decisions/archDecision.ttl`)¶

Namespace: https://meta.linked.archi/arch-decision# (prefix: ad:) Version: 0.0.5 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:QualityAttribute`	`owl:Class`	Software quality characteristic

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

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`)¶

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 for modeling architecture governance processes, activities, tasks, and their inputs/outputs as first-class architecture model elements. All classes subclass arch:Element, making them usable in architecture views and governed by metamodels.

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

When to use: Import this extension when your metamodel needs to capture the architecture governance process — 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`	`arch:Element`	A process within the architecture governance or lifecycle framework
`ap:ProcessActivity`	`arch:Element`	A cohesive set of tasks within a process
`ap:ProcessTask`	`arch:Element`	A specific action or work item within an activity
`ap:ProcessDeliverable`	`arch:Element`	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`	`arch:Element`	A significant checkpoint or gate in a process
`ap:ProcessRole`	`arch:Stakeholder`	A role that a stakeholder plays within a process

Key Properties¶

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

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 modeling 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 — lifecycle states, environment types, criticality levels
`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 license) 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.2.0 Imports: arch:core License: CC BY 4.0

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

Files¶

File	Content
`backstage-onto.ttl`	Elements + relationships (three-declaration pattern)
`backstage-metamodel.ttl`	Metamodel manifest — ties together all Backstage resources
`backstage-shapes.ttl`	SHACL shapes — per-relationship-type constraints (imports `core-shapes`)
`backstage-tax.ttl`	SKOS taxonomy — software entities vs organizational entities
`backstage-viewpoints.ttl`	5 viewpoints (ServiceCatalog, SystemDependency, OwnershipMatrix, APIDependency, DomainOverview)
`backstage-deliverable-templates.ttl`	Deliverable templates — Service Catalog Document, System Architecture Document
`backstage-reference-data.ttl`	Reference data — component lifecycle, component type, API type
`backstage-presentation-contexts.ttl`	Presentation contexts — Developer, Platform Engineer, Engineering Manager

Classes¶

Class	Parent	Description
`bs:Component`	`arch:Element`	Deployable unit, service, library, or application
`bs:System`	`arch:Element`	Set of components providing business/technical value
`bs:API`	`arch:Element`	An API in the ecosystem
`bs:Resource`	`arch:Element`	Resource used by components (database, bucket, etc.)
`bs:Domain`	`arch:Element`	High-level business domain grouping
`bs:User`	`arch:Element`	Human user
`bs:Group`	`arch:Element`	Group of users (team, department)

Relationship Types (7 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`
Resource Usage	`bs:usesResource`	`bs:ResourceUsage`
Domain Membership	`bs:belongsToDomain`	`bs:DomainMembership`
Group Membership	`bs:memberOf`	`bs:GroupMembership`

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 catalog
`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 + 9 relationship types (three-declaration pattern)
`leanIX-metamodel.ttl`	0.1.0	Metamodel manifest — ties together LeanIX resources
`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-v3-onto.ttl`	3	Prior version — v3 fact sheet types, elements only

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 (9 types, three declarations each)¶

Type	Unqualified Predicate	Qualified Class
Supporting	`lmm:supports`	`lmm:Supporting`
Requiring	`lmm:requires`	`lmm:Requiring`
Interface Ownership	`lmm:hasInterface`	`lmm:InterfaceOwnership`
Data Usage	`lmm:usesData`	`lmm:DataUsage`
Impact	`lmm:impacts`	`lmm:Impact`
Driving	`lmm:drives`	`lmm:Driving`
Organizational Usage	`lmm:usedByOrg`	`lmm:OrganizationalUsage`
Provision	`lmm:providedBy`	`lmm:Provision`
Categorization	`lmm:categorizedBy`	`lmm:Categorization`

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-alignment.ttl`	Alignment axioms mapping BPMN classes to `arch:Element` / `arch:QualifiedRelationship`
`linkedarchi-bpmn-suite-imports.ttl`	Import aggregator
`linkedarchi-bpmn-suite-shapes.ttl`	Combined shapes aggregator

Alignment to Core¶

The alignment file maps BPMN semantic classes to the core ontology: - bpmn:BaseElement rdfs:subClassOf arch:Element - 12 BPMN relationship classes (Association, SequenceFlow, MessageFlow, DataAssociation, etc.) → rdfs:subClassOf arch:QualifiedRelationship

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 modeling 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:) Version: 0.1.1 Imports: arch:core

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

Files — Three-Layer Architecture¶

The TIME framework uses three complementary layers, each serving a different purpose:

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
`time-tax.ttl`	`time-framework/tax#`	SKOS (navigation)	6 ConceptSchemes organizing enumeration individuals for UI dropdowns, documentation, and faceted search
`time-metamodel.ttl`	`time-framework/metamodel#`	Manifest	Ties together onto, shapes, and tax into a single discoverable resource

Why three layers? Each answers a different question: - OWL answers: "This assessment has High/High ratings → it is an InvestAssessment" (inference) - SHACL answers: "This assessment is missing a timeDisposition → validation error" (constraint) - 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. Warning: should have rationale.
`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).
`timefw:FitCriterionScore`	Scored evaluation of a criterion
`timefw:TimeAssessmentModel`	Scoring model with thresholds

Controlled Vocabularies¶

timefw:TimeDisposition — Tolerate, Invest, Migrate, Eliminate
timefw:FitRating — High, Low
timefw:FitDimension — Functional, Technical, Cost

Includes optional OWL class expressions for automatic TIME quadrant classification based on fit ratings.

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.).

Fortis Bank (`examples/fortis/fortis-onto.ttl`)¶

Banking domain example extending ArchiMate with organization-specific concepts: Asset, ApplicationGroup, ApplicationCode, Application, DistributedApplication, ApplicationInstallation. Demonstrates how to specialize ArchiMate elements for a specific enterprise context.

Simple Example (`examples/simple-onto.ttl`)¶

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

Ontology Reference¶

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

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

Classes¶

Model Concepts (the modeling palette)¶

Architecture Description Concepts¶

Stakeholder and Concern Concepts¶

Quality and Governance¶

Key Properties¶

Relationship Properties¶

Structural Properties¶

Governance Properties¶

Quality Measurement Properties¶

Metamodel Composition Properties¶

Presentation Properties¶

Deliverable Template Properties¶

Annotation Properties¶

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

Purpose Individuals¶

Concern Individuals (10)¶

Viewpoints (12)¶

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

Presentation Formats¶

Deliverable Templates¶

Usage Pattern¶

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

Classes¶

Properties¶

Visual Notation Flow¶

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

Top-Level Concepts¶

Extensions Overview¶

6. Architecture Decision Ontology (extensions/decisions/archDecision.ttl)¶

Classes¶

Key Properties¶

Design Rationale¶

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

Classes¶

Key Properties¶

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

Classes¶

Design Rationale¶

9. ArchiMate Ontology (modelingLanguages/archimate/)¶

Files¶

Element Classes (62 elements across layers)¶

Relationship Types (11 types, three declarations each)¶

Taxonomy Organization¶

SHACL Validation¶

Derivation Rules¶

10. Backstage Ontology (modelingLanguages/backstage/)¶

Files¶

Classes¶

Relationship Types (7 types, three declarations each)¶

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

Files¶

Classes¶

Relationship Types (4 types, three declarations each)¶

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

Files¶

v4 Fact Sheet Types¶

v4 Relationship Types (9 types, three declarations each)¶

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

Files¶

Concept Scheme¶

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

Files¶

Alignment to Core¶

12. TOGAF 9.2 (frameworks/togaf/)¶

Content Metamodel (togaf.ttl)¶

ADM Phases (TOGAF_9.2-ADM.ttl)¶

Viewpoints (togaf-vp.ttl)¶

13. DoDAF 2.02 (frameworks/dodaf/)¶

Files¶

Viewpoints (8 categories, 52 models)¶

Data and Information Viewpoint (DIV)¶

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

Interrogatives (Columns)¶

Perspectives (Rows)¶

15. ADMIT Framework (frameworks/admit/)¶

Files¶

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

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

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

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

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

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

6. Architecture Decision Ontology (`extensions/decisions/archDecision.ttl`)¶

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

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

9. ArchiMate Ontology (`modelingLanguages/archimate/`)¶

10. Backstage Ontology (`modelingLanguages/backstage/`)¶

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

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

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

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

12. TOGAF 9.2 (`frameworks/togaf/`)¶

Content Metamodel (`togaf.ttl`)¶

ADM Phases (`TOGAF_9.2-ADM.ttl`)¶

Viewpoints (`togaf-vp.ttl`)¶

13. DoDAF 2.02 (`frameworks/dodaf/`)¶

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

15. ADMIT Framework (`frameworks/admit/`)¶

16. TIME Framework (`frameworks/TIME/`)¶

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

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

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

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

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

Fortis Bank (`examples/fortis/fortis-onto.ttl`)¶

Simple Example (`examples/simple-onto.ttl`)¶