Re: please wait on Graphstore Protocol

On Mon, 2011-12-12 at 16:01 -0500, Chime Ogbuji wrote:
> 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

I understood Arnaud's last point to be about something different than
what you're responding to.  I think it's about how you write an RDF
graph that is in some sense self describing (eg with a cc:license
triple) when the client doesn't know where the server will end up
publishing it.  I think their solution (a null URI, aka a URI relative
to where it ends up) is the right one; I'm not sure if it's in scope for
this spec.

> 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? 

I don't quite understand the question.   In general, people should
comment as early as they can, but definitely before LC if they are in
the WG (as I'm doing now), and before CR if they are not in the WG.  Or
before the end of CR, if it's about something they learned during
Implementation.  If they don't comment by those deadlines, they are on
somewhat lower moral ground to complain, but if their suggestion is
good, we probably should still pay attention.

I gather the solution written up in the Dec 6th article has been running
in some IBM products for a long time, maybe years, but I don't really
see how who-came-first matters.  The main point is we all want to make
the spec as good as it can be given our limited time and resources.

On the point at hand, I believe there is an architectural problem with
the POST-to-Graph=APPEND rule.  In the general case, I believe it makes
sense to consider a Graph URI as potentially identifying any Resource
which has state which the system can encode to and/or decode from an RDF
Graph.  So, the backend doesn't have to be a general purpose RDF store;
it can be a specific application (as in the IBM paper), which provides
an RDF *view* of its internal structures.    So the "Graph" might be
almost any kind of OO-style Object, mapped to/from RDF.

The problem with POST=APPEND is that I think we also want to be able to
use POST to pass messages to (or invoke methods on) those objects.  

For example, if there's an RDF+REST view of a test case, maintained by
some enterprise test case management system, it makes sense to GET and
PATCH the state of the test case, but it also might make sense to invoke
operations which perform analysis or even run the test against some
identified service.   Since we can do APPEND with PATCH, I don't think
we should close the door to method invocation / message passing by also
devoting POST to that.

(Yes, we could open another door by POSTing with a non-RDF media type,
but I certainly don't want to drive people to either (1) making
duplicate media types or (2) not using RDF.)

Does that make sense?   This didn't occur to me in my review; it wasn't
until I learned, last week, how IBM was doing RDF+REST access to data
which was not in a GraphStore.

> 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. 

I think they're talking about POST to the collection (aka GraphStore)
URI (as in our current draft), not POST to the graph URIs.  For directly
creating an addressable resource, I think everyone would agree to use
PUT.

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

Well, what I said above was probably the most interesting bit.

    -- Sandro

Received on Tuesday, 13 December 2011 04:36:38 UTC