The documentation on this page applies to the APIs in the Protege 3.4.8 release. In 3.5, the APIs described here changed substantially. The documentation has not yet been updated to reflect these changes.    (CHK)

What is the SWRL Rule Engine Bridge?    (6OF)

The SWRL Rule Engine Bridge is a subcomponent of the SWRLTab 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 Protege-OWL to execute SWRL rules.    (6OG)

The bridge provides mechanisms to:    (6OH)

The bridge also provides mechanisms to dynamically add graphical user interfaces to the SWRLTab to allow interaction between a particular rule engine implementation and a user. This mechanism is described here.    (7RK)

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.    (6ON)

This FAQ assumes that the reader has some familiarity with the Protege-OWL API and, of course, SWRL.    (6OO)

Where is the SWRL Rule Engine Bridge located?    (6OP)

The SWRL Rule Engine Bridge is part of (and distributed with) Protege-OWL. The API for this factory is provided by the SWRLRuleEngineBridge interface.    (6UG)

Can more than one bridge exist in a single process?    (8XW)

Yes. Any number of bridges may be instantiated in a single process (of the same or different types). However, if more than one bridge is attached to the same OWL model, inconsistencies may occur if they both try to modify the model. In general, more than one bridge should not be attached to a single model if bridge-initiated updates are made to the model.    (8XX)

How do I interact with the SWRL Rule Engine Bridge?    (6PM)

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:    (6UF)

None of these methods has a return value and all methods throw SWRLRuleEngineException.    (6UJ)

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.    (6OS)

Can I run a subset of the rules in an ontology with the bridge?    (98G)

Not directly. The bridge tries execute all the rules in an ontology. However, it is possible to partition rules into different ontologies and to use the SWRLFactory rule replacement mechanism to swap the set of rules in an ontology and to then execute those new rules.    (98H)


OWLModel owlModelCore = ... // Core ontology with no SWRL rules
OWLModel owlModelRuleSet1 = ... // Ontology containing a set of SWRL rules
OWLModel owlModelRuleSet2 = ... // Ontology containing another set of SWRL rules

SWRLFactory factory = new SWRLFactory(owlModelCore);

SWRLRuleEngine ruleEngine = SWRLRuleEngineFactory.create(owlModelA);

factory.copyImps(owlModelRuleSet1); // Copy rules into core ontology

ruleEngine.infer();

factory.replaceImps(owlModelRuleSet2); // Replace existing rules in core ontology with new rules

ruleEngine.infer();
    (98J)

An ontology must import all the OWL entities referred to by the rules that are copied into it and must also use the same prefix for those entities.    (98I)

How do I specialize the bridge for a particular rule engine?    (6PW)

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.    (BLJ)

Internally, a bridge uses OWLAPI-like 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. For example, the OWLClass class is used to represent information about all OWL axioms. A implementation for a particular rule engine must be able to take these objects and represent them in the rule engine's native format.    (BLK)

The following methods should be implemented to perform this task. As mentioned, a class defining these methods should implement the TargetSWRLRuleEngine interface.    (A56)

None of these methods has a return value and all methods throw TargetSWRLRuleEngineException.    (6UI)

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.    (BKP)

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.    (8LW)

An implementation class for the Jess rule engine is supplied with the standard Protege-OWL distribution (see here).    (8WN)

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.    (6QA)

How does a rule engine pass inferred knowledge back to the bridge?    (6QB)

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:    (6P4)

This method can throw the exception SWRLRuleEngineBridgeException.    (6VK)

How does a rule engine deal with SWRL built-ins?    (6QF)

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.    (6P6)

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 bridge. This method takes the name of the invoking SWRL rule, the fully qualified name of the built-in (e.g., http://www.w3.org/2003/11/swrlb#greaterThan) and a List containing BuiltInArgument objects. The main possible types of argument objects are ClassArgument, PropertyArgument, IndividualArgument, and DataValueArgument. If an invalid built-in name is supplied to this method, it throws InvalidBuiltInNameException; if the built-in can not be found, UnresolvedBuiltInException is thrown.    (6P7)

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.    (6P8)

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.    (6QG)

As outlined here, the invokeSWRLBuiltIn method is thread safe so parallel invocations from a rule engine will not cause undesired behaviour.    (8DN)

How are the results of built-in argument binding passed to a rule engine?    (8LX)

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:    (8LY)

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.    (BKR)

It is important to note that an implementation must ensure that these bound values are available within the same rule.    (BKS)

For example, assume that we have the following two built-ins in a rule body:    (BKT)

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.    (BKV)

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.    (BKW)

Are there any example bridges?    (6QH)

Yes - there is a Jess bridge. It is described here.    (6UL)

Can I display a GUI within the SWRLTab to interact with my own components?    (6QJ)

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.    (8JG)

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.    (8JI)

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 SWRLJessTab and the SQWRLQueryTab use this plugin mechanism.    (8A3)