- From: John Arwe <johnarwe@us.ibm.com>
- Date: Mon, 12 May 2014 08:03:36 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <OF9FC0411B.B586B0B8-ON85257CD6.004110CA-85257CD6.00423FD4@us.ibm.com>
In the general case (absolutely anything permitted by the spec occurs in practice), Direct containers can have non-information resources as members. One path to this state is via client update of the membership triples; another is the classic "side effects of other operations" effect ... I could see 'calculated views' of some database in that light, e.g. a set of people satisfying some query predicate being materialized by a server as a read-only container whose membership is automatically updated to reflect changes "elsewhere" in the system. In the normal case (membership triples managed ONLY via LDP create/delete requests), Direct containers will only have information resources as members. membership-constant-URI might the the container (this would be the normal case in our discussions) but can be another resource ... examples of the latter occur in the spec where we talk about "overlaying" the LDP model onto existing resources (assets/liabilities), and I think the pattern Roger has discussed many times where some resource has a posse of containers, each acting as the sheriff for one predicate... IIRC the subject of those triples was "the other resource" not each container. Best Regards, John Voice US 845-435-9470 BluePages Cloud and Smarter Infrastructure OSLC Lead From: Roger Menday <roger.menday@uk.fujitsu.com> To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org> Date: 05/09/2014 05:52 AM Subject: Re: A question on the definition of LDP-BC hi Nandana, It's an interesting point. Especially the line you have highlighted: " allows members to be any resources, not only documents". I'm looking forward to getting some perspective on that - especially from the spec authors. regards, Roger On 8 May 2014, at 11:36, Nandana Mihindukulasooriya wrote: Hi, In the LDP spec, one form of a membership triple can be as following. (membership-constant-URI, membership-predicate, member-derived-URI) In this case, what we call the 'member-derived-URI' resource is the member, isn't it ? I am not sure the name of the 'membership-constant-URI' resource but it is not the member, I assume. The definition of the LDP-DC says, An LDPC that adds the concept of membership, allowing the flexibility of choosing what form its membership triples take, and allows members to be any resources, not only documents. LDP-DC allows membership-constant-URI to be any resource but the member-derived-URI (or member) will always be the created document. So I am not sure whether the latter part of the definition is correct but that depends on the answer to the first question. I assume the answer should be yes, because the definition of the LDP-IC says An LDPC similar to a LDP-DC that is also capable of having members whose URIs are based on the content of its contained documents rather than the URIs assigned to those documents. Best Regards, Nandana
Received on Monday, 12 May 2014 12:04:09 UTC