Re: Questions and comments on SPARQL 1.1 Graph Store HTTP Protocol draft

On 24/12/11 13:14, Sandro Hawke wrote:
> On Thu, 2011-12-22 at 16:44 +0000, Andy Seaborne wrote:
>> Re-directed to the working group list.
>>
>> On 22/12/11 16:01, Sandro Hawke wrote:
>>>>> One convention we have adopted is to use the null relative URL (<>   in
>>>>> Turtle, or "" in RDF/XML). I'd like to know whether there is a standard
>>>>> way of doing this. Maybe the spec should indicate one.
>>>>>
>>>>
>>>>
>>>> This would require a base URI resolution mechanism that would (in the end) simply resolve this to the request-URI (per base URI resolution rules). The WG has decided to not support a base URI resolution mechanism for this specification. So, without a discovery mechanism the only way to perform this "append" behavior is to know the URI of the Graph Store before hand and to POST to it directly.
>>>
>>> So the suggested workaround is to POST to the graphstore to get a new
>>> URL allocated, then PUT your graph to that new address.   And your
>>> understanding is that the technique Arnaud is suggesting -- defining the
>>> base URI as the URI that is allocated to hold the content -- could be
>>> standardized in the future?
>>
>> Sandro,
>>
>> By your reading, does RFC 3986 "5.1.  Establishing a Base URI" and RFC
>> 2616 defining a request URI apply here?
>>
>> If so, doesn't that say what the base URI is?
>> If not, why don't these RFCs apply?
>
> Sorry, I know you asked this earlier, and in the crush of events I lost
> track of it.
>
> As I read RFC 3986 section 5.1, it doesn't constrain the base URI for
> the content of a POST.  So it falls back to the outer-ring, in that
> diagram, of being application dependent.  That seems right to me -- in
> this case, the application is whichever POST semantics the given
> resource implements.  For POSTing to the graphstore itself (but not the
> elements inside it), I believe we can specify the protocol for POST, and
> saying how it handles relative URIs in RDF syntaxes seems to me like a
> reasonable part of that.

[[
  (5.1.2) Base URI of the encapsulating entity
          (message, representation, or none)
]]
the encapsulating entity is the HTTP request.

Even then:
[[
  (5.1.3) URI used to retrieve the entity
]]
and "retrieve" can be read as a bias to GET. GET and PUT are a pair.

There is nothing operation specific mentioned except a bias to 
"retrieve" so if it applies to PUT, it applies to POST.

Test case:

----------------------
PUT http://example/foo/bar
Content-type: text/turtle;charset=utf-8

@prefix : <#> .

<> :p 123 .
----------------------

What triple is that?

GET http://example/foo/bar
==>
----------------------
Content-type: text/turtle;charset=utf-8

@prefix : <#> .

<> :p 123 .
----------------------
What triple is that?

This is not what would we might like for the answer but what the specs 
say. I agree it would be nice if container-add could have a base of the 
"Location" but I don't think is what the RFCs say.

We can test this by looking at other (non-RDF) deployed usages.

minor - so how to refer to the container?
"Location" does not have  <..../container/newthing_1>; it can be any URI.

> I don't see anything in 2616 that directly bears on this; perhaps I'm
> missing something.

It defines the request URI.

> The biggest stretch, I think, is how to talk about what is being
> serialized in a POST.   Strictly speaking, it's not an RDF graph, since
> it has relative URIs.  Logically, it's some kind of "relative RDF
> graph", but that's not in the current RDF specs.   My sense is that
> while it's not perfect, it would be acceptable for whatever spec says
> this relative-URIs-in-POSTing is okay to also define this variation on
> RDF graphs.

This is the part that would not worry me - the representation uses 
relative URIs, but they are just a shorthand.  There is a base.

> An alternative would be to define some well-known URI to use as the base
> (eg "http://www.w3.org/2011/move-during-post/"), and the POST-handler
> can rewrite those absolute URIs to new URIs.  But to me that seems less
> attractive than just using relative URIs.

Agreed - in fact for some of the use cases beyond just store-retrieve 
data, then the notion of a process applied to the data makes sense to 
me.  It is not necessarily at odds with REST.  POST to a container could 
be seen as a process action.

 Andy

Received on Saturday, 24 December 2011 16:58:46 UTC