Currently, the extension of ontologies by a rule representation is a very popular research issue. A rule language increases the expressiveness of the underlying knowledge in many ways. Likewise, the integration creates new challenges for the design process of such ontologies, but also existing evaluation methodologies have to cope with the extension of ontologies by rules. In this work, we introduce supplements to existing verification techniques to support the design of ontologies with rule enhancements, and we focus on the detection of anomalies that can especially occur due to the combined use of rules and ontological definitions.
The use of ontologies has shown its benefits in many applications of intelligent systems in the last years. It is not only a fantasy of computer scientists, but it correesponds to real needs. E.g., in scholarly editions, the lack of semantic search is very obvious. The works of the poet Stifter, e.g., are full of geological metaphors but the word geological is never mentioned. The philosopher Wittgenstein is dealing with philosophical problems, but does not use traditional philosophical terminology. So the editors are considering an ontology for the work of Wittgenstein. In the context of [PZW13], Pichler and Zöllner– Weber were also exploring the potential of PROLOG ontologies and logic reasoning as tools in the Humanities [Zoe09].
Whereas, the implementation of lower parts of the semantic web stack has
successfully led to standardizations, the upper parts, especially rules and the logic
framework, are still heavily discussed in the research community, e.g., see Horrocks et al. [
Concerning the expressiveness of the ontology language we focus on the basic
subset of OWL DL (that should make the work transferable to ontology languages other
than OWL) and we mostly describe syntactic methods for the analysis of the considered
ontology. We also focus on the basic features of SWRL: we consider Horn clauses with
class or property descriptions as literals, and we omit a discussion of SWRL built–ins.
Due to the use of rules with OWL DL the detection of all anomalies is an undecidable
task, cf. [
Here, the term verification denotes the syntactic analysis of ontologies for detecting
anomalies. On one hand, the discussed issues of the presented work originate from the
evaluation of taxonomic structures in ontologies introduced by Gómez–Pérez [
In detail, we investigate the implications and problems that can be drawn from rule definitions in combination with some of the following ontological descriptions: 1. class relations like subclass of, complement of, disjointness 2. basic property characteristics like transitivity, ranges and domains, and cardinality restrictions. We distinguish the following classes of anomalies: – Circularity in taxonomies and rule definitions. – Redundancy due to duplicate or subsuming knowledge. – Inconsistency because of contradicting definitions. – Deficiency as a category comprising subtle issues describing questionable design in an ontology.
The presented work is different from the evaluation of an ontology with respect
to the intended semantic meaning: the OntoClean methodology [
This paper is organized as follows: The next section gives basic definitions and describes the expressiveness of the underlying knowledge representation; in the context of this work a subset of OWL DL is used. Then, the four main classes of anomalies are discussed. In Section 3, we present a case study with anomalies in OWL ontologies. The paper is concluded with a discussion.
For the analysis of ontologies with rules, we restrict the range of the considered constructs to a subset of OWL DL: we investigate the implications of rules that are mixed with subclass relations and/or the property characteristics transitivity, cardinality restrictions, complement, and disjointness.
Given a class C and a property P . When used in rules, we call C(x) a class atom and P (x; y) a property atom. For the following it will be useful to extend the relations on classes and properties to relations on class and property atoms. Given two atoms A; A0, we write (A; A0), if both atoms have the same argument tuple, and their predicate symbols are related by , i.e., if A and A0 both are – class atoms, such that A = C(x), A0 = C0(x), and (C; C0), or – property atoms, such that A = P (x; y), A0 = P 0(x; y), and (P; P 0). E.g., the relation can be sub_class, isa, disjoint, complement, etc. From a relationship (A; A0) it follows that A and A0 are of the same type. 2.1
The detection of anomalies has been done using a PROLOG meta–interpreter
DATALOG?, which we have implemented in SWI PROLOG [
Variables such A, B, C, . . . , A0, or Bi can denote both class atoms and property atoms, whereas As, Bs, . . . , denote sets of class atoms and property atoms. We denote a relationship A is-a A’ by isa(A, A’). SWRL rules B1 ^ ^ Bn ) A are represented as non–ground DATALOG? facts rule(A-Bs) (with variable symbols), where Bs = [B1; : : : ; Bn] is the list of body atoms and A is the head atom. Since SWRL rules with conjunctive rule heads can be split into several rules, we can – without loss of generality – assume rule heads are atomic. In DATALOG? and PROLOG rules, conjunction (and) is denoted by ”,”, disjunction (or) is denoted by ”;”, and negation by ”\+”. Incompatible Classes: Complements and Disjointness. For classes, there exists the construct complementOf to point to instances that do not belong to a specified class. In DATALOG?, the complement relation between two classes C1 and C2 is denoted by complement(C1,C2). In OWL, the disjointness between two classes is defined by the disjointWith constructor; with disjoint(C1,C2) we denote the disjointness between two classes C1 and C2. We call two classes C1 and C2 incompatible, if there exists a disjoint or a complement relation between them. This is detected by the following PROLOG predicate: incompatible(C1, C2) :( complement(C1, C2) ; disjoint(C1, C2) ).
Taxonomic Relationships and Rules An obvious equivalence exists between the relationships B is-a A – where A and B are both class atoms or both property atoms with the same arguments – and rules of the form B ) A with a single atom B in the body having the same argument as A. Thus, we combine them into the single formalism derives in DATALOG?: derives(C1, C2) :( isa(C1, C2) ; rule(A-[B]) B =.. [C1, X1], A =.. [C2, X2],
var(X1), X1 == X2 ). isa(C1, C2) :
sub_class(C1, C2). isa(C1, C3) :
isa(C1, C2), sub_class(C2, C3).
Observe, that the call var(X1), X1 == X2 tests if X1 and X2 are bound to the same variable.
With the existence of equivalence definitions E1 E2 in an ontology language, e.g., the OWL definitions equivalent_class and equivalent_property, we can further extend the definition of derives: an element E1 is derived by an element E2, if the elements are equivalent classes or properties. Since such an equivalence is symmetrical, the predicate derives/2 always creates cyclic dervations of equivalent elements with length 1.
derives(E1, E2) :( equivalent_class(E1, E2) ; equivalent_property(E1, E2) ).
We compute the transitive closure tc_derives of derives using the following simple, standard DATALOG? scheme: tc_derives(E1, E2) :
derives(E1, E2). tc_derives(E1, E3) :
derives(E1, E2), tc_derives(E2, E3). tcr_derives(E1, E2) :( E1 = E2 ; tc_derives(E1, E2) ).
Subsequently, the reflexive transitive closure tcr_derives of derives is computed using the following PROLOG predicate: Remark on Examples. In the following we give examples for most of the described anomalies. For this task, we use a printer domain, because to its popularity and intuitive understanding.
The detection of anomalies in SWRL ontologies could not be formulated using PROLOG backward chaining or DATALOG forward chaining alone, since we may need recursion on cyclic data, function symbols (mainly for representing lists), non–ground facts, negation and disjunction in rule bodies, aggregation, and stratification.
Thus we have developed a new approach that extends the DATALOG paradigm to
DATALOG? and mixes in with PROLOG. However, an intuitive understanding of the
presented, mixed rule sets is possible without understanding the new inference method.
The interested reader can run the analysis using our DisLog system [
The supporting PROLOG rules are evaluated top–down, and for efficiency reasons only on demand, and they can in turn refer to DATALOG? facts. The PROLOG rules are also necessary for expressivity reasons: the are used for some computations on complex terms, and more importantly for computing very general aggregations of DATALOG? facts.
Ontology Evaluation in DATALOG?. For ontology evaluation, we have implemented two layers D1 and D2 of DATALOG? rules: – The upper layer D2 consists of the rules for the predicate anomaly/2 and some
DATALOG? rules that are stated together with them. – The lower layer D1 consists of all other DATALOG? rules. E.g., the rules for predicates derives and tc_derives are in D1.
D1 is applied to the DATALOG? facts for the following basic predicates, which have to be derived from the underlying SWRL document: rule, class, sub_class, complement, incompatible, equivalent_class, equivalent_property, transitive_property, symmetric_property, property_restriction, min_cardinality_restriction, max_cardinality_restriction, class_has_property. The resulting DATALOG? facts are the input for D2. The stratification into two layers is necessary, because D2 refers to D1 through negation and aggregation. Most PROLOG predicates in this paper support the layer D2.
E.g., the following predicates with calls to DATALOG? facts generalize tc_derives and incompatible to atoms: tc_derives_atom(A1, A2) :
tc_derives(P1, P2), A1 =.. [P1|Xs], A2 =.. [P2|Xs]. incompatible_atoms(A1, A2) :
incompatible(P1, P2), A1 =.. [P1|Xs], A2 =.. [P2|Xs]. We cannot evaluate these rules using forward chaining, since Xs is a unknown list.
The head and body predicates of a rule can be determined using the following pure PROLOG predicates: head_predicate(A-_, P) :
functor(A, P, _). body_predicate(_-Bs, P) :
member(B, Bs), functor(B, P, _).
The following PROLOG rules define siblings and aggregate the siblings Z of a class X to a list Xs using the well–known meta–predicate findall, respectively: sibling(X, Y) :
sub_class(X, Z), sub_class(Y, Z), X \= Y. siblings(Xs) :sibling(X, _), findall( Z, sibling(X, Z),
Xs ).
These rules could also be evaluated in DATALOG? using forward chaining. But, since we need siblings only for certain lists Xs, this would be far to inefficient. Evaluation of DATALOG?. DATALOG? rules cannot be evaluated in PROLOG or DATALOG alone for the following reasons: Current DATALOG engines cannot handle function symbols and non–ground facts, and they do not allow for the embedded computations, which we need. Standard PROLOG systems cannot easily handle recursion with cycles, because of non–termination, and are inefficient, because of subqueries that are posed and answered multiply. Thus, they have to be extended by some DATALOG? facilities (our approach) or memoing/tabling facilities (the approach of the PROLOG extension XSB). Since we wanted to use SWI PROLOG – because of its publicly available graphical API – we have implemented a new inference machine that can handle mixed, stratified DATALOG?/PROLOG rule systems. 3
Knowledge representation in the Semantic Web is based on ontologies and logic. The reasoning tasks require search (query answering) and knowledge engineering / modeling (analysis of the structure of the ontologies for anomalies). Knowledge engineering and reasoning in the Semantic Web is based on ontology editors and specialized databases. It can further be supported by deductive databases and logic programming techniques.
In the Semantic Web, it is possible to reason about the ontology / taxonomy (i.e., the schema) and the instances. This is called terminological or assertional (T–Box or A– Box) reasoning, respectively. This makes search in the Semantic Web more effective. – In the following printer ontology, we could search for a printer from HP, and the result could be a laser–jet printer from HP, since the system knows that hpLaserJetPrinter is a sub–class of hpPrinter. – It can also be derived, that all laser–jet printers from HP are no laser writers from Apple; in this case, this is very easy, since it is explicitely stored in the ontology. product printer
{disjoint} hpApplePrinter hpProduct personalPrinter laserJetPrinter hpPrinter ibmLaserPrinter appleLaserWriter hpLaserJetPrinter
Moreover, we will show in the following how to support knowledge engineering by detecting anomalies in OWL ontologies. In the Web Ontology Language (OWL), we can mix concepts from rdf (Resource Description Framework) for defining instances and rdfs (rdf Schema) for defining the schema of an application. Moreover, tags with the namespace owl are allowed. The Semantic Web Rule Language (SWRL) incorporates logic programming rules into OWL ontologies. There exist well–known, powerful tools for asking queries on and for reasoning with OWL ontologies.
The following examples are given in Turtle syntax [
The following owl:Class element defines the class appleLaserWriter: p:appleLaserWriter rdf:type owl:Class ; rdfs:comment "Apple laser writers are laser jet printers" ; rdfs:subClassOf p:laserJetPrinter ; owl:disjointWith p:hpLaserJetPrinter .
The rdfs:subClassOf sub–element states that appleLaserWriter is a sub–class of laserJetPrinter. The owl:disjointWith sub–element states that appleLaserWriter is disjoint from hpLaserJetPrinter.
The following owl:Class element defines a class of printers from a joint venture of HP and Apple: p:hpApplePrinter rdfs:comment "Printers from a joint venture of HP and Apple" ; rdfs:subClassOf p:hpLaserJetPrinter, p:appleLaserWriter . The existence of such printers would contradict the disjointWith restriction between the classes hpLaserJetPrinter and apperLaserWriter. The emptiness of the class hpApplePrinter can be detected by reasoners used, for instance, by ontology editors like Protégé.
Redundant subClassOf Relation. Since hpLaserJetPrinter is a sub–class of the class hpPrinter, and hpPrinter is a sub–class of hpProduct, it is redundant to explicitly state that hpLaserJetPrinter is a sub–class of hpProduct. p:hpLaserJetPrinter rdfs:subClassOf p:laserJetPrinter, p:hpPrinter, p:hpProduct ; owl:disjointWith p:appleLaserWriter .
This redundancy is not an error. We could simply consider it as an anomaly, that should be reported to the knowledge engineer. This anomaly is usually not reported by reasoners in standard ontology editors.
Instances. Finally, we have some instances of the defined classes: p:1001 rdf:type p:appleLaserWriter . p:1002 rdf:type p:appleLaserWriter . p:1003 rdf:type p:hpLaserJetPrinter . p:1004 rdf:type p:hpLaserJetPrinter .
As mentioned before, there cannot exist instances of the class hpApplePrinter.
The ontology editor Protégé offers plugged–in reasoners, such as FaCT++, HermiT, and Racer. The ontology reasoner FaCT++ can inferr that the class hpApplePrinter is EquivalentTo the empty class Nothing. By clicking the question mark, an explanation can be shown. There are also databases for handling rdf data, so called triple stores, such as Sesame or Jena. They use extensions of SQL– most notably SPARQL – as a query language.
Please note, that for the presented Turtle syntax the corresponding XML syntax can be generated. For instance, the definition of the joint HP and Apple printer would read as follows: <rdf:Description rdf:about="printer#hpLaserJetPrinter"> <rdfs:subClassOf rdf:resource="printer#hpPrinter"/> <rdfs:subClassOf rdf:resource="printer#laserJetPrinter"/> </rdf:Description> Protégé. Figure 1 shows the printer ontology in the standard ontolgy editor Protégé.
In PROLOG, an XML element can be represented as a term structure T:As:C, called FN–triple. T is the tag of the element, As is the list of the attribute/value pairs A:V of the element, and C is a list of FN–triples for the sub–elements.
’owl:Class’:[’rdf:ID’:’appleLaserWriter’]:[ ’rdfs:comment’:[’Apple laser ...’], ’rdfs:subClassOf’:[
’rdf:resource’:’#laserJetPrinter’]:[], ’owl:disjointWith’:[
’rdf:resource’:’#hpLaserJetPrinter’]:[] ]
In an OWL knowledge base Owl, there exists an isa relation between two classes C1 and C2, if a subclassOf relation is stated explicitely, or if C1 was defined as the interesection of C2 and some other classes: % isa(+Owl, ?C1, ?C2) <isa(Owl, C1, C2) :
C := Owl/’owl:Class’::[@’rdf:ID’=C1], ( R2 := C/’rdfs:subClassOf’@’rdf:resource’ ; R2 := C/’owl:intersectionOf’/’owl:Class’@’rdf:about’ ), owl_reference_to_id(R2, C2).
% disjointWith(+Owl, ?C1, ?C2) <
In the following, we often suppress the ontology argument Owl. Transitive Closure of isa.
% subClassOf(?C1, ?C2) <subClassOf(C1, C2) :
isa(C1, C2). subClassOf(C1, C2) :
isa(C1, C), subClassOf(C, C2).
?- isa(C1, C2), subClassOf(C2, C1).
C1 = personalPrinter,
C2 = printer Partition Error. The class C is a sub–class of two disjoint classes C1 and C2. ?- disjointWith(C1, C2),
subClassOf(C, C1), subClassOf(C, C2).
C = hpApplePrinter, C1 = hpLaserJetPrinter,
C2 = appleLaserWriter Incompleteness. The class C has three sub–classes C1, C2 and C3, from which only the two sub–classes C1 and C2 are declared as disjoint in the knowledge base. ?- isa(C1, C), isa(C2, C), isa(C3, C),
disjointWith(C1, C2), not(disjointWith(C2, C3)).
C = laserJetPrinter, C1 = hpLaserJetPrinter, C2 = appleLaserWriter,
C3 = ibmLaserPrinter The fact that C2 and C3 are disjoint and that C1 and C3 are disjoint as well, possibly was forgotten by the knowledge engineer during the creation of the knowledge base. Redundant subClassOf/instanceOf Relations. The sub–class relation between C1 and C3 can be derived by transitivity over the class C2.
% redundant_isa(?Chain) <redundant_isa(C1->C2->C3) :isa(C1, C2), subClassOf(C2, C3), isa(C1, C3). ?- redundant_isa(Chain).
Chain = hpLaserJetPrinter -> hpPrinter -> hpProduct
Here, isa(C1, C2), subClassOf(C2, C3), requires that this deduction is done over at least two levels.
Undefined Reference. During the development of an ontology in OWL, it is possible that we reference a class that we have not yet defined.
% undefined_reference(+Owl, ?Ref) <undefined_reference(Owl, Ref) :rdf_reference(Owl, Ref), not(owl_class(Owl, Ref)). rdf_reference(Owl, Ref) :( R := Owl/descendant_or_self::’*’@’rdf:resource’ ; R := Owl/descendant_or_self::’*’@’rdf:about’ ), owl_reference_to_id(R, Ref). owl_class(Owl, Ref) :
Ref := Owl/’owl:Class’@’rdf:ID’.
If we load such an ontology into Protégé, then the ontology reasoners may produce wrong results, even for unrelated parts of the ontology. 4
In the last years ontologies have played a major role for building intelligent systems. Currently, standard ontology languages like OWL are extended by rule–based elements, e.g., RULEML and the semantic web rule language SWRL.
We have shown that with the increased expressiveness of ontologies – now also including rules – a number of new evaluation issues have to be considered. In this paper, we have presented a framework for verifying ontologies with rules comprising a collection of anomalies, that verify the represented knowledge in a combined methodology. For all anomalies, we have described a DATALOG? implementation which is used in a prototype for ontology verification. Due to its declarative nature, new methods for anomaly detection can be easily added to the existing work. From our point of view, the declarative approach is crucial because of the incompleteness of the presented anomalies: in principle, an entire overview of possible anomalies is not possible, since the number of anomalies depends on the used expressiveness of the ontology and the rule representation, respectively.
The actual frequency of the introduced anomalies is an interesting issue. However, only a small number of ontologies (mostly toy examples) is available that actually use a rule extension. A sound review of anomaly occurrences would require a reasonable number of ontologies having a significant size.
For many real–world applications, we expect a more expressive rule language to
be used than SWRL. With SWRL FOL, an extension of SWRL to first–order logic is
currently discussed as a proposal. Furthermore, larger systems may also include parts of
a non–monotonic rule base. Here, some work has been done on the verification of non–
monotonic rule bases [