Re: sparqlParam: an approach to QL selection/migration

Dan Connolly wrote:
> sparqlParam is an idea that came to me in Helsinki,
> in discussion of automated support for
> query language migration/selection.
>   http://www.w3.org/2001/sw/DataAccess/ftf4.html#item10
> 
> Suppose, hypothetically, some totally made up person, say,
> Steve, has a service running at, I dunno...
> 
>   http://triplestore.aktors.org/rdql/
> 
> i.e. it services GET to...
> 
>   http://triplestore.aktors.org/rdql/?query=rdql...
> 
> and suppose he wants to add SPARQL support. One way
> to do it is to service URIs like...
> 
>   http://triplestore.aktors.org/rdql/?query2=sparql...
> 
> and in the HTML form served in response to GETs to
>    http://triplestore.aktors.org/rdql/
> where it currently says...
> 
>   <h1>3store: RDQL Query</h1>
>   <textarea name="query" cols="80" rows="24">
> 
> just add another one:
> 
>   <h2>SPARQL Query</h1>
>   <textarea name="query2" cols="80" rows="24">
> 
> That HTML form markup basically says:
> 
>   I'll take RDQL syntax after ?query=...
>   and I'll take SPARQL syntax after ?query2=...
> 
> The sparqlParam approach is to capture this in RDF
> ala...
> 
>   @prefix rdql: <http://rdql-cabal.example/vocab#>.
>   @prefix sparql: <http://dawg.example/vocab#>.
> 
>   <http://triplestore.aktors.org/rdql/>
>     rdql:param "query";
>     sparql:param "query2".
> 
> On the client side, to use a sparql service, somebody
> has to tell you the parameter name somehow. Highly automated
> scenarios will use RDF (ala the turtle above) but
> you can also peek into some HTML or read some prose documentation.
> 
> There was some issue of how to pass this thru ODBC/JDBC.
> I've forgotten most of the details of how those work, but if
> I recall correctly, they have some syntax for passing things
> like host names, user names, etc., and this parameter name
> should fit thru that interface just fine.
> 
> Now that I've dumped my thoughts on the matter, I'll
> re-read what Kendall sent a while ago...
> 

This is a useful approach where there is significant legacy of services that 
wish to keep existing functionality and add SPARQL capability.  With no legacy 
concern, it seems easier to just say the SPARQL param is "query" and so that 
SPARQL-offering services just use that.  They can, of course, offer other 
params.  And there is no problem if some other service, unconnected to SPARQL 
offers "query" (parameters names aren't globally unique) and it would not have a 
service description anyway.

For Joseki, in moving from Joseki2 (current, pre SPARQL) to Joseki3 (provides 
SPARQL QL and protocol), compatibility would be nice but not essential.  The 
change in nature of the service offered is sufficient to mean publishers ought 
to reconsider their service anyway - SPARQL covers things done different ways in 
Joseki so it more a migration issue than an compatibility issue.

 Andy

Received on Monday, 21 February 2005 13:38:29 UTC