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.
Linked.Archi
Linked.Archi UML 2.5.1 Ontology
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
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.
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.
A qualified relationship representing a UML Abstraction — a Dependency relating elements at different abstraction levels.
Abstraction
An AcceptEventAction waits for the occurrence of one or more specific events. Maps to UML 2.5.1 §16.10 AcceptEventAction.
Accept Event Action
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.
Action
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
An ActivityEdge is an abstract class for directed connections between two ActivityNodes. Maps to UML 2.5.1 §15.2 ActivityEdge.
Activity Edge
An ActivityFinalNode is a FinalNode that stops all flows in an Activity. Maps to UML 2.5.1 §15.3 ActivityFinalNode.
Activity Final Node
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 Node
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.
Activity Partition
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.
Actor
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.
A qualified relationship representing a UML shared aggregation — a whole-part relationship where the part can exist independently.
Aggregation
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.
Artifact
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.
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.
Association
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
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").
Behavior Execution Specification
A Classifier that may have InterfaceRealizations and owned Behaviors. Maps to UML 2.5.1 §10.5 BehavioredClassifier.
Behaviored Classifier
A CallAction is an Action that invokes a Behavior or Operation. Maps to UML 2.5.1 §16.3 CallAction.
Call Action
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.
Class
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).
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.
Classifier
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
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.
Collaboration Use
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").
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 .
Combined Fragment
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.
A textual annotation attached to a set of elements. Maps to UML 2.5.1 §7.2 Comment.
Comment
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.
Communication Path
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.
Component
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.
A qualified relationship representing a UML composite aggregation — a strong whole-part relationship where the part cannot exist without the whole.
Composition
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
A ConnectorEnd is an endpoint of a Connector, which attaches the Connector to a ConnectableElement. Maps to UML 2.5.1 §11.2 ConnectorEnd.
Connector End
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.
Constraint
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").
Continuation
A ControlFlow is an ActivityEdge traversed by control tokens only. Maps to UML 2.5.1 §15.2 ControlFlow.
Control Flow
A ControlNode is an abstract ActivityNode used to coordinate the flows between other nodes. Maps to UML 2.5.1 §15.3 ControlNode.
Control Node
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.
Data Type
A DecisionNode is a ControlNode that chooses between outgoing flows. Maps to UML 2.5.1 §15.3 DecisionNode.
Decision Node
A qualified relationship representing a UML Dependency — a supplier/client relationship where changes to the supplier may affect the client.
Dependency
A qualified relationship representing a UML Deployment — an Artifact is deployed on a DeploymentTarget (Node, Device, ExecutionEnvironment).
Deployment
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 Specification
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.
Deployment Target
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").
Destruction Occurrence Specification
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.
Device
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.
Element
A StructuredClassifier that may have Ports. Maps to UML 2.5.1 §11.2 EncapsulatedClassifier.
Encapsulated Classifier
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
A user-defined data value for an Enumeration. Maps to UML 2.5.1 §10.2 EnumerationLiteral.
Enumeration Literal
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.
Event
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 Environment
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").
Execution Occurrence Specification
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.
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").
Execution Specification
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).
A qualified relationship representing a UML Extend — an extending UseCase conditionally augments the behavior of an extended UseCase.
Extend
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.
Extension Point
A Feature declares a behavioral or structural characteristic of Classifiers. Maps to UML 2.5.1 §9.4 Feature.
Feature
A FinalNode is an abstract ControlNode at which a flow in an Activity stops. Maps to UML 2.5.1 §15.3 FinalNode.
Final Node
A FinalState represents the completion of activity in the enclosing Region. Maps to UML 2.5.1 §14.2 FinalState.
Final State
A FlowFinalNode is a FinalNode that terminates a flow without terminating the overall Activity. Maps to UML 2.5.1 §15.3 FlowFinalNode.
Flow Final Node
A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. Maps to UML 2.5.1 §15.3 ForkNode.
Fork Node
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.
Function Behavior
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").
Gate
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
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").
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.
General Ordering
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
A qualified relationship representing a UML Generalization — a taxonomic relationship from specific to general Classifier.
Generalization
A qualified relationship representing a UML Include — a base UseCase incorporates the behavior of an included UseCase.
Include
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 Flow
An InformationItem represents an abstraction of data that can be conveyed between two entities. Maps to UML 2.5.1 §20.2 InformationItem.
Information Item
An InitialNode is a ControlNode at which flow starts when the Activity is invoked. Maps to UML 2.5.1 §15.3 InitialNode.
Initial Node
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").
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 .
Interaction
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).
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").
Interaction Constraint
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
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").
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.
Interaction Fragment
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.
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").
Interaction Operand
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.
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").
Interaction Use
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.
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.
Interface
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.
A qualified relationship representing a UML InterfaceRealization — a BehavioredClassifier fulfills the contract of an Interface.
Interface Realization
A JoinNode is a ControlNode that synchronizes multiple flows. Maps to UML 2.5.1 §15.3 JoinNode.
Join Node
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").
Lifeline
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.
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.
Manifestation
A MergeNode is a ControlNode that brings together multiple alternate flows without synchronization. Maps to UML 2.5.1 §15.3 MergeNode.
Merge Node
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").
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.
Message
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.
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").
Message End
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).
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").
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 .
Message Occurrence Specification
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.
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.
Model
An element that has a name and visibility within a namespace. Maps to UML 2.5.1 §7.4 NamedElement.
Named Element
A named element that can own other named elements, providing a naming scope. Maps to UML 2.5.1 §7.4 Namespace.
Namespace
A Node is a computational resource upon which Artifacts may be deployed, via Deployment relationships, for execution. Nodes can be interconnected through communication paths.
Node
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.
An ObjectFlow is an ActivityEdge that can have objects or data passing along it. Maps to UML 2.5.1 §15.2 ObjectFlow.
Object Flow
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.
Object Node
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").
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.
Occurrence Specification
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.
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.
Opaque Behavior
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.
Operation
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
A qualified relationship representing a UML PackageImport.
Package Import
A qualified relationship representing a UML PackageMerge.
Package Merge
A named element that may be owned directly by a Package. Maps to UML 2.5.1 §7.4 PackageableElement.
Packageable Element
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.
Parameter
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.
Port
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.
Primitive Type
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
A ProfileApplication is used to show which Profiles have been applied to a Package. Maps to UML 2.5.1 §12.3 ProfileApplication.
Profile Application
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).
Property
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.
Pseudostate
A qualified relationship representing a UML Realization — a relationship between a specification and its implementation.
Realization
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.
Redefinable Element
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.
Region
A SendSignalAction creates a Signal instance and transmits it to the target object. Maps to UML 2.5.1 §16.3 SendSignalAction.
Send Signal Action
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.
Signal
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
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").
State Invariant
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.
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.
State Machine
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.
Stereotype
A typed feature of a Classifier that specifies the structure of instances. Maps to UML 2.5.1 §9.4 StructuralFeature.
Structural Feature
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.
Structured Classifier
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.
Transition
A Trigger specifies an Event that may cause the execution of an associated Behavior. Maps to UML 2.5.1 §13.3 Trigger.
Trigger
A Type constrains the values represented by a TypedElement. Maps to UML 2.5.1 §7.5 Type.
Type
A named element that has a type. Maps to UML 2.5.1 §7.5 TypedElement.
Typed Element
A qualified relationship representing a UML Usage — a Dependency where the client requires the supplier for its implementation.
Usage
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.
Use Case
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.
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.
Vertex
A Dependency relating two elements at different abstraction levels. Maps to UML 2.5.1 §7.7 Abstraction.
Abstracts
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").
Actual Gate
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.
Aggregates
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.
Associated With
The textual body of a Comment or Constraint. Maps to UML 2.5.1 §7.2 Comment::body.
Body
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").
CFragment Gate
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.
Composed Of
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").
Covered
The default value of a Property. Maps to UML 2.5.1 §9.5 Property::defaultValue.
Default Value
A relationship where a change to the supplier may affect the client. Maps to UML 2.5.1 §7.7 Dependency.
Depends On
A relationship from a DeployedArtifact to a DeploymentTarget. Maps to UML 2.5.1 §19.2 Deployment.
Deployed On
An effect Behavior executed when a Transition fires. Maps to UML 2.5.1 §14.2 Transition::effect.
Effect
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").
Execution
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").
Execution Finish
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").
Execution Start
A relationship from an extending UseCase to an extended UseCase. Maps to UML 2.5.1 §18.2 Extend.
Extends
The file name of an Artifact. Maps to UML 2.5.1 §19.3 Artifact::fileName.
File Name
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").
Formal Gate
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.
Generalizes
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.
A guard condition on a Transition or ActivityEdge. Maps to UML 2.5.1 §14.2 Transition::guard.
Guard
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").
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.
Guard Constraint
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").
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.
Has Fragment
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").
Has General Ordering
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").
Has Lifeline
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").
Has Message
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").
Has Operand
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.
Imports Package
A relationship from a base UseCase to an included UseCase. Maps to UML 2.5.1 §18.2 Include.
Includes
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").
Interaction Operator
Whether the Classifier is abstract. Maps to UML 2.5.1 §9.2 Classifier::isAbstract.
Is Abstract
Whether the Port provides the published functionality of the owning EncapsulatedClassifier. Maps to UML 2.5.1 §11.3 Port::isBehavior.
Is Behavior
Whether the State is a composite state containing Regions. Maps to UML 2.5.1 §14.2 State::isComposite.
Is Composite
Whether the Port is conjugated (provided and required interfaces are swapped). Maps to UML 2.5.1 §11.3 Port::isConjugated.
Is Conjugated
Whether the Property value is derived from other information. Maps to UML 2.5.1 §9.5 Property::isDerived.
Is Derived
Whether the Component is instantiated indirectly. Maps to UML 2.5.1 §11.6 Component::isIndirectlyInstantiated.
Is Indirectly Instantiated
Whether the RedefinableElement cannot be further redefined. Maps to UML 2.5.1 §7.6 RedefinableElement::isLeaf.
Is Leaf
Whether the values of a multi-valued property are ordered. Maps to UML 2.5.1 §7.5 MultiplicityElement::isOrdered.
Is Ordered
Whether the State has multiple Regions (orthogonal). Maps to UML 2.5.1 §14.2 State::isOrthogonal.
Is Orthogonal
Whether the StructuralFeature is read-only. Maps to UML 2.5.1 §9.4 StructuralFeature::isReadOnly.
Is Read Only
Whether the Port is used to provide the published functionality of the owning Component. Maps to UML 2.5.1 §11.3 Port::isService.
Is Service
Whether the Feature is a classifier-level feature. Maps to UML 2.5.1 §9.4 Feature::isStatic.
Is Static
Whether the values of a multi-valued property must be unique. Maps to UML 2.5.1 §7.5 MultiplicityElement::isUnique.
Is Unique
The lower bound of the multiplicity interval. Maps to UML 2.5.1 §7.5 MultiplicityElement::lower.
Lower Bound
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.
Merges Package
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").
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.
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").
Message Kind
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.
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").
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".
Message Sort
The name of a NamedElement. Maps to UML 2.5.1 §7.4 NamedElement::name.
Name
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").
Ordering After
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").
Ordering Before
A relationship between a specification (e.g., Interface) and its implementation (e.g., Class). Maps to UML 2.5.1 §7.7 Realization.
Realizes
A specialized Realization between a BehavioredClassifier and an Interface. Maps to UML 2.5.1 §10.4 InterfaceRealization.
Realizes Interface
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").
Receive Event
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").
Refers To
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").
Represents
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).
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").
Send Event
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.
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.
Sequence Number
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.
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").
Signature
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").
To After
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").
To Before
The upper bound of the multiplicity interval. Use -1 for unlimited (*). Maps to UML 2.5.1 §7.5 MultiplicityElement::upper.
Upper Bound
A Dependency where the client requires the supplier for its full implementation or operation. Maps to UML 2.5.1 §7.7 Usage.
Uses
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.
Visibility