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

On 20 Apr 2013, at 16:00, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> Henry Story <henry.story@bblfish.net> wrote on 04/20/2013 04:25:21 AM:
> > ...
> > Btw, there would be no need for repetition of the ldp:contains and 
> > rdfs:member relations if one just 
> > adds to the ontology 
> > 
> > ldp:contains rdfs:subPropertyOf rdfs:member . 
> > 
> > <> a ldp:Container; 
> >    rdfs:member <a>; 
> >    ldp:contains <b>. 
> > 
> > which is more elegant. 
> > ...
> 
> If all we had to deal with was rdfs:member as the membership predicate I would agree but I don't see how that works with membershipPredicate and membershipPredicateInverse that let you use something different from rdfs:member.  Can you explain? 

The membershipPredicate statements are already a bit tricky. 

It depends how one interprets it. 
If the using membershipPredicate means one has to add the closure of applying the 
following rule to a graph that contains it:

CONSTRUCT {
     ?s rdfs:Container;
          rdfs:member ?b 
} WHERE { 
   ?a ldp:membershipPredicate ?r ;
         ldp:membershipSubject ?s . 
    ?s ?r ?b .
} 

then:
 a. I wonder how many people realise that the subject is forced to be a rdfs:Container, when they use the membershipPredicate relation.
 b. yes, one would have to add the ldp:contains member for each relation, if one wanted to express containment for a relation. For example
    the following graph 
{
   <>   a ldp:Container;
        dcterms:title "The assets of JohnZSmith";
        ldp:membershipSubject <>;
        ldp:membershipPredicate o:asset.

    <>   a o:NetWorth;
        o:asset <a1>, <a3>, <a2>.
}

would only allow us to conclude that 

   <> rdfs:member <a1>, <a3>, <a2> .

and perhaps not what one needs which could be

   <> rdfs:contains <a1>, <a3>, <a2> .

One would therefore have to add those triples to the graph,
which I admit is a bit tedious.

The other solution would be perhaps to not write

{  
     <>   a o:NetWorth;
        o:asset <a1>, <a3>, <a2>.
}

but rather

{
    <>   a o:NetWorth;
        ldp:contains <a1>, <a3>;
        rdfs:member <a2>.
} = G1.

And for the rule to be instead

CONSTRUCT {
     ?s  ?r ?b .
} WHERE { 
   ?a ldp:membershipPredicate ?r ;
         ldp:membershipSubject ?s . 
   ?s rdfs:member ?b .
} 

So that one could conclude from

{
   <>   a ldp:Container;
        dcterms:title "The assets of JohnZSmith";
        ldp:membershipSubject <>;
        ldp:membershipPredicate o:asset.

    <>   a o:NetWorth;
        ldp:contains <a1>, <a3>;
        rdfs:member <a2>.
}

that
 
{
  <> a o:NetWorth;
     o:asset <a1>, <a2>, <a3> .
}

(given that ldp:contains is a subProperty of rdfs:member)


OTHERWISE
---------

I would like to remind us that my proposal originally was to stick with
our agreement at our first TPAC meeting, and that we don't need a weak
aggregation. That can always be modelled in a resource that one creates on
the side. It seems to me that we moved with very little consensus to the
weak aggregation proposal. 

http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

At the time I thought this was something that we were going to discuss, not
put in the spec. So it seems to me that the way things are turning we should
go back to the pre- weak aggregation consensus.


> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 

Social Web Architect
http://bblfish.net/