- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Thu, 2 Jun 2005 18:22:18 +0200
- 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. Understood. > > * 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. Ok. > Thanks for the comments! Thanks for the draft! Cheers, Danny. -- http://dannyayers.com
Received on Thursday, 2 June 2005 16:22:22 UTC