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

Hi Henry,

Henry Story <henry.story@bblfish.net> wrote on 03/21/2013 12:54:08 PM:
...
> 
> # 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> .
> 
> Sorry, I sent the send button too quickly. I meant
> 
> <> a lpd:Container;
>     ldp:contains <lm1>;
>     rdf:member <http://server2.example.org/m2> .
> 
> Deleting an ldp:Container would only delete recursively ldp:contains
> relations recursively.

Indeed, we could do that. But then the client has to deal with two 
different predicates. Given last week's decision to add 
membershipPredicateInverse I'm afraid the number of predicates one has to 
keep track is going to get out of control. To avoid that you could combine 
the two:

<> a ldp:Container;
  rdf:contains <lm1>; 
  rdf:member <lm1>; 
  rdf:member <http://server2.example.org/m2>. 

<lm1> :title "a local member". 

But then the size of the container doubles for what might be the most 
general case where it only contains server-managed resources.
There doesn't seem to be any magic bullet here, If there is one I haven't 
seen it yet. We have different possibilities, each of which has its pros 
and cons. So, it's a matter of figuring out something we can all live with 
and which best addresses the most common use cases.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group