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)
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
No more "unknown" relationship of the selected advocated types →
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 |
→ every class should be connected to each other class
(or "at least one other object" → slightly less work but far less advantages)
either by
Easiest method: subtyping each class C using
sub:proper-superClassOf_uncomparable_with_its_siblings
relations to C
For the ontology designer, this method does not take much more time than
just using subClassOf 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
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) | |
Advantages: 3) more querying possibilities
| Example: | x:Covered_area ↑ ↖ y:Lodging != x:Covered_sport-hall No disjointWith relation above |
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
}
Similar advantages (as for classes) but for more objects
| owl:subPropertyOf relations → | for properties too; similar implementation+checking via OWL+SPARQL |
→ 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).
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
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
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 .
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.