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)

How do I create a SWRL Rule Engine Bridge?    (6PK)

In general, an implementation of a rule engine bridge is supplied with an OWLModel object containing an OWL ontology (which presumably contains SWRL rules). A factory class called BridgeFactory is provided to create instances of a bridge. For example, a bridge can be created using this factory as follows:    (6U8)


OWLModel owlModel = ... // Create using normal Protege-OWL mechanisms.

SWRLRuleEngineBridge bridge = BridgeFactory.createBridge(owlModel);
    (8HJ)

If no bridges are registered when this method is called a NoRegisteredBridgesException will be thrown. This factory also provides a method called getRegisteredBridgeNames that lists the names of all the currently registered bridges.    (8XY)

The create an instance of a specific bridge, say, for example, one named "SWRLJessBridge", one can do the following:    (8WQ)


OWLModel owlModel = ... // Create using normal Protege-OWL mechanisms.

SWRLRuleEngineBridge bridge = BridgeFactory.createBridge("SWRLJessBridge", owlModel);
    (8HJ)

A SWRLRuleEngineBridgeException will be thrown if any errors occur during bridge creation.    (8WS)

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);

SWRLRuleEngineBridge bridge = BridgeFactory.createBridge(owlModelA);

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

bridge.infer();

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

bridge.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 SWRLRuleEngineBridge interface described the methods that a bridge must implement. A base implementation class called AbstractSWRLRuleEngineBridge provides a set of core functionality that most bridges will require. Concrete subclasses of this class can provide implementations for particular rule engines. A developer can subclass this class and then implement methods 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.    (8WO)

Internally, the bridge uses bridge classes to store generic representations of all rules and relevant OWL knowledge. This representation is used to bridge between SWRL rules and OWL knowledge and the representation used by the target rule engine. SWRL rules and OWL classes, properties, individuals, and axioms are represented using these objects; 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 an OWL class.    (6UH)

A 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. Each method must take an object of the appropriate type and produce an internal representation of that object and other objects that it refers to. A class defining these methods should extend the AbstractSWRLRuleEngineBridge class and implement the SWRLRuleEngineBridge interface.    (A56)

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

The methods outlined above provide all the functionality necessary for a bridge to execute rules for a particular rule engine. In addition, an implementor must define a method to represent information generated as a result of built-in parameter binding. 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)

To enable other SWRLTab components to create instances of a bridge, an implementor should register the bridge with the SWRLTab's BridgeFactory. This class provides a registerBridge call that takes the name of the bridge being registered and an instance of class that implements the BridgeFactory.BridgeCreator interface. This interface defines a single method called create that takes an OWL model as a parameter. When invoked, this method should create a concrete instance of the appropriate rule engine bridge and pass it the supplied OWL model. A SWRLRuleEngineBridgeException can be thrown if any errors occur during bridge creation.    (8WS)

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. This knowledge will be of the form of class membership and property assertions for existing individuals. These assertions can be passed to the bridge using the following two methods:    (6P4)

These methods 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 arithmethic, string, and date maniplations 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., swrlb:greaterThan) and a List containing BuiltInArgument objects. The main possible types of argument objects are ClassArgument, PropertyArgument, IndividualArgument, and DatatypeValueArgument. 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 is information created by built-in argument binding passed to the bridge?    (8LX)

Built-ins may bind values to their arguments. These bound values are automatically passed to a rule engine implementation by the bridge using the following method:    (8LY)

This method does not return any arguments and throws a BuiltInException. 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. 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.    (8MJ)

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.PluginRegistrationInfo. 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)

What are the current limitations of the SWRL Rule Engine Bridge?    (6QL)

A significant limitation of the current bridge is that it does not represent all OWL axioms when transferring knowledge from an OWL ontology to the bridge. The exceptions are the basic class and property axioms such as, for example, rdfs:subClassOf and rdfs:subPropertyOf, and the axioms owl:sameAs, owl:differentFrom, owl:allDifferent, owl:equivalentClass, and owl:equivalentProperty. As a result, the inferencing mechanisms do not know about the remaining OWL axioms so all possible inferences may not be made. Also, conflicts can potentially arise in an OWL ontology between information asserted by a rule engine and the OWL axioms that were not considered. For example, a hasUncle property may be asserted for an individual as a result of firing a SWRL rule, but a class level OWL axiom may forbid this property from belonging to that individual. As present, these conflicts are not detected automatically, and resolving the conflict - which is essentially between a SWRL rule and one or more OWL axioms and has nothing to do with a particular rule engine - is left to the user. Conflicts can be detected by running an OWL reasoner on the ontology that has been populated by inferred knowledge.    (6PD)

An additional issue is that a conflict-free execution of the classifier may also infer new knowledge that may in turn produce information that may benefit from further SWRL inference, a process that may require several iterations before no new knowledge is generated.    (6PF)

The Pellet reasoner considers all the relevant OWL axioms when performing inference with SWRL rules - but will not work with the SWRLTab's built-in libraries.    (AHL)