Home
DIP is a DLQueryTab-style plugin for the Protégé Desktop Ontology Editor (version 5.0 and higher) allowing users to specify which SubClass axioms in their ontologies should hold "in general" but permit exceptions. For example: Student SubClassOf not (pays some Tax) does not permit exceptions like EmployedStudent SubClassOf Student and (pays some Tax) because EmployedStudent would be unsatisfiable. However, in DIP one is able to "flag" the former axiom to be defeasible (susceptible to overruling).
DIP is then able to provide reasoning services that derive sensible conclusions with these statements. In particular, DIP allows the user to:
-
Toggle SubClass axioms in the ontology to be treated as defeasible.
-
Identify class expressions violating defeasible SubClass axioms (i.e. the exceptions).
-
Find all named SuperClasses of a user-specified class expression.
-
Find all instances of a user-specified class expression.
-
View all defeasible SubClass axioms separately from the rest of the ontology.
The plugin can be enabled in Protégé via the Window->Tabs menu item. The component views of the plugin are also accessible via the Window->Views->DIP views menu item.
Option 1: (Manual method)
Step 1. Click on the annotations button for the selected SubClass axiom in Protégé.
Step 2. Click on the (+) button to add an annotation.
Step 3. If there is an existing "defeasible" annotation property with IRI "http://cair.za.net/defeasible", skip to Step 5. If not, create it.
Step 4. Ensure that the created property has the same settings as pictured below by clicking on "New entity options...".
Step 5. Set the type of the defeasible annotation property to "xsd:boolean" and the value to "true".
Step 6. Click OK to add this annotation to the selected SubClass axiom. The axiom will now be considered as defeasible by the DIP Plugin.
Step 7. Once your ontology contains the defeasible annotation property, you can repeat Steps 1, 2, 5 and 6 for each axiom that you would like to make defeasible.
Note: to make an axiom non-defeasible again, click on the (x) button to remove its defeasible annotation as shown below
Option 2: (Installing an extension to Protégé's editor plugin)
Step 1. If Protégé is open, close it.
Step 2. Replace protege-editor-owl.jar in the bundles/ directory of your Protégé Desktop installation with the downloaded file. Backup the original protege-editor-owl.jar so you can revert back to it if the downloaded file does not function correctly.
Step 3. Fire up Protégé again. If the plugin is correctly recognised you will see an additional button labeled (d) on each SubClass axiom in Protégé. Clicking this button will toggle the defeasibility of the axiom (it provides an automated way to add/remove the annotation described in Option 1 of this guide).
The plugin can be enabled in Protégé via the Window->Tabs menu item. The component views of the plugin are also accessible via the Window->Views->DIP views menu item. The interface should look something like the image below:
The different components of the interface are described below:
Query (class expression): in this textbox you can type in a class expression whose named SuperClasses and instances you would like to compute. Autocompletion is also provided using the TAB key. Select a reasoning algorithm from the dropdown box. There are four to choose from and the default is "Rational Closure" which is the most cautious reasoning paradigm in the list. "Basic Relevant Closure" is bolder in deriving conclusions, and "Minimal Relevant Closure" is even bolder. "Lexicographic Closure" is bolder than "Rational Closure" but is not directly comparable to the other algorithms in terms of its caution/boldness when deriving conclusions.
Once an expression is specified and a reasoning algorithm is selected, click on the "Execute" button to compute the results:
Exceptions: the Exceptions box displays all the exceptions it finds in the ontology. That is, it identifies the left-hand-side class expressions of defeasible axioms in the ontology, for which there is evidence of exceptions. An exception can be classified into different levels. This is because exceptions themselves could also have exceptions (i.e. "exceptions-to-exceptions"). Therefore, the higher the level, the longer this "exception-to-exception" chain is for the classes displayed in this level. Some exceptions cannot have any instances in the ontology, and are classified under "Uninstantiable". These exceptions are analogous to unsatisfiable classes in ontologies without defeasible axioms.
Super Classes & Instances: this section in most cases will display three types of information. The "Strict" and "Typical" superclasses, as well as the "Instances" for the given class expression. "Strict" superclasses are those that follow purely from the non-defeasible axioms in the ontology, and "Typical" superclasses are those that follow from the entire ontology. Instances are potentially of two types - "Plausible" and "Definite". Plausible instances are those for which there is evidence in the ontology (albeit potentially weaker evidence, according to DIP's algorithms). Definite instances are those for which there is particularly strong evidence in the ontology, according to DIP's algorithms. Definite instances are the default type of instances and are thus are found under "Instances". Plausible instances fall under the explicitly labeled "Plausible Instances".
Refreshing Exceptions List: DIP should automatically take into account real-time changes in the ontology to update the Exceptions list. However, if the Exceptions list seems out of sync with the ontology, the user can click on the Refresh button in the Exceptions pane to tell DIP explicitly to recompute the list.
Q: Why doesn't DIP compute ALL the superclasses for my given class expression?
A: DIP will compute all named (i.e. not anonymous) superclasses for the given class expression. If you would like certain anonymous superclasses to be recognized in the reasoning results, give them a name by introducing an equivalence class axiom into the ontology. For example, if the ontology is about university students, and the query class expression is Student and employedBy some Company, then one might expect the typical superclass: pays some TaxFee. However, DIP will not list this class. TIP: add an equivalence class axiom to the ontology e.g. TaxPayer EquivalentTo pays some TaxFee. DIP will then be able to list TaxPayer as a typical superclass of Student and employedBy some Company.
Q: Why does the colour of some classes in the ontology become red after starting the reasoner?
A: We strongly recommend that you do NOT start the selected reasoner (from the Reasoner menu in Protégé) whenever you want to use DIP. As long as one of the reasoners in this menu is selected, all defeasible reasoning with your ontology is done inside the DIP tab. DIP will NOT display inferences elsewhere in Protégé. All inferences made outside of the DIP tab are made solely by the standard non-defeasible reasoner selected in the Reasoner menu of Protégé. I.e., these inferences are made by ignoring the defeasible annotations in the ontology.
Q: Why can't DIP compute the subclasses for my given class expression?
A: The task of computing all named subclasses is theoretically more complex than computing the superclasses using DIPs algorithms. There are some planned optimisations for this task and this feature will hopefully be included in the near future.
Q: Why can't I infer object property assertions from my ontology using DIP?
A: Coming soon!