Re: please wait on Graphstore Protocol

Sandro,

Could you please point to or quote the relevant parts of specs?  (e.g. 
RFC 2616, RFC 3986).

On 13/12/11 04:34, Sandro Hawke wrote:
> I understood Arnaud's last point to be about something different than
> what you're responding to.  I think it's about how you write an RDF
> graph that is in some sense self describing (eg with a cc:license
> triple) when the client doesn't know where the server will end up
> publishing it.  I think their solution (a null URI, aka a URI relative
> to where it ends up) is the right one; I'm not sure if it's in scope for
> this spec.

http://www.ietf.org/rfc/rfc3986.txt sec 5.1

They want the base URI to be the URI of the destination.  I don't know 
if there is a precedence for that, it seems mildly at odds with RFC2616
[(5.1.3) URI used to retrieve the entity] as the named entity is the 
container.

As a processing problem, the receiving processor converts the RDF from 
one form to another based on the URI allocated.

(or, in practice, you store the bytes at the new location and it just 
works).

An RDF serialization is absolute URIs - anything else if processing the RDF.

> I don't quite understand the question.   In general, people should
> comment as early as they can, but definitely before LC if they are in
> the WG (as I'm doing now), and before CR if they are not in the WG.  Or
> before the end of CR, if it's about something they learned during
> Implementation.  If they don't comment by those deadlines, they are on
> somewhat lower moral ground to complain, but if their suggestion is
> good, we probably should still pay attention.
>
> I gather the solution written up in the Dec 6th article has been running
> in some IBM products for a long time, maybe years, but I don't really
> see how who-came-first matters.  The main point is we all want to make
> the spec as good as it can be given our limited time and resources.
>
> On the point at hand, I believe there is an architectural problem with
> the POST-to-Graph=APPEND rule.   In the general case, I believe it makes
> sense to consider a Graph URI as potentially identifying any Resource
> which has state which the system can encode to and/or decode from an RDF
> Graph.  So, the backend doesn't have to be a general purpose RDF store;
> it can be a specific application (as in the IBM paper), which provides
> an RDF *view* of its internal structures.    So the "Graph" might be
> almost any kind of OO-style Object, mapped to/from RDF.
>
> The problem with POST=APPEND is that I think we also want to be able to
> use POST to pass messages to (or invoke methods on) those objects.

In the graph store protocol, this applies to

1/ POST to an existing graph appending triples

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
point 4.

"Extending a database through an append operation."

2/ POST to an explicitly named, but not existing, graph

Their case is POST to a container (= grpah store) where the graph store 
allocates a server-rooted URI and returnes in in Location:.



If, in their language there is a POST to Basic Profile *Resource* which 
is not a Basic Profile *Container*, the doc does not say what happens.

"""
Basic Profile Resources use RDF to define their state.
"""

We also have POST to a graph store URI which is container-like:

"""
New resources are created in Basic Profile Containers by POSTing to them.
After POSTing a new resource to a Container, the new resource will 
appear as a member of the Container until it is deleted
"""

Sando - what do you think the container is in the graph store protocol?

> For example, if there's an RDF+REST view of a test case, maintained by
> some enterprise test case management system, it makes sense to GET and
> PATCH the state of the test case, but it also might make sense to invoke
> operations which perform analysis or even run the test against some
> identified service.   Since we can do APPEND with PATCH, I don't think
> we should close the door to method invocation / message passing by also
> devoting POST to that.

I don't think we are defining anything - more clarifying the way RFC 
2616 verbs are used with graph stores (and that clarification is very 
helpful and well worth doing).

RFC 2616 sec 9.5 bullet 3:
POST
       - Annotation of existing resources;

       - Posting a message to a bulletin board, newsgroup, mailing list,
         or similar group of articles;

       - Providing a block of data, such as the result of submitting a
         form, to a data-handling process;

       - Extending a database through an append operation.

All the graph store protocol document says is that POST to an existing 
graph is append.  I.e. a graph is a resource and is not a general 
data-handling process.

I don't see any definition of POST to Basic Profile *Resource* in the 
IBM document.

"""
Basic Profile Resources are created by HTTP POST (or PUT) to an existing 
resource,
"""
the existing resource is the container.

although PUT to an existing URI creating a different URI-named resource 
is not my reading of RFC 2616.

"""
  The PUT method requests that the enclosed entity be stored under the
    supplied Request-URI.
"""

'under' is clarified a little later on:

"""
The fundamental difference between the POST and PUT requests is
    reflected in the different meaning of the Request-URI. The URI in a
    POST request identifies the resource that will handle the enclosed
    entity. That resource might be a data-accepting process, a gateway to
    some other protocol, or a separate entity that accepts annotations.
    In contrast, the URI in a PUT request identifies the entity enclosed
    with the request -- the user agent knows what URI is intended and the
    server MUST NOT attempt to apply the request to some other resource.
"""

>
> (Yes, we could open another door by POSTing with a non-RDF media type,
> but I certainly don't want to drive people to either (1) making
> duplicate media types or (2) not using RDF.)
>
> Does that make sense?   This didn't occur to me in my review; it wasn't
> until I learned, last week, how IBM was doing RDF+REST access to data
> which was not in a GraphStore.
>
>> It could also be (straight-forwardly) argued that using POST to
>> directly create an addressable resource is at odds with the semantics
>> of the verbs.
>
> I think they're talking about POST to the collection (aka GraphStore)
> URI (as in our current draft), not POST to the graph URIs.  For directly
> creating an addressable resource, I think everyone would agree to use
> PUT.
>
>>>> It's pretty much my top
>>>> priority -- I hope to have a proposal in the next day or two.
>> I look forward to that
>
> Well, what I said above was probably the most interesting bit.
>
>      -- Sandro

That's my reading of the situation - the IBM basic profile
is a use of REST-style interaction with the usual meaning of actions. 
It distinguishes "container" and the action of POST;  "resources" are 
general descriptions viewable as RDF.

 Andy

Received on Tuesday, 13 December 2011 10:26:34 UTC