W3C home > Mailing lists > Public > public-ldp-wg@w3.org > April 2013

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

From: David Wood <david@3roundstones.com>
Date: Fri, 19 Apr 2013 13:52:51 -0400
Cc: public-ldp-wg@w3.org
Message-Id: <24E4B757-F11E-4CE3-9691-8E2F75FC70F6@3roundstones.com>
To: Arnaud Le Hors <lehors@us.ibm.com>
+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




Received on Friday, 19 April 2013 17:53:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:46 UTC