Re: A simpler way of thinking about containment and membership?

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.

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

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

> 
> [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?

> 
> [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.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group