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

Hi Arnaud,

I might be wrong but I think even if ISSUE-71 gets resolved in a manner
that would not remove ldp:membershipPredicate and ldp:membershipSubject, it
might be possible that still ISSUE-73 might get resolved as proposed.
However, IMHO all three issues 71, 72, and 73 are quite dependent on each
other and might have to be discussed together.

As I overused my self-imposed quota on this list, I thought of paying my
debt here.
http://www.nandana.org/2013/05/ldp-71-72-73.html

Best Regards,
Nandana

On Fri, May 24, 2013 at 11:11 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote:

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