ISSUE-59: Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

recursive-delete

Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

State:
CLOSED
Product:
Linked Data Platform Spec
Raised by:
Steve Speicher
Opened on:
2013-03-19
Description:
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.
Related Actions Items:
Related emails:
  1. LDP Rec (from eric@w3.org on 2015-02-20)
  2. Re: Sandro's various issues (was Re: A simpler way of thinking about containment and membership?) (from lehors@us.ibm.com on 2014-02-20)
  3. Re: ISSUE-71: second bug tracking example (from henry.story@bblfish.net on 2013-05-29)
  4. Re: ISSUE-71: second bug tracking example (from lehors@us.ibm.com on 2013-05-29)
  5. Re: Recommendation for specification edits (from sspeiche@gmail.com on 2013-05-17)
  6. Re: LDP Minutes for April 22 (from johnarwe@us.ibm.com on 2013-04-29)
  7. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2 (from henry.story@bblfish.net on 2013-04-29)
  8. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2 (from sergio.fernandez@salzburgresearch.at on 2013-04-29)
  9. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2 (from kidehen@openlinksw.com on 2013-04-28)
  10. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2 (from ashok.malhotra@oracle.com on 2013-04-27)
  11. Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior - take #2 (from lehors@us.ibm.com on 2013-04-26)
  12. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from henry.story@bblfish.net on 2013-04-20)
  13. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from lehors@us.ibm.com on 2013-04-20)
  14. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from henry.story@bblfish.net on 2013-04-20)
  15. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from roger.menday@uk.fujitsu.com on 2013-04-20)
  16. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from Roger.Menday@uk.fujitsu.com on 2013-04-20)
  17. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from kidehen@openlinksw.com on 2013-04-19)
  18. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from kidehen@openlinksw.com on 2013-04-19)
  19. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from kidehen@openlinksw.com on 2013-04-19)
  20. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from lehors@us.ibm.com on 2013-04-19)
  21. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from cody.burleson@base22.com on 2013-04-19)
  22. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from kidehen@openlinksw.com on 2013-04-19)
  23. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from Erik.Wilde@emc.com on 2013-04-19)
  24. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from sspeiche@gmail.com on 2013-04-19)
  25. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from steve.battle@sysemia.co.uk on 2013-04-19)
  26. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from kidehen@openlinksw.com on 2013-04-19)
  27. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from cody.burleson@base22.com on 2013-04-19)
  28. Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from david@3roundstones.com on 2013-04-19)
  29. Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior (from lehors@us.ibm.com on 2013-04-19)
  30. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from ashok.malhotra@oracle.com on 2013-04-05)
  31. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sspeiche@gmail.com on 2013-04-05)
  32. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from ashok.malhotra@oracle.com on 2013-04-05)
  33. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sspeiche@gmail.com on 2013-04-05)
  34. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from nmihindu@fi.upm.es on 2013-04-05)
  35. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-04-04)
  36. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sspeiche@gmail.com on 2013-04-04)
  37. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from tthibodeau@openlinksw.com on 2013-03-25)
  38. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from andy.seaborne@epimorphics.com on 2013-03-22)
  39. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-22)
  40. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-22)
  41. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-21)
  42. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from lehors@us.ibm.com on 2013-03-21)
  43. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-21)
  44. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-21)
  45. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from andy.seaborne@epimorphics.com on 2013-03-21)
  46. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from lehors@us.ibm.com on 2013-03-21)
  47. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from ashok.malhotra@oracle.com on 2013-03-20)
  48. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-20)
  49. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sspeiche@gmail.com on 2013-03-20)
  50. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-19)
  51. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-19)
  52. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from andy.seaborne@epimorphics.com on 2013-03-19)
  53. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-19)
  54. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from ashok.malhotra@oracle.com on 2013-03-19)
  55. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-19)
  56. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-19)
  57. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from Erik.Wilde@emc.com on 2013-03-19)
  58. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-19)
  59. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sspeiche@gmail.com on 2013-03-19)
  60. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from henry.story@bblfish.net on 2013-03-19)
  61. Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from lehors@us.ibm.com on 2013-03-19)
  62. ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from sysbot+tracker@w3.org on 2013-03-19)

Related notes:

Arnaud's option A

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


option B
---------

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

Ted Thibodeau, 22 Apr 2013, 14:41:15

Resolution: Close issue-59, with option A.
See http://www.w3.org/2013/meeting/ldp/2013-04-29#resolution_5

Arnaud Le Hors, 30 Apr 2013, 15:56:12

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 59.html,v 1.1 2015/08/17 04:43:10 denis Exp $