https://esterel.bluegreen.com/fr/initiations-gratuites 0494 44 6465 (pas 04 94 52 68 30 en fait) 14:45 Sébastien

Ontology Design Rules Based On
Comparability Via Particular Relations


Ph. A. Martin 1O. Corby 2  and  C. Faron Zucker 2

1 University of La Réunion (France) + Griffith University (Australia)
2 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:


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

→ 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  →

Next sections before the conclusion

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

1.  for subclass relations

p. 6-11
2.  for other specialization relations

p. 12
3.  for "definition element" relations

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

p. 14
5.  for transitive relations plus minimal differentia

p. 15

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

1.  ... for subclass relations

Easiest method:  subtyping each class C using


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

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

SubClassOf relations (manually set or generated from definitions of the classes)
    relating similar subtypings (like those of x:Vehicle and y:Car with colors)
    avoid unrelated partial redundancies in the KB
             (frequent when the KB is large or multi-authored)

1.  ... for subclass relations

Advantages:  3) more querying possibilities

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

No disjointWith relation above
and the KB follows the ODR for subclass relations
→ querying for individuals not disjoint with Lodging
    only retrieves potentially relevant lodgings
    (e.g. covered sport halls in case of natural disaster)
    → no fully irrelevant results
    → the querier does not have to use (or even know about)
        x:Covered_sport-hall  to get such results

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

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)


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