Ontology Alignment¶
Scope of this page
"Alignment" here means which published ontology each converter's output is aligned to, and the typing contract that makes cross-notation queries work. It is about one graph agreeing with the vocabularies it claims to use.
It is not about relating one modelling language's concepts to another's. For that:
- Between two instances — this BPMN task and that ArchiMate process describe the same
thing — see Extension data → Stating a correspondence.
skos:exactMatchis the default,owl:sameAsthe documented exception. - Between two languages' types —
bpmn:UserTaskcorresponds toam:BusinessProcess— see Authoring cross-language mappings. Those assertions live in a curated*-crossmappings.ttl, never in converter output. - Swapping which vocabulary the output speaks — see Type Mapping, which substitutes types rather than relating them.
Published ontologies on meta.linked.archi¶
Each converter targets a specific published ontology:
| Converter | Ontology | Namespace | Classes |
|---|---|---|---|
| ArchiMate | ArchiMate 3.2 | am: |
~55 |
| BPMN (full) | BPMN 2.0.2 | bpmn: |
~144 |
| BPMN (lite) | BPMN Lite | bpmnl: |
~28 |
| PlantUML | UML 2.5.1 | uml: |
~80 |
All converters additionally emit dual-typing with the Core Ontology:
- Every element:
a arch:Element, arch:ModelConcept - Every relationship:
a arch:QualifiedRelationship, arch:ModelConcept - Every diagram:
a arch:Diagram
arch:ModelConcept is the common supertype of elements and relationships. Although the
core ontology declares arch:Element rdfs:subClassOf arch:ModelConcept, the converters
emit it explicitly so that consumers (and SHACL sh:class constraints) do not have to
perform RDFS reasoning to see it.
Serialization containers are deliberately not dual-typed. bpmn:definitions and
bpmn:imports, for example, describe the source document rather than the architecture, so
they keep only their notation types.
Core ontology contract¶
The foundational types that enable cross-notation querying:
# Any element from any notation
?elem a arch:Element .
# Any relationship from any notation (with source/target)
?rel a arch:QualifiedRelationship ;
arch:source ?src ;
arch:target ?tgt .
# Any diagram from any notation
?diag a arch:Diagram .
This means a SPARQL query like SELECT ?e WHERE { ?e a arch:Element } returns
elements from ArchiMate, BPMN, and PlantUML models alike.
Labels are language-tagged¶
skos:prefLabel is always emitted as an rdf:langString, because the core SHACL shapes
require it. Match it with a language-aware pattern rather than a plain string:
# Correct — matches "Payment Gateway"@en
?elem skos:prefLabel ?label .
# Will NOT match, the literal is not xsd:string
?elem skos:prefLabel "Payment Gateway" .
The tag defaults to en and is configurable per run with --label-language.
Relationship endpoints¶
Endpoints are arch:source / arch:target. Earlier versions emitted
arch:relSource / arch:relTarget, which the core ontology has superseded; queries
written against the old predicates need updating.
Triple typing pattern¶
Every resource gets three levels of typing:
<.../element/UserTask_1>
a bpmn:UserTask , # 1. Notation-specific type (from published ontology)
arch:Element , # 2. Core foundational type (for cross-notation queries)
arch:ModelConcept . # ...and its supertype, emitted explicitly
With a custom type-mapping YAML, the notation-specific type is replaced by one from your own domain vocabulary:
<.../element/UserTask_1>
a myont:HumanActivity , # from --type-mapping, in place of bpmn:UserTask
arch:Element ,
arch:ModelConcept .
Note this is a substitution, not an addition: bpmn:UserTask is not also emitted, and no triple
relates it to myont:HumanActivity. If a consumer needs to know the two correspond, that
correspondence is asserted in a published ontology or a cross-language mapping document — see
Type Mapping → Substitution, not alignment.
BPMN full vs BPMN Lite¶
| Aspect | Full (bpmn/onto#) |
Lite (bpmn-lite/onto#) |
|---|---|---|
| Classes | ~144 (CMOF-complete) | ~28 (EA-relevant subset) |
| Includes | Documentation, ExtensionElements, EventDefinitions | Only semantic-value elements |
| Use case | Spec-faithful roundtrip, BPMN tool interop | Architecture reasoning, cross-model queries |
| Config | None (default) | --type-mapping config/type-mapping-bpmn-lite.yml |
Verifying alignment¶
The ConversionVerifier checks output against the ontology contract: