ArchiMate 3.2 Primer & Modelling Guide — Enterprise Architecture with Linked.Archi¶

This guide walks through ArchiMate 3.2 as formalised in Linked.Archi: read the language, author a model, validate it, derive new facts from it, present it to different audiences, tailor it to your organisation, and link it to other notations.

It is both breadth-complete and self-contained: every capability is demonstrated here with enough depth to be actionable, using a single worked example (NordFreight Logistics) and a single mental map (the metamodel manifest).

Orientation¶

What ArchiMate 3.2 is¶

ArchiMate is an open enterprise architecture modeling language published by The Open Group. Version 3.2 organises the language along two orthogonal dimensions — aspect (what kind of thing it is) and layer (where it belongs):

Seven layers. Strategy, Business, Application, Technology, Physical, and Implementation & Migration — plus the cross-cutting Motivation aspect.
Per-layer behaviour. Each layer has its own element types: BusinessProcess, ApplicationProcess, TechnologyProcess; likewise for Function, Service, Event, Interaction.
Physical layer. Equipment, Facility, Distribution Network, and Material model the physical estate.
Implementation & Migration elements. Work Package, Deliverable, Implementation Event, Plateau, and Gap track architecture change.
Junctions. Junction_And and Junction_Or connectors combine relationships into logical groups.

Official specification: https://pubs.opengroup.org/architecture/archimate3-doc/

What Linked.Archi adds¶

In Linked.Archi, ArchiMate 3.2 is not a diagramming convention — it is a formally defined modeling language whose definition is a queryable knowledge graph. The language is published as a set of W3C-standard semantic assets, tied together by a single manifest. Each W3C standard plays one role, with no overlap:

OWL defines what the concepts mean — the element and relationship vocabulary and its hierarchy.
SHACL defines what a conforming model must satisfy — closed-world validation rules.
SKOS defines how concepts are classified and navigated — the taxonomies behind palettes, filters, and views.
SPARQL is how you query and traverse the model.

This is what turns "boxes and arrows" into something a machine can validate, reason over, and generate documents from.

Namespace: https://meta.linked.archi/archimate3/onto# (prefix: am) Current version: 3.2 Status: Draft License: CC BY 4.0

The manifest is your map¶

A Linked.Archi metamodel (arch:Metamodel) is a manifest — a single resource that aggregates all the assets making up the language. The ArchiMate 3.2 manifest lives at https://meta.linked.archi/archimate3/metamodel#ArchiMate3.2 and ties together the resources below. Keep this picture in mind; every section of this guide "lights up" one node of it.

The manifest aggregates all semantic assets making up the language definition. Browse the live manifest ▶

am3mm: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     <https://meta.linked.archi/archimate3/tax#> ;
    arch:hasDeliverableTemplate    am3mm:ArchitectureDefinitionDocument ;
    arch:referenceData             am3mm:ArchiMateReferenceData ;
    arch:referenceModels           am3mm:ArchiMateReferenceModels ;
    arch:presentationContextScheme am3mm:ArchiMatePresentationContexts .

You can browse the live manifest at https://meta.linked.archi/archimate3/metamodel/.

File structure¶

The ArchiMate module is versioned by directory. The current version is 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

Prerequisites¶

To author and validate a model, load the assets in this order (foundation first):

core/core-onto.ttl                                       # shared foundation (arch:*)
modelingLanguages/archimate/3.2/archimate3.2-onto.ttl    # elements + relationships
modelingLanguages/archimate/3.2/archimate3.2-tax.ttl     # SKOS taxonomy
modelingLanguages/archimate/3.2/archimate3.2-element-shapes.ttl
modelingLanguages/archimate/3.2/archimate3.2-relationship-shapes.ttl
modelingLanguages/archimate/3.2/archimate3.2-viewpoints.ttl
modelingLanguages/archimate/3.2/archimate3.2-metamodel.ttl  # the manifest (entry point)

Throughout, these prefixes are assumed:

@prefix owl:     <http://www.w3.org/2002/07/owl#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix sh:      <http://www.w3.org/ns/shacl#> .
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix arch:    <https://meta.linked.archi/core#> .
@prefix am:      <https://meta.linked.archi/archimate3/onto#> .
@prefix amtax:   <https://meta.linked.archi/archimate3/tax#> .
@prefix amvp:    <https://meta.linked.archi/archimate3/viewpoints#> .
@prefix amrd:    <https://meta.linked.archi/archimate3/reference-data#> .

Part 1 — The Language¶

ArchiMate 3.2 classifies every element along two orthogonal dimensions: by aspect (what kind of thing it is) and by layer (where it belongs). In Linked.Archi both dimensions are real, queryable structures — they are the tax SKOS concept scheme.

By aspect — what kind of thing¶

The six aspect dimensions of ArchiMate 3.2.

Aspect	What it represents	Examples
Behaviour	Dynamic aspects — what happens	Process, Function, Interaction, Service (per layer)
Active Structure	Entities that perform behaviour	Actor, Role, Component, Node, Device
Passive Structure	Objects acted upon	Business Object, Data Object, Artifact, Material
Motivation	Why things happen	Stakeholder, Driver, Goal, Requirement, Constraint, Principle
Composite	Combinations of aspects	Grouping, Location, Product
Event	Things that happen at a moment	Business Event, Application Event, Technology Event

By layer — where it belongs¶

Layer	Scope	Key elements
Strategy	Strategic planning	Resource, Capability, Value Stream, Course of Action
Business	Business-specific	Business Actor, Role, Process, Function, Service, Event, Object, Contract, Representation, Product
Application	Software systems	Application Component, Function, Service, Interaction, Event, Data Object
Technology	Infrastructure	Node, Device, System Software, Communication Network, Path, Function, Process, Service, Artifact
Physical	Physical estate	Equipment, Facility, Distribution Network, Material
Motivation	Why architecture exists	Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint, Meaning, Value
Implementation & Migration	Change management	Work Package, Deliverable, Implementation Event, Plateau, Gap

The bridge — these dimensions are an asset. Both dimensions are published as one SKOS concept scheme (tax). Each element is classified twice — once under a layer, once under an aspect — so a single SPARQL query can ask "every Behaviour element" or "every Technology-layer element" without enumerating types by hand:

amtax:ArchiMate3ConceptScheme a skos:ConceptScheme ;
    skos:prefLabel "ArchiMate 3.2 Concept Scheme"@en ;
    skos:hasTopConcept amtax:StrategyLayer , amtax:BusinessLayer , amtax:ApplicationLayer ,
                       amtax:TechnologyLayer , amtax:PhysicalLayer ,
                       amtax:ImplementationMigrationLayer ,
                       amtax:BehaviorElement , amtax:ActiveStructureElement ,
                       amtax:PassiveStructureElement , amtax:MotivationElement ,
                       amtax:CompositeElement .

# "BusinessProcess" is classified on BOTH axes:
amtax:BusinessProcess a skos:Concept ;
    skos:prefLabel "Business Process"@en ;
    skos:broader amtax:BusinessLayer , amtax:InternalBehaviorElement ;
    rdfs:seeAlso am:BusinessProcess .       # links the SKOS concept to the OWL class (no punning)

Note the rdfs:seeAlso bridge: the SKOS concept and the OWL class are kept as separate resources (Linked.Archi never puns an IRI as both). The class carries logical semantics for reasoners and shapes; the concept carries navigation for palettes and filters.

Element coverage (~62 types)¶

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

Elements by layer — OWL declarations¶

Each concrete element has dual parentage: abstract classes from the aspect and layer classification, plus arch:Element from the core ontology. Below, one representative OWL declaration per layer shows the pattern.

Motivation¶

Element	Notation
Stakeholder
Driver
Assessment
Goal
Outcome
Principle
Requirement
Constraint
Meaning
Value

am:Requirement a owl:Class ;
    rdfs:subClassOf am:MotivationElement , arch:Element ;
    skos:prefLabel "Requirement"@en ;
    skos:definition "A statement of need that must be realized by a system."@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap06.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/requirement.svg" .

Strategy¶

Element	Notation	Aspect
Resource		Passive Structure
Capability		Behaviour
Value Stream		Behaviour
Course of Action		Behaviour

am:Capability a owl:Class ;
    rdfs:subClassOf am:StrategyLayerElement , am:InternalBehaviorElement , arch:Element ;
    skos:prefLabel "Capability"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap07.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/capability.svg" .

Business¶

Element	Notation	Aspect
Business Actor		Active Structure
Business Role		Active Structure
Business Process		Behaviour
Business Function		Behaviour
Business Service		Behaviour
Business Object		Passive Structure
Product		Composite

am:BusinessProcess a owl:Class ;
    rdfs:subClassOf am:BusinessLayerElement , am:InternalBehaviorElement , arch:Element ;
    skos:prefLabel "BusinessProcess"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/business-process.svg" .

Application¶

Element	Notation	Aspect
Application Component		Active Structure
Application Function		Behaviour
Application Service		Behaviour
Data Object		Passive Structure

am:ApplicationComponent a owl:Class ;
    rdfs:subClassOf am:ApplicationLayerElement , am:InternalActiveStructureElement , arch:Element ;
    skos:prefLabel "ApplicationComponent"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap09.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/application-component.svg" .

Technology¶

Element	Notation	Aspect
Node		Active Structure
Device		Active Structure
System Software		Active Structure
Artifact		Passive Structure

am:Node a owl:Class ;
    rdfs:subClassOf am:TechnologyLayerElement , am:InternalActiveStructureElement , arch:Element ;
    skos:prefLabel "Node"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap10.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/node.svg" .

Physical¶

Element	Notation	Aspect
Equipment		Active Structure
Facility		Active Structure
Distribution Network		Active Structure
Material		Passive Structure

am:Facility a owl:Class ;
    rdfs:subClassOf am:PhysicalLayerElement , am:InternalActiveStructureElement , arch:Element ;
    skos:prefLabel "Facility"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap11.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/facility.svg" .

Implementation & Migration¶

Element	Notation	Aspect
Work Package		Behaviour
Deliverable		Passive Structure
Implementation Event		Event
Plateau		Composite
Gap		Composite

am:WorkPackage a owl:Class ;
    rdfs:subClassOf am:ImplementationAndMigrationLayerElement , am:InternalBehaviorElement , arch:Element ;
    skos:prefLabel "WorkPackage"@en ;
    dcterms:source <https://pubs.opengroup.org/architecture/archimate3-doc/chap12.html> ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/icons/work-package.svg" .

Abstract vs concrete classes¶

The two hierarchies are anchored by abstract classes — never instantiated directly. They exist so that queries, shapes, and tool palettes can generalise. Because rdfs:subClassOf carries monotonic inference, anything typed as am:BusinessProcess is automatically an am:InternalBehaviorElement, an am:BusinessLayerElement, and an arch:Element — without you asserting it.

Abstract (by aspect)	Abstract (by layer)	Concrete examples
`BehaviorElement`	`StrategyLayerElement`	Capability, Value Stream, Course of Action
`InternalBehaviorElement`	`BusinessLayerElement`	Business Process, Business Function
`ActiveStructureElement`	`ApplicationLayerElement`	Application Component, Application Interface
`InternalActiveStructureElement`	`TechnologyLayerElement`	Node, Device, System Software
`ExternalActiveStructureElement`	`PhysicalLayerElement`	Equipment, Facility
`PassiveStructureElement`	`ImplementationAndMigrationLayerElement`	Work Package, Deliverable
`MotivationElement`		Stakeholder, Driver, Goal, Constraint
`CompositeElement`		Grouping, Location, Product
`Event`		Business/Application/Technology/Implementation Event

Relationships (11 types)¶

Eleven relationship types organised by category.

Category	Relationship	Meaning
Structural	Composition	Element consists of other elements
Structural	Aggregation	Element combines other elements
Structural	Assignment	Active structure performs behaviour
Structural	Realization	Element realizes another
Dependency	Serving	Element provides functionality to another
Dependency	Access	Behaviour accesses passive structure
Dependency	Influence	Element influences another (motivation)
Dynamic	Triggering	Element triggers another
Dynamic	Flow	Transfer of content between elements
Other	Specialization	Element is a specialization of another
Other	Association	Unspecified relationship

The three-declaration relationship pattern¶

Every relationship type has three representations, because enterprise architecture needs both cheap graph traversal and rich relationship management. Using Serving as the example:

## 1. Direct predicate — for fast SPARQL traversal and analytics
am:serves a owl:ObjectProperty ;
    skos:prefLabel "Serves"@en ;
    arch:domainIncludes arch:Element ;          # tooling hint, not a constraint
    arch:rangeIncludes  arch:Element .

## 2. Qualified relationship class — a reified resource carrying metadata, lifecycle, provenance
am:Serving a owl:Class ;
    rdfs:subClassOf arch:QualifiedRelationship ;
    arch:unqualifiedForm am:serves ;
    skos:prefLabel "Serving"@en .

## 3. Qualified property — navigates from a source to its qualified resource
am:qualifiedServes a owl:ObjectProperty ;
    rdfs:range am:Serving ;
    arch:unqualifiedForm am:serves .

Why three? The direct predicate (am:serves) answers "what serves what?" in one cheap triple pattern. But suppose the same component serves the same process in two different ways, each with its own lifecycle state and owner — a bare predicate cannot tell those edges apart. The qualified am:Serving resource can, because it is a thing in its own right with arch:source, arch:target, and any metadata you attach.

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

Two relationship types carry typed attributes drawn from reference-data and only exist on the qualified form:

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

Rule of thumb: write the direct predicate by default. Promote an edge to a qualified resource only when you need to say something about the relationship itself (provenance, lifecycle, multiple distinct edges, access type, influence strength). The full rationale is in the Relationship Modeling Guide.

The 11 relationship types — full summary¶

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

Part 2 — Authoring a Model¶

Everything from here on uses one running example, NordFreight Logistics — a Scandinavian freight company modernising its shipment-tracking platform and integrating with EU customs systems for post-Brexit trade compliance.

Model header¶

A model is an arch:Model that declares which metamodel it conforms to:

@prefix : <https://model.nordfreight.example/> .

:NordFreightModel
    a                             arch:Model ;
    skos:prefLabel                "NordFreight Logistics — Architecture Model (3.2)"@en ;
    arch:modelConformsToMetamodel <https://meta.linked.archi/archimate3/metamodel#ArchiMate3.2> ;
    dcterms:created               "2025-06-27"^^xsd:date .

Element patterns¶

Each element needs only rdf:type and a language-tagged skos:prefLabel to be valid. Grouped by layer:

## Motivation
:EUCustomsCompliance a am:Requirement ; skos:prefLabel "EU Customs Compliance"@en .
:NoDataOutsideEU a am:Constraint ; skos:prefLabel "No personal data outside EU"@en .
:OperationalEfficiency a am:Goal ; skos:prefLabel "Operational Efficiency"@en .
:ShipperStakeholder a am:Stakeholder ; skos:prefLabel "Shipper"@en .

## Strategy
:ShipmentTracking a am:Capability ; skos:prefLabel "Shipment Tracking"@en .
:FreightBooking a am:Capability ; skos:prefLabel "Freight Booking"@en .
:CustomsClearance a am:Capability ; skos:prefLabel "Customs Clearance"@en .

## Business
:BookingProcess a am:BusinessProcess ; skos:prefLabel "Booking Process"@en .
:TrackingService a am:BusinessService ; skos:prefLabel "Shipment Tracking Service"@en .
:FreightOperations a am:BusinessRole ; skos:prefLabel "Freight Operations"@en .
:Shipment a am:BusinessObject ; skos:prefLabel "Shipment"@en .

## Application — Functions (behaviour performed by components)
:BookingFunction a am:ApplicationFunction ; skos:prefLabel "Booking Function"@en .
:TrackingFunction a am:ApplicationFunction ; skos:prefLabel "Tracking Function"@en .
:CustomsFunction a am:ApplicationFunction ; skos:prefLabel "Customs Processing"@en .

## Application — Services (exposed to consumers)
:BookingAppService a am:ApplicationService ; skos:prefLabel "Booking Service"@en .

## Application — Components (active structure)
:TMS a am:ApplicationComponent ; skos:prefLabel "Transport Management System"@en .
:TrackingPortal a am:ApplicationComponent ; skos:prefLabel "Tracking Portal"@en .
:CustomsGateway a am:ApplicationComponent ; skos:prefLabel "Customs Gateway"@en .
:ShipmentData a am:DataObject ; skos:prefLabel "Shipment Data"@en .

## Technology
:AzureCloud a am:Node ; skos:prefLabel "Azure North Europe"@en .
:K8sCluster a am:SystemSoftware ; skos:prefLabel "AKS Kubernetes Cluster"@en .
:IoTGateway a am:Device ; skos:prefLabel "IoT Tracking Gateway"@en .

## Physical
:NordicHub a am:Facility ; skos:prefLabel "Oslo Logistics Hub"@en .
:TruckFleet a am:Equipment ; skos:prefLabel "Truck Fleet"@en .
:RoadNetwork a am:DistributionNetwork ; skos:prefLabel "Nordic Road Network"@en .

## Implementation & Migration
:PlatformModernisation a am:WorkPackage ; skos:prefLabel "Platform Modernisation"@en .
:TargetState a am:Plateau ; skos:prefLabel "Target Architecture 2027"@en .
:GoLive a am:ImplementationEvent ; skos:prefLabel "Platform Go-Live"@en .
:TrackingGap a am:Gap ; skos:prefLabel "Real-time Tracking Gap"@en .

Relationship patterns¶

Direct predicates for the bulk of the model:

## Assignment — active structure performs behaviour
:FreightOperations am:assignedTo :BookingProcess .

## Application layer — the proper Component → Function → Service → Consumer pattern
:TMS               am:assignedTo :BookingFunction .      # component performs function
:BookingFunction   am:realizes   :BookingAppService .    # function provides service
:BookingAppService am:serves     :FreightOperations .    # service serves the role

:TrackingPortal    am:assignedTo :TrackingFunction .
:TrackingFunction  am:realizes   :TrackingService .
:TrackingService   am:serves     :FreightOperations .

:CustomsGateway    am:assignedTo :CustomsFunction .      # component performs function
:CustomsFunction   am:realizes   :CustomsClearance .     # function realizes capability directly

## Realization — process/service realizes capability
:BookingProcess    am:realizes :FreightBooking .
:TrackingService   am:realizes :ShipmentTracking .

## Serving — technology layer (valid: infra serves component)
:K8sCluster       am:serves :TMS .
:AzureCloud       am:serves :K8sCluster .

## Access
:BookingProcess am:accesses :Shipment .
:TMS            am:accesses :ShipmentData .

## Structural + dynamic
:AzureCloud           am:composedOf :K8sCluster .
:NordicHub            am:composedOf :TruckFleet .
:TMS                  am:flowsTo    :CustomsGateway .
:BookingProcess       am:triggers   :TrackingService .
:GoLive               am:triggers   :TargetState .
:CustomsGateway  am:realizes :EUCustomsCompliance .
:TMS      am:realizes :NoDataOutsideEU .
:PlatformModernisation am:aggregates :TargetState .
:TrackingGap          am:associatedWith :PlatformModernisation .

Read one fragment three ways¶

Here is the Customs Gateway corner of the model — as a diagram, as direct predicates, and as a qualified resource:

The Customs Gateway corner — component realizes requirement, component assigned to function, function realizes capability, flow from TMS. View source model · Try it out ▶

# Direct predicates (the diagram, literally)
:CustomsGateway am:realizes :EUCustomsCompliance .
:CustomsGateway      am:assignedTo :CustomsFunction .
:CustomsFunction     am:realizes   :CustomsClearance .
:TMS                 am:flowsTo    :CustomsGateway .

# The assignment promoted to a managed resource, because we want to record why and since when
:cg-assigned-customs-fn a am:Assignment ;
    arch:source :CustomsGateway ;
    arch:target :CustomsFunction ;
    arch:lifecycleState "planned" ;
    dcterms:created "2025-06-27"^^xsd:date ;
    rdf:reifies <<( :CustomsGateway am:assignedTo :CustomsFunction )>> .

A cross-layer view¶

A cross-layer architecture view spanning motivation, strategy, business, application, and technology. View source model · Try it out ▶

This view conforms to the Layered Viewpoint — we will make that conformance checkable in Part 5.

Part 3 — Validating the Model¶

ArchiMate semantics that constrain a model live in SHACL, not OWL. This is deliberate: OWL works under the open-world assumption (a missing fact is merely unknown), whereas governance needs the closed-world opposite — "every Application Component must have an owner" should be a checkable rule whose violation is an error, not an invitation to infer a missing owner. The manifest publishes four shape families, each answering a different question.

3.1 Element validation (`element-shapes`)¶

Are the elements well-formed? 19 SPARQL-based shapes covering structural integrity (elements must have labels), layer direction constraints, cross-layer relationship rules, junction homogeneity, and metamodel pattern conformance. The simplest shape:

am:ElementShape a sh:NodeShape ;
    sh:targetClass arch:Element ;
    sh:property [
        sh:path skos:prefLabel ;
        sh:minCount 1 ;
        sh:datatype rdf:langString ;
        sh:message "Every element must have at least one language-tagged skos:prefLabel."@en ;
    ] .

Passing: :TMS a am:ApplicationComponent ; skos:prefLabel "Transport Management System"@en .

Failing, and the report it produces:

# Offending data
:Orphan a am:ApplicationComponent .     # no prefLabel

# sh:ValidationReport
[ a sh:ValidationResult ;
  sh:focusNode      :Orphan ;
  sh:resultPath     skos:prefLabel ;
  sh:sourceShape    am:ElementShape ;
  sh:resultSeverity sh:Violation ;
  sh:resultMessage  "Every element must have at least one language-tagged skos:prefLabel."@en ] .

3.2 Relationship-validity validation (`relationship-shapes`)¶

Is this edge legal? ArchiMate's relationship rules state which element types may connect via which relationship — the validity matrix in Appendix B of the specification. Linked.Archi generates SHACL from that matrix (via archimate-relationships-matrix.xml), covering 10,484 valid pairs across the 11 relationship types. For example, Assignment runs from an active-structure element to a behaviour element:

am:AssignmentValidityShape a sh:NodeShape ;
    sh:targetSubjectsOf am:assignedTo ;
    sh:class am:ActiveStructureElement ;
    sh:property [
        sh:path am:assignedTo ;
        sh:class am:BehaviorElement ;
        sh:message "Assignment must run from an Active Structure element to a Behavior element."@en ;
    ] .

:FreightOperations am:assignedTo :BookingProcess passes (BusinessRole → BusinessProcess). The following fails, because a Data Object is passive structure, not behaviour:

:ShipmentData am:assignedTo :BookingProcess .   # ✗ source is passive structure
# → sh:ValidationResult: "Assignment must run from an Active Structure element to a Behavior element."

3.3 Principle validation (`principle-shapes`)¶

Does the model satisfy our governance rules? This is where SHACL becomes architecture compliance as code — rules you run in CI/CD on every commit, not in a quarterly review. 20 shapes encoding governance principles: redundancy avoidance, single source of truth, stewardship, separation of concerns, service orientation, completeness, and motivation alignment.

A completeness principle — every Capability must be realized by at least one core element:

am:CapabilityRealizationPrinciple a sh:NodeShape ;
    sh:targetClass am:Capability ;
    sh:sparql [
        sh:message "Every Capability must be realized by at least one Business Process or Application Service."@en ;
        sh:select """
            SELECT $this WHERE {
                FILTER NOT EXISTS { ?x am:realizes $this }
            }
        """ ;
    ] .

Against NordFreight as authored, :FreightBooking passes (:BookingProcess am:realizes :FreightBooking); a capability with no realizing element is flagged.

3.4 Viewpoint conformance (`viewpoint-shapes`)¶

Does this view show only what its viewpoint allows? A arch:View that declares conformance to a viewpoint can be checked against the element types that viewpoint permits — data-driven, reading the viewpoint definition from the graph. (See Part 5 for the viewpoint definitions this checks against.)

Running it¶

.scripts/validate.sh --shacl nordfreight-3.2-model.ttl \
    core/core-shapes.ttl \
    modelingLanguages/archimate/3.2/archimate3.2-element-shapes.ttl \
    modelingLanguages/archimate/3.2/archimate3.2-relationship-shapes.ttl \
    modelingLanguages/archimate/3.2/archimate3.2-principle-shapes.ttl

You now understand every file passed to it: element well-formedness, relationship legality, and governance principles, in one pass.

Part 4 — Deriving and Inferring New Facts¶

A model states some relationships explicitly; many more are implied. ArchiMate's derivation rules say that a valid chain of relationships permits a derived relationship between its endpoints. In Linked.Archi these are sh:SPARQLRules, and every derived fact is annotated with provenance (PROV-O) and a certainty — valid (DR1–DR8: derived relationship is always valid) or potential (PDR1–PDR12: may be valid depending on context) — so inferred knowledge never silently masquerades as asserted knowledge.

Derivation rule inventory¶

ID	Type	Chain pattern	Derived relationship
DR1–DR8	Valid	Asserted chains guaranteed to produce valid edges	Realization, Serving, Assignment, etc.
PDR1–PDR12	Potential	Chains that may produce valid edges depending on context	Various — require human review

One derivation rule¶

If an Application Component is assigned to an Application Function, and that function realizes a service, then the component realizes the service:

am:DR-AssignRealize a sh:NodeShape ;
    sh:rule [
        a sh:SPARQLRule ;
        sh:construct """
            PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
            PREFIX arch: <https://meta.linked.archi/core#>
            PREFIX prov: <http://www.w3.org/ns/prov#>
            CONSTRUCT {
                ?comp am:realizes ?svc .
                ?d a am:Realization ;
                   arch:source ?comp ; arch:target ?svc ;
                   am:derivationCertainty am:Valid ;
                   prov:wasGeneratedBy am:DR-AssignRealize ;
                   prov:wasDerivedFrom ?fn .
            }
            WHERE {
                ?comp am:assignedTo ?fn .
                ?fn   am:realizes    ?svc .
                BIND( IRI(CONCAT(STR(?comp), "-realizes-", STRAFTER(STR(?svc), "#"))) AS ?d )
            }
        """ ;
    ] .

Before and after¶

The red edge (TMS realizes Tracking Service) is derived from the chain: TMS assigned to Tracking Function, Tracking Function realizes Tracking Service. View source model · Try it out ▶

The derived edge is produced by the rule, carrying its lineage:

:TMS am:realizes :TrackingService .         # the derived triple

:TMS-realizes-TrackingService a am:Realization ;
    arch:source :TMS ;
    arch:target :TrackingService ;
    am:derivationCertainty am:Valid ;
    prov:wasGeneratedBy am:DR-AssignRealize ;
    prov:wasDerivedFrom :TrackingFunction .

Querying — including impact analysis¶

# 1. List every Application Component
PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?c ?label WHERE {
    ?c a am:ApplicationComponent ; skos:prefLabel ?label .
}

# 2. Capabilities with no realizing element (a gap-finder)
SELECT ?cap WHERE {
    ?cap a am:Capability .
    FILTER NOT EXISTS { ?x am:realizes ?cap }
}

# 3. All Realization edges, labelled by how we know them (asserted vs derived)
SELECT ?source ?target ?certainty WHERE {
    ?r a am:Realization ; arch:source ?source ; arch:target ?target .
    OPTIONAL { ?r am:derivationCertainty ?certainty }   # unbound ⇒ asserted
}

# 4. Impact analysis — which capabilities ride on a given technology node?
SELECT DISTINCT ?capability WHERE {
    :AzureCloud (am:serves|am:composedOf|am:realizes|am:assignedTo)+ ?capability .
    ?capability a am:Capability .
}

Query 4 makes "what breaks if we retire this node?" a property-path question rather than a week of manual tracing.

Part 5 — Viewpoints and Generating Presentations¶

A model is one source of truth; stakeholders need many tailored views of it. Linked.Archi separates viewpoints (the specification of a kind of view), presentation contexts (how a view is styled and filtered for an audience), and deliverable templates (SPARQL-driven documents) — all generated from the single model.

Viewpoints as first-class resources¶

A viewpoint is an arch:Viewpoint individual that names the element types it admits, the stakeholders it targets, and the concerns it frames. It is also classified across the arch:Consideration hierarchy (Concern / Aspect / Perspective):

amvp:LayeredViewpoint a arch:Viewpoint ;
    skos:prefLabel "Layered Viewpoint"@en ;
    arch:includesConcept am:BusinessProcess , am:BusinessService , am:ApplicationComponent ,
                         am:ApplicationService , am:Node , am:SystemSoftware ;
    arch:targetsStakeholder amvp:EnterpriseArchitect ;
    arch:viewpointFramesConcern amvp:CrossLayerTraceabilityConcern ;
    arch:viewpointCoversAspect am:ActiveStructureAspect , am:BehaviorAspect ;
    arch:viewpointAddressesPerspective am:OperationalPerspective .

A arch:View declares conformance to one viewpoint — and that conformance is exactly what the viewpoint-shapes from Part 3.4 check:

:NordFreightLayeredView a arch:View ;
    skos:prefLabel "NordFreight Layered View"@en ;
    arch:viewConformsToViewpoint amvp:LayeredViewpoint .

Selected viewpoints (the full catalog is the SKOS ViewpointCatalog):

Viewpoint	Focus
Organization	Business actors, roles, collaborations
Application Cooperation	Application components and their interactions
Application Usage	How applications support business processes
Technology	Nodes, devices, system software, networks
Implementation & Deployment	Artifacts deployed on technology infrastructure
Information Structure	Business and data objects
Service Realization	How services are realized by processes and active structure
Goal Realization	How goals are realized through requirements and outcomes
Capability Map	Capability hierarchy and composition
Migration	Baseline-to-target transition via plateaus and work packages
Layered	Cross-layer traceability — the canonical end-to-end view

Presentation contexts — one model, many renderings¶

A presentation context filters and styles a subgraph for a specific audience. The same NordFreight fragment renders very differently for an executive (capabilities and outcomes, no infrastructure) versus technology operations (nodes and deployment, no strategy).

Presentation contexts are modelled as SKOS concepts with a skos:definition that describes what the audience needs, plus an arch:usesNotationSet link to a visual notation set. Tooling reads the definition text to decide which viewpoints to apply and what level of abstraction is appropriate:

am3pc:ExecutiveContext
    a skos:Concept ; skos:topConceptOf am3pc:ArchiMatePresentationContexts ;
    skos:prefLabel "Executive / C-Level"@en ;
    skos:definition "High-level overview with minimal technical detail. Focus on business capabilities, strategic alignment, cost, and risk."@en ;
    arch:usesNotationSet am3not:ArchiMate32StandardNotation ;
    skos:inScheme am3pc:ArchiMatePresentationContexts .

am3pc:OperationsContext
    a skos:Concept ; skos:topConceptOf am3pc:ArchiMatePresentationContexts ;
    skos:prefLabel "Operations / Infrastructure"@en ;
    skos:definition "Focus on technology layer and deployment. Nodes, devices, networks, environments."@en ;
    arch:usesNotationSet am3not:ArchiMate32StandardNotation ;
    skos:inScheme am3pc:ArchiMatePresentationContexts .

Both use the standard notation set by default. Organisations that want a simplified visual treatment for executives can define their own notation set (e.g. flat boxes without ArchiMate icons) and reference it via arch:usesNotationSet. The skos:definition text on each context drives tooling decisions about which viewpoints to apply and what level of detail to include.

Same NordFreight model, two audiences — executives see capabilities and goals, tech-ops sees nodes and deployment.

Deliverable templates — model to document¶

A deliverable template is a document structure whose sections are populated by SPARQL. The manifest ships templates for the Architecture Definition Document, Architecture Requirements Specification, and Architecture Principles Document:

am3mm:ArchitectureDefinitionDocument a arch:DeliverableTemplate ;
    skos:prefLabel "Architecture Definition Document"@en ;
    arch:hasSection [
        skos:prefLabel "Application Portfolio"@en ;
        arch:populatedBy """
            SELECT ?c ?label WHERE {
                ?c a am:ApplicationComponent ; skos:prefLabel ?label .
            } ORDER BY ?label
        """ ;
    ] .

Run the toolbox generator over NordFreight and the Application Portfolio section materialises as Markdown:

## Application Portfolio
- Customs Gateway
- Tracking Portal
- Transport Management System

Part 6 — Tailoring and Extending the Language¶

The semantic assets are raw material, not a sealed package. Tailoring means adding resources the manifest already knows how to aggregate — never forking the language.

Add a custom element type¶

Suppose NordFreight wants to single out regulatory integration points. Define :RegulatoryGateway as a subclass of am:ApplicationComponent, register it for navigation, and constrain it — touching several assets coherently:

# onto — the class
:RegulatoryGateway a owl:Class ;
    rdfs:subClassOf am:ApplicationComponent ;
    skos:prefLabel "Regulatory Gateway"@en ;
    skos:definition "An application component that integrates with an external regulatory authority."@en .

# tax — so palettes and filters pick it up
:RegulatoryGatewayConcept a skos:Concept ;
    skos:prefLabel "Regulatory Gateway"@en ;
    skos:broader amtax:ApplicationLayer , amtax:InternalActiveStructureElement ;
    rdfs:seeAlso :RegulatoryGateway .

# shapes — a tailored governance rule
:RegulatoryGatewayShape a sh:NodeShape ;
    sh:targetClass :RegulatoryGateway ;
    sh:property [
        sh:path am:influences ;
        sh:minCount 1 ;
        sh:message "A Regulatory Gateway must be influenced by at least one Requirement."@en ;
    ] .

Now reclassify the Customs Gateway:

:CustomsGateway a :RegulatoryGateway ; skos:prefLabel "Customs Gateway"@en .

Because of rdfs:subClassOf, everything already written for am:ApplicationComponent still applies — the relationship-validity shapes from the matrix (Part 3.2), the derivation rules (Part 4), the queries (Part 4), and the viewpoints (Part 5) all continue to see :CustomsGateway, with no changes. That is the payoff of monotonic subsumption.

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:

myorg:CloudApplicationComponent rdfs:subClassOf am:ApplicationComponent .

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

Compose with extensions¶

Cross-cutting extensions import arch:core, so they attach to ArchiMate elements with no integration code. Record why the Customs Gateway pattern was chosen, and how the legacy TMS scores in portfolio terms:

@prefix ad:     <https://meta.linked.archi/arch-decision#> .
@prefix timefw: <https://meta.linked.archi/time-framework/onto#> .

:UseDedicatedCustomsGateway a ad:Decision ;
    skos:prefLabel "Use a dedicated Customs Gateway"@en ;
    ad:addresses :EUCustomsCompliance ;
    ad:affects   :CustomsGateway ;
    ad:status    "accepted" .

:TMSFitAssessment a timefw:FitAssessment ;
    timefw:assesses :TMS ;
    timefw:functionalFit "low" ;
    timefw:technicalFit  "low" ;
    timefw:classifiedAs  timefw:Migrate .   # → flagged for migration

Part 7 — Linking with Other Notations and Frameworks¶

Because every Linked.Archi language imports arch:core, an ArchiMate ApplicationComponent, a C4 Container, and a Backstage Component are all arch:Element instances. They coexist in one graph, share SHACL shapes, and answer the same SPARQL queries.

All languages import arch:core, enabling cross-notation linking in one graph.

A concrete link: ArchiMate ↔ Backstage¶

NordFreight's running estate is catalogued in Backstage, which knows ownership and lifecycle that the ArchiMate model does not. Link the two representations of the same system:

@prefix bs: <https://meta.linked.archi/backstage/onto#> .

# The Backstage catalog entry, with the owner ArchiMate lacked
bs:tracking-portal a bs:Component ;
    skos:prefLabel "tracking-portal"@en ;
    bs:lifecycle "production" ;
    arch:owner "team-shipment-tracking" .

# Establish that these are the same thing
:TrackingPortal owl:sameAs bs:tracking-portal .

Now ask a question no single tool could answer:

# Which ArchiMate Application Components lack an owner, even after consulting Backstage?
PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX arch: <https://meta.linked.archi/core#>
SELECT ?c WHERE {
    ?c a am:ApplicationComponent .
    FILTER NOT EXISTS { ?c arch:owner ?o }
}

With owl:sameAs reasoning, :TrackingPortal inherits arch:owner from bs:tracking-portal, so the governance gap was closed by linking, not by re-modelling.

The SKOS bridge for cross-notation alignment¶

When two notations describe the same concept at different granularities (e.g. an ArchiMate ApplicationComponent and a C4 Container), Linked.Archi uses SKOS mapping properties (skos:exactMatch, skos:closeMatch, skos:broadMatch) to express the correspondence between their taxonomy concepts. This allows tooling to suggest alignments and to generate cross-notation reports without asserting ontological identity (owl:sameAs) between the element types themselves.

Other pairings, in brief¶

ArchiMate ↔ C4 — map an am:ApplicationComponent to a C4 Container for developer-facing zoom-in. See Application Layer vs C4 Containers.
ArchiMate ↔ BPMN — drill a single am:BusinessProcess down into an executable BPMN flow when order, gateways, and exceptions matter.
ArchiMate ↔ TOGAF — cross-map elements to the TOGAF content metamodel so a NordFreight element participates in an ADM deliverable. See the TOGAF Modeling Guide.

The cross-mapping mechanics use owl:sameAs for identity (as shown above) or arch:relatedElement for weaker correspondence. Cross-boundary SPARQL queries then traverse the unified graph regardless of which notation originated each element.

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. The full notation set provides structured rendering data (shape, colour, icon, dimensions) via arch-vis:VisualNotation instances for palette generation.
Spec traceability — dcterms: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 (10,484 valid pairs)
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

Where to Go Next¶

You have now exercised every capability of ArchiMate 3.2 in Linked.Archi: you read the language, authored a model, validated it three ways, derived new facts with provenance, rendered it for two audiences and a document, tailored it with a custom type and two extensions, and linked it to another notation. Re-reading the manifest map, every node is now lit.

You never have to write SPARQL by hand: the Linked.Archi MCP server exposes this whole graph to AI agents, so a natural-language question ("what breaks if we retire Azure North Europe?") is translated to the query in Part 4 and answered against your real model.