A simpler way of thinking about containment and membership?

I think I understand where y'all are coming from better now.     Let's 
see if I can describe it with the appropriate separation.   I think this 
is an easier way to explain it, and a slightly easier protocol:

    An "LDP Container" (LDPC) is a special kind of LDP-RS which is used
    to provide the service of creating and managing the lifecycle of
    LDPRs.  It can also enumerate a list of the LDPRs it is managing
    (that is, the ones it "contains").    The request to create can be
    done in one of two ways: (1) a POST to the LDPC, in which case the
    server allocates a new URL to the new LDPR, or (2) a PUT to a URL
    somewhere new in the LDPC's private URL space [1].   LDPRs can be
    deleted, and thus removed from the LDPC, using HTTP DELETE on the
    LDPR.   In either case, for each contained LDPR which has been
    created and not yet deleted, the server includes a triple of the
    form {<LDPC URL> ldp:contains <URL of new LDPR>} in the LDPC.    If
    an LDPC is itself DELETE'd, all the LDPRs it contains are DELETE'd.

    A "Membership" is a kind of simple,  unordered collection in RDF,
    which can make use of existing triples in an application domain.  A
    "Membership Graph" is an RDF Graph (often a subgraph of a larger
    graph) which contains "Membership Triples" as well as "Membership
    Configuration Triples".    The Membership Configuration Triples convey:
        (1) in the membership triples, is it the subject or object of
    the triples that is the Membership itself?
        (2) which resource is the Membership itself?
        (3) which predicate is used in the membership triples?

    If an LDPC contains Membership Configuration Triples, then the
    server MUST help maintain the membership triples.  Specifically,
    every time an LDPR is created in the LDPC, the server MUST add a
    membership triple for that LDPR's primary topic (if it has one
    declared [2]) or for the LDPR itself (if it does not).   When an
    LDPR is DELETE'd, the server MUST remove the corresponding
    membership triple, if it is still present in the LDPC.   Note that
    Membership Triples may also be added or removed by application logic
    on the server or by other permitted clients, not necessarily in sync
    with LDPRs being created or deleted.

To me, that's a story that makes sense.   Or maybe it's just me that 
finds the current story odd and somewhat underspecified?   I think it 
would only change the spec in editorial ways, and probably change some 
of the container classes to being membership classes (which I think can 
& probably should be specified in the LDPC triples, rather than the LDPC 
header).

     -- Sandro

[1] This is kind of orthogonal, but a really good time bring up I think 
servers which are going to do this MUST include in the LDPC's headers a 
Link: <http://example.org/myldpc/> 
rel="http://www.w3.org/ns/ldp/ContainerPrefix".      If we don't include 
this in the spec now, I think people will just assume the LDPC's URL is 
the prefix, and it'll be hard to change that behavior down the road.

[2] I think it's overly constraining to say that if you want to do the 
primary-subject thing, you have to have the same primary-subject 
predicate for every resource in the membership, and that you have to 
have such a triple in the data at all.   That basically forces 
memberships to be homogeneous and overly explicit about their document 
structuring.   I suggest instead that during PUT or POST, the client 
include a header like:  Link <#me> 
rel="http://www.w3.org/ns/ldp/PrimarySubject".    This tells the server 
to use this alternate URL in the membership triples it's maintaining, if 
any.   Maybe on GET, the server should be handing back that header, too. 
   (It needs to remember it for later use in DELETE.)






On 02/19/2014 05:01 PM, Arnaud Le Hors wrote:
> 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
>