Re: membershipSubject clarification

On 3 May 2013, at 18:41, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> I have to admit not to follow all of what you wrote. The basic idea is that containers have a list of members that are identified by triples of the form: membershipSubject membershipPredicate member 
> 
> By default membershipSubject is the container itself, and membershipPredicate is rdf:member but they can be set to something else so that a container can be defined "around" a different resource. 

So if by default ldp:membershipPredicate is rdf:member then I can deduce from 

<> ldp:Container .

that 

<> ldp:Container ;
     ldp:membershipPredicate rdf:member .

but when I now add to the <> container the triple { <> ldp:membershipPredicate foaf:depiction } 
then I can no longer deduce that {<> ldp:membershipPredicate rdf:member } which
means that appending { <> ldp:membershipPredicate xxx } is a non-monotonic 
process. This goes against RDF logic.

To help find a quick solution to this we need to be clear about what membershipPredicate 
and membershipSubject are trying to accomplish in a more general way.
The above shows that there is a harmful confusion with the ldp:member relation. Seperate
what those relations are doing from the rdf:member logic, and I think we will have made a 
step forward.

> 
> More comments below.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> Henry Story <henry.story@bblfish.net> wrote on 05/02/2013 12:40:53 PM:
> 
> > From: Henry Story <henry.story@bblfish.net> 
> > To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> > Cc: public-ldp-wg@w3.org, Richard Cyganiak <richard@cyganiak.de> 
> > Date: 05/02/2013 12:41 PM 
> > Subject: Re: membershipSubject clarification 
> > 
> > 
> > On 30 Apr 2013, at 18:11, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> > 
> > > Hi all, 
> > > On Monday we agreed to close Issue-61 which suggested to drop 
> > membershipSubject and focus on clarifying the spec instead. 
> > > To get us started I'd like to highlight that the editor's draft 
> > has an expanded example 3 which may clarify things a bit: 
> > > 
> > > # The following is an elaborated representation of
> > > #   http://example.org/netWorth/nw1
> > > @prefix ldp: <http://www.w3.org/ns/ldp#>.
> > > @prefix o: <http://example.org/ontology/>.
> > > <>
> > >   a o:NetWorth;
> > >   o:netWorthOf <http://example.org/users/JohnZSmith>;
> > >   o:asset 
> > >      <assetContainer/a1>,
> > >      <assetContainer/a2>;
> > >   o:liability 
> > >      <liabilityContainer/l1>,
> > >      <liabilityContainer/l2>,
> > >      <liabilityContainer/l3>.
> > > 
> > > <assetContainer/>
> > >   a ldp:Container;
> > >   dcterms:title "The assets of JohnZSmith";
> > >   ldp:membershipSubject <.>;
> > >   ldp:membershipPredicate o:asset.
> > > 
> > > <liabilityContainer/>
> > >   a ldp:Container;
> > >   dcterms:title "The liabilities of JohnZSmith";
> > >   ldp:membershipSubject <.>;
> > >   ldp:membershipPredicate o:liability. 
> > > 
> > > This defines two containers (assetContainer and 
> > libabilityContainer) corresponding two different membership 
> > predicates (respectively o:asset and o:liability) around the same 
> > subject resource (netWorth/nw1). 
> > 
> > 1. does the ldp:membershipSubject have to be a document such as <> ?
> > ( which in the example above is a o:NetWorth )
> >     a. if yes: how would one add a relation to a thing such as a 
> > person <#me> a foaf:Person ?
> >     b. if no: why is the relation called membership subject? Does 
> > this imply that the o:asset relation is an rdf:subProperty of rdf:member.
> >       I don't think that if I want to create a document I want to 
> > necessarily think of the document I created in say <assetContainer> 
> > as being a ldp:member of me.
> >  
> >   Consider the following example
> >  
> >    {
> >       <#me> a foaf:Person;
> >       foaf:depicts <portrait/img1> ;
> >       cal:attending <meetings/meet1> .
> >       
> >        <portrait/> a ldp:Container;
> >          dcterms:title "The assets of JohnZSmith";
> >          ldp:membershipSubject <#me>;
> >          ldp:membershipPredicate foaf:depicts.
> > 
> >        <meetings/>
> >          a ldp:Container;
> >          dcterms:title "The liabilities of JohnZSmith";
> >          ldp:membershipSubject <.>;
> >          ldp:membershipPredicate cal:attending. 
> >     } 
> >  
> >     Is this ok?
> 
> I don't think so. The first container is fine, I don't see any problems with setting membershipSubject to <#me>.

My problem is that then we no longer have any information about where the members of the container are. It
is very weird to have to look at a completely different resources foaf:depicts  relation on #me to know what resource
the container created.

> On the other hand <.> would have to be the URL of the resource you actually GET, right? So that would be something like http://example.org/JohnZSmith and that's not the subject you want because there is no <http://example.org/JohnZSmith> cal:attending xxx triples. 

I think I meant that to be <> . It's a bit confusing because the same content describes both containers.

> 
> > 2. Would it not be a good thing if a GET on <portrait/> returned thefollowing
> > 
> >     <> a ldp:Container;
> >          dcterms:title "The assets of JohnZSmith";
> >          ldp:membershipSubject <#me>;
> >          ldp:membershipPredicate foaf:depicts;
> >          rdfs:member <img1>, <img2> .
> > 
> >     and of course if <meetings> mentioned its rds:member ?
> > 
> 
> The point of membershipSubject and membershipPredicate is to allow defining containers that map onto existing resources and allow several containers to be defined over the same resource. 

I think what you want is rather some way of saying: "when you create a content 
in this container, these other relations will be added in these other LDPRs to
the content created". 

The current solution confuses the above need with container
membership, and produces a solution that is too constrained for
what people will inevitably need when they start using this.

> > 3. What if I want the object of the relation from the 
> > ldp:membershipSubject to the the object to be something described by
> > the created  
> > resource? Say I want to create a resource that contains a <#me> and 
> > the ldp:membershipPredicate should be a foaf:knows relation to the object
> > ( perhaps a <#him> in the created document? )
> 
> What about it? I'm afraid I don't understand this. 
> 
> >  
> > 4. Can I have a number of different membershipSubjects?
> 
> Not for a given container. 
> 
> > 
> > Guess
> > -----
> > 
> >   My feeling is that what is wanted is some way to describe how 
> > contents of the POSTed
> > graph get tied to other resources managed by the server. My feeling 
> > is that this is
> > a good idea, but orthogonal to the rdf:member of an LDPC. 
> > 
> > Henry
> > 
> > > 
> > > I would appreciate if Henry and others could ask specific 
> > questions about this design so we can try to answer them and see how
> > the spec needs to be clarified. 
> > > 
> > > Thanks.
> > > --
> > > Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 

Social Web Architect
http://bblfish.net/