SPIN and RIF

201 views
Skip to first unread message

Arthur Keen

unread,
Oct 13, 2010, 4:43:35 PM10/13/10
to topbrai...@googlegroups.com
A question I am being asked more frequently by developers who like SPIN, but who are wary of interoperability issues because it is not yet being a standard:
 
1)  Can SPIN be encoded in RIF and transferred to another platform capable of processing RIF without loss of functionality?  
2)  Can SPIN be encoded as SWRL (or other rules languages) without loss?
 
WIthout looking into this too deeply, I think that the answer in general to these questions is no, because among other things, SPIN can create, and has access to SPARQL extensions that may not exist on a non-spin (non Jena) platform and the scope of SPIN inference can be more flexibly constrained than on other inference engines, so only a subset of SPIN capabilities would be interoperable in this way.  A counter argument supporting SPIN interoperability capabilities is that SPIN is open source and is mostly about SPARQL, so it can be easily adapted to to run on other platforms that support SPARQL.
 
Is this how others see this?
 
Thanks
Arthur

Scott Henninger

unread,
Oct 13, 2010, 10:07:34 PM10/13/10
to TopBraid Suite Users
Hello Arthur; First, to be clear, SWRL is not a standard. SPARQL is a
standard and that is the basis for SPIN.

That said, here are a few thing to help understand the relationships
between SPIN and RIF efforts. SPIN is a family of SPARQL convenience
features, one of which is rule-based processing using SPARQL. The
others, such as RDF syntax, functions, templates, magic properties,
JavaScript extensions, and SPARQL result sets, etc., are related to
using SPARQL in any real-world application, where it becomes necessary
to reuse queries and extend the query language. Another technology,
SPARQL Web Pages (SWP, aka UISPIN) adds to the SPIN stack by embedding
SPARQL queries in text templates. So rules are a subset of what SPIN
offers.

Note that from a developer's perspective, SPIN extensions to SPARQL
are defined in SPARQL or JavaScript. That means all one needs to
understand are two well-established standards (recommendations):
SPARQL and JavaScript. Other technologies are optional.

The next part of the question is how SPARQL Rules (constructors,
rules, and constraints) relate to RIF. RIF is not a general-purpose
rule syntax, but one that has been created to accommodate a number of
logic-based semantic web (semantic network) languages. The starting
point for RIF is OWL 1.1 (see Chris Welty's presentation on RIF at
http://vimeo.com/12989827). So from the start one is limited to
particular kinds of logic, which is a small subset of what RDF and
hence SPARQL and hence SPIN can express.

It is theoretically possible to limit oneself to a small subset of
rules that can be expressed in RIF and where the subset could be
imported and executed by one or more rule engines. This would ensure
rules portability across the vendors supporting this particular
subset. But the trade off to limiting the expressivity of rules would
be to embed the rules in program code to address these limitations.
(Just try concatenating two strings in OWL or a RIF dialect, and note
that some RIF dialects do not include negation!). This runs counter
to the purpose of embedding business logic in rules.

This is to say (reading between the lines of the RIF publications)
that the purpose of RIF was to find a common ground for a number of
existing logic-based languages such as JESS, CLIPS, OPS, RuleML,
KAON2, JenaRules, etc. And that's it. General-purpose rule languages
was not part of their charter. Note that RIF is as it says - an
interchange format that one can use like RDF/XML or Turtle so the
existing rule processors can exchange rules in a common format. As
you know from experience with RDF parsers, this is a small step toward
the larger issue of computational equivalence across engines.

RIF support remains limited and it remains to be seen how it evolves.
SPARQL, on the other hand, is quite established and the number of
SPARQL engines, and applications that adopt existing SPARQL engines,
appears to be on a sharp increase. All SPARQL engines support both
parsing and execution.

This is not to say that RIF is a bad idea or anything like that. Just
that it expresses the syntax for a couple of very specialized kinds of
logic. Like OWL, it may have its place. As some of these become
standard (especially if SPARQL processing is specified) TopBraid may
offer some of these. For now, SPARQL is both adequate and better
established. SPIN adds significant value on top of SPARQL.

BTW, as I see it, the starting point for this a discussion on SPARQL
(and hence SPIN) should be query languages, not logic languages. Note
that SPARQL is to RDF what SQL is to relational models. That's
probably a different discussion for a different time.

If you are interested in fate of SWRL, see the RIF FAQ (http://
www.w3.org/2005/rules/wiki/RIF_FAQ) which states "most SWRL features
are covered by RIF-BLD with the exception of 'different-from'".

To summarize, the question is really one of choosing between two
standards: SPARQL and RIF. SPARQL is clearly the more flexible of
these, and from the above you can see that RIF is a subset of a subset
of what SPARQL has to offer. SPIN if fully based on the SPARQL
standard.

Hopefully that will help fill in some details...

-- Scott

Arthur Keen

unread,
Oct 14, 2010, 3:28:54 PM10/14/10
to topbrai...@googlegroups.com
Scott,
 
Thanks very much for that detailed answer. 
 
Arthur

--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

Reply all
Reply to author
Forward
0 new messages