Re: membershipSubject clarification

hi John, 

> > 1. does the ldp:membershipSubject have to be a document such as <> ?
> > ( which in the example above is a o:NetWorth )
> 
> I'm guessing that by 'document' you mean "a URI that is also, without modification, a valid HTTP request-URI".  Under that assumption, no.  The membership subject is just a URI, any URI usable as a subject in RDF triples. 
> 
> >     Is this [JA: elided example] ok? 
> I think it is.  I disagree with Arnaud there, because the triple
> 
>    <meetings/> ldp:membershipSubject <.>; 
> can be restated as 
>    <http://example.org/netWorth/nw1/meetings/ ldp:membershipSubject <http://example.org/netWorth/nw1> 
> and I see a triple 
>   <>       cal:attending <meetings/meet1> . 
> aka 
>    <http://example.org/netWorth/nw1>       cal:attending <<http://example.org/netWorth/nw1/meetings/meet1> . 
> (although the presence of that triple is not itself required per se, it lends credence that what you conveyed and what you intended to convey are consistent) 
> 
> 
> > 2. Would it not be a good thing if a GET on <portrait/> returned the following 
> ... 
> >     and of course if <meetings> mentioned its rds:member ? 
> 
> LDP *allows* the server to return 'extra' triples beyond those whose subject matches the HTTP request-URI. 
> 
> I think your intent here is basically to say: would it not be useful of GET on a container always returned the membership triples, regardless of the subject of those triples?  Which seems reasonable. 
> 
The way I interpreted Henry's email was that the rdf:member assertion about the <meetings/> container was *in addition to* the cal:meetings assertion on the <#me> resource ... I mostly came to that conclusion because Henry's example has a specific membershipPredicate (overriding the default rdf:member). 

On John's point, this seem to satisfy the definition of a LDPC, i.e. it returns a list of triples where the LDPR is found in the subject position.

That said, there is something disconcerting about re-referencing a resource, and finding a bunch of triples where the subject is some other resource (or is that just me ???).  In an older proposal [1], I did something similar to Henry and used ldp:element to assert the elements inside a container (as well as allowing the domain specific triple to be asserted using the LDPR resource as subject). 

I am happy with what we have at the moment though. 

regards, 
Roger

[1] http://www.w3.org/2012/ldp/wiki/Bug-tracker_LDP_service