- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Thu, 2 Jun 2005 12:35:51 +0200
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: public-rdf-dawg-comments@w3.org
> > http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050527/ I've been following Dave's one-screenful protocol suggestion [1] in my experiments, which has worked pretty well. Running that against the new draft: http://example.org?query=sparql-query&query-lang=sparql&data=uri1&data=uri2&format=rdfxml&output-xslt=uri&limit=10 Parameter Value (allowed count): * query sparql query string (1) - same as proposed * query-lang "sparql" [default?] or … (1) - the protocol spec is only defined for SPARQL, so it seems reasonable not to include this, but this may be useful as an optional value (see below) * data URI/name of a data graph (0+) - ok, I have doubts about this, and it's appearance in the latest draft - default-graph-uri - shouldn't the default graph be something determined in the scope of the query engine? If it does need to be named, shouldn't that go in the query itself? * format "rdfxml", "xml", "turtle", "ntriples" … [defaults vary] (1) - possibly useful optional, though the use of the Accept header does seem neater. I forget my HTTP, apologies, but if there isn't anything of the specified type available, what is the response (code)? Does it list what mime types are available? * output-xslt URI of xslt document to apply on XML output (0-1) limit integer decimal 0+ (0-1) - if the server supports XSLT this can make a whole range of applications very easily available using a single URI. So I would like to see this available as an optional field. There may also be other useful options that may be supplied as URI query parameters. This leads me to suggest there should be some mechanism for optionals, perhaps covering 1. discovery of what's available; 2. response when an unsupported option is used. A HEAD might be a route to 1, for 2. - if the server doesn't support a given query parameter, it returns a 5xx along with a list of what it does support (if I could remember my HTTP I'd know whether these would need custom fields or not...) . Just a thought - the examples make the protocol side look more complicated than it is in practice. I wonder if it might be worth including informative sample code for e.g. Java, C#, Python (20, 15 and 3 lines respectively). Cheers, Danny. [1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0054.html -- http://dannyayers.com
Received on Thursday, 2 June 2005 10:35:53 UTC