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

On 21/10/12 15:29, Eric Prud'hommeaux wrote:
> * 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.

I think the guidance should be made a general text, not specific to the 
method - it applies to PUTting replacement data to a URI just as much as 
DELETE+later PUT.

The guidance needs to be carefully worded - it gets interesting around 
making revisions/corrections for mistakes, and for time-varying 
resources like today's weather forecast.

 Andy

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

Received on Monday, 22 October 2012 09:02:17 UTC