Re: next steps on http graph store protocol

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.

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

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Monday, 9 January 2012 11:15:36 UTC