Debugging OWL Ontologies
using Swoop
Ontology Debugging
Background &
Motivation
What is an Ontology?
Broadly speaking, an ontology is a set of axioms used
to formally define concepts and relations that exist in a
certain domain and assert information about individuals in that domain.
What is OWL? OWL is the de-facto standard for the creation and exchange
of ontological models on the Web, and thus represents a basis of the Semantic
Web. One of the main benefits of OWL is the support for formal reasoning,
and to this effect, the sublanguage OWL-DL is its most relevant subset since
its semantics are firmly rooted in Description Logic, a decidable
fragment of First Order Logic.
Why is debugging OWL Ontologies hard? OWL-DL
is based on an expressive description logic -- SHOIN(D),
and a DL reasoner can be used to derive inferences
from, or detect contradictions in an OWL Ontology. However, given the
expressivity of the logic, newcomers to OWL have difficulty in understanding
inferences and/or fixing errors in an OWL ontology, since most reasoners only report inferences (or errors) in the
ontology without explaining how or why they are derived. Even DL experts find
it hard to debug errors in large, complex ontologies.
The two main types of semantic or logical errors found in an OWL ontology are:
- Unsatisfiable Concept - this occurs when a concept definition contains a contradiction
which prevents the concept from having a model, i.e., the concept is
forced to not have any individuals.
- Inconsistent Ontology
- this occurs when the axioms in an ontology
contain a contradiction which prevents the ontology from having a model,
e.g., when the ontology asserts that an individual belongs to an unsatisfiable concept.
Our
Goal? To devise non-standard DL services that are specifically catered towards the
debugging and repair of logical inconsistencies in OWL ontologies.
An additional motivation is to demonstrate that good debugging support will not
only give users control over their modeling, but also encourage them to
experiment more freely with expressions, and help them come to understand their
ontologies through the debugging process.
Debugging
Services
Axiom
Pinpointing
This
service is used to understand the output of the reasoner
as it provides the justification premises (axioms) for any arbitrary
entailment derived by the reasoner from an OWL-DL
ontology -- from a debugging standpoint, this service is critical for
identifying the precise set of axioms, along with the relevant sub-parts
of each axiom, that is responsible for a particular error. For example, Figure
1 displays the use of the service to debug the unsatisfiable
concept AI_Dept in the University OWL Ontology.
Figure 1: Axiom Pinpointing
As
can be seen, in addition to identifying the minimal set of axioms in the
ontology responsible for the error, the service also provides a natural
language explanation for the cause of the root clash or contradiction. Also,
notice how the axioms are ordered and indented in order to create a chain of
inferences leading to the source of the error. In this case, an instance of AI_Dept is an instance of CS_Department (because of the subclass relation in 1), and,
through a series of inferences (axioms 2-5) an instance of EE_Department, which is defined to be disjoint with CS_Department (axiom 6).
Root Error Pinpointing
This
service is useful when there are a large number of semantic errors in an ontology. It prunes the problem space by separating the
root or critical errors in the ontology from the derived or dependent ones.
Typical cases when errors spread is if a class is defined to be a subclass of
another unsatisfiable class, or is related to another
unsatisfiable class via an existential property
restriction, in which case, it becomes unsatisfiable
as well.
Figure 2 displays the use of this service to debug the large number of unsatisfiable classes in the Tambis OWL Ontology - in this case only 3 out of 144 unsatisfiable
classes are identified as roots.
Figure 2: Root Error Pinpointing
Using this service, we have an
efficient iterative procedure to remove all the unsatisfiability
bugs in the ontology: at each point, we focus solely on fixing all the
root classes, which effectively fixes a large set of directly derived class bugs.
However, doing so might reveal additional contradictions and a new set of unsatisfiable classes. We then use the service again to
obtain a new set of roots and repeat the fixing process iteratively till no unsatisfiable classes are left in the ontology. In the Tambis case, we find that only 6 unsatisfiable
classes (in two iterations) need to be fixed in order to resolve all the
errors.
Ontology Repair
This service acts as a guideline for ontology repair, by aiding the user in
understanding and evaluating the various repair options available. The basic
methodology is the following: it takes the critical erroneous axioms as inputs,
considers various metrics to rank axioms (defining notions such as semantic
and syntactic relevance), and automatically generates repair solutions
to fix any or all of the errors in the ontology based on the axiom ranks.
Figure 3: Ontology Repair
Figure
3 demonstrates the use of this
service for generating a repair plan to remove all root unsatisfiable
concepts in the University OWL Ontology. Key features of this service include
the option to preview entailments that are lost/added when axioms are
removed/inserted (impact analysis), the ability to modify plans on the fly by
forcibly keeping or removing certain axioms, and the
auto-suggestion of axiom rewrites in special cases.
Other Generic
Tool Support
Non- Standard
Query
Two
non-standard query features in Swoop that are useful for debugging are:
displaying sub/super classes of arbitrary class expressions, and "Show
References", which highlights the usage of an OWL entity
(concept/property/individual) by listing all references of that entity in local
or external ontological definitions.
Figure 4 displays the use of the latter query type to debug an unsatisfiable class in the Sweet-JPL ontology. In
this case, the class OceanCrustLayer is unsatisfiable because it
is a subclass of both GeometricObject_2D and GeometricObject_3D which
enforce conflicting restrictions on the data-property hasDimension, and
here, the use of Show References reveals the incorrect usage of the
property hasDimension.
Figure 4: Using non-standard queries to debug logical inconsistencies
Change
Management and Ontology Versioning
Part
of good debugging support for OWL ontologies is
making experimentation safe, easy, and effective. Swoop has an ontology
versioning feature that supports ad hoc undo/redo of changes (with logging)
coupled with the ability to checkpoint and archive different ontology versions.
Such a feature can play a vital role in ontology debugging. Consider the
scenario in which a user starts with an inconsistent ontology version, performs
a set of changes in succession (undoing and redoing as necessary), in order to
reach a final consistent version. Here the change logs give a direct pointer to
the source of inconsistency. The checkpointing allows
the user to switch between versions easily exploring different modeling
alternatives.
Figure 5: Change Management in Swoop: change log with option for undo,
checkpoints etc.
Alternately, if the user has two different ontology versions, one consistent
and the other inconsistent, a diff between the versions can be performed
using Swoop's Concise Format Renderer in order to
determine possible change paths between the versions. By examining these change
paths, and noting the common bug-producing changes, users can find and
eliminate erroneous entity-definitions and axioms in the ontology.
Annotea
Once
a series of changes has proven effective in removing the defect and seems sensible,
the modeler can use Swoop's integrated Annotea client to publish the set of changes plus a
commentary (see Figure 6). Other subscribers to the Annotea
store can see these changes and commentary in context they were made, apply the
changes to see their effect, and publish responses. These exchanges persist,
providing a repository of real cases for subsequent modelers to study.
Figure 6: Using the Annotea Client in Swoop to
publish and share explanations on the Ontology. In this case, the annotation
also contains a change set that when applied to the ontology will
rectify the problem.
Alternate Applications
Explaining
Arbitrary Entailments
As
noted earlier, the Axiom Pinpointing service can be used to identify the
minimal set of axioms responsible for any arbitrary entailment of an OWL-DL ontology. We have thus extended our explanation
support in Swoop to cover any inference derived by the reasoner,
Pellet. Figure 7 shows an example used to explain a subsumption (subclass) relationship in the Koala
ontology.
Figure 7: Explaining why MaleStudentWith3Daughters is a subclass of Parent in the Koala ontology
Try it out
Download
Swoop-Debugger
The debugging support has
been integrated into Swoop since v2.3. Download it here.
Sample Ontologies
All ontologies
listed on this page and used as samples for debugging are listed here.
Publications
[1] Aditya Kalyanpur. Debugging
and Repair of OWL Ontologies. Ph.D. Dissertation,
[2] Aditya Kalyanpur,
Bijan Parsia, Evren Sirin, Bernardo Cuenca-Grau. Repairing
Unsatisfiable Concepts in OWL Ontologies. In The European Semantic Web Conference ESWC 2006 (Best-Paper Award Winner)
[3] Aditya Kalyanpur, Bijan Parsia, Evren
Sirin, James Hendler. Debugging
Unsatisfiable Classes in OWL Ontologies. Journal of Web Semantics, Volume 3 Issue 4, 2006
[4] Aditya
Kalyanpur, Bijan Parsia, Evren Sirin.
Black Box Techniques for Debugging Unsatisfiable Concepts.
In The 2005 International Workshop on Description Logics -
DL2005,
[5] Bijan Parsia, Evren Sirin,
Aditya Kalyanpur. Debugging
owl ontologies. In
The 14th International World Wide Web Conference
(WWW2005),
Feedback
Note that the work
described here represents ongoing research. We appreciate and welcome any
feedback on this topic - please send mail to the Swoop-Devel
list (especially if you have examples of buggy OWL ontologies!)
Last Updated: February 2006