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

> 
> I agree too, i.e. Steve's suggestion which covers the basics. 
> 
> The way I see it at the moment, the current round of LDP will define such basics. Then in extensions and future work, we can do Containers, hyperRDF, services, etc, etc .. This might mean an "LDP for real containers", which would define the additions making explicit the recursive deletion semantics, etc. 
> 
> I really liked the "value-set" terminology which we talked about at the F2F and Richard describes at [1]. Personally, I think we should be using this value-set terminology, and reserve the word "container" for where the additional semantics are involved. 

[1] http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Richard%27s_LDP_101

> 
> Roger
> 
> 
> On 19 Apr 2013, at 18:52, David Wood wrote:
> 
>> +1 to resolving this the first way (per Steve's suggestion).
>> 
>> Regards,
>> Dave
>> --
>> http://about.me/david_wood
>> 
>> 
>> 
>> On Apr 19, 2013, at 12: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. 
>>> 
>>> 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
>> 
>