Skip to content

Related Work: Alberto D. Mendoza — ArchiMate 3.2 OWL Ontology

Alberto D. Mendoza's ArchiMate ontology is an independent, spec-faithful OWL formalization of ArchiMate 3.2. It is one of the most complete community-driven efforts to represent the ArchiMate language in RDF — covering not just the element and relationship type system, but also derivation rules, three-level SHACL validation, and a SKOS taxonomy. The project demonstrates that a standalone, self-contained ArchiMate ontology is achievable and practically useful.

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

The Project

Mendoza's ontology 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, no ecosystem buy-in required. This makes it immediately usable for anyone who wants ArchiMate-in-RDF as a self-contained artifact.

The namespace is https://purl.org/archimate#, using a PURL for long-term resolvability — a thoughtful choice for a community ontology intended for broad adoption.

The project covers ArchiMate 3.2 and includes:

  • A full OWL ontology with all element types, relationship types, and aspect/layer classification
  • Three-level SHACL validation (core → metamodel → relationships)
  • Derivation rules implementing all 20 ArchiMate derivation rules (DR1–DR8, PDR1–PDR12)
  • A SKOS taxonomy with definitions, alternative labels, and editorial notes
  • A profile/specialization mechanism for custom element types

The Standalone Design

The self-contained design philosophy has clear benefits for adoption:

  • No dependencies — consumers can use the ontology without importing or understanding any external framework. The ArchiMate formalization is complete in itself.
  • Spec fidelity — the ontology mirrors the ArchiMate specification's structure and terminology directly, making it recognizable to practitioners familiar with the standard.
  • Portability — the ontology can be dropped into any RDF environment without compatibility concerns. It works with any triplestore, any SPARQL endpoint, any SHACL validator.

This approach serves organizations that want to represent their ArchiMate models as linked data without committing to a broader platform or multi-language integration strategy.

Relationship Modeling

Mendoza uses OWL ObjectProperties organized under base hierarchies (structuralRelationship, dependencyRelationship, dynamicRelationship, otherRelationship). This mirrors the ArchiMate specification's own categorization and makes the relationship type system immediately navigable.

For relationship metadata (access type, influence sign, and other qualifiers), the project uses RDF-Star quoted triples:

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

This is an elegant approach within the RDF 1.1 + RDF-Star extension ecosystem. It keeps the base graph clean (simple subject-predicate-object triples for graph traversal) while allowing metadata to be attached to specific relationship occurrences without introducing additional nodes. The pattern is lightweight and query-friendly — a SPARQL query can match the base triple without awareness of the metadata layer.

For projects working within RDF 1.2 — such as linked.archi — the rdf:reifies mechanism provides similar annotation capabilities with the addition of typed reifier resources — an evolution of the same underlying idea. Both approaches solve the same fundamental problem: how to attach metadata to a relationship without losing the simplicity of direct triples.

Derivation Rules

The implementation of all 20 ArchiMate derivation rules using SHACL Advanced Features is a significant contribution. Derivation rules are one of the more complex aspects of the ArchiMate specification, and having a working SHACL-based implementation provides a reference for anyone attempting the same. Linked.archi independently implements the same 20 rules using the same SHACL mechanism — the convergence on this approach across projects suggests it is the natural fit for closed-world derivation in RDF.

The approach uses:

  • sh:SPARQLRule with sh:construct for rule execution
  • Weakest-wins logic via numeric strength properties
  • Post-derivation validation of cross-domain restrictions
  • Custom properties for derivation certainty (valid vs. potential)

One notable design choice: DR1 (specialization transitivity) is handled via owl:TransitiveProperty on the specialization property, letting the OWL reasoner handle transitive closure rather than implementing it as a SHACL rule. This is a clean separation of concerns — using OWL reasoning where it naturally fits and SHACL rules where closed-world validation is needed.

Three-Level SHACL Validation

The three-level validation architecture is a particularly well-structured contribution:

  1. Core shapes — basic structural constraints (required properties, cardinality)
  2. Metamodel shapes — element type classification and aspect/layer membership
  3. Relationship shapes — the relationship validity matrix (which source/target type pairs are allowed for each relationship type)

This separation means consumers can apply validation incrementally. An organization might start with core shapes for basic data quality, add metamodel shapes for type correctness, and enable relationship shapes only when they need full specification compliance. The layered approach also makes it easier to extend or override specific validation levels without touching others. Linked.archi's own SHACL shape organization follows a similar layered philosophy, validating elements, relationships, principles, and viewpoints as distinct concerns.

Specialization and Profiles

Mendoza introduces a dedicated archimate:specialization transitive property alongside rdfs:subClassOf. This enables derivation rules to reason about the specialization chain explicitly — the rules can query the specialization property directly rather than relying on OWL class hierarchy inference.

The profile pattern allows organizations to define custom element types as specializations of standard ArchiMate types, with clear semantics for how derivation rules propagate through the specialization hierarchy. This addresses a real need: most enterprise architecture practices extend the standard ArchiMate type system with organization-specific specializations. Linked.archi handles specialization via rdfs:subClassOf directly, which composes naturally across modeling languages but doesn't provide the same explicit queryable property for derivation rule traversal.

Taxonomy

The project provides a SKOS concept scheme with skos:altLabel, skos:scopeNote, skos:changeNote, and skos:editorialNote. The bridge between the SKOS taxonomy and OWL classes uses skos:exactMatch, treating the concept and the class as parallel representations of the same thing.

This is a defensible approach — the SKOS concept provides human-oriented documentation, search, and navigation, while the OWL class provides formal semantics and reasoning. The skos:exactMatch link makes the correspondence explicit and queryable. Linked.archi also maintains a separate SKOS taxonomy alongside its OWL ontology, using rdfs:seeAlso for the bridge — a slightly different stance on the relationship between concept and class, but addressing the same need for dual human-readable and machine-processable representations.

Key Insights from This Work

  • Self-contained ontologies lower the adoption barrier. Not every organization needs or wants a multi-language integration platform. A standalone ArchiMate ontology that "just works" serves a real and important use case.

  • Three-level SHACL validation is a clean architecture. Separating core, metamodel, and relationship validation into distinct layers enables incremental adoption and selective override. This pattern is applicable beyond ArchiMate to any complex metamodel validation scenario.

  • RDF-Star for relationship metadata is pragmatic. When relationships don't need lifecycle management or higher-order modeling (relationships targeting other relationships), quoted triples provide a lightweight annotation mechanism that keeps the base graph simple.

  • Explicit specialization properties aid derivation. Having a dedicated property for specialization (rather than relying solely on rdfs:subClassOf) gives derivation rules a clear, queryable path through the specialization hierarchy.

  • Derivation rule implementations are a community resource. The 20 ArchiMate derivation rules are complex enough that working reference implementations — regardless of the specific ontology they target — benefit everyone working in this space.

  • PURL namespaces signal community intent. Using purl.org for the namespace indicates the ontology is designed for broad community use with stable, resolvable identifiers — a good practice for any ontology intended to outlive its original author's infrastructure.

References