W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2005

Re: SPARQL Protocol for RDF

From: Danny Ayers <danny.ayers@gmail.com>
Date: Thu, 2 Jun 2005 18:22:18 +0200
Message-ID: <1f2ed5cd050602092247eecf8f@mail.gmail.com>
To: kendall@monkeyfist.com
Cc: Patrick Stickler <patrick.stickler@nokia.com>, public-rdf-dawg-comments@w3.org

On 6/2/05, Kendall Clark <kendall@monkeyfist.com> wrote:
> 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.

Yep, that'll do. 

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

What I don't really get from that is much about the case where the
background graph is named in neither the protocol nor the query. I
would imagine that will be the most common dataset specification -
"The Graph" (well, what you know of it).

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

Ok, ta.

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

Ok, I'd overlooked how easy that was. 

> (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. :>

All the more reason to make the list of parameters more flexible..?

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

Thanks for the draft!



Received on Thursday, 2 June 2005 16:22:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC