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

"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>.

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