Re: please wait on Graphstore Protocol

See my response(s) inline below.

-- 
Chime Ogbuji
Sent with Sparrow
On Monday, December 12, 2011 at 12:08 PM, Andy Seaborne wrote: 
> See also:
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Jun/0000.html
> 
> and the use of the Location header:
> 
> http://www.w3.org/TR/sparql11-http-rdf-update/#http-post
> 
> when the request URI identifies the underlying Graph Store.
This is not a new comment. There was a drafted response that I have just not yet sent out. I may have not brought this draft to the attention of the WG. Please take a quick look at it now, because I will be sending it out shortly (since it is long overdue). From my perspective the questions raised in that comment are addressed by the response and please let me know if you think the response needs tweaking.

http://www.w3.org/2009/sparql/wiki/CommentResponse:AL-1

Note (as I mentioned during my review of the Service Description spec) that our decision to coordinate the Graph Store protocol and the SD specification ensures this cannot be resolved in the proper manner.
> > Unfortunately, we're not quite ready for Last Call on Graphstore
> > Protocol. I started to surface some issues in my review, and they came
> > up again much more strongly at last week's Enterprise Linked Data
> > Workshop. 
Ok, I'll look forward to your more substantive comments. 
> > At one level the problem is that the document could stand
> > on its own, without any reference to SPARQL, 
I don't see how that would work as the specification covers the management of RDF graphs (datasets / graph stores) and the definition of these is part of the SPARQL specification(s). Are you suggesting this specification define it's own self-contained notion of what is a mutable graph independent of what is defined in the SPARQL update language or something to that effect?
> > but the users who want
> > that will have a hard time finding and understand it because of all the
> > SPARQL trappings. 
Some more details here would be helpful.
> > At another level, this design may conflict with
> > some users doing just that. For example:
> > 
> >  Basic Profile Resources are created by HTTP POST (or PUT) to an
> >  existing resource, deleted by HTTP DELETE, updated by HTTP PUT
> >  or PATCH, and "fetched" using HTTP GET.
> > 
> >  --
> > http://www.ibm.com/developerworks/rational/library/basic-profile-linked-data/index.html
> > 
> > I think that conflicts with our POST-to-Graph=APPEND rule. I think we
> > need to sort this out before Last Call. 
What are we 'sorting out' exactly? Note the date of that article (December 6th 2011) predates the initial publications of this specification. Is there some W3C precedent on what is the correct way to (properly) incorporate independent and divergent implementations that were spawned after the beginning of the publication period of a WG and in circumstances where the implementors do not participate in the WG? 

It could also be (straight-forwardly) argued that using POST to directly create an addressable resource is at odds with the semantics of the verbs. 

> > It's pretty much my top
> > priority -- I hope to have a proposal in the next day or two.
I look forward to that

Received on Monday, 12 December 2011 21:01:49 UTC