ArchiMate Ontology — Design Decisions¶

Design decisions specific to the ArchiMate modeling language ontology. For repo-wide decisions that apply to all Linked.Archi ontologies, see Design Decisions.

AM-DD-1: Abstract Classification via rdfs:subClassOf (Layer × Aspect)¶

Decision: Concrete ArchiMate elements use rdfs:subClassOf to inherit from both their aspect class (e.g., am:InternalBehaviorElement) and their layer class (e.g., am:BusinessLayerElement), alongside arch:Element. The abstract classes and concrete elements all live in the am: namespace within archimate3.2-onto.ttl. A separate SKOS taxonomy (archimate3.2-tax.ttl) provides navigation and UI classification.

:BusinessProcess
    rdfs:subClassOf  :InternalBehaviorElement,
                     :BusinessLayerElement,
                     arch:Element .

Rationale: The abstract categories (BehaviorElement, ActiveStructureElement, BusinessLayerElement, etc.) are genuine semantic types — they determine what relationships an element can participate in. This is exactly what rdfs:subClassOf is for. SHACL shapes use rdf:type/rdfs:subClassOf* property paths to query the hierarchy, which is the simplest and most standard pattern.

Why both OWL classes and SKOS concepts?

The OWL classes and the SKOS concepts in the taxonomy are NOT duplicates. They serve complementary purposes:

	OWL classes (`am:` in onto)	SKOS concepts (`amtax:` in tax)
Example	`am:ActiveStructureElement`	`amtax:ActiveStructureAspect`
Purpose	Formal semantics — determines what relationships an element can participate in	Navigation — organizes elements for UI palettes, filtering, and visualization tools
Used by	SHACL shapes via `rdf:type/rdfs:subClassOf*`	Modeling tools via `skos:broader`/`skos:narrower`
Use case	"In core layers, assignment can only originate from ActiveStructureElements" — SHACL walks the class hierarchy to enforce this	"Show all Business Layer elements in the palette" — tool queries `skos:narrower` of `amtax:BusinessLayer`
Linked via	`rdfs:seeAlso` on each SKOS concept pointing to its OWL class

The OWL hierarchy defines what things ARE. The SKOS taxonomy defines how things are PRESENTED. A BusinessActor IS-A ActiveStructureElement (formal, used in constraints). A BusinessActor is FILED UNDER ActiveStructureAspect (navigational, used in UIs).

Trade-off: Multiple inheritance via rdfs:subClassOf means instances are inferred to be members of all ancestor classes. In practice this is acceptable because Linked.Archi uses minimal OWL (DD-2) and SHACL for validation — no DL reasoner materializes the full closure.

AM-DD-2: Specialization via rdfs:subClassOf (No Dedicated Profile Mechanism)¶

Decision: ArchiMate user-defined specializations are modeled as rdfs:subClassOf the parent element type. No separate profile or specialization framework is introduced.

myorg:CloudApplicationComponent
    a               owl:Class ;
    rdfs:subClassOf am:ApplicationComponent ;
    skos:prefLabel  "Cloud Application Component"@en ;
    skos:definition "An application component deployed as a cloud-native service."@en .

Rationale: rdfs:subClassOf is the standard OWL/RDFS mechanism for specialization and already provides everything a profile system would need:

SHACL shape inheritance — Shapes targeting am:ApplicationComponent via rdf:type/rdfs:subClassOf* automatically apply to myorg:CloudApplicationComponent instances. No shape duplication or profile-aware validation logic required.
Relationship validity — The generated relationship shapes (from the ArchiMate matrix) use class hierarchy paths. A subclass inherits all valid source/target pairs from its parent.
Taxonomy membership — SKOS concepts linked to the parent class via rdfs:seeAlso remain navigable. Organizations can extend the taxonomy with their own SKOS concepts for the specialization.
Visual notation — arch:prefVisNotation can be overridden on the subclass or inherited from the parent.

Organizations bundle their specializations into a custom metamodel that imports the ArchiMate ontology and declares itself as an arch:Metamodel (see DD-17):

myorg-mm:MyOrgMetamodel
    a                    arch:Metamodel ;
    owl:imports          <https://meta.linked.archi/archimate3/onto#> ;
    arch:modelConcepts   <https://myorg.example/metamodel/onto#> ;
    arch:formalRules     <https://myorg.example/metamodel/shapes#> .

Why not a dedicated profile mechanism? A profile system would add a layer of indirection (profile → specialization → element) that duplicates what rdfs:subClassOf already does. The ArchiMate specification's own Specialization relationship maps directly to rdfs:subClassOf — the semantic web already has the concept built in. Adding a parallel mechanism would create two ways to do the same thing, with the risk that tools and shapes need to understand both.

Activation is handled at the graph level — load the extension ontology or don't. This is strictly more powerful than UML-style profile application because it composes freely across modeling languages. An organization can create a single metamodel that combines ArchiMate, C4, and custom elements, importing what it needs:

myorg-mm:MyOrgMetamodel
    a              arch:Metamodel ;
    owl:imports    <https://meta.linked.archi/archimate3/onto#> ,
                   <https://meta.linked.archi/c4/onto#> ;
    arch:modelConcepts <https://myorg.example/metamodel/onto#> .