- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Thu, 2 Jun 2005 10:01:40 -0400
- To: Danny Ayers <danny.ayers@gmail.com>
- Cc: Patrick Stickler <patrick.stickler@nokia.com>, public-rdf-dawg-comments@w3.org
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