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

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.

Regards,
Dave

> 
> 
>

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