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

> -----Original Message-----
> From: Ruben Verborgh [mailto:ruben.verborgh@ugent.be]
> Sent: 15 October 2012 16:19
> To: David Wood
> Cc: Linked Data Platform (LDP) Working Group
> Subject: Re: ldp-ISSUE-24 (remain deleted): Should DELETED resources
> remain deleted? [Linked Data Platform core]
> 
> Hi all,
> 
> Let me clarify my concerns in Issue 24, based on David's questions.
> 
> >> 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 fully agree here.
> My issue is that the spec seems to suggest *not* to use Cool URIs, why in
> fact, I don't think we should make any suggestion in any direction
> whatsoever.

Is there a downside to including references to known best practice in the
area? Could we not add something like:
"It is recommended that best practices on the use of Cool URIs [ref] are
followed."

> Specifically, the word "another" is a problem. 
> Therefore, I suggest changing the final subclause to "until a subsequent
> action associates a resource with the Request-URI."
> This leaves open whether this resource should be the same or different.

I still think that the use of 'until' introduces ambiguity. It doesn't
really say anything about whether the event following 'until' is really
expected to happen. 
Compare "until next week" and "until hell freezes over". 
And if there were no subsequent action to associate a resource with the
Request-URI, is that because my application rejected all attempts to do so?
This scenario is consistent with the spec.

> > 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.

Yes - I agree that it should be left open to the application whether or not
they allow URI re-use, regardless of whether they are cool or un-cool.

> Yes, but the spec should leave open what those are.
> I think we should recommend against reusing URIs for different resource
> though, but not enforce it.

I think the current spec is unintentionally(?) open.
As a reader I'd rather not have to read between the lines to discover this.
I'd rather make it explicit.

"It is open to the application to implement its own URI management policy
with regard to URI re-use."

In particular, it would be interesting to make use of Atom's resource
'tombstone' metadata <http://www.rfc-editor.org/rfc/rfc6721.txt> so we can
still describe 'DELETED' resources in RDF.

> 
> Best,
> 
> Ruben

Steve.

Received on Thursday, 18 October 2012 13:06:03 UTC