Linked.Archi ArchiMate Ontology — Deep Dive¶

Detailed analysis of the ArchiMate ontology defined in modelingLanguages/archimate/, covering its architecture, element coverage, taxonomy structure, relationship modeling, SHACL shapes, derivation rules, and viewpoints.

1. Overview¶

Namespace: https://meta.linked.archi/archimate3/onto# (prefix: am) Current version: 3.2 Spec source: ArchiMate 3.2 Specification (The Open Group) Status: Draft Creator: Kalin Maldzhanski License: CC BY 4.0

The Linked.Archi ArchiMate ontology is an unofficial OWL representation of the ArchiMate modeling language. It imports the core ontology (arch:) and positions ArchiMate as one modeling language within the Linked.Archi ecosystem. The ontology is declared as both owl:Ontology and arch:Metamodel.

2. File Structure¶

The ArchiMate module is versioned by directory. The current version is 3.2.

Current (3.2)¶

File	Purpose
`archimate3.2-onto.ttl`	Element classes, abstract hierarchy, and 11 relationship types (three-declaration pattern)
`archimate3.2-tax.ttl`	SKOS taxonomy classifying elements by layer and aspect
`archimate3.2-metamodel.ttl`	Metamodel manifest aggregating all constituent resources
`archimate3.2-relationship-shapes.ttl`	Generated SHACL shapes for valid source/target pairs (from relationship matrix)
`archimate3.2-element-shapes.ttl`	SHACL shapes for structural integrity, layer direction, cross-layer constraints
`archimate3.2-principle-shapes.ttl`	SHACL shapes for architecture governance principles
`archimate3.2-derivation-rules.ttl`	DR1–DR8 (valid) + PDR1–PDR12 (potential) derivation rules as SHACL Rules
`archimate3.2-viewpoints.ttl`	ArchiMate example viewpoints with allowed concepts and stakeholder targeting
`archimate3.2-viewpoint-shapes.ttl`	SHACL shapes validating viewpoint conformance
`archimate3.2-reference-data.ttl`	Reference data (access types, influence strengths, etc.)
`archimate3.2-reference-models.ttl`	Reference model definitions
`archimate3.2-presentation-contexts.ttl`	Presentation context schemes for stakeholder-specific views
`archimate3.2-deliverable-templates.ttl`	Deliverable template definitions
`templates/`	Template content files

Versions¶

Directory	Version	Status	Notes
`3.0/`	3.0	Deprecated	Uses removed `arch:Relationship` class and `rdfs:label`; superseded by 3.2
`3.1/`	3.1	Superseded	Element ontology + taxonomy only; limited shapes
`3.2/`	3.2	Current	Full suite: ontology, shapes, derivation rules, viewpoints, metamodel manifest
`4.0/`	4.0	Draft	ArchiMate 4.0 ("Hexagonion"); domain-based structure replacing 3.x layers. See 3.2 vs 4.0 comparison.

Shared files¶

File	Purpose
`archimate-relationships-matrix.xml`	Source data for generating relationship shapes
`README.md`	Module overview and conventions
`suite-page.html`	Generated documentation index

3. Architecture and Class Hierarchy¶

3.1 Abstract Element Categories¶

The ontology defines an intermediate abstract class hierarchy that mirrors the ArchiMate framework's two-dimensional classification (Layer × Aspect):

By Aspect:

ArchimateElement
├── BehaviorElement
│   └── InternalBehaviorElement
├── StructureElement
│   ├── ActiveStructureElement
│   │   ├── InternalActiveStructureElement
│   │   └── ExternalActiveStructureElement
│   └── PassiveStructureElement
├── MotivationElement
├── CompositeElement
└── Event

By Layer:

ArchimateElement
├── StrategyLayerElement
├── BusinessLayerElement
├── ApplicationLayerElement
├── TechnologyLayerElement
├── PhysicalLayerElement
└── ImplementationAndMigrationLayerElement

Abstract classes and concrete elements all live in the am: namespace within archimate3.2-onto.ttl. See AM-DD-1 for the rationale.

3.2 Concrete Element Classes¶

Each concrete element has dual parentage: 1. Abstract classes from the aspect and layer classification 2. arch:Element from the core ontology

Example:

:BusinessActor
    a               owl:Class ;
    rdfs:subClassOf :InternalActiveStructureElement,
                    :BusinessLayerElement,
                    arch:Element ;
    skos:prefLabel  "BusinessActor"@en ;
    dc:source       <https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html> ;
    skos:definition '''A business actor is a business entity that is capable of
                    performing behavior.'''@en ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/v3/img/business_actor.svg" ;
.

3.3 Element Coverage¶

Category	Count	Examples
Motivation	10	Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint, Meaning, Value
Strategy	4	Resource, Capability, ValueStream, CourseOfAction
Business	13	BusinessActor, BusinessRole, BusinessProcess, BusinessService, Product, ...
Application	9	ApplicationComponent, ApplicationFunction, ApplicationService, DataObject, ...
Technology	13	Node, Device, SystemSoftware, TechnologyService, Artifact, ...
Physical	4	Equipment, Facility, DistributionNetwork, Material
Implementation & Migration	5	WorkPackage, Deliverable, ImplementationEvent, Plateau, Gap
Composite	2	Grouping, Location
Connectors	2	Junction_And, Junction_Or
Total	~62

4. Element Metadata Pattern¶

Each element carries rich metadata:

Property	Purpose	Example
`skos:prefLabel`	Human-readable name	`"BusinessActor"@en`
`skos:definition`	Formal definition from the spec	Full ArchiMate definition text
`skos:scopeNote`	Extended usage guidance from the spec	Detailed modeling guidance
`dc:source`	URL to the spec section	`<https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html>`
`arch:prefVisNotation`	SVG icon URL	`"https://meta.linked.archi/archimate3/v3/img/business_actor.svg"`

Definitions are not abbreviated summaries but full reproductions of the ArchiMate specification text, including scope notes with modeling guidance.

5. Taxonomy (`archimate3.2-tax.ttl`)¶

The taxonomy provides a SKOS concept scheme that classifies ArchiMate elements along two independent dimensions.

5.1 By Layer¶

ArchimateConcept
├── ArchimateElement
│   └── ArchimateElementByLayer
│       ├── StrategyLayer → Resource, Capability, ValueStream, CourseOfAction
│       ├── BusinessLayer → BusinessActor, BusinessRole, ... (13 elements)
│       ├── ApplicationLayer → ApplicationComponent, ... (9 elements)
│       ├── TechnologyLayer → Node, Device, ... (13 elements)
│       ├── PhysicalLayer → Equipment, Facility, DistributionNetwork, Material
│       └── ImplementationAndMigrationLayer → WorkPackage, Deliverable, ...
├── ArchimateRelationship
│   ├── StructuralRelationship → Realization, Assignment, Aggregation, Composition
│   ├── DependencyRelationship → Influence, Access, Serving
│   ├── DynamicRelationship → Triggering, Flow
│   └── OtherRelationship → Specialization, Association
└── ArchimateRelationshipConnector → Junction_And, Junction_Or

5.2 By Aspect¶

ArchimateElementByAspect
├── StructureElement
│   ├── ActiveStructureElement
│   │   ├── ExternalActiveStructureElement (interfaces)
│   │   └── InternalActiveStructureElement (actors, components)
│   └── PassiveStructureElement (objects, artifacts)
├── BehaviorElement
│   ├── ExternalBehaviorElement (services)
│   ├── InternalBehaviorElement (functions, processes)
│   └── Event (business/application/technology events)
├── MotivationElement → Stakeholder, Driver, Assessment, Goal, ...
└── CompositeElement → Product, Grouping, Location

5.3 SKOS vs OWL for Classification¶

The taxonomy uses SKOS skos:broader/skos:narrower rather than OWL class hierarchies. This is deliberate — see AM-DD-1 for the full rationale. In short: OWL classes define what things ARE (used by SHACL shapes), SKOS concepts define how things are PRESENTED (used by modeling tools).

6. Relationship Modeling¶

The 3.2 ontology declares all 11 ArchiMate relationship types using the three-declaration qualified relationship pattern (see DD-3 and Relationship Modeling Guide).

6.1 The 11 Relationship Types¶

Unqualified predicate	Qualified class	Qualified predicate	Category
`am:composedOf`	`am:Composition`	`am:qualifiedComposedOf`	Structural
`am:aggregates`	`am:Aggregation`	`am:qualifiedAggregates`	Structural
`am:assignedTo`	`am:Assignment`	`am:qualifiedAssignedTo`	Structural
`am:realizes`	`am:Realization`	`am:qualifiedRealizes`	Structural
`am:serves`	`am:Serving`	`am:qualifiedServes`	Dependency
`am:accesses`	`am:Access`	`am:qualifiedAccesses`	Dependency
`am:influences`	`am:Influence`	`am:qualifiedInfluences`	Dependency
`am:triggers`	`am:Triggering`	`am:qualifiedTriggers`	Dynamic
`am:flowsTo`	`am:Flow`	`am:qualifiedFlowsTo`	Dynamic
`am:specializes`	`am:Specialization`	`am:qualifiedSpecializes`	Other
`am:associatedWith`	`am:Association`	`am:qualifiedAssociatedWith`	Other

6.2 Example¶

Note: Relationship properties use arch:domainIncludes/arch:rangeIncludes (annotation properties) rather than rdfs:domain/rdfs:range (inference axioms). This provides tooling guidance without triggering unintended type inference. See the Domain & Range Guide for the full rationale.```turtle

1. Unqualified predicate¶

:serves a owl:ObjectProperty ; skos:prefLabel "Serves"@en ; arch:domainIncludes arch:Element ; arch:rangeIncludes arch:Element .

2. Qualified class¶

:Serving a owl:Class ; rdfs:subClassOf arch:QualifiedRelationship ; arch:unqualifiedForm :serves ; skos:prefLabel "Serving"@en .

3. Qualified predicate¶

:qualifiedServes a owl:ObjectProperty ; rdfs:range :Serving ; arch:unqualifiedForm :serves ; skos:prefLabel "qualified Serves"@en .

### 6.3 Relationship Attributes

Relationship types with attributes have dedicated properties:

- `am:accessType` — on `am:Access` instances (values: `read`, `write`, `readWrite`)
- `am:influenceStrength` — on `am:Influence` instances (values: `++`, `+`, `0`, `-`, `--`)

---

## 7. SHACL Shapes

The 3.2 suite includes three layers of SHACL validation:

### 7.1 Relationship Shapes (`archimate3.2-relationship-shapes.ttl`)

Generated from `archimate-relationships-matrix.xml` (the ArchiMate Appendix B matrix). Validates that relationship source/target pairs conform to the specification. Covers 10,484 valid pairs across the 11 relationship types.

### 7.2 Element Shapes (`archimate3.2-element-shapes.ttl`)

19 SPARQL-based shapes covering:
- Structural integrity (elements must have labels)
- Layer direction constraints
- Cross-layer relationship rules
- Junction homogeneity
- Metamodel pattern conformance (Figures 5/34/45/46/51/52/70/82/99/104–106 from the spec)

### 7.3 Principle Shapes (`archimate3.2-principle-shapes.ttl`)

20 shapes encoding architecture governance principles:
- Redundancy avoidance
- Single source of truth
- Stewardship
- Separation of concerns
- Service orientation
- Completeness
- Motivation alignment

Validate with: `.scripts/validate.sh --shacl archimate-principles`

---

## 8. Derivation Rules (`archimate3.2-derivation-rules.ttl`)

Implements all 20 ArchiMate derivation rules as SHACL Rules (`sh:SPARQLRule` with `sh:construct`):

- **DR1–DR8** — Valid derivation rules (derived relationships are always valid)
- **PDR1–PDR12** — Potential derivation rules (derived relationships may be valid depending on context)
- **Cross-domain restrictions** — SHACL validation shapes enforcing Section B.4 restrictions on derived relationships crossing domain boundaries

Derived relationships carry RDF 1.2 reification metadata: `:derivationCertainty` (`:Valid` or `:Potential`), `prov:wasGeneratedBy` (referencing named `prov:Activity` individuals for each rule), and `prov:wasDerivedFrom` (the source relationships).

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

---

## 9. Viewpoints (`archimate3.2-viewpoints.ttl`)

Defines ArchiMate example viewpoints as `arch:Viewpoint` individuals, derived from Chapter 9 of the spec. Each viewpoint specifies:

- Allowed element types (`arch:includesConcept`)
- Target stakeholders (`arch:targetsStakeholder`)
- Framed concerns (`arch:viewpointFramesConcern`)

A SKOS Concept Scheme provides a viewpoint catalog for tool navigation.

Viewpoint conformance is validated by `archimate3.2-viewpoint-shapes.ttl`.

---

## 10. Metamodel Manifest (`archimate3.2-metamodel.ttl`)

The metamodel manifest aggregates all constituent resources into a single entry point (see [DD-17](../design-decisions.md#dd-17-metamodel-as-manifest-separate-from-ontology)):

```turtle
ammm:ArchiMate3.2
    a                              arch:Metamodel ;
    arch:modelConcepts             <https://meta.linked.archi/archimate3/onto#> ;
    arch:formalRules               amsh:, amelsh:, ampsh: ;
    arch:derivationRules           amderiv: ;
    arch:architectureViewpoints    amvp: ;
    arch:conceptClassification     amtax:ArchiMateConceptScheme ;
    arch:hasDeliverableTemplate    ammm:ArchitectureDefinitionDocument ;
    arch:referenceData             ammm:ArchiMateReferenceData ;
    arch:referenceModels           ammm:ArchiMateReferenceModels ;
    arch:presentationContextScheme ammm:ArchiMatePresentationContexts .

11. Strengths¶

Rich element definitions — Full ArchiMate specification text as skos:definition and skos:scopeNote
Dual classification — OWL class hierarchy (abstract classes) and SKOS taxonomy provide complementary classification
Visual notation links — Every element has arch:prefVisNotation pointing to SVG icons
Spec traceability — dc:source links to specific ArchiMate specification sections
Core ontology integration — All elements are rdfs:subClassOf arch:Element, enabling cross-metamodel queries
Complete relationship modeling — 11 relationship types with three-declaration qualified pattern
Generated SHACL shapes — Relationship shapes generated from the Archi matrix XML
Element/metamodel shapes — 19 SPARQL-based shapes covering structural integrity and cross-layer constraints
Governance principle shapes — 20 shapes for architecture governance validation
Derivation rules — DR1–DR8 + PDR1–PDR12 implemented as SHACL Rules with PROV-O provenance
Viewpoints — Example viewpoints with allowed concepts, stakeholder targeting, and SHACL validation
Metamodel manifest — Single entry point aggregating all resources

12. Specialization / Profiles¶

ArchiMate supports user-defined specializations of element types. In Linked.Archi, this is handled directly via rdfs:subClassOf — the standard OWL/RDFS mechanism for specialization:

myorg:CloudApplicationComponent rdfs:subClassOf am:ApplicationComponent .

The subclass inherits all SHACL shapes, relationship validity rules, taxonomy membership, and visual notation from the parent. Organizations bundle their specializations into a custom metamodel that imports the ArchiMate one (see AM-DD-2 for the full rationale).