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

Re: ldp-ISSUE-24 (remain deleted): Should DELETED resources remain deleted? [Linked Data Platform core]

From: David Wood <david@3roundstones.com>
Date: Mon, 15 Oct 2012 10:00:09 -0400
Message-Id: <B094301C-B34B-4430-A3BA-02AE746CF019@3roundstones.com>
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
To: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Hi all,

I promised myself that I wouldn't get too involved in LDP until the RDF WG wound down, but it seems I can't help myself :)

On Oct 15, 2012, at 9:45, Linked Data Platform (LDP) Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> ldp-ISSUE-24 (remain deleted): Should DELETED resources remain deleted? [Linked Data Platform core]
> http://www.w3.org/2012/ldp/track/issues/24
> Raised by: Ruben Verborgh
> On product: Linked Data Platform core
> Under 4.5 DELETE, the draft currently reads:
> 4.5.1 BPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 (Gone) status code, until another resource is created or associated with the same Request-URI.
> Isn't the creation of another resource in contradiction with Cool URIs?

Yes, but that is guidance, not a standard.  My two cents is that LDP should encourage ("SHOULD") Cool URIs but not demand them (via "MUST"). 

> I see two cases:
> 1. the resource is permanently gone, which should result in a 410 and it should *not* be possible to create a resource again on this URI. Otherwise, the Cool URI principle would be broken.
> 2. the resource is temporarily gone, which results in a 404. It should *not* be possible to create another resource on this URI, only to re-upload the same resource here (the contents of which may have changed in the meantime, but it should still be the same resource).
> This raises two additional issues:
> - how does the server know the DELETE is permanent?
> - how does the server know the resource is the same or different?

These are decisions the server would need to make based on its own URI management policies, not something it can decide based on the content of the DELETE message itself.

In general, I support compliance with Cool URIs unless there is a good reason not to do so.  Some server side strategy for persistent URIs such as the PURLs concept could be used to manage Cool URIs over time.  Callimachus now supports PURLs as a built-in resource type to facilitate this.


Received on Monday, 15 October 2012 14:00:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC