... | ... | @@ -17,26 +17,27 @@ These steps are necessary in order to run the plug-in: |
|
|
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*** to the user in the form of axioms.
|
|
|
- Each axiom given in 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?***
|
|
|
- The user then can give the answer yes if she thinks that this axiom must hold for the ontology or no otherwise.
|
|
|
- Note that the axioms in a query can be either already given explicitely in the ontology or they can be new to the user since they are inferred from the existing set of axioms in the ontology and the answers given before.
|
|
|
- The answers given by the user are also taken into account in the process of narrowing down the set of faulty axiom sets.
|
|
|
- As long as there are more than one set of faulty axioms that together explain the inconsistency/incoherency, the Ontology Debugger repeats with stating questions to 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?***
|
|
|
- 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.
|
|
|
- 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.
|
|
|
|
|
|
### Step 1: Load the ontology
|
|
|
To demonstrate these 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.
|
|
|
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.
|
|
|
|
|
|
![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 provided *Hermit Reasoner* in the ```Reasoner``` menu. ![reasoner](/uploads/654ee6fdd1959cc9f947945776142d1b/reasoner.PNG)
|
|
|
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)
|
|
|
|
|
|
### Step 3: Open the Ontology Debugger Tab
|
|
|
|
|
|
Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger Tab* by selecting ```Tools->Debug Ontology...``` in the menu. You may also activate the tab by selecting it in ```Window->Tabs```. The initial layout of the *Ontology Debugger* should look similar to this:
|
|
|
Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger Tab* by selecting ```Tools->Debug Ontology...``` in the menu. You may also activate the tab by enabling the tab with ```Window->Tabs->Debugger```. The initial layout of the *Ontology Debugger* should look similar to this screenshot:
|
|
|
|
|
|
![step3](/uploads/3b5d8a2e56f26a7e9a4475c87dbc00c8/step3.PNG)
|
|
|
|
... | ... | @@ -44,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 kind of data 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 of inconsistent and/or incoherent ontologies. In the following we will describe the 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.
|
|
|
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.
|
|
|
|
|
|
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 expert can modify this two lists by clicking on the icons ![possibly_Faulty](/uploads/d152029365ddc44a0946c68e3ece74b7/possibly_Faulty.PNG) and the ![correct](/uploads/433f214d1523b2ec6c3ba2ef66aa83f9/correct.PNG) to assume axioms as 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 middle section the so called acquired and the original test cases of the current debugging session are shown. Acquired test cases are the answered axioms. They are named _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 following image we see two test cases that have been answered by an experted which have to be entailed in the _Koala_ ontology.
|
|
|
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.
|
|
|
|
|
|
![acquired_testcases](/uploads/1429db4892205ccee3ddd6ffeb9da6db/acquired_testcases.PNG)
|
|
|
|
|
|
Below the set of acquired test cases there will also be shown original test cases that are given beforehand. This feature however is not yet implemented and thus we omit this part.
|
|
|
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.
|
|
|
|
|
|
##### Queries / Faulty Axioms
|
|
|
|
|
|
The left part finally shows us the most important information during a debugging session.
|
|
|
|
|
|
First we have 3 buttons:
|
|
|
- Start to start a new debugging session. Once a session has been started this button changes to restart. This let's the user restart a running session. ![start](/uploads/b93fbef049714ac66a819709aa3015e8/start.PNG)
|
|
|
- Stop to stop a running session. As long there is no running session this button is greyed out ![stop](/uploads/9a5f30421341fa4ff1a2f94437f6d52d/stop.PNG)
|
|
|
- Submit to answer a query. As long as a session has not been started ad the user has not classified a formulated axiom in the query as entailed or non-entailed this button is greyed out. ![submit](/uploads/06b7a61d7a3d6f8fac58bc4ba7a31730/submit.PNG)
|
|
|
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)
|
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -82,13 +83,13 @@ Let us ignore these two axioms at first and let us concentrate on the lower part |
|
|
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).
|
|
|
|
|
|
### Step 5 Anwer the first query
|
|
|
Given the session from above, the queries section will show us the following question to be answered: ```hasDegree Domain Person``` and ```isHardWorking Domain Person```.
|
|
|
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 (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.
|
|
|
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.
|
|
|
|
|
|
The expert has to answer _at least one_ question. If the expert 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 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__).
|
|
|
|
|
|
In our example we assume both axioms as correct since hasDegree is a domain of a person and persons are hardworking. Please note that as soon as the user answers/classifies one axiom the submit button is getting active.
|
|
|
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.
|
|
|
|
|
|
![step1](/uploads/71eb8cb6fc4c95a048e9ab71492ece24/step1.PNG)
|
|
|
|
... | ... | @@ -98,7 +99,7 @@ Acknowledging this decision by pressing __Submit__ list both axioms in the list |
|
|
|
|
|
### Step 6 Answer all queries until the Debugger gives us a solution
|
|
|
|
|
|
Since we still have no solution the next set of diagnoses and queries are calculated immediately after our first submission. If we continue answering the questions we should finally find a final set of faulty axioms (a diagnosis) corresponding to our test cases and which represents the possibly faulty axioms in the ontology.
|
|
|
Since the Ontology Debugger has not found a solution yet a new set of faulty axioms sets and queries are calculated after the user pressed the Submit-button. If we continue answering the questions we should finally find a set of faulty axioms (also known as diagnosis) corresponding to our Acquire Test Cases and Input Ontology.
|
|
|
|
|
|
![finalstep](/uploads/aa1cd5248e7c58b7455ae330bcaafc86/finalstep.PNG)
|
|
|
|
... | ... | @@ -109,7 +110,9 @@ Our debugging session ended with a found set of 3 faulty axioms: |
|
|
and
|
|
|
- [x] ```Koala SubClassOf isHardWorking value false```.
|
|
|
|
|
|
**Hint**: You can reproduce this final set of faulty axioms by looking at the given answers in the **Acquired test cases ** view in the mid section in the picture above.
|
|
|
You can reproduce the solution given by taking a look at the given answers in the **Acquired test cases ** view in the mid section in the picture above.
|
|
|
|
|
|
Note that the axioms ```Quokka SubClassOf Person```as well as ```Koala DisjointWith Person``` have been **inferred** by the Ontology Debugger and have been presented in queries.
|
|
|
|
|
|
# Preference settings for the Ontology Debugger Plug-In in Protégé
|
|
|
|
... | ... | @@ -127,13 +130,13 @@ The above debugging session was using the default settings and the *HermiT* solv |
|
|
|
|
|
The diagnosis engine HS-DAG and HS-Tree need cost estimation functions for the generation of fault axioms (diagnoses).
|
|
|
|
|
|
The user can choose between **EqualCosts** which equalizes all diagnoses , **Cardinality** (default) which simply count the number of axioms per diagnoses, and **Syntax** which calculates the diagnoses measures according to the occurrence of keywords in the axioms.
|
|
|
The user can choose between **EqualCosts** which equalizes all diagnoses , **Cardinality** (default) which simply count the number of axioms per diagnosis, and **Syntax** which calculates the diagnoses measures according to the occurrence of keywords in the axioms.
|
|
|
|
|
|
##### Diagnoses Calculation
|
|
|
|
|
|
Next we can choose how many diagnoses we want to calculate at most (default is 9). Please note that the higher the number the more time is required to calculate depending on the complexity of the ontology.
|
|
|
Next we can choose how many faulty axiom sets we want to calculate at most (default is 9). Please note that the higher the number the more time is required to calculate depending on the complexity of the ontology.
|
|
|
|
|
|
If you want to debug an __incoherent ontology__, the process quite often can be speed up by reducing the incoherency to inconsistency -- by adding a new individual to every unsatisfiable class. By default this option is enabled, want to be able to debug both inconsistent and incoherent ontologies.
|
|
|
If you want to debug an __incoherent ontology__, the process quite often can be sped up by reducing the incoherency to inconsistency -- by adding a new individual to every unsatisfiable class. By default this option is enabled, since we normally want to be able to debug both inconsistent and incoherent ontologies.
|
|
|
|
|
|
### Preferences for Query computation
|
|
|
|
... | ... | @@ -141,13 +144,38 @@ If you want to debug an __incoherent ontology__, the process quite often can be |
|
|
|
|
|
##### Query Computation
|
|
|
|
|
|
**Enrich query**: by default, if possible, we want to **enrich** the generated queries with axioms that are not stated explicitely in our ontology but can be followed using logical reasoning mechanism. Thus the Ontology Debugger can show the expert consequences from the axioms given in the ontology.
|
|
|
**Enrich query**: by default, if possible, we want to **enrich** the generated queries with axioms that are not stated explicitely in our ontology but can be followed using logical reasoning mechanism. Thus the Ontology Debugger can show the user consequences from the axioms given in the ontology and the acquired test cases.
|
|
|
|
|
|
##### Measurements
|
|
|
|
|
|
The the **Sort Criterion** is necessary for prioritizing faulty axioms (diagnoses) in the query computation. You can choose between MinCard (default), MinSum and MinMax. Next you can define Requirements Measurements such as Entropy (default), Split in Half and RIO.
|
|
|
The **Sort Criterion** is necessary for prioritizing faulty axioms (diagnoses) in the query computation. You can choose between MinCard (default), MinSum and MinMax. Next you can define Requirements Measurements such as Entropy (default), Split in Half and RIO.
|
|
|
|
|
|
##### Thresholds
|
|
|
|
|
|
Depending on the above selection of the Requirements Measurement the threshold values can be set (Default for Entropy: 0.5, Cardinality: 0 and Cautious 0.4).
|
|
|
|
|
|
### Default Preferences ###
|
|
|
|
|
|
These default preferences were used for this tutorial.
|
|
|
|
|
|
**Engine Type**: _HS-Tree_
|
|
|
|
|
|
**Cost Estimation**: _Cardinality_
|
|
|
|
|
|
**Number of Faulty Axiom Sets**: _9_
|
|
|
|
|
|
**also check for incoherency**: _yes_
|
|
|
|
|
|
**enrich query**: _yes_
|
|
|
|
|
|
**Sort Criterion**: _MinCard_
|
|
|
|
|
|
**Requirements Measure**: _Entropy_
|
|
|
|
|
|
**Entropy Threshold**: _0,05_
|
|
|
|
|
|
**Cardinality Threshold**:_0_ (when active)
|
|
|
|
|
|
**Cautious Parameter**:_0,4_ (when active)
|
|
|
|
|
|
|