Re: SPARQL Protocol for RDF

On Thu, Jun 02, 2005 at 12:35:51PM +0200, Danny Ayers wrote:
> > >    http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050527/

> I've been following Dave's one-screenful protocol suggestion [1] in myexperiments, which has worked pretty well. Running that against thenew 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):

A few things, Danny:

1. This is only a reply from me, a person, not the WG. :>
2. I'm pretty sure we aren't taking backward-compatability with Dave's
"one-screenful protocol suggestion" as a constraint, but no one's trying to
be willfully perverse, either.

> * 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 reasonablenot to include this, but this may be useful as an optional value (seebelow)
> * data URI/name of a data graph (0+)

After our Helsinki meeting, I think we agreed (though not formally) that
we'd drop this parameter and suggest people route diff queries to diff
service endpoints.

> - ok, I have doubts about this, and it's appearance in the latestdraft -
> default-graph-uri - shouldn't the default graph be somethingdetermined in
> the scope of the query engine? If it does need to benamed, shouldn't that go
> in the query itself?

The design we've come up with allows the RDF dataset (which is composed of
zero or one default (sometimes called "background") graph and zero or more
named graphs) to be specified either in the protocol, or in the query
language, or in both. In the case where it is specified in both, but the RDF
datasets are not identical, the dataset specified in the protocol trumps the
one specified in the query.

This is spelled out in the latest draft thus:

  The RDF dataset may be specified either in a legal [SPARQL] query using
  FROM and FROM NAMED keywords; or it may be specified in the protocol
  described in this document; or it may be specified in both the query
  proper and in the protocol. In the case where both the query and the
  protocol specify an RDF dataset, but not the identical RDF dataset, the
  dataset specified in the protocol must be the RDF dataset consumed by
  SparqlQuery's query operation.

Since both you and Patrick asked about this, this bit must either be vague
or just doesn't stand out enough in the draft presently. I'll think about
ways to make it more difficult to miss. :>

> * format "rdfxml", "xml", "turtle", "ntriples" ? [defaults vary] (1)

> - possibly useful optional, though the use of the Accept header doesseem
> neater. I forget my HTTP, apologies, but if there isn't anythingof the
> specified type available, what is the response (code)? Does itlist what mime
> types are available?

Yes, I prefer to use plain old content negotiation for this. No sense
reinventing it for this use of HTTP. I will eventually add an example that
uses con-neg to the spec.

> * 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 ofapplications
> very easily available using a single URI. So I would liketo see this
> available as an optional field.

I am personally dead set against this. It's a lot more complex to specify
than one query parameter, and it's completely orthogonal to conveying RDF
queries between clients and servers. The right approach, IMO, is to pass a
SPARQL protocol URI into an XSLT transformation service as input; that's the
reason, or one of the reasons, we made SPARQL queries *plainly*
URI-addressable: so that merely dereferencing one of them returns query
results (a representation of query results!), which another service may
consume as it pleases. The W3C (and Amazon and lots of other groups) have
XSLT (and XQuery and...) services already designed, spec'd, and deployed.
DAWG shouldn't reinvent this wheel either.

(And, really, why XSLT and not XQuery? Or: why not both?)

> There may also be other useful options that may be supplied as URIquery
> parameters. This leads me to suggest there should be somemechanism for
> optionals, perhaps covering 1. discovery of what'savailable; 2. response
> when an unsupported option is used. A HEADmight be a route to 1, for 2. - if
> the server doesn't support a givenquery parameter, it returns a 5xx along
> with a list of what it doessupport (if I could remember my HTTP I'd know
> whether these would needcustom fields or not...) .

Yes, this is what we were gonna do with SADDLE, and what, I suspect, a
future iteration of our work may well do. But we formally decided recently
to punt on this for now. As someone put it, "the ecosystem isn't yet mature
enough for us to know what to standardize" -- oh, yeah, right, that was me. :>

> Just a thought - the examples make the protocol side look morecomplicated
> than it is in practice. I wonder if it might be worthincluding informative
> sample code for e.g. Java, C#, Python (20, 15and 3 lines respectively).

Hmm, I suspect not, but who knows. One thing that will happen is more and
simpler examples, which I think should help this perception a bit.

Thanks for the comments!

Kendall Clark

Received on Thursday, 2 June 2005 14:03:12 UTC