... | @@ -62,7 +62,7 @@ Since we still have no solution the next set of diagnoses and queries are calcul |
... | @@ -62,7 +62,7 @@ Since we still have no solution the next set of diagnoses and queries are calcul |
|
|
|
|
|
![FinalSessionStep](/uploads/068312d3065c9bfb93cf41614570afd9/FinalSessionStep.PNG)
|
|
![FinalSessionStep](/uploads/068312d3065c9bfb93cf41614570afd9/FinalSessionStep.PNG)
|
|
|
|
|
|
You can reproduce the answers given and the resulting diagnoses by looking at the answers view in the lower right.
|
|
**Hint**: You can reproduce the answers and the resulting diagnoses with the **Answers** view in the lower right or by reproducing the answers given with the **Test Cases** on the left.
|
|
|
|
|
|
Our debugging session ended with a found set of 3 faulty axioms:
|
|
Our debugging session ended with a found set of 3 faulty axioms:
|
|
- [x] ```KoalaWithPhD EquivalentTo Koala and (hasDegree value PhD)```
|
|
- [x] ```KoalaWithPhD EquivalentTo Koala and (hasDegree value PhD)```
|
... | @@ -73,42 +73,41 @@ and |
... | @@ -73,42 +73,41 @@ and |
|
|
|
|
|
# Preference settings for the Ontology Debugger Plug-In in Protégé
|
|
# Preference settings for the Ontology Debugger Plug-In in Protégé
|
|
|
|
|
|
The above debugging session was using the default settings and the HermiT solver. You can change these settings in ```Ontology Debugger->Options```
|
|
The above debugging session was using the default settings and the *HermiT* solver. You can change these settings in ```Ontology Debugger->Options```
|
|
|
|
|
|
### Preferences for Diagnosis calculation
|
|
### Preferences for Fault Localization
|
|
|
|
|
|
![pref_diag](/uploads/b086b2ff1cc8d637f81e69cac91eba87/pref_diag.PNG)
|
|
![pref1](/uploads/0f9d049f1b4d7036d15b6eb010e5cfce/pref1.PNG)
|
|
|
|
|
|
##### Engine Types
|
|
##### Engine Types
|
|
|
|
|
|
As diagnoses engine we can choose either between Inv-QuickXPlain, HS-Tree (default) and HS-DAG. The first algorithm computes diagnoses directly, i.e. without computation of minimal conflicts, and must be used if you want to find only a few diagnoses very fast. The other two algorithms are based on computation of conflicts and are preferable if you want to use the interactive version of our debugger.
|
|
**Diagnosis Engines** are responsible for finding our **Faulty Axioms** (or diagnoses). As **Diagnosis Engines** we can choose either between HS-DAG, HS-Tree (default) and Inv-QuickXPlain. The last algorithm computes the fault axioms (or diagnoses) directly, i.e. without computation of minimal conflicts, and must be used if you want to find only a few diagnoses very fast. The other two algorithms are based on computation of conflicts and are preferable if you want to use the interactive version of our debugger.
|
|
|
|
|
|
|
|
##### Cost Estimation
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
##### Diagnoses Calculation
|
|
##### 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 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.
|
|
|
|
|
|
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 -- and by replacing the initial ontology with a set of "star" modules. The first option is selected by default. __DO NOT ENABLE THE STAR MODULE OPTION__ as this may cause deadlocks!
|
|
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.
|
|
|
|
|
|
### Preferences for Query computation
|
|
### Preferences for Query computation
|
|
|
|
|
|
![pref_query](/uploads/bbc5e8e9c0685fb3a1cf06961cf25731/pref_query.PNG)
|
|
![pref2](/uploads/fae26104a4ec12624ede7034a4d2a908/pref2.PNG)
|
|
|
|
|
|
##### Query Computation
|
|
##### Query Computation
|
|
|
|
|
|
We can define the minimal and maximal number of queries to compute. If the maximal number is smaller than the minimal, maximal equals minimal. The default for both is 1. Next we can define if we want to enrich the queries. This is enabled by default.
|
|
**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.
|
|
|
|
|
|
##### Measurements
|
|
##### Measurements
|
|
|
|
|
|
The the sort criterion is necessary for prioritizing diagnoses in 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. can either bea MinCard which preferes those , a requirements measurement and some thresholds. A detailed description of these options will follow.
|
|
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.
|
|
|
|
|
|
##### Thresholds
|
|
##### 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). A detailed description of these parameters will follow soon.
|
|
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).
|
|
|
|
|
|
### Preference measures
|
|
|
|
|
|
|
|
![pref_measures](/uploads/2f32abe48474f7b37a9724138a7977a5/pref_measures.PNG)
|
|
|
|
|
|
|
|
These measures set measures to the diagnoses.
|
|
|
|
|
|
|
|
The user can choose between Cardinality (default) which simply count the number of axioms per diagnoses, EqualCosts which equalizes all diagnoses and Syntax which calculates the diagnoses measures according to the occurrence of keywords in the axioms. |
|
|
|
\ No newline at end of file |
|
|