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-3)
`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):

┌─────────────────────┐
│    <<component>>    │
│    OrderService     │
├─────────────────────┤
│ - maxRetries: int   │
│ + processOrder()    │
└─────────────────────┘
         △
         │ generalizes
┌─────────────────────┐
│    BaseService      │
└─────────────────────┘

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-3)

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:

arch:Element
└── uml:Element
    └── uml:NamedElement
        ├── uml:Namespace
        ├── uml:TypedElement
        ├── uml:RedefinableElement
        └── uml:PackageableElement
            └── uml:Type
                └── uml:Classifier
                    ├── uml:StructuredClassifier
                    │   └── uml:EncapsulatedClassifier
                    ├── uml:BehavioredClassifier
                    └── (concrete classifiers below)

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, CombinedFragment, InteractionOperand, InteractionUse, ExecutionSpecification	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 ;
    dc: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-6, 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-5) 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-3):

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:

arch:QualifiedRelationship
├── uml:Association
│   ├── uml:Aggregation (shared)
│   └── uml:Composition (composite)
├── uml:Generalization
├── uml:Realization
│   └── uml:InterfaceRealization
├── uml:Dependency
│   ├── uml:Usage
│   └── uml:Abstraction
├── uml:Include
├── uml:Extend
├── uml:Deployment
├── uml:PackageImport
└── uml:PackageMerge

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)¶

UMLConceptScheme
├── ByDiagramType
│   ├── StructuralDiagrams
│   │   ├── ClassDiagram → Class, Interface, DataType, Enumeration
│   │   ├── ComponentDiagram → Component, Port, Connector
│   │   ├── PackageDiagram → Package
│   │   ├── DeploymentDiagram → Node, Device, ExecutionEnvironment, Artifact
│   │   ├── CompositeStructureDiagram → Collaboration
│   │   ├── ObjectDiagram
│   │   └── ProfileDiagram → Profile, Stereotype
│   └── BehavioralDiagrams
│       ├── UseCaseDiagram → Actor, UseCase
│       ├── ActivityDiagram → Activity, Action, DecisionNode, ForkNode, JoinNode
│       ├── StateMachineDiagram → StateMachine, State, Transition
│       ├── SequenceDiagram → Interaction, Lifeline, Message, CombinedFragment
│       ├── CommunicationDiagram
│       ├── TimingDiagram
│       └── InteractionOverviewDiagram
└── ByMetaclassCategory
    ├── Classifiers
    ├── Relationships
    ├── Behaviors
    ├── Packaging
    └── Deployment

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-17:

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    umltax:UMLConceptScheme ;
    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 dc: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 ;
    dc: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:

RDF/OWL is not a peer of UML — it is the layer below that enables UML models to participate in a knowledge graph
The ODM mapping is well-defined — every MOF construct has a prescribed OWL equivalent
Linked.Archi conventions extend ODM — the three-declaration pattern, SHACL shapes, and SKOS taxonomies add architecture-specific capabilities that ODM does not prescribe
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:

RDF/OWL (M3 — representation framework)
  └── uml-onto.ttl (M2 — UML metamodel expressed in OWL)
       └── Model data as RDF individuals (M1 — UML model instances)
            └── The real world (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.

References¶

OMG Standards¶

UML 2.5.1 Specification — OMG formal/2017-12-05
MOF 2.5.1 Specification — OMG formal/2019-10-01
ODM 1.1 Specification — OMG formal/2014-09-02
XMI 2.5.1 Specification — OMG formal/2015-06-07

ISO Standards¶

ISO/IEC 19505-1:2012 — UML Infrastructure
ISO/IEC 19505-2:2012 — UML Superstructure

Linked.Archi¶

Design Decisions — DD-19: MOF↔OWL Equivalence
Design Decisions — DD-1: Metamodel as Ontology
Design Decisions — DD-2: Minimal OWL + SHACL
Design Decisions — DD-3: Qualified Relationships
Relationship Modeling Guide
UML Ontology Files
ArchiMate Deep Dive — Parallel document for ArchiMate

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