... | ... | @@ -18,13 +18,13 @@ The Ontology Debugger's main task is to ***support the user*** in the process o |
|
|
|
|
|
- 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: ***Is this axiom entailed in the ontology?*** or ***Does this axiom hold for the ontology?***
|
|
|
- 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 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 already be explicitely defined*** in the ontology beforehnd ***or they can be inferred*** from the existing set of axioms in the ontology and the answers given in previous queries and thus showing the user consequences of the current set of axioms in the ontology and answers given.
|
|
|
- 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 _diagnoses_).
|
|
|
- As long as there are more than one set of faulty axioms that together explain the inconsistency/incoherency, the Ontology Debugger is repeating the dialog and asks queries to the user.
|
|
|
- Once there is only one set of faulty axioms that explain the incoherency/inconsistency the interaction is finished and no more question is generated.
|
|
|
- Note that once a 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.
|
|
|
- As long as there are more than one set of faulty axioms that together explain the inconsistency/incoherency, the Ontology Debugger is repeating the dialog and stating further queries to the user.
|
|
|
- Once there is only one set of faulty axioms that explain the incoherency/inconsistency the interaction is finished and no more questions are generated.
|
|
|
- Note that once a 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.
|
|
|
|
|
|
### 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... ``` and enter the URL http://protege.stanford.edu/ontologies/koala.owl or simply select the URL from the Bookmarks.
|
... | ... | @@ -32,8 +32,8 @@ To demonstrate the features of the Ontology Debugger, we will now try to find th |
|
|
![koala](/uploads/3de58c1126cd7b4b641a131c28195ca7/koala.PNG)
|
|
|
|
|
|
### Step 2: Select a reasoner
|
|
|
For the process of formulating queries and finding the faulty axioms the Ontology Debugger also relies on using a reasoner.
|
|
|
For our example therefore we also must select a reasoner. Please choose the already installed *Hermit Reasoner* in the ```Reasoner``` menu. ![reasoner](/uploads/654ee6fdd1959cc9f947945776142d1b/reasoner.PNG)
|
|
|
The process of formulating queries and finding the faulty axioms the Ontology Debugger requires the usage of a reasoner.
|
|
|
For our example we must therefore also select a reasoner. Please choose the already installed *Hermit Reasoner* in the ```Reasoner``` menu. ![reasoner](/uploads/654ee6fdd1959cc9f947945776142d1b/reasoner.PNG)
|
|
|
|
|
|
### Step 3: Open the Ontology Debugger Tab
|
|
|
|
... | ... | @@ -45,31 +45,31 @@ Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger T |
|
|
|
|
|
### Step 4: Understanding the layout
|
|
|
|
|
|
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 of inconsistent and/or incoherent ontologies. In the following we will describe the sections and their meaning.
|
|
|
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 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_). __Correct Axioms__ are axioms that are guaranteed to be correct beforehand and are either identified as correct by an expert or are automatically assigned by the Ontology Debugger when the ontology is loaded.
|
|
|
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_). __Correct Axioms__ are axioms that are assumed to be correct beforehand and are either identified as correct by an expert or are automatically assigned by the Ontology Debugger when the ontology is loaded.
|
|
|
|
|
|
Below them, we see the list of __Possibly Faulty Axioms__ which represents the set of axioms that might be erroneous and thus might be the cause for the inconsistencies / incoherencies in your ontology.
|
|
|
|
|
|
**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 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.
|
|
|
**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 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
|
|
|
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 been answered already by the user from previous queries. They are categorized as _Entailed Test Cases_ when they have been classified as entailed in the current ontology by the user or_Non Entailed Testcases_ when they must not be entailed in the current ontology according to the user's answer. In the image below we see an exmple with three entailed and two non-entailed test cases that have been acquired by the interaction with the user.
|
|
|
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 terms of previous queries. They are categorized as _Entailed Test Cases_ when they have been classified by the user as entailed by (or correct in) the desired ontology or_Non Entailed Testcases_ when they must not be entailed by (or correct in) the desired ontology according to the user's answer. In the image below we see an example with three entailed and two non-entailed test cases that have been acquired by the interaction with the user.
|
|
|
|
|
|
![acquired_testcases](/uploads/1429db4892205ccee3ddd6ffeb9da6db/acquired_testcases.PNG)
|
|
|
|
|
|
Below the set of acquired test cases there will also be shown original test cases that are defined beforehand. This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
Below the set of acquired test cases original test cases will be shown that are defined beforehand. This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
|
|
|
##### Queries / Faulty Axioms
|
|
|
|
|
|
The left part finally shows us the most important information during a debugging session.
|
|
|
Finally, the left part shows us the most important information during a debugging session.
|
|
|
|
|
|
In the queries view we have 3 buttons that control the debugging session:
|
|
|
- Once an ontology is loaded we have to **Start** a new debugging session to start the interaction with the user. Once a debugging session has been started, the start-button changes to **Restart**. This let's the user restart a once started debugging session. ![start](/uploads/b93fbef049714ac66a819709aa3015e8/start.PNG) ![restart](/uploads/6d9ee6c92befc0981fe52c24e583928c/restart.PNG)
|
|
|
- The **Stop**-button stops a running debugging session. As long there is no running session this button is greyed out ![stop](/uploads/9a5f30421341fa4ff1a2f94437f6d52d/stop.PNG)
|
|
|
- A **Submit**-button to answer a query. This button is greyed out as long as a session has not been started and the user has not classified an axiom in the query as entailed or non-entailed. ![submit](/uploads/06b7a61d7a3d6f8fac58bc4ba7a31730/submit.PNG)
|
|
|
- The **Submit**-button is used to answer a query. This button is greyed out as long as a session has not been started or the user has not yet classified any axiom in the query as entailed or non-entailed. ![submit](/uploads/06b7a61d7a3d6f8fac58bc4ba7a31730/submit.PNG)
|
|
|
|
|
|
Let us use now press the button Start to start a new debugging session. The ontology debugger now recognizes if the ontology is consistent/coherent. Since our Koala ontology is incoherent it states the first query consisting of 2 formulas.
|
|
|
|
... | ... | @@ -77,19 +77,19 @@ Below the 3 buttons you now will see these two axioms: |
|
|
- ![axiom1](/uploads/72e8773f48025aa456a9b3720fe4fc69/axiom1.PNG)
|
|
|
- ![axiom2](/uploads/5d8a28bf5208799f8f6019e84029e707/axiom2.PNG)
|
|
|
|
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting us the possibly faulty axioms.
|
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting the different possible sets of faulty axioms. **Note** if there are multiple such sets, this means that, given the current information, each one of these sets (on its own) constitutes a possible explanation of the faulty ontology. Each additionally answered query will rule out some of these sets.
|
|
|
![possibly_Faulty](/uploads/fb81708f968681dd211a22b6af8774f4/possibly_Faulty.PNG)
|
|
|
|
|
|
Such possibly faulty axioms are calculated once the session has started or the user has given an answer to compute one or more queries. So the query given above are a result of the sets of possibly faulty axioms below. Each set of possibly faulty axioms are based on _minimal conflicts sets_ which can be shown in the Ontology Debugger's __Conflicts__ tab. **Note** that the conflict sets can only be calculated using *HS-Tree* and *HS-DAG* as *Diagnosis Engine Type* (selectable in the debuggers preferences).
|
|
|
These possible sets of faulty axioms are calculated / updated once the session has been started or the user has given an answer to a query. (At least two) sets of faulty axioms are a necessary prerequisite to compute queries. So the query given above is calculated as a result of the sets of faulty axioms below. Each set of faulty axioms can be determined based on _minimal conflicts sets_ which can be shown in the Ontology Debugger's __Conflicts__ tab. A minimal conflict set is a minimal (or irreducible) inconsistent / incoherent set of axioms in the inconsistent / incoherent ontology. **Note** that the conflict sets can only be calculated using *HS-Tree* and *HS-DAG* as *Diagnosis Engine Type* (selectable in the debuggers preferences).
|
|
|
|
|
|
### Step 5 Anwer the first query
|
|
|
### Step 5 Answer the first query
|
|
|
Continuing with the session from above, the queries section shows us the following question to be answered: ```hasDegree Domain Person``` and ```isHardWorking Domain Person```.
|
|
|
|
|
|
These two axioms are to be understood as questions generated from the Ontology Debugger given to us (for this introduction let us assume that we are experts in the domain of Marsupials). Note that the questions may be axioms already stated in the ontology or logically entailed axioms given the axioms in the ontology. An indeed these two axioms are defined explicitely in the ontology. They can be found in the set of Possibly Faulty Axioms in the right section.
|
|
|
These two axioms are to be understood as questions generated from the Ontology Debugger given to us (for this introduction let us assume that we are experts in the domain of Marsupials). Note that the questions may be axioms already stated in the ontology or axioms that are logically entailed from axioms in the ontology. In this particular case these two axioms are indeed explicitly defined in the ontology. They can be found in the set of Possibly Faulty Axioms in the right section.
|
|
|
|
|
|
The user has to answer _at least one_ question. If the user thinks this statement or axiom is true, she answers by clicking on the ![plus0](/uploads/53e6de21ab2264a301910e4e31cbc7e4/plus0.PNG) icon (__Entailed__). If she believes that this statement is false, she answers by clicking on the ![minus0](/uploads/10c449a582f342be1211599213c6480b/minus0.PNG) icon (__Not Entailed__).
|
|
|
The user has to answer _at least one_ question. If the user thinks a statement or axiom in the query is true, she answers by clicking on the ![plus0](/uploads/53e6de21ab2264a301910e4e31cbc7e4/plus0.PNG) icon (__Entailed__) next to it on the right. If she believes that the statement is false, she answers by clicking on the ![minus0](/uploads/10c449a582f342be1211599213c6480b/minus0.PNG) icon (__Not Entailed__) to the right of it.
|
|
|
|
|
|
In our example we assume that both axioms are correct since hasDegree is a domain of a person and we assume that persons are hard-working. Please note that as soon as the user answers/classifies one axiom the submit button is getting active. So the user is not forced to answer all questions.
|
|
|
In our example we assume that both axioms are correct since only persons can have a degree, i.e. the domain of ```hasDegree``` is ```Person```, and we assume that only persons can be hard-working, i.e. the domain of ```isHardWorking``` is ```Person``` as well. Please note that as soon as the user answers/classifies one axiom the submit button gets active. So the user is not forced to answer all questions.
|
|
|
|
|
|
![step1](/uploads/71eb8cb6fc4c95a048e9ab71492ece24/step1.PNG)
|
|
|
|
... | ... | |