Re: next steps on http graph store protocol

On 10/01/12 15:06, Sandro Hawke wrote:
> On Tue, 2012-01-10 at 14:38 +0000, Andy Seaborne wrote:
>>
>> On 10/01/12 14:12, Sandro Hawke wrote:
>>> On Tue, 2012-01-10 at 13:47 +0000, Steve Harris wrote:
>>>> On 2012-01-10, at 13:24, Sandro Hawke wrote:
>>>> …
>>>>
>>>>> It sounds like where we actually disagree is about the scope of
>>>>> applicability of this spec.
>>>>
>>>> Yes.
>>>>
>>>>> If I understand how you're approaching the situation, maybe you'd be
>>>>> okay with the following text in Graph Store HTTP Protocol.   This text
>>>>> would probably go in the introduction, with its first sentence in the
>>>>> abstract:
>>>>>
>>>>>          This protocol is only one of many possible HTTP (REST) protocols
>>>>>          one could use involving RDF payloads and RDF Graph Resources.
>>>>>          This specification only applies to one particular sort of RDF
>>>>>          graph storage system, the sort for which these operations are
>>>>>          the appropriate ones.  In contrast, for example, if one wanted a
>>>>>          Graph Store which also included some service components, where
>>>>>          POST was used to invoke operations, one would need to use a
>>>>>          different Graph Store HTTP Protocol and the constraints of this
>>>>>          document would not apply.
>>>>
>>>> Seems tautological to me, but as you disagree it's clearly not.
>>>>
>>>> If you have a Graph Store - use the Graph Store Protocol. If you don't have a Graph Store (e.g. IBM) then use something else. Seems self evident.
>>>>
>>>> In other words, I'd be OK with the quoted text above, though I'm not sure "one would need to use a different Graph Store HTTP Protocol" makes sense, as the thing in question wouldn't be a Graph Store, by definition would it?
>>>
>>> It wouldn't be a "SPARQL 1.1 Graph Store", true.   I think these future
>>> RDF graph storage systems that also provide some services ought to be
>>> able to call themselves "graph stores" and/or "Graph Stores".    Perhaps
>>> we could use a phrase like, "in this document, the term 'Graph Store'
>>> means a SPARQL 1.1 Graph Store", and that would suffice.
>>
>> We already formally define Graph Store (in update section 4.1.1).  I
>> think that, plus the first line of the intro, plus the title is quite
>> clear.  (Can we make the Graph Store in the intro a link please?)
>>
>> Bringing in an undefined concept "RDF Graph Resources" is confusing.
>>
>> We do agree on "POST was used to invoke operations" (except the 'was' as
>> it's really speculative future!).  It is invoke operations; services
>> react to messages.
>
> So you agree with the meaning of my proposed text, you just don't want
> it there because (like Steve) you think it's redundant?
>
> To me, the first sentence of the abstract:
>
>          This document describes the use of HTTP operations for the
>          purpose of managing a collection of RDF graphs in the REST
>          architectural style.
>
> ... has an obvious reading, for a W3C Recommendation, which is that this
> spec is *the* recommended way to RESTfully manage a collection of RDF
> graphs.

Maybe, and I'm happy to refine the text.

It says "managing" so adding, removing and doing the usual things for 
GET/PUT/DELETE on a graph (container) follows from managing.  Ordering a 
book by using POST as a service invocation on a shopping basket falls 
under RFC 2616

"
  - Providing a block of data, such as the result of submitting a
         form, to a data-handling process;
"
and isn't "managing" to me.

A *lot* of people will argue it's not RESTful as well but let's leave 
that for another time :-)

 Andy

>
>     - Sandro
>
>>>
>>>       -s
>>>
>>>
>>>> - Steve
>>>>
>>>
>>>
>>>
>>
>>
>
>

Received on Tuesday, 10 January 2012 16:20:12 UTC