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

On 24 May 2013, at 23:11, 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? 

Issue-71 argues that one need not have the membershipXX relations
http://www.w3.org/2012/ldp/track/issues/71
Issue-73 argues that rdf:member properties should be on the LDPC 
http://www.w3.org/2012/ldp/track/issues/73

accepting issue-71 probably implies issue-73, but not vice versa.

In my view one should first vote on issue-73. That still allows the 
membershipXXX relations to exist. Issue-73 would then be a further 
thing to vote on. In my view unless one can find an acceptable solution
to ISSUE-72 on membershipObject the membershipXXX properties are 
all in a weak spot, as they incentivise bad modelling, and have
not UC&R. 

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

Social Web Architect
http://bblfish.net/

Received on Friday, 24 May 2013 22:47:37 UTC