Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

On 19 Apr 2013, at 18:22, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi all, 
> I would really like us get over that one sooner rather than later so based on the previous discussions and what I've heard from everyone I'd like to make the following proposal to close issue-59: 
> 
> Close Issue-59 per Steve's suggestion (see http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html ): 
> 
> 1. remove the two types of container AggregateContainer and CompositeContainter, leaving the only kind of container to be ldp:Container 
> 
> 2. specify that on deleting a container LDP servers MUST delete the container and MAY delete member resources (typically to satisfy internal requirements). 
> 
> So if I have: 
> 
> <> a ldp:Container; 
>    rdfs:member <a>. 
> 
> and I create <b> using POST to the container, I end up with: 
> 
> <> a ldp:Container; 
>    rdfs:member <a>, <b>. 
> 
> When I delete the container, the container gets deleted, and <a> and <b> MAY get deleted. 
> 
> 3. Defer adding an operation that let's a client request a recursive delete to a future version of LDP, and do one of the following: 
> ------------- 
> 
> If people can't live with the uncertainty regarding the delete behavior we could go with the following alternative, inspired by Henry's proposal around ldp:contains: 
> 
> 1. remove the two types of container AggregateContainer and CompositeContainter, leaving the only kind of container to be ldp:Container 
> 
> 2. add that on creating a new member resource using POST, LDP servers SHOULD add a triple a la : <> ldp:contains <newly_created_resource> if the resource will be deleted when the container is deleted. Note that this is in addition to adding the appropriate ldp:membershipPredicate or ldp:membershipPredicateInverse triple to the container representation as currently required. 
> 
> 3. specify that on deleting a container LDP servers MUST delete the container and member resources listed as contained via ldp:contains, and MAY delete other member resources (typically to satisfy internal requirements). 
> 
> So if I have: 
> 
> <> a ldp:Container; 
>    rdfs:member <a>. 
> 
> and I create <b> using POST to the container, I end up with: 
> 
> <> a ldp:Container; 
>    rdfs:member <a>, <b>; 
>    ldp:contains <b>. 
> 
> When I delete the container, both the container and <b> get deleted. <a> MAY be deleted. 

I think we need the ldp:conains because that is the only way to be consistent with our resolution at 
our first TPAC meeting that deleting a container would delete its contents.

Btw, there would be no need for repetition of the ldp:contains and rdfs:member relations if one just
adds to the ontology 

ldp:contains rdfs:subPropertyOf rdfs:member .

> <> a ldp:Container; 
>    rdfs:member <a>; 
>    ldp:contains <b>.


which is more elegant.

> 
> 4. Defer adding an operation that let's a client request a recursive delete to a future version of LDP, and do one of the following: 
> ------------- 
> 
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Social Web Architect
http://bblfish.net/