Re: clarifying containment vs membership

On 02/19/2014 02:09 PM, Steve Speicher wrote:
>
> On Wed, Feb 19, 2014 at 12:34 PM, Sandro Hawke <sandro@w3.org 
> <mailto:sandro@w3.org>> wrote:
>
>     On 02/19/2014 12:18 PM, Sandro Hawke wrote:
>>     As I read the spec, it seems to me that normally a container
>>     contains exactly the same resources it has as members.
>>
>>     The one circumstance I can see where this would not be true is
>>     when ldp:insertedContentRelation is used.
>>
>>     I think this is reasonable, but I'm not at all sure I'm reading
>>     things right.
>
>     To be clear, some people think I'm not.   The spec says, very
>     cryptically:
>
>         A LDP Direct Container or LDP Container's membership triples
>         MAY also be modified via through other means.
>
>     Like what?     It also says, "LDP servers SHOULD NOT allow HTTP
>     PUT to update a LDPC's membership triples", so... what are those
>     other means.   Is it the cases of the server violating the "SHOULD
>     NOT"?
>
>
> PATCH or application specific behavior (like membership triples may 
> just appear, such as events in a log on the server).  I wonder if 
> SHOULD NOT is right after the containment resolution.  Personally I'd 
> like to just generalize it to say "LDP servers SHOULD NOT allow HTTP 
> PUT to update a LDPC but instead use PATCH." and we'd avoid other 
> problems.

Ah.   What's wrong with PUT, then?     PUT is semantically the same as 
PATCH, just slower.     I took the prohibition on PUT to be a 
prohibition on changing the membership triples.

FWIW, given my current understanding, I strongly support a prohibition 
on changing membership triples.    The only way to put something in a 
container should be POST, or PUT to the container's declared URL 
space.   And the only way to take it out should be to DELETE it.

At the moment, I'm seeing a lot of cost and no value to letting things 
randomly and unpredictably make containment and membership not align 
with each other.

(I do support them being different for non-information resources. In 
that case, the non-information resource is a member, and the information 
resource is contained.     There's probably a more-efficient way to 
represent that case, but whatever.)

Of course people want membership-only "containers", but those are just 
RDF Collections or Containers  (Seq and List), or things that look like 
LDP containers, but there's no need for the server to know about them.   
It just needs to know about containment so it can manage the lifecycle.

       -- Sandro


>
>     The spec also says cryptically:
>
>         This ldp:contains triple can be the only link from the
>         container to the newly created resource in certain cases.
>
>     which threw me off for a bit.   I think "in certain cases" should
>     be replaced by "until or unless more links are made."
>
>
> Yes, your suggestion is better.  Thanks.
>
> - Steve
>
>
>
>            -- Sandro
>
>
>
>>       Is there some other circumstance where it's possible to have a
>>     resource that is a member but is not contained, or is contained
>>     but is not a member?
>>
>>     (I guess the current spec doesn't rule out the server making
>>     these sets different for its own reasons, but I think the clients
>>     can't make it happen, so I'm not too worried about it.   It would
>>     probably be best if servers were forbidden from doing it, too.)
>>
>>     BTW, I have an alternative proposal for
>>     ldp:insertedContentRelation (which I think has some problems),
>>     but I want to make sure I understand the context before I get
>>     into that.
>>
>>              -- Sandro
>>
>>
>>
>>
>>
>>
>>
>>     |||||
>>     | 
>
>