SWRL is a semantic web rule language that combines OWL ontologies with Horn Logic rules of the RuleML family of rule languages. Being supported by Protégé as well as by popular rule engines and ontology reasoners, such as Jess, Drools and Pellet, SWRL has become a very popular choice for developing rule-based applications on top of ontologies. However, being doubtful whether SWRL will become a W3C standard, it is difficult to reach out to the industrial world. On the other hand, SPIN has become a de-facto industry standard to represent SPARQL rules and constraints on Semantic Web models, building on the widespread acceptance of the SPARQL query language. In this paper, we argue that the life of existing SWRL rule-based ontology applications can be prolonged by being transformed into SPIN. To this end, we have developed a prototype tool using SWI-Prolog that takes as input an OWL ontology with a SWRL rule base and transforms SWRL rules into SPIN rules in the same ontology, taking into consideration the object-oriented scent of SPIN, i.e. linking rules to the appropriate ontology classes as derived by analyzing the rule conditions.
Rule-based systems have been extensively used in several applications and domains, such as e-commerce, personalization, games, businesses and academia. They offer a simplistic model for knowledge representation for both domain experts and programmers; experts usually find it easier to express knowledge in a rule-like format and programmers usually find rule-based programming easier to understand and manipulate, decoupling computation from control. The first is performed by the rules whereas the latter is determined by the rule engine itself, that is when and how to apply the rules.
The Semantic Web initiative [
There are mainly two modeling paradigms for the Semantic Web [
Since description logics and Horn logic are orthogonal in the sense that neither of
them is a subset of the other [
SWRL [
On the other hand, SPIN [
For all the above reasons, in this paper, we argue that the life of existing SWRL
rulebased ontology applications can be prolonged by being transformed into SPIN. To this
end, we have developed the SWRL2SPIN tool, using SWI-Prolog [
In the rest of the paper, we overview SWRL and SPIN syntax and semantics, focusing on their RDF vocabularies, in sections 2 and 3, respectively. In section 4 we present our tool, its transformation methodology, how rules are embedded into classes, how they are optimized and how builtins have been implemented. In section 5 we evaluate the tool and finally, in section 6, we conclude. 2
The Semantic Web Rule Language (SWRL) [
Rules are of the form of an implication between an antecedent (body) and consequent
(head). The intended meaning can be read as: whenever the conditions specified in the
antecedent hold, then the conditions specified in the consequent must also hold. Both
the antecedent (body) and consequent (head) consist of zero or more atoms. An empty
antecedent is treated as trivially true (i.e. satisfied by every interpretation), so the
consequent must also be satisfied by every interpretation; an empty consequent is treated
as trivially false (i.e., not satisfied by any interpretation), so the antecedent must also
not be satisfied by any interpretation. Multiple atoms are treated as a conjunction. Note
that rules with conjunctive consequents could easily be transformed (via the
LloydTopor transformations [
SWRL has various representation syntaxes: abstract, human readable, XML concrete and RDF concrete. Listing 1 shows an SWRL rule example in human readable syntax that states “when a student ?s attends a course ?c that is taught by a faculty member ?f, then the student ?s knows the faculty member ?f”. uni:Student(?s) ∧ uni:attends(?s,?c) ∧ uni:isTaughtBy(?c,?f) → uni:knows(?s,?f)
Listing 2 shows how this rule is represented in the RDF concrete syntax. Rules are instances of the swrl:Imp class. The head and body of the rule are lists of atoms (swrl:AtomList); each atom can be one of classAtom, IndividualPropertyAtom, DatavaluedPropertyAtom, SameIndividualAtom, DifferentIndividualsAtom, or BuiltinAtom. All but the builtin atoms have one or two arguments (properties swr:argumentNN); additionally classAtom has a classPredicate property, whereas the PropertyAtoms have a propertyPredicate property. BuiltinAtoms have a list of arguments instead and the name of the builtin function. Arguments can be variables, declared as instances of the swrl:Variable class, datatype constants, in the Value^^Datatype format, or individuals, i.e. instances of an OWL class.
3
Modeling languages for the semantic web, such as RDF Schema [
The SPARQL Inferencing Notation (SPIN) [
The SPIN Modeling Vocabulary [
The SPIN class description vocabulary defines several RDF properties that can be used to attach SPARQL queries to classes. The property spin:rule can be used by SPIN reasoning engines to construct inferred RDF triples from the currently asserted information in the model. The SPARQL queries referenced by the SPIN properties are interpreted in the context of the associated class. At run-time, the SPARQL variable ?this is (by default) pre-bound with instances of the class and its sub-classes. Typically, the query itself does not need to bind ?this to any value in the WHERE clause. The execution context (e.g., inference engine) will do this before the query is executed.
SPIN takes an object-oriented world view on Semantic Web models, in which SPARQL queries play a similar role to functions and methods. Inheritance (expressed using rdfs:subClassOf) is treated in the sense that any query/rule defined for superclasses will also be applied to subclasses. In other words, SPIN class descriptors can only "narrow down" and further restrict what has been defined further up in the class hierarchy. In this spirit, global class descriptions are those that are attached to the root class rdfs:Resource or its OWL equivalent owl:Thing. Those global queries may not even mention ?this at all.
The property spin:rule links an rdfs:Class with a SPARQL CONSTRUCT query that defines an inference rule that determines how additional triples can be inferred from what is stated in the WHERE clause. For each binding of the pattern in the WHERE clause of the rule, the triple templates from the CONSTRUCT clause are instantiated and added as inferred triples to the underlying model. At query execution time, the SPARQL variable ?this is bound to the current instance of the class.
The example in Listing 3a defines a SPIN rule (in textual SPARQL format), attached to class uni:Student via the spin:rule property, that infers the value of the uni:knows property from values of uni:attends and uni:isTaughtBy. Listing 3b shows how the same rule is represented using the SPIN modeling vocabulary. uni:Student a rdfs:Class ; spin:rule [ a sp:Construct ; sp:text """
CONSTRUCT {
?this uni:knows ?f . } WHERE { ?this uni:attends ?c . ?c uni:isTaughtBy ?f }""" ].
[ a sp:Construct ; sp:templates ([ sp:object spin:_this; sp:predicate uni:knows ; sp:subject sp:_f ]) ; sp:where ( [ sp:object spin:_this ; sp:predicate uni:attends ; sp:subject sp:_c ] [ sp:object sp:_c; sp:predicate uni:knows ; sp:subject sp:_f ] Listing 3. Sample SPIN rule in (a) human-friendly notation and (b) SPIN modeling vocabulary
SPIN rules are instances of the sp:Construct class; the rule “head” is defined with the sp:templates property whereas the sp:where property defines the rule “body”. The above properties contain lists of triple patterns (sp:subject, sp:predicate, sp:object). Other SPARQL query elements contained in rule “body” can be TriplePath, Filter, Bind, Optional, Union, NamedGraph, SubQuery, NotExists, Minus, Service, and Values. In the following we only present the first three, since they are the only ones used in the SWRL2SPIN tool.
A TriplePath is similar to a triple pattern, but instead of an sp:predicate, has an sp:path property, whose value can be one of several types, sp:SeqPath being the most usual one. The sequential steps of the path are represented through consecutive sp:pathNN properties. The representation is more complex when arbitrary length path matching is involved, i.e. when the * operator is used.
Filter elements are blank nodes, instances of sp:Filter that have property sp:expression, pointing to an expression that can be evaluated to true or false. Expressions are actually function calls which are resresnted as instances of the function's URI. All other properties of expressions (or function calls) are interpreted as arguments, using consecutive sp:argNN properties. However, other property names can be used as well, depending in the function. Arguments can be either datatype constants or variables, which are blank nodes with an sp:varName property whose value is a string. E.g. the FILTER (?y > 30) expression is shown in Listing 4a.
The BIND keyword assigns a computed value to a variable. Bind assignments in the rule “body” are represented as instances of the class sp:Bind, having an sp:variable property to point at the variable on the right side of the assignment. The property sp:expression points to the root of the expression tree that delivers the computed value, in much a similar way to filter expressions (i.e. function calls). E.g., the expression BIND ((?x * 2) AS ?y) is shown in Listing 4b.
[ rdf:type sp:Filter ; sp:expression [ rdf:type sp:gt ; sp:arg1 [
sp:varName "y" ; ] ; sp:arg2 "30"^^xsd:int ;
Listing 4. Filter (a) and Bind (b) expressions in SPIN modeling vocabulary.
The SWRL2SPIN tool accepts at its input an OWL ontology with SWRL rules embedded in the ontology using the RDF concrete syntax of SWRL, as exported by tools such as Protégé combined with the SWRLtab plugin. The tool produces at its output an OWL ontology (just copying the input one) extended by SPIN rules that have been created by translating the SWRL rules. SPIN rules are embedded inside their corresponding classes, following the OO nature of SPIN, instead of having a flat rule base as in SWRL. Furthermore, the ?this variable of SPIN is used to identify instances of the rule-embedding class, therefore SWRL condition elements that identify the class of the corresponding instances are removed, speeding-up, thus, rule execution. Finally, the same SWRL may involve instances of multiple classes, so our tool generates multiple versions / views of a rule, optimized for each of the classes, separately.
The main procedure for translating a SWRL rule into a SPIN rule involves mapping classes and properties of the RDF concrete syntax of SWRL into corresponding classes and properties of the SPIN modeling vocabulary, in a recursive way starting from swrl:Imp instances, following an almost one-to-one mapping scheme shown in Table 1. The only exception to the straightforward mapping is the SWRL built-ins whose translation is customized for each function. We will discuss translation of built-ins in section 4.3.
In the following, we give an example of translating a SWRL rule without built-ins to a SPIN rule. Consider the SWLR rule in Listing 1 that is translated into the SPIN rule in Listing 5. The actual translation is between the RDF representations of the SWRL and SPIN rules, shown in Listing 6 and Listing 7, respectively.
CONSTRUCT {
?x :knows ?z . } WHERE { ?x rdf:type :Student . ?x :attends ?y .
?y :isTaughtBy ?z .
}
Listing 5. Translation of SRWL rule of Listing 1 into SPIN Listing 6. Example of an input SWRL rule in RDF concrete syntax
One of the unique features of SPIN compared to SWRL is the ability to embed rules into classes and treat them in an OO way as inheritable behaviors (aka methods). By doing so, instances of the embedding class can be identified by variable ?this. In SWRL2SPIN we 1. identify variables in the rule body that refer to class instances that play the role of the “subject” in the triple patterns; 2. identify the classes these variables refer to; 3. generate as many rules as the number of the different classes “discovered” in step 2; 4. rewrite each rule of step 3 so that: • corresponding variable names are replaced by ?this • rdf:type triple patterns that refer to ?this are removed from the rule body • triple patterns in the rule body are re-ordered so that the order of triple patterns is optimal.
2. first arguments of a swrl:IndividualPropertyAtom or a swrl:DatavaluedPropertyAtom construct;
The rationale behind this is that subjects of triple patterns can only play the role of the “referenced object”, i.e. the object that exhibits the class behavior. For our example, the collected variables are:
2. variable ?y, due to isTaughtBy(?y,?z) individual property atom.
In step 2, we identify the class that the instantiations of the above variables belong to by: 1. checking if they are arguments of a swrl:ClassAtom construct; 2. retrieving the domain / range of arguments of swrl:IndividualPropertyAtom constructs; 3. retrieving the domain of arguments of swrl:DatavaluedPropertyAtom constructs.
For the ongoing SWRL rule example, the collected variables ?x and ?y belong to classes Student and Course, respectively. The former is discovered from the Student(?x) class atom, while the latter is discovered from the domain of the isTaughtBy(?y,?z) individual property atom and / or the range of the attends(?x,?y) atom. Thus, the SWRL rule is converted into two SPIN rules stored at classes Student (Listing 8a) and Course (Listing 8b), respectively:
CONSTRUCT { # @Student
?this :knows ?z . } WHERE { ?this :attends ?y .
?y :isTaughtBy ?z . } CONSTRUCT { # @Course
?x :knows ?z . } WHERE { ?x rdf:type :Student . ?x :attends ?this .
?this :isTaughtBy ?z .
}
4.2
Optimizing SPIN rules
In the previous example, the body of the SPIN rule at class Course has two triple patterns that contain variable ?this and one triple pattern for variable ?x ranging over all instances of class Student, following the initial ordering of the atoms at the body of the SWRL rule. However, it is evident that this ordering leads to a very inefficient SPARQL query execution, since variable ?x can be instantiated with many values, whereas variable ?this instantiates each time only with one value. So, SWRL2SPIN reorders the triple patterns in the body of converted / embedded SPIN rules using the following heuristics: 1. Triple patterns that contain variable ?this at the subject of the triple pattern are placed first; 2. Triple patterns that contain variable ?this at the object of the triple pattern are placed second; 3. Triple patterns that contain the properties owl:sameAs or owl:differentFrom are placed after the triple patterns that instantiate the variables of their subject and object; 4. The order of all other triple patterns remains unchanged.
According to the above, the triple patterns of the body of the SPIN rule at class Course are re-ordered as shown in Listing 9. CONSTRUCT { # @Course
?x :knows ?z . } WHERE { ?this :isTaughtBy ?z . ?x :attends ?this .
?x rdf:type :Student . }
4.3
Implementing SWRL builtins
The translation of the SWRL builtins does not follow the straightforward approach
for the rest of the SWRL atoms and it depends on the nature of each function and the
existence of equivalent SPIN or SPARQL functions. More specifically, SWRL
specification [
The conversion of the builtins falls into ten categories: binary filter, associative infix assign, binary infix assign, unary assign, assign function, filter function, magic property, complex assign, complex filter, and complex expression1. Filter-type conversions lead to SPARQL FILTER Boolean expressions, whereas assign-type conversions lead to BIND expressions. Simple mathematical comparisons and operations are treated as binary infix mathematical operations, such as >= or -. Addition and multiplication in SWRL builtins can have an arbitrary number of arguments, so they are treated as associative binary infix operators. Finally, there are also simple unary operators, e.g. minus.
Another large category is SWRL builtin functions with an exact equivalent SPIN / SPARQL function, as e.g. round, replace, and contains. The conversion of these functions is straightforward, as in the FILTER case all arguments of the SWRL builtin become arguments of the SPIN / SPARQL function, whereas in the BIND case the first argument of the SWRL builtin becomes the variable to be bound in the SPIN / SPARQL BIND expression, whereas the rest of the arguments of the SWRL builtin become the arguments of the SPIN / SPARQL function.
As discussed in Section 3, FILTER and BIND expressions both have an sp:expression property that contains the mathematical or functional SPARQL expression; BIND also has an sp:variable for the assigned variable. All expressions belong to a type, which is the name of the main SPARQL function in the expression, e.g. sp:gt, sp:lcase, etc. In the case of the complex functional expressions, the outer function is the type of the FILTER expression, e.g. sp:contains in the case of the containsIgnoreCase SWRL builtin. The argument list of the SWRL builtin (property swrl:arguments) is treated as explained above, generating sp:argNN properties of the SPARQL expression / function. The only exception is the spif:cast function, whose second argument is represented by an arg:datatype property. The values of the sp:argNN properties can be SPIN variables, datatype constants, individuals or nested SPARQL functions / expressions. 1 Due to space limitations, details can be found at https://github.com/nbassili/SWRL2SPIN
The rest of the SWRL builtins are treated as Complex cases, meaning that their translation involves the combination of more than one simple functions, as discussed above. Complex cases can be filters, assignments or general SPARQL expressions (graph patterns) and they are treated in an ad-hoc manner. For example, the integerDivide builtin is translated as a division and a cast to integer, whereas the pow builtin is translated as repetitive multiplication using recursion. List builtins are of special interest because their translation cannot be performed using SPIN/SPARQL functions, but can be treated using SPARQL path expressions. For example, the member builtin is translated into a recursive path expression combining rdf:first and rdf:rest. The translation of the length builtin is the most complicated one because it requires a SPARQL subquery that counts all the elements in the list, i.e. all possible iterations of the rdf:rest property in the rdf:rest* recursive path. As an example, consider the SWRL rule in Listing 10 which is translated in the SPIN rule at class Person (Listing 11). Specifically, the RDF concrete syntax for the SWRL builtin atom is shown in Listing 12, whereas the converted SPIN / SPARQL expression is shown in Listing 13.
Person(?x) ∧ firstName(?x, ?y) ∧ lastName(?x, ?z) ∧ swrlb:stringConcat(?a, ?y, " ", ?z) → fullName(?x, ?a)
CONSTRUCT { # @Person
?this :fullName ?a . } WHERE { ?this :firstName ?y . ?this :lastName ?z .
BIND (CONCAT(?y, " ", ?z) AS ?a) . } Listing 11. Sample SWRL builtin translated to SPIN/SPARQL [ rdf:type swrl:BuiltinAtom ; swrl:builtin swrlb:stringConcat ; swrl:arguments [ rdf:type rdf:List ; rdf:first :a ; rdf:rest [ rdf:type rdf:List ; rdf:first :y ; rdf:rest [ rdf:type rdf:List ; rdf:first " "^^xsd:string ; rdf:rest ( :z ) ] ] ] ] ; Listing 12. RDF syntax for the SWRL builtin example [ rdf:type sp:Bind ; sp:expression [ rdf:type sp:concat ; sp:arg1 [ sp:varName "y" ; ] ; sp:arg2 " " ; sp:arg3 [ sp:varName "z" ; ];]; sp:variable [ sp:varName "a" ; ] ;
A special case is magic properties which are supported by many SPARQL engines to dynamically compute values at query time. A magic property usually is implemented by a calculation function that determines bindings of the variables on the left or right side of the predicate. SPIN enables users to define such magic properties, in a very similar way as SPIN Functions, but providing greater flexibility. In contrast to BIND/FILTER functions, magic properties can return multiple values. Furthermore, any input or output variable may be unbound; it is the task of the magic property to find their potential bindings. The magic property spif:split is used in SWRL2SPIN to translate the swrlb:tokenize SWRL builtin. The first variable of the SWRL builtin generates multiple bindings. When the spif:split magic property is used, the subject of the “triple pattern” generates multiple alternative bindings. Magic properties are treated in an adhoc manner in SWRL2SPIN, since their definition and behavior does not follow a regular pattern.
The rest of the SWRL builtins will be implemented as a future work, most probably
as complex conversion cases or as user-defined magic properties. We notice here that
the only other SWRL related tool supporting functions for RDF lists is the SWRL-IQ
plugin [
To evaluate SWRL2SPIN we have initially generated use cases of a University
ontology with various SWRL rules in Protégé2 [
Finally, we have evaluated the optimized SPIN rules (section 4.2) of SWRL2SPIN against their unoptimized version. For this we have used the unoptimized rule at Listing 8b against the optimized rule at Listing 9 in an ontology with 100K student instances that all attend the same course with one teacher. The inference took 1256,93 msec (on average) for the optimized rule version at TopBraid against 1414,61 msec for the unoptimized rule. Results are statistically significant with a p-value equal to 0,0208<0,05. All tests were performed on a Windows 10 PC with Intel i7-4770 @ 3.40GHz, 8 GB RAM and SSD. 6
In this paper we have argued that SPIN is a more promising de-facto industrial standard for the future of combining ontologies and rules, because it builds upon the 2 We have used the SWRLTab editor of both Protégé 3.5 and 5.2. widespread use of SPARQL. Furthermore, SWRL has been around for quite a while, not being able to achieve a W3C recommendation status. SPIN also offers more expressivity than SWRL due to constructs like FILTER and UNION, and also offers object-orientation by being able to store rules to classes as behaviors to be inherited through the class hierarchy. Thus, we believe that existing large SWRL projects can benefit from being translated into SPIN rules.
To this end we have developed in Prolog and presented the SWRL2SPIN prototype tool3 that translates ontologies with SWRL rules into ontologies with SPIN rules. We have tested the tool using ontologies and SWRL rule bases edited (and tested for reasoning) by Protégé and we have successfully imported the translated ontologies and SPIN rules into the TopBraid Composer, having the same inference results. We have also evaluated the scalability of the tool and the effectiveness of some optimization of the generated SPIN rules. Our tool currently supports 41 SWRL builtins, including builtins for lists which are usually not supported, but we have provided a structured methodology for supporting more in the future.
Notice that our translation methodology is based on direct RDF-to-RDF translation
between the SWRL and SPIN RDF vocabularies; therefore, it is not dependent on the
implementation language we have choose for SWRL2SPIN. As for future work, we
plan to evaluate it for converting larger SWRL rule bases, to support more SWRL
builtins and to possibly provide this tool as an add-on to some SPIN rule engine. Finally, a
transition of the tool to SHACL SPARQL rules [
Available at https://github.com/nbassili/SWRL2SPIN https://github.com/nbassili/SWRL2SHACL