- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 29 May 2013 07:51:29 +0200
- To: John Arwe <johnarwe@us.ibm.com>
- Cc: Linked Data Platform (LDP) Working Group <public-ldp-wg@w3.org>
- Message-Id: <A2582AA5-9ECF-4A36-BB34-58F212E6ABBA@bblfish.net>
On 28 May 2013, at 15:25, John Arwe <johnarwe@us.ibm.com> wrote: > > 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 . > > We agree that they're HTTP resources. Probably GETable. The others, depends on the container's implementation capabilities. agreed. > Other container members (those created via means other than POST/Create ... PUT, PATCH, out of band means) may behave exactly the same way as members created through the container yes. the language would need to be tuned. I was just trying to make the point clear by forcing the important trait. > . > > > > > 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 formulation above only yields "all" the members when the container supports Create and DOES NOT support any other form of membership modifications. No doubt an interesting subset for certain implementations, but not at all useful in my space. I'd say that even those members created by other means should appear in the LDPC. > Unless we're back to talking about profiles, which did not seem to thrill anyone the first time, I don't think this works as it has been portrayed. > > > > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > > Social Web Architect http://bblfish.net/
Received on Wednesday, 29 May 2013 05:52:04 UTC