Re: next steps on http graph store protocol

On 9 Jan 2012, at 18:44, Sandro Hawke wrote:

> 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

I think where we disagree is on whether URIs that aren't in the Graph Store are covered by it's protocol - I just don't see why they would be.

Suppose I have Graph Store graphs of

http://foo.example/graph1
http://foo.example/graph2

And some magic API endpoint at

http://foo.example/magicCollectionThing

I see no reason why http://foo.example/magicCollectionThing should be covered by the graph store protocol just because it's lexically near by http://foo.example/graph1 and co.

Hence, I just don't see the problem with what IBM, or anyone else, is doing.

As far as I can see, the mechanism with being able to selectively ignore parts of the Graph Store protocol, flagged via the service description is a bit unwieldy, and completely unnecessary.

> Also, what about the points below…?

I agree with those.

- 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 22:29:43 UTC