... | ... | @@ -6,7 +6,7 @@ |
|
|
|
|
|
* You may experience faulty and unexpected behaviour such as deadlocks, exceptions etc. You may report any bugs you experience in our [feedback](http://isbi.aau.at/ontodebug/feedback). [We](http://isbi.aau.at/ontodebug/team) will try to fix them as soon as possible.
|
|
|
* There are still many features missing that we plan to implement ([see the list of open issues](https://git-ainf.aau.at/interactive-KB-debugging/debugger/issues)). If you have ideas for features that would be nice to have [we](http://isbi.aau.at/ontodebug/team) would be pleased if you [send us your request](http://isbi.aau.at/ontodebug/feedback).
|
|
|
* Please note that this plugin is a BETA ! **If you experience a faulty behaviour of your Protégé instance** (for example your Protege cannot start), it *may* be that this plugin causes the error. You can test this in the following way: delete the file called "*org.exquisite.protege-\<x.y.z>.BETA.jar*" in the "*plugins*" subdirectory of your Protege installation directory and restart Protégé (the *\<x.y.z>* represents the current version such as 0.1.4). In the same way you can also check other plugins if they are responsible for the fault. If this plugin is not causing the error you can later reinstall it.
|
|
|
* Please note that this plugin is a BETA ! **If you experience a faulty behaviour of your Protégé instance** (for example your Protege cannot start), it *may* be that this plugin causes the error. You can test this in the following way: delete the file called "*org.exquisite.protege-\<x.y.z>.BETA.jar*" in the "*plugins*" subdirectory of your Protege installation directory and restart Protégé (the *\<x.y.z>* represents the current version such as 0.1.5). In the same way you can also check other plugins if they are responsible for the fault. If this plugin is not causing the error you can later reinstall it.
|
|
|
|
|
|
<br><br>
|
|
|
# Installation
|
... | ... | @@ -14,7 +14,7 @@ |
|
|
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_plugin](/uploads/93eff0f60980596022e284b38bc3679e/installation_plugin.PNG)
|
|
|
* Install the Ontology Debugger Plugin with Protégé's Update Function```File->Check for Plugins...``` and select *Ontology Debugger* ![installation_plugin](/uploads/479c1b78deb462462d492664a9d6ac55/image.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 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 ...```
|
... | ... | @@ -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/1b7a63618ffc50cd0cd5dc333b50e3ce/step3.png)
|
|
|
![step3](/uploads/2cbd91a07df7a852d1afdaecc8f27c99/image.png)
|
|
|
|
|
|
*The Ontology Debugger Tab after the Koala ontology has been opened*
|
|
|
|
... | ... | @@ -82,16 +82,16 @@ The Ontology Debugger is divided into three sections where each one is responsib |
|
|
|
|
|
#### The Input Ontology View
|
|
|
|
|
|
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.
|
|
|
The rightmost section shows us a list of all logical axioms from the the currently used __Input Ontology__ separating them between the list of __Possibly Faulty Axioms__ (the _Knowledge Base_ or _KB_) and the list of __Correct Axioms__ (also called the _Background Knowledge_).
|
|
|
|
|
|
##### 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.
|
|
|
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. When loading or creating a new ontology, by default all logical axioms are assumed to be possibly faulty. The user can then decide if some of these axioms are correct.
|
|
|
|
|
|
##### Correct Axioms
|
|
|
__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 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.
|
|
|
**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.
|
|
|
|
|
|
#### Test Cases View
|
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown.
|
... | ... | @@ -106,9 +106,12 @@ In the image below we see an example with three Entailed Testcases and one Non E |
|
|
*The Acquired Test Cases show us the answers - the yellow background color highlights an inferred axiom*
|
|
|
|
|
|
##### Original Test Cases
|
|
|
Below the set of Acquired Test Cases the **Original Test Cases** are shown that are defined beforehand.
|
|
|
Next to the set of Acquired Test Cases you have the **Original Test Cases** showing manually added test cases.
|
|
|
|
|
|
While the Aquired Test Cases lists the answers the user has given the Original Test Cases list manually added axioms that the user wants to be entailed or not entailed in the intended ontology.
|
|
|
![image](/uploads/944a1007a47741af7ebc0c92d1f4de26/image.png)
|
|
|
|
|
|
**Note**: This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
* The Original Test Cases lists handcrafted entailed and non-entailed test cases*
|
|
|
|
|
|
#### Queries View
|
|
|
|
... | ... | @@ -136,7 +139,7 @@ Since our Koala ontology is incoherent it will present us the following two stat |
|
|
|
|
|
In the Queries view you now will see these two axioms:
|
|
|
|
|
|
![first_two_axioms](/uploads/1e8f5381ed0541131964117598fc6fa9/first_two_axioms.PNG)
|
|
|
![first_two_axioms](/uploads/ca34a2f515a4598c62d583aaf3cda574/image.png)
|
|
|
|
|
|
*Note: if you got other axioms, then you probably have selected different preference values and/or have selected a different reasoner - use the default prefence values (see below) and HermiT for this tutorial*
|
|
|
|
... | ... | @@ -144,7 +147,7 @@ In the Queries view you now will see these two axioms: |
|
|
|
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting the different **Possible Ontology Repairs**.
|
|
|
|
|
|
![possible_ontology_repairs](/uploads/ad82aabc72e11f3c36cdf56d33749e25/possible_ontology_repairs.PNG)
|
|
|
![possible_ontology_repairs](/uploads/d6e333cf0933dfa80e4c9dea86751442/image.png)
|
|
|
|
|
|
*Repairs are possible erroneous axioms - we are finished when we get one such repair*
|
|
|
|
... | ... | @@ -156,6 +159,8 @@ In our example however there have been identified multiple Possible Ontology Rep |
|
|
|
|
|
What is a Possible Ontology Repair? It means that, given the current information, each one of these sets of possible faulty axioms (on its own) constitutes a possible explanation of the faulty ontology. Each additionally answered query will narrow down the Possible Ontology Repairs.
|
|
|
|
|
|
Note the repair icon ![repair](/uploads/eca7e2ec3b3b3e8ca20d5444f51b5361/repair.png) that comes with every possible ontology repair. This icon enables a per-axiom modification or deletion of each found repair set of axioms. A detailed description of this feature will be presented later, when a final repair is fond.
|
|
|
|
|
|
#### Conflicts View
|
|
|
|
|
|
Each Possible Ontology Repair consisting of a set of faulty axioms is calculated based on so called _minimal conflicts sets_. A minimal conflict set is a minimal (or irreducible) inconsistent / incoherent set of axioms in the inconsistent / incoherent ontology.
|
... | ... | @@ -174,7 +179,7 @@ and |
|
|
-```isHardWorking Domain Person```.
|
|
|
|
|
|
|
|
|
![first_two_axioms](/uploads/1e8f5381ed0541131964117598fc6fa9/first_two_axioms.PNG)
|
|
|
![first_two_axioms](/uploads/ca34a2f515a4598c62d583aaf3cda574/image.png)
|
|
|
|
|
|
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).
|
|
|
|
... | ... | @@ -184,25 +189,27 @@ If the user thinks a statement in the query is true, she answers by clicking on |
|
|
|
|
|
If she believes that the statement is false, she answers by clicking on the ![minus0](/uploads/10c449a582f342be1211599213c6480b/minus0.PNG) icon (__No, this statement is not true__) to the right of it.
|
|
|
|
|
|
If she is not sure about the correct answer she can leave the question unanswered by either deselecting given answers or by clicking the question mark ![not_sure](/uploads/a336fcc84bd6616bdca870d9c0ffc721/not_sure.PNG) icon (__I am not sure about this about this statement__).
|
|
|
If she is not sure about the correct answer she can leave the question unanswered by deselecting already given answers.
|
|
|
|
|
|
**Note**: in order to proceed the user __has to answer at least one question__ in the current set of queries, it is not necessary to answer all queries. If the user is unsure about the correctness of an axiom she can leave this statement unanswered.
|
|
|
|
|
|
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/b16660d4ac3eaa898adce04a71b752a6/step1.png)
|
|
|
![step1](/uploads/3a4abb8af1214bf5b0f958ed36158839/image.png)
|
|
|
|
|
|
*Answer both statements with YES and press the SUBMIT button*
|
|
|
|
|
|
Acknowledging this decision by pressing __Submit__ causes the Ontology Debugger to take the users answers into account for the calculation of a new set of repairs and a new query.
|
|
|
|
|
|
Since the calculation may take some time - this heavily depends on the size and complexity of the ontology, on the preferred number of maximal ontology repairs, the selected reasoner and other influencing factors - a window pops up to inform the user about the progress of the calculation.
|
|
|
Since the calculation may take some time - this heavily depends on the size and complexity of the ontology, on the preferred number of maximal ontology repairs, the selected reasoner and other influencing factors - a window pops up to inform the user about the progress of the calculation.
|
|
|
|
|
|
**Note**: To reduce this complexity, **module extraction** is enabled by default. Once a debugging session starts the module extraction comes into play and reduces the set of possibly faulty axioms to a fragment of possibly faulty axioms that still preserve the inconsistency/incoherency. In our case the set of initially 42 possibly faulty axioms has been reduced to 20 as soon as the debugging session has been started. Module extraction can be turned on/off in the preference settings.
|
|
|
|
|
|
After the calculation has finished, the user is presented a new query and a new set of possible repairs (see below).
|
|
|
|
|
|
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/b7aca8279cd4c9869d96384382aa39a7/step2.png)
|
|
|
![step2](/uploads/8a7b96ac321c100918fbd981230ec07f/image.png)
|
|
|
|
|
|
*A new query with a set of statements (including an inferred one) is presented to the user*
|
|
|
|
... | ... | @@ -212,7 +219,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/3264b384e6aaef83d50c77d11d6da902/finalstep.png)
|
|
|
![finalstep](/uploads/0dcc1e4770802714c317ad6e34f1ef7e/image.png)
|
|
|
|
|
|
*At the end of a debugging session the user gets notified that a Repair has been found*
|
|
|
|
... | ... | @@ -227,7 +234,37 @@ You can reproduce the provided solution either by taking a look at the given ans |
|
|
|
|
|
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 are not listed in the Input Ontology.
|
|
|
|
|
|
### Step 8: Searching the knowledge base
|
|
|
### Step 8: Repair the ontology
|
|
|
|
|
|
Once an ontology repair has been identified - either by the debugging process itself or as soon as the user identifies the problematic axioms during the debugging session by herself - the user can **repair** the problematic axioms by pressing the repair icon ![repair](/uploads/eca7e2ec3b3b3e8ca20d5444f51b5361/repair.png).
|
|
|
|
|
|
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)
|
|
|
|
|
|
*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.*
|
|
|
|
|
|
#### Explanations
|
|
|
|
|
|
In addition the user can get an explanation (if enabled) of why the currently selected axiom is problematic. There are two possible reasons why an axiom from the ontology repair may be problematic:
|
|
|
* either it is responsible for an inconsistency/incoherency
|
|
|
* or it is responsible for the entailment of an axiom that has been explicitely declared as non-entailed by the user.
|
|
|
|
|
|
Such an explanation is supposed to give the user a hint of how the selected axiom of a repair contributes to the faults and what to change in the axiom in order to obtain a correct ontology.
|
|
|
|
|
|
From the example shown above the explanation for the selected axiom ``Quokka SubClassOf isHardWorking value true`` shows us that this axiom is responsible for an inconsistency/incoherency (expressed by owl:Thing SubClassOf owl:Nothing) and lists some axioms explaining this inconsistency/incoherency. Analysis of these elucidates that a ``Quokka`` is a ``Marsupial`` (axiom 5) and a ``Person`` (axiom 2 and 4) simultaneously. However, since the Marsupial and Person are disjoint classes (axiom 1), the Quokka class is unsatisfiable.
|
|
|
|
|
|
#### Repairing
|
|
|
|
|
|
![repaired_axioms](/uploads/e19368f6caaba5ad266ba650bd7a4835/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 (//).
|
|
|
|
|
|
As long as the user does not commit the changes to the ontology, she can still restore deleted and edited axioms to it's original version ![restore icon](/uploads/6c4bc5e57a4a09904bbe5addcfce19c8/image.png).
|
|
|
|
|
|
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.
|
|
|
|
|
|
### 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)
|
... | ... | @@ -241,7 +278,7 @@ In the above debugging session the default settings and the *HermiT* reasoner we |
|
|
|
|
|
### Preferences for Fault Localization
|
|
|
|
|
|
![pref1](/uploads/4d99be46e71a9f621cc2c851a42682e4/pref1.PNG)
|
|
|
![pref1](/uploads/e1611544ed2bac964c2e522626c8ca7e/image.png)
|
|
|
|
|
|
##### Engine Types
|
|
|
|
... | ... | @@ -259,9 +296,11 @@ Next you can choose how many repairs you want the debugger to calculate at most |
|
|
|
|
|
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.
|
|
|
|
|
|
In addition by using module extraction the process can once again be sped up as the search space in problematic ontologies can be reduced dramatically. By default this option is enabled.
|
|
|
|
|
|
### Preferences for Query computation
|
|
|
|
|
|
![pref2](/uploads/fb85edeca2870e18e5a5ec669bb4c719/pref2.PNG)
|
|
|
![pref2](/uploads/45dd7e97538ae4dfe8384cd42f801054/image.png)
|
|
|
|
|
|
age 1 has as goal the minimization of the overall number of queries in the debugging session. There are several measures for this purpose (default: Entropy).
|
|
|
|
... | ... | @@ -294,6 +333,8 @@ These default preferences were used for this tutorial. |
|
|
|
|
|
**also repair incoherency**: _yes_
|
|
|
|
|
|
**enable module extraction**: _yes_
|
|
|
|
|
|
**Query Quality Measure**: _Entropy_
|
|
|
|
|
|
**Approx. Parameters**:
|
... | ... | |