Re: next steps on http graph store protocol

On Mon, 2012-01-09 at 11:12 +0000, Steve Harris wrote:
> On 2012-01-06, at 19:50, Sandro Hawke wrote:
> 
> > As I understand it, the potentially-blocking issues are:
> > 
> > 1.  I want to make sure it's okay to have some resources which are
> > subject to this protocol (with people doing GET and PUT of RDF to them),
> > for which POST does not mean "please merge".   I believe we have
> > consensus on this, framing it as some resources have this behavior and
> > some don't.  Eric is suggesting we name this class, so that people can
> > express in RDF whether a resource is this kind of resource.   (When he
> > and I brainstormed about this, I think our best suggestion for the URI
> > was http://www.w3.org/2012/http/PostMeansAppend.  One can easily imagine
> > a parallel PostMeansCreate, which would be true for the GraphStore
> > itself and any nested collections.   Another URI candidate:
> > http://www.w3.org/ns/http-post/AppendingResource (and
> > CreatingResource)).
> 
> I'm not convinced that this is the best characterisation of the problem.
> 
> I see it more as: within some conceptual web space (URI prefix, domain/port combination/whatever) there are some URIs that are an exposed GraphStore, and some URIs that do other things (e.g. describe collections, whatever) - the RDF Dataset ones are covered by Graph Store Protocol, the others aren't.

I don't understand what you're proposing folks should do who want
subdirectories in their Graph Store.   This is, I believe, what IBM and
Alexandre Bertails (in the new W3C Validator) and Annotea do.   They
POST to a collection to create a new resource, and they GET that
collection to see, in some RDF, what resources are in it.      That
seems like a very nice design to me, and one that requires some of the
graphstore resources to NOT have PostMeansMerge semantics.    So, I
argued this in our side telecon, and people seemed convinced, and Chime
put in some text that was good enough for me.    If you want to take
that text out again, I have a problem, because all these systems would
become in violation of the spec. I don't really care if we go this extra
step to name the class of resources

Also, what about the points below...?

    -- Sandro


> - Steve
> 
> > 2.  I want to make sure that we don't have any normative (RFC 2119)
> > language in sections labeled "non-normative" or "informative".  I'm not
> > sure where we got on this one.
> > 
> > 3.  I want to make sure we don't require (at the SHOULD or MUST level)
> > people to implement SPARQL UPDATE if they want to implement PATCH.   I
> > think we had a agreement on this, but it got a little confused with
> > issue (2) above during the telecon, so I'm not sure.
> > 
> > 4.  I understood Greg to be concerned about some connections with
> > Service Description.   I haven't gotten the gist of his concern. The
> > one thing I think we need from that connection is a way to find the
> > GraphStore URI (for use in making indirect URIs for named graphs) from
> > the endpoint address.   (I argued that we should just use the endpoint
> > address itself, bypassing SD for this, but no one else supported that
> > position.   I can live with the design that's been in the spec for some
> > time.)
> > 
> > 5.  Now it looks like we might also have a concern about the Base URI
> > for POST and PUT operations.   Arnaud had a comment about this, and in
> > the latest emails Andy and I are disagreeing about what the relevant
> > RFCs say about this.
> > 
> > (I also continue to have some editorial concerns, like the use of the
> > term "RDF Graph content" for what the RDF WG calls "Graph Container",
> > but I can live with the current text, since it it is editorial.)
> > 
> >      -- Sandro
> > 
> > 
> > 
>

Received on Monday, 9 January 2012 18:44:39 UTC