Ontology Design Rules Based On
Comparability Via Particular Relations

Ph. A. Martin ¹,  O. Corby ²  and  C. Faron Zucker ²

¹ University of La Réunion (France) + Griffith University (Australia)
² Wimmics team, INRIA / Uni. Côte d'Azur, CNRS, I3S, Sophia Antipolis, France

www.phmartin.info/slides/sem19.html

Goals

Context: helping knowledge base (KB) modelling for general knowledge reuse/sharing
                 (→ not for knowledge exploitation performance)

Research questions:

• How to enter knowledge for supporting
  the automatic checking that relations of selected types are systematically used
  but only when this use is considered correct by the knowledge provider
  (→ not whenever this use is allowed by the relation signatures)?
• How to extend best practices, ontology patterns or methodologies that
  advocate the systematic use of selected relation types
  for them to be automatically checkable (in the above sense)?

Our answer: the following proposed generic "ontology design rule" (ODR)

General formulation of the ODR

In the evaluated knowledge base (KB) or subset of it,
every object (→ type or individual)
should be connected to each other object  either by

• relations of the selected advocated types (plus sameAs/equivalentTo),  or
• negations of them (→ these relations do not or cannot occur)

→ no more "unknown" relationship of the selected advocated types

Implementation:
- OWL statements using dedicated properties
- inference rules represented by SPARQL Insert queries

General advantages

No more "unknown" relationship of the selected advocated types  →

• more inferences for queries, checks, ...
      without using the closed world assumption, unique name assumption, ...
  
  
• the ODR is automatically checkable  →
  • way to extend best practices and make them automatically checkable
  • usable for evaluating a KB connectedness (relational completeness
        wrt. the selected advocated types):  % of objects following this ODR

Next sections before the conclusion

Advantages and OWL+SPARQL implementation of this ODR ...

1.  ... for subclass relations

→ every class should be connected to each other class
    (or "at least one other object" → slightly less work but far less advantages)
    either by

• relations of type subClassOf or sameAs or equivalentTo,  or
• negations of them (→ disjointUnionOf, disjointWith, complementOf, differentFrom, ...)

1.  ... for subclass relations

Easiest method:  subtyping each class C using

• complete sets of exclusive subtypes (i.e. disjoint union of subtypes),  or else
• incomplete sets of exclusive subtypes,  or else
• for the remaining subtypes:
  (in-)complete sets of subclasses that are not exclusive but still different
  → sub:proper-superClassOf_uncomparable_with_its_siblings  relations to C
  
  To ease the representation of this case when RDF+OWL is used,
      the article proposes a SPARQL update operation that replaces the remaining
      subClassOf relations by sub:proper-superClassOf_uncomparable_with_its_siblings relations

For the ontology designer, this method does not take much more time than
just using subClassOf relations

1.  ... for subclass relations

Advantages:  1) detection of inconsistencies

Example:

wn:Action  ←disjointWith→  wn:Location      //relation added at the WordNet top-level
  ↑                        ↑              //subclassOf relations
wn:Military_action       wn:District
  ↑                        ↑
wn:Battle                wn:Town
          ⇖            ⇗                  //type relations
            wn:Waterloo                   //inconsistency detected

1.  ... for subclass relations

Advantages:  2) detection/explicitation of implicit partial redundancies

    x:Vehicle
     ↗   ↖
y:Car      x:Red_vehicle       
 ↑       ↗  
y:Red_car                      

1.  ... for subclass relations

Advantages:  3) more querying possibilities

x:Covered_area                         
 ↑           ↖      
y:Lodging   !=    x:Covered_sport-hall                  

1.  ... for subclass relations

Using SPARQL to search classes that
are not compliant with the ODR applied to subclassOf:

SELECT distinct ?c1 ?c2  WHERE
{ ?c1 a owl:Class.  ?c2 a owl:Class.  #for each pair of classes ?c1 and ?c2 

  #each class ?c2 "comparable via subClassOf" to ?c1 is not an error:
  FILTER NOT EXISTS{ ?c1 rdfs:subClassOf|^rdfs:subClassOf ?c2 } 
  FILTER NOT EXISTS{ ?c1 owl:equivalentClass|owl:sameAs ?c2 }

  #each class ?c2 "strongly uncomparable via subClassOf" to ?c1 is not an error:
  FILTER NOT EXISTS{ ?c1 owl:complementOf|owl:disjointWith ?c2 }
  FILTER NOT EXISTS{ [] a owl:AllDisjointClasses;
                        owl:members/rdf:rest*/rdf:first ?c1,?c2 }
  FILTER NOT EXISTS{ [] owl:disjointUnionOf/rdf:rest*/rdf:first ?c1,?c2 }

  #each remaining class ?c2 "uncomparable via subClassOf" to ?c1 is not an error:
  FILTER NOT EXISTS{ ?c1 owl:differentFrom ?c2 }

  #each remaining class ?c2 is an error:
  #  no compliance with the ODR applied to subclassOf
}

2.  ... for other specialization relations

Similar advantages (as for classes) but for more objects

• owl:subPropertyOf relations →

  for properties too; similar implementation+checking via OWL+SPARQL

  
  
•  sub:subIndividualOf relations → for individuals too, when relevant
   (SUB: proposed ontology for applying the ODR to other important relations)
  
  
•  sub:subStatementOf relations → for inferencing performance purposes and,
   if more precise relations are used, for a scalable and non-restrictive sharing of the KB
   by multiple authors (cf. Section 3.1 of the online companion article)

3.  ... for "definition element" relations

→ to detect implicit redundancies
    as in the example of Slide 8 but using any relation in class expressions
    (not just subClassOf relations between classes)

    → detection of all/many implicit redundancies
        (depending on the selected option; cf. online companion article)

Example wrt. the detection/explicitation of implicit partial redundancies:

x:Car                                          x:Color
 ↑  ↖                                         ⇑   ↑ 
 |    x:Colored_car :=>-sub:attribute→ a x:Color   /
 |                                                /
 |                                       x:Red_color
 |                                       ⇑
y:Red_car :=>-sub:attribute→ a x:Red_color

#-> y's subtyping of Car   by Red_car   mimicks
#   x's subtyping of Color by Red_color. This partial redundancy can
#   be detected via a SPARQL query exploiting sub:definition_element 
#   relations inferred from the definitions. It can also be forbidden
#   by setting a sub:definition-element_exclusion relation between
#   Car (or Physical_entity) and Color (or Attribute).

3.  ... for "definition element" relations

SPARQL query to detect implicit redundancies via
    the exploitation of "definition element" relations:

SELECT distinct  ?subC1 r1 ?c2   ?subC2 ?r2 ?c2  WHERE
{ ?subC1 sub:definition_element ?r1, ?c2; rdfs:subClassOf ?c1.
  ?subC2 sub:definition_element ?r2, ?c2; rdfs:subClassOf ?c1.
  FILTER( (?c1 != ?c2) && ((?r1 = ?r2)||(EXISTS{ ?r1 rdfs:subClassOf ?r2 }) )

  #the next lines check that ?c2 is semantically a destination of ?r1 and ?r2  
  FILTER(  (EXISTS {?r1 rdfs:subClassOf sub:definition_element})
         ||(EXISTS {?subC1 ?pr1 [rdf:type owl:Restriction;
                                 owl:onProperty ?r1;  owl:someValuesFrom ?c2]}))
  FILTER(  (EXISTS {?r2 rdfs:subClassOf sub:definition_element})
         ||(EXISTS {?subC2 ?pr2 [rdf:type owl:Restriction;
                                 owl:onProperty ?r2;  owl:someValuesFrom ?c2]}))
}

#with the previous example,
#   since sub:definition_element is transitive, we have:
# ?subC1, ?r1, ?c2  ?  x:Colored_car, sub:attribute, x:color 
# ?subC2, ?r2, ?c2 �?  y:Red_car,     sub:attribute, x:color

4.  ... for other transitive relations, especially part relations

Similar advantages (as with specialization relations) but for other relation types

Example wrt. the detection of inconsistencies:

x:Skin  ←sub:part_exclusion→  x:Hair      
  ↑                        ↗     //sub:partOf relations
x:Dermis                  / 
        ↖                /       //inconsistency detected: the left partOf relation
          y:Hair_follicle        //  should instead be a sub:location relation

4.  ... for other transitive relations, especially part relations

SPARQL query for checking the application of the ODR to sub:partOf relations:

SELECT distinct ?i1 ?i2  WHERE  
{ ?i1 a ?c1.  FILTER NOT EXISTS { ?c1 rdfs:subClassOf owl:Class }  #?i1 is an individual 
  ?i2 a ?c2.  FILTER NOT EXISTS { ?c2 rdfs:subClassOf owl:Class }  #?i2 is an individual 

  #each individual ?i2 "comparable via partOf" to ?i1 is not an error:
  FILTER NOT EXISTS {?i1 owl:sameAs|sub:part+|(^sub:part)+ ?i2} 

  #each individual ?i2 "strongly uncomparable via partOf" to ?i1 is not an error:
  FILTER NOT EXISTS {?i1 sub:part_exclusion ?i2}

  #each remaining individual ?i2 "uncomparable via partOf" to ?i1 is not an error:
  FILTER NOT EXISTS {?i1 owl:differentFrom ?i2}
}
#with:    sub:part rdfs:subPropertyOf owl:differentFrom ;
#                  a owl:TransitiveProperty .
#         sub:part_exclusion  rdfs:subPropertyOf  owl:differentFrom ;
#                             owl:propertyDisjointWith  sub:part .

5.  ... for transitive relations plus minimal differentia

Minimal differentia with subClassOf relations:  for each class,
    formally defining its minimal difference (→ one more/less/different relation)
    with each of its direct superclasses and each of its siblings wrt. these superclasses
    (the SPARQL checking query is in the article)

• Way to apply the "Differential Semantics" methodology in a formal way
• The KB is a decision tree for categorization/alignment/integration/search/... purposes
  → this can be seen as a kind of "(minimal) completeness" (for the content of the KB)
      without the need for any reference KB ("gold standard" KB)

Example: if Car is subtyped only by Hatchback_car and Sedan_car,
  following this ODR simply means
  (fully) defining a Hatchback_car as a car having for part a hatch and
  (partially) defining a Sedan_car as a car not having for part a hatch,
  thus allowing to distinguish these 3 classes on this point.

Conclusion

• Way to support the checking of a constraint-based completeness
  (as opposed to a "real-world-based completeness" which is
   the only case usually considered by "quality measures" for KBs)
  
  
• Way to extend some best practices, ontology patterns or methodologies
  and support their automatic checking
  
  
• Way to evaluate the connectedness of a KB (relational completeness),
  improve inferencing (→ for querying or
  for detecting inconsistencies and implicit redundancies)
  → we shall for example use this to quantify the connectedness of DBpedia
      before and after complementing its top-level
  
  
• Can be implemented in OWL+SPARQL for simple common cases
  (a generic approach is proposed at the end of the online companion article)