W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-35 (fresh-URI): POSTing to a container MUST yield a fresh URI [Linked Data Platform core]

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Tue, 6 Nov 2012 12:41:56 +0000
CC: Richard Cyganiak <richard.cyganiak@deri.org>
Message-ID: <880B7161-58E5-4615-A346-C0A15A2E96C9@uk.fujitsu.com>
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>

Would like to make a related point to this issue: we have used resource creation for management of lifecycle management (for example management of a virtual machine), and in the case where changes are non-instantaneous we reply to the create with a 202, later moving to a 201.

thanks, 
Roger

On 6 Nov 2012, at 09:23, Linked Data Platform (LDP) Working Group Issue Tracker wrote:

> ldp-ISSUE-35 (fresh-URI): POSTing to a container MUST yield a fresh URI [Linked Data Platform core]
> 
> http://www.w3.org/2012/ldp/track/issues/35
> 
> Raised by: Richard Cyganiak
> On product: Linked Data Platform core
> 
> Section 5.4 talks about the new URIs that are generated when POSTing to a container:
> 
> [[
> LDPC servers must respond with status code 201 (Created) and the Location header set to the new resource’s URL.
> 
> LDPC servers should assign the subject URI for the resource to be created using server application specific rules.
> ]]
> 
> This says that the resource is new, and therefore sort of implies that the URI has to be new too. But the sentence about “server-specific rules” seems to give lots of wiggle-room However, I think there should be a much stronger statement, along these lines:
> 
> [[
> Once a URI has been assigned to a new resource (as indicated by the 201 response code and Location: header), then the same URI MUST NOT be assigned again in any subsequent request.
> ]]
> 
> This is to avoid a situation where a resource is assigned a “recycled” URI that was previously assigned to a different resource and then deleted or moved or whatever, as discussed by TimBL and others in the ISSUE-24 discussion at the F2F.
> 
> 
> 



Received on Tuesday, 6 November 2012 12:42:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC