Experiences with SPIN?

I'm curious what kind of experiences people have had with SPIN? I see that there seems to be a reference implementation for Jena, as well as support in Topbraid. Have you found the concept useful? Is the performance acceptable? Are there other more standards based alternatives that can perform a similar function?

I like the features and power of SPIN, but I'm a bit worried about the possibility of it disappearing if the concept fails to catch on.

In terms of risk with adopting a new technology, I'd like to emphasize that SPIN is SPARQL-based. It defines abstractions and rule processing for conveniently organizing SPARQL queries. Anything defined in SPIN can be broken down to a set of SPARQL queries, along with code specifying how and when the queries are executed. SPIN can be seen as three basic concepts:

First, SPIN defines a RDF representation for SPARQL queries. The value added is that queries become part of the model's RDF triples and can be viewed as triples. Translators from SPIN to text formats are freely available, so there is no risk using SPIN RDF syntax.

Second, SPIN defines abstractions for reusing and parameterizing queries. The value added is a standard way of reusing segments of SPARQL queries for more readable queries and improved maintenance. SPARQL syntax is used throughout, so queries can easily be moved to other SPARQL-based platforms.

Third, SPIN defines a rule-based process for executing sets of SPARQL queries for inference and constraint warnings. It specifies object-oriented processing of queries where rules and constraints are defined for classes and applied to members of classes. The value added is a flexible mechanism for defining rule systems, including RDFS and OWL/OWL 2, and rules for constraint checking. All rules are defined in SPARQL so they can easily be transferred to other SPARQL-based systems.

In sum, SPIN is based on SPARQL standards throughout, allowing an easy migration to and from SPIN-based systems.

Hello, We are using many aspects of SPIN pretty extensively on a project here at Boeing. It has now completely replaced the pellet inference engine we used to use. We've found it's ability to pick and choose exactly which of the "standard" (e.g. inverse, transitivity, etc.) inferences to generate, as well as its ability to define custom inferences that are bound directly to specific classes in our model, has been both easy to use and very empowering.

We are also extensively using its constraint checking capabilities, with again all the advantages of binding the rules directly to the model.

As an example, below is a constraint check we've bound to one of our classes that has a subAction property that must be acyclic.

# Action hierarchy must be acyclic
    ?this (Neutral:subAction)+ ?descendent .
    ?descendent (Neutral:subAction)+ ?this .

Of course SPIN depends extensively on the SPARQL language, a language that is becoming more and more flexible and powerful. The big advantage of using SPARQL as a rules language is that you don't have to learn a new language, assuming anyone who is doing semantic web work is going to have to learn SPARQL anyway.

As for it disappearing, I think knowing that TopBraid is fully committed to it should assuage some of your fears. IMO, TopBraid is one of the leading (if not THE leading) company in the SemWeb industry, and as such holds some influence over its direction. My guess is SPIN is going to become central to a lot of new features of their products (if it hasn't already), and if so they will remain highly motivated to continue its development. If they go away, I think the implications to the semantic web industry would be a lot worse than just SPIN disappearing.

I like SPIN, for all the reasons mentioned above. Unfortunately, I currently have to prune it out of my ontology when I deliver it to customers, since it's not standard in the way one would claim SWRL is. And that's a legitimate complaint, of course - right now most people'd need to incorporate TopBraid into their deployment solution to leverage those SPIN rules.

I haven't heard of a reference implementation in Jena, but that'd be a nice step in the right direction. It'd also be nice if there were a cleaner Turtle syntax for declaring those rules: if RDF moves in the (IMHO) right direction, two named graphs'd be just peachy for declaring a head and body.