- SPIN is more expressive than SWRL because SPARQL is (e.g. you have richer filter expressions and you can really use the semantic web as part of your queries via named graphs).
- SPIN will benefit from the further evolution of SPARQL which is a very active W3C standard with lots of tools. As far as I can tell, SWRL is not actively moved further right now apart from a RIF mapping.
- SPIN is more extensible, e.g. you can create your own functions and templates. With SWRL you are limited to whatever hard-coded execution library has been provided by the engine. SPIN functions are first-class citizens and can be shared together with the data models.
- SPIN has explicit support for constraint checking.
- SPIN is object-oriented and therefore arguably easier to maintain. Also rule execution and constraint checking can be scoped better due to the OO attachment.

You may want to get additional opinions by posting a similar question to the SWRL proponents such as the Protege-OWL 3 people. I have seen some postings there that compare SWRL with SPARQL, but I largely disagree with their conclusions. In particular they seem to claim that only SWRL can use OWL DL semantics, which is untrue because you can of course execute SPARQL on top of a triple store with OWL DL inferencing turned on. For additional questions on SPIN I recommend either contacting me directly or via the TopBraid Composer mailing list http://groups.google.com/group/topbraid-composer-users. Thanks.

(Unsurprisingly) I couldn’t agree more with your observations. The company I work for (TopQuadrant) has quite a number of “real-world” customers from industry, government military and one of the main complaints that we always tend to hear is that the open-world semantics of OWL don’t match their use cases and expectations. In many cases, our users (and the tools) simply ignore that the open-world assumption (and no unique-name assumption) exist in OWL and instead pretend that an OWL cardinality restriction of 1 really means just “one value allowed” – which is incorrect according to the formal semantics of OWL. SPARQL has a much clearer answer here: you get what you see in the graph, and not more. All what SPARQL does is pattern matching against the triples, and thus it has closed-world semantics and the unique name assumption. Having said this there are of course still use cases where bringing in OWL semantics has benefits, but the choice should be yours if you want to activate those semantics for your use case. I gave an example of how to express a large subset of OWL using SPIN in a follow-up posting [1].

And yes, a general strength of RDF-based technology is for linking models. Everything in RDF has a unique URI to start with, but then it’s also possible to link arbitrary concepts together by reusing or sub-property-ing properties. We have many customers (such as NASA) who are very keen on integrating their large stock of existing XML dialects to make information exchange more efficient. We are building ontologies for them and with them to capture the domains of interest and thus avoid redundancies etc. I wrote about the SPIN-based unit conversion that is one of the outcomes of this work [2]. A constant problem that my colleagues face in this XML-related work is the weakness of expressivity of XML Schema – a format mainly geared for tree structures whereas most of the real-world is better modeled as graphs.

Another aspect of RDF that SPIN rides on is the vision of a distributed self-describing data structure. In the Semantic Web, both classes and instances live in the same space and can be queried using the same mechanisms. SPIN takes this idea to extremes: you can not only define classes and properties, but even define executable semantics of those and use this mechanism to build your own modeling languages. I wrote about this elsewhere as well, but my article on SPIN templates [3] might be a good place to start. The key idea is that if someone introduces a new concept such as a constraint check on units then he or she can publish this constraint check by means of a SPIN template that lives at a specific URI for anyone (human or machine) to look up and execute. No other hard-coded magic is needed anywhere as long as your tools understand SPARQL. This approach can be used to build truly open model-driven applications, and the computer game on my blog is one example [4] of this vision.

Anyway, there is certainly more to evolve in the SPARQL space. And yes we may be going to W3C with SPIN in the future. Right now we are in beta phase and I didn’t even properly announce this work yet to the wider Semantic Web community. So far responses from our users have been very positive and I know of at least one company that is considering to even create their own SPIN implementation. Since it’s all based on SPARQL, a large number of vendors with SPARQL support (including Oracle 11g :) ) could in principle add SPIN-like technology to their stack.

Holger

[1] http://composing-the-semantic-web.blogspot.com/2009/01/owl-2-rl-in-sparql-using-spin.html
[2] http://composing-the-semantic-web.blogspot.com/2009/01/video-sparql-based-unit-conversion-with.html
[3] http://composing-the-semantic-web.blogspot.com/2009/01/understanding-spin-templates.html
[4] http://composing-the-semantic-web.blogspot.com/2009/01/spin-box-sparql-based-computer-game.html

There may be another option here as well… Tools like Pellet add SWRL/Datalog rules which could be used for constraints. I think that this is still preliminary work in their AL-Log engine, but it looks similar/valuable.

Andrea