Skip to content

Linked.Archi UML Ontology — Deep Dive

Detailed analysis of the UML 2.5.1 ontology defined in modelingLanguages/uml/, covering the theoretical foundation (MOF↔OWL equivalence, ODM mapping rules), the ontology architecture, element coverage, relationship modeling, SHACL shapes, taxonomy, viewpoints, and cross-language integration.

1. Overview

The Linked.Archi UML ontology is an RDF/OWL formalization of the OMG Unified Modeling Language metamodel (UML 2.5.1, OMG formal/2017-12-05). It imports the core ontology (arch:) and positions UML as one modeling language within the Linked.Archi ecosystem — alongside ArchiMate, C4, BPMN, and Backstage.

The OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) is acknowledged as related work — its Annex D mapping rules are used as an informative reference for how UML constructs surface in OWL. See §2.3 for the disambiguation.

2. Theoretical Foundation — Why RDF Can Represent UML

2.1 The Approach: Modeling UML WITH OWL

Linked.Archi uses RDFS/OWL as the foundational layer in which all modeling languages — including UML — are expressed. UML's metamodel becomes an OWL ontology; UML model instances become RDF individuals typed with that ontology's classes.

OMG Stack                              Linked.Archi (W3C-rooted)
─────────────────────                  ─────────────────────────────────
M3:  MOF                               M3:  RDFS/OWL (reflective)
     (defines metamodels)                   (defines ontologies)
M2:  UML, BPMN, SysML                  M2:  uml-onto.ttl
     (all defined using MOF)                (UML metamodel expressed IN OWL)
M1:  Model instances                   M1:  RDF individuals
     (conform to M2)                        (typed with M2 classes)
M0:  The real world                    M0:  The real world

RDFS/OWL is the spine — already reflective, already self-describing — and UML is just one M2 vocabulary expressed in it. The lingua franca is RDF/Turtle; UML (and architectural models) is the payload. This gets you SPARQL, OWL reasoners, SHACL validation, dereferenceable URIs, and the linked-data ecosystem "for free" because models are just RDF.

This is sometimes called the "Linked Metamodels" or "ontology-based metamodeling" pattern. Precedents include: - FIBO (finance) — OWL ontologies consumed as plain RDF by people who never touch a UML tool - ArchiMate-as-RDF efforts (various, including from The Open Group) — same move for the ArchiMate metamodel - OSLC (Open Services for Lifecycle Collaboration) — chose RDF/OWL as the foundation for tool interchange in software/systems engineering - Atlas Group "UML2 in OWL" and IBM's earlier work — academic/industrial OWL renderings of the UML metamodel since ~2010

2.2 Note on the M3 Framing

The W3C stack is much flatter than the four-layer MOF tower and doesn't really need an "M3" in the OMG sense. owl:Class, rdfs:Class, and rdf:Property are reflective resources (rdfs:Class rdf:type rdfs:Class), not a separate meta-meta tier.

We keep the four-layer framing for didactic continuity with OMG-trained colleagues — it helps them understand where UML-as-OWL fits relative to what they know. But structurally, everything is in one RDF graph; layers are a viewpoint, not a structural fact.

2.3 Relationship to the OMG Ontology Definition Metamodel (ODM)

The OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) is "a family of MOF metamodels, mappings between those metamodels as well as mappings to and from UML, and a set of profiles that enable ontology modeling through the use of UML-based tools" (ODM §1). The metamodels that comprise ODM reflect the abstract syntax of knowledge representation languages — RDF and OWL (W3C), Common Logic and Topic Maps (ISO) — and enable their authoring in UML environments.

Note how ODM places OWL at M2 — just another metamodel defined in MOF, alongside UML, BPMN, and SysML:

Layer OMG Stack (with ODM) Linked.Archi (W3C-rooted)
M3 MOF (defines metamodels) RDFS/OWL (defines ontologies)
M2 UML, BPMN, SysML, OWL (all defined using MOF) uml-onto.ttl (UML metamodel expressed IN OWL)
M1 Model instances (conform to M2) RDF individuals (typed with M2 classes)
M0 The real world The real world

In Linked.Archi, OWL is not at M2 — it is the M3 foundation itself. This is the fundamental architectural difference: ODM treats OWL as a payload to be modeled; we treat OWL as the substrate that models everything else.

ODM is relevant when building data models and vocabularies for datasets — for example, modeling a domain ontology for healthcare or finance in a UML tool using stereotypes like <<owl:Class>> and <<owl:ObjectProperty>>, then exporting the result as OWL/RDF.

Example of what ODM enables: A data modeler creates an OWL ontology for a university domain using ODM's OWL Profile. They draw a class Course with stereotype <<owl:Class>>, an association enrolled with stereotype <<owl:ObjectProperty>>, and export:

<owl:Class rdf:ID="Course"/>
<owl:ObjectProperty rdf:ID="enrolled">
  <rdfs:domain rdf:resource="Course"/>
  <rdfs:range rdf:resource="Student"/>
</owl:ObjectProperty>

This is not what Linked.Archi does. We don't use UML tools to author ontologies, and we don't transform UML models into equivalent OWL ontologies for datasets. We use OWL directly to describe the UML metamodel itself — so that UML model data can be typed in an architecture knowledge graph.

Where ODM's mapping rules remain relevant: ODM Annex D (informative, not normative — see ODM §8.4.4) contains rules for how UML constructs translate to OWL. These remain a useful peer-reviewed reference when deciding how to represent UML metaclass features in OWL — for example, how association ends, multiplicity, and generalization sets should surface.

UML Construct ODM Maps To How We Use It
Package owl:Ontology (D.3.2) The metamodel is an owl:Ontology
Class owl:Class (D.3.3) Metaclasses become owl:Class + rdfs:subClassOf arch:Element
Generalization rdfs:subClassOf (D.3.3) Metaclass hierarchy: uml:Component rdfs:subClassOf uml:Class
Property (attribute) owl:DatatypeProperty (D.3.4) Metaclass features: uml:isAbstract a owl:DatatypeProperty
Association (binary) owl:ObjectProperty pair (D.3.5) Three-declaration pattern (extends this — see DD-10)
AssociationClass / N-ary owl:Class + functional properties (D.3.6) Closest ODM precedent for arch:QualifiedRelationship
Multiplicity OWL cardinality restrictions (D.3.7) SHACL shapes instead (DD-2)
Enumeration owl:oneOf (D.3.9) SKOS ConceptScheme, optionally combined with owl:oneOf

The key difference: ODM maps UML model instances (M1) to OWL for dataset/vocabulary use. We represent the UML metamodel (M2) in OWL so that architecture model data can be typed in a knowledge graph. A UML model instance becomes ex:OrderService a uml:Component — not ex:OrderService a owl:Class.

2.4 Concrete Example — UML Class to RDF

Consider a UML model containing a class OrderService with an attribute maxRetries: Integer and a generalization to BaseService:

In UML (M1 — model instance): 

classDiagram
    class OrderService {
        <<component>>
        -maxRetries: int
        +processOrder()
    }
    class BaseService

    BaseService <|-- OrderService : generalizes

In RDF (M1 — same model as RDF individuals): 

@prefix uml: <https://meta.linked.archi/uml/onto#> .
@prefix ex:  <https://model.example.com/orders#> .

# The class itself
ex:OrderService
    a               uml:Component ;
    skos:prefLabel  "OrderService"@en ;
    uml:isAbstract  false ;
.

# An attribute
ex:OrderService_maxRetries
    a               uml:Property ;
    skos:prefLabel  "maxRetries"@en ;
    uml:visibility  "private" ;
    uml:lower       0 ;
    uml:upper       1 ;
.

# The generalization (direct triple — for SPARQL traversal)
ex:OrderService uml:generalizes ex:BaseService .

# The generalization (qualified resource — when metadata needed)
ex:OrderService uml:qualifiedGeneralizes ex:gen-001 .
ex:gen-001
    a               uml:Generalization ;
    arch:source     ex:OrderService ;
    arch:target     ex:BaseService ;
    rdf:reifies     <<( ex:OrderService uml:generalizes ex:BaseService )>> ;
    prov:wasDerivedFrom ex:classdiagram-main ;
.

# The general class
ex:BaseService
    a               uml:Class ;
    skos:prefLabel  "BaseService"@en ;
    uml:isAbstract  true ;
.

This demonstrates how we model UML WITH OWL (not use UML AS OWL): - UML Class metaclass → uml:Class which is rdfs:subClassOf arch:Element (a palette concept) - UML Component metaclass → uml:Component which is rdfs:subClassOf uml:Class (metaclass hierarchy) - A model instance OrderService → ex:OrderService a uml:Component (typed with the metaclass, NOT a owl:Class) - UML Property metaclass → uml:Property instance for attributes - UML Generalization → both uml:generalizes predicate AND uml:Generalization qualified resource (Linked.Archi DD-10)

2.5 Why This Works for a Common Architecture Knowledge Graph

Because UML models become RDF triples typed with uml: classes, they can coexist with ArchiMate, C4, BPMN, and Backstage models in the same graph:

# Find all "components" across all modeling languages
SELECT ?component ?label ?language WHERE {
    ?component a/rdfs:subClassOf* arch:Element ;
               skos:prefLabel ?label .
    VALUES (?type ?language) {
        (uml:Component "UML")
        (am:ApplicationComponent "ArchiMate")
        (c4:Container "C4")
        (bs:Component "Backstage")
    }
    ?component a ?type .
}

The shared arch:Element superclass and the common arch:source/arch:target pattern on relationships make cross-language queries trivial.

3. File Structure

File Purpose
uml-onto.ttl Element classes (70+ metaclasses), relationship types (14, three-declaration pattern), attribute properties (20+)
uml-metamodel.ttl Metamodel manifest aggregating all constituent resources
uml-alignment.ttl Alignment axioms mapping UML metaclasses to arch:Element / arch:QualifiedRelationship
uml-shapes.ttl SHACL shapes for relationship domain/range and element property constraints
uml-tax.ttl SKOS taxonomy classifying metaclasses by diagram type and by category
uml-viewpoints.ttl All 14 UML diagram types as arch:Viewpoint instances
uml-reference-data.ttl Controlled vocabularies (8 SKOS concept schemes for UML enumerations)
README.md Module overview, ODM mapping table, cross-language integration

4. Architecture and Class Hierarchy

4.1 Abstract Metaclass Hierarchy

The ontology mirrors the UML 2.5.1 metaclass hierarchy from Chapters 7-11:

flowchart TD
    archEl["arch:Element"]
    umlEl["uml:Element"]
    NE["uml:NamedElement"]
    NS["uml:Namespace"]
    TE["uml:TypedElement"]
    RE["uml:RedefinableElement"]
    PE["uml:PackageableElement"]
    Ty["uml:Type"]
    Cl["uml:Classifier"]
    SC["uml:StructuredClassifier"]
    EC["uml:EncapsulatedClassifier"]
    BC["uml:BehavioredClassifier"]
    CC["(concrete classifiers)"]

    archEl --> umlEl --> NE
    NE --> NS & TE & RE & PE
    PE --> Ty --> Cl
    Cl --> SC & BC & CC
    SC --> EC

4.2 Concrete Classifiers

Category Classes UML Chapter
Simple Classifiers Class, Interface, DataType, PrimitiveType, Enumeration, Signal Ch. 10
Structured Classifiers Component, Port, Connector, Collaboration Ch. 11
Packages Package, Model, Profile, Stereotype Ch. 12
Use Cases Actor, UseCase, ExtensionPoint Ch. 18
Deployments Node, Device, ExecutionEnvironment, Artifact, DeploymentSpecification Ch. 19
Common Behavior Behavior, Event, Trigger, OpaqueBehavior, FunctionBehavior Ch. 13
Activities Activity, Action, ControlNode (Initial, Final, Decision, Merge, Fork, Join), ObjectNode, ActivityPartition Ch. 15-16
State Machines StateMachine, State, FinalState, Pseudostate, Region, Transition Ch. 14
Interactions Interaction, Lifeline, Message, MessageOccurrenceSpecification, OccurrenceSpecification, InteractionFragment, MessageEnd, CombinedFragment, InteractionOperand, InteractionUse, ExecutionSpecification, BehaviorExecutionSpecification, StateInvariant, GeneralOrdering, Gate, InteractionConstraint, DestructionOccurrenceSpecification, Continuation Ch. 17
Information Flows InformationItem, InformationFlow Ch. 20

4.3 How UML Metaclass Categories Map to OWL

Classifiers — every UML metaclass becomes an owl:Class with rdfs:subClassOf reflecting the UML generalization hierarchy:

uml:Component
    a               owl:Class ;
    rdfs:subClassOf uml:Class ;          # UML: Component specializes Class
    skos:prefLabel  "Component"@en ;
    skos:definition '''A Component represents a modular part of a system...'''@en ;
    dcterms:source       <https://www.omg.org/spec/UML/2.5.1/> ;
.

Attributes — UML metaclass attributes become owl:DatatypeProperty declarations:

uml:isAbstract
    a               owl:DatatypeProperty ;
    skos:prefLabel  "Is Abstract"@en ;
    arch:domainIncludes uml:Classifier ;
    rdfs:range      xsd:boolean ;
.

Note: We use arch:domainIncludes rather than rdfs:domain (DD-8, Domain & Range Guide) to avoid unintended inference.

Packages — in Linked.Archi, the entire UML metamodel is a single ontology file (uml-onto.ttl) because we are representing the metamodel itself, not individual UML models. When converting actual UML models to RDF, each UML Package in the model could become a named graph or a separate ontology file.

Enumerations — Linked.Archi uses SKOS concept schemes (DD-7) as the primary mechanism because they support: - Hierarchical organization of values - Multilingual labels - Notation symbols (e.g., + for public, - for private) - Extensibility without modifying the ontology

Example from uml-reference-data.ttl: 

:VisibilityKind
    a                skos:ConceptScheme ;
    skos:prefLabel   "Visibility Kind"@en ;
    skos:hasTopConcept :Public, :Private, :Protected, :Package ;
.

:Public a skos:Concept ; skos:topConceptOf :VisibilityKind ;
    skos:prefLabel "public"@en ;
    skos:notation  "+" ;
    skos:definition "The NamedElement is visible to all elements that can access the Namespace."@en ;
.

Note on owl:oneOf: The UML reference data uses pure SKOS (no owl:oneOf) because the enumeration values don't need closed-world reasoning in this context. However, Linked.Archi does combine both patterns when needed — see frameworks/TIME/time-onto.ttl where owl:oneOf provides closed-enumeration semantics and the same individuals are also skos:Concept for navigation. The choice depends on whether a reasoner needs to know "these are the ONLY possible values."

5. Relationship Modeling

5.1 The 14 Relationship Types

All UML relationship types follow the Linked.Archi three-declaration pattern (DD-10):

Unqualified Predicate Qualified Class Qualified Predicate UML Source
uml:associatedWith uml:Association uml:qualifiedAssociatedWith §11.5
uml:aggregates uml:Aggregation uml:qualifiedAggregates §11.5 (shared)
uml:composedOf uml:Composition uml:qualifiedComposedOf §11.5 (composite)
uml:generalizes uml:Generalization uml:qualifiedGeneralizes §9.7
uml:realizes uml:Realization uml:qualifiedRealizes §7.7
uml:realizesInterface uml:InterfaceRealization uml:qualifiedRealizesInterface §10.4
uml:dependsOn uml:Dependency uml:qualifiedDependsOn §7.7
uml:uses uml:Usage uml:qualifiedUses §7.7
uml:abstracts uml:Abstraction uml:qualifiedAbstracts §7.7
uml:includes uml:Include uml:qualifiedIncludes §18.2
uml:extends uml:Extend uml:qualifiedExtends §18.2
uml:deployedOn uml:Deployment uml:qualifiedDeployedOn §19.2
uml:importsPackage uml:PackageImport uml:qualifiedImportsPackage §12.2
uml:mergesPackage uml:PackageMerge uml:qualifiedMergesPackage §12.2

5.2 Association Mapping Pattern

ODM maps MOF::Association to owl:ObjectProperty. However, UML Associations are richer than OWL properties — they have: - Named association ends (member ends) - Navigability - Multiplicity on each end - Aggregation kind (none, shared, composite) - Association classes

The Linked.Archi three-declaration pattern handles this by making the Association a first-class arch:QualifiedRelationship resource that can carry all this metadata:

# Schema level (in uml-onto.ttl)
uml:associatedWith
    a                    owl:ObjectProperty ;       # Unqualified predicate
    arch:domainIncludes  uml:Classifier ;
    arch:rangeIncludes   uml:Classifier ;
.

uml:Association
    a                    owl:Class ;
    rdfs:subClassOf      arch:QualifiedRelationship ;
    arch:unqualifiedForm uml:associatedWith ;       # Schema-level bridge
.

# Instance level (in model data)
ex:Customer uml:associatedWith ex:Order .           # Direct triple (SPARQL traversal)

ex:assoc-001 a uml:Association ;                    # Qualified resource (metadata)
    arch:source     ex:Customer ;
    arch:target     ex:Order ;
    skos:prefLabel  "places"@en ;                   # Association name
    uml:lower       1 ;                             # Target end multiplicity
    uml:upper       -1 ;                            # * (unlimited)
    rdf:reifies     <<( ex:Customer uml:associatedWith ex:Order )>> ;
.

5.3 Relationship Hierarchy

UML relationship types form a hierarchy that is preserved in the ontology:

flowchart TD
    QR["arch:QualifiedRelationship"]
    Assoc["uml:Association"]
    Agg["uml:Aggregation (shared)"]
    Comp["uml:Composition (composite)"]
    Gen["uml:Generalization"]
    Real["uml:Realization"]
    IR["uml:InterfaceRealization"]
    Dep["uml:Dependency"]
    Usage["uml:Usage"]
    Abs["uml:Abstraction"]
    Inc["uml:Include"]
    Ext["uml:Extend"]
    Deploy["uml:Deployment"]
    PI["uml:PackageImport"]
    PM["uml:PackageMerge"]

    QR --> Assoc & Gen & Real & Dep & Inc & Ext & Deploy & PI & PM
    Assoc --> Agg & Comp
    Real --> IR
    Dep --> Usage & Abs

This hierarchy means SHACL shapes targeting uml:Dependency automatically apply to uml:Usage and uml:Abstraction instances.

6. SHACL Shapes (uml-shapes.ttl)

6.1 Relationship Domain/Range Shapes

Every relationship type has a SHACL NodeShape validating source and target types:

:InterfaceRealizationShape
    a              sh:NodeShape ;
    sh:targetClass uml:InterfaceRealization ;
    sh:property [
        sh:path     arch:source ;
        sh:class    uml:BehavioredClassifier ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:message  "InterfaceRealization source must be a BehavioredClassifier."@en ;
    ] ;
    sh:property [
        sh:path     arch:target ;
        sh:class    uml:Interface ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:message  "InterfaceRealization target must be an Interface."@en ;
    ] ;
.

6.2 Element Property Shapes

Structural constraints on element properties:

  • NamedElementShape — requires skos:prefLabel
  • ClassifierShape — uml:isAbstract must be single boolean
  • PropertyShape — uml:lower/uml:upper must be single integers
  • PortShape — boolean flags (isBehavior, isService, isConjugated)

7. Taxonomy (uml-tax.ttl)

The SKOS taxonomy classifies UML metaclasses along two independent dimensions:

7.1 By Diagram Type (UML 2.5.1 Annex A)

flowchart TD
    UCS["&lt;uml/tax#&gt;  (ConceptScheme)"]
    BDT["ByDiagramType"]
    SD["StructuralDiagrams"]
    CD["ClassDiagram → Class, Interface, DataType, Enumeration"]
    CompD["ComponentDiagram → Component, Port, Connector"]
    PD["PackageDiagram → Package"]
    DD["DeploymentDiagram → Node, Device, ExecutionEnvironment, Artifact"]
    CSD["CompositeStructureDiagram → Collaboration"]
    OD["ObjectDiagram"]
    PrD["ProfileDiagram → Profile, Stereotype"]
    BD["BehavioralDiagrams"]
    UCD["UseCaseDiagram → Actor, UseCase"]
    AD["ActivityDiagram → Activity, Action, DecisionNode, ForkNode, JoinNode"]
    SMD["StateMachineDiagram → StateMachine, State, Transition"]
    SeqD["SequenceDiagram → Interaction, Lifeline, Message, CombinedFragment"]
    CommD["CommunicationDiagram"]
    TD["TimingDiagram"]
    IOD["InteractionOverviewDiagram"]
    BMC["ByMetaclassCategory"]
    Cls["Classifiers"]
    Rels["Relationships"]
    Beh["Behaviors"]
    Pkg["Packaging"]
    Depl["Deployment"]

    UCS --> BDT & BMC
    BDT --> SD & BD
    SD --> CD & CompD & PD & DD & CSD & OD & PrD
    BD --> UCD & AD & SMD & SeqD & CommD & TD & IOD
    BMC --> Cls & Rels & Beh & Pkg & Depl

7.2 SKOS vs OWL (Same Pattern as ArchiMate)

Following the same rationale as ArchiMate (AM-DD-1): - OWL classes (uml:Class, uml:Classifier) define what things ARE — used by SHACL shapes - SKOS concepts (umltax:ClassDiagramConcept) define how things are PRESENTED — used by tools

Linked via rdfs:seeAlso on each SKOS concept.

8. Viewpoints (uml-viewpoints.ttl)

All 14 UML diagram types are formalized as arch:Viewpoint instances:

8.1 Structural Viewpoints (7)

Viewpoint Included Concepts Purpose Concern
Class Diagram Class, Interface, DataType, Enumeration, Property, Operation Designing Structure
Object Diagram Class Informing Structure
Component Diagram Component, Interface, Port, Connector Designing Structure, Dependency
Deployment Diagram Node, Device, ExecutionEnvironment, Artifact Designing Deployment
Package Diagram Package, Model Designing Structure, Dependency
Composite Structure Diagram Class, Port, Connector, Collaboration Designing Structure
Profile Diagram Profile, Stereotype Designing Structure

8.2 Behavioral Viewpoints (7)

Viewpoint Included Concepts Purpose Concern
Use Case Diagram Actor, UseCase Informing Stakeholder, Behavior
Activity Diagram Activity, Action, ControlNode, ObjectNode, ActivityPartition Designing Behavior
State Machine Diagram StateMachine, State, Pseudostate, Region, Transition Designing Behavior
Sequence Diagram Interaction, Lifeline, Message, CombinedFragment, ExecutionSpecification Designing Behavior, Integration
Communication Diagram Interaction, Lifeline, Message Designing Behavior, Integration
Timing Diagram Interaction, Lifeline, State Designing Behavior
Interaction Overview Diagram Interaction, InteractionUse Designing Behavior

9. Reference Data (uml-reference-data.ttl)

Eight SKOS concept schemes modeling UML enumerations (ODM Annex D.3.9):

Concept Scheme UML Source Values
VisibilityKind §7.4 public (+), private (-), protected (#), package (~)
AggregationKind §9.5 none, shared, composite
ParameterDirectionKind §9.4 in, out, inout, return
MessageSort §17.4 synchCall, asynchCall, asynchSignal, createMessage, deleteMessage, reply
PseudostateKind §14.3 initial, deepHistory, shallowHistory, join, fork, junction, choice, entryPoint, exitPoint, terminate
TransitionKind §14.2 external, internal, local
InteractionOperatorKind §17.6 alt, opt, loop, break, par, seq, strict, critical, neg, assert, ignore, consider
ConnectorKind §11.2 assembly, delegation

10. Alignment (uml-alignment.ttl)

Explicit alignment axioms mapping UML metaclasses to Linked.Archi core types. This follows the same pattern as linkedarchi-bpmn-suite-alignment.ttl:

# Structural elements → arch:Element
uml:Class                rdfs:subClassOf arch:Element .
uml:Interface            rdfs:subClassOf arch:Element .
uml:Component            rdfs:subClassOf arch:Element .
uml:Node                 rdfs:subClassOf arch:Element .
uml:Actor                rdfs:subClassOf arch:Element .
uml:Activity             rdfs:subClassOf arch:Element .
uml:StateMachine         rdfs:subClassOf arch:Element .
uml:Interaction          rdfs:subClassOf arch:Element .
...

# Relationship metaclasses → arch:QualifiedRelationship
uml:Association          rdfs:subClassOf arch:QualifiedRelationship .
uml:Generalization       rdfs:subClassOf arch:QualifiedRelationship .
uml:Dependency           rdfs:subClassOf arch:QualifiedRelationship .
uml:Transition           rdfs:subClassOf arch:QualifiedRelationship .
uml:ControlFlow          rdfs:subClassOf arch:QualifiedRelationship .
...

This enables queries like ?x a arch:Element to find UML elements alongside ArchiMate, C4, and BPMN elements.

11. Cross-Language Integration

11.1 Mapping Points

UML Concept ArchiMate C4 Backstage Integration Mechanism
uml:Component am:ApplicationComponent c4:Container / c4:Component bs:Component Same IRI or owl:sameAs
uml:Interface am:ApplicationInterface — bs:API Same IRI or skos:exactMatch
uml:Node am:Node c4:DeploymentNode bs:Resource Same IRI or naming convention
uml:Actor am:BusinessActor c4:Person bs:User Same IRI or owl:sameAs
uml:Package — c4:SoftwareSystem bs:System Same IRI or naming convention
uml:Artifact am:Artifact — — Same IRI
uml:Activity am:BusinessProcess — — arch:refines or owl:sameAs

11.2 Example — Multi-Language Query

PREFIX uml:  <https://meta.linked.archi/uml/onto#>
PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX c4:   <https://meta.linked.archi/c4/onto#>
PREFIX arch: <https://meta.linked.archi/core#>

# Find all deployment targets across UML, ArchiMate, and C4
SELECT ?target ?label ?language WHERE {
    {
        ?target a uml:Node ; skos:prefLabel ?label .
        BIND("UML" AS ?language)
    } UNION {
        ?target a am:Node ; skos:prefLabel ?label .
        BIND("ArchiMate" AS ?language)
    } UNION {
        ?target a c4:DeploymentNode ; skos:prefLabel ?label .
        BIND("C4" AS ?language)
    }
}

12. Metamodel Manifest (uml-metamodel.ttl)

The manifest aggregates all resources following DD-13:

umlmm:UML2
    a                             arch:Metamodel ;
    arch:basedOnFramework         umlmm:UMLFramework ;
    arch:modelConcepts            <https://meta.linked.archi/uml/onto#> ;
    arch:formalRules              <https://meta.linked.archi/uml/shapes#> ;
    arch:formalRules              <https://meta.linked.archi/uml/suite#alignment> ;
    arch:architectureViewpoints   <https://meta.linked.archi/uml/viewpoints#> ;
    arch:conceptClassification    <https://meta.linked.archi/uml/tax#> ;
    arch:viewpointLibrary         umlvp:ViewpointCatalog ;
    arch:referenceData            <https://meta.linked.archi/uml/reference-data#> ;
.

The manifest also declares arch:Framework individuals for UML, MOF, and ODM — making the standards themselves discoverable in the knowledge graph.

13. Standards Traceability

Every class and property in the ontology carries dcterms:source pointing to the UML 2.5.1 specification. The ODM mapping rule applied is documented in skos:definition where relevant:

uml:Class
    skos:definition '''A Class classifies a set of objects and specifies the features
that characterize the structure and behavior of those objects. ...
Maps to UML 2.5.1 §11.4 Class. ODM Annex D.3.3 maps UML Class to owl:Class.'''@en ;
    dcterms:source       <https://www.omg.org/spec/UML/2.5.1/> ;
    rdfs:seeAlso    <https://www.omg.org/spec/ODM/1.1/PDF> ;
.

14. Summary — The MOF↔OWL Equivalence in Practice

This ontology demonstrates that:

  1. RDF/OWL is not a peer of UML — it is the layer below that enables UML models to participate in a knowledge graph
  2. The ODM mapping is well-defined — every MOF construct has a prescribed OWL equivalent
  3. Linked.Archi conventions extend ODM — the three-declaration pattern, SHACL shapes, and SKOS taxonomies add architecture-specific capabilities that ODM does not prescribe
  4. Cross-language integration works — because all modeling languages share the same M3 substrate (OWL), their M1 instances (RDF triples) can coexist in one graph

The relationship between the layers:

flowchart TD
    M3["RDF/OWL (M3 — representation framework)"]
    M2["uml-onto.ttl (M2 — UML metamodel expressed in OWL)"]
    M1["Model data as RDF individuals (M1 — UML model instances)"]
    M0["The real world (M0)"]

    M3 --> M2 --> M1 --> M0

This is exactly what the arch:Metamodel definition in core-onto.ttl now states: RDF/OWL is the substrate, not a sibling of UML.

15. Sequence Diagram Modeling — From UML XMI to Linked.Archi RDF

This section provides a complete worked example of how a UML sequence diagram is represented in both the OMG XMI format and the Linked.Archi RDF format, with particular attention to how temporal ordering is captured.

15.1 The Example: Login Sequence

A simple authentication flow with three participants:

sequenceDiagram
    participant User
    participant AuthService
    participant Database

    User->>AuthService: authenticate(credentials)
    AuthService->>Database: validateCredentials(credentials)
    Database-->>AuthService: result
    AuthService-->>User: authToken

15.2 UML XMI Representation

In UML 2.5.1 XMI (based on .reference/omg/uml/ptc-18-01-01.xmi), the sequence diagram is serialised as an Interaction element. Ordering is implicit in the XML document order of <fragment> elements — the fragment property is {ordered} in the metamodel:

<packagedElement xmi:type="uml:Interaction" xmi:id="login-sd" name="Login">

  <!-- Lifelines (participants) -->
  <lifeline xmi:id="ll-user" name="user" represents="User"/>
  <lifeline xmi:id="ll-auth" name="authService" represents="AuthService"/>
  <lifeline xmi:id="ll-db"   name="database" represents="Database"/>

  <!-- Fragments — ORDER MATTERS (position = temporal sequence) -->
  <!-- Message 1: authenticate (User → AuthService) -->
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos1-send" covered="ll-user" message="msg1"/>
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos1-recv" covered="ll-auth" message="msg1"/>

  <!-- Message 2: validateCredentials (AuthService → Database) -->
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos2-send" covered="ll-auth" message="msg2"/>
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos2-recv" covered="ll-db"   message="msg2"/>

  <!-- Message 3: result (Database → AuthService, reply) -->
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos3-send" covered="ll-db"   message="msg3"/>
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos3-recv" covered="ll-auth" message="msg3"/>

  <!-- Message 4: authToken (AuthService → User, reply) -->
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos4-send" covered="ll-auth" message="msg4"/>
  <fragment xmi:type="uml:MessageOccurrenceSpecification"
            xmi:id="mos4-recv" covered="ll-user" message="msg4"/>

  <!-- Messages (the arrows) -->
  <message xmi:id="msg1" name="authenticate" messageSort="synchCall"
           sendEvent="mos1-send" receiveEvent="mos1-recv"/>
  <message xmi:id="msg2" name="validateCredentials" messageSort="synchCall"
           sendEvent="mos2-send" receiveEvent="mos2-recv"/>
  <message xmi:id="msg3" name="result" messageSort="reply"
           sendEvent="mos3-send" receiveEvent="mos3-recv"/>
  <message xmi:id="msg4" name="authToken" messageSort="reply"
           sendEvent="mos4-send" receiveEvent="mos4-recv"/>
</packagedElement>

Key ordering mechanism in XMI: The <fragment> elements appear in document order. mos1-send is first (position 1), mos1-recv is second (position 2), etc. This positional ordering IS the temporal ordering. The UML spec (§17.2, ptc-18-01-01.xmi line 10078) declares Interaction::fragment as isOrdered="true".

15.3 Linked.Archi RDF Representation

In Linked.Archi, the same sequence diagram becomes RDF triples. Since RDF graphs have no inherent ordering, we use uml:sequenceNumber to capture the temporal position explicitly (see UML-DD-9):

@prefix uml:  <https://meta.linked.archi/uml/onto#> .
@prefix ref:  <https://meta.linked.archi/uml/reference-data#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:   <https://model.example.com/auth#> .

# ─── The Interaction (container) ───
ex:LoginInteraction
    a               uml:Interaction ;
    skos:prefLabel  "Login"@en ;
    uml:hasLifeline ex:ll-user, ex:ll-auth, ex:ll-db ;
    uml:hasMessage  ex:msg-authenticate, ex:msg-validate,
                    ex:msg-result, ex:msg-token ;
    uml:hasFragment ex:mos1-send, ex:mos1-recv, ex:mos2-send, ex:mos2-recv,
                    ex:mos3-send, ex:mos3-recv, ex:mos4-send, ex:mos4-recv ;
.

# ─── Lifelines (participants) ───
ex:ll-user
    a               uml:Lifeline ;
    skos:prefLabel  "user : User"@en ;
    uml:represents  ex:User ;
.

ex:ll-auth
    a               uml:Lifeline ;
    skos:prefLabel  "authService : AuthService"@en ;
    uml:represents  ex:AuthService ;
.

ex:ll-db
    a               uml:Lifeline ;
    skos:prefLabel  "database : Database"@en ;
    uml:represents  ex:Database ;
.

# ─── MessageOccurrenceSpecifications (ordered events) ───
# sequenceNumber defines the temporal ordering (equivalent to XMI document order)

ex:mos1-send a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-user ;
    uml:sequenceNumber 10 .

ex:mos1-recv a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-auth ;
    uml:sequenceNumber 20 .

ex:mos2-send a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-auth ;
    uml:sequenceNumber 30 .

ex:mos2-recv a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-db ;
    uml:sequenceNumber 40 .

ex:mos3-send a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-db ;
    uml:sequenceNumber 50 .

ex:mos3-recv a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-auth ;
    uml:sequenceNumber 60 .

ex:mos4-send a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-auth ;
    uml:sequenceNumber 70 .

ex:mos4-recv a uml:MessageOccurrenceSpecification ;
    uml:covered        ex:ll-user ;
    uml:sequenceNumber 80 .

# ─── Messages (the arrows) ───
ex:msg-authenticate
    a               uml:Message ;
    skos:prefLabel  "authenticate"@en ;
    uml:messageSort ref:SynchCall ;
    uml:sendEvent   ex:mos1-send ;
    uml:receiveEvent ex:mos1-recv ;
    uml:signature   ex:op-authenticate ;
.

ex:msg-validate
    a               uml:Message ;
    skos:prefLabel  "validateCredentials"@en ;
    uml:messageSort ref:SynchCall ;
    uml:sendEvent   ex:mos2-send ;
    uml:receiveEvent ex:mos2-recv ;
    uml:signature   ex:op-validateCredentials ;
.

ex:msg-result
    a               uml:Message ;
    skos:prefLabel  "result"@en ;
    uml:messageSort ref:Reply ;
    uml:sendEvent   ex:mos3-send ;
    uml:receiveEvent ex:mos3-recv ;
.

ex:msg-token
    a               uml:Message ;
    skos:prefLabel  "authToken"@en ;
    uml:messageSort ref:Reply ;
    uml:sendEvent   ex:mos4-send ;
    uml:receiveEvent ex:mos4-recv ;
.

15.4 How Ordering Works — Comparison

Aspect UML XMI Linked.Archi RDF
Primary ordering Document order of <fragment> elements (implicit) uml:sequenceNumber integer on each fragment (explicit)
Secondary ordering GeneralOrdering element with before/after attributes uml:GeneralOrdering instance with uml:orderingBefore/uml:orderingAfter properties
Message ordering Derived from fragment position of sendEvent Derived: ORDER BY the sequenceNumber of the sendEvent
Scope Per Interaction or InteractionOperand Per Interaction or InteractionOperand (same)
Insertion Requires rewriting XML (all subsequent elements shift) Use gaps (10, 20, 30...) — insert at 15 without renumbering

15.5 Querying Message Order in SPARQL

PREFIX uml: <https://meta.linked.archi/uml/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

# Get all messages in temporal order for a given Interaction
SELECT ?msg ?name ?sort ?fromLifeline ?toLifeline ?seq WHERE {
    <https://model.example.com/auth#LoginInteraction> uml:hasMessage ?msg .
    ?msg skos:prefLabel ?name ;
         uml:messageSort ?sortConcept ;
         uml:sendEvent ?se ;
         uml:receiveEvent ?re .
    ?sortConcept skos:prefLabel ?sort .
    ?se uml:covered ?fromLL ; uml:sequenceNumber ?seq .
    ?re uml:covered ?toLL .
    ?fromLL skos:prefLabel ?fromLifeline .
    ?toLL skos:prefLabel ?toLifeline .
}
ORDER BY ?seq

Result:

msg name sort fromLifeline toLifeline seq
ex:msg-authenticate authenticate synchCall user : User authService : AuthService 10
ex:msg-validate validateCredentials synchCall authService : AuthService database : Database 30
ex:msg-result result reply database : Database authService : AuthService 50
ex:msg-token authToken reply authService : AuthService user : User 70

15.6 Extended Example: CombinedFragment (alt)

Adding an alternative fragment for authentication success/failure:

# ─── CombinedFragment (alt) ───
ex:alt-auth-result
    a                    uml:CombinedFragment ;
    uml:interactionOperator <https://meta.linked.archi/uml/reference-data#Alt> ;
    uml:covered          ex:ll-user, ex:ll-auth, ex:ll-db ;
    uml:sequenceNumber   50 ;
    uml:hasOperand       ex:operand-success, ex:operand-failure ;
.

# ─── Operand 1: [credentials valid] ───
ex:operand-success
    a               uml:InteractionOperand ;
    uml:guard       "[credentials valid]" ;
    uml:hasFragment ex:mos-success-send, ex:mos-success-recv ;
.

ex:mos-success-send a uml:MessageOccurrenceSpecification ;
    uml:covered ex:ll-auth ; uml:sequenceNumber 10 .
ex:mos-success-recv a uml:MessageOccurrenceSpecification ;
    uml:covered ex:ll-user ; uml:sequenceNumber 20 .

ex:msg-success a uml:Message ;
    skos:prefLabel  "authToken"@en ;
    uml:messageSort <https://meta.linked.archi/uml/reference-data#Reply> ;
    uml:sendEvent   ex:mos-success-send ;
    uml:receiveEvent ex:mos-success-recv .

# ─── Operand 2: [credentials invalid] ───
ex:operand-failure
    a               uml:InteractionOperand ;
    uml:guard       "[credentials invalid]" ;
    uml:hasFragment ex:mos-failure-send, ex:mos-failure-recv ;
.

ex:mos-failure-send a uml:MessageOccurrenceSpecification ;
    uml:covered ex:ll-auth ; uml:sequenceNumber 10 .
ex:mos-failure-recv a uml:MessageOccurrenceSpecification ;
    uml:covered ex:ll-user ; uml:sequenceNumber 20 .

ex:msg-failure a uml:Message ;
    skos:prefLabel  "authError"@en ;
    uml:messageSort <https://meta.linked.archi/uml/reference-data#Reply> ;
    uml:sendEvent   ex:mos-failure-send ;
    uml:receiveEvent ex:mos-failure-recv .

Note how sequenceNumber is scoped to the container: the operands have their own numbering (10, 20) independent of the top-level Interaction's numbering.

15.7 GeneralOrdering Example

When explicit ordering between events on different lifelines is needed beyond what messages imply:

# Explicit constraint: database commit must happen before auth token is sent
ex:ordering-commit-before-token
    a                  uml:GeneralOrdering ;
    skos:prefLabel     "commit before token"@en ;
    uml:orderingBefore ex:mos-db-commit ;
    uml:orderingAfter  ex:mos4-send ;
.

This is the RDF equivalent of the UML XMI GeneralOrdering element with before and after attributes pointing to OccurrenceSpecifications.

15.8 Visual Layer — RDF-First Canvas Modelling

The RDF examples above capture UML abstract syntax — the semantic model of what participants exist, what messages are exchanged, and in what order. This is intentionally separate from diagram layout.

If the sequence diagram is authored directly on an RDF-first canvas (rather than imported from XMI), the visual state is represented separately using the Linked.Archi core visualisation vocabulary:

  • core-vis:ArchNode instances for lifeline headers, activation bars, and fragment frames
  • core-vis:Link instances for message arrows
  • core-vis:bounds / core-vis:points for layout coordinates
  • arch:viewConformsToViewpoint umlvp:SequenceDiagram to declare the diagram type

This separation follows the same principle as BPMN-DI vs BPMN abstract syntax: the semantic model (uml-onto.ttl) defines what the diagram means; the visual model (core-vis) defines how it looks. A future uml-di bridge module could map UMLDI concepts (such as UMLInteractionDiagram with kind=sequence) to the core-vis vocabulary, but this is not part of the current UML ontology scope.

See UML-DD-2 for the rationale on excluding UML Diagram Interchange from the current ontology.

OMG Standards

ISO Standards

Linked.Archi

All trademarked names (UML, MOF, ODM, BPMN, ArchiMate, TOGAF, Backstage) are property of their respective owners. See Trademark Acknowledgments for details.