W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2012

Re: next steps on http graph store protocol

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 10 Jan 2012 08:43:45 +0000
Message-ID: <4F0BFA41.5020000@epimorphics.com>
To: public-rdf-dawg@w3.org


On 10/01/12 00:26, Steve Harris wrote:
> 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.

What is a subdirectory of a graph store?

Is it a "Graph Store" - i.e. a SPARQL concept or soemthing else?


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


Atom Publishing Protocol
http://tools.ietf.org/html/rfc5023#page-11

The return from the POST contains a Location: header.  The graph store 
protocol is the same.

>>>> 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 also http://foo.example/a/b/c/graph2

because to the Graph Store protocol the use of "/" is irrelevant.

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

That is because RFC 2616 defines GET, PUT, DELETE, HEAD semantics and 
they apply more widely than SPARQL, RDF or semantic web.

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

For anything else, I think we should leave it open to another working 
group and not try to second guess.  They have to, e.g. work on the 
relationship to the Atom Publishing protocol, the world of JSON linking, 
embedded RDF content.

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

... when the content type of the destination is a graph container.

Any other use of POST and especially any use of POST where the content 
of the POST influences the action performed, is a service.

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

+1

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

POST to a graph container means merge;

POST to a graph store means add new graph continer;

POST of RDF content in the POST body to something is a service.

> Whatever they point to now?
>
> Anyway - I'm not really that bothered, I just think it's an unnecessary complexity.
>
> - Steve
>

	Andy


>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
Received on Tuesday, 10 January 2012 08:44:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:47 GMT