W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

Re: Proposed wording to clarify that POST behavior in GSHP is only for RDF graph content

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 19 Dec 2011 21:00:00 -0500
To: Chime Ogbuji <chimezie@gmail.com>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <1324346400.6252.1597.camel@waldron>
On Mon, 2011-12-19 at 16:09 -0500, Chime Ogbuji wrote:
> So, per our conversation in today's teleconference regarding the graph store protocol, below is suggested text that would go into section 5.5 (HTTP Post) of the editor's draft immediately after the second pair of HTTP message and SPARQL Update examples for the POST = append scenario and right before the paragraph beginning "As mentioned earlier..":
> 
> "Note that this behavior is only sanctioned for HTTP POST requests where the request URI identifies RDF graph content. Implementations of this protocol can interpret HTTP POST requests to other kinds of information resources in a manner that still provides a uniform method to cover the functions indicated in [RFC2616] (section 9.5 POST) but that is more appropriate for the kind of resource being targeted"
> 
> In addition, we also tentatively agreed to change the first sentence in that section from "A request that uses the HTTP POST method SHOULD [..]" to "A request that uses the HTTP POST method MUST [..]"
> 

Sorry, but "where the request URI identifies RDF graph content" does not
make it clear enough which resources this rule applies to. 

If I had a graphstore that implemented my strawman collections interface
or Eric's strawman trouble ticket interface, I would feel on *very* weak
ground (really, no ground) pointing to this text and saying "no, really,
I'm not violating the spec".   

The definition in this spec of "RDF graph content" is:

        An information resource identified by the graph IRI of a named
        graph and managed by a server that implements this protocol or
        identified by an indirect operation on the default graph.
        
and I think that's what I'd have in my collections interface.  In my
strawman, everything looks just a "normal" graphstore, except some of
the "graphs" are collections, and you can POST to them to make new
resources in those collections (as per typical REST behavior).  I'm not
okay with this spec ruling out such systems.

So, here's a minimal change that handles that:

        Note that this behavior is only sanctioned for HTTP POST
        requests where the request URI identifies only RDF graph
        content, with no special semantics or behavior.  Implementations
        of this protocol MAY interpret HTTP POST requests to other kinds
        of information resources in a manner that still provides a
        uniform method to cover the functions indicated in [RFC2616]
        (section 9.5 POST) but that is more appropriate for the kind of
        resource being targeted.

Given that we still haven't even talked about my other points, or closed
the loop with Arnaud, I'm thinking we should keep working on this
document, and not try to make the Last Call decision tomorrow.

    -- Sandro
Received on Tuesday, 20 December 2011 02:00:11 GMT

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