Re: protocol: updated (radically changed) draft

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