... | ... | @@ -50,79 +50,113 @@ The Ontology Debugger is divided into three sections where each one is responsib |
|
|
|
|
|
##### The Input Ontology
|
|
|
|
|
|
The right section shows us a list of all 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__ are axioms that are assumed to be correct beforehand and are either identified as correct by an expert or are automatically assigned by the Ontology Debugger when the ontology is loaded.
|
|
|
The right section shows us a list of all 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_).
|
|
|
|
|
|
Below them, we see the list of __Possibly Faulty Axioms__ which represents the set of axioms that might be erroneous and thus might be the cause for the inconsistencies / incoherencies in your ontology.
|
|
|
__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.
|
|
|
|
|
|
**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 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.
|
|
|
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.
|
|
|
|
|
|
**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.
|
|
|
|
|
|
##### Test Cases
|
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown. Acquired test cases are axioms that have already been answered by the user in terms of previous queries. They are categorized as _Entailed Test Cases_ when they have been classified by the user as entailed by (or correct in) the desired ontology or_Non Entailed Testcases_ when they must not be entailed by (or correct in) the desired ontology according to the user's answer. In the image below we see an example with three entailed and two non-entailed test cases that have been acquired by the interaction with the user.
|
|
|
In the mid section the so called **acquired** and **original test cases** of the current debugging session are shown.
|
|
|
|
|
|
**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.
|
|
|
|
|
|
![acquired_testcases](/uploads/1429db4892205ccee3ddd6ffeb9da6db/acquired_testcases.PNG)
|
|
|
![acquired_testcases](/uploads/cd4ad4276d8c4d7f03eca85d6230bcbd/acquired_testcases.PNG)
|
|
|
|
|
|
Below the set of acquired test cases original test cases will be shown that are defined beforehand. This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
Below the set of Acquired Test Cases the **Original Test Cases** are shown that are defined beforehand.
|
|
|
|
|
|
##### Queries / Faulty Axioms
|
|
|
**Note**: This will be a future feature which is not yet implemented and thus we can omit this part at the moment.
|
|
|
|
|
|
##### Queries
|
|
|
|
|
|
Finally, the left part shows us the most important information during a 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 let's the user restart a once started debugging session. ![start](/uploads/b93fbef049714ac66a819709aa3015e8/start.PNG) ![restart](/uploads/6d9ee6c92befc0981fe52c24e583928c/restart.PNG)
|
|
|
- The **Stop**-button stops a running debugging session. As long there is no running session this button is greyed out ![stop](/uploads/9a5f30421341fa4ff1a2f94437f6d52d/stop.PNG)
|
|
|
- The **Submit**-button is used to answer a query. This button is greyed out as long as a session has not been started or the user has not yet classified any axiom in the query as entailed or non-entailed. ![submit](/uploads/06b7a61d7a3d6f8fac58bc4ba7a31730/submit.PNG)
|
|
|
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. ![start](/uploads/b93fbef049714ac66a819709aa3015e8/start.PNG) ![restart](/uploads/6d9ee6c92befc0981fe52c24e583928c/restart.PNG)
|
|
|
- The **Stop**-button stops a running debugging session. As long there is no running session this button is disabled (greyed out) ![stop](/uploads/9a5f30421341fa4ff1a2f94437f6d52d/stop.PNG)
|
|
|
- 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. ![submit](/uploads/06b7a61d7a3d6f8fac58bc4ba7a31730/submit.PNG)
|
|
|
|
|
|
Let us use now press the button Start to start a new debugging session!
|
|
|
|
|
|
The ontology debugger first checks if the ontology is consistent/coherent. 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:
|
|
|
![first_two_axioms](/uploads/1e8f5381ed0541131964117598fc6fa9/first_two_axioms.PNG)
|
|
|
|
|
|
##### 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**.
|
|
|
|
|
|
![possible_ontology_repairs](/uploads/ad82aabc72e11f3c36cdf56d33749e25/possible_ontology_repairs.PNG)
|
|
|
|
|
|
Let us use now press the button Start to start a new debugging session. The ontology debugger now recognizes if the ontology is consistent/coherent. Since our Koala ontology is incoherent it states the first query consisting of 2 formulas.
|
|
|
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.
|
|
|
|
|
|
Below the 3 buttons you now will see these two axioms:
|
|
|
- ![axiom1](/uploads/72e8773f48025aa456a9b3720fe4fc69/axiom1.PNG)
|
|
|
- ![axiom2](/uploads/5d8a28bf5208799f8f6019e84029e707/axiom2.PNG)
|
|
|
If only one Possible Ontology Repair has been found then we have identified the faulty axioms that altogethter explain inconsistency/incoherency in the ontology and the debugging session is finished.
|
|
|
|
|
|
Let us ignore these two axioms at first and let us concentrate on the lower part presenting the different possible sets of faulty axioms. **Note** if there are multiple such sets, this means that, given the current information, each one of these sets (on its own) constitutes a possible explanation of the faulty ontology. Each additionally answered query will rule out some of these sets.
|
|
|
![possibly_Faulty](/uploads/fb81708f968681dd211a22b6af8774f4/possibly_Faulty.PNG)
|
|
|
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.
|
|
|
|
|
|
These possible sets of faulty axioms are calculated / updated once the session has been started or the user has given an answer to a query. (At least two) sets of faulty axioms are a necessary prerequisite to compute queries. So the query given above is calculated as a result of the sets of faulty axioms below. Each set of faulty axioms can be determined based on _minimal conflicts sets_ which can be shown in the Ontology Debugger's __Conflicts__ tab. A minimal conflict set is a minimal (or irreducible) inconsistent / incoherent set of axioms in the inconsistent / incoherent ontology. **Note** that the conflict sets can only be calculated using *HS-Tree* and *HS-DAG* as *Diagnosis Engine Type* (selectable in the debuggers preferences).
|
|
|
**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.
|
|
|
|
|
|
The minimal conflict sets can be viewed in the Ontology Debugger's __Conflicts__ view (you can enable it with ```Window->Views->Debugger views->Conflicts```).
|
|
|
|
|
|
**Note** that the conflict sets can only be calculated using *HS-Tree* and *HS-DAG* as *Diagnosis Engine Type* (selectable in the debuggers preferences).
|
|
|
|
|
|
### Step 5 Answer the first query
|
|
|
Continuing with the session from above, the queries section shows us the following question to be answered: ```hasDegree Domain Person``` and ```isHardWorking Domain Person```.
|
|
|
|
|
|
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). Note that the questions may be axioms already stated in the ontology or axioms that are logically entailed from 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 in the right section.
|
|
|
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).
|
|
|
|
|
|
Note that the questions either may be axioms already stated in the ontology or axioms that are logically inferred in our 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. Inferred axioms are highlighted by a yellow background color.
|
|
|
|
|
|
The user has to answer _at least one_ of these quersions question.
|
|
|
|
|
|
If the user thinks a statement in the query is true, she answers by clicking on the ![plus0](/uploads/53e6de21ab2264a301910e4e31cbc7e4/plus0.PNG) icon (__Yes, this statement is true__) next to it.
|
|
|
|
|
|
The user has to answer _at least one_ question. If the user thinks a statement or axiom in the query is true, she answers by clicking on the ![plus0](/uploads/53e6de21ab2264a301910e4e31cbc7e4/plus0.PNG) icon (__Entailed__) next to it on the right. If she believes that the statement is false, she answers by clicking on the ![minus0](/uploads/10c449a582f342be1211599213c6480b/minus0.PNG) icon (__Not Entailed__) to the right of it.
|
|
|
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.
|
|
|
|
|
|
The user can deselect her answer by clicking again on the icon. 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__).
|
|
|
|
|
|
**Important**: in order to proceed the user __has to answer at least one question__ in the current set of 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 gets active. So the user is not forced to answer all questions.
|
|
|
|
|
|
![step1](/uploads/ee64b251b8fde2418eb4e723d3f4ccce/step1.PNG)
|
|
|
![step1](/uploads/b16660d4ac3eaa898adce04a71b752a6/step1.png)
|
|
|
|
|
|
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.
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
Afterwards new Queries and Possible Repair Sets are presented to the user. Both previously given answers are now listed among the __Entailed Testcases__ in the view for Acquired Test Cases in the mid section (see below).
|
|
|
|
|
|
![step2](/uploads/e06df8117bc78a9ebce5b67bf33708cd/step2.PNG)
|
|
|
![step2](/uploads/b7aca8279cd4c9869d96384382aa39a7/step2.png)
|
|
|
|
|
|
### Step 6 Answer all queries until the Debugger gives us a solution
|
|
|
|
|
|
Since the Ontology Debugger has not found a unique solution yet (i.e. there are still multiple possible sets of faulty axioms), the set of faulty axiom sets is updated based on the given query answer after the user presses the Submit-button. This update involves the deletion of faulty axiom sets inconsistent with the given answer and the generation of some new possible faulty axiom sets as a basis for the computation of the next query. If we continue answering the stated questions of the debugger we will finally end up with a unique set of faulty axioms (also known as diagnosis) corresponding to our Acquired Test Cases and Input Ontology.
|
|
|
Since the Ontology Debugger has not found a unique solution yet (i.e. there are still multiple Possible Ontology Repairs), the set of faulty axiom sets is updated based on the given query answer after the user presses the Submit-button. This update involves the deletion of faulty axiom sets inconsistent with the given answer and the generation of some new possible faulty axiom sets as a basis for the computation of the next query. If we continue answering the stated questions of the debugger we will finally end up with one Possible Ontology Repair (also known as diagnosis) corresponding to our Acquired Test Cases and Input Ontology.
|
|
|
|
|
|
**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.
|
|
|
**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/674759cfce31a893f711d81f43b08c41/finalstep.PNG)
|
|
|
![finalstep](/uploads/3264b384e6aaef83d50c77d11d6da902/finalstep.png)
|
|
|
|
|
|
As it can be seen in the image above, 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 up with a Possible Ontology Repair consisting of 3 faulty axioms:
|
|
|
- [x] ```KoalaWithPhD EquivalentTo Koala and (hasDegree value PhD)```
|
|
|
- [x] ```Quokka SubClassOf isHardWorking value true```
|
|
|
|
|
|
and
|
|
|
- [x] ```Koala SubClassOf isHardWorking value false```.
|
|
|
|
|
|
You can reproduce the provided solution by taking a look at the given answers in the **Acquired test cases** view in the mid section in the picture above.
|
|
|
You can reproduce the provided solution either by taking a look at the given answers in the **Acquired test cases** view in the mid section or by opening the **Answer History View** which lists the given answers per querying-answering-iteration of our debugging session (see picture above).
|
|
|
|
|
|
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.
|
|
|
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 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)
|
|
|
![search](/uploads/c9ff4e4a0c61c1ddca456abc399a8c23/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é
|
|
|
|
... | ... | @@ -130,35 +164,35 @@ In the above debugging session the default settings and the *HermiT* reasoner we |
|
|
|
|
|
### Preferences for Fault Localization
|
|
|
|
|
|
![pref1](/uploads/6e6a182e3388b0eff9016d556f551f1f/pref1.PNG)
|
|
|
![pref1](/uploads/37328ed2d3c99259200a8a28e895eb5c/pref1.png)
|
|
|
|
|
|
##### Engine Types
|
|
|
|
|
|
**Diagnosis Engines** are responsible for finding the **Faulty Axioms** sets (or diagnoses). As **Diagnosis Engines** we can choose either between HS-DAG, HS-Tree (default) and Inv-QuickXPlain. The last algorithm computes the faulty axioms (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 cost estimation function, 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 **Faulty Axioms** tab.
|
|
|
**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.
|
|
|
|
|
|
##### Cost Estimation
|
|
|
##### Repair Preference Order
|
|
|
|
|
|
The diagnosis engine HS-DAG and HS-Tree need cost estimation functions for the generation of faulty axiom sets (diagnoses).
|
|
|
The diagnosis engine HS-DAG and HS-Tree require Preference Functions for the generation of Possible Ontology Repairs (diagnoses).
|
|
|
|
|
|
The user can choose between three functions: **EqualCosts** equalizes all diagnoses (no preference), **Cardinality** (default) prefers diagnoses with lower numbers of axioms per diagnosis, and **Syntax** prefers diagnoses with higher probability where the probability of a diagnosis is calculated according to the occurrence of syntactic keywords in the axioms.
|
|
|
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.
|
|
|
|
|
|
##### Diagnoses Calculation
|
|
|
##### Repair Calculation
|
|
|
|
|
|
Next you can choose how many faulty axiom sets you want the debugger to calculate at most (default is 9) before providing the next query. Please note that the higher the number, the lower the overall number of queries might be in a debugging session, but the more computation time might be required between two queries depending on the complexity of the ontology.
|
|
|
Next you can choose how many repairs you want the debugger to calculate at most (default is 9) before providing the next query. Please note that the higher the number, the lower the overall number of queries might be in a debugging session, but the more computation time might be required between two queries depending on the complexity of the ontology.
|
|
|
|
|
|
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.
|
|
|
|
|
|
### Preferences for Query computation
|
|
|
|
|
|
![pref2](/uploads/6e96661f5a0b8d0259168f181e22cab4/pref2.PNG)
|
|
|
![pref2](/uploads/328117a41b994b95cf088fe49e4ecd24/pref2.png)
|
|
|
|
|
|
Query Computation is a 3-stage process ...
|
|
|
|
|
|
#### 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).
|
|
|
Stage 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).
|
|
|
|
|
|
##### 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.
|
|
|
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 repair.
|
|
|
|
|
|
##### Thresholds
|
|
|
Approximation parameters control the quality of the found query w.r.t. the selected measure.
|
... | ... | @@ -176,24 +210,28 @@ Stage 3 tries to make the query easier to understand for the user by simplifying |
|
|
|
|
|
These default preferences were used for this tutorial.
|
|
|
|
|
|
**Conflict Searcher**: _Cardinality_
|
|
|
|
|
|
**Engine Type**: _HS-Tree_
|
|
|
|
|
|
**Cost Estimation**: _Cardinality_
|
|
|
**Preference Function**: Cardinality
|
|
|
|
|
|
**Max. Number of Computed Ontology Repairs per Iteration**: _9_
|
|
|
|
|
|
**Number of Faulty Axiom Sets**: _9_
|
|
|
**also repair incoherency**: _yes_
|
|
|
|
|
|
**also check for incoherency**: _yes_
|
|
|
**Query Quality Measure**: _Entropy_
|
|
|
|
|
|
**enrich query**: _yes_
|
|
|
**Approx. Parameters**:
|
|
|
|
|
|
**Sort Criterion**: _MinCard_
|
|
|
- **Entropy**: _0,05_
|
|
|
|
|
|
**Requirements Measure**: _Entropy_
|
|
|
- **Cardinality Threshold**: _0_ (when active)
|
|
|
|
|
|
**Entropy Threshold**: _0,05_
|
|
|
- **Cautious Parameter**: _0,4_ (when active)
|
|
|
|
|
|
**Cardinality Threshold**:_0_ (when active)
|
|
|
**Criterion**: _MinCard_
|
|
|
|
|
|
**Cautious Parameter**:_0,4_ (when active)
|
|
|
**enrich and optimize query**: _yes_
|
|
|
|
|
|
|