Re: SPIN prospects

I appreciate all the comments on this thread, and thanks, Holger, for
your elaboration. See additional responses below.

On Thu, 2013-01-31 at 11:42 +1000, Holger Knublauch wrote:
> My guess whether people want to use SPIN or not depends on their 
> background. Clearly for many programmers it is better to take full 
> control without having another execution engine in the middle. Also the 
> complexity of the RDF syntax (which basically required the use of a 
> tool) was a show stopper for some.

Well, the complexity is just in the nature of the thing. If your choices
are to write a SPARQL parser and serializer or write an application
using an RDF model, I'll take the latter (especially if most of the work
can be done using SPARQL and Turtle).

>  The latter problem has been addressed 
> though, see my email announcing the Turtle-friendly simplified SPIN 
> syntax [1].

This is not a feature I would be interested in, but I suppose it could
be a useful shortcut for blocks of SPARQL that can remain opaque. It
would of course be necessary to use sp:text if there were features of
SPARQL syntax that could not be represented elsewise in SPIN, but I
don't believe there are any, are there?

> 
> However, not everyone is a programmer. SPIN addresses a different 
> problem than executing a bunch of SPARQL queries. It provides a 
> vocabulary for modeling and sharing the meaning and behavior of semantic 
> web resources. SPIN definitions can be published as linked data, just 
> like people share OWL restrictions to clarify the meaning of OWL classes.

I think SPIN can help fill the gap between rule languages and SPARQL, in
the opposite direction from which RIF is working. SPIN should make it
easier to build a complete RDF repository of data+model+rules that can
be navigated using linked data principles.

One of the early problems I found using SPARQL was conveying
meta-information about the variable bindings, e.g. to a downstream XSLT
process for transforming srx results. Now that I am generating SPARQL
the problem is compounded: how to transmit variable binding information
from a structured rule source (e.g. Common Logic) to SPARQL to the
sparql results processor--and, along the way, expose information to a
template controller to allow initial bindings at execution time. It
looks like SPIN can help with this.

> 
> One benefit of using SPIN is that it defines standard properties and 
> URIs that can limit the proliferation of ad-hoc mechanisms that would 
> otherwise appear.

Yes, and unlike approaches that rely on token replacement or macro
expansion, it offers the possibility to preserve, expose, and re-use
pertinent business logic across all your linked data applications.

>  Properties such as spin:rule and spin:constraint 
> clarify the role of a SPARQL query within a model. Furthermore, the 
> attachment of those rules and constraints to classes can create much 
> more maintainable query libraries than plain lists of CONSTRUCTs. (As a 
> side-bar, David: SPIN rules can also be INSERT/DELETE commands). This 
> object-oriented attachment also allows execution engines to select which 
> constraints and rules need to be executed for a given context resource.
> 
> Another key feature of SPIN is the ability to define and share new 
> SPARQL functions without programming them in Java [5]. Furthermore, SPIN 
> provides a simple yet powerful template mechanism that allows anyone to 
> make up their own domain-specific modeling language, even including 
> visual notations like SPINMap [6].
> 
> FWIW I have received confirmation from Kingsley that OpenLink Software 
> is adding some form of SPIN support to their products. AllegroGraph 
> already supports defining SPIN functions natively, similar to stored 
> procedures. Needless to say, TopQuadrant has a whole technology stack 
> built on top of SPIN [2], and some of this is available via free tools 
> [3] or open source APIs [4]. I hope with the recent generalization of 
> the SPIN syntax, more companies will adopt it.
> 
> And yes, a full W3C process beyond the Member Submission is still a 
> possibility. If only those processes were not so time consuming! 
> Meanwhile I believe the market will decide, and SPIN is already a 
> de-facto standard in certain areas.

Perhaps the W3C folks will take note and reconsider whether SPIN should
be tied to RIF future, or if it might have a useful place alongside
SPARQL (regardless of how RIF fares).

Regards,
--Paul

> 
> Regards,
> Holger
> 
> [1] http://lists.w3.org/Archives/Public/semantic-web/2013Jan/0147.html
> [2] 
> http://composing-the-semantic-web.blogspot.com/2010/04/spin-technology-stack.html
> [3] http://www.topquadrant.com/products/TB_Composer.html
> [4] http://topbraid.org/spin/api/
> [5] 
> http://composing-the-semantic-web.blogspot.com/2009/01/understanding-spin-functions.html
> [6] 
> http://composing-the-semantic-web.blogspot.com/2011/04/spinmap-sparql-based-ontology-mapping.html
>

Received on Thursday, 31 January 2013 03:39:11 UTC