Re: Creating members

change set https://dvcs.w3.org/hg/ldpwg/rev/ebfb1abdf1cb

The existing superclass definition (LDPC-nothing) already talks about 
create, so I removed that word from LDPC-IC.

This discussion did raise a question however: are we concerned about the 
What (describing correct state), or the How?  Currently we describe 
membership/contains triple "maintenance" primarily via How - when X 
happens, do Y, with the (implicit) intended consequence of keeping things 
in a consistent state.  Meaning if we miss any How, we have a hole.
In the context of indirect containers, this shows up as: if I post our 
usual case (foaf:primaryTopic is the inserted content relation), and the 
object of that triple in the formerly-posted LDPR changes later, is any 
action suggested/required on the corresponding membership triple?  Today 
the answer is we're silent.  To someone coming in and just looking at the 
aggregate state after such a change, it looks inconsistent.
Example:
t=0: post content containing foaf:primaryTopic = Henry#me
t=1: 201, location= henryLDPR
t=2: GET membership ... expect to find  <ldpc, ldp:member, Henry#me> in 
there
t=3: put henryLDPR with foaf:primaryTopic = Henry#me2
t=4: GET membership ... blindly following LDP as-is-now I think you'd 
still have <ldpc, ldp:member, Henry#me> 
To someone (like us) walking up after the fact and GETting henryLDPR , 
we'd expect (based on the container properties) to find <ldpc, ldp:member, 
Henry#me2> ...#me2 not #me
That looks "odd"

I think this only arises for indirect.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario