Re: SPARQL Protocol for RDF

> >    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