-
Notifications
You must be signed in to change notification settings - Fork 41
SWRLRuleEngineBridge
The SWRL Rule Engine Bridge is a subcomponent of the SWRLAPI that provides a bridge between an OWL model with SWRL rules and a rule engine. Its goal is to provide the infrastructure necessary to incorporate rule engines into the SWRLAPI to execute SWRL rules.
The bridge provides mechanisms to:
- Import SWRL rules and relevant OWL classes, individuals and properties from an OWL model and write that knowledge to a rule engine
- Allow the rule engine to perform inference and to assert its new knowledge back to the bridge
- Insert that asserted knowledge into an OWL model
The bridge also provides mechanisms to dynamically add graphical user interfaces allow interaction between a particular rule engine implementation and a user.
A subcomponent of the bridge called the SWRL Built-in Bridge provides mechanisms to dynamically load Java-defined implementations for SWRL built-ins. This component is described here.
This FAQ assumes that the reader has some familiarity with the OWLAPI API and, of course, SWRL.
The SWRL Rule Engine Bridge is part of the SWRLAPI. The API for this factory is provided by the SWRLRuleEngineBridge interface.
Once a bridge has been created, it can be used to execute SWRL rules and to pass any inferred information back to the OWL model. The SWRLRuleEngine interface provides the following methods to control this process:
- reset() - Clear all knowledge from the the rule engine.
- importAssertedOWLAxioms() - Import all SWRL rules and relevant OWL knowledge from the OWL model into the bridge. All existing bridge rules and knowledge will first be cleared and the associated rule engine will be reset.
- run() - Invoke the rule engine.
- exportInferredOWLAxioms() - Transfer any information asserted by a rule engine to the OWL model.
- infer() - Load rules and knowledge from OWL into bridge, send them to a rule engine, run the rule engine, and write any inferred knowledge back to OWL. Basically a wrapper around the four preceding methods.
None of these methods has a return value and all methods throw a SWRLRuleEngineException.
The public interface to a SWRL rule engine is designed to be the same irrespective of the particular rule engine implementation. Users of a SWRL rule engine may not necessarily know or care about the underlying rule engine being used.
The TargetSWRLRuleEngine interface defines the methods that a target rule engine must implement. A developer must implement this interface and provide methods to to represent SWRL rules, and OWL classes, properties, individuals, and axioms within a particular rule engine. They must also provide a method to perform inference using that knowledge. Additionally, an implementation must be able to handle arguments bound by built-ins.
Internally, a bridge uses OWLAPI classes to represent rules and relevant OWL knowledge. SWRL rules and OWL classes, properties, individuals, and axioms are represented using these classes; components of SWRL rules, such as atoms, literals and variables, are also represented using these objects. An implementation for a particular rule engine must be able to take these objects and represent them in the rule engine's native format.
The following methods should be implemented to perform this task. As mentioned, a class defining these methods should implement the TargetSWRLRuleEngine interface.
- initialize(SWRLRuleEngineBridge bridge) - Initialize the target engine and give it a reference to its bridge.
- defineOWLAxiom(OWLAxiom axiom) - Take an OWLAxiom object and use it to produce an internal representation in the target rule system. A SWRL rule is a type of OWL axiom.
- defineBuiltInArgumentBinding(String ruleName, String builtInName, int builtInIndex, List<BuiltInArgument> arguments) - Define a rule engine representation of one set of the arguments generated by a built-in that binds one or more of its arguments.
- runRuleEngine() - Run the rule engine.
- resetRuleEngine() - Reset the rule engine.
None of these methods has a return value and all methods throw a TargetSWRLRuleEngineException.
The methods outlined above provide all the functionality necessary for a bridge to execute rules for a particular rule engine. The representation of SWRL rules and OWL axioms is completely at the discretion of the target rule engine implementation - as are any inference mechanisms employed by it.
During inference, target rule engines may invoke built-ins through the bridge and will thus have to deal with arguments that may bound by those built-ins. This mechanism is described below.
An implementation of a SWRL rule engine using the Drools rule engine is supplied here.
An implementor may also wish to provide GUI-based interaction with their bridge. Mechanisms to allow provide this interaction within the Protege-OWL GUI are also described below.
As inference is carried out by a rule engine, new knowledge will be generated. These assertions can be passed to the bridge using the following method:
- inferOWLAxiom(OWLAxiom owlAxiom)
This method can throw the exception SWRLRuleEngineBridgeException.
SWRL built-ins are predicates that accept several arguments. A number of standard built-ins for common arithmetic, string, and date manipulations are defined here but SWRL also allows user-defined built-ins. There is no way for a rule engine to anticipate all possible built-ins so the bridge provides a mechanism for rule engines to access Java-implementations of built-ins. If the bridge has an implementation for the particular built-in, a rule engine can then invoke this built-ins while it is performing inference. Of course, the bridge also cannot anticipate all possible SWRL built-ins - hence, it supports a dynamic loading mechanism to find implementations of built-ins at run time.
Assuming the bridge has an implementation for a particular built-in, a rule engine can invoke that built-in using the invokeSWRLBuiltIn method provided by the SWRLRuleEngineBridge inrerface. This method takes the name of the invoking SWRL rule, the short name of the built-in (e.g., swrlb:greaterThan) and a List containing SWRLBuiltInArgument objects.
The main possible types of argument objects are SWRLBuiltInClassArgument, SWRLBuiltInObjectPropertyArgument, SWRLBuiltInDataPropertyArgument, SWRLIndividualArgument, and SWRLLiteralArgument. If an invalid built-in name is supplied to this method, it throws an InvalidBuiltInNameException; if the built-in can not be found, an UnresolvedBuiltInException is thrown.
Each built-in method implementation should check that the correct number of arguments are passed to it and that the arguments are of the correct type. If an incorrect number of arguments is passed to a built-in or the arguments supplied are of the wrong type, it throws InvalidBuiltInArgumentNumberException or InvalidBuiltInArgumentException, respectively.
The overhead of invoking a built-in from a rule engine may be significant, particularly if the rule engine is not Java based. Hence, a developer may also decide to implement some built-ins natively in the target rule engine. Simple arithmetic built-ins, for example, will probably be easy and convenient to implement natively.
Built-ins may bind values to their arguments. These bound values are automatically passed to a rule engine implementation by the bridge. For every unique set of bindings, the following method in the target rule engine is called:
- defineBuiltInArgumentBinding(String ruleName, String builtInName, int builtInIndex, List<BuiltInArgument> arguments)
This method does not return any arguments and can throw a TargetSWRLRuleEngineException if an error occurs. The argument list contain all the arguments of a built-in that generated a binding - not just the bound ones - and all must be represented. This method must take the argument objects and generate the appropriate native rule engine pattern representation for those objects so that they can be used for further inference.
It is important to note that an implementation must ensure that these bound values are available within the same rule.
For example, assume that we have the following two built-ins in a rule body:
swrlb:add(?r, 2, 4) ^ swrlb:equals(?r, 6)
If variable r is unbound when the swrlb:add built-in is invoked than it must be bound to the result of the built-in operation and then made available as a bound argument to the swrlb:equals built-in.
Some built-ins can bind multiple value to a single argument when they are invoked, or may bind more than one argument. A target rule engine implementation must be able to handle all of these cases.
Yes - there is a Drools bridge. It is described here.
Yes. A mechanism is provided to allow developers to access real estate on the SWRLTab, which allows a window for other plugins to coexist with the SWRL Editor. A class called the BridgePluginManager is provided to register these plugins with the SWRLTab.
The registration information provided by the plugin is defined by the class BridgePluginManager.PluginRegistration. The plugin must provide a name for the plugin, some tool tip text, an activation icon for display in the SWRL Editor, and a class implementing the interface SWRLPluginGUIAdapter. This adapter class is responsible for supplying the plugin window to display under the SWRL Editor. It must define the methods createPluginGUI and getPluginGUI. The createPluginGUI method is called once when the plugin is registered and is expecting a Java Swing component that is a subclass of a Java Swing Container class. The getPluginGUI may be called repeatedly after registration and should return the Container instance created on initialization.
Once registered, an activation icon will be displayed for each plugin at the top right of the SWRL rules table in the SWRL Editor. When clicked the plugin window created by the SWRLPluginGUIAapter will appear below the editor in the SWRLTab. Plugin developers have full control of the area inside this window. Both the SWRL Drools Tab and the SQWRL Query Tab use this plugin mechanism.