| ... | @@ -60,7 +60,7 @@ Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger T |
... | @@ -60,7 +60,7 @@ Once you have loaded the *Koala ontology*, you can open the *Ontology Debugger T |
|
|
|
|
|
|
|
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 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 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_).
|
|
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_).
|
|
|
|
|
|
| ... | @@ -70,58 +70,64 @@ __Correct Axioms__ are axioms that are assumed to be correct beforehand and are |
... | @@ -70,58 +70,64 @@ __Correct Axioms__ are axioms that are assumed to be correct beforehand and are |
|
|
##### Possibly Faulty Axioms
|
|
##### 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.
|
|
|
|
|
|
|
|
##### Moving axioms
|
|
##### 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  and  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 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  and  to assume axioms to be either _possibly faulty_ or _correct_, respectively.
|
|
|
|
|
|
|
|
#### Test Cases
|
|
#### Test Cases View
|
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown.
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown.
|
|
|
|
|
|
|
|
|
##### Acquired Test Cases
|
|
|
**Acquired Test Cases** are axioms that have already been answered by the user in previous queries. They are either categorized as _Entailed Test Cases_ when they have been classified by the user as correct statements in the ontology or as _Non Entailed Testcases_ when they must not be entailed in (these statements are not correct) the ontology according to the user's answer.
|
|
**Acquired Test Cases** are axioms that have already been answered by the user in previous queries. They are either categorized as _Entailed Test Cases_ when they have been classified by the user as correct statements in the ontology or as _Non Entailed Testcases_ when they must not be entailed in (these statements are not correct) the ontology according to the user's answer.
|
|
|
|
|
|
|
|
In the image below we see an example with three Entailed Testcases and one Non Entailed Testcase which have been acquired during the interaction with the user.
|
|
In the image below we see an example with three Entailed Testcases and one Non Entailed Testcase which have been acquired during the interaction with the user.
|
|
|
|
|
|
|
|
*The Acquired Test Cases show us the answers - the yellow background color highlights an inferred axiom*
|
|
*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.
|
|
Below the set of Acquired Test Cases the **Original Test Cases** are shown that are defined beforehand.
|
|
|
|
|
|
|
|
**Note**: This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
**Note**: This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
|
|
|
|
|
##### Queries
|
|
#### Queries View
|
|
|
|
|
|
|
|
Finally, the left part shows us the most important information during a debugging session.
|
|
Finally, the leftmost part shows us the most important information during a debugging session.
|
|
|
|
|
|
|
|
In the **Queries** view we have 3 buttons that control the 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 enables the user to start again 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 enables the user to start again the debugging session.  
|
|
|
- The **Stop**-button stops a running debugging session. As long there is no running session this button is disabled (greyed out) 
|
|
- The **Stop**-button stops a running debugging session. As long there is no running session this button is disabled (greyed out) 
|
|
|
- The **Submit**-button is used to **answer a query**. This button is greyed out as long as a session has not been started or - once started - as long as the user has not yet classified any axiom in the query as entailed or non-entailed. 
|
|
- The **Submit**-button is used to **answer a query**. This button is greyed out as long as a session has not been started or - once started - as long as the user has not yet classified any axiom in the query as entailed or non-entailed. 
|
|
|
|
|
|
|
|
### Step 5: Starting a new debugging session
|
|
### Step 5: Starting a new Debugging Session
|
|
|
|
|
|
|
|
Let's press the button Start to start a new debugging session!
|
|
Let's press the button Start to start a new debugging session!
|
|
|
|
|
|
|
|
The ontology debugger first checks if the ontology is consistent/coherent.
|
|
The ontology debugger first checks if the ontology is consistent and coherent.
|
|
|
|
|
|
|
|
If you debug a consistent / 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 - no further debugging is necessary.
|
|
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.
|
|
|
 *A information pops up if the ontology meets the requirements (coherency and/or consistency)*
|
|
 *A information pops up if the ontology meets the requirements (coherency and/or consistency)*
|
|
|
|
|
|
|
|
Since our Koala ontology is incoherent it will present us the following two statements as part of the first query:
|
|
Since our Koala ontology is incoherent it will present us the following two statements as part of the first query:
|
|
|
|
|
|
|
|
In the Queries view you now will see these two axioms:
|
|
In the Queries view you now will see these two axioms:
|
|
|
*Note: if you get other axioms, then you have set different preference values - use the default prefence values (see below) in this tutorial*
|
|
*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*
|
|
|
|
|
|
|
|
##### Possible Ontology Repairs
|
|
#### The Possible Ontology Repairs View
|
|
|
|
|
|
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting the different **Possible Ontology Repairs**.
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting the different **Possible Ontology Repairs**.
|
|
|
|
|
|
|
|
*Repairs are possible erroneous axioms - we are finished when we get one such repair*
|
|
*Repairs are possible erroneous axioms - we are finished when we get one such repair*
|
|
|
|
|
|
|
|
These Possible Ontology Repairs represent sets of possibly faulty axioms and are calculated once the session has been started or each time after the user submits an answer to a query.
|
|
These Possible Ontology Repairs represent sets of possibly faulty axioms and are calculated once the session has been started and are recalculated each time after the user submits a query answer.
|
|
|
|
|
|
|
|
If only one Possible Ontology Repair has been found then we have identified the faulty axioms that altogether explain inconsistency/incoherency in the ontology and the debugging session is finished.
|
|
If only one Possible Ontology Repair has been found then we have identified the faulty axioms that altogether explain the inconsistency and/ or the incoherency in the ontology and the debugging session is finished.
|
|
|
|
|
|
|
|
In our example however there have been identified multiple Possible Ontology Repairs by the Ontology Debugger. This 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.
|
|
In our example however there have been identified multiple Possible Ontology Repairs by the Ontology Debugger. In detail our debugger found 9 Possible Ontology Repairs because we defined in our preferences that the debugger should stop the search for Possible Ontology Repairs after maximal 9 found diagnoses.
|
|
|
|
|
|
|
|
**Additional Info**: 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.
|
|
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.
|
|
|
|
|
|
|
|
#### 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.
|
|
|
|
|
|
|
|
The minimal conflict sets can be viewed in the Ontology Debugger's __Conflicts__ view (you can enable it with ```Window->Views->Debugger views->Conflicts```).
|
|
The minimal conflict sets can be viewed in the Ontology Debugger's __Conflicts__ view (you can enable it with ```Window->Views->Debugger views->Conflicts```).
|
|
|
|
|
|
| ... | @@ -143,28 +149,27 @@ These two axioms are to be understood as questions generated from the Ontology D |
... | @@ -143,28 +149,27 @@ These two axioms are to be understood as questions generated from the Ontology D |
|
|
|
|
|
|
|
Note that the questions either may be axioms already stated in the ontology or axioms that are logically inferred in our ontology. Logical inferences are consequences that follow from explicit 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 section of the Input Ontology view (you can use the search function). Inferred axioms are highlighted in a yellow background color.
|
|
Note that the questions either may be axioms already stated in the ontology or axioms that are logically inferred in our ontology. Logical inferences are consequences that follow from explicit 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 section of the Input Ontology view (you can use the search function). Inferred axioms are highlighted in a yellow background color.
|
|
|
|
|
|
|
|
The user has to answer _at least one_ of these queries.
|
|
|
|
|
|
|
|
|
|
If the user thinks a statement in the query is true, she answers by clicking on the  icon (__Yes, this statement is true__) next to it.
|
|
If the user thinks a statement in the query is true, she answers by clicking on the  icon (__Yes, this statement is true__) next to it.
|
|
|
|
|
|
|
|
If she believes that the statement is false, she answers by clicking on the  icon (__No, this statement is not true__) to the right of it.
|
|
If she believes that the statement is false, she answers by clicking on the  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  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 either deselecting given answers or by clicking the question mark  icon (__I am not sure about this about this statement__).
|
|
|
|
|
|
|
|
**Important**: in order to proceed the user __has to answer at least one question__ in the current set of queries.
|
|
**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 - the user is not forced to answer all queries.
|
|
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.
|
|
|
|
|
|
|
|
*Answer both statements with YES and press the SUBMIT button*
|
|
*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 new set of queries.
|
|
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 (depending on the size and complexity of the ontology), a window pops up to show the user 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.
|
|
|
|
|
|
|
|
Afterwards new Queries and Possible Repair Sets are presented to the user.
|
|
After the calculation has finished, the user is presented another Query and another set of possible repairs (see below).
|
|
|
|
|
|
|
|
Both previously given answers are now listed among the __Entailed Testcases__ in the view for Acquired Test Cases in the mid section (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__.
|
|
|
|
|
|
|
|
*A new set of Queries is presented to the user*
|
|
*A new query with a set of statements (including an inferred one) is presented to the user*
|
|
|
|
|
|
|
|
### Step 7: Answer all queries until the Debugger gives us a solution
|
|
### Step 7: Answer all queries until the Debugger gives us a solution
|
|
|
|
|
|
| ... | | ... | |
