Skip to content

Related Work: bp4mc2 — ArchiMate to RDF Transformation

bp4mc2's archimate2rdf is an XSL-based translator that converts ArchiMate Model Exchange Files into RDF. It represents a pragmatic, low-barrier approach to bringing architecture models into the linked data world — prioritizing immediate usability and simplicity over ontological depth. The project is a valuable contribution from the Dutch linked data community and demonstrates that useful RDF representations of ArchiMate can be achieved with minimal tooling.

Repository: github.com/bp4mc2/archimate2rdf
Ontology: bp4mc2.org/def/archimate

The Project

bp4mc2 (Best Practices for Meaningful Connected Computing) is a Dutch initiative from the Platform Implementatie Linked Open Data (PiLOD), focused on linked data best practices for government and public sector data. The archimate2rdf project is a practical tool within this ecosystem — it takes an ArchiMate Open Exchange Format XML file, applies an XSL transformation, and produces RDF output.

The project explicitly states its ontology is "as close to the XSD as possible, focusing on simplicity" and is "actually generated from the XSD." This is a deliberate design choice: the authors prioritize a thin, predictable mapping over semantic richness. The result is an ontology where ArchiMate element type names become OWL classes and relationship types become ObjectProperties — a direct structural mirror of the exchange format.

The namespace is https://bp4mc2.org/def/archimate#.

The Transformation Approach

The core value proposition is zero-friction conversion. You have an ArchiMate Exchange XML file, you run the XSL transform, you get RDF. No programming dependencies, no ecosystem buy-in, no learning curve beyond basic RDF and XSLT processing. This makes it particularly accessible for organizations already working with XML toolchains who want to explore what their architecture models look like as linked data.

The XSD-derived ontology approach has clear benefits:

  • Reproducibility — the ontology can be regenerated whenever the ArchiMate XSD changes, keeping it aligned with the exchange format specification.
  • Predictability — consumers familiar with the ArchiMate exchange format can anticipate the RDF structure without studying a separate ontology documentation.
  • Low maintenance — the ontology doesn't require manual curation or interpretation of the ArchiMate specification's prose.

The trade-off is that structural mappings capture the shape of the data but not its semantics. Definitions, abstract hierarchies, derivation rules, and cross-language integration require human interpretation of the specification — work that automated XSD-to-OWL generation cannot perform.

Relationship Metadata

bp4mc2 uses classic rdf:Statement reification when relationships need metadata:

ex:rel1 a rdf:Statement ;
    rdf:subject   ex:AC1 ;
    rdf:object    ex:AC2 ;
    rdf:predicate archimate:flow ;
    archimate:association ex:DO1 .

The project emits both the direct triple and the reified statement — a pragmatic pattern that makes SPARQL queries simpler for consumers who don't need the metadata while still preserving it for those who do. This dual-emission approach is a well-known best practice in the RDF community and is independently adopted by other projects working with qualified relationships, including linked.archi's own converters which emit the unqualified triple alongside the qualified relationship resource.

The rdf:Statement reification pattern is straightforward and well-understood by any RDF practitioner. It works well for data interchange scenarios where relationship metadata (like names, documentation, or properties) needs to travel alongside the structural graph.

Instance Identification

The project uses URN-based identifiers (urn:uuid:) for instances, directly preserving the UUIDs from the ArchiMate exchange format. This is a sensible choice for a transformation tool — it maintains a stable, tool-independent identity for each element and relationship without requiring a URL resolution infrastructure.

Design Rationale and Documentation

One of the project's strengths is its explicit documentation of design choices. The README explains why rdfs:label is used over custom properties, why rdf:Statement reification was chosen, and why URN-based identifiers are preferred. Documenting what you chose not to do is as valuable as documenting what you did — it helps consumers understand the boundaries and intended use of the ontology.

The Call for an Official Ontology

The bp4mc2 authors include a notable call to action: "We urge the Open Group to publish the archimate ontology at their own namespace!" This reflects a widely shared sentiment in the community. Until an official ArchiMate ontology exists, independent formalizations — whether transformation-oriented like bp4mc2 or semantically rich like those pursuing full metamodel coverage — fill an important gap.

Each independent effort validates the demand and demonstrates different facets of what an official formalization could look like. The diversity of approaches (XSD-derived, hand-authored, reasoning-oriented) collectively maps the design space and informs what a future standard might need to address.

Key Insights from This Work

  • Immediate usability matters. Not every organization needs a full metamodel platform on day one. A lightweight transformation that gets architecture data into RDF — even with a thin ontology — enables exploration, prototyping, and integration experiments that can inform later investment in richer representations.

  • XSL-based transformation is accessible. By staying within the XML/XSL ecosystem, the project meets architects and data engineers where they already are. No new programming languages, no graph database setup required for the initial conversion.

  • The dual-emission pattern is sound. Emitting both the direct triple and the reified statement is a pragmatic choice that serves different query patterns without forcing consumers to choose. This pattern appears independently in multiple projects working with qualified relationships in RDF, including linked.archi's own converters.

  • XSD-derived ontologies have a role. They are fast to produce, easy to maintain, and adequate for data interchange. They capture structure faithfully. For use cases that require semantic depth — definitions, validation, derivation, cross-language integration — they serve as a useful starting point that can be enriched incrementally. Linked.archi's hand-authored ontology takes the opposite path (interpreting the specification's prose rather than its schema), but both approaches start from the same source material and serve complementary purposes.

  • Community contributions advance the field. Projects like bp4mc2's archimate2rdf demonstrate real-world demand for ArchiMate in RDF and provide working implementations that others can learn from, build upon, or use as reference points for their own approaches. Together with linked.archi, Mendoza's ontology, and Figay's OWL explorations, they form a growing body of evidence that the architecture modeling community needs and wants linked data representations of its frameworks.

References