Re: next steps on http graph store protocol

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?

> 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 Monday, 9 January 2012 23:58:09 UTC