... | ... | @@ -10,33 +10,41 @@ These steps are necessary in order to run the plug-in: |
|
|
* Note that **the Debugger Plug-In is not compatible with Protégé version 4 and below**.
|
|
|
* Install the Ontology Debugger Plugin with Protégé's Update Function```File->Check for Plugins...``` and select *Ontology Debugger* ![installation_plugin](/uploads/19bb8181c61d7982936f275fe877d2b4/installation_plugin.png)
|
|
|
* **As an alternative** you can also download the [latest jar-file](http://isbi.aau.at/ontodebug/plugin) of the *Ontology Debugger* and copy the jar-File into the ```plugins``` subfolder of your Protégé 5 desktop client.
|
|
|
* If your Protégé client is already running, you willhave to restart the client to load the plugin.
|
|
|
* After your Protégé client has restarted you will see an additional menu entry in ```Tools->Debug Ontology ...``` as shown here: ![debug_ontology_menuentry](/uploads/4d52afa2f4c3591f9e408cb193f85de5/debug_ontology_menuentry.png)*These three menu items in the Tools menu show that the Ontology Debugger is installed correctly*
|
|
|
* If your Protégé client is already running, you will have to restart the client to load the plugin.
|
|
|
* After your Protégé client has restarted you will see the additional menu entry ```Tools->Debug Ontology ...``` ![debug_ontology_menuentry](/uploads/4d52afa2f4c3591f9e408cb193f85de5/debug_ontology_menuentry.png)*These three menu items in the Tools menu show that the Ontology Debugger is installed correctly*
|
|
|
|
|
|
# How to use the Ontology Debugger Plug-In in Protégé
|
|
|
# About the Ontology Debugger Plug-In for Protégé
|
|
|
The Ontology Debugger's main task is to ***support the user*** in the process of ***finding the faulty axioms*** in [inconsistent and/or incoherent ontologies](http://ontogenesis.knowledgeblog.org/1329).
|
|
|
|
|
|
- The process of finding the faulty axioms in the ontology that are responsible for the inconsistency/incoherency is done by ***interacting with the user***.
|
|
|
- The interaction with the user takes place in the way of ***iteratively stating questions*** (or queries) to the user in the form of axioms.
|
|
|
- Each axiom given in such a query can then be read in the form of the question: ***Must this axiom be entailed by the desired ontology?*** or ***Does this axiom hold in the domain that should be modeled by the ontology?***
|
|
|
- The interaction with the user takes place in the way of ***iteratively stating questions*** (or queries) to the user in the form of axioms - we call this interaction a ***Debugging Session***.
|
|
|
- Each axiom given in such a query can be read in the form of the question: ***Must this axiom be entailed by the desired ontology?*** or ***Does this axiom hold in the domain that should be modeled by the ontology?***
|
|
|
- The user responds with the answer _YES_ if she thinks that this axiom must hold for the ontology or _NO_ otherwise.
|
|
|
- Note that the ***axioms of a query*** can be either ***explicitly stated axioms in the faulty ontology*** or ***statements inferred from axioms in the ontology and the answers given for previous queries***.
|
|
|
- The answers given by the user are also taken into account in the process of narrowing down the set of faulty axiom sets (these faulty axiom sets are also called ***Possible Ontology Repairs*** or _diagnoses_).
|
|
|
- As long as there are more than one set of Possible Ontology Repairs that together explain the inconsistency/incoherency, the Ontology Debugger is repeating the dialog and stating further queries to the user.
|
|
|
- The answers given by the user are then taken into account in the process of narrowing down the set of faulty axiom sets (we also call such faulty axiom sets ***Possible Ontology Repairs*** or _diagnoses_).
|
|
|
- As long as there are more than one set of Possible Ontology Repairs that together explain the inconsistency/incoherency, the Ontology Debugger is repeating the dialog and states further queries to the user.
|
|
|
- Once there is only one repair set of faulty axioms that explain the incoherency/inconsistency the interaction is finished and no more questions are generated.
|
|
|
- Note that once a possible ontology repair set of faulty axioms (or diagnosis) is found this means that ***every axiom*** in this set is responsible for the inconsistency/incoherency in the ontology.
|
|
|
- **Remark**: The user of the Ontology Debugger is ***not*** required to analyze (1) which entailments (or statements) do or do not hold or why certain entailments (or statements) do or do not hold ***in the faulty input ontology*** or (2) ***why exactly the input ontology is faulty***. The user is just assumed to answer questions about what must or must not hold ***in the intended ontology or domain model***, respectively. Given the answers, the Ontology Debugger will return what must be repaired in the faulty input ontology.
|
|
|
|
|
|
# Tutorial
|
|
|
|
|
|
In the following tutorial we want to show you
|
|
|
- the features of the Ontology Debugger Plug-In and
|
|
|
- how to use it to find the faulty axioms
|
|
|
in the ***consistent but incoherent*** [*Koala ontology*](http://protege.stanford.edu/ontologies/koala.owl).
|
|
|
|
|
|
### Step 1: Load the ontology
|
|
|
To demonstrate the features of the Ontology Debugger, we will now try to find the faulty axioms in the ***consistent but incoherent*** [*Koala ontology*](http://protege.stanford.edu/ontologies/koala.owl).
|
|
|
|
|
|
Select ```File->Open from URL... ``` ,enter the URL http://protege.stanford.edu/ontologies/koala.owl or select the appropriate URL from the Bookmarks.
|
|
|
Select ```File->Open from URL... ``` and enter the URL http://protege.stanford.edu/ontologies/koala.owl or select the appropriate URL from the Bookmarks.
|
|
|
|
|
|
![koala](/uploads/3de58c1126cd7b4b641a131c28195ca7/koala.PNG)*For our tutorial please select the incoherent Koala ontology from the Bookmarks*
|
|
|
|
|
|
### Step 2: Select a reasoner
|
|
|
The process of formulating queries and finding the faulty axioms the Ontology Debugger requires the usage of a reasoner.
|
|
|
You have to select a reasoner such as HermiT, Pellet, FaCT++ or ELK to be able to start a debugging session. For our tutorial let us choose the already installed *Hermit Reasoner* in the ```Reasoner``` menu. ![reasoner](/uploads/654ee6fdd1959cc9f947945776142d1b/reasoner.PNG)*The Ontology Debugger requires a reasoner. For our tutorial we choose HermiT.*
|
|
|
You have to select a reasoner such as HermiT, Pellet, FaCT++ or ELK to be able to start a debugging session.
|
|
|
|
|
|
For our tutorial let us choose the already installed *Hermit Reasoner* in the ```Reasoner``` menu. ![reasoner](/uploads/654ee6fdd1959cc9f947945776142d1b/reasoner.PNG)*The Ontology Debugger requires a reasoner. For our tutorial we choose HermiT.*
|
|
|
|
|
|
Please note that reasoners use different techniques to reason over ontologies. Therefore one reasoner may perform better than others on a specific ontology and worse on another ontology. Sometimes it might be helpful to select a different reasoner if the debugging is too time consuming [1].
|
|
|
|
... | ... | @@ -52,17 +60,22 @@ Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger T |
|
|
|
|
|
The Ontology Debugger is divided into three sections where each one is responsible for the presentation and manipulation of different information during the debugging session. In the following we will describe these sections and their meaning.
|
|
|
|
|
|
##### The Input Ontology
|
|
|
#### The Input Ontology
|
|
|
|
|
|
The right section shows us a list of all axioms from the the currently used __Input Ontology__ separating them between __Correct Axioms__ (also called the _Background Knowledge_) and the list of __Possibly Faulty Axioms__ (the _Knowledge Base_ or _KB_).
|
|
|
The rightmost section shows us a list of all logical axioms from the the currently used __Input Ontology__ separating them between __Correct Axioms__ (also called the _Background Knowledge_) and the list of __Possibly Faulty Axioms__ (the _Knowledge Base_ or _KB_).
|
|
|
|
|
|
##### Correct Axioms
|
|
|
__Correct Axioms__ are axioms that are assumed to be correct beforehand and are either identified as correct by the user herself or are automatically assigned by the Ontology Debugger when the ontology is loaded.
|
|
|
|
|
|
##### Possibly Faulty Axioms
|
|
|
The list of __Possibly Faulty Axioms__ represents the set of axioms that might be erroneous and thus might be the cause for the inconsistencies / incoherencies in your ontology. A subset of these axiom will finally be proposed as the possible repair set to resolve the ontology's inconsistency / incoherency.
|
|
|
|
|
|
**Note**: When loading the *Koala ontology* the debugger automatically separates axioms of ```AxiomType ClassAssertion``` from the set of axioms and marks them as *Correct Axioms*. All other 36 logical axioms are *Possibly Faulty* axioms. As long as the Debugging Session has not been started, the user can modify the two lists by clicking on the icons ![possibly_Faulty](/uploads/d152029365ddc44a0946c68e3ece74b7/possibly_Faulty.PNG) and ![correct](/uploads/433f214d1523b2ec6c3ba2ef66aa83f9/correct.PNG) to assume axioms to be either _possibly faulty_ or _correct_, respectively.
|
|
|
|
|
|
##### Test Cases
|
|
|
##### Moving axioms
|
|
|
As long as there is no running debugging session the user can move axiom from possibly faulty axioms to the correct axioms if she knows that the axiom is correct.
|
|
|
|
|
|
#### Test Cases
|
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown.
|
|
|
|
|
|
**Acquired Test Cases** are axioms that have already been answered by the user in previous queries. They are either categorized as _Entailed Test Cases_ when they have been classified by the user as correct statements in the ontology or as _Non Entailed Testcases_ when they must not be entailed in (these statements are not correct) the ontology according to the user's answer.
|
... | ... | |