Sandro's various issues (was Re: A simpler way of thinking about containment and membership?)

On 02/20/2014 11:48 AM, Arnaud Le Hors wrote:
> Sandro Hawke <sandro@w3.org> wrote on 02/19/2014 05:04:33 PM:
>
> > 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.
>
> That's correct but, similarly, containment triples may also be added 
> or removed by application logic on the server.

My understanding is that containment triples always mirror containment.  
So application logic can remove the triples ONLY by deleting the 
resource.   I suppose it could then re-create it under another 
container, or no container, at the same URL... but that seems like very 
bad practice, and unlikely.

My view has always been that application logic on the server should be 
indistinguishable from another client.  I haven't noticed any violations 
of that, but I haven't really been looking for them.

(In the implementation I'm doing, that's certainly how it's 
structured.   Application code running inside the server has the same 
api as code running in the client.  It just has more efficient access.   
And for now, for some things, the client needs to use non-standard LDP 
extensions.)

>
> > To me, that's a story that makes sense. Or maybe it's just me that
> > finds the current story odd and somewhat underspecified?
>
> Evidently the editors barely had the time to try and capture the 
> latest resolutions, which included the whole containment stuff. There 
> is no doubt that the spec would benefit from some additional editorial 
> work to put all of that in the proper perspective. I certainly hope 
> effort can be put into this once the firedrill of trying to get to LC2 
> is passed.
>

Yes, but I think this is more than strictly editorial.

> >   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).
>
> Can you please expand a bit on that? I don't understand what you mean.
>


Well, the way I've explained it here, there is only one kind of 
container.   All containers will maintain whatever membership structure 
they happen to contain.   Servers that allow clients to create 
containers with an "indirect container" membership configuration will 
have to maintain the membership triples of such a contruct, etc.   If 
the server only wants to maintain one kind of membership triples, then 
it has to put that membership configuration in the container state and 
not let any client change them.

The main point is probably that, with this framing, a Membership is a 
perfectly sensible thing to use in RDF outside of LDP. It's just that 
LDP Containers happen to be mandated to maintain them when they find 
them in a container's state.

In terms of normative changes, it means there would be no 
ldp:DirectContainer or ldp:BasicContainer.  Instead, what we now call an 
ldp:BasicContainer would be an ldp:Container that doesn't happen to have 
any Membership in it, and an ldp:DirectContainer and what used to be 
IndirectContainer would be ldp:Containers that happen to contain 
different Membership Configuration Triples.

> >
> > [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.
>
> Are you talking about the prefix of the URLs the server will mint for 
> contained resources, or that a client could create using PUT?

Yeah, I'm talking about LDPRs that a client could create using PUT.   It 
makes no sense to me to say clients can create using PUT but not give 
them any way to find out what URLs they can use to do that.   As we 
currently have it, I think readers will have to pick something, so 
they'll assume the container IRI is the container prefix.

My suggestions is that we either include a way to advertise it, or take 
out the idea that resources can be created using PUT (or PATCH).      
Then let it be an extension to support direct creation of contained 
resources.

>
> >
> > [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.)
>
> This would be more powerful indeed but we are way past the design 
> period and it's too late to think of better/more powerful ways of 
> doing things. I'm happy to make the spec more understandable and fix 
> what's broken but requests for new features automatically go to the 
> LDPnext wish list.

Well, my instinct on this, as on the points above, is that if we don't 
fix them now, we'll be fixing them in LC3, because we wont actually get 
real implementations during CR.     Or worse, we'll squeak through CR 
based on implementations from folks in the WG, but we wont really have 
any industry buy in because it just seems too weird and complicated.

I think it's fine for LDP to have complexity as long as it's 
pay-as-you-go: if you want a Membership structure, then you have to read 
the part of the spec (or manual or book) that talks about Membership.   
But if ldp:contains triples suit your needs, then you never even need to 
read anything about Memberships.   Right now, the protocol makes that 
impossible because of these three classes of Containers that differ only 
in how they handle Memberships.

But perhaps I'm being overly cautious, and you're right on the 
procedure.    (I could perhaps make an argument about new information 
here.  I'd have to go back and see exactly what options were considered 
at the time.    Obviously that doesn't change whatever time pressures we 
really have.)

Speaking of LDPnext, did you like my idea of having an outsite-the-WG 
page where we start to maintain a list of extensions?    I say 
outsite-the-WG so it can still be maintained after the WG goes away.

     -- Sandro


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group