Re: A question on the definition of LDP-BC

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