Guidance for representing UML/SysML Datatypes in OML

[NicolasRouquette]

The embedding of UML/SysML Datatypes in OWL2-DL has been problematic for quite a while.
This issue proposes a strategy to solve this problem in a way that preserves the essential characteristics that make OWL2-DL particularly well-suited for the analysis of systems engineering information.

Background

Within the family of Description Logics, OWL2-DL was deliberately
designed to ensure that the logical consequences of a vocabulary of
conceptual entities and relations are independent of the particular
choice of datatypes used (See Theorem DS1 in the OWL2 Direct Semantics specification).

The independence theorem of OWL2 Direct Semantics reflects a strong syntactic and semantic decoupling between two categories of constructs:

• Datatypes entities (this is called a "Datatype Map" in OWL2-DL).
• Conceptual entities (classes, object properties, data properties and individuals) and logical axioms about them.

The syntactic category of datatype map constructs in OWl2-DL builds on
the so-called "Datatype system" framework defined in the XML Schema 1.1 Datatypes specification.

This framework establishes the fundamental principles for defining
datatypes in terms of an abstract characterization of their
implementations. In practice, this framework has proven so effective
that most users have become accustomed to assume that all the tools
they use provide adequate interoperability for datatypes operations
and interchangeability of datatype value representations.

The OWL2-Direct Semantics independence theorem builds on the practical effectiveness of the datatype system of abstractions;
it effectively ensures that the logical properties of a vocabulary of conceptual entities is independent of the particular
datatype system used and therefore of the particular datatype system implementation as well.

This independence is particularly valuable for systems engineering where the plurality of domain-specific vocabularies,
methodologies and tools has, in the past, caused significant problems due to poor interchange and interoperability.
Although OMG's SysML is widely used in the emerging field of model-based systems engineering, it inherits from its
architecture as an extension of OMG's UML structural problems that make the application of OWL2-DL difficult for
preserving the practical utility of the independence theorem with respect to a choice of datatype system.

The reason for this difficulty stems from the design of the UML syntax
and semantics around the notion of "Classifier" as some kind of
unifying abstraction of both datatype entities (i.e., UML Datatype)
and conceptual entities (e.g., UML Class, UML Association).
This unification permeates the vocabulary for representing datatype values
and instances of conceptual entities; both of which are kinds of UML
ValueSpecifications at the syntactic level and kinds of FUML Values at
the semantic level.

Since SysML is defined as a profile extension of UML, SysML inherits the same blurred unification of
these two categories. While it might be possible that someone could design a clever semantics for UML/SysML
that could achieve practically useful capabilities for both logical reasoning, interchangeable representations
and implementaiton level interoperability, it is legitimate to question how much harder this task is because
of the unified Classifier/ValueSpecification/Value scheme:

Is it possible to map UML to OWL2-DL in such a way that preseves the syntactic and semantic decoupling?

The unified Classifier/ValueSpecification/Value scheme makes this mapping non-trivial, if at all possible.
Instead of attempting this challenge, the strategy adopted here involves deliberately breaking the UML unification scheme
so as to ensure that the OWL2-DL mapping of UML preserves the decoupling that is essential for the validity of OWL2-DL itself
and of the indepdence theorem.

At the syntactic level, this involves deleting the classification of UML Datatype as a kind of UML Classifier.
This has several implications that need to be addressed; including the consequence that a UML ValueSpecification can no longer be typed by a UML Datatype.

From the perspecive of the OWL2-DL Datatype map and its underlying datatype system framework, what is the implicit datatype map of UML and of SysML?

The following analysis examines the syntactic UML/SysML vocabulary pertaining to defining datatypes and to representing values of datatypes
and uses OML to augment the expressiveness of the vocabulary of datatype entities beyond the limitations of the OWL2-DL datatype map framework to provide
support for the syntax and semantics of structured datatypes by embedding them in the existing OWL2-DL vocabulary and semantics.

In the following discussion, any UML Property defined in a UML Datatype must be typed by some kind of UML Datatype.
The UML 2.5 specification allows, in principle, a UML Datatype to have a UML Property typed by something other than a UML Datatype.
For the purposes of this discussion, such a case is considered ill-formed.

Analysis of the UML/SysML Datatype vocabulary

1) UML Datatype, UML PrimitiveType, UML Enumeration

Based on the definitions in UML 2.5:

• A UML Datatype may have internal structure in terms of properties typed by Datatypes.
• A UML PrimitiveType is a kind of UML Datatype restricted to have no internal structure.
• A UML Enumeration is a kind of UML Datatype whose values is defined explicitly by extension with a list of UML EnumerationLiterals.

2) Datatype arity

In OWL2-DL, an OWL Datatype definition is restricted to an OWL Datarange with arity=1.
An OML Scalar corresponds to an OWL Datatype definition (w/ an OWL Datarange of arity=1).

Currently, OWL2-DL does not support defining datatypes with arity>1.
OML provides such support with the OML Structure construct, which is embedded as a special kind of OWL2-DL OWL Class
carefully restricted to be isolated from other embeddings of OML constructs as OWL2-DL OWL Class.

In UML, datatype arity is unfortunately a complicated topic that requires a case-by-case analysis.

2.1) Arity of a UML PrimitiveType.

Since a UML PrimitiveType is restricted to have no substructure, it clearly corresponds to a datatype of arity 1.
Therefore, a UML PrimitiveType is embedded as an OML Scalar, which is itself embedded as an OWL2-DL OWL Datatype definition of arity=1.

The UML PrimitiveTypes library (see clause 22 in UML 2.5) defines several UML PrimitiveTypes
with an embedding in XML Schema 1.1 Datatypes per clause E.3 in UML 2.5

• Boolean is embedded as xsd:boolean
• Integer is embedded as xsd:integer
• Real is embedded as xsd:double

Note that there is a discrepancy in the UML 2.5 specificaiton between the intended definition of Real (infinite set of real numbers)
and its finite embedding as xsd:double (64-bit floating point precision numbers).

• String is embedded as xsd:string
• UnlimitedNatural is embedded as xsd:string

Note that there is a discrepancy in the UML 2.5 specification between the intended definition of UnlimitedNatural (non-negative natural numbers plus "" denoting infinity) and its embedding as xsd:string.
In OML, UnlimitedNatural is embedded as an OWL Datatype defined to reflect the intended UML 2.5 definition, that is:
OWL DataUnionOf between xsd:nonNegativeInteger and an OWL DataOneOf enumeration for the special value "" denoting positive infinity.

2.2) Arity of a UML Enumeration.

In principle, the UML specification allows a UML Enumeration to have substructure.

2.2.1) UML Enumeration with arity=1

An UML Enumeration with no substructure has arity=1 and is trivially embedded to an OML ScalarOneOfRestriction definition with
OML ScalarOneOfLiteral axioms for each UML EnumerationLiteral. This OML embedding becomes an OWL2-DL OWL Datatype definition
for an OWL DataOneOf data range.

2.2.2) UML Enumeration with arity>1

There is currently no support for this in the OML datatype extensions of OWL2-DL.
It is questionable whether such support is useful at all because it aspires to provide
an identifier for a tuple value of a structured datatype. Since the semantics of a datatype is fundamentally a set of values
regardless of arity, it is questionable whether identifying a particular tuple value makes sense at all.
However, one could certainly define a conceptual entity of some kind with a property typed by a structured datatype
and identify particular instances of such an entity and specify a particular value as a restriction on its property.

2.3) UML Datatype with arity > 1 (that is not a UML PrimitiveType nor a UML Enumeration)

A UML Datatype corresponds to the definition of a structured datatype that is embedded as an OML Structure.
The properties of the UML Datatype are embedded as OML DataPropertyFromStructure according
to whether their type is structured (i.e., OML StructuredDataProperty) or scalar (i.e., OML ScalarDataProperty).

3) UML Generalizations among UML Datatypes

In the UML metamodel, a UML Datatype is a kind of UML Classifier; therefore, it may be involved in relations with other compatible UML Datatypes via UML Generalizations.
The embedding of such relations depends on the arity of the UML Datatypes involved as specific and general classifiers.
Note that the UML specification requires that generalizations must be acyclic and that the specific classifier must be of a compatible kind with respect to the general classifier.
In practice, this means that UML Generalizations can only happen in the following 5 cases:

3.a) A UML Datatype(arity>1) may specialize another UML Datatype(arity>1) (not a UML Enumeration or UML PrimitiveType).

3.b) A UML Enumeration(arity=1) may specialize another UML Enumeration(arity=1).

3.c) A UML PrimitiveType(arity=1) may specialize another UML PrimitiveType(arity=1).

3.d) A UML Enumeration(arity=1) may specialize another UML Datatype(arity>1) (not a UML Enumeration or UML PrimitiveType).

3.e) A UML PrimitiveType(arity=1) may specialize another UML Datatype(arity>1) (not a UML Enumeration or UML PrimitiveType).

All these cases are currently allowed in the UML 2.5 specification; however, several are excluded for reasons below:

- Case (3.a) is excluded because the meaning of such a specialization is esoteric at best.

In the case where the arity is different, a set of tuple values of arity N1>1 can never be a subset of a set of tuple values of arity N2>1 where N1 != N2.
If the arity is the same, the generalization can be meaningless if the types of the properties are structurally different (e.g., because of arity or because of the set of values).
In the very limited circumstances where both specialized and general UML Datatypes have structurally equivalent shapes (arity) and semanically compatible sets of values recursively,
it is questionable what practical utility there is, if any, in asserting a subsetting relationship between such UML Datatypes.
In absence of a compelling use case to the contrary, this is is excluded.

- Case (3.b) is excluded because the meaning of such a specialization is esoteric at best and there is no vocabulary in OWL2-DL to specify it.

This case is well-formed if and only if the set of UML EnumerationLiterals defined of the specific UML Enumeration
is the same as or a proper subset of the set of UML EnumerationLiterals of the general UML Enumeration.
Although the OWL2-DL vocabulary for specifying OWL DataRanges includes the construct of OWL DataOneOf for specifying an enumeration
(see 2.2.1 above), there is no vocabulary available for specifying that an OWL DataOneOf range is a subset of another OWL DataOneOf range.
Since the practical utility of this case is questionable, there is no support for it either in the OML datatype extensions of OWL2-DL.

- Cases (3.d) and (3.e) are allowed in UML but are excluded because they are logically unsatisfiable: a set of atomic values can never be a subset of a set of tuple values.

- Case (3.c) is the only remaining case where one may consider mapping a UML Generalization among UML PrimitiveTypes.

Unfortunately, the UML 2.5 specification provides no additional vocabulary for specifying the intended meaning of such a relationship.
Per (2.2.1), a UML PrimitiveType is ultimately embedded as an OWL Datatype definition. In contrast to the paucity of the datatype vocabulary in the UML 2.5 specification,
the OWL2-DL specification provides a rich vocabulary of OWL DataRange modeling constructs; this OWL DataRange modeling vocabulary is closed:
This means that any syntactic combination of OWL DataRange modeling constructs is a semantically valid OWL DataRange (albeit denoting a possibly empty set of values!).
Absent of any corresponding vocabulary, OML provides, via an embedding strategy, a UML profile corresponding to the OWL DataRange vocabulary.
The embedding of the OML profile for OWL DataRange is in 1-1 correspondence between UML patterns based on this OML profile and OWL DataRange vocabulary constructs.

4) UML ValueSpecifications and FUML Values

A UML ValueSpecification typed by a UML Datatype is the syntactic representation of its semantic FUML Value classified by the same UML Datatype.
Conversely, a semantic FUML Value classified by a UML Datatype can be converted into a syntactic representation as a UML ValueSpecification typed by that UML Datatype.

Since UML ValueSpecification is an abstract metaclass; this means that the syntactic representation of the value of a UML Datatype varies according to the kind of UML Datatype involved.

4.1) A UML ValueSpecification typed by a UML PrimitiveType (see 2.1)

Cases need to be distinguished according to the UML PrimitiveType involved.

4.1.1) UML PrimitiveTypes defined in the standard library (see UML clause 21)

There is a 1-1 correspondence with specializaitons of UML LiteralSpecification and definitions of UML PrimitiveTypes:

• UML LiteralBoolean specifies a value of a UML Boolean
• UML LiteralInteger specifies a value of a UML Integer
• UML LiteralReal specifies a value of a UML Real
• UML LiteralString specifies a value of a UML String
• UML LiteralUnlimitedNatural specifies a value of a UML UnlimitedNatural

4.1.2) A user-defined UML PrimitiveType other than one of the UML PrimitiveType library (see UML 2.5 clause 21)

There is no clear support in UML 2.5 for specifying the value of a user-defined UML PrimitiveType.

OML relaxes a bit the UML 2.5 specification in allowing a UML LiteralString to be typed by a user-defined UML PrimitiveType
as a practically simple and convenient way to specify a value of such a user-defined UML PrimitiveType.

4.2) A UML ValueSpecification typed by an UML Enumeration(arity=1) (see 2.2.1)

In UML 2.5, this involves an UML InstanceValue that refers to the particular UML EnumerationLiteral corresponding to the desired value.
The embedding of this in OML and in OWl2-DL is litterally a copy of the UML EnumerationLiteral value.
This is because UML ValueSpecifications have intrinsic identity as kinds of UML Elements whereas
in the context of OML and of OWL2-DL's partitioning between datatype entities and conceptual entities,
datatypes denote values that have no identity except their own value.

4.3) A UML ValueSpecification typed by an UML Datatype (arity>1) (see 2.3)

In UML 2.5, this involvesan UML InstanceValue that refers to an UML InstanceSpecification
whose UML Slots in turn represent the values of the properties of the structured UML Datatype.

Since there is no support for datatypes of arity>1, OML uses a restricted partition of OWL Class for representing a structured datatype.
Consequently, OML uses a restricted partition of OWL AnonymousLiterals for representing values of a structured datatype in a way
that ensures that, albeit represented as instances of OWL Classes, such OWL AnnonymousLiterals do not leak any identity outside
the scope of the restricted OWL ontology in which they are defined.

5) SysML ValueType stereotype extension of UML Datatype

The OMG SysML 1.5 Revision Task Force chose to defer two significant issues about SysML ValueTypes:

• SYSMLR-62
• SYSMLR-84

Both issues point to serious problems with SysML's ValueType extension
of UML's Datatype: SysML lacks guidance for representing the value of
a SysML ValueType, whether it is from the SysML library of SysML
PrimitiveTypes (SYSMLR-62) or other kinds of SysML ValueTypes (SYSMLR-84).

From the perspective of an embedding in OML and OWL2-DL where there is a partitioning between datatypes and conceptual entities, SysML's ValueType extension amounts to a bridge across this partition:

• As a kind of UML Datatype, a SysML ValueType seems to belong to the category of datatype related entities.

• The SysML ValueType extension provides support for specifying metrological characteristics of unit and quantity kind via stereotype properties defined on the SysML ValueType extension. These properties in turn are intended to refer to specifications of metrological units and quanitity kinds explicitly represented in some way; for example, with the SysML conceptual vocabulary of Quantities, Units, Dimensions and Values (QUDV) annex.

Regardless of whether it is based on SysML QUDV or some user-defined metrological vocabulary,
the unit and quantity kind characteristics of a SysML ValueType are clearly in the realm of conceptual entities, not datatype values.

Mapping this SysML ValueType heterogenous bridge into OML and OWL2-DL would merge the categories of datatypes and conceptual entities. Consequently, this would invalidate the independence theorem of OWL2-DL Direct Semantics. To avoid this, it is therefore necessary
to deconstruct SysML's ValueType extension and reconstruct it in a way that can be mapped into a combination of constructs that remained partitioned between datatype and conceptual entities.

In principle, there could be many ways to perform this deconstruction and reconstruction into OML/OWL2-DL. The following approach builds on the deferred SysML 1.5 issues (SYSMLR-62, SYSMLR-84) as follows:

• A SysML ValueType is a conceptual entity; more specifically, it is embedded as an OML Aspect that is embedded as an OWL Class.

• Similarly, all the SysML Blocks that define the QUDV conceptual vocabulary are embedded as OML Aspects and the SysML AssociationBlocks that define conceptual relationships among them are embedded as OML ReifiedRelationships among the corresponding OML Aspects.

• Per above distinction between UML Datatypes with arity=1 vs. arity>1, it is important to correspondingly distinguish scalar vs. structured SysML ValueTypes. The importance of this distinction was originally made in the presentation to the OMG SE DSIG in 2014 about QUDV (See http://www.omg.org/cgi-bin/doc?syseng/2014-03-08). In the OML/OWL2-DL reconstruction of SysML ValueType, this means that there are two specializations of the OML SysML Value aspect:

  • OML SysML ScalarValueType for arity=1 (this corresponds to applying SysML ValueType to either a UML PrimitiveType or an UML Enumeration(arity=1)).
  • OML SysML StructuredValueType for arity>1 (this corresponds to applying SysML ValueType to a UML Datatype, not a UML PrimitiveType, not a UML Enumeration). This construct does not need to be explicitly defined in the OMG SysML vocabulary; it will be created as a consequence of mapping a user-defined SysML model to OML.

  As a refinement of the "Introduction to QUDV" presentation to the SE DSIG in 2014, the SysML::ValueType::{unit,quantityKind} properties are reconstructed only for the case of an OML SysML ScalarValueType. For an OML SysML StructuredValueType, it is unclear whether there is a sensible metrological interpretation to the notion of a metrology unit and/or quantity kind that applies to a structured datatype. Doing so would be outside the scope of the International Vocabulary of Metrology (VIM) on which the OMG SysML 1.4/5 QUDV vocabulary is based because the VIM explicitly states that the magnitude of a quantity can be expressed as a number and a reference (e.g., a measurement unit).

  The SysML notions of unit and quantityKind only pertain to OML SysML ScalarValueType. This means that these notions need to be refactored as OML unreified properties from OML SysML ScalarValueType to OML Unit/QuantityKind respectively.

The reconstruction of OML SysML ScalarValueType also includes multiple OML ScalarDataProperties for each OML DataRange in scope of the OWL2-DL Datatype map and of the SysML datatype vocabulary.

6) Summary of the proposed changes to the IMCE ontologies of UML/SysML

6.1) In ontologies/imce.jpl.nasa.gov/www.omg.org/spec/PrimitiveTypes/20110701/PrimitiveTypes.owl

• In principle, the definition of UnlimitedNatural should be changed as discussed in 2.1 above since it properly reflects the intent of the UML 2.5 specification; that is:

    <!-- http://imce.jpl.nasa.gov/www.omg.org/spec/PrimitiveTypes/20110701/PrimitiveTypes#UnlimitedNatural -->

    <rdfs:Datatype rdf:about="http://imce.jpl.nasa.gov/www.omg.org/spec/PrimitiveTypes/20110701/PrimitiveTypes#UnlimitedNatural">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:unionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="http://www.w3.org/2001/XMLSchema#nonNegativeInteger"/>
                    <rdfs:Datatype>
                        <owl:oneOf>
                            <rdf:Description>
                                <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#List"/>
                                <rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string">*</rdf:first>
                                <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
                            </rdf:Description>
                        </owl:oneOf>
                    </rdfs:Datatype>
                </owl:unionOf>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>

Or more succinctly in OWL Functional Syntax:

DatatypeDefinition(primitivetypes:UnlimitedNatural DataUnionOf(xsd:nonNegativeInteger DataOneOf("*"^^xsd:string)))

Unfortunately, OML 0.9 supports a closed of the OWL2-DL DataRange vocabulary for defining enumerations (OWL DataOneOf) and restrictions (OWL DatatypeRestriction). The vocabulary for defining intersections (OWL DataIntersectionOf), complements (OWL DataComplementOf) or unions (OWL DataUnionOf) has yet to be added to OML.

However, the current definition of UML UnlimitedNatural fits within the supported OML 0.9 vocabulary of OWL DataRanges. For the time being, this definition remains as it stands.

This can be revisited when the OML DataRange vocabulary is available (see JPL-IMCE/gov.nasa.jpl.imce.oml#165)

6.2) In ontologies/imce.jpl.nasa.gov/www.omg.org/spec/UML/20110701/UML.owl

• Delete UML:Datatype
• Delete UML:PrimitiveType
• Delete UML:Enumeration
• Delete UML:EnumerationLiteral
• Delete UML:LiteralSpecification & its specializations (LiteralBoolean, LiteralInteger, LiteralReal, LiteralString, LiteralUnlimitedNatural)

User-defined UML Datatypes will be embedded in OWL per the guidelines defined in (2) above.

6.3) In ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML.owl

• Delete SysML:Boolean

• Delete SysML:Complex

• Delete SysML:Integer

• Delete SysML:Number

• Delete SysML:Real

• Delete SysML:String

• Change SysML:Complex as a restriction of xsd:string for the pattern: .* i .*

• Keep SysML:ValueType as an OML Aspect

• Add SysML:StructuredValueType as an OML Aspect specialization of SysML:ValueType

• Add SysML:ScalarValueType as an OML Aspect specialization of SysML:ValueType

• Add SysML:<datatype>.value OML ScalarDataType properties for a covering set of OWL Datatypes that is compatible with the OWL2-DL Datatype map. The minimal covering set of such OWL Datatypes is precisely:

From OWL2's Real Numbers, Decimal Numbers and Integers

• owl:real
• owl:rational
• xsd:decimal
  Note that the value space of xsd:decimal includes the values space of all other kinds of decimal numbers and integers mentioned in this section (see https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#built-in-datatypes).

From OWL2's Floating-Point Numbers

• xsd:double
• xsd:float

From OWL2's Strings

• rdf:PlainLiteral

• xsd:string

  Note that the value space of xsd:string includes the value spaces of all other kinds of strings mentioned in this section (see https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#built-in-datatypes).

From OWL2's Boolean Values

• xsd:boolean

From OWL2's Binary Data

• xsd:base64Binary
• xsd:hexBinary

From OWL2's IRIs

• xsd:anyURI

  While it might be strange to think of an URI as a syntactical representation of a number, it is conceivable that such a number may be specified by reference to its definition as an external resource located via a URI.

From OWL2's Time Instants

• xsd:dateTime
• xsd:dateTimeStamp

From OWL2's XML Literals

• rdf:XMLLiteral

Define an OML StringScalarRestriction for SysML:Complex

Define the pattern facet constraint as a regular expression for "<R> i <I>" where <R> and <I> are arbitrary strings representing the real and imaginary components of a complex number.

6.4) In ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/QUDV.owl

• The QUDV ontology seems OK; no change needed.

6.5) In ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/Metrology.owl

• The Metrology ontology seems OK; no change needed.

[NicolasRouquette]

Completed refactoring.