Re: Documenting SPARQL extension functions

Hi Toby,

I believe you are raising a very important topic. SPARQL has been designed to allow extension functions, but current infrastructure does not seem to fully exploit this, leading to little sharing of otherwise reusable functions between triple stores.

The SPIN [1] framework is very much related work. SPIN makes it possible to define SPARQL functions declaratively on the web. SPIN functions are RDF resources that have an RDF description of arguments, return values etc attached to them [2,3]. This means that this function meta data can be looked up on the web, either by humans or linked data agents.

SPIN also supports various ways of formalizing the executable part of a function. One popular way is to define SPARQL functions by combining other SPARQL functions (or queries) using spin:body. But our user base frequently also uses JavaScript to define SPIN functions, and we have the SPINx [4,5] vocabulary for that purpose. This provides the same information like your content-negotiation solution, but also the function's other metadata, in a single RDF-friendly transaction. Being entirely in RDF, it allows users to see and edit the function's bodies within RDF tools such as ontology editors. Plus, the SPINx vocabulary makes it possible to simply point to a JavaScript file at a URL, and this would then make explicit that there is some JavaScript present at that URI, instead of having the client make random guesses at various content types to discover whether something executable might be there or not.

I believe a content negotiation approach like your outline might be interesting if there were a large number of possible implementation languages, and JavaScript seems to be a prime, platform independent and web-friendly choice. Yet I believe an RDF vocabulary such as SPIN should be used in conjunction with this.

SPIN is fully supported by TopBraid Composer, Free Edition [6].

Regards,
Holger

[1] http://spinrdf.org/
[2] http://spinrdf.org/spin.html#spin-functions
[3] http://composing-the-semantic-web.blogspot.com/2009/01/understanding-spin-functions.html
[4] http://spinrdf.org/spinx.html
[5] http://composing-the-semantic-web.blogspot.com/2009/03/using-javascript-to-define-sparql.html
[6] http://www.topquadrant.com/products/TB_Composer.html


On Jan 5, 2011, at 5:26 AM, Toby Inkster wrote:

> SPARQL has a number of built-in functions like STR() and REGEX() which
> can be used in filters, and since SPARQL 1.1, can be bound as results.
> As well as the built-in functions, SPARQL can be extended with
> additional functions which are identified by URIs.
> 
> While there's no requirement that those URIs be dereferencable,
> experience from linked data tells us that it's probably a good idea
> for them to be. But what should be the representation delivered when a
> client dereferences them?
> 
> I've been writing a few extension functions for Gregory Williams'
> RDF::Query Perl SPARQL implementation recently, so I was pondering this
> question and stumbled upon what I think is a pretty good solution.
> 
> Take for example, the function I've defined which takes no parameters
> and returns a UUID string as a literal. That function has the URI:
> 
> http://buzzword.org.uk/2011/functions/util#uuid
> 
> If you dereference that URI sending "Accept: application/ecmascript"
> you'll get an ECMAScript (JavaScript) implementation of the function,
> built on the RDF API which is currently being worked on by the RDFa
> Working Group.
> 
> The ECMAScript implementations there aren't directly used by the Perl
> implementation - they just serve as documentation for the functions
> identified by the URIs.
> 
> What do people think of this as a solution for documenting SPARQL
> extension functions?
> 
> -- 
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> 
>

Received on Wednesday, 5 January 2011 01:41:47 UTC