Debugging OWL Ontologies using Swoop
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.
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).
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
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.
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.
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
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.
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.
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
The debugging support has been integrated into Swoop since v2.3. Download it here.
All ontologies listed on this page and used as samples for debugging are listed here.
 Aditya Kalyanpur. Debugging
and Repair of OWL Ontologies. Ph.D. Dissertation,
 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)
 Aditya Kalyanpur, Bijan Parsia, Evren Sirin, James Hendler. Debugging Unsatisfiable Classes in OWL Ontologies. Journal of Web Semantics, Volume 3 Issue 4, 2006
 Aditya Kalyanpur, Bijan Parsia, Evren Sirin. Black Box Techniques for Debugging Unsatisfiable Concepts. In The 2005 International Workshop on Description Logics - DL2005,
 Bijan Parsia, Evren Sirin, Aditya Kalyanpur. Debugging owl ontologies. In The 14th International World Wide Web Conference
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