From Protege Wiki
Using DL reasoners in Protege-OWL
This wiki page is a brief users guide for using reasoners in Protege-OWL. It assumes a basic working knowledge of Protege-OWL. Please refer first to the Protege-OWL Tutorial section "4.9 Using a Reasoner". This page explains some additions (e.g. the direct reasoner) that occurred after the publication of the Protege-OWL tutorial.
Using the DIG Reasoner
The DIG interface is a standard interface/protocol that was introduced to provide a common interface to DL reasoners. In this way, applications, such as Protege-OWL, can access several reasoners by using a common interface. The current version implemented by several DIG compliant version is DIG 1.1, which has a number of know flaws (e.g. very limited support for datatypes, etc.). See this paper for more details. There is a roadmap for the 2.0 version of DIG that would address these limitations, however it is not clear when this version will become available.
Getting the DIG-compliant reasoner
First, you need to make sure that you have downloaded a DIG compliant reasoner, such as:
- Pellet - open source, implemented in Java
- Fact++ - open source, implemented in C++
- RacerPro - commercial
- KAON2 - commercial, free of charge for universities and for noncommecial academic usage
Second step is to install the reasoner and start the DIG HTTP service. Please read the documentation of the reasoner to see how to start the DIG service.
Configure the DIG reasoner URL
Then you need to configure the port on which the reasoner DIG service is running. The most common port used by the reasoner is 8080, and that is also the default configuration for Protege-OWL. If the reasoner runs on this port (which you can usually figure out from the console window in which the reasoner is running), then you can skip this step. If however, the reasoner runs on a different port (e.g. Pellet runs by default on 8081), then you need to do the following steps:
Go to the OWL Menu -> Preferences -> General Tab and in the Reasoner URL text field adjust the URL and port on which the reasoner is running.
For example, if Pellet would run on localhost and port 8081, then the reasoner URL should be: http://localhost:8081.
Classifying the ontology with the DIG reasoner
Now you are ready to test the reasoner connection and to classify the ontology.
First, make sure that "DIG Reasoner" is selected in the Reasoning menu (the default selection when you install Protege). The Reasoning menu allows you to select which is the current reasoner that should be used when the users classifies the ontology, checks the consistency, computes the inferred types, etc. from the user interface.
To classify the ontology, select "Classify taxonomy" in the Reasoning menu. You should see a panel coming up that has a title: Connected to Pellet x.y.z (DIG)
If instead of that, you see an almost empty panel with a red text: Reasoner Error: Connection refused, it means that you have not configured correctly the Reasoner URL in the OWL Preferences or the reasoner is not running.
Using the Direct Reasoner
Direct reasoner means that the reasoner is invoked from Protege by calling directly the reasoner API, rather than through DIG, which has several limitations, as mentioned before. The advantage of using the direct reasoner over the DIG reasoner is that the entire ontology can be "sent" to the reasoner without suffering any of the limitations that DIG has. A possible disadvantage of the direct reasoner is that Protege-OWL and the reasoner share the same memory space. So, you will most likely need to give Protege more memory if you are using the direct reasoner. See instructions for increasing the heap size for Protege here.
The direct reasoners are shown in the Reasoning menu. After the Protege installation, you will see in the Reasoning menu, only one direct reasoner, Pellet x.y.z (direct). New direct reasoners can be easily added by implementing a reasoner plugin.
To use a direct reasoner, please select it in the Reasoning menu. For example, the Pellet 1.5.1 direct reasoner is selected in the image below:
Classifying the ontology with the Direct Reasoner
To classify the ontology with the direct reasoner, select the direct reasoner in the Reasoning menu and select Classify Taxonomy. You should see a panel with the title made of the reasoner name and (direct). E.g. for Pellet: Pellet 1.5.1 (direct):
Configuring the Direct Reasoner
Configuring the display of direct vs. all inferred types in the user interface
When computing the inferred types of the individuals by selecting the in menu Reasoning -> Compute inferred types, the default behavior is that all inferred types of an individual will be shown in the UI. This means that both the direct and indirect inferred types will be shown.
To explain better the difference between the direct and indirect inferred types, please consider the following example:
Class_A has been inferred to have a subclass
Class_B. It was also inferred that
Individual_1 has type
Class_A | |___ Class_B ------- Individual_1
So, the reasoner computed that
Individual_1 has direct type
Class_B, but it also has an indirect type
Class_B is a subclass of
Class_A. All the inferred types of
Individual_1 will be
As we have mentioned, the default behavior of the Protege-OWL UI is to display all inferred types for an individual. (So, for
Individual_1 it will show
To change this behavior, and show in the UI only the direct inferred types, you will have to add a line in the protege.properties file:
This can be done also in the user interface, by going to the File menu -> Preferences -> Property Files -> protege.properties and adding a row entry:
After making this setting, the next time you will compute the inferred types, the number of inferred types shown in the classes panel and the inferred individuals shown in the Individuals list will change to reflect the new setting (you will see fewer of them than with the default setting).
The user interface of the Individuals Tab shows in the classes panel next to a class name two numbers:
In the image above, Class_2 is displayed as
Class_2 (0 / 1) which means that Class_2 had 0 asserted types and 1 inferred type.