ProtegeReasonerPlugin
Implementing a Protege-OWL Reasoner Plugin
A new plugin type, the Reasoner Plugin, is available in Protege starting with version 3.4 beta 120 (from 2007/11/17). This page describes how you can implement your own reasoner plugin that will allow you to integrate another reasoner into Protege.
Contents
Introduction
Starting with Protege 3.4 beta 120 (from 2007/11/17), the reasoner plugin will allow you to integrate other reasoners into Protege. The plugin reasoner will be accessible through the Protege user interface in the Reasoning menu. For example, you will be able to select in the Reasoning menu, your own reasoner and then all the reasoner related actions (e.g. "Classify taxonomy", "Compute inferred types" , etc.) will be run using your reasoner.
In the same way, the reasoner will be accessible through the reasoning API that is documented here.
All the reasoners that are distributed with the Protege installation and that are available in the Reasoning menu are also reasoner plugins.
Implement the ProtegeReasoner interface
To create a new reasoner plugin, you will have to implement the ProtegeReasoner interface.
To make your life easier, you can start by subclassing the AbstractProtegeReasoner that already takes care of the synchronization between the OWL model and the reasoner in case that the OWL model has changed. It uses listeners for OWL model events (e.g. class deleted, created, etc.) and informs the reasoner that at the next request a full synchronization is necessary. It does not support currently an incremental approach to synchronization.
TIP: In case you implement a DIG reasoner, you may subclass the DefaultProtegeDIGReasoner, or if you want to use a Jena reasoner, you can subclass the DefaultJenaReasoner available in the protege-pellet.jar from the edu.stanford.smi.protegex.owl.inference.pellet plugin folder. (Yes, we should move the Jena reasoner to its own jar..)
You should also implement the method:
public static String getReasonerName()
and return a nice name for your reasoner that will be shown in the Reasoning menu.
It is also recommended that you implement the method:
public static isSuitable(Project prj, Collection errors)
in case your reasoner cannot handle certain types of Protege-OWL models. For example if your reasoner does not work with OWL databases, then isSuitable should return false for this case. Then, the plugin will not show up in the Reasoning menu for OWL database projects.
The trick to make it work
Due to some limitation in the current implementation of the plugin architecure of Protege, you will have to make a trick to make Protege recognize your plugin: You will have to create an empty project plugin and package it in the same jar with the reasoner plugin implementation. (We'll try to fix this in the future).
The implementation of the Project plugin can look like:
import edu.stanford.smi.protege.plugin.ProjectPluginAdapter;
public class EmptyProjectPlugin extends ProjectPluginAdapter {
}
The manifest file
In the manifest file containing your implementation of a reasoner plugin, please include the following entry, so that Protege can recognize your plugin:
Name: myPackage.MyReasonerPlugin.class ReasonerPlugin: True Name: myPackage.EmptyProjectPlugin.class Project-Plugin: True
Replace the myPackage.MyReasonerPlugin with the full Java path to the class that implements the ProtegeReasoner interface. The same for the project plugin.
TIP: In case this is the last line in your manifest file, then add an extra empty line.
Other tips
The interface methods of ProtegeReasoner that you have to implement are well documented and it should be clear what to do.
It is also a good idea to look at the existing reasoner plugin implementations from the Protege SVN repository:
