search

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

Ontology Modeling Language (OML) Workbench
14 stars 1 forks source link

Restore the old ReifiedRelationshipSpecialization pattern #251

Closed NicolasRouquette closed 6 years ago

NicolasRouquette commented 6 years ago

https://github.com/JPL-IMCE/gov.nasa.jpl.imce.oml/issues/238 replaced the old ReifiedRelationshipSpecialization pattern with a new SpecializedReifiedRelationship pattern.

However, the current IMCE ontologies make use of the old pattern.

Q: How many patterns are needed for specializing a ReifiedRelationship?

A: There are six different patterns:

1) Full specialization pattern.

This pattern involves an axiom asserting that a child reified relationship is a specialization of a parent reified relationship where both child and parent are defined as reified relationships.

Example:

reifiedRelationship Characterizes {
    asymmetric
    irreflexive
    unreified = characterizes
    inverse = isCharacterizedBy
    source = Characterization
    target = CharacterizedElement }

reifiedRelationship Explains {
    asymmetric
    irreflexive
    unreified = explains
    inverse = isExplainedBy
    source = Explanation
    target = CharacterizedElement }

Explains extendsRelationship Characterizes

2) Specialization by restriction pattern

This pattern involves an universal entity restriction axioms that, in the context of a specific domain, restrict a reified relationship to a specific range.

The main difference with the full specialization pattern is that the specialization is not explicitly reified; consequently, the use of the specialization is in terms of the vocabulary of the general reified relationship.

concept Device
Device extendsConcept CharacterizedElement

concept ElectricalDevice
ElectricalDevice extendsConcept Device

concept MechanicalDevice
MechanicalDevice extendsConcept Device

concept ElectroMechanicalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice

concept FailureExplanation
FailureExplanation extendsConcept Explanation

concept ElectricalFailureExplanation
ElectricalFailureExplanation extendsConcept FailureExplanation

concept MechanicalFailureExplanation
MechanicalFailureExplanation extendsConcept FailureExplanation

concept ElectroMechanicalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept ElectricalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept MechanicalFailureExplanation

allEntities FailureExplanation .  explains in Device
allEntities ElectricalFailureExplanation .  explains in ElectricalDevice
allEntities MechanicalFailureExplanation .  explains in MechanicalDevice
allEntities ElectroMechanicalFailureExplanation .  explains in ElectroMechanicalDevice

3) Specialization by inclusion pattern

This pattern involves an existential entity restriction axioms that, in the context of a specific domain, restrict a reified relationship to include some elements of a specific range.

The main difference with the full specialization pattern is that the specialization is not explicitly reified; consequently, the use of the specialization is in terms of the vocabulary of the general reified relationship.

The main difference with the restriction pattern is that the inclusion pattern requires the specialization to include at least a relation tuple whose range is in the restricted target.

concept Device
Device extendsConcept CharacterizedElement

concept ElectricalDevice
ElectricalDevice extendsConcept Device

concept MechanicalDevice
MechanicalDevice extendsConcept Device

concept ElectroMechanicalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice

concept FailureExplanation
FailureExplanation extendsConcept Explanation

concept ElectricalFailureExplanation
ElectricalFailureExplanation extendsConcept FailureExplanation

concept MechanicalFailureExplanation
MechanicalFailureExplanation extendsConcept FailureExplanation

concept ElectroMechanicalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept ElectricalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept MechanicalFailureExplanation

someEntities FailureExplanation .  explains in Device
someEntities ElectricalFailureExplanation .  explains in ElectricalDevice
someEntities MechanicalFailureExplanation .  explains in MechanicalDevice
someEntities ElectroMechanicalFailureExplanation .  explains in ElectroMechanicalDevice

4) Specialization by inclusive restriction pattern

This pattern is the combination of the specialization by restriction and by inclusion patterns.

The main difference with the full specialization pattern is that the specialization is not explicitly reified; consequently, the use of the specialization is in terms of the vocabulary of the general reified relationship.

The main difference with the restriction pattern is that the inclusive restriction pattern forces the specialization to include at least a relation tuple.

The main difference with the inclusion pattern is that all relation tuples must involve elements in the restricted source and target.

concept Device
Device extendsConcept CharacterizedElement

concept ElectricalDevice
ElectricalDevice extendsConcept Device

concept MechanicalDevice
MechanicalDevice extendsConcept Device

concept ElectroMechanicalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice
ElectroMechanicalDevice extendsConcept ElectricalDevice

concept FailureExplanation
FailureExplanation extendsConcept Explanation

concept ElectricalFailureExplanation
ElectricalFailureExplanation extendsConcept FailureExplanation

concept MechanicalFailureExplanation
MechanicalFailureExplanation extendsConcept FailureExplanation

concept ElectroMechanicalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept ElectricalFailureExplanation
ElectroMechanicalFailureExplanation extendsConcept MechanicalFailureExplanation

allEntities FailureExplanation .  explains in Device
allEntities ElectricalFailureExplanation .  explains in ElectricalDevice
allEntities MechanicalFailureExplanation .  explains in MechanicalDevice
allEntities ElectroMechanicalFailureExplanation .  explains in ElectroMechanicalDevice

someEntities FailureExplanation .  explains in Device
someEntities ElectricalFailureExplanation .  explains in ElectricalDevice
someEntities MechanicalFailureExplanation .  explains in MechanicalDevice
someEntities ElectroMechanicalFailureExplanation .  explains in ElectroMechanicalDevice

5) Partial specialization pattern

This pattern is a variant of the full specialization pattern that avoids creating new specialized vocabulary. 

concept StarTracker_647
every StarTracker_647 . id = 246

StarTracker_647 extendsConcept ElectricalDevice

concept ElectricalFailureExplanation_246
every ElectricalFailureExplanation_246 . id = 246

ElectricalFailureExplanation_246 extendsConcept ElectricalFailureExplanation

reifiedRelationship ElectricalFailureExplanation_246_explains_StarTracker_647 extends Explains {
    source = ElectricalFailureExplanation_246
    target = StarTracker_647 }

6) Partial specialization with inclusion pattern

This pattern is the combination of partial specialization and specialization by inclusion patterns.

concept StarTracker_647
every StarTracker_647 . id = 246

StarTracker_647 extendsConcept ElectricalDevice

concept ElectricalFailureExplanation_246
every ElectricalFailureExplanation_246 . id = 246

ElectricalFailureExplanation_246 extendsConcept ElectricalFailureExplanation

reifiedRelationship ElectricalFailureExplanation_246_explains_StarTracker_647 extends Explains {
    source = ElectricalFailureExplanation_246
    target = StarTracker_647 }

someEntities ElectricalFailureExplanation_246 . explains in StarTracker_647
NicolasRouquette commented 6 years ago

Current OML already supports the restriction and inclusion based patterns. After discussion, it is clear that both full and partial specialization patterns are needed; however, it is unclear what OML syntax will result in unambiguous, bidirectional mapping to/from OWL.

The OML syntax introduced in https://github.com/JPL-IMCE/gov.nasa.jpl.imce.oml/issues/238 is insufficient because it supports only one specialization parent.

To explore the possible options and constraints, consider the following:

concept A1
concept B1
reifiedRelationship U1 { 
   unreified = u1 
   source = A1 
   target = B1 
}

concept C1
concept D1
reifiedRelationship V1 { 
  unreified = v1
  source = C1
  target = D1
}

concept A2
A2 extendsConcept A1

concept B2
B2 extendsConcept B1

concept A3
A3 extendsConcept A2

concept B3
B3 extendsConcept B2

concept C2
C2 extendsConcept C1

concept D2
D2 extendsConcept D1

concept C3
C3 extendsConcept C2

concept D3
D3 extendsConcept D2

concept E
E extendsConcept A3
E extendsConcept C3

concept F
F extendsConcept B3
F extendsConcept D3

concept G
G extendsConcept E

concept H
H extendsConcept F

The objective is to define 6 reification specializations:

The current proposal involves an OML syntax like this:

reifiedRelationship U2 {
   unreified u2
   source A2
   target B2
}

U2 extendsRelationship U1

partial reifiedRelationship U3 {
   source A3
   target B3
}

U3 extendsRelationship U2

partial reifiedRelationship V2 {
   source C2
   target D2
}

V2 extendsRelationship V1

partial reifiedRelationship V3 {
   source C3
   target D3
}

V3 extendsRelationship V2

partial reifiedRelationship W {
  source E
  target F
}

W extendsRelationship U2
W extendsRelationship V3

reifiedRelationship X {
   unreified x
   source G
   target H
}

X extendsRelationship W

This syntax would be subject to the following constraints:

1) partial reifiedRelationship is only valid in an OML TerminologyBox 2) extendsRelationship is only valid in an OML TerminologyBox 3) In a given OML TerminologyBox, every partial reifiedRelationship $R must have at least one corresponding $R extendsRelationship ... axiom 4) If a TerminologyBox T1 defines a partial reifiedRelationship R and TerminologyBox T2 extends T1, then T2 may assert additional R extendsRelationship ... axioms. 5) extentRelationship is applicable to any combination of specific/general reified relationship (full or partial)

Note that (3) means that it is necessary to have OML validation to ensure that, when an OML model is saved, it is well-formed (i.e., every partial reifiedRelationship in a given TerminologyBox has at least one extendsRelationship.)

The sketch of the OML abstract syntax is the following:

// Same as 0.9.2 except for the new rootRelationships query
abstract class ConceptualRelationship extends ConceptualEntity, EntityRelationship {
   // For a ReifiedRelationship, the singleton set of itself.
   // For a PartialReification, the union of all rootReifiedRelationships of its specialization parents
   op ReifiedRelationship[*] rootReifiedRelationships
}

// Same as 0.9.2 except for the new rootRelationships query
class ReifiedRelationship extends ConceptualRelationship, CharacterizedEntityRelationship {
   // rootReifiedRelationships is the singleton set of itself.
   op ReifiedRelationship[*] rootReifiedRelationships { /* ... */ }
}

// New
class PartialReification extends ConceptualRelationship {
   // rootReifiedRelationships is the union of all rootReifiedRelationships of its specialization parents
   op ReifiedRelationship[*] rootReifiedRelationships { /* ... */ }
}

// Same as 0.9.2 except for sub/superRelationship typed by ConceptualRelationship
// instead of ReifiedRelationship in 0.9.2 
class ReifiedRelationshipSpecializationAxiom extends SpecializationAxiom {
   refers ConceptualRelationship[1] subRelationship
   refers ConceptualRelationship[1] superRelationship
  op Entity[1] child() { subRelationship }
  op Entity[1] parent() { superRelationship }
}

For the mapping to/from OWL, each ReifiedRelationshipSpecializationAxiom contributes:

In the above example:

// For U2:
U2 rdf:type owl:Class .
hasU2Source rdf:type owl:ObjectProperty ;
    rdfs:domain U2 ;
    rdfs:range A2 .
hasU2Target rdf:type owl:ObjectProperty ;
    rdfs:domain U2 ;
    rdfs:range B2 .
u2 rdf:type owl:ObjectProperty ;
    rdfs:domain A2 ;
    rdfs:range B2 .

// For U3:
U3 rdf:type owl:Class ;
      rdfs:subClassOf U2 .

U3 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Source ;
    owl:someValuesFrom A3 .
]

U3 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Target ;
    owl:someValuesFrom B3 .
]

// For V2:
V2 rdf:type owl:Class ;
      rdfs:subClassOf V1 .

V2 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Source ;
    owl:someValuesFrom C2 .
]

V2 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Target ;
    owl:someValuesFrom D2 .
]

// For V3:
V3 rdf:type owl:Class ;
      rdfs:subClassOf V2 .

V3 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasV1Source ;
    owl:someValuesFrom C3 .
]

V3 rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasV1Target ;
    owl:someValuesFrom D3 .
]

// For W:
W rdf:type owl:Class ;
      rdfs:subClassOf U2 .

W rdf:type owl:Class ;
      rdfs:subClassOf V3 .

W rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Source ;
    owl:someValuesFrom E .
]

W rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasU1Target ;
    owl:someValuesFrom E .
]

W rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasV1Source ;
    owl:someValuesFrom E .
]

W rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty hasV1Target ;
    owl:someValuesFrom E .
]

// For X:
X rdf:type owl:Class ;
   rdfs:subClassOf W .
hasXSource rdf:type owl:ObjectProperty ;
    rdfs:domain X ;
    rdfs:range H .
hasXTarget rdf:type owl:ObjectProperty ;
    rdfs:domain X ;
    rdfs:range H .
x rdf:type owl:ObjectProperty ;
    rdfs:domain G ;
    rdfs:range H .
StevenJenkinsJPL commented 6 years ago

The terminology is confusing. When we create a reified relationship in OWL, we construct a set of elements with a highly-patterned interconnection: an object property, a reification class, source and target properties, and a SWRL rule. What we're calling partial reifiedRelationship isn't a subset of that and therefore isn't a "partial". Its purpose is completely different, namely, to restrict a particular occurrence of a property reification. In that case we create a specialization of the reification class (only) and add additional range restrictions on the corresponding source and target properties. I think the name should convey that this is a reification restriction or specialization. It doesn't reify anything, partially or otherwise.

sjiherzig commented 6 years ago

Hmm... aren't we creating:

  1. An OWL class that represents a specialized version of the reification class
  2. A specialization relationship between the newly created OWL class and the original reification class?

In that sense, I think it matches well - even in the "old" pattern we have:

(a) A class representing a reified relationship (with definition of a property, source, target, etc.) (b) A separate, optional axiom declaring that this reification class is a subclass of another reification class

So:

reifiedRelationship A { ... }
reifiedRelationship B { ... }

A extendsRelationship B

In the new pattern, we do (at least in my understanding) exactly the same thing, except that we do not create a subproperty / unreified relationship property. To me, this would be the same as leaving out some of the elements in the definition of either A or B in the example above (e.g., the definition of the unreified property). The fact that we have a separate element (partial reifiedRelationship) just makes it a little easier on the grammar parsing process.

StevenJenkinsJPL commented 6 years ago

In the "partial" pattern we assert two someValuesFrom range restrictions that are not asserted in the "full" pattern. In that sense, it isn't "partial".

The use cases for the two patterns are completely different. The "full" case is to define a new relationship and its entire reification apparatus. The resulting definition need never be used. The "partial" case is to assert existential quantification on an existing relationship. The fact that subclass axioms are asserted in both cases doesn't make one a partial realization of the other.