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

On 23 May 2013, at 21:08, "Linked Data Platform (LDP) Working Group Issue Tracker" <sysbot+tracker@w3.org> wrote:

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


Here is what it would look like for a bugtracker example. This seems very 
clean and reasonable to me.


The </BugTracker> resource lists different relationships

~~~~~~~~GET /BugTracker HTTP/1.1~~~~~~~~~
<#obj> tracksProduct 
          </BugTracker/productsContainer/ProductA#p> ,
          </BugTracker/productsContainer/ProductB#p> ;
   hasBug </BugTracker/bugsContainer/bug1#b> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The productsContainer lists the members of the container.

~~~~~GET /BugTracker/productsContainer/ HTTP/1.1 ~~~~
<> a ldp:Container;
  ldp:membershipSubject </BugTracker#obj>;
  ldp:membershipPredicate bt:tracksProduct ;  
  rdfs:member <ProductA>, <ProductB> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The we have ProductA and ProductB described very cleanly 
as you suggested

~~ GET /BugTracker/productsContainer/ProductA> ~~~~~~
<> a bt:ProductDescription;;
  foaf:primaryTopic <#p>;
  dcterms:title "The Product A Page";
<#p> ... # description of product
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~ GET /BugTracker/productsContainer/ProductB> ~~~~~~
<> a bt:ProductDescription;;
  foaf:primaryTopic <#p>;
  dcterms:title "The Product A Page";
<#p> ... # description of product
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The bugsContainer lists its only member <bug1> 
(It's a very young project clearly )

~~~~ GET /BugTracker/bugsContainer/ HTTP/1.1 ~~~~~~~~
<> a ldp:Container;
  ldp:membershipSubject </BugTracker>;
  ldp:membershipPredicate bt:hasBug ;
  rdfs:member <bug1> .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And <bug1> contains all the info as you suggested again.

~~~GET /BugTracker/bugsContainer/bug1 HTTP/1.1 ~~~~~~ 
<> a bt:BugReport;
 foaf:primaryTopic <#b> ;
 dcterms:title "Product A crashes when shutting down.";
 dcterms:creator </users/johndoe#me>;
 dcterms:created "2013-05-05T10:00"^^xsd:dateTime .

<#b> a bt:Bug;
 bt:relatedProduct </app/BugTracker/ProductA#p>;
 bt:isInState "New" .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Social Web Architect
http://bblfish.net/

Received on Thursday, 23 May 2013 19:13:19 UTC