- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Wed, 24 Nov 2004 11:57:50 +0000
- To: kendall@monkeyfist.com
- Cc: public-rdf-dawg@w3.org
Finally had the time to look at these... On Fri, 19 Nov 2004 11:22:50 -0500, Kendall Clark <kendall@monkeyfist.com> wrote: > I've decided to pretend as if I believe that doing something too > simple in the protocol space will result in something *actually useful > and interesting* much sooner than trying to do something interesting > right now. > > I don't actually believe this, but I'm going to try it on for size. > > So I've published a new draft of my protocol document that: > > - removes 5 of the 7 methods, leaving on query and getGraph That's good. > - removes all talk of discovery, advertisement, and WSDL I'm not familar enough with WS* to really see if the connection is good. > - hardcodes (gag!!!) query parameters That's a good choice. > In other words, I've forked myself -- a sure sign of insanity. :> > > If nothing else, having 2 v. different but obviously related drafts > should give the WG something to straw poll, so that we can figure out > where the hell we are. > > Hence, the new version (1.7) of the protocol is available at > > http://monkeyfist.com/kendall/sparql-protocol-simplex/ The scope of this smaller document seems appropriate for the first version of a protocol work we produce to the public. The document itself needs work as it sort of reads like ~60% definitions (till B.) before getting to the the real interesting content. I'd prefer to have examples in HTTP first, then go into the formal bits. [Yes, this is like the RDF/XML spec I edited, worked for me :) ] > While the older, fuller (and more interesting!) version of the > protocol is (and will remain) available at > > http://monkeyfist.com/kendall/sparql-protocol/ I like the approach of the abstract/concrete operations split so that other concrete protocol bindings can be made later in or outside this WG. Given the timescales of the WG, I feel we need to get the protocol stuff out soon and hence cut it down to the core needed - HTTP binding and be query focused. So the other 5 methods for updates/add/remove triples should be shelved for later work, in this WG or other. Detailed comments I don't worry about query params being graph=, lang=. That's fine, all the words in the existing XML formats, RDF/XML, HTTP protocol (GET, PUT, ..) and the protocol document itself are also in English. I'd prefer not to have single character parameters, they are easy to misread/spell especially if we used things like: g and q (descenders only distinguish them) Preference to all query parameters for HTTP rather than a mixture of them + HTTP response headers. For a yes/no response, I'd expect response 'OK' and the content to indicate the yes/no, such as with text/plain "1\r\n" and "0\r\n" Some of the abstract protocol responses may not be needed - unsure about the Moved ones. As I understand that OperationPoint is the (URI of the) service access point for the protocol. You also URIs for named graphs and for constructing sets of them - OperationTargetSet or for giving a single graph OperationTarget. I'm unsure whether getGraph is needed. Neutral to marginally convinced for now. You may be able to GET some of the graphs but a sparql protocol service *could* provide access to graphs with no public URI, such as a graph containing infered triples or other virtual graph. As I understand it, you need some Internet Media Types for the HTTP binding results for the three result formats: [ A QueryResult is either an RDFGraph, BooleanQueryResult, or VariableBindingSet.] the first one is pretty ok (application/rdf+xml) but the others? Should the form of the result - graph OR boolean OR variable bindings be selected in the protocol or just inferered by the result that returns - i.e. all systems must expect all query result forms for any query? Dave
Received on Wednesday, 24 November 2004 11:59:31 UTC