- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 21 Feb 2005 13:32:29 +0000
- To: Dan Connolly <connolly@w3.org>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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