... | ... | @@ -50,9 +50,9 @@ in the ***consistent but incoherent*** [*Koala ontology*](http://protege.stanfo |
|
|
|
|
|
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)
|
|
|
![koala](/uploads/88e5e345d79aec35eae0cbf357433fa2/image.png)
|
|
|
|
|
|
*For our tutorial please select the incoherent Koala ontology from the Bookmarks*
|
|
|
*For our tutorial 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.
|
... | ... | @@ -70,7 +70,7 @@ Please note that reasoners use different techniques to reason over ontologies. T |
|
|
|
|
|
Once you loaded the *Koala ontology*, you can open the *Ontology Debugger Tab* by selecting ```Tools->Debug Ontology...``` in the menu. You can also open the tab by selecting ```Window->Tabs->Debugger```. The initial layout of the *Ontology Debugger* should look similar to this screenshot:
|
|
|
|
|
|
![step3](/uploads/a95cb389e9994d08c452283bc453891a/image.png)
|
|
|
![step3](/uploads/0e2804fe15b841e9fccfb9528d0e2b3a/image.png)
|
|
|
|
|
|
*The Ontology Debugger Tab after the Koala ontology has been opened*
|
|
|
|
... | ... | @@ -91,7 +91,11 @@ The list of __Possibly Faulty Axioms__ represents the set of axioms that might b |
|
|
__Correct Axioms__ are axioms that are assumed to be correct. Such axioms have to be identified by the user herself before starting a new debugging session.
|
|
|
|
|
|
##### Modifying The Input Ontology
|
|
|
**Note**: When loading the *Koala ontology* the debugger assumes all logical axioms as *Possibly Faulty Axioms*. Thus all 42 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.
|
|
|
**Note**: When loading the *Koala ontology* the debugger assumes all logical axioms as *Possibly Faulty Axioms*. Thus all 42 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. Alternatively the user can select one or more axioms and either drag'n drop the selected axioms to the target or use the arrow buttons (use CTRL-A to select all axioms). Additionally the user can filter the Possibly Faulty Axioms by using the search tool bar in order to reduce the list of shown axioms.
|
|
|
|
|
|
![modifiying_input_ontology_in_action](/uploads/9621547ddebd722ba501feb10530b9d7/modifiying_input_ontology_in_action.gif)
|
|
|
|
|
|
*There are many ways to modify the Input Ontology*
|
|
|
|
|
|
#### Queries View
|
|
|
|
... | ... | @@ -129,7 +133,7 @@ While the Aquired Test Cases lists the answers the user has given in the current |
|
|
|
|
|
Note that the manual addition of test cases is not possible during a running debugging session.
|
|
|
|
|
|
![image](/uploads/74470db3ea2f456778a2c72b7d0f3929/image.png)
|
|
|
![image](/uploads/f0258da8dd3919899a12ac518142a4a5/image.png)
|
|
|
|
|
|
*This screenshot shows a handcrafted non entailed test case next to two saved entailed test cases from a previous debugging session*
|
|
|
|
... | ... | @@ -143,7 +147,7 @@ The ontology debugger first checks if the ontology is consistent and coherent. |
|
|
|
|
|
If you debug a consistent and coherent ontology, the debugger recognizes the correctness of the ontology and informs the user about the correctness of her ontology. The camera ontology (http://protege.stanford.edu/ontologies/camera.owl) for example would be such a consistent and coherent ontology - our Ontology Debugger would recognize it, notify the user and no further debugging would be necessary.
|
|
|
|
|
|
![coherent_ontology](/uploads/2068ac4641163ca52b146085b79bc43e/coherent_ontology.PNG)
|
|
|
![coherent_ontology](/uploads/7df1e6a1d5cb4a8b14e21bb3bee78973/image.png)
|
|
|
|
|
|
*A information pops up if the ontology meets the requirements (coherency and/or consistency)*
|
|
|
|
... | ... | @@ -207,7 +211,7 @@ If she is not sure about the correct answer she can leave the question unanswere |
|
|
|
|
|
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 becomes active - since, as previously stated, the user is not forced to answer all queries.
|
|
|
|
|
|
![step1](/uploads/9fb08b5de41bafb747636515743b0e3b/image.png)
|
|
|
![step1](/uploads/9900673d5148eeecab6ec8030c26ef2e/image.png)
|
|
|
|
|
|
*Answer both statements with YES and press the SUBMIT button*
|
|
|
|
... | ... | @@ -221,7 +225,7 @@ After the calculation has finished, the user is presented a new query and a new |
|
|
|
|
|
The given answers are listed as __Entailed Testcases__ in the __Acquired Test Cases View__ in the mid section, since the user answered with *YES*. Negatively answered statements are listed as __Non Entailed Testcases__.
|
|
|
|
|
|
![step2](/uploads/243cbc8fe348838a9dfa45454a41ca4d/image.png)
|
|
|
![step2](/uploads/1069756f5b6e0b35355c23f18a7a6251/image.png)
|
|
|
|
|
|
*A new query with a set of statements (including an inferred one) is presented to the user*
|
|
|
|
... | ... | @@ -231,7 +235,7 @@ Since the Ontology Debugger has not found a unique solution yet (i.e. there are |
|
|
|
|
|
**Note** that (1) performing adequate modifications to all the axioms in the obtained set of faulty axioms from the Possible Ontology Repair or (2) deleting all these axioms from the ontology is the only possible way of repairing the inconsistency / incoherency of the Input Ontology in the light of the query answers given during the debugging session. In other words, among all possible repairs of the Input Ontology, the one obtained at the end of the debugging session is the only one reflecting your desired domain model, i.e. in this case the domain model of Marsupials you believe is the correct one.
|
|
|
|
|
|
![finalstep](/uploads/0dcc1e4770802714c317ad6e34f1ef7e/image.png)
|
|
|
![finalstep](/uploads/bb475edda52ca38ac7bc75bbeec76a29/image.png)
|
|
|
|
|
|
*At the end of a debugging session the user gets notified that a Repair has been found*
|
|
|
|
... | ... | @@ -252,7 +256,7 @@ Once an ontology repair has been identified - either by the debugging process it |
|
|
|
|
|
The icon opens a repair interface to manually change or delete the problematic axioms in order to resolve the inconsistency or incoherency in the ontology.
|
|
|
|
|
|
![image](/uploads/c38206d731f95ccda053c5849dcd4c5f/image.png)
|
|
|
![image](/uploads/d43f06ce1ada0126c56a9271bd5ac2a1/image.png)
|
|
|
|
|
|
*The repair interface supports the user in the repair process by giving her the opportunity to delete and edit the axioms of the found repair.*
|
|
|
|
... | ... | @@ -268,7 +272,7 @@ From the example shown above the explanation for the selected axiom ``Quokka Sub |
|
|
|
|
|
#### Repairing
|
|
|
|
|
|
![repaired_axioms](/uploads/e19368f6caaba5ad266ba650bd7a4835/image.png)
|
|
|
![repaired_axioms](/uploads/b410df8c4c15f4ea5d538424b4115414/image.png)
|
|
|
|
|
|
We can either change the axioms in such a way that the fault is resolved by editing the axiom ![edit icon](/uploads/7deb9bce341b4cbacf707fd50a3fdf14/image.png) or simply by deleting the axiom ![delete icon](/uploads/2cccbc824322fc4fd8dd25ca8cd59a35/image.png). Deleted axiom are shown in grey color with a leading comment symbol (//).
|
|
|
|
... | ... | @@ -276,12 +280,19 @@ As long as the user does not commit the changes to the ontology, she can still r |
|
|
|
|
|
The user can commit the changes by pressing the OK button. Pressing the cancel button ignores any changes. Once the changes are committed to the ontology the debugger checks if the ontology is consistent/coherent and either informas the user that the ontology is correct or restarts a new debugging session if there are still problems with the correctness of the ontology.
|
|
|
|
|
|
|
|
|
The debugging session described in this tutorial can be seen in the following animation:
|
|
|
|
|
|
![debuggingsession_koala](/uploads/9df03436e6fb58cc3a77aa6049e47226/debuggingsession_koala.gif)
|
|
|
|
|
|
*The animated debugging session described in the tutorial*
|
|
|
|
|
|
### Step 9: Searching the knowledge base
|
|
|
We can verify that the axiom ```Quokka SubClassOf Person```is indeed an inferred axiom by searching the knowledge base (possibly faulty axioms) for axioms containing the search expression ```Quokka``` using the search bar in the input ontology view.
|
|
|
|
|
|
![search](/uploads/c9ff4e4a0c61c1ddca456abc399a8c23/search.png)
|
|
|
![search](/uploads/81811f8afeb38e9765f92b82d2491063/image.png)
|
|
|
|
|
|
The search can be either *case sensitive*, or restricted to have *whole words* or *ignoring white spaces* or a combination of these.
|
|
|
The search can be either *case sensitive*, or restricted to have *whole words* or *ignoring white spaces* or a combination of these. Additionally we can search for axioms of a specific type.
|
|
|
|
|
|
<br><br>
|
|
|
# Preference settings for the Ontology Debugger Plug-In in Protégé
|
... | ... | @@ -294,11 +305,11 @@ In the above debugging session the default settings and the *HermiT* reasoner we |
|
|
|
|
|
##### Engine Types
|
|
|
|
|
|
**Diagnosis Engines** are responsible for finding the **Possible Ontology Repairs** (or diagnoses). As **Diagnosis Engines** we can choose either between HS-DAG, HS-Tree (default) and Inv-QuickXPlain. The last algorithm computes the Possible Ontology Repairs (or diagnoses) directly, i.e. without the computation of minimal conflicts, and is the preferred choice if you want to find only a few diagnoses very fast. The other two algorithms are based on the calculation of conflicts and are preferable if you want to find the diagnoses in a best-first order (w.r.t. some repair preference order, see below). In other words, Inv-QuickXPlain tends to exhibit the least wait for the user between two consecutive queries whereas the other two engines always show the best possible sets of faulty axioms to the user in the **Possible Onology Repairs** view.
|
|
|
**Diagnosis Engines** are responsible for finding the **Possible Ontology Repairs** (or diagnoses). As **Diagnosis Engines** we can choose either between HS-Tree (default) and Inv-HS-Tree. The last algorithm computes the Possible Ontology Repairs (or diagnoses) directly, i.e. without the computation of minimal conflicts, and is the preferred choice if you want to find only a few diagnoses very fast. The other algorithm is based on the calculation of conflicts and are preferable if you want to find the diagnoses in a best-first order (w.r.t. some repair preference order, see below). In other words, Inv-HS-Tree tends to exhibit the least wait for the user between two consecutive queries whereas the other engine always show the best possible sets of faulty axioms to the user in the **Possible Ontology Repairs** view.
|
|
|
|
|
|
##### Repair Preference Order
|
|
|
|
|
|
The diagnosis engine HS-DAG and HS-Tree require Preference Functions for the generation of Possible Ontology Repairs (diagnoses).
|
|
|
The diagnosis engine HS-Tree requires Preference Functions for the generation of Possible Ontology Repairs (diagnoses).
|
|
|
|
|
|
The user can choose between three functions: **EqualCosts** equalizes all repairs (no preference), **Cardinality** (default) prefers repairs with lower numbers of axioms per repair, and **Syntax** prefers repairs with higher probability where the probability of a repair is calculated according to the occurrence of syntactic keywords in the axioms.
|
|
|
|
... | ... | |