Re: Review of Graph Store Protocol (action 564)

On 06/12/11 00:34, Chime Ogbuji wrote:
> == Comment 13

>> = Related to comment 10
>>
>> Does the discussion about auto-creation of a graph name when
>> POSTing to the dataset URI, also apply to PUT?

> I currently doesn't and I don't think it is applicable due to the
> semantics of PUT. In particular, the use of PUT assumes that the
> enclosed request will be be stored directly using the supplied
> Request-URI.

IM-1 (point 1) requests that multipart applies to PUT and the reply says 
the editors working draft has been changed to permit it.

(I do agree that forms use POST, not PUT though).

>> This is another case where pulling the text out into it's own
>> subsection then mentioning from POTS and PUT would be better.
>>
>> Generally, PUT and POST are the same except PUT replaces and POST
>> appends so in this case both should allocate a new named graph.

> This is not my understanding of the semantics of both operations. PUT
> is an operation on a directly-identified resource while POST is a
> more generic operation and the body is assumed to be a subordinate of
> resource identified by the request.

We can solve this by simply surveying if PUT with multipart/* is 
supported out there.

I can read a multipart/related as being a collection of triples, they 
just happen to be coming from different files, maybe different RDF 
serializations.  It's scatter-gather.

POST, for us, already puts all the triples into one place.

>> What happens with multipart? One graph, all content or severalnew
>> named graphs? I'd expect the latter but I think the doc needs to
>> say so.

> Currently multipart only applies to POST and (in particular) to the
> append scenario. So, it is the equivalent of multiple POST / append
> operations against the same identified RDF graph content.

 Andy

Received on Tuesday, 6 December 2011 08:53:33 UTC