JPL's IMCE ontologies for Model-Based Systems Engineering

Scala 0.12% HTML 99.86% Shell 0.01%

gov.nasa.jpl.imce.ontologies.public's Introduction

IMCE Ontologies

gov.nasa.jpl.imce.ontologies.public's People

Contributors

Stargazers

Watchers

Forkers

mbe-shipyard atk5025-hedron

gov.nasa.jpl.imce.ontologies.public's Issues

PrimitiveTypes:UnlimitedNatural is not OML compatible.

OML does not support OWL2-DL datatype unions, which is how PrimitiveTypes:UnlimitedNatural is currently defined:

    <rdfs:Datatype rdf:about="&PrimitiveTypes;UnlimitedNatural">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:unionOf rdf:parseType="Collection">
                    <rdf:Description rdf:about="&xsd;nonNegativeInteger"/>
                    <rdfs:Datatype>
                        <owl:oneOf>
                            <rdf:Description>
                                <rdf:type rdf:resource="&rdf;List"/>
                                <rdf:first rdf:datatype="&xsd;string">*</rdf:first>
                                <rdf:rest rdf:resource="&rdf;nil"/>
                            </rdf:Description>
                        </owl:oneOf>
                    </rdfs:Datatype>
                </owl:unionOf>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>

An OML-compatible definition based on OWL2-DL datatype restrictions with OWL2-DL supported facets is as follows:

   <rdfs:Datatype rdf:about="http://imce.jpl.nasa.gov/www.omg.org/spec/PrimitiveTypes/20110701/PrimitiveTypes#UnlimitedNatural">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
                <owl:withRestrictions rdf:parseType="Collection">
                    <rdf:Description>
                        <xsd:minInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">-1</xsd:minInclusive>
                    </rdf:Description>
                </owl:withRestrictions>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>

ill-formed application of the ReifiedObjectProperty pattern in `discipline/state-analysis-functional-design`

This ontology needs to be updated to the current ReifiedObjectProperty pattern.
It is missing:

state-analysis-functional-design-backbone:topReifiedObjectProperty
Using SWRL rules instead of SubPropertyChainOf

How can mission:Interchange represent the joint behavior of a pair of mission:PerformingElements?

The description of mission:Interchange says:

An Interchange represents the intended joint behavior of a pair of PerformingElements. It indicates that a Flow or Item may be sent or emitted by one PerformingElement and received or ingested by another.

However, the ontology defines:

mission:Interchange mission:involves[12] mission:InterchangePoint
mission:Function mission:interchangesThrough mission:InterchangePoint

However, the description suggests that there should be also:

mission:PerformingElement mission:interchangesThrough mission:InterchangePoint

Since a mission:Function is not a kind of mission:PerformingElement, the above seems missing.

Ill-formed reification pattern in vandv:hasAffectsTarget

In version 1.4.1, vandv:hasAffectsTarget is ill-formed:

    <owl:ObjectProperty rdf:about="&vandv;hasAffectsTarget">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:subPropertyOf rdf:resource="&vandv-backbone;topReifiedObjectPropertyTarget"/>
        <rdfs:range rdf:resource="&vandv;Activity"/>
        <rdfs:domain rdf:resource="&vandv;Affects"/>
        <rdfs:range rdf:resource="&vandv;VerificationActivity"/>
    </owl:ObjectProperty>

The domain and range should each be a single OWL ClassExpression that is a single OWL Class.
Here, there are two ranges OWL ClassExpressions.

miscellaneous bugs in mission discovered in round-trip analysis

Change the embedding of several concepts to SysML:Block & UML:Class

According to R. Karban, NoMagic reported that MagicDraw has a lot of problems with using UML::Component stereotyped by SysML::Block; that is, SysML-metamodel#Component.Block

This was fixed for the embedding of mission:Component, i.e.:

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#PerformingElement">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryAssociationEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryDependencyEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#StructuralFullPortEncapsulatedClassifierType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML#Block"/>
</rdf:Description>

This change should have been done for all concepts across all ontologies.
In the mission ontology, this means refactoring the embedding of the following like the above:

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#Environment">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryDependencyEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML-metamodel#Component.Block"/>
</rdf:Description>

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#Function">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryAssociationEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryDependencyEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#StructuralFullPortEncapsulatedClassifierType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML-metamodel#Component.Block"/>
</rdf:Description>

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#InterchangePoint">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryAssociationEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#StructuralFlowPropertyContainerType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#StructuralFullPortType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML-metamodel#Component.Block"/>
</rdf:Description>

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#Objective">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryAssociationEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryDependencyEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML-metamodel#Component.Block"/>
</rdf:Description>

<rdf:Description rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#Product">
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/foundation/owl2-mof2/owl2-mof2#BinaryAssociationEndType"/>
    <rdfs:subClassOf rdf:resource="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML-metamodel#Component.Block"/>
</rdf:Description>

Fix the patterns in the UML/SysML ontologies

The new round-trip conversion/census testing points to three categories of discrepancies between the original OMG ontologies in OWL and those after conversion to OML and back to OWL.
list1.txt
list2.txt
list3.txt

Delete stale references to SysML:A_quantityKind_unit

This includes deleting the following as specializations of SysML:A_quantityKind_unit:

QUDV:A_quantityKind_measurementUnit
QUDV:A_noQuantityKind_prefixedUnit

Delete obsolete ontologies that do not conform to the OML patterns

[x ] List all the obsolete ontologies to be deleted.

See branch: issue-28

	deleted:    ontologies/imce.jpl.nasa.gov/discipline/electrical/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/discipline/electrical/electrical-embedding.owl
	deleted:    ontologies/imce.jpl.nasa.gov/discipline/electrical/electrical.owl
	deleted:    ontologies/imce.jpl.nasa.gov/discipline/state-analysis-functional-design/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/discipline/state-analysis-functional-design/state-analysis-functional-design-embedding.owl
	deleted:    ontologies/imce.jpl.nasa.gov/discipline/state-analysis-functional-design/state-analysis-functional-design.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architectural-description/architectural-description-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architectural-description/architectural-description.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architectural-description/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architecture-framework/architecture-framework-embedding.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architecture-framework/architecture-framework.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/architecture-framework/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/artifact/artifact.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/audit-test/audit-test-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/audit-test/audit-test.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/audit-test/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/audit-test/test-cases.als
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/flight-subsystem/flight-subsystem.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/ieee-1471/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/ieee-1471/ieee-1471-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/ieee-1471/ieee-1471.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/life-cycle/life-cycle.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/mechanical/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/mechanical/mechanical-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/mechanical/mechanical.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/pbs/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/pbs/pbs-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/pbs/pbs.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/physics/physics.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/state-analysis-implementation/MD/Control System Implementation descriptor.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/state-analysis-implementation/icons/hwa14.svg
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/state-analysis-implementation/icons/isv.svg
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/timeline/catalog-v001.xml
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/timeline/timeline-mapping.owl
	deleted:    ontologies/imce.jpl.nasa.gov/inactive/timeline/timeline.owl
	deleted:    ontologies/www.w3.org/2001/XMLSchema.xsd
	deleted:    ontologies/www.w3.org/2003/11/catalog-v001.xml
	deleted:    ontologies/www.w3.org/2003/11/swrl.owl
	deleted:    ontologies/www.w3.org/2003/g/catalog-v001.xml
	deleted:    ontologies/www.w3.org/2003/g/data-view.owl

Get Steve's confirmation that these deletions are OK.
Delete them.

Delete Protege's bogus annotation properties.

There is an odd behavior with Protege where it saves RDF/XML with new annotation properties for object properties that have been refactored. Not clear exactly how this happens....

Add the 3 label-related OML annotation properties

Per JPL-IMCE/gov.nasa.jpl.imce.oml#168

Fix stale references in *.owl files

The UML Datatype & SysML ValueType refactoring left stale references in owl files.
#62

Some SWRL rules refer to an object property in head that is not properly declared

In branch IMCEIS-1477, the mission ontology defines several SWRL inference rules like this one:

    <rdf:Description>
        <swrla:isRuleEnabled rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</swrla:isRuleEnabled>
        <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></rdfs:comment>
        <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">S29</rdfs:label>
        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#Imp"/>
        <swrl:body>
            <rdf:Description>
                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#specifies"/>
                        <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#r"/>
                        <swrl:argument2 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                        <rdf:first>
                            <rdf:Description>
                                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#ClassAtom"/>
                                <swrl:classPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#Component"/>
                                <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                            </rdf:Description>
                        </rdf:first>
                        <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
                    </rdf:Description>
                </rdf:rest>
            </rdf:Description>
        </swrl:body>
        <swrl:head>
            <rdf:Description>
                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#binds"/>
                        <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#r"/>
                        <swrl:argument2 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
            </rdf:Description>
        </swrl:head>
    </rdf:Description>

This involves a new unreified relationship, mission:binds, which is ill-formed because it lacks a domain & range class.

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#binds -->

    <owl:ObjectProperty rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#binds">
        <rdfs:subPropertyOf rdf:resource="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/foundation/mission/mission#topUnreifiedObjectProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AsymmetricProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#IrreflexiveProperty"/>
    </owl:ObjectProperty>

It seems it ought to be:

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#binds -->

    <owl:ObjectProperty rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#binds">
        <rdfs:subPropertyOf rdf:resource="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/foundation/mission/mission#topUnreifiedObjectProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AsymmetricProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#IrreflexiveProperty"/>
        <rdfs:domain rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#Requirement"/>
        <rdfs:range rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#PerformingElement"/>
    </owl:ObjectProperty>

Correct inconsistencies in the reification property pattern

There are several inconsistencies in the following ontologies:

ontologies/imce.jpl.nasa.gov/discipline/state-analysis/state-analysis.owl
ontologies/imce.jpl.nasa.gov/foundation/behavior/behavior.owl
ontologies/imce.jpl.nasa.gov/www.omg.org/spec/UML/20110701/UML.owl

Anonymous inverse property

I have been looking at the ‘project’ ontology (http://imce.jpl.nasa.gov/foundation/project/project), and I am having trouble with the following construct:

<!-- http://imce.jpl.nasa.gov/foundation/project/project#hasDeliversTarget -->

<owl:ObjectProperty rdf:about="&project;hasDeliversTarget">
    <rdf:type rdf:resource="&owl;FunctionalProperty"/>
    <rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>
    <rdfs:subPropertyOf rdf:resource="&project-backbone;topReifiedObjectPropertyTarget"/>
    <rdfs:range rdf:resource="&project;Deliverable"/>
    <rdfs:domain rdf:resource="&project;Delivers"/>
</owl:ObjectProperty>
<rdf:Description>
    <owl:inverseOf rdf:resource="&project;hasDeliversTarget"/>
</rdf:Description>

When I load this in protégé, I see the following image:

I am failing to understand the usefulness of the anonymous inverse. Could you please provide insight into the purpose of it? Thanks.

Incorrect owl2-mof2 patterns.

See: JPL-IMCE/gov.nasa.jpl.omf.scala.binding.owlapi#53

Most abstractions in owl2-mof2 should be Aspects, not Concepts.

Ill-formed reification pattern for SysML:{Quantity,Unit}

Currently, SysML:Quantity, SysML:Unit are not subclassing any of the backbone categories: SysML-backbone:{Aspect,Entity,ReifiedObjectProperty,ReifiedStructuredDataProperty,StructuredDatatype}

This means that application of the reification pattern toSysML:A_quantityKind_unit, SysML:A_valueType_quantityKind, SysML:A_valueType_unit classified as SysML-backbone:ReifiedObjectProperty is ill-formed.

Remove ObjectPropertyDependentRangeType

This was defined in an older version of the backbone for IMCE ontologies.
It is no longer relevant and should be deleted and/or substituted as appropriate.

Incorrect data properties

The problem is not with the OML/OWLAPI parser, it's with the properties themselves.

[2] “QUDV:Prefix.factor”
[3] “QUDV:QuantityKindFactor.exponent”
[4] “QUDV:UnitFactor.exponent”
[5] “UML:MultiplicityElement.upper”
[6] “UML:Operation.upper”

Lots of duplicated SWRL rules

The merge of the IMCEIS-1573 branch effectively duplicates the SWRL rules corresponding to the reification pattern.

For example:

gov.nasa.jpl.imce.ontologies.public/ontologies/imce.jpl.nasa.gov/foundation/base/base.owl

Line 858 in 17561be

<rdf:Description>

    <rdf:Description>
        <rdf:type rdf:resource="&swrl;Imp"/>
        <rdfs:label rdf:datatype="&xsd;string">contains reification rule</rdfs:label>
        <swrl:body>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="&base;hasContainsSource"/>
                        <swrl:argument1 rdf:resource="urn:swrl#r"/>
                        <swrl:argument2 rdf:resource="urn:swrl#s"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;AtomList"/>
                        <rdf:rest rdf:resource="&rdf;nil"/>
                        <rdf:first>
                            <rdf:Description>
                                <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                                <swrl:propertyPredicate rdf:resource="&base;hasContainsTarget"/>
                                <swrl:argument1 rdf:resource="urn:swrl#r"/>
                                <swrl:argument2 rdf:resource="urn:swrl#t"/>
                            </rdf:Description>
                        </rdf:first>
                    </rdf:Description>
                </rdf:rest>
            </rdf:Description>
        </swrl:body>
        <swrl:head>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:rest rdf:resource="&rdf;nil"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="&base;contains"/>
                        <swrl:argument1 rdf:resource="urn:swrl#s"/>
                        <swrl:argument2 rdf:resource="urn:swrl#t"/>
                    </rdf:Description>
                </rdf:first>
            </rdf:Description>
        </swrl:head>
    </rdf:Description>

gov.nasa.jpl.imce.ontologies.public/ontologies/imce.jpl.nasa.gov/foundation/base/base.owl

Line 903 in 17561be

<rdf:Description>

    <rdf:Description>
        <rdf:type rdf:resource="&swrl;Imp"/>
        <swrl:head>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:rest rdf:resource="&rdf;nil"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="&base;contains"/>
                        <swrl:argument1 rdf:resource="urn:swrl#s"/>
                        <swrl:argument2 rdf:resource="urn:swrl#t"/>
                    </rdf:Description>
                </rdf:first>
            </rdf:Description>
        </swrl:head>
        <swrl:body>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="&base;hasContainsSource"/>
                        <swrl:argument1 rdf:resource="urn:swrl#r"/>
                        <swrl:argument2 rdf:resource="urn:swrl#s"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;AtomList"/>
                        <rdf:rest rdf:resource="&rdf;nil"/>
                        <rdf:first>
                            <rdf:Description>
                                <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                                <swrl:propertyPredicate rdf:resource="&base;hasContainsTarget"/>
                                <swrl:argument1 rdf:resource="urn:swrl#r"/>
                                <swrl:argument2 rdf:resource="urn:swrl#t"/>
                            </rdf:Description>
                        </rdf:first>
                    </rdf:Description>
                </rdf:rest>
            </rdf:Description>
        </swrl:body>
    </rdf:Description>

The difference is that the first rule has a label; the second does not.

For OML, a SWRL rule corresponding to the reified object property pattern is not used in OML per se. However, this label could be useful for explanation purposes with OWL2-DL + SWRL reasoners.

Recommend keeping the labelled rule and delete the unlabeled rule.

Explain the differentiation between `mission:Involves` and `mission:Involves1` and `mission:Involves2`

mission:Involves1 and mission:Involves2 specialize mission:Involves.

Unless I missed something, I don't see any ontologically significant difference among them.
This is a violation of a pattern we've strived for in these ontologies -- that is, every entity of some kind (i.e. aspect, concept, reified relationship, ..) has a discernable signature of ontologically significant characteristics that uniquely distinguishes it from any other entity of the same kind.

It seems that there is something missing and this suggests that the pattern needs to be reviewed and probably revised.

OMG's "metamodel" ontologies should define aspects, not entities

Scope:
- ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/Metrology.owl
- ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/QUDV.owl
- ontologies/imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML.owl
- ontologies/imce.jpl.nasa.gov/www.omg.org/spec/UML/20110701/StandardProfileL2.owl
- ontologies/imce.jpl.nasa.gov/www.omg.org/spec/UML/20110701/UML.owl

foundation/annotation uses OWL annotation properties from dc without import.

In the OML-restricted subset of OWL, the import is necessary.

Add rdfs:label annotation to name each SWRL rule to support OML conversions

A named SWRL implication rule corresponds to an OML ChainRule.

In OML, a ChainRule has an IRI, which is, the IRI of the OML TerminologyBox with the OML ChainRule label as IRI fragment. Identifying rules is important for traceability and explanation purposes. However, identification is optional in SWRL.

From the OWL2 API perspective, a SWRL rule is an OWL logical axiom that can be annotated.
Some tools like Protege support adding a label to a rule; e.g.:

    <rdf:Description>
        <swrla:isRuleEnabled rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</swrla:isRuleEnabled>
        <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"></rdfs:comment>
        <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">S29</rdfs:label>
        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#Imp"/>
        <swrl:body>
            <rdf:Description>
                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#specifies"/>
                        <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#r"/>
                        <swrl:argument2 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                        <rdf:first>
                            <rdf:Description>
                                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#ClassAtom"/>
                                <swrl:classPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#Component"/>
                                <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                            </rdf:Description>
                        </rdf:first>
                        <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
                    </rdf:Description>
                </rdf:rest>
            </rdf:Description>
        </swrl:body>
        <swrl:head>
            <rdf:Description>
                <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#AtomList"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="http://www.w3.org/2003/11/swrl#IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#binds"/>
                        <swrl:argument1 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#r"/>
                        <swrl:argument2 rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#c"/>
                    </rdf:Description>
                </rdf:first>
                <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
            </rdf:Description>
        </swrl:head>
    </rdf:Description>

For this issue, please review each SWRL rule and add a sensible rdfs:label annotation as its identifier. The identifier must conform to the following lexical grammar:

terminal fragment LETTER:				'a'..'z'|'A'..'Z';

terminal fragment LETTER_DIGIT:		LETTER | DIGIT;

terminal fragment LETTER_DIGIT_PREFIX:	LETTER_DIGIT | '_';

terminal fragment LETTER_DIGIT_SUFFIX:	LETTER_DIGIT | '_' | '-' | '.';

terminal fragment ID_PREFIX: 			LETTER|'_';

terminal ID:							'^'? ID_PREFIX LETTER_DIGIT_SUFFIX*;

Define a special OML ontology

Even though the semantics of an OML module is defined as the semantics of the corresponding OWL2-DL + SWRL rules ontology, there is a subtle representation difference between OML and OWL:

In OML, every module is explicitly represented (in textual and tabular syntax)
In OWL, the built-in datatype map cannot be explicitly represented because it confuses the OWLAPI (as of v5.0.5); see: #15

A special OML module in OWL is needed to facilitate determining which OML modules have an explicit vs. implicit representation in OWL:

If an OML module A directly or indirectly imports this special OML module, then A has an explicit representation in OWL2-DL + SWRL rules.
If an OML module B does not directly or indirectly import this special OML module, then B has an implicit representation in OWL2-DL + SWRL rules if B's IRI corresponds to one of the built-in ontology IRIs; otherwise this is an error.

Guidance for representing UML/SysML Datatypes in OML

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:

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.

SysML-metamodel:QuantityKind lost a necessary subclass of axiom

  <rdf:Description rdf:about="http://imce.jpl.nasa.gov/www.omg.org/spec/SysML/20140311/SysML#QuantityKind">
        <rdfs:subClassOf rdf:resource="&SysML-metamodel;Class.Block"/>

inconsistent definition for behavior:{Constrains,HasAttribute,Uses}

In behavior, each is categorized as a kind of behavior-backbone:ReifiedStructuredDataProperty

In behavior-embedding, each is categorized as a kind of owl2-mof2:StructuredClassifierOwnsAttribute, which is a kind of owl2-mof2-backbone:ReifiedObjectProperty.

This is inconsistent!

The fix involves changing these definitions in behavior by categorizing them as kinds of behavior-backbone:ReifiedObjectProperty.

Note that the behavior ontology does not define vocabulary for specifying value of a behavior:AbstractValueTypedAttribute; however, there is vocabulary for specifying the type of such values (behavior:hasValueType)

Rename the catalog from 'imce.local.catalog.xml' to: 'oml.catalog.xml'

The name of the catalog file, 'imce.local.catalog.xml', was chosen a long time ago and kept as-is.

The current OML tooling requires the catalog to be named 'oml.catalog.xml'.
Whereas previously this catalog was only used for OWL (incl. Protege), in OML, this catalog is used for all conversions among the OML formats (ontology, textual, tabular).

Update OMF/OWL ontology per revised OMF/Schema

Fix broken oml header

Update the FSE vocabulary to reflect the 3 levels of FSE topology.

During the meeting of 2017/11/01, Carlos M Gross Jones clarified that there are three levels of EFSE modeling involved in Capital tools (Systems, Architect, Integrator, Logic, ...):

Signal level
This shows information flowing from one port on an assembly to another port on an assembly.
Net level
A port connected to another port means that there is some kind of electrical connection between them allowing electrons to flow.
- Many signal-level flows amongst different input/output signal-level ports can be mapped to the same net-level connection between a pair of net-level ports to which the signal-level ports map.
- A given signal-level flow can be mapped to multiple net-level connections; which entails mapping the input and output signal-level ports to the corresponding multiple net-level ports.
- Example: PoE (Power over Ethernet)
Physical level
- A given wire connects exactly 2 terminals.
- A terminal can be either a pin or a splice.
- A net-level connection can be mapped to multiple wires establishing a path between two physical pins corresponding to the net-level ports.

`base:Package` is not a `base:Container`

In the CAESAR demo, there is a pattern that involves containment trees of base:Package.
This is currently illegal without making base:Package a kind of base:Container.

Update the backbone in annotation & oml

$every entity declared in some ontology$pass.before.minus.after
[1] “annotation-backbone:topStructuredDataProperty”
$every entity declared in some ontology$pass.after.minus.before
[1] “annotation-backbone:Aspect”
[2] “annotation-backbone:ReifiedStructuredDataProperty”
[3] “annotation-backbone:topReifiedObjectPropertySource”
[4] “annotation-backbone:topReifiedObjectPropertyTarget”
[5] “annotation-backbone:topReifiedStructuredDataProperty”
[6] “annotation-backbone:topReifiedStructuredDataPropertySource”
[7] “annotation-backbone:topReifiedStructuredDataPropertyTarget”
[8] “annotation-backbone:topUnreifiedObjectProperty”
[9] “oml-backbone:Aspect”
[10] “oml-backbone:Entity”
[11] “oml-backbone:ReifiedObjectProperty”
[12] “oml-backbone:ReifiedStructuredDataProperty”
[13] “oml-backbone:StructuredDatatype”
[14] “oml-backbone:Thing”
[15] “oml-backbone:topDataProperty”
[16] “oml-backbone:topObjectProperty”
[17] “oml-backbone:topReifiedObjectProperty”
[18] “oml-backbone:topReifiedObjectPropertySource”
[19] “oml-backbone:topReifiedObjectPropertyTarget”
[20] “oml-backbone:topReifiedStructuredDataProperty”
[21] “oml-backbone:topReifiedStructuredDataPropertySource”
[22] “oml-backbone:topReifiedStructuredDataPropertyTarget”
[23] “oml-backbone:topUnreifiedObjectProperty”

Note that this needs to be coordinated with the OML/OWLAPI backbone update for this issue: JPL-IMCE/gov.nasa.jpl.omf.scala.binding.owlapi#63

Ill-formed SWRL rule in discipline/fault-management

In version 1.4.1, the ill-formed rule is the following:

    <rdf:Description>
        <rdf:type rdf:resource="&swrl;Imp"/>
        <swrl:body>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:rest>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;AtomList"/>
                        <rdf:rest>
                            <rdf:Description>
                                <rdf:type rdf:resource="&swrl;AtomList"/>
                                <rdf:rest>
                                    <rdf:Description>
                                        <rdf:type rdf:resource="&swrl;AtomList"/>
                                        <rdf:rest>
                                            <rdf:Description>
                                                <rdf:type rdf:resource="&swrl;AtomList"/>
                                                <rdf:rest rdf:resource="&rdf;nil"/>
                                                <rdf:first>
                                                    <rdf:Description>
                                                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                                                        <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/analysis/analysis#explains"/>
                                                        <swrl:argument2 rdf:resource="urn:swrl#B"/>
                                                        <swrl:argument1 rdf:resource="urn:swrl#V"/>
                                                    </rdf:Description>
                                                </rdf:first>
                                            </rdf:Description>
                                        </rdf:rest>
                                        <rdf:first>
                                            <rdf:Description>
                                                <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                                                <swrl:propertyPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/analysis/analysis#analyzes"/>
                                                <swrl:argument2 rdf:resource="urn:swrl#P"/>
                                                <swrl:argument1 rdf:resource="urn:swrl#V"/>
                                            </rdf:Description>
                                        </rdf:first>
                                    </rdf:Description>
                                </rdf:rest>
                                <rdf:first>
                                    <rdf:Description>
                                        <rdf:type rdf:resource="&swrl;ClassAtom"/>
                                        <swrl:classPredicate rdf:resource="http://imce.jpl.nasa.gov/foundation/behavior/behavior#ElementBehavior"/>
                                        <swrl:argument1 rdf:resource="urn:swrl#B"/>
                                    </rdf:Description>
                                </rdf:first>
                            </rdf:Description>
                        </rdf:rest>
                        <rdf:first>
                            <rdf:Description>
                                <rdf:type rdf:resource="&swrl;ClassAtom"/>
                                <swrl:classPredicate rdf:resource="&fault-management;ViolationExplanation"/>
                                <swrl:argument1 rdf:resource="urn:swrl#V"/>
                            </rdf:Description>
                        </rdf:first>
                    </rdf:Description>
                </rdf:rest>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;ClassAtom"/>
                        <swrl:classPredicate rdf:resource="&fault-management;PerformanceConstraint"/>
                        <swrl:argument1 rdf:resource="urn:swrl#P"/>
                    </rdf:Description>
                </rdf:first>
            </rdf:Description>
        </swrl:body>
        <swrl:head>
            <rdf:Description>
                <rdf:type rdf:resource="&swrl;AtomList"/>
                <rdf:rest rdf:resource="&rdf;nil"/>
                <rdf:first>
                    <rdf:Description>
                        <rdf:type rdf:resource="&swrl;IndividualPropertyAtom"/>
                        <swrl:propertyPredicate rdf:resource="&fault-management;violates"/>
                        <swrl:argument1 rdf:resource="urn:swrl#B"/>
                        <swrl:argument2 rdf:resource="urn:swrl#P"/>
                    </rdf:Description>
                </rdf:first>
            </rdf:Description>
        </swrl:head>
    </rdf:Description>

In compact notation, this rule says:

fault-management:PerformanceConstraint(?P) ^ 
fault-management:ViolationExplanation(?V) ^ 
behavior:ElementBehavior(?B) ^ 
analysis:analyzes(?V, ?P) ^ 
analysis:explains(?V, ?B) -> 
fault-management:violates(?B, ?P)

It should be instead:

behavior:ElementBehavior(?B) ^ 
inverseOf(analysis:explains(?V, ?B))  ^ 
fault-management:ViolationExplanation(?V) ^ 
analysis:analyzes(?V, ?P) ^ 
fault-management:PerformanceConstraint(?P)-> 
fault-management:violates(?B, ?P)

or equivalently:

behavior:ElementBehavior(?B) ^ 
analysis:isExplainedBy(?B, ?V)  ^ 
fault-management:ViolationExplanation(?V) ^ 
analysis:analyzes(?V, ?P) ^ 
fault-management:PerformanceConstraint(?P)-> 
fault-management:violates(?B, ?P)

Bizarre OWL2API parsing problem with datatypes

Converting from OWL => OML requires mapping OWL datatype definitions as OML scalar data ranges.

Two variants of OWL datatypes seem to pose problems with the OWL2API v5.0.5 currently used:

Datatype restriction

    <rdfs:Datatype rdf:about="&PrimitiveTypes;UnlimitedNatural">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:onDatatype rdf:resource="&xsd;integer"/>
                <owl:withRestrictions rdf:parseType="Collection">
                    <rdf:Description>
                        <xsd:minInclusive rdf:datatype="&xsd;integer">-1</xsd:minInclusive>
                    </rdf:Description>
               </owl:withRestrictions>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>

Asking the OWLAPI for the definition of PrimitiveTypes:UnlimitedNatural returns an error IRI like this: <http://org.semanticweb.owlapi/error#Error9>.

Enumeration of literals


    <rdfs:Datatype rdf:about="&UML;VisibilityKind">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:oneOf>
                    <rdf:Description>
                        <rdf:type rdf:resource="&rdf;List"/>
                        <rdf:first rdf:datatype="&xsd;string">package</rdf:first>
                        <rdf:rest>
                            <rdf:Description>
                                <rdf:type rdf:resource="&rdf;List"/>
                                <rdf:first rdf:datatype="&xsd;string">private</rdf:first>
                                <rdf:rest>
                                    <rdf:Description>
                                        <rdf:type rdf:resource="&rdf;List"/>
                                        <rdf:first rdf:datatype="&xsd;string">protected</rdf:first>
                                        <rdf:rest>
                                            <rdf:Description>
                                                <rdf:type rdf:resource="&rdf;List"/>
                                                <rdf:first rdf:datatype="&xsd;string">public</rdf:first>
                                                <rdf:rest rdf:resource="&rdf;nil"/>
                                            </rdf:Description>
                                        </rdf:rest>
                                    </rdf:Description>
                                </rdf:rest>
                            </rdf:Description>
                        </rdf:rest>
                    </rdf:Description>
                </owl:oneOf>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>
    
    <rdfs:Datatype rdf:about="&UML;ParameterEffectKind">
        <owl:equivalentClass>
            <rdfs:Datatype>
                <owl:oneOf>
                    <rdf:Description>
                        <rdf:type rdf:resource="&rdf;List"/>
                        <rdf:first rdf:datatype="&xsd;string">create</rdf:first>
                        <rdf:rest>
                            <rdf:Description>
                                <rdf:type rdf:resource="&rdf;List"/>
                                <rdf:first rdf:datatype="&xsd;string">delete</rdf:first>
                                <rdf:rest>
                                    <rdf:Description>
                                        <rdf:type rdf:resource="&rdf;List"/>
                                        <rdf:first rdf:datatype="&xsd;string">read</rdf:first>
                                        <rdf:rest>
                                            <rdf:Description>
                                                <rdf:type rdf:resource="&rdf;List"/>
                                                <rdf:first rdf:datatype="&xsd;string">update</rdf:first>
                                                <rdf:rest rdf:resource="&rdf;nil"/>
                                            </rdf:Description>
                                        </rdf:rest>
                                    </rdf:Description>
                                </rdf:rest>
                            </rdf:Description>
                        </rdf:rest>
                    </rdf:Description>
                </owl:oneOf>
            </rdfs:Datatype>
        </owl:equivalentClass>
    </rdfs:Datatype>

Usually, the OWLAPI provides the correct definition for UML:VisibilityKind but provides an error IRI for the definition of UML:ParameterEffectKind.

With Protege 5.2.0, loading these ontologies produces errors in the log:

2017-06-19 12:45:05.632 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error2 for type Class
2017-06-19 12:45:05.636 [pool-4-thread-1] INFO  OntologyLoader    Finished loading imported ontology at file:/opt/local/imce/users/nfr/github.imce/gov.nasa.jpl.imce.ontologies.public/ontologies/imce.jpl.nasa.gov/www.omg.org/spec/PrimitiveTypes/20110701/PrimitiveTypes.owl
2017-06-19 12:45:06.002 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error3 for type Datatype
2017-06-19 12:45:06.006 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error4 for type Datatype
2017-06-19 12:45:06.007 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error5 for type Datatype
2017-06-19 12:45:06.008 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error6 for type Datatype
2017-06-19 12:45:06.009 [pool-4-thread-1] ERROR OWLRDFConsumer    Entity not properly recognized, missing triples in input? http://org.semanticweb.owlapi/error#Error7 for type Datatype

Why is a mission:Component not a base:AggregatedElement?

Without this, we can't say that a mission:Component base:aggregates mission:Component.

Fix minor inconsistencies in UML.

Delete stale OWL annotations in *-metamodel.owl

JPL willing to release corresponding IMCE sysml profiles?

Hey all, I am just wondering if releasing the corresponding sysml profiles is in the plans / possible?
thanks!

Incomplete application of the ReifiedObjectProperty pattern to `electrical:Provides`

Currently, the ontology has:


    <!-- http://imce.jpl.nasa.gov/discipline/electrical/electrical#isProvidedBy -->

    <owl:ObjectProperty rdf:about="&electrical;isProvidedBy">
        <rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>
        <annotation:isDerived rdf:datatype="&xsd;boolean">true</annotation:isDerived>
        <rdfs:subPropertyOf rdf:resource="&electrical-backbone;topObjectProperty"/>
        <rdfs:range rdf:resource="&electrical;ChannelInterface"/>
        <rdfs:domain rdf:resource="&electrical;LinkInterface"/>
    </owl:ObjectProperty>
    


    <!-- http://imce.jpl.nasa.gov/discipline/electrical/electrical#provides -->

    <owl:ObjectProperty rdf:about="&electrical;provides">
        <rdf:type rdf:resource="&owl;AsymmetricProperty"/>
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdf:type rdf:resource="&owl;IrreflexiveProperty"/>
        <rdfs:subPropertyOf rdf:resource="&electrical-backbone;topObjectProperty"/>
        <rdfs:domain rdf:resource="&electrical;ChannelInterface"/>
        <rdfs:range rdf:resource="&electrical;LinkInterface"/>
        <owl:inverseOf rdf:resource="&electrical;isProvidedBy"/>
    </owl:ObjectProperty>

But it needs instead:

    <!-- http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/discipline/electrical/electrical#topReifiedObjectProperty -->

    <owl:ObjectProperty rdf:about="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/discipline/electrical/electrical#topReifiedObjectProperty">
        <rdfs:subPropertyOf rdf:resource="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/discipline/electrical/electrical#topObjectProperty"/>
    </owl:ObjectProperty>
    
    <!-- http://imce.jpl.nasa.gov/discipline/electrical/electrical#isProvidedBy -->

    <owl:ObjectProperty rdf:about="http://imce.jpl.nasa.gov/discipline/electrical/electrical#isProvidedBy">
        <rdfs:subPropertyOf rdf:resource="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/discipline/electrical/electrical#topReifiedObjectProperty"/>
        <owl:inverseOf rdf:resource="http://imce.jpl.nasa.gov/discipline/electrical/electrical#provides"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#InverseFunctionalProperty"/>
        <rdfs:domain rdf:resource="http://imce.jpl.nasa.gov/discipline/electrical/electrical#LinkInterface"/>
        <rdfs:range rdf:resource="http://imce.jpl.nasa.gov/discipline/electrical/electrical#ChannelInterface"/>
        <annotation:isDerived rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</annotation:isDerived>
    </owl:ObjectProperty>
    


    <!-- http://imce.jpl.nasa.gov/discipline/electrical/electrical#provides -->

    <owl:ObjectProperty rdf:about="http://imce.jpl.nasa.gov/discipline/electrical/electrical#provides">
        <rdfs:subPropertyOf rdf:resource="http://imce.jpl.nasa.gov/backbone/imce.jpl.nasa.gov/discipline/electrical/electrical#topReifiedObjectProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AsymmetricProperty"/>
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#IrreflexiveProperty"/>
        <rdfs:domain rdf:resource="http://imce.jpl.nasa.gov/discipline/electrical/electrical#ChannelInterface"/>
        <rdfs:range rdf:resource="http://imce.jpl.nasa.gov/discipline/electrical/electrical#LinkInterface"/>
    </owl:ObjectProperty>

Incorrect reification pattern in mission:IsTraversedBy

In version 1.4.6:

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#hasIsTraversedBySource -->

    <owl:ObjectProperty rdf:about="&mission;hasIsTraversedBySource">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:subPropertyOf rdf:resource="&mission-backbone;topReifiedObjectPropertySource"/>
        <rdfs:domain rdf:resource="&mission;IsTraversedBy"/>
        <rdfs:range rdf:resource="&mission;Junction"/>
        <rdfs:domain rdf:resource="&mission;Traverses"/>
    </owl:ObjectProperty>

This should be:

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#hasIsTraversedBySource -->

    <owl:ObjectProperty rdf:about="&mission;hasIsTraversedBySource">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:subPropertyOf rdf:resource="&mission-backbone;topReifiedObjectPropertySource"/>
        <rdfs:domain rdf:resource="&mission;IsTraversedBy"/>
        <rdfs:range rdf:resource="&mission;Junction"/>
    </owl:ObjectProperty>

In version 1.4.6:

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#hasIsTraversedByTarget -->

    <owl:ObjectProperty rdf:about="&mission;hasIsTraversedByTarget">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:subPropertyOf rdf:resource="&mission-backbone;topReifiedObjectPropertyTarget"/>
        <rdfs:domain rdf:resource="&mission;IsTraversedBy"/>
        <rdfs:domain rdf:resource="&mission;Traverses"/>
        <rdfs:range rdf:resource="&mission;TraversingElement"/>
    </owl:ObjectProperty>

This should be:

    <!-- http://imce.jpl.nasa.gov/foundation/mission/mission#hasIsTraversedByTarget -->

    <owl:ObjectProperty rdf:about="&mission;hasIsTraversedByTarget">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:subPropertyOf rdf:resource="&mission-backbone;topReifiedObjectPropertyTarget"/>
        <rdfs:domain rdf:resource="&mission;IsTraversedBy"/>
        <rdfs:range rdf:resource="&mission;TraversingElement"/>
    </owl:ObjectProperty>

Delete the obsolete OMF metadata ontology.

The OMF metadata ontology was a precursor to the current OML:

OWL Classes annotated omf:isAbstract=false correspond to concrete OML metaclasses.
For example:

omf:ModelEntityAspect corresponds to oml:Aspect
omf:ModelEntityConcept corresponds to oml:Concept
omf:ModelEntityReifiedRelationship corresponds to oml:ReifiedRelationship

Since the OWL2-DL + SWRL representation of, e.g., an omf:ModelEntityReifiedRelationship involves a complex pattern of multiple OWL2-DL entities, including:

an OWL2-DL Class representing the omf:ModelEntityReifiedRelationship as a class;
an OWL2-DL ObjectProperty representing the omf:ModelEntityReifiedRelationship as a relation;
a pair of OWL2-DL ObjectProperties representing the domain and range of that relation;
a SWRL rule encoding the logical entailment of a relationship fact from assertions about an instance of the class and of the domain/range relationships.

Recognizing this pattern is non-trivial and error prone because one has to be careful about discerning the use of OWL2-DL Class for representing OML/OMF Aspects, Concepts, ReifiedRelationships or StructuredDatatypes as well as discerning the use of OWL2-DL ObjectProperty for representing OML/OMF ReifiedRelationships (as a property, or its domain or its range or its inverse) or an OML/OMF UnreifiedRelationship or an OML/OMF StructuredDataProperty or an OML/OMF EntityStructuredDataProperty.

The OMF metadata ontology provided an OWL2-DL instance-level representation that was simpler to parse because each individual was classified in terms of the kind of OML/OMF thing it is representing and related explicitly with other OML/OMF individuals via OML/OMF object properties.

The definition of OML as an explicit language now alleviates the need for the OMF metadata ontology.

Update OML ontology for the different kinds of OML Modules

In OML, a TerminologyBox can be open or closed; a DescriptionBox can be final or partial.
Add annotation properties to represent this information in OWL2-DL

[foundation/behavior] ill-formed AbstractValueType

Currently, this datatype is defined as follows:

 <rdfs:Datatype rdf:about="http://imce.jpl.nasa.gov/foundation/behavior/behavior#AbstractValueType"/>

The OML subset of OWL2-DL requires that every datatype must be either:

a built-in datatype defined in the OWL2-DL datatype map
(see https://www.w3.org/TR/owl2-syntax/#Datatype_Maps)
defined using the OWL2-DL vocabulary as a direct or indirect restriction of a built-in datatype defined in the OWL2-DL datatype map

This restriction ensures that an OWL2-DL reasoner that supports the OWL2-DL datatype map should support reasoning about OML modules including datatypes.

discipline/electrical: ill-formed reified object property pattern for :Provides

The OML Converter reports an error for http://imce.jpl.nasa.gov/discipline/electrical/electrical

Basically this ontology has an incomplete backbone, it is missing:

Declaration( ObjectProperty( electrical-backbone:topReifiedObjectProperty ))
SubObjectPropertyOf( electrical-backbone:topReifiedObjectProperty, electrical-backbone:topObjectProperty )
SubObjectPropertyOf( electrical:provides, electrical-backbone:topReifiedObjectProperty)

foundation/annotation needs to import owl explicitly instead of XMLSchema

In OWL, importing OWL is superfluous; however, in OML, it is necessary to reference the "built-in" vocabulary, particularly the datatypes in scope of the OWL2-DL datatype map.

Per https://www.w3.org/TR/owl2-syntax/#Datatype_Maps, the OWL2 DL datatype map includes datatypes from OWL, RDF and XSD.

Since imports are transitive, it is sufficient to import OWL for each "topmost" ontology.
In the case of the IMCE ontologies, that's foundation/annotation.

Add OML UUID annotation for provenance

For the mapping from OML => OWL, it is useful to annotate each OWL axiom with the UUID of the corresponding OML element.

Delete bogus self inverses of source/target reified object properties & superfluous double inverses

Several reified object property sources/targets are declared to be the inverses of themselves.
This makes no sense at all.