- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 3 Jun 2013 07:27:38 +0200
- To: John Arwe <johnarwe@us.ibm.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <253548AE-B6BF-4587-B2A0-5CD485E6655A@bblfish.net>
On 3 Jun 2013, at 06:53, John Arwe <johnarwe@us.ibm.com> wrote: > Most (vast majority) of my clients *do not care* if a member was created by the container or are simply listed as members but exist independently (quite possibly existing prior to the container itself). It's a completely irrelevant (to those clients) who consider "who created it" to be an implementation detail. They are going to want to update the members (hence the r/w part), for sure. That's fine. Many clients may create a member and just go on from there, without ever doing a GET on the LDPC again. > > The way the spec is written reflects this notion of membership. I don't care personally if you wish to add a contains relation. For the implementations of interest to me it is, so far, completely extraneous but I have no trouble imagining a place for it. Ok, so we can settle on replacing the text in the spec with ldp:contains then? In the end if you want to add different relations to your LDPC you can of course use different relations. So this would be perfectly ok: <> a ldp:Container; ldp:contains <member>; rdf:member <http://ibm.com/cart/23> . It helps us if the ldp:contains relation is the default predicate in our spec, because this is the one most closely related to the protocol. > > I can tell at this point that anything else I would say falls on deaf ears, so </end> > > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > > Social Web Architect http://bblfish.net/
Received on Monday, 3 June 2013 05:28:10 UTC