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

Hi Henry,
Could you please tell me what this issue adds to ISSUE-71? Isn't that 
redundant?
Thanks.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   "Linked Data Platform (LDP) Working Group Issue Tracker" 
<sysbot+tracker@w3.org>
To:     public-ldp-wg@w3.org, 
Date:   05/23/2013 12:16 PM
Subject:        ldp-ISSUE-73 (rdf:member): LDPCs to list all their 
rdf:member [Linked Data Platform core]



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, ...