The SWRL Built-in Bridge is a component of the SWRLTab that provides a mechanism to define Java implementations of SWRL built-ins. The bridge provides mechanisms to dynamically load these implementations and to invoke them from a rule engine. (6RN)
SWRL Built-Ins (6RO)
SWRL provides a very powerful extension mechanism that allows user-defined methods to be used in rules. These methods are called built-ins and are predicates that accept one or more arguments. Built-ins are analogous to functions in production rule systems. A number of core built-ins are defined in the SWRL specification. This core set includes basic mathematical operators and built-ins for string and date manipulations. These built-ins can be used directly in SWRL rules. (6RP)
An example use of a core SWRL mathematical built-in called greaterThanOrEqual to indicate that a person with an age of 18 or greater is an adult is: (6RQ)
Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThanOrEqual(?age, 18) -> Adult(?p) (6RR)
When executed, this rule would classify individuals of class Person with an hasAge property value of 18 or greater as members of the class Adult. The swrlb qualifier before the built-in name indicates the alias of the namespace containing the built-in definition. In this case, it indicates that the built-in comes from the core SWRL built-in ontology. (6RS)
Users can also define their own built-in libraries. Example libraries could include built-ins for currency conversion, and statistical, temporal or spatial operations. Again, these user-defined built-ins can be used directly in SWRL rules. (6RT)
An OWL definition for a SWRL built-in is provided by the class Builtin, which is contained in the file swrl.owl. This file has the namespace http://www.w3.org/2003/11/swrl. A copy of this file can be found at http://www.daml.org/rules/proposal/swrl.owl and also in the standard Protege-OWL distribution. (6RU)
Three properties are added to the Builtin class in the file swrlb.owl. This file has the namespace http://www.w3.org/2003/11/swrlb; a copy of this file can also be found at http://www.daml.org/rules/proposal/swrlb.owl. These properties can be used to describe the number of arguments a particular built-in is expecting. These arguments are: args, minArgs, and maxArgs. The args property can be used if the built-in is expecting a set number of arguments; minArgs, and maxArgs are used when a variable number of arguments are expected. These argument properties can be used, for example, to perform argument checking on built-ins in an editor. The built-in definition does not, however, specify the types of the arguments that it is expecting. This checking is left to the built-in implementation. (738)
A new user-defined built-in is described in OWL as an instance of the Builtin class. The individual name is set to the name of the built-in. In general, a set of related built-ins are defined in a single OWL file. For example, a user-defined set of temporal built-ins could be defined in a file called temporal.owl, which must reference swrlb.owl. A specific built-in, such as, say, before, would then be defined in this file as an individual named before, which would be an instance of the class Builtin. The argument properties of each built-in can be used to specify the number arguments it is expecting. (6RW)
To use these user-defined built-ins in SWRL rules, the file containing them must be imported. Sets of built-ins are usually given a user-friendly alias when they are imported. For example, the built-ins defined in temporal.owl could be given the alias temporal that can be used to qualify their use in SWRL rules. (6SO)
Defining Java Built-in Implementations (6SP)
The built-in bridge provides a mechanism for defining and dynamically loading built-in implementation written in Java. Users wishing to provide implementations for a library of built-in methods must first define a Java class that contains definitions for all the built-ins in the library. The bridge is expecting this built-in implementation class to be called SWRLBuiltInMethodsImpl. This class must implement the interface SWRLBuiltInMethods. This interface acts as a typing or structuring mechanism - it does not define any methods itself. (6RX)
The package name of the SWRLBuiltInMethods class should be the namespace qualifier of the built-ins appended to the Java package name edu.stanford.smi.protegex.owl.swrl.bridge.builtins. For example, the standard SWRL built-in swrlb:greaterThan should be defined as a method called greaterThan in the class SWRLBuiltInMethodsImpl, which should be located in the package edu.stanford.smi.protegex.owl.swrl.bridge.builtins.swrlb. (6RY)
Each implementation of a specific built-in in the SWRLBuiltInMethodsImpl class should have a signature of the form: (6RZ)
public boolean <builtInName>(List arguments) throws BuiltInException (6SQ)
The single arguments parameter is a list that should contains one or more Argument objects. The three possible types of argument objects expected by the bridge are IndividualInfo, LiteralInfo and VariableInfo. The LiteralInfo and IndividualInfo objects are used to pass information to built-ins: the LiteralInfo object contains OWL literals, such as integers or strings, and the IndividualInfo object specifies the name of an OWL individual. The VariableInfo class can be used by a built-in to assign a value to a variable. This value can be either an OWL individual name or a literal. (6S1)
The three parameter classes have constructors to create them from their matching types. LiteralInfo objects can be constructed from RDFFSLiteral objects or from basic Java types. Accessor methods are provided to get these values. IndividualInfo and VariableInfo classes can be constructed from Java instances of OWLIndividual and SWRLVariable classes, respectively. Both of these classes also have a getName call to retrieve the variable or individual name. (6S2)
For example, the SWRL rule atom swrlb:add(?x, 2, 3) could use the core SWRL built-in add method to add two integer literals. When this built-in is invoked by a rule engine, the first argument should be an instance of the VariableInfo class with its name set to x; the second and third arguments should be instances of the LiteralInfo class that hold their respective values. (6S3)
Each built-in class must declare the exception BuiltInException, which is defined in the exceptions subpackage of the standard bridge package. This abstract class has concrete subclasses for the four possible exceptions that can be thrown by a built-in implementation: (6T9)