Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

On 21 Mar 2013, at 16:41, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> "Wilde, Erik" <Erik.Wilde@emc.com> wrote on 03/19/2013 12:05:39 PM:
> > 
> > as a side note, i still think that the simplest solution to all of that is
> > to simply have a concept of linked vs. server-managed content and say that
> > a DELETE on the container DELETEs everything managed in it. if content was
> > POSTed to the server, it will get deleted. if content was linked from a
> > POSTed member, it remains unaffected. in either case, the member (the LDP
> > metadata POSTed to the container) will get deleted if the container is
> > deleted. i still haven't seen any reason why we shouldn't go with the
> > simple semantics.
> 
> 
> Hi Erik, 
> 
> I agree that the model you describe is more regular and simpler. One argument against it though is that it means the externally-managed resource isn't linked directly from the container but via an intermediary server-managed resource - similar to an atom entry. So, you would have something like this, assuming a container with two member resources, lm1 - local/server-managed, m2 - remote/externally-managed. 
> 
> # http://server1.example.org/c 
> <> a ldp:Container;
>   rdf:member <lm1>; 
>    rdf:member <lm2>. 
> 
> <lm1> :title "a local member". 
> <lm2> owl:sameAs <http://server2.example.org/m2>. 

You can avoid this problem by creating an ldp:contains relation 

<> a ldp:Container
   ldp:contains <lm1>;
   rdf:member <lm2> .


> 
> I chose to use owl:sameAs to link to the externally-managed resource but it could be anything else. The point is that it is different from having this: 
> 
> <> a ldp:Container;
>   rdf:member <lm1>; 
>    rdf:member <http://server2.example.org/m2>. 
> 
> <lm1> :title "a local member". 
> 
> In the former, both resources are added via POST to the container, they both get deleted when the container gets deleted - meaning lm1 and lm2 get created on POST and deleted on DELETE, m2 is left alone. This is simple and easy to understand. On the other hand, the client has to go through an extra hop (lm2 -> m2) to get to the actual resource (m2) that is meant to be listed as a member. 
> 
> In the latter, lm1 is created and added to the container via POST and m2 is added via PATCH (the current draft doesn't support this today but with the resolution on PATCH that's an easy fix). The structure more accurately represents what is meant to be: m2 is a member of c (which is consistent with how the WG chose to handle binary data at the F2F: the binary blob is what gets linked from the container). 
> 
> But now the container is a mixed bag of server-managed resources and externally-managed resources which makes the semantics of DELETE not so simple. 
> 
> Regards. 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/