Re: next steps on http graph store protocol

>>>>>> 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?
>
> I was speaking loosely, sorry.

Sandro introduced the term:

[[ Sandro wrote:
I don't understand what you're proposing folks should do who want
subdirectories in their Graph Store.
]]

I can guess what the intention is (containers in container) but it puts 
it way outside the graph store protocol.  It's why I think we should 
leave the space open to the next WG not guess now.

Atom Pub Protocol does not allow for creation of containers by protocol 
either.

I've built a non-SPARQL backed graph store protocol impl based the IBM 
doc (which isn't complete when you get into the details of the protocol) 
and Atom and things of that kind, and it does not need to have 
containers-in-containers.  Names in containers can contain "/".

	Andy

>
>> Is it a "Graph Store" - i.e. a SPARQL concept or soemthing else?
>
> Well, as far as I can tell from Sandro's description it's a mixture of things.
>
> Some URIs form (part of) a Graph Store, but others have system-specific behaviour. I thnk this is a pretty common situation, and personally I don't feel that it requires additional text.
>
>>>>>> 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.
>
> Right.
>
>>>>> 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.
>
> Exactly.
>
> - Steve
>
>>> 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 10:19:30 UTC