Documenting SPARQL extension functions

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 Tuesday, 4 January 2011 19:27:34 UTC