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

Sandro Hawke <sandro@w3.org> wrote on 02/20/2014 06:14:06 PM:

> My understanding is that containment triples always mirror 
> containment.  So application logic can remove the triples ONLY by 
> deleting the resource.

That's fine. Your text simply didn't acknowledge that containment triples 
might be modified by the server, while it did for membership triples. My 
point was simply that it is true for both.

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

That's fine but that's certainly not going to always be the case. If you 
put a thin LDP layer to turn bugzilla into an LDP server it won't be used 
when a user creates or delete a bugs via bugzilla.

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

The only thing I see in your storyline that's not in keeping with the 
normative part of the current spec is that you expect that deleting 
containers will delete the contained resources. The WG already went 
through this a long time ago and decided DELETE was NOT 
recursive/cascading, that such an operation might be added later on.
See ISSUE-59: http://www.w3.org/2012/ldp/track/issues/59

The part about separating Membership from the Container is somewhat 
orthogonal.

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

Maybe it could have been designed that way. It reminds me of a proposal 
Henry had, in which he proposed to define membership as a consequence 
defined by a rule set on the container.

We've been through a lot of variations around aggregations and 
compositions and I don't see anything really new here. It's the same issue 
that keeps popping back up in different forms.

I suggest you have a look at the following wiki pages:
http://www.w3.org/2012/ldp/wiki/Member
http://www.w3.org/2012/ldp/wiki/MembershipInferencing
http://www.w3.org/2012/ldp/wiki/Membership
http://www.w3.org/2012/ldp/wiki/Containers

What we ended up with is the result of a series of compromises to get 
everybody to be able to live with it. This is never in my experience what 
anyone would design on their own. But I have no reason to believe that 
adopting the model you propose would 1) satisfy everybody's needs, 2) not 
generate another set of issues that will take time to resolve.


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

To be fair, the intent of the spec is clearly not to have client create 
resources using PUT. It reads:

5.5.5 LDP servers MAY choose to allow the creation of new resources using 
HTTP PUT.

I think that's a pretty discouraging statement.

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

I'd argue that this is pretty much what we have.

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

If ldp:contains triples suit your needs, you're welcome to only use 
BasicContainer and never read anything about the other containers. This is 
exactly why I introduced the three types of containers. So that people 
could choose to only use the container that fits their needs. I don't 
believe it is necessary to redesign the spec to make that clear. They each 
address one of the three most common use cases we've been hearing all 
along.

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

As I said, I actually don't see anything new. There always are several 
possible solutions to a given problem.
I understand that you're actually discovering a lot of this but I must 
tell you that a lot of this is just rehashing of old issues.
Again, I don't doubt that the spec couldn't be made easier to read. I just 
don't believe it really requires changing the normative part of the spec.

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

That's fine with me.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group