Re: ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core]

Henry,

I think I understand why you want this. For me, if I need to find out about the Bugs in the BugTracker, I'm going to ask the BugTracker. I don't need to go to the container. 

What will happen in the case of combined LDPR and LDPC (where the membershipPredicate is present, but the membershipSubject is not). If the members follow the bad modelling style, then this means duplicated triples (I think) ...

regards,
Roger



> ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core]
> 
> http://www.w3.org/2012/ldp/track/issues/73
> 
> Raised by: Henry Story
> On product: Linked Data Platform core
> 
> An LDPR MUST/SHOULD list all the resources that were created in it with a POST as rdf:member .
> That is doing a GET on the LDPC should return a list of members. These members are the HTTP resources that are GETable, PATCHable, POSTable, DELETEable .
> 
> Advantages:
> - a client can easily find out all the members of an LDPC by GETing it and querying the returned representation with some query  that is the equivalent of the SPARQL
>      SELECT ?member WHERE { <> rdf:member ?member } 
> - the client does not need reasoning to find out what the members are
>    ( currently it seems to require some ldp:membershipProperty relation to find out what the member is )
> - LDPRs that are not LDPCs don't get lost after creation. An admin client can easily find out all the members. ( currently LDPRs may be listed on a remote resource for which one needs to know the LDPCs it came from and that it had a ldp:membershipSubject . The same issue would be true for an ldp:membershipObject . )
> - the LDPC is a good place to add metadata on the LDPR created such as title, update time, acl resources, ...
> 
> 
>