Skip to content

Related Work: Mendoza ArchiMate Ontology

Alberto D. Mendoza's ArchiMate ontology is an independent OWL formalization of ArchiMate 3.2 — self-contained, spec-faithful, and designed as a standalone representation of the language.

Repository: github.com/AlbertoDMendoza/archimate_ontology Blog: ArchiMate 3.2 in RDF — Engineering the Graph

Overview

Dimension Linked.Archi Mendoza
Namespace https://meta.linked.archi/archimate3/onto# https://purl.org/archimate#
ArchiMate version 3.2 and 4.0 3.2
Design stance Module within a multi-language ecosystem Standalone, self-contained
Relationships Three-declaration qualified pattern + rdf:reifies (RDF 1.2) OWL ObjectProperties + RDF-Star quoted triples
Validation SHACL shapes (generated relationship matrix + element + principle + viewpoint) Three-level SHACL + profiles + derivation rules
Derivation rules DR1–DR8, PDR1–PDR12 via SHACL Rules DR1–DR8, PDR1–PDR12 via SHACL Rules (DR1 via owl:TransitiveProperty)
Specialization rdfs:subClassOf directly Dedicated profile pattern with archimate:specialization property
Taxonomy Separate SKOS file Separate SKOS file with skos:exactMatch to OWL classes

Different design stances

We make different foundational choices based on different goals.

Mendoza treats ArchiMate as a complete, self-sufficient modeling language that should be faithfully represented in OWL without external dependencies. The ontology stands alone — no imports, no integration layer. This makes it immediately usable for anyone who wants ArchiMate-in-RDF without buying into a larger ecosystem.

Linked.Archi treats ArchiMate as one modeling language among many. Every element is rdfs:subClassOf arch:Element, which enables cross-language queries (ArchiMate + BPMN + Backstage in the same graph) but creates a dependency on the core ontology.

Neither stance is wrong — they serve different use cases.

Relationship modeling

This is the most significant divergence.

Mendoza uses OWL ObjectProperties organized under base hierarchies (structuralRelationship, dependencyRelationship, dynamicRelationship, otherRelationship). Relationship metadata (access type, influence sign) uses RDF-Star quoted triples:

:Process1 archimate:access :CustomerData .
<<:Process1 archimate:access :CustomerData>>
    archimate:accessType "read" .

Linked.Archi emits three declarations per relationship type — an unqualified predicate for graph traversal, a qualified class for first-class relationship resources, and a qualified predicate for navigation. Relationship occurrences are architectural objects with identity, lifecycle, and provenance, bridged to their direct triple via RDF 1.2 rdf:reifies.

The trade-off: Mendoza's approach is simpler and sufficient when relationships are just connections. Our approach is heavier but supports lifecycle management (proposed → approved → deprecated), multiple distinct occurrences between the same pair, and higher-order modeling (relationships targeting other relationships). Enterprise architecture governance often needs these — but not always.

Derivation rules

Both implement the same 20 ArchiMate derivation rules (Appendix B/C) using SHACL Advanced Features. The mechanisms are nearly identical — sh:SPARQLRule with sh:construct, weakest-wins logic via numeric strength properties, and post-derivation validation of cross-domain restrictions.

One notable difference: Mendoza handles DR1 (specialization transitivity) via owl:TransitiveProperty on the specialization property, letting the OWL reasoner handle it rather than a SHACL rule. Linked.Archi implements it as a SHACL rule like the others.

Both define custom properties for derivation certainty (valid vs potential) since no standard vocabulary exists for this ArchiMate-specific distinction.

Specialization

Mendoza introduces a dedicated archimate:specialization transitive property alongside rdfs:subClassOf. This enables derivation rules to reason about the specialization chain explicitly.

Linked.Archi uses rdfs:subClassOf directly — the standard OWL mechanism. Simpler, and composes across modeling languages (a custom element can subclass both an ArchiMate type and a Backstage type). But it doesn't provide an explicit specialization property for derivation rules to query.

Taxonomy

Both provide SKOS concept schemes with skos:altLabel, skos:scopeNote, skos:changeNote, and skos:editorialNote. The main difference is the bridge to OWL classes: Linked.Archi uses rdfs:seeAlso (the SKOS concept and OWL class serve different purposes), Mendoza uses skos:exactMatch (treating them as parallel representations of the same thing). Both positions are defensible.

What we learned from this project

  • The three-level SHACL validation architecture (core → metamodel → relationships) is a clean separation that Linked.Archi's shape organization could benefit from.
  • The dedicated profile pattern with an explicit specialization property is worth considering if derivation rules need to reason about specialization chains.
  • RDF-Star for relationship metadata is simpler than qualified relationship resources when you don't need lifecycle management or higher-order modeling. However, RDF 1.2 with rdf:reifies supersedes RDF-Star and provides the same lightweight annotation capability while also supporting typed reifiers — which is what we use. The Mendoza approach works within RDF 1.1 + the RDF-Star extension; ours requires RDF 1.2 but gets typed relationship resources as a bonus.
  • The skos:exactMatch approach to bridging taxonomy and ontology is reasonable when the two are genuinely parallel representations.

References