Linked.Archi UML 2.5.1 Ontology
type: Ontology
license: http://creativecommons.org/licenses/by/4.0/
created: 2025-12-01
creator: Kalin Maldzhanski
description: RDF/OWL formalization of the OMG Unified Modeling Language (UML) 2.5.1 metamodel for use in the Linked.Archi architecture knowledge graph. Covers structural classifiers (Class, Interface, Component, Package), behavioral elements (Activity, StateMachine, Interaction), deployment concepts (Node, Artifact), and use cases (Actor, UseCase). Relationship types follow the Linked.Archi three-declaration qualified relationship pattern. This ontology is INFORMED BY the OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) but does NOT apply ODM directly. ODM Annex D maps UML model instances (M1) to OWL; this ontology represents the UML metamodel itself (M2) as OWL classes so that UML model data can be typed in a knowledge graph. We adopt ODM principles (Class→owl:Class, Generalization→rdfs:subClassOf, Package→owl:Ontology) but depart from ODM for associations (three-declaration pattern), enumerations (SKOS), constraints (SHACL), and domain/range (arch:domainIncludes). See the skos:scopeNote for the full comparison. This is not an official OMG document. It is a Linked.Archi interpretation of the UML specification for semantic architecture modeling.
modified: 2026-02-01
publisher: linked.archi
publisher: Linked.Archi
source: https://www.omg.org/spec/MOF/2.5.1/
source: https://www.omg.org/spec/ODM/1.1/
source: https://www.omg.org/spec/UML/2.5.1/
status: draft
preferred namespace prefix: uml
version IRI: 0.1.0#
version info: 0.1.0
editorial note: Source materials: .reference/omg/uml/formal-17-12-05.pdf — UML 2.5.1 specification (796 pages) .reference/omg/uml/ptc-18-01-01.xmi through ptc-18-01-04.xmi — machine-readable metamodel (242 metaclasses) .reference/omg/odm/ODM-PDF.pdf — ODM 1.1 specification (362 pages) .reference/omg/odm/analysis.md — Analysis of ODM vs Linked.Archi duality .reference/omg/odm/OWLProfile.xmi, RDFProfile.xmi — UML profiles for OWL/RDF (ODM Direction 2, not used) .reference/omg/odm/OWLLibrary.xmi, RDFLibrary.xmi — OWL/RDF vocabulary as UML model libraries
history note: 0.1.0: Initial version. Covers UML 2.5.1 structural classifiers, behavioral elements, deployment, use cases, and interactions. Follows ODM mapping rules for MOF→OWL. Relationship types use the Linked.Archi three-declaration pattern.
scope note: This ontology uses OWL/RDFS to model the UML metamodel — the inverse of what ODM does. The duality: OMG Stack Linked.Archi (W3C-rooted) ───────── ──────────────────────────── M3: MOF M3: RDFS/OWL (reflective) (defines metamodels) (defines ontologies) M2: UML, BPMN, SysML, OWL M2: uml-onto.ttl (all defined using MOF) (UML metamodel expressed IN OWL) M1: UML model instances M1: RDF individuals (conform to M2) (typed with M2 classes) M0: The real world M0: The real world ODM treats MOF as the universal spine and slots OWL into it as just another M2 metamodel (alongside UML, BPMN, etc.). You author ontologies in UML tools using OWL/RDF profiles. The lingua franca is MOF/XMI; OWL is the payload. Linked.Archi does the inverse: 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. ODM primary use case (authoring OWL ontologies in UML tools) is irrelevant to this stack. What IS relevant: ODM mapping rules (Annex D) as a peer-reviewed reference for how UML constructs should surface in OWL. Where this ontology disagrees with ODM, it is deliberate (three-declaration pattern, SHACL, SKOS, arch:domainIncludes). Note on the M3 framing: The W3C stack is flatter than the four-layer MOF tower. RDFS is reflective (rdfs:Class rdf:type rdfs:Class) and does not need a separate M3 in the OMG sense. We keep the four-layer framing for didactic continuity with OMG-trained colleagues, not because it is structurally necessary. Everything is in one RDF graph; layers are a viewpoint, not a structural fact. See .reference/omg/odm/analysis.md for the full comparison.

Abstraction
type: Class
subclass of: Dependency
definition: A qualified relationship representing a UML Abstraction — a Dependency relating elements at different abstraction levels.
domain includes: Named Element
range includes: Named Element
unqualified form: Abstracts

Accept Event Action
type: Class
subclass of: Action
definition: An AcceptEventAction waits for the occurrence of one or more specific events. Maps to UML 2.5.1 §16.10 AcceptEventAction.

Action
type: Class
subclass of: Activity Node
definition: An Action is the fundamental unit of executable functionality. The execution of an Action represents some transformation or processing in the modeled system. Maps to UML 2.5.1 §16.2 Action.

Activity
type: Class
subclass of: Behavior
definition: An Activity specifies the coordination of executions of subordinate Behaviors, using a control and data flow model. Maps to UML 2.5.1 §15.2 Activity.

Activity Edge
type: Class
subclass of: QualifiedRelationship
subclass of: Redefinable Element
definition: An ActivityEdge is an abstract class for directed connections between two ActivityNodes. Maps to UML 2.5.1 §15.2 ActivityEdge.

Activity Final Node
type: Class
subclass of: Final Node
definition: An ActivityFinalNode is a FinalNode that stops all flows in an Activity. Maps to UML 2.5.1 §15.3 ActivityFinalNode.

Activity Node
type: Class
subclass of: Redefinable Element
definition: An ActivityNode is an abstract class for points in the flow of an Activity connected by ActivityEdges. Maps to UML 2.5.1 §15.2 ActivityNode.

Activity Partition
type: Class
subclass of: Named Element
definition: An ActivityPartition is a kind of ActivityGroup for identifying ActivityNodes that have some characteristic in common (swim lanes). Maps to UML 2.5.1 §15.6 ActivityPartition.

Actor
type: Class
subclass of: Behaviored Classifier
definition: An Actor specifies a role played by a user or any other system that interacts with the subject. Actors model a type of role played by an entity that interacts with the subject but which is external to it.
scope note: UML 2.5.1 §18.2: Actors may represent roles played by human users, external hardware, or other systems. An Actor does not necessarily represent a specific physical entity but a particular role of some entity relevant to the specification of its associated UseCases.

Aggregation
type: Class
subclass of: Association
definition: A qualified relationship representing a UML shared aggregation — a whole-part relationship where the part can exist independently.
domain includes: Classifier
range includes: Classifier
unqualified form: Aggregates

Artifact
type: Class
subclass of: Classifier
subclass of: Deployment Target
definition: An Artifact is the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of Artifacts include model files, source files, scripts, and binary executable files.
scope note: UML 2.5.1 §19.5.1: "An artifact is the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system." An Artifact is the source of a Deployment to a Node.

Association
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Association — a structural relationship between Classifiers that specifies connections among their instances. Maps to UML 2.5.1 §11.5 Association.
domain includes: Classifier
range includes: Classifier
unqualified form: Associated With

Behavior
type: Class
subclass of: Class
definition: A Behavior is a specification of how its context BehavioredClassifier changes state over time. It is the abstract base for Activity, StateMachine, Interaction, and OpaqueBehavior. Maps to UML 2.5.1 §13.2 Behavior.

Behavior Execution Specification
type: Class
subclass of: Execution Specification
definition: A BehaviorExecutionSpecification is an ExecutionSpecification that represents the execution of a Behavior (as opposed to an opaque action). It references the Behavior being executed. Maps to UML 2.5.1 §17.5 BehaviorExecutionSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="BehaviorExecutionSpecification").

Behaviored Classifier
type: Class
subclass of: Classifier
definition: A Classifier that may have InterfaceRealizations and owned Behaviors. Maps to UML 2.5.1 §10.5 BehavioredClassifier.

Call Action
type: Class
subclass of: Action
definition: A CallAction is an Action that invokes a Behavior or Operation. Maps to UML 2.5.1 §16.3 CallAction.

Class
subclass of: Behaviored Classifier
subclass of: Encapsulated Classifier
definition: A Class is a kind of EncapsulatedClassifier whose Features are Properties, Operations, Receptions, Ports, and Connectors. A Class may have attributes (Properties owned by the Class), some of which may represent the ends of binary Associations.
scope note: UML 2.5.1 §11.4.3: "Class is a kind of EncapsulatedClassifier whose Features are Properties, Operations, Receptions, Ports and Connectors." Objects of a Class must contain values for each attribute that is a member of that Class, in accordance with the characteristics of the attribute (type, multiplicity).

Classifier
type: Class
subclass of: Namespace
subclass of: Redefinable Element
subclass of: Type
definition: A Classifier represents a classification of instances according to their features. It is the abstract base for Class, Interface, DataType, Component, and other concrete classifiers. Maps to UML 2.5.1 §9.2 Classifier. ODM maps MOF::Class to owl:Class; Classifier is the UML-level abstraction.

Collaboration
type: Class
subclass of: Behaviored Classifier
subclass of: Structured Classifier
definition: A Collaboration defines a set of cooperating roles and their connectors. It represents a pattern of interaction. Maps to UML 2.5.1 §11.7 Collaboration.

Collaboration Use
type: Class
subclass of: Named Element
definition: A CollaborationUse represents the application of a pattern described by a Collaboration to a specific situation. Maps to UML 2.5.1 §11.7 CollaborationUse.

Combined Fragment
type: Class
subclass of: Interaction Fragment
definition: A CombinedFragment defines an expression of InteractionFragments governed by an interaction operator. The operator (alt, opt, loop, break, par, seq, strict, critical, neg, assert, ignore, consider) determines the semantics of how the contained InteractionOperands are combined. A CombinedFragment is the mechanism for expressing control flow (conditionals, loops, parallelism) within a sequence diagram. Maps to UML 2.5.1 §17.6 CombinedFragment. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="CombinedFragment").
example: An "alt" fragment for login success/failure: ex:alt-login a uml:CombinedFragment ; uml:interactionOperator <https://meta.linked.archi/uml/reference-data#Alt> ; uml:hasOperand ex:operand-success, ex:operand-failure ; uml:sequenceNumber 5 .
scope note: UML 2.5.1 §17.6.1: "A CombinedFragment defines an expression of InteractionFragments. A CombinedFragment is defined by an interaction operator and corresponding InteractionOperands. Through the use of CombinedFragments the user will be able to describe a number of traces in a compact and concise manner." Key properties: - interactionOperator : InteractionOperatorKind — the operator (alt, opt, loop, etc.) - operand : InteractionOperand [1..*] {ordered, composite} — the operands - cfragmentGate : Gate [0..*] {composite} — gates for messages crossing the boundary Constraint: if interactionOperator is break, the operand must cover all Lifelines covered by the enclosing InteractionFragment.

Comment
type: Class
subclass of: Element
definition: A textual annotation attached to a set of elements. Maps to UML 2.5.1 §7.2 Comment.

Communication Path
type: Class
subclass of: Element
definition: A CommunicationPath is an association between two DeploymentTargets, through which they are able to exchange signals and messages. Maps to UML 2.5.1 §19.4 CommunicationPath.

Component
type: Class
subclass of: Class
definition: A Component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components or services in the system in terms of its provided and required Interfaces.
scope note: UML 2.5.1 §11.6.3: "A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers. A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality based on compatibility of its Interfaces." A Component may be manifested by one or more Artifacts, and that Artifact may be deployed to its execution environment.

Composition
type: Class
subclass of: Association
definition: A qualified relationship representing a UML composite aggregation — a strong whole-part relationship where the part cannot exist without the whole.
domain includes: Classifier
range includes: Classifier
unqualified form: Composed Of

Connector
type: Class
subclass of: Feature
definition: A Connector specifies links that enable communication between two or more instances. Each Connector may be attached to two or more ConnectableElements (Ports, Properties). Maps to UML 2.5.1 §11.2 Connector.

Connector End
type: Class
subclass of: Element
definition: A ConnectorEnd is an endpoint of a Connector, which attaches the Connector to a ConnectableElement. Maps to UML 2.5.1 §11.2 ConnectorEnd.

Constraint
type: Class
subclass of: Packageable Element
definition: A condition or restriction expressed in natural language or in a machine-readable language for the purpose of declaring some of the semantics of an element. Maps to UML 2.5.1 §7.6 Constraint.

Continuation
type: Class
subclass of: Interaction Fragment
definition: A Continuation is an InteractionFragment that defines a continuation label within a CombinedFragment with operator "alt". Continuations always occur as the very first or very last InteractionFragment of the enclosing InteractionOperand, and are global (cover all Lifelines covered by the enclosing operator). Maps to UML 2.5.1 §17.6 Continuation. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Continuation").

Control Flow
type: Class
subclass of: Activity Edge
definition: A ControlFlow is an ActivityEdge traversed by control tokens only. Maps to UML 2.5.1 §15.2 ControlFlow.

Control Node
type: Class
subclass of: Activity Node
definition: A ControlNode is an abstract ActivityNode used to coordinate the flows between other nodes. Maps to UML 2.5.1 §15.3 ControlNode.

Data Type
type: Class
subclass of: Classifier
definition: A DataType is a type whose instances are identified only by their value. Maps to UML 2.5.1 §10.2 DataType. ODM Annex D.2.4 (Table D.10) maps to rdfs:Datatype or owl:Class depending on whether it has structural features.

Decision Node
type: Class
subclass of: Control Node
definition: A DecisionNode is a ControlNode that chooses between outgoing flows. Maps to UML 2.5.1 §15.3 DecisionNode.

Dependency
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Dependency — a supplier/client relationship where changes to the supplier may affect the client.
domain includes: Named Element
range includes: Named Element
unqualified form: Depends On

Deployment
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Deployment — an Artifact is deployed on a DeploymentTarget (Node, Device, ExecutionEnvironment).
domain includes: Artifact
range includes: Deployment Target
unqualified form: Deployed On

Deployment Specification
type: Class
subclass of: Artifact
definition: A DeploymentSpecification specifies a set of properties that determine execution parameters of a component artifact deployed on a node. Maps to UML 2.5.1 §19.3 DeploymentSpecification.

Deployment Target
type: Class
subclass of: Named Element
definition: A DeploymentTarget is the general concept of a location in which a DeployedArtifact can be deployed. Maps to UML 2.5.1 §19.2 DeploymentTarget.

Destruction Occurrence Specification
type: Class
subclass of: Message Occurrence Specification
definition: A DestructionOccurrenceSpecification models the destruction of an object. It is shown as an X at the bottom of a Lifeline. No other OccurrenceSpecifications on the same Lifeline may appear below a DestructionOccurrenceSpecification within the same InteractionOperand. Maps to UML 2.5.1 §17.4 DestructionOccurrenceSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="DestructionOccurrenceSpecification").

Device
type: Class
subclass of: Node
definition: A Device is a physical computational resource with processing capability upon which artifacts may be deployed. Maps to UML 2.5.1 §19.4 Device.

Element
type: Class
subclass of: Element
definition: The root metaclass for all UML model elements. Maps to UML 2.5.1 §7.2 Element. In the ODM mapping, this corresponds to the root MOF::Element mapped to owl:Class.

Encapsulated Classifier
type: Class
subclass of: Structured Classifier
definition: A StructuredClassifier that may have Ports. Maps to UML 2.5.1 §11.2 EncapsulatedClassifier.

Enumeration
type: Class
subclass of: Data Type
definition: An Enumeration is a DataType whose values are enumerated in the model as EnumerationLiterals. Maps to UML 2.5.1 §10.2 Enumeration. In Linked.Archi, enumeration values are modeled as SKOS concepts in the reference data (see DD-5).

Enumeration Literal
type: Class
subclass of: Named Element
definition: A user-defined data value for an Enumeration. Maps to UML 2.5.1 §10.2 EnumerationLiteral.

Event
type: Class
subclass of: Packageable Element
definition: An Event is the specification of some occurrence that may potentially trigger effects by an object. Maps to UML 2.5.1 §13.3 Event.

Execution Environment
type: Class
subclass of: Node
definition: An ExecutionEnvironment is a Node that offers an execution environment for specific types of components that are deployed on it in the form of executable artifacts. Maps to UML 2.5.1 §19.4 ExecutionEnvironment.

Execution Occurrence Specification
type: Class
subclass of: Occurrence Specification
definition: An ExecutionOccurrenceSpecification represents moments in time at which Actions or Behaviors start or finish. It is the concrete OccurrenceSpecification subclass used as the start and finish points of an ExecutionSpecification (activation bar). Unlike MessageOccurrenceSpecification (which represents message send/receive), ExecutionOccurrenceSpecification represents the beginning or end of an execution period on a Lifeline. Maps to UML 2.5.1 §17.5 ExecutionOccurrenceSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="ExecutionOccurrenceSpecification").
scope note: UML 2.5.1 §17.5.2: "An ExecutionOccurrenceSpecification represents moments in time at which Actions or Behaviors start or finish." Key property: - execution : ExecutionSpecification [1] — the execution that starts or finishes here This class allows distinguishing execution start/finish occurrences from message send/receive occurrences in the fragment ordering. The executionStart and executionFinish properties on ExecutionSpecification typically point to instances of this class.

Execution Specification
type: Class
subclass of: Interaction Fragment
definition: An ExecutionSpecification is a specification of the execution of a unit of Behavior or Action within a Lifeline. It is depicted as the activation bar (thin rectangle) on a Lifeline in a sequence diagram. An ExecutionSpecification has a start OccurrenceSpecification and a finish OccurrenceSpecification that delimit the period during which the Lifeline is actively executing. Maps to UML 2.5.1 §17.5 ExecutionSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="ExecutionSpecification").
scope note: UML 2.5.1 §17.5.1: "An ExecutionSpecification is a specification of the execution of a unit of Behavior or Action within the Lifeline." Key properties: - start : OccurrenceSpecification [1] — the occurrence starting the execution - finish : OccurrenceSpecification [1] — the occurrence ending the execution The start and finish OccurrenceSpecifications are typically the receiveEvent of an incoming message and the sendEvent of the reply message, respectively. Nested ExecutionSpecifications represent nested calls (stacked activation bars).

Extend
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Extend — an extending UseCase conditionally augments the behavior of an extended UseCase.
domain includes: Use Case
range includes: Use Case
unqualified form: Extends

Extension Point
type: Class
subclass of: Redefinable Element
definition: An ExtensionPoint identifies a point in the behavior of a UseCase where that behavior can be extended by the behavior of some other UseCase. Maps to UML 2.5.1 §18.2 ExtensionPoint.

Feature
type: Class
subclass of: Redefinable Element
definition: A Feature declares a behavioral or structural characteristic of Classifiers. Maps to UML 2.5.1 §9.4 Feature.

Final Node
type: Class
subclass of: Control Node
definition: A FinalNode is an abstract ControlNode at which a flow in an Activity stops. Maps to UML 2.5.1 §15.3 FinalNode.

Final State
type: Class
subclass of: State
definition: A FinalState represents the completion of activity in the enclosing Region. Maps to UML 2.5.1 §14.2 FinalState.

Flow Final Node
type: Class
subclass of: Final Node
definition: A FlowFinalNode is a FinalNode that terminates a flow without terminating the overall Activity. Maps to UML 2.5.1 §15.3 FlowFinalNode.

Fork Node
type: Class
subclass of: Control Node
definition: A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. Maps to UML 2.5.1 §15.3 ForkNode.

Function Behavior
type: Class
subclass of: Opaque Behavior
definition: A FunctionBehavior is an OpaqueBehavior that does not access or modify any objects or other external data. Maps to UML 2.5.1 §13.2 FunctionBehavior.

Gate
type: Class
subclass of: Message End
definition: A Gate is a MessageEnd that serves as a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment. Gates are used at the boundary of Interactions (formalGate) and CombinedFragments (cfragmentGate) to allow Messages to cross those boundaries, and at InteractionUse boundaries (actualGate) to bind to the referenced Interaction's formalGates. Maps to UML 2.5.1 §17.4 Gate. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Gate").
scope note: UML 2.5.1 §17.4.5: "A Gate is a MessageEnd which serves as a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment." Gates enable modular composition: - formalGate (on Interaction) — the "interface" of a reusable Interaction - actualGate (on InteractionUse) — binds to formalGates when referencing - cfragmentGate (on CombinedFragment) — allows messages to enter/exit the fragment

General Ordering
type: Class
subclass of: Named Element
definition: A GeneralOrdering represents a binary relation between two OccurrenceSpecifications, to describe that one OccurrenceSpecification must occur before the other in a valid trace. This mechanism provides the ability to define partial orders of OccurrenceSpecifications that may otherwise not have a specified order — for example, events on different Lifelines that are not connected by a Message but must still be ordered. Maps to UML 2.5.1 §17.3 GeneralOrdering. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="GeneralOrdering").
editorial note: In UML XMI, GeneralOrdering has two properties: - before : OccurrenceSpecification [1] — the occurrence that must happen first - after : OccurrenceSpecification [1] — the occurrence that must happen second In Linked.Archi RDF, these are modeled as :orderingBefore and :orderingAfter object properties on the GeneralOrdering instance. See .reference/omg/uml/ptc-18-01-01.xmi lines 9928–9963.
scope note: UML 2.5.1 §17.3.4: "A GeneralOrdering represents a binary relation between two OccurrenceSpecifications, to describe that one OccurrenceSpecification must occur before the other in a valid trace. This mechanism provides the ability to define partial orders of OccurrenceSpecifications that may otherwise not have a specified order." Constraint: the transitive closure of GeneralOrderings must be irreflexive (no cycles). GeneralOrdering is owned by an InteractionFragment (via the generalOrdering composite property). It is the secondary ordering mechanism — the primary mechanism is the position (sequenceNumber) of fragments in the Interaction::fragment ordered list. GeneralOrdering is used when: 1. Events on different Lifelines need explicit ordering beyond what Messages imply 2. Partial orders need to be expressed (not all events are totally ordered) 3. Tools need to record ordering constraints that are not captured by the linear list

Generalization
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Generalization — a taxonomic relationship from specific to general Classifier.
domain includes: Classifier
range includes: Classifier
unqualified form: Generalizes

Include
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Include — a base UseCase incorporates the behavior of an included UseCase.
domain includes: Use Case
range includes: Use Case
unqualified form: Includes

Information Flow
type: Class
subclass of: QualifiedRelationship
subclass of: Element
definition: An InformationFlow specifies that one or more information items circulate from its sources to its targets. Maps to UML 2.5.1 §20.2 InformationFlow.

Information Item
type: Class
subclass of: Classifier
definition: An InformationItem represents an abstraction of data that can be conveyed between two entities. Maps to UML 2.5.1 §20.2 InformationItem.

Initial Node
type: Class
subclass of: Control Node
definition: An InitialNode is a ControlNode at which flow starts when the Activity is invoked. Maps to UML 2.5.1 §15.3 InitialNode.

Interaction
type: Class
subclass of: Behavior
subclass of: Interaction Fragment
definition: An Interaction is a unit of Behavior that focuses on the observable exchange of information between connectable elements. It owns an ordered set of InteractionFragments (the fragment property), a set of Lifelines (the participants), and a set of Messages (the communications). An Interaction is itself an InteractionFragment, allowing nesting. Maps to UML 2.5.1 §17.2 Interaction. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Interaction").
example: A "Login" sequence diagram is modeled as: 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 .
scope note: UML 2.5.1 §17.2.1: "An Interaction is a unit of Behavior that focuses on the observable exchange of information between connectable elements." Interactions are the semantic foundation for Sequence Diagrams, Communication Diagrams, Timing Diagrams, and Interaction Overview Diagrams. The Interaction owns: - lifeline [0..*] {composite} — the participants - message [0..*] {composite} — the communications - fragment [0..*] {ordered, composite} — the temporal ordering of events - formalGate [0..*] {composite} — gates for InteractionUse binding - action [0..*] {composite} — actions owned by the Interaction An Interaction instance must not be contained within another Interaction instance (constraint: not_contained).

Interaction Constraint
type: Class
subclass of: Constraint
definition: An InteractionConstraint is a Boolean expression that guards an operand in a CombinedFragment. It determines whether the InteractionOperand is executed. For loop CombinedFragments, it may also specify minint and maxint bounds. Maps to UML 2.5.1 §17.6 InteractionConstraint. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionConstraint").
scope note: UML 2.5.1 §17.6.4: "An InteractionConstraint is a Boolean expression that guards an operand in a CombinedFragment." Key properties: - minint : ValueSpecification [0..1] — minimum iterations (loop only) - maxint : ValueSpecification [0..1] — maximum iterations (loop only) Constraints: - minint/maxint can only be present if the enclosing CombinedFragment is a loop - minint must evaluate to a non-negative integer - maxint must evaluate to a positive integer >= minint - The guard must contain only references to values local to the covered Lifeline or values global to the whole Interaction

Interaction Fragment
type: Class
subclass of: Named Element
definition: InteractionFragment is the abstract base metaclass for all elements that can appear in the ordered fragment list of an Interaction or InteractionOperand. Every InteractionFragment is conceptually like an Interaction by itself — it covers one or more Lifelines and occupies a position in the temporal ordering of the enclosing Interaction. Concrete subclasses include OccurrenceSpecification, CombinedFragment, InteractionUse, ExecutionSpecification, and StateInvariant. Maps to UML 2.5.1 §17.3 InteractionFragment. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionFragment").
editorial note: Key properties from the UML metamodel: - covered : Lifeline [0..*] — the lifelines this fragment involves - enclosingInteraction : Interaction [0..1] — the owning Interaction - enclosingOperand : InteractionOperand [0..1] — the owning operand (if nested) - generalOrdering : GeneralOrdering [0..*] {composite} — explicit ordering constraints See .reference/omg/uml/ptc-18-01-01.xmi lines 10157–10215.
scope note: UML 2.5.1 §17.3.1: "InteractionFragment is an abstract notion of the most general interaction unit. An InteractionFragment is a piece of an Interaction. Each InteractionFragment is conceptually like an Interaction by itself." The fragment list on Interaction and InteractionOperand is {ordered} — the position in the list defines the top-to-bottom temporal ordering in a sequence diagram. In RDF (which has no inherent document order), this ordering is captured via the :sequenceNumber datatype property on each fragment instance.

Interaction Operand
type: Class
subclass of: Interaction Fragment
subclass of: Namespace
definition: An InteractionOperand is contained in a CombinedFragment and represents one operand of the expression given by the enclosing CombinedFragment. It owns an ordered set of InteractionFragments (its own fragment list) and may have a guard (InteractionConstraint) that determines whether the operand is executed. Maps to UML 2.5.1 §17.6 InteractionOperand. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionOperand").
scope note: UML 2.5.1 §17.6.3: "An InteractionOperand is contained in a CombinedFragment. An InteractionOperand represents one operand of the expression given by the enclosing CombinedFragment." Key properties: - fragment : InteractionFragment [0..*] {ordered, composite} — nested fragments - guard : InteractionConstraint [0..1] {composite} — the guard condition The fragment property is {ordered} — the position of fragments within an operand defines their temporal ordering, just as in the top-level Interaction. In RDF, this is captured via :sequenceNumber on each nested fragment.

Interaction Use
type: Class
subclass of: Interaction Fragment
definition: An InteractionUse refers to another Interaction. It is a means of copying a portion of the referred Interaction into the enclosing Interaction — the "ref" fragment in sequence diagram notation. InteractionUse enables modular composition of interactions by referencing reusable sub-sequences. Maps to UML 2.5.1 §17.7 InteractionUse. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionUse").
scope note: UML 2.5.1 §17.7.1: "An InteractionUse refers to an Interaction. The InteractionUse is a shorthand for copying the contents of the referred Interaction where the InteractionUse is." Key properties: - refersTo : Interaction [1] — the referenced Interaction - actualGate : Gate [0..*] {composite} — gates binding to the referred formalGates - argument : ValueSpecification [0..*] {ordered, composite} — actual arguments - returnValue : ValueSpecification [0..1] — the return value In a sequence diagram, an InteractionUse appears as a frame labeled "ref" with the name of the referenced Interaction.

Interface
type: Class
subclass of: Classifier
definition: An Interface is a kind of Classifier that represents a declaration of a set of public Features and obligations that together constitute a coherent service. An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract.
scope note: UML 2.5.1 §10.4.3: "An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract. The obligations associated with an Interface are in the form of constraints (such as pre- and postconditions) or protocol specifications." Interfaces may not be instantiated directly.

Interface Realization
type: Class
subclass of: Realization
definition: A qualified relationship representing a UML InterfaceRealization — a BehavioredClassifier fulfills the contract of an Interface.
domain includes: Behaviored Classifier
range includes: Interface
unqualified form: Realizes Interface

Join Node
type: Class
subclass of: Control Node
definition: A JoinNode is a ControlNode that synchronizes multiple flows. Maps to UML 2.5.1 §15.3 JoinNode.

Lifeline
type: Class
subclass of: Named Element
definition: A Lifeline represents an individual participant in the Interaction. While parts and structural features may have multiplicity greater than 1, Lifelines represent only one interacting entity. A Lifeline is depicted as a vertical dashed line with a header box showing the participant name and type. It references a ConnectableElement (Property, Port, Parameter) within the classifier that contains the enclosing Interaction. Maps to UML 2.5.1 §17.3 Lifeline. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Lifeline").
scope note: UML 2.5.1 §17.3.1: "A Lifeline represents an individual participant in the Interaction. While parts and structural features may have multiplicity greater than 1, Lifelines represent only one interacting entity." Key properties: - represents : ConnectableElement [0..1] — what the lifeline stands for - interaction : Interaction [1] — the owning Interaction - coveredBy : InteractionFragment [0..*] — fragments covering this lifeline - selector : ValueSpecification [0..1] — index if represents is multivalued - decomposedAs : PartDecomposition [0..1] — decomposition reference The coveredBy association is the inverse of InteractionFragment::covered — it links a Lifeline to all the OccurrenceSpecifications and other fragments that occur on it. The ordering of events on a Lifeline is determined by the sequenceNumber of the OccurrenceSpecifications that cover it.

Manifestation
type: Class
subclass of: Element
definition: A Manifestation is the concrete physical rendering of one or more model elements by an artifact. Maps to UML 2.5.1 §19.3 Manifestation.

Merge Node
type: Class
subclass of: Control Node
definition: A MergeNode is a ControlNode that brings together multiple alternate flows without synchronization. Maps to UML 2.5.1 §15.3 MergeNode.

Message
type: Class
subclass of: Named Element
definition: A Message defines a particular communication between Lifelines of an Interaction. Each Message has a sendEvent and a receiveEvent (both MessageEnd instances), a messageSort indicating the type of communication (synchCall, asynchCall, asynchSignal, createMessage, deleteMessage, reply), and an optional signature referencing the Operation or Signal being invoked. Messages are the arrows in a sequence diagram. Maps to UML 2.5.1 §17.4 Message. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message").
editorial note: Message ordering in a sequence diagram is NOT a property of the Message itself — it is determined by the position (sequenceNumber) of the MessageOccurrenceSpecifications that serve as its sendEvent and receiveEvent within the Interaction::fragment ordered collection. Message M1 precedes M2 if M1.sendEvent.sequenceNumber < M2.sendEvent.sequenceNumber. See UML-DD-9 in design-decisions.md for the full rationale.
scope note: UML 2.5.1 §17.4.3: "A Message defines a particular communication between Lifelines of an Interaction." Key properties: - sendEvent : MessageEnd [0..1] — the sending occurrence (on the source lifeline) - receiveEvent : MessageEnd [0..1] — the receiving occurrence (on the target lifeline) - messageSort : MessageSort — synchCall (default), asynchCall, asynchSignal, createMessage, deleteMessage, reply - messageKind : MessageKind {derived} — complete, lost, found, or unknown - signature : NamedElement [0..1] — the Operation or Signal - argument : ValueSpecification [0..*] {ordered, composite} — message arguments - connector : Connector [0..1] — the connector carrying the message - interaction : Interaction [1] — the owning Interaction Ordering constraint: "If the sendEvent and the receiveEvent of the same Message are on the same Lifeline, the sendEvent must be ordered before the receiveEvent." Messages cannot cross boundaries of CombinedFragments or their operands.

Message End
type: Class
subclass of: Named Element
definition: MessageEnd is an abstract specialization of NamedElement that represents what can occur at the end of a Message. A MessageEnd is either a MessageOccurrenceSpecification (on a Lifeline) or a Gate (at an Interaction or CombinedFragment boundary). The sendEvent and receiveEvent properties of Message point to MessageEnd instances. Maps to UML 2.5.1 §17.4 MessageEnd. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="MessageEnd").
scope note: UML 2.5.1 §17.4.3: "MessageEnd is an abstract specialization of NamedElement that represents what can occur at the end of a Message." The two concrete subclasses are MessageOccurrenceSpecification (the common case — a point on a Lifeline) and Gate (a message endpoint at the boundary of an Interaction or CombinedFragment, used for InteractionUse and CombinedFragment gates).

Message Occurrence Specification
type: Class
subclass of: Message End
subclass of: Occurrence Specification
definition: A MessageOccurrenceSpecification represents the sending or receiving of a Message on a specific Lifeline. It is both an OccurrenceSpecification (a point in time on a Lifeline) and a MessageEnd (an endpoint of a Message). This dual inheritance is the key structural element that connects Messages to the temporal ordering: the sequenceNumber of the MessageOccurrenceSpecification determines when the send or receive occurs relative to other events on the same Lifeline. Maps to UML 2.5.1 §17.4 MessageOccurrenceSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="MessageOccurrenceSpecification").
example: For a synchronous call "authenticate" from User to AuthService: ex:mos1-send a uml:MessageOccurrenceSpecification ; uml:covered ex:ll-user ; uml:sequenceNumber 1 . ex:mos1-recv a uml:MessageOccurrenceSpecification ; uml:covered ex:ll-auth ; uml:sequenceNumber 2 . ex:msg-authenticate uml:sendEvent ex:mos1-send ; uml:receiveEvent ex:mos1-recv .
scope note: UML 2.5.1 §17.4.4: A MessageOccurrenceSpecification inherits from both OccurrenceSpecification and MessageEnd. It covers exactly one Lifeline (from OccurrenceSpecification) and references exactly one Message (from MessageEnd). In a sequence diagram, each message arrow has two MessageOccurrenceSpecifications: one at the tail (sendEvent) and one at the arrowhead (receiveEvent). Their positions in the Interaction::fragment ordered list define the temporal ordering.

Model
type: Class
subclass of: Package
definition: A Model is a Package that contains a complete description of the modeled system from a particular viewpoint. Maps to UML 2.5.1 §12.2 Model.

Named Element
type: Class
subclass of: Element
definition: An element that has a name and visibility within a namespace. Maps to UML 2.5.1 §7.4 NamedElement.

Namespace
type: Class
subclass of: Named Element
definition: A named element that can own other named elements, providing a naming scope. Maps to UML 2.5.1 §7.4 Namespace.

Node
type: Class
subclass of: Class
subclass of: Deployment Target
definition: A Node is a computational resource upon which Artifacts may be deployed, via Deployment relationships, for execution. Nodes can be interconnected through communication paths.
scope note: UML 2.5.1 §19.4.3: "A Node is computational resource upon which Artifacts may be deployed, via Deployment relationships, for execution. For advanced modeling applications, Nodes may have complex internal structure defined by nested Nodes." Nodes form a deployment topology.

Object Flow
type: Class
subclass of: Activity Edge
definition: An ObjectFlow is an ActivityEdge that can have objects or data passing along it. Maps to UML 2.5.1 §15.2 ObjectFlow.

Object Node
type: Class
subclass of: Activity Node
subclass of: Typed Element
definition: An ObjectNode is an ActivityNode that indicates an instance of a particular Classifier, possibly in a particular state, may be available at a particular point in the Activity. Maps to UML 2.5.1 §15.4 ObjectNode.

Occurrence Specification
type: Class
subclass of: Interaction Fragment
definition: An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions. Each OccurrenceSpecification covers exactly one Lifeline and represents a single point in time on that Lifeline — typically the sending or receiving of a Message, or the start/finish of an ExecutionSpecification. Maps to UML 2.5.1 §17.4 OccurrenceSpecification. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="OccurrenceSpecification").
editorial note: Key properties: - covered : Lifeline [1] — redefines InteractionFragment::covered to exactly one - toAfter : GeneralOrdering [0..*] — orderings where this is the "before" element - toBefore : GeneralOrdering [0..*] — orderings where this is the "after" element See .reference/omg/uml/ptc-18-01-01.xmi lines 10986–11035.
scope note: UML 2.5.1 §17.4.1: "An OccurrenceSpecification is the basic semantic unit of Interactions. The sequences of occurrences specified by them are the meanings of Interactions." OccurrenceSpecifications are ordered along a Lifeline — this ordering (combined with GeneralOrdering constraints) defines the valid traces of the Interaction. In the XMI serialisation, ordering is implicit in the position within the {ordered} fragment collection. In Linked.Archi RDF, ordering is explicit via :sequenceNumber.

Opaque Behavior
type: Class
subclass of: Behavior
definition: An OpaqueBehavior is a Behavior whose specification is given in a textual language other than UML. Maps to UML 2.5.1 §13.2 OpaqueBehavior.

Operation
type: Class
subclass of: Feature
subclass of: Namespace
definition: A behavioral feature of a Classifier that specifies the name, type, parameters, and constraints for invoking an associated Behavior. Maps to UML 2.5.1 §9.6 Operation.

Package
type: Class
subclass of: Namespace
subclass of: Packageable Element
definition: A Package is used to group elements and provides a namespace for the grouped elements. Maps to UML 2.5.1 §12.2 Package. ODM Annex D.3.2 maps MOF::Package to owl:Ontology.

Package Import
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML PackageImport.
domain includes: Namespace
range includes: Package
unqualified form: Imports Package

Package Merge
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML PackageMerge.
domain includes: Package
range includes: Package
unqualified form: Merges Package

Packageable Element
type: Class
subclass of: Named Element
definition: A named element that may be owned directly by a Package. Maps to UML 2.5.1 §7.4 PackageableElement.

Parameter
type: Class
subclass of: Typed Element
definition: A specification of an argument used to pass information into or out of an invocation of a BehavioralFeature. Maps to UML 2.5.1 §9.4 Parameter.

Port
type: Class
subclass of: Property
definition: A Port is a property of an EncapsulatedClassifier that specifies a distinct interaction point between the classifier and its environment or between the classifier and its internal parts. Maps to UML 2.5.1 §11.3 Port.

Primitive Type
type: Class
subclass of: Data Type
definition: A PrimitiveType defines a predefined DataType without any substructure. Typical examples are Integer, Boolean, String, and UnlimitedNatural. Maps to UML 2.5.1 §10.2 PrimitiveType.

Profile
type: Class
subclass of: Package
definition: A Profile defines limited extensions to a reference metamodel with the purpose of adapting the metamodel to a specific platform or domain. Maps to UML 2.5.1 §12.3 Profile.

Profile Application
type: Class
subclass of: Element
definition: A ProfileApplication is used to show which Profiles have been applied to a Package. Maps to UML 2.5.1 §12.3 ProfileApplication.

Property
type: Class
subclass of: Structural Feature
definition: A Property is a StructuralFeature that represents an attribute of a Classifier or an end of an Association. Maps to UML 2.5.1 §9.5 Property. ODM Annex D.3.4 maps UML Property to owl:DatatypeProperty (for attributes) or owl:ObjectProperty (for association ends).

Pseudostate
type: Class
subclass of: Vertex
definition: A Pseudostate is an abstraction that encompasses different types of transient Vertices in the StateMachine graph (initial, choice, junction, fork, join, etc.). Maps to UML 2.5.1 §14.3 Pseudostate.

Realization
type: Class
subclass of: QualifiedRelationship
definition: A qualified relationship representing a UML Realization — a relationship between a specification and its implementation.
domain includes: Classifier
range includes: Classifier
unqualified form: Realizes

Redefinable Element
type: Class
subclass of: Named Element
definition: An element that, when defined in the context of a classifier, can be redefined more specifically in the context of another classifier that specializes the first. Maps to UML 2.5.1 §7.6 RedefinableElement.

Region
type: Class
subclass of: Namespace
definition: A Region is a top-level part of a StateMachine or a composite State, containing States and Transitions. Maps to UML 2.5.1 §14.2 Region.

Send Signal Action
type: Class
subclass of: Action
definition: A SendSignalAction creates a Signal instance and transmits it to the target object. Maps to UML 2.5.1 §16.3 SendSignalAction.

Signal
type: Class
subclass of: Classifier
definition: A Signal is a specification of a kind of communication between objects in which a reaction is asynchronously triggered in the receiver without a reply. Maps to UML 2.5.1 §10.3 Signal.

State
type: Class
subclass of: Namespace
subclass of: Vertex
definition: A State models a situation during which some invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event. Maps to UML 2.5.1 §14.2 State.

State Invariant
type: Class
subclass of: Interaction Fragment
definition: A StateInvariant is a runtime constraint on the participants of the Interaction. It specifies a condition that must hold at the point in time where the StateInvariant appears on a Lifeline. It covers exactly one Lifeline. Maps to UML 2.5.1 §17.8 StateInvariant. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="StateInvariant").
scope note: UML 2.5.1 §17.8.1: "A StateInvariant is a runtime constraint on the participants of the Interaction." Key properties: - invariant : Constraint [1] {composite} — the constraint expression - covered : Lifeline [1] — redefines InteractionFragment::covered to exactly one In a sequence diagram, a StateInvariant is shown as a state symbol or constraint notation on a Lifeline between two OccurrenceSpecifications.

State Machine
type: Class
subclass of: Behavior
definition: A StateMachine specifies the behavior of a part of a system through a finite state-transition system. Maps to UML 2.5.1 §14.2 StateMachine.

Stereotype
type: Class
subclass of: Class
definition: A Stereotype defines how an existing metaclass may be extended as part of a Profile. Maps to UML 2.5.1 §12.3 Stereotype. In the ODM mapping, stereotypes become OWL classes that extend the stereotyped metaclass via rdfs:subClassOf.

Structural Feature
type: Class
subclass of: Feature
subclass of: Typed Element
definition: A typed feature of a Classifier that specifies the structure of instances. Maps to UML 2.5.1 §9.4 StructuralFeature.

Structured Classifier
type: Class
subclass of: Classifier
definition: A Classifier whose behavior can be fully or partly described by the collaboration of owned or referenced instances. Maps to UML 2.5.1 §11.2 StructuredClassifier.

Transition
type: Class
subclass of: QualifiedRelationship
subclass of: Namespace
definition: A Transition is a directed relationship between a source Vertex and a target Vertex. It may be part of a compound transition, which takes the StateMachine from one stable State configuration to another. Maps to UML 2.5.1 §14.2 Transition.

Trigger
type: Class
subclass of: Named Element
definition: A Trigger specifies an Event that may cause the execution of an associated Behavior. Maps to UML 2.5.1 §13.3 Trigger.

Type
type: Class
subclass of: Packageable Element
definition: A Type constrains the values represented by a TypedElement. Maps to UML 2.5.1 §7.5 Type.

Typed Element
type: Class
subclass of: Named Element
definition: A named element that has a type. Maps to UML 2.5.1 §7.5 TypedElement.

Usage
type: Class
subclass of: Dependency
definition: A qualified relationship representing a UML Usage — a Dependency where the client requires the supplier for its implementation.
domain includes: Named Element
range includes: Named Element
unqualified form: Uses

Use Case
type: Class
subclass of: Behaviored Classifier
definition: A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.
scope note: UML 2.5.1 §18.2: "A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors." UseCases define the offered behavior of the subject without reference to its internal structure.

Vertex
type: Class
subclass of: Named Element
definition: A Vertex is an abstraction of a node in a StateMachine graph. It can be the source or target of any number of Transitions. Maps to UML 2.5.1 §14.2 Vertex.

Abstracts
type: ObjectProperty
definition: A Dependency relating two elements at different abstraction levels. Maps to UML 2.5.1 §7.7 Abstraction.
domain includes: Named Element
range includes: Named Element

Actual Gate
type: ObjectProperty
definition: The Gates on an InteractionUse that bind to the formalGates of the referenced Interaction. Actual gates connect messages in the enclosing Interaction to the formal interface of the referenced Interaction. Maps to UML 2.5.1 §17.7 InteractionUse::actualGate [0..*] {composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionUse-actualGate").
domain includes: Interaction Use
range includes: Gate

Aggregates
type: ObjectProperty
definition: A whole-part relationship where the part can exist independently of the whole (shared aggregation). Maps to UML 2.5.1 §11.5 Property::aggregation = shared.
domain includes: Classifier
range includes: Classifier

Associated With
type: ObjectProperty
definition: A semantic connection between Classifiers. Maps to UML 2.5.1 §11.5 Association. ODM Annex D.3.5 maps UML binary Association to owl:ObjectProperty.
domain includes: Classifier
range includes: Classifier

Body
type: DatatypeProperty
range: string
definition: The textual body of a Comment or Constraint. Maps to UML 2.5.1 §7.2 Comment::body.
domain includes: Comment
domain includes: Constraint

CFragment Gate
type: ObjectProperty
definition: The Gates owned by a CombinedFragment, through which messages can cross the CombinedFragment boundary. These gates connect messages outside the fragment to messages inside its operands. Maps to UML 2.5.1 §17.6 CombinedFragment::cfragmentGate [0..*] {composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="CombinedFragment-cfragmentGate").
domain includes: Combined Fragment
range includes: Gate

Composed Of
type: ObjectProperty
definition: A strong whole-part relationship where the part cannot exist without the whole (composite aggregation). Deletion of the whole cascades to the parts. Maps to UML 2.5.1 §11.5 Property::aggregation = composite.
domain includes: Classifier
range includes: Classifier

Covered
type: ObjectProperty
definition: References the Lifeline(s) that an InteractionFragment involves. For OccurrenceSpecification, this is exactly one Lifeline (the one on which the event occurs). For CombinedFragment, it may be multiple Lifelines (all those spanned by the fragment box). Maps to UML 2.5.1 §17.3 InteractionFragment::covered [0..*] and §17.4 OccurrenceSpecification::covered [1] (redefines to exactly one). Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionFragment-covered", "OccurrenceSpecification-covered").
domain includes: Interaction Fragment
range includes: Lifeline

Default Value
type: DatatypeProperty
range: string
definition: The default value of a Property. Maps to UML 2.5.1 §9.5 Property::defaultValue.
domain includes: Property

Depends On
type: ObjectProperty
definition: A relationship where a change to the supplier may affect the client. Maps to UML 2.5.1 §7.7 Dependency.
domain includes: Named Element
range includes: Named Element

Deployed On
type: ObjectProperty
definition: A relationship from a DeployedArtifact to a DeploymentTarget. Maps to UML 2.5.1 §19.2 Deployment.
domain includes: Artifact
range includes: Deployment Target

Effect
type: DatatypeProperty
range: string
definition: An effect Behavior executed when a Transition fires. Maps to UML 2.5.1 §14.2 Transition::effect.
domain includes: Transition

Execution
type: ObjectProperty
definition: The ExecutionSpecification that this ExecutionOccurrenceSpecification starts or finishes. This links the occurrence (a point in time) to the execution period it delimits. Maps to UML 2.5.1 §17.5 ExecutionOccurrenceSpecification::execution [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="ExecutionOccurrenceSpecification-execution").
domain includes: Execution Occurrence Specification
range includes: Execution Specification

Execution Finish
type: ObjectProperty
definition: The OccurrenceSpecification that marks the end of this ExecutionSpecification (the bottom of the activation bar). Typically this is the sendEvent of the reply message. Maps to UML 2.5.1 §17.5 ExecutionSpecification::finish [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="ExecutionSpecification-finish").
domain includes: Execution Specification
range includes: Occurrence Specification

Execution Start
type: ObjectProperty
definition: The OccurrenceSpecification that marks the beginning of this ExecutionSpecification (the top of the activation bar). Typically this is the receiveEvent of an incoming message. Maps to UML 2.5.1 §17.5 ExecutionSpecification::start [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="ExecutionSpecification-start").
domain includes: Execution Specification
range includes: Occurrence Specification

Extends
type: ObjectProperty
definition: A relationship from an extending UseCase to an extended UseCase. Maps to UML 2.5.1 §18.2 Extend.
domain includes: Use Case
range includes: Use Case

File Name
type: DatatypeProperty
range: string
definition: The file name of an Artifact. Maps to UML 2.5.1 §19.3 Artifact::fileName.
domain includes: Artifact

Formal Gate
type: ObjectProperty
definition: The Gates that form the message interface between this Interaction and any InteractionUses which reference it. Formal gates define the "ports" through which messages can enter or leave a reusable Interaction. Maps to UML 2.5.1 §17.2 Interaction::formalGate [0..*] {composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Interaction-formalGate").
domain includes: Interaction
range includes: Gate

Generalizes
type: ObjectProperty
definition: A taxonomic relationship between a more general Classifier and a more specific Classifier. Maps to UML 2.5.1 §9.7 Generalization. ODM Annex D.3.3 maps UML Generalization to rdfs:subClassOf. The direct triple uses this predicate; the qualified form carries metadata.
domain includes: Classifier
range includes: Classifier

Guard
type: DatatypeProperty
range: string
definition: A guard condition expressed as a string. For InteractionOperands, this is the Boolean expression that determines whether the operand is executed. For Transitions (state machines), this is the condition that must be true for the transition to fire. Maps to UML 2.5.1 §17.6 InteractionOperand (via InteractionConstraint) and §14.2 Transition::guard.
definition: A guard condition on a Transition or ActivityEdge. Maps to UML 2.5.1 §14.2 Transition::guard.
domain includes: Activity Edge
domain includes: Interaction Operand
domain includes: Transition

Guard Constraint
type: ObjectProperty
definition: The InteractionConstraint that guards an InteractionOperand. In UML, InteractionOperand::guard points to an InteractionConstraint instance (not directly to a string). This property provides the strict UML form; the :guard datatype property provides a pragmatic shortcut for simple cases. Maps to UML 2.5.1 §17.6 InteractionOperand::guard [0..1] {composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionOperand-guard").
editorial note: Both :guard (string shortcut) and :guardConstraint (object form) are supported. Use :guard for simple textual guards in architecture models. Use :guardConstraint when you need to attach minint/maxint (for loops) or when round-tripping from XMI where the guard is a full InteractionConstraint.
domain includes: Interaction Operand
range includes: Interaction Constraint

Has Fragment
type: ObjectProperty
definition: The ordered set of InteractionFragments owned by this Interaction or InteractionOperand. Maps to UML 2.5.1 §17.2 Interaction::fragment [0..*] {ordered, composite} and §17.6 InteractionOperand::fragment [0..*] {ordered, composite}. The ordering of fragments defines the top-to-bottom temporal sequence in a sequence diagram. In RDF, the ordering is captured by :sequenceNumber on each fragment instance rather than by collection position. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Interaction-fragment", "InteractionOperand-fragment").
editorial note: In UML XMI, the fragment property is {ordered} — the XML document order of <fragment> elements defines temporal ordering. In RDF there is no inherent document order, so each fragment carries a :sequenceNumber integer. See UML-DD-9 in design-decisions.md for the rationale.
domain includes: Interaction
domain includes: Interaction Operand
range includes: Interaction Fragment

Has General Ordering
type: ObjectProperty
definition: The GeneralOrdering constraints owned by this InteractionFragment. Maps to UML 2.5.1 §17.3 InteractionFragment::generalOrdering [0..*] {composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionFragment-generalOrdering").
domain includes: Interaction Fragment
range includes: General Ordering

Has Lifeline
type: ObjectProperty
definition: The Lifelines owned by this Interaction. Maps to UML 2.5.1 §17.2 Interaction::lifeline [0..*] {composite}. In the UML metamodel this is a composite association — the Interaction owns its Lifelines. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Interaction-lifeline").
domain includes: Interaction
range includes: Lifeline

Has Message
type: ObjectProperty
definition: The Messages owned by this Interaction. Maps to UML 2.5.1 §17.2 Interaction::message [0..*] {composite}. The Interaction owns all Messages that define communications between its Lifelines. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Interaction-message").
domain includes: Interaction
range includes: Message

Has Operand
type: ObjectProperty
definition: The ordered set of InteractionOperands contained in this CombinedFragment. Each operand represents one branch (for alt), one iteration body (for loop), or one parallel track (for par). Maps to UML 2.5.1 §17.6 CombinedFragment::operand [1..*] {ordered, composite}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="CombinedFragment-operand").
domain includes: Combined Fragment
range includes: Interaction Operand

Imports Package
type: ObjectProperty
definition: A relationship that allows the use of unqualified names to refer to members of the imported Package. Maps to UML 2.5.1 §12.2 PackageImport.
domain includes: Namespace
range includes: Package

Includes
type: ObjectProperty
definition: A relationship from a base UseCase to an included UseCase. Maps to UML 2.5.1 §18.2 Include.
domain includes: Use Case
range includes: Use Case

Interaction Operator
type: ObjectProperty
definition: The interaction operator that determines the semantics of this CombinedFragment. Values are from the InteractionOperatorKind enumeration in uml-reference-data.ttl: alt, opt, loop, break, par, seq, strict, critical, neg, assert, ignore, consider. Maps to UML 2.5.1 §17.6 CombinedFragment::interactionOperator. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="CombinedFragment-interactionOperator").
domain includes: Combined Fragment
range includes: Concept

Is Abstract
type: DatatypeProperty
range: boolean
definition: Whether the Classifier is abstract. Maps to UML 2.5.1 §9.2 Classifier::isAbstract.
domain includes: Classifier

Is Behavior
type: DatatypeProperty
range: boolean
definition: Whether the Port provides the published functionality of the owning EncapsulatedClassifier. Maps to UML 2.5.1 §11.3 Port::isBehavior.
domain includes: Port

Is Composite
type: DatatypeProperty
range: boolean
definition: Whether the State is a composite state containing Regions. Maps to UML 2.5.1 §14.2 State::isComposite.
domain includes: State

Is Conjugated
type: DatatypeProperty
range: boolean
definition: Whether the Port is conjugated (provided and required interfaces are swapped). Maps to UML 2.5.1 §11.3 Port::isConjugated.
domain includes: Port

Is Derived
type: DatatypeProperty
range: boolean
definition: Whether the Property value is derived from other information. Maps to UML 2.5.1 §9.5 Property::isDerived.
domain includes: Property

Is Indirectly Instantiated
type: DatatypeProperty
range: boolean
definition: Whether the Component is instantiated indirectly. Maps to UML 2.5.1 §11.6 Component::isIndirectlyInstantiated.
domain includes: Component

Is Leaf
type: DatatypeProperty
range: boolean
definition: Whether the RedefinableElement cannot be further redefined. Maps to UML 2.5.1 §7.6 RedefinableElement::isLeaf.
domain includes: Redefinable Element

Is Ordered
type: DatatypeProperty
range: boolean
definition: Whether the values of a multi-valued property are ordered. Maps to UML 2.5.1 §7.5 MultiplicityElement::isOrdered.
domain includes: Property

Is Orthogonal
type: DatatypeProperty
range: boolean
definition: Whether the State has multiple Regions (orthogonal). Maps to UML 2.5.1 §14.2 State::isOrthogonal.
domain includes: State

Is Read Only
type: DatatypeProperty
range: boolean
definition: Whether the StructuralFeature is read-only. Maps to UML 2.5.1 §9.4 StructuralFeature::isReadOnly.
domain includes: Structural Feature

Is Service
type: DatatypeProperty
range: boolean
definition: Whether the Port is used to provide the published functionality of the owning Component. Maps to UML 2.5.1 §11.3 Port::isService.
domain includes: Port

Is Static
type: DatatypeProperty
range: boolean
definition: Whether the Feature is a classifier-level feature. Maps to UML 2.5.1 §9.4 Feature::isStatic.
domain includes: Feature

Is Unique
type: DatatypeProperty
range: boolean
definition: Whether the values of a multi-valued property must be unique. Maps to UML 2.5.1 §7.5 MultiplicityElement::isUnique.
domain includes: Property

Lower Bound
type: DatatypeProperty
range: integer
definition: The lower bound of the multiplicity interval. Maps to UML 2.5.1 §7.5 MultiplicityElement::lower.
domain includes: Property

Merges Package
type: ObjectProperty
definition: A directed relationship between two Packages that indicates that the contents of the merged Package are combined into the receiving Package. Maps to UML 2.5.1 §12.2 PackageMerge.
domain includes: Package
range includes: Package

Message
type: ObjectProperty
definition: References the Message of which this MessageEnd is an endpoint. This is the inverse navigation from a MessageOccurrenceSpecification (or Gate) back to the Message it belongs to. In UML XMI, this appears as the "message" attribute on MessageOccurrenceSpecification elements. Maps to UML 2.5.1 §17.4 MessageEnd::message [0..1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="MessageEnd-message").
editorial note: This property is the inverse of sendEvent/receiveEvent. Both directions are provided for query convenience: from Message to its endpoints (sendEvent/receiveEvent) and from endpoint back to its Message (message). In strict UML, the authoritative direction is Message→MessageEnd; this inverse is a convenience property.
domain includes: Message End
range includes: Message

Message Kind
type: ObjectProperty
definition: The derived kind of the Message: complete, lost, found, or unknown. A Message is "complete" if both sendEvent and receiveEvent are present; "lost" if sendEvent is present but receiveEvent is absent; "found" if receiveEvent is present but sendEvent is absent; "unknown" if neither can be resolved. Maps to UML 2.5.1 §17.4 Message::messageKind {derived, readOnly}. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message-messageKind").
scope note: In UML, messageKind is a derived property — its value is computed from the presence/absence of sendEvent and receiveEvent. In Linked.Archi RDF, it may be materialised explicitly for query convenience, or left to SPARQL/SHACL rules to derive. Values are from the MessageKind concept scheme in uml-reference-data.ttl.
domain includes: Message
range includes: Concept

Message Sort
type: ObjectProperty
definition: The sort of communication reflected by the Message. Values are from the MessageSort enumeration in uml-reference-data.ttl: synchCall (default), asynchCall, asynchSignal, createMessage, deleteMessage, reply. The messageSort determines the visual notation (solid vs. dashed arrow, filled vs. open arrowhead) and the behavioral semantics (blocking vs. non-blocking, creation vs. destruction). Maps to UML 2.5.1 §17.4 Message::messageSort. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message-messageSort").
editorial note: Default value is synchCall. The signature must refer to an Operation (for synchCall, asynchCall, reply) or a Signal (for asynchSignal). See .reference/omg/uml/ptc-18-01-01.xmi constraint "signature_refer_to".
domain includes: Message
range includes: Concept

Name
type: DatatypeProperty
range: string
definition: The name of a NamedElement. Maps to UML 2.5.1 §7.4 NamedElement::name.
domain includes: Named Element

Ordering After
type: ObjectProperty
definition: The OccurrenceSpecification that must occur second in a GeneralOrdering constraint. This is the "after" end of the ordering relation. Maps to UML 2.5.1 §17.3 GeneralOrdering::after [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="GeneralOrdering-after").
domain includes: General Ordering
range includes: Occurrence Specification

Ordering Before
type: ObjectProperty
definition: The OccurrenceSpecification that must occur first in a GeneralOrdering constraint. This is the "before" end of the ordering relation. Maps to UML 2.5.1 §17.3 GeneralOrdering::before [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="GeneralOrdering-before").
domain includes: General Ordering
range includes: Occurrence Specification

Realizes
type: ObjectProperty
definition: A relationship between a specification (e.g., Interface) and its implementation (e.g., Class). Maps to UML 2.5.1 §7.7 Realization.
domain includes: Classifier
range includes: Classifier

Realizes Interface
type: ObjectProperty
definition: A specialized Realization between a BehavioredClassifier and an Interface. Maps to UML 2.5.1 §10.4 InterfaceRealization.
domain includes: Behaviored Classifier
range includes: Interface

Receive Event
type: ObjectProperty
definition: References the MessageEnd (typically a MessageOccurrenceSpecification) that represents the receiving of this Message. The receiveEvent is the point on the target Lifeline where the message arrow terminates. If absent, the Message is "lost" (messageKind = lost). Maps to UML 2.5.1 §17.4 Message::receiveEvent [0..1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message-receiveEvent").
domain includes: Message
range includes: Message End

Refers To
type: ObjectProperty
definition: The Interaction that this InteractionUse references. The semantics is that the contents of the referred Interaction are copied into the enclosing Interaction at the position of the InteractionUse. Maps to UML 2.5.1 §17.7 InteractionUse::refersTo [1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="InteractionUse-refersTo").
domain includes: Interaction Use
range includes: Interaction

Represents
type: ObjectProperty
definition: References the ConnectableElement (Property, Port, or Parameter) within the classifier that contains the enclosing Interaction. This is what the Lifeline "stands for" — the participant whose behavior is being described. Maps to UML 2.5.1 §17.3 Lifeline::represents [0..1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Lifeline-represents").
scope note: The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the classifier that contains the Interaction enclosing this Lifeline (constraint: same_classifier). If represents is absent, the Lifeline represents the classifier itself (the "self" lifeline).
domain includes: Lifeline
range includes: Property

Send Event
type: ObjectProperty
definition: References the MessageEnd (typically a MessageOccurrenceSpecification) that represents the sending of this Message. The sendEvent is the point on the source Lifeline where the message arrow originates. If absent, the Message is "found" (messageKind = found). Maps to UML 2.5.1 §17.4 Message::sendEvent [0..1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message-sendEvent").
domain includes: Message
range includes: Message End

Sequence Number
type: DatatypeProperty
range: integer
definition: The ordinal position of an InteractionFragment within its enclosing Interaction or InteractionOperand. This property captures the temporal ordering that UML XMI encodes via document order of the {ordered} fragment collection. Fragment with sequenceNumber 1 occurs before fragment with sequenceNumber 2, and so on. This is the primary ordering mechanism for sequence diagrams in Linked.Archi RDF.
editorial note: Alternative approaches considered: 1. rdf:List — rejected because lists are awkward to query in SPARQL and don't support random access or insertion 2. rdf:Seq — deprecated in modern RDF usage 3. Blank node chains — rejected for the same SPARQL ergonomics reasons The integer index approach is simple, queryable (ORDER BY ?seq), and consistent with how BPMN SequenceFlow uses explicit ordering in Linked.Archi.
scope note: In UML 2.5.1, the Interaction::fragment and InteractionOperand::fragment properties are both {ordered} — meaning the position of each InteractionFragment in the collection defines its temporal position. In XMI serialisation, this ordering is implicit in the XML document order of <fragment> elements. Since RDF has no inherent document order (triples in a graph are unordered), Linked.Archi uses an explicit integer index to preserve this semantics. The sequenceNumber is scoped to the immediately enclosing container (Interaction or InteractionOperand). Fragments in different containers have independent numbering. Message ordering is derived: Message M1 precedes M2 if M1.sendEvent.sequenceNumber < M2.sendEvent.sequenceNumber (within the same container). See UML-DD-9 in design-decisions.md for the full rationale.
domain includes: Interaction Fragment

Signature
type: ObjectProperty
definition: The signature of the Message — the specification of its content. It refers either to an Operation (for call/reply messages) or a Signal (for asynchronous signal messages). The name of the referenced element must match the name of the Message. Maps to UML 2.5.1 §17.4 Message::signature [0..1]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="Message-signature").
domain includes: Message
range includes: Operation
range includes: Signal

To After
type: ObjectProperty
definition: References the GeneralOrderings that specify OccurrenceSpecifications that must occur after this OccurrenceSpecification. This is the inverse navigation from an OccurrenceSpecification to the GeneralOrderings where it is the "before" element. Maps to UML 2.5.1 §17.4 OccurrenceSpecification::toAfter [0..*]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="OccurrenceSpecification-toAfter").
domain includes: Occurrence Specification
range includes: General Ordering

To Before
type: ObjectProperty
definition: References the GeneralOrderings that specify OccurrenceSpecifications that must occur before this OccurrenceSpecification. This is the inverse navigation from an OccurrenceSpecification to the GeneralOrderings where it is the "after" element. Maps to UML 2.5.1 §17.4 OccurrenceSpecification::toBefore [0..*]. Source: .reference/omg/uml/ptc-18-01-01.xmi (xmi:id="OccurrenceSpecification-toBefore").
domain includes: Occurrence Specification
range includes: General Ordering

Upper Bound
type: DatatypeProperty
range: integer
definition: The upper bound of the multiplicity interval. Use -1 for unlimited (*). Maps to UML 2.5.1 §7.5 MultiplicityElement::upper.
domain includes: Property

Uses
type: ObjectProperty
definition: A Dependency where the client requires the supplier for its full implementation or operation. Maps to UML 2.5.1 §7.7 Usage.
domain includes: Named Element
range includes: Named Element

Visibility
type: DatatypeProperty
range: string
definition: The visibility of a NamedElement (public, private, protected, package). Maps to UML 2.5.1 §7.4 NamedElement::visibility. Values are modeled as SKOS concepts in uml-reference-data.ttl.
domain includes: Named Element