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

* Steve Battle <steve.battle@sysemia.co.uk> [2012-10-18 14:05+0100]
> > -----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."

I'm tempted to turn up the guidance a little, though the current "Cool URIs
Don't Change" document¹ is more provocative than is typically referenced in
a Rec. It's also more likely to be read as "don't move X to Y" than "don't
change X's meaning (by deletions and creations)". Given that, we can add an
informative sentence about the dangers of changing meaning:

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.
+ . The service SHOULD NOT permit the creation of a different resource with
+ the same Request-URI. Note that replacing a resource in this fashion
+ potentially misinforms the users of that resource and undermines the
+ stability of the data.

¹ http://www.w3.org/Provider/Style/URI.html

I'm also partial to Steve's "when hell freezes over" proposal, but
think it needs to be sketched out a bit more thoroughly before we
vote on it.


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

IMO, Atom is offering a peek into a relatively arbitrary part of the
access log of a resource. Deletions are pretty interesting, as are
creations and modifications. (Gets are rarely interesting unless you
want to see who knew what when.) If we go down this road, I think it
should be an auxiliary spec which doesn't impede the progress of the
basic profile.


> > Best,
> > 
> > Ruben
> 
> Steve.
> 
> 

-- 
-ericP

Received on Sunday, 21 October 2012 14:30:21 UTC