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

On 29 Apr 2013, at 13:50, Sergio Fernández <sergio.fernandez@salzburgresearch.at> wrote:

> Hi,
> 
> Personally I don not like Option C, as we discussed several times. Besides Option B FMPOV basically moves to the properties interpretation the problem of having two type of containers.
> 
> Therefore, I prefer Option A, but behaving recursive by default. For example, a valid interpretation for a hypothetical implementation could be something like:
> 
>    DELETE requests to LDPC remove all members (both LDPR and LDPC)
>    that bellows to the container (i.e., same base URI, even URI
>    templates or whatever), keeping reference to those externals
>    not directly managed by the container.
> 
> I can see this working for many uses cases. So for my let's got to Option A amending the 3rd point, and move forward.

I think that is what we had agreed to at TPAC1.

Btw, AggregationContainement was added because of ISSUE-34 
http://www.w3.org/2012/ldp/track/issues/34

[[
LDPCs provide a way of managing groups of resources with composition semantics. But it is unclear how to do the same for groups of resources with simple aggregation semantics.

Many resources in a graph have lots of in- or outlinks with the same property: a person's friends, an author's publications, a company's employees, a class's members, a geographical area's contained entities, and so on. This is simple “weak” aggregation—we merely have lots of resources connected to one other via the same property from a domain vocabulary, with no additional LDP-related semantics.

If a node has many arcs, the representation can become way too large, so that PUT becomes impractical as a means of adding and removing arcs from the resource. However, the ability to handle graphs with such resources seems quite important. ISSUE-33 (paging) is one piece of this. How to add and remove arcs is another one.

PATCH, if supported, may be one answer to this; but only if a patch format is specified.

Something that allows adding and removing arcs via POST might be another answer.
]]

I don't think it was ever made clear how this aggregation works in fact. From what is being proposed here it looks like
aggregation never solved issue 34.


> 
> Kind regards,
> 
> 
> On 26/04/13 22:58, Arnaud Le Hors wrote:
>> Hi all,
>> 
>> Last week I tried to get us to a resolution on this issue but we didn't
>> quite get to it. I'd like to try again. We actually have 3 different ways
>> to do so:
>> 
>> ** Option A: 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.
>> -------------
>> 
>> ** Option B: 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.
>> -------------
>> 
>> ** Option C: Leave the spec as it currently stands, keeping the two types
>> of container: AggregateContainer and CompositeContainter
>> 
>> 
>> Note that as it was pointed out last week, both options B&  C mean doing
>> more work because each of this option raise their own set of additional
>> issues we will need to resolve. Off the top of my head, this includes what
>> it means to "move" a contained resource from one container to another in
>> option B, and whether a container can be changed from one type to the
>> other in option C.
>> 
>> Thanks.
>> --
>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>> 
> 
> -- 
> Sergio Fernández
> Salzburg Research
> +43 662 2288 318
> Jakob-Haringer Strasse 5/II
> A-5020 Salzburg (Austria)
> http://www.salzburgresearch.at
> 

Social Web Architect
http://bblfish.net/