Add support for OML EntityRestrictionAxiom about forward or inverse property.

There is an unfortunate limitation in the Eclipse XText grammar support for cross-references.

Version 0.9.0.7's definition of OML EntityRelationships (Reified & Unreified) is summarized as follows:

abstract class EntityRelationship extends Term, DirectedBinaryRelationshipKind {
    refers Entity[1] source
    refers Entity[1] target
        ...
}

class ReifiedRelationship extends EntityRelationship, ConceptualEntity {
    LocalName[1] unreifiedPropertyName
    LocalName[?] unreifiedInversePropertyName
}

class UnreifiedRelationship extends EntityRelationship {}

Note that, by inheritance, the XText cross-referencable identifier of a ReifiedRelationship is an inherited name attribute. In particular, unreifiedPropertyName and unreifiedInversePropertyName are not cross-referencable in XText.

This enabled defining version 0.9.0.7 of OML EntityRelationshipRestrictions (Existential & Universal) as summarized below:

abstract class EntityRestrictionAxiom extends TermAxiom, ElementCrossReferenceTuple {
     refers EntityRelationship[1] restrictedRelation
     refers Entity[1] restrictedRange
     refers Entity[1] restrictedDomain
}

class EntityExistentialRestrictionAxiom extends EntityRestrictionAxiom {}

class EntityUniversalRestrictionAxiom extends EntityRestrictionAxiom {}

In Version 0.9.0.7, the XText parsing rules for EntityRelationshipRestrictions are summarized as follows:

EntityRestrictionAxiom returns EntityRestrictionAxiom:
    EntityExistentialRestrictionAxiom | 
    EntityUniversalRestrictionAxiom;

EntityExistentialRestrictionAxiom returns EntityExistentialRestrictionAxiom:
    'someEntities'
    restrictedDomain=[Entity|Reference]
    '.' 
    restrictedRelation=[EntityRelationship|Reference]
    'in' restrictedRange=[Entity|Reference];

EntityUniversalRestrictionAxiom returns EntityUniversalRestrictionAxiom:
    'allEntities'
    restrictedDomain=[Entity|Reference]
    '.' 
    restrictedRelation=[EntityRelationship|Reference]
    'in' restrictedRange=[Entity|Reference];

Since unreifiedPropertyName and unreifiedInversePropertyName are not cross-referencable in XText, the OML abstract syntax metamodel has to be changed so that they can be independently cross-referencable. This is a significant change in the OML abstract syntax.

Given that the limitation comes from the XText cross-referencing mechanism, it makes sense to explore the possible ways to fix this problem from the perspective of what change in the concrete syntax of OML makes sense to go with.

As of version 0.9.0.7, the concrete syntax for EntityRestrictionAxiom defined above yields the following examples:

// in the IMCE mission ontology:

    allEntities Component . base:Aggregates in Component

    allEntities Component . base:Contains in Component

    allEntities Function . Invokes in Function

    allEntities Product . base:Aggregates in base:AggregatedElement

// in the IMCE project ontology:

    allEntities DevelopmentState . analysis:Characterizes in DevelopedElement

    allEntities WorkPackage . Supplies in mission:Component

By convention, the names of OML ReifiedRelationships is a positive verb with an initial capital letter, e.g., Contains, Supplies, Aggregates, Characterizes, which in OWL2 corresponds to an OWL2 Class (the reified relationship).

However, it would be more correct to use the names of the unreified properties in these restriction axioms because the unreified properties precisely correspond to the OWL2 ObjectProperties that are involved in the corresponding OWL2 restriction axioms. By convention, the names of the unreified properties is the lowercase initial name of the OML ReifiedRelationship verb.

That is, a better concrete syntax would involve the name of the unreified property of an OML ReifiedRelationship (i.e., lowercase initial positive verb) as shown below:

// in the IMCE mission ontology:

    allEntities Component . base:aggregates in Component

    allEntities Component . base:contains in Component

    allEntities Function . invokes in Function

        allEntities Environment . base:Aggregates in Environment

    allEntities Product . base:aggregates in base:AggregatedElement

// in the IMCE project ontology:

    allEntities DevelopmentState . analysis:characterizes in DevelopedElement

    allEntities WorkPackage . supplies in mission:Component

In terms of the original issue, https://github.com/JPL-IMCE/gov.nasa.jpl.omf.scala.binding.owlapi/issues/68, the roundtrip is missing two restrictions that involve the inverses of OML ReifiedRelationships, which by convention, are the lowercase names of the passive voice of the OML ReifiedRelationship verb.

In that issue, the missing axioms in OWL2 were:

    <owl:Class rdf:about="http://imce.jpl.nasa.gov/foundation/mission/mission#Component">
        ...
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://imce.jpl.nasa.gov/foundation/base/base#isAggregatedIn"/>
                <owl:allValuesFrom rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#Component"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://imce.jpl.nasa.gov/foundation/base/base#isContainedIn"/>
                <owl:allValuesFrom rdf:resource="http://imce.jpl.nasa.gov/foundation/mission/mission#Component"/>
            </owl:Restriction>
        </rdfs:subClassOf>
    </owl:Class>

Based on the above, it would make sense to use the name of the inverse property of an OML ReifiedRelationship (i.e., lowercase initial name of the passive voice of the OML ReifiedRelationship verb) as shown below:

    allEntities Component . base:isAggregatedIn in Component

    allEntities Component . base:isContainedIn in Component

Taken together, this would yield a syntactically uniform concrete syntax that unambiguously distinguishes between restricting the unreified property or the unreified inverse property:

    allEntities Component . base:contains in Component

    allEntities Component . base:isContainedIn in Component

    allEntities Component . base:aggregates in Component

        allEntities Component . base:isAggregatedIn in Component

A legitimate question is whether it is necessary to do this.

Hopefully, the following example will suffice to convince about this necessity:

    allEntities Product . base:aggregates in base:AggregatedElement

Clearly, it would be incorrect to infer from the above the following:

    allEntities base:AggregatedElement . base:isAggregatedIn in Product

Given that the above also included the following axiom:

       allEntities Environment . base:Aggregates in Environment

The incorrect inference would effectively force every Environment to be base:isAggregatedIn some Product; which is absurd.

In conclusion, there is a definite need for supporting a concrete syntax that distinguishes between referring to either an unreified property or an unreified inverse property of an OML ReifiedRelationship.

Given the necessity of that distinction, it makes sense to revisit the concrete syntax for OML ChainRules which also refers to the unreified property or unreified inverse property of an OML ReifiedRelationship. However in that case, the mechanism currently used to make this distinction involves an 'inverse' keyword but the concrete syntax refers either way to the OML ReifiedRelaitonship. Given the above change for relationship restrictions, it makes sense to simplify the syntax of chain rules to also refer directly to the unreified property or unreified inverse property thereby eliminating the need for the 'inverse' keyword.

JPL-IMCE / gov.nasa.jpl.imce.oml

Add support for OML EntityRestrictionAxiom about forward or inverse property. #208