Understanding SPIN Templates

The SPIN Modeling Vocabulary defines a mechanism to encapsulate SPARQL queries so that they can be reused in different contexts: SPIN Templates. A SPIN Template is basically a canned SPARQL query that is parameterized with arguments. In this blog entry, I will walk through an example SPIN template to explain how templates are defined and used. In the end of this article I will also boldly explain why I believe that SPIN is potentially one of the missing links in the Semantic Web puzzle, and a disruptive killer technology.

If you haven't done so yet, please read the previous posting about Understanding SPIN Functions. SPIN Functions and Templates basically use the same mechanisms - the main difference is that templates are more general.

We will again use the kennedysSPIN ontology that is shipped with TopBraid Composer 3.0. This example ontology defines various family relationships, including parent, grandFather and grandMother. The example uses a template called InferGrandParent to derive the values of the two grand parent properties from the values of parent and gender.

Let's first have a look at how these relationships could be inferred using plain SPARQL queries. In the following screenshots, we have attached two SPARQL CONSTRUCT queries as spin:rules to the class Person.

The upper rule computes the values of grandFather while the lower rule infers the values of grandMother. We can see that both rules are almost identical: both queries walk up the parent relationship two steps and then check the gender of the grand parent. The only difference are the pairs grandFather/male and grandMother/female, but the basic structure of the queries is the same. SPIN templates can be used to generalize such query patterns so that they can be reused in a more maintainable way. In our example, we will introduce a template that allows us to replace the two individual SPARQL queries, so that the rules look will like in the following screenshot.

In order to get there, we first introduce a template called InferGrandParent, the definition of which is shown below.

A SPIN template is a class that has the metaclass spin:Template as its type. I recommend creating a subclass of the system class spin:Templates to keep your templates organized in the class tree. A template should have a comment describing what the template does and can have any number of arguments. These arguments are similar to the arguments of SPIN Functions described earlier; the main difference is that the arguments of templates are unordered and can point to any property instead of being limited to sp:arg1, sp:arg2 etc.

In our example template, we need two arguments:

1. the gender that we are matching against (male or female)
   
2. the predicate that we want to infer (grandFather or grandMother)
   

The values of those arguments will be inserted into the body query of the template at execution time. Let's take the rule to infer the grandFather relationship as an example. The instantiated template is an instance of the template class in which the values for gender and predicate are filled in:

When executed as a SPIN rule, the template call above will be substituted with the body of the template, so that we get:

So instantiating the template has the effect that the variables ?predicate and ?gender have been replaced with the arguments; in this case: grandFather and male. The same template can now be reused for the pair grandMother and female.

To summarize, SPIN templates are a powerful mechanism to put SPARQL queries into a (black) box so that you or others can reuse a piece of behavior, even without having to worry about the specific details of the query. Instead, they can use a simple form-based interface to "fill in the blanks" and let the system do the low-level SPARQLing.

Taking this idea further, SPIN templates are a mechanism to create arbitrary new ontology modeling languages. For example, I have shown how you can create templates that encapsulate unit conversion expert knowledge. Another example was the re-definition of OWL 2 RL using SPARQL, although the latter did not really use template arguments because all rules were global. The SPIN Standard Modules Library is another example of very generic templates for tasks such as cardinality constraint checking. But these examples may be just the tip of the iceberg. There could be a marketplace for SPIN template libraries consisting of domain-specific modeling languages with executable semantics.

Instead of hard-coding a pre-defined collection of modeling constructs such as OWL with its system vocabulary owl:Restriction, owl:FunctionalProperty etc, SPIN is an extensible framework for building your own modeling language. There is no need for SPIN-aware tools to hard-code the semantics of any specific modeling language - all they need to understand is how to execute SPIN templates, and the rest is completely driven by whatever is encoded in the particular ontology. SPIN users are not restricted by the vocabulary that any particular W3C committee has selected for them. Instead the democracy of the Semantic Web user's community will select the ideal set of those constructs that are really needed in practice.