- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 09 Dec 2004 09:10:04 -0600
- To: andy.seaborne@hp.com
- Cc: Kendall Clark <kendall@monkeyfist.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Thu, 2004-12-09 at 14:56 +0000, Seaborne, Andy wrote: > Kendall, > > Good to see a new draft. Seems to me to be going in the right direction and > could be published as a first WD as-is. > > Andy > > == Language specification This part of your message seems relevant to an existing issue http://www.w3.org/2001/sw/DataAccess/issues#protocolRootReferent > It would be good to be able to transport other query languages, existing and > to come. The abstract syntax for RDFGraphQuery does not contain a specifier for > the query language; That's a good thing, per my experience. (as reported earlier in a DESCRIBE thread http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0346.html ) > guess/parsing may be insufficient (some RDQL is legal SPARQL > but the effect of SELECT is different). Guessing isn't necessary, any more than an HTTP server needs to guess that the incoming syntax on port 80 is HTTP syntax. There's external metadata out there in the world that says that this endpoint speaks HTTP. > > I'd like to see a parameter in the abstract protocol with "lang=" in the HTTP > binding. It becomes the only globally defined parameter and would free up all > other parameter names to be specific to the query language, not predefined by > this doc. (I think there are slight differences in "graph=" between the SPARQL > query and the getGraph query.) > > With a lang= parameter, then the requests would look like [*] this: > > GET /qps?lang=sparql&graph=...&query=... > > then the 3rd party form (ask a service for a named graph) of getGraph is: > > GET /qps?lang=getGraph&graph=... > > while the 1st part version is still regular GET: > > GET /3.rdf > > [*] except it should be a URI, not a short name. But it won't fit them. [... other review sections elided...] -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Thursday, 9 December 2004 15:10:06 UTC