... | ... | @@ -7,7 +7,7 @@ This plug-in is still in development! Very probably you may experience faulty an |
|
|
|
|
|
These steps are necessary in order to run the plug-in:
|
|
|
* Download the latest version of Protégé Desktop from [http://protege.stanford.edu/](http://protege.stanford.edu/) and follow the installation instructions. 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](/uploads/878b277d18b3ee7e17cb985fd75530d6/installation.PNG)
|
|
|
* Install the Ontology Debugger Plugin with Protégé's Update Function```File->Check for Plugins...``` and select *Ontology Debugger* ![Unbenannt](/uploads/71481d72ac9c72dedebdcef37d042d7f/Unbenannt.PNG)
|
|
|
|
|
|
* **Alternatively** 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, then you have to restart the client to load the plug-In.
|
... | ... | @@ -40,7 +40,7 @@ For our example we must therefore also select a reasoner. Please choose the alr |
|
|
|
|
|
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)
|
|
|
![step3](/uploads/4552840330ef1449241f3ef422f4a437/step3.PNG)
|
|
|
|
|
|
***Note*** if you do not see this layout or if you see errors then the layout has changed with a new version of the debugger. Please select ```Window->Reset selected tab to default state``` in such a case to display the current layout.
|
|
|
|
... | ... | @@ -92,11 +92,11 @@ The user has to answer _at least one_ question. If the user thinks a statement o |
|
|
|
|
|
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)
|
|
|
![step1](/uploads/ee64b251b8fde2418eb4e723d3f4ccce/step1.PNG)
|
|
|
|
|
|
Acknowledging this decision by pressing __Submit__ causes both axioms to be listed among the __Entailed Testcases__ in the view for Acquired Test Cases in the mid section.
|
|
|
|
|
|
![step2](/uploads/63bda321d784fc1792f86c6a03a1ed87/step2.PNG)
|
|
|
![step2](/uploads/e06df8117bc78a9ebce5b67bf33708cd/step2.PNG)
|
|
|
|
|
|
### Step 6 Answer all queries until the Debugger gives us a solution
|
|
|
|
... | ... | @@ -104,9 +104,9 @@ 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 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/aa1cd5248e7c58b7455ae330bcaafc86/finalstep.PNG)
|
|
|
![finalstep](/uploads/674759cfce31a893f711d81f43b08c41/finalstep.PNG)
|
|
|
|
|
|
Our debugging session ended with a found set of 3 faulty axioms:
|
|
|
As it can be seen in the image above, our debugging session ended with a found set of 3 faulty axioms:
|
|
|
- [x] ```KoalaWithPhD EquivalentTo Koala and (hasDegree value PhD)```
|
|
|
- [x] ```Quokka SubClassOf isHardWorking value true```
|
|
|
|
... | ... | @@ -117,6 +117,13 @@ You can reproduce the provided solution by taking a look at the given answers in |
|
|
|
|
|
Note that the axioms ```Quokka SubClassOf Person```as well as ```Koala DisjointWith Person``` among the acquired test cases are axioms **inferred** by the Ontology Debugger that have been presented in queries. That is, these axioms do not occur in the Input Ontology.
|
|
|
|
|
|
### Step 7 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/6b403e8c3776b10ebf445e5674db002d/search.PNG)
|
|
|
|
|
|
The search can be either *case sensitive*, or restricted to have *whole words* or *ignoring white spaces* or a combination of these.
|
|
|
![search_details](/uploads/c3fd19b948a85f18bb2026a8b8051c42/search_details.PNG)
|
|
|
|
|
|
# Preference settings for the Ontology Debugger Plug-In in Protégé
|
|
|
|
|
|
In the above debugging session the default settings and the *HermiT* reasoner were used. You can change these settings in the debugger preferences in ```File->Preferences```
|
... | ... | @@ -143,19 +150,27 @@ If you want to debug an __incoherent ontology__, the process quite often can be |
|
|
|
|
|
### Preferences for Query computation
|
|
|
|
|
|
![pref2](/uploads/b35bb2d9fa82e571415ca893c68ee568/pref2.PNG)
|
|
|
![pref2](/uploads/6e96661f5a0b8d0259168f181e22cab4/pref2.PNG)
|
|
|
|
|
|
##### Query Computation
|
|
|
Query Computation is a 3-stage process ...
|
|
|
|
|
|
**Enrich query**: By default, if possible, the generated queries are **enriched** with axioms that are not stated explicitly in the input ontology but can be deduced from axioms in the ontology using the logical reasoner. Thus the Ontology Debugger can show the user implicit consequences from the axioms given in the ontology and the acquired test cases.
|
|
|
#### Stage 1
|
|
|
Stage 1 has as goal the minimization fo the overal number of queries in the debugging session. Theere are several measures for this purpose (default: Entropy).
|
|
|
|
|
|
##### Measurements
|
|
|
|
|
|
The **Sort Criterion** is used for filtering out a preferred query among a set of possible query candidates during query computation. You can choose between **MinCard** (default) which prefers queries involving a minimal number of axioms, **MinSum** and **MinMax**. Each of the latter criteria aims at selecting a query that might be best understood by the interacting user. Moreover, you can define Requirements Measures for query selection such as **Entropy** (default), **Split in Half** and **RIO**. These aim at minimizing the number of queries to be answered by the interacting user until obtaining the correct diagnosis.
|
|
|
##### Query Quality Measure
|
|
|
You can define Query Quality Measure for query selection such as **Entropy** (default), **Split in Half** and **RIO**. These aim at minimizing the number of queries to be answered by the interacting user until obtaining the correct diagnosis.
|
|
|
|
|
|
##### Thresholds
|
|
|
Approximation parameters control the quality of the found query w.r.t. the selected measure.
|
|
|
Lower values signalize better quality but with a potentially longer query computation time.
|
|
|
(Default for Entropy: 0.5, Cardinality: 0 and Cautious 0.4).
|
|
|
|
|
|
#### Stage 2
|
|
|
Stage 2 has as goal the minimization of the number of axioms per query (MinCard) or the complexity of the query axioms (MinSum: tries to minimize the overall complexity of all query axioms; MinMax: tries to min. the complexity of the most complex query axiom). Axiom complexity is estimated from syntax fault probabilities - the higher the estimated fault prob. of the axiom, the higher the estimated complexity of it.
|
|
|
There are several Query Quality Measures for this purpose (default: Entropy).
|
|
|
|
|
|
Depending on the above selection of the Requirements Measure the threshold values can be set (Default for Entropy: 0.5, Cardinality: 0 and Cautious 0.4).
|
|
|
#### Stage 3
|
|
|
Stage 3 tries to make the query easier to understand for the user by simplifying axioms in the query. Users can select axiom types considered easy. These are used to enrich the query of Stage 2 first. Second the enriched query is optimized, i.e. a smallest and easiest possible subset of it is determined.
|
|
|
|
|
|
### Default Preferences ###
|
|
|
|
... | ... | |