Re: next steps on http graph store protocol

On 9 Jan 2012, at 23:55, Sandro Hawke wrote:

> On Mon, 2012-01-09 at 22:26 +0000, Steve Harris wrote:
>> 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.
> 
> It's not the lexical similarity that makes me think they should be
> governed by the same protocol document, it's that similarity in the
> protocol.   For both graph1 and magicCollectionThing, everything in the
> protocol is the same except the behavior on POST.   GET, PUT, DELETE,
> and PATCH, for RDF content types, all the same.   They just different in
> how they handle POST of RDF.  So, (1) it seems odd to have two W3C
> Recommendations that differ in only one small part, and (2) I'd think it
> would cause lots of market confusion, as people didn't understand which
> of those documents they were supposed to be using.   Especially since
> the second one doesn't exist yet, and the first one doesn't acknowledge
> that the second one might, someday.  So as people try to do the second
> one, many people will be unhappy, I predict, that they are, apparently,
> violating the first one.  What I want is for the first one to admit the
> possibility of the second one, explicitly.
> 
> It reminds me a bit of what you and I were talking about with techniques
> for avoid the overhead of 303 redirection.  If the HTTP specs were
> written with a little more awareness of this possibility, we'd be fine,
> but as they are, it's hard to know what's in conformance with spec
> and/or with software built from the spec.   If GSHP says POST always
> means Merge, then people are going be in a very awkward place when they
> try to say that doesn't apply to them.
> 
>> Hence, I just don't see the problem with what IBM, or anyone else, is doing.
> 
> You, personally, may not.  But if the spec gets written to say POST of
> RDF always means MERGE, then what text are they going to point to which
> allows them to use POST of RDF to mean something else?

Whatever they point to now?

Anyway - I'm not really that bothered, I just think it's an unnecessary complexity.

- Steve

>> 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.
> 
> I'm not proposing anything using Service Description.   I'm proposing we
> just say there is a class of resources for which POST means MERGE, and
> I'm happy with giving that class a URI.   If people want to use that
> class URI in SPARQL Service Descriptions, or in POWDER declarations, or
> in other metadata, that's up to them.   I do not think we should mandate
> such declarations be present in any particular context, in part since I
> don't think we are mandating any other kind of metadata for GraphStores,
> and we haven't provided any way to find metadata.   (Two already exist,
> of course, that I know of: Link headers and POWDER.)
> 
>>> Also, what about the points below…?
>> 
>> I agree with those.
> 
> Excellent.
> 
>   - s
> 
>> - 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 Tuesday, 10 January 2012 00:27:12 UTC