DDI XMI analyzer

Introduction

This section loosely describes a mapping from UML models to RDF models in order to describe compliant RDF data.

The UML model includes Associations, Enumerations, atomic and complex Datatypes and Classes with Generalizations and Properties. For RDF, Classes and complex Datatypes are captured as Shapes, Properties are captured as TripleConstraints, and atomic Datatypes and Enumerations are expressed as NodeConstraints. In principle, OCL encodings of co-occurrence constraints can be expressed as TripleExpressions, but this must be tested on a corpus of UML that has such OCL.

Shapes describe data structures while typical intepretations of OWL classes are that they describe real-world objects. For example, a real-world Person object will always have two biological parents which are in turn entities of type Person. A data structure describing a person will deal with this infinite series (and with likely missing data) by making the biological parents "optional". OWL model using OWL Classes as OWL has been used to model this duality since before shapes languages existed and DDI exports a data structure-oriented ontology.

Creating the RDF model requires a mapping of Property names to RDF predicates. OMG’s ODM offers a conservative approach to this which constructs an RDF predicate from a the name of a containing Class, a Property name, and the value type of that Property. For instance, from the BRIDG, a BiologicEntityPart has a anatomicSiteLaterality which has a value which is a code. The ODM representation of this as an RDF predicate is bridg:BiologicEntityPart.anatomicSiteLateralityCode. Greater understanding of the domain of the UML model may reveal at all properties with the same name can be given the same identifier in RDF. For instance, DDI’s member property appears in many Classes with different value types, but the RDF identifier ddi:member captures them all.

Enumerations contain a list one or more constants. While these could be expressed in RDF instances as either literals or IRIs, the strong preference in RDF is to leverage IRIs and web architecture to provide unambiguous identifiers.

The following examples are taken from a subset of the DDI model forming a constellation around ConceptSystem.

parsing XMI

recursively walk the XMI capturing the UML model:

packages

<packagedElement xmi:id="…-Conceptual" xmi:uuid="…" xmi:type="uml:Package">

package comment

  <ownedComment xmi:type="uml:Comment">
    <body>some comment text</body>
  </ownedComment>

classes

<packagedElement xmi:id="…-Conceptual-ConceptSystem" xmi:uuid="…" xmi:type="uml:Class">
  <name>ConceptSystem</name>

class properties

<packagedElement xmi:id="…-Conceptual-ConceptSystem" xmi:uuid="…" xmi:type="uml:Class">
  ...
  <ownedAttribute xmi:id="…-Conceptual-ConceptSystem-type" xmi:uuid="…" xmi:type="uml:Property">
    <type xmi:idref="…-EnumerationsRegExp-CollectionType"/>
    <name>type</name>

property comment

  <ownedComment xmi:type="uml:Comment">
        <body>some comment text</body>
      </ownedComment>

class assocations

<packagedElement xmi:id="…-Conceptual-ConceptSystem" xmi:uuid="…" xmi:type="uml:Class">
  ...
  <ownedAttribute xmi:id="…-Conceptual-ConceptSystem-ownedAttribute-8" xmi:uuid="..." xmi:type="uml:Property">
    <type xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-Concept"/>
    <association xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-packagedElement-13"/>

<packagedElement xmi:id="…-Conceptual-packagedElement-13" xmi:uuid="..." xmi:type="uml:Association">
  <name>definingConcept</name>
  <memberEnd xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-ConceptSystem-ownedAttribute-8"/>
  <memberEnd xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-packagedElement-13-ownedEnd"/>
  <ownedEnd xmi:id="…-Conceptual-packagedElement-13-ownedEnd" xmi:uuid="..." xmi:type="uml:Property">
    <type xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-ConceptSystem"/>
    <association xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-packagedElement-13"/>

property comment

  <ownedComment xmi:type="uml:Comment">
        <body>some comment text</body>
      </ownedComment>

Associations are annotated by an aggregation attribute they are marked as shared:

<packagedElement xmi:id="…-Conceptual-ConceptSystem" xmi:uuid="…" xmi:type="uml:Class">
  ...
  <ownedAttribute xmi:id="…-Conceptual-ConceptSystem-ownedAttribute-6" xmi:uuid="…" xmi:type="uml:Property">
    <association xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-packagedElement-11"/>
      <aggregation>shared</aggregation>

or composite:

      <aggregation>composite</aggregation>

class comment

<packagedElement xmi:id="…-Conceptual-ConceptSystem" xmi:uuid="…" xmi:type="uml:Class">
  ...
  <ownedComment xmi:type="uml:Comment">
    <body>some comment text</body>
  </ownedComment>

Classes may be marked abstract:

<isAbstract>true</isAbstract>

and may be derived from other classes:

  <generalization xmi:id="…-Conceptual-ConceptSystem-generalization" xmi:uuid="…" xmi:type="uml:Generalization">
    <general xmi:idref="…-Identification-AnnotatedIdentifiable"/>

Practical permutations:

simple concrete class
concrete class with a generalization relationship to another concrete class
concrete class with a generalization relationship to another abstract class
abstract class with a generalization relationship to another abstract class

enumerations

<packagedElement xmi:id="…-ComplexDataTypes-RelationSpecification" xmi:uuid="…" xmi:type="uml:Enumeration">
  <name>RelationSpecification</name>
  <ownedLiteral xmi:id="…-ComplexDataTypes-RelationSpecification-Unordered" xmi:uuid="…" xmi:type="uml:EnumerationLiteral">
    <name>Unordered</name>
  </ownedLiteral>

datatypes

<packagedElement xmi:id="…-EnumerationsRegExp-IsoDateType" xmi:uuid="…" xmi:type="uml:DataType">
  <name>IsoDateType</name>
</packagedElement>

views - packages ending with the word "View"

<packagedElement xmi:id="…-ConceptualContentView" xmi:uuid="…" xmi:type="uml:Package">
  <elementImport xmi:id="…-ConceptualContentView-elementImport-7" xmi:uuid="…" xmi:type="uml:ElementImport">
    <importedElement xmi:idref="DDI4_PIM-ClassLibrary-Conceptual-ConceptSystem"/>

ElementImport can stand for a class, association or property. No PackageImport.

This produces a model object which is supplemented by:

classHierarchy - hierarchy of classes, e.g. AnnotationDate refines Date.
packageHierarchy - hierarchy of packages, e.g. Conceptual nests inside ClassLibrary.

RDF Model

For the corresping RDF model:

Each class, property, datatype, enumeration and literal in that enumeration is an IRI with and identifier of that entity's name prefixed with 'ddi:'
Each class and each structured (complex) datatype¹ becomes an RDF class. This class has:
- Properties - becomes an RDF property with predicate of the property name prefixed by 'ddi:'.
- Associations - becomes an RDF property with predicate of either the property name, if present, or the Association name, prefixed by 'ddi:'.
  
  Aggregations are treated as regular associations (above). Properties are annotated by an shexmi:partonomy property if the source assocations was marked as shared or composite:
¹ Neither RDF, nor the structure-defining schema languages OWL and ShEx, have a distinction between complex datatype and class.

Abstract classes are expressed as a disjoint union of their subclasses. This assumes no terminal abstract classes.

Primitive UML datatypes are mapped to their corresponding XML Schema datatype per

UML	XSD
boolean	xsd:boolean
integer	xsd:integer
double	xsd:double
LiteralUnlimitedNatural	xsd:double (n.b. "INF" for infinite values)
string	xsd:string
float	xsd:float
anyURI	xsd:anyURI

Note the the canonical representation of primitive datatypes is still uncertain. They may be expressed directly in <ownedProperty> elements or they may require an extra level of indirection to a locally-defined datatype.

OWL Representation

For the OWL representation:

The entire DDI4 UML class library is captured in a single OWL ontology.
Express in OWL/XML because protege's (OWLAPI's) error feedback is better.

For each property with a single datatype, declare that property's range. If the the property is an href or an idref to a datatype, it's a DataProperty:

<Declaration>
    <DataProperty abbreviatedIRI="ddi:uri"/>
</Declaration>
<DataPropertyRange>
    <DataProperty abbreviatedIRI="ddi:uri"/>
    <Datatype abbreviatedIRI="xsd:anyURI"/>
</DataPropertyRange>

Otherwise, it's an ObjectProperty:

<Declaration>
    <ObjectProperty abbreviatedIRI="ddi:mimeType"/>
</Declaration>
<ObjectPropertyRange>
    <ObjectProperty abbreviatedIRI="ddi:mimeType"/>
    <Class abbreviatedIRI="ddi:ExternalControlledVocabularyEntry"/>
</ObjectPropertyRange>

For each Class

Declare the class

<Declaration>
    <Class abbreviatedIRI="ddi:ConceptSystem"/>
</Declaration>

For each property with a single datatype, declare that property's range:

<SubClassOf>
    <Class abbreviatedIRI="ddi:Identifiable"/>
    <DataAllValuesFrom>
        <DataProperty abbreviatedIRI="ddi:versionDate"/>
        <Datatype abbreviatedIRI="ddi:IsoDateType"/>
    </DataAllValuesFrom>
</SubClassOf>

For each generalizes (max one because DDI has single-inheritance), express the superclass:

<SubClassOf>
    <Class abbreviatedIRI="ddi:ConceptSystem"/>
    <Class abbreviatedIRI="ddi:AnnotatedIdentifiable"/>
</SubClassOf>

For navigation, express the immidiately enclosing package:

<SubClassOf>
    <Class abbreviatedIRI="ddi:ConceptSystem"/>
    <Class abbreviatedIRI="ddi:Conceptual_Package"/>
</SubClassOf>

Per LODE, use rdfs:comment for comments.

<AnnotationAssertion>
    <AnnotationProperty abbreviatedIRI="rdfs:comment"/>
    <AbbreviatedIRI>ddi:ConceptSystem</AbbreviatedIRI>
    <Literal datatypeIRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#PlainLiteral">Definition
============
A set of Concepts structured by the relations among them. [GSIM 1.1] …
    </Literal>
</AnnotationAssertion>

Different comment types are attached to different OWL construcs:

package:	the OWL class declaration for the package
class:	the OWL class declaration for the class
property:	the OWL class declaration for the containing class
assocation:	the OWL class declaration for the containing class

Status

Right now, the UML parser emits something half-way between a UML model and an RDF model. All of the markup for the OWL and ShEx is mixed in with the main program. Fixing this involves segregating the following modules and should take about 10 days of focused work. The product should be a set of stand-alone tools that can trivially executed on this and future versions of DDI XMI.

(goal) Architecture

Once completed, this pipeline will produce all of the documents. The libraries should be independent of DDI and ideally profit from wider distribution and tool contribution. The DDI-specific module should be small and easy to maintain and clearly enumerate the DDI-specific transformations.

(NPM library) XMI parser: XMI → UML model (mostly done)
(DDI-specific) UML transforms:
- Move view packages to auxilliary Views object.
- Remove packages ending in /Pattern$/ and their embedded contents (classes, assocations, enumerations, datatypes).
- Generate distinct UML models for the different views.
(NPM library) UmlToRdf: UML model → RDF model
(NPM library) RdfToOwl: RDF model → OWL XML
(NPM library) RdfToOwl: RDF model → ShExC
(NPM library) RdfToHtml: RDF model → HTML schema explorer

Apart from the UML transformations, these can all be released as NPM packages. The DDI-specific UML transformations will import the NPM libraries. Note that the NPM conventions include a package.json file which capture version information for all imported libraries. If the some UML/RDF community extends the NPM libraries in ways that are not backward-compatible, the UML transforms script will continue to work as it; it will simply require a little work if we want to update it to use new libraries with new features.

Introduction

parsing XMI

packages

package comment

classes

class properties

property comment

class assocations

property comment

class comment

enumerations

datatypes

views - packages ending with the word "View"

RDF Model

OWL Representation

Status

(goal) Architecture

Issues