Re: clarifying containment vs membership

Sandro Hawke <sandro@w3.org> wrote on 02/19/2014 01:16:43 PM:

> 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. 

Doesn't that prohibit adding an existing resource to a container?

> 
> 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 can certainly sympathize with that and I've been going back and forth 
between the two options but 1) I see value in allowing existing resources 
to be added as members (via PATCH or possibly PUT of the 
containerResource), 2) I find it more justifiable to have to deal with 
both containment and membership if containment is limited to "managed" 
resources while membership is not than if there is a direct mapping 
between the two.

> (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.)

Well, we had a more efficient way with ldp:created that was to be used in 
that specific case but several people insisted on having the containment 
relationship materialized in all cases.

> 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.

I've heard that argument before but I think this misses the initial idea 
of the having a standard usage pattern on how to manage collections in 
LDP.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group