Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

On 19 Mar 2013, at 15:51, Steve Speicher <sspeiche@gmail.com> wrote:

> On Tue, Mar 19, 2013 at 10:24 AM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 19 Mar 2013, at 13:10, Linked Data Platform (LDP) Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>> 
>>> ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]
>>> 
>>> http://www.w3.org/2012/ldp/track/issues/59
>>> 
>>> Raised by: Steve Speicher
>>> On product: Linked Data Platform core
>>> 
>>> The origins of the need for concepts of Aggregate and Composite type containers was from the desire to be able to have predictable delete behavior, instead of leaving it unspecified and therefore implementation dependent (see ISSUE-34).   As the editors have made the changes for these concepts, feedback from the editors and WG members is that they terminology and concepts add confusion for the simple needs for clear delete semantics.   Instead, having a simple resource and container model is preferred.  Then having a delete model that meets the recursive needs is desired.
>>> 
>>> Proposal:
>>> a) Remove the concepts of AggregateContainer and CompositeContainer. Leaving the only kind of container to be ldp:Container
>>> b) Have DELETE on a container only delete the container itself, not its members.  Introduce a "recursive delete" mechanism, that deletes the container and issues a DELETE on all its members (if the members are also containers, it recurses the delete).  The server may not be able to successfully delete the members but will at least attempt the DELETE.  It would seem unreasonable for the errors on deletion of members to be composed into a error report in that it would be infrequently used and come at a cost to produce.  Clients that need to know, could know based on some condition or minimal error response, then attempting to access member resources.
>>> 
>>> There are a number of ways that (b) can be solved that don't require a new rdfs:Class to be introduced.  For example, since introducing a new HTTP verb is probably too heavyweight, it might be ideal to expose a "recursive delete" URL that a client can find (either in RDF or header) that a DELETE on this URL will invoke the recursive behavior.
>> 
>> Whatever you do you'll need to help the client distinguish those resource that he can delete
>> from those the server has no control over. So you'd need at least the following:
>> 
>> <> a ldp:Container;
>>   ldp:contains <entry1>;
>>   rdfs:member <http://some.other.server/another/resource> .
>> 
> 
> This is not in line with what I was proposing, a regular-DELETE would
> remove just the container (both the triples of members and
> non-members).  In the case of recursive-DELETE, it would do the same
> as regular-DELETE and issue a recursive-DELETE on each container
> member object URL.

currently there is no way of knowing which members are contained objects
that could be deleted if the container were deleted and which one are
not.

>  Or are you saying you want some way to distinguish
> which container members it thinks it can delete based on current user
> credentials?  Seems like this should be deferred to discovery of some
> ACL capability, which may be out of scope for 1.0

I was not thinking about this. But it is interesting. The current
setup leads to the conclusion that outer containers have more rights
than inner ones, since outer containers can delete inner ones.

In a way that makes sense. If I have a namespace that I own, I can
give you access to subnamespaces beneath it. Just as Facebook can give
users accounts such as http://facebook.com/bblfish. That container is
dependent on the outer container. 


Henry


> 
>>> 
>>> 
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> 
> -- 
> - Steve

Social Web Architect
http://bblfish.net/