Re: ldp-ISSUE-62 (siblings): Creating Sibling Containers [Linked Data Platform core]

hi John, 

> > But, that is what I need [*] - a new HTTP interaction point with LDPC semantics !! 
> Then that is different from the original request to which I responded, which was: I want to record some new/other information about a Networth resource
> 
> The answer to that original question is very simple: PUT/PATCH.  Add your triples.  Done.
> 

We got wires crossed. 

I want to interact with a rogersnetworth LDPR via it's LDPC 'sub-ordinates' to manage resources representing my assets and liabilities. But, what if the assetContainer and liabilitiesContainer resources are not provided (or not locatable) on the server ?

In the ref [1] that Arnaud circulated yesterday, there is the reasonable proposal of creating containers in the normal way of creation (using an existing container). But, in the case of a single rogersnetworth resource, that method doesn't quite work. 

[1] http://www.w3.org/2012/ldp/meeting/2013-02-11#resolution_5

> I don't have any special objection to a server allowing the creation of new interaction points in this way, given that the factory role in general is optional.  It's simply a different problem than was originally stated.  Per Arnaud's email, there is an action open to talk about container creation so we can use this email thread to get consensus on another aspect of that action's output, fair enough.  I'm reasonably sure that not all implementations would allow that sort of create.
> 
Yes, I am quite sure that all implementations would not allow that kind of create. In an server driven application-specific API, I wouldn't expect this kind of function to be available.

> 
> > Every LDPR has a representation with a number of triples. 
> > An LDPC is a subset of those triples - same-subject, same-predicate. 
> > That's what I mean by 'inside' - maybe I should've used 'subset'. 
> 
> As stated those are insufficient constraints.  <LDPR> a ldp:Resource.  <LDPC> a ldp:Container.  Assuming <LDPR> and <LDPC> are both GETtable URLs, satisfies your stated constraints.  I would not consider one necessarily related in ANY way to the other.  
> 

Well, they are related by definition because in the same-subject, same-predicate definition of a LDPC it has a single LDPR resource as the same-subject. I would hope that HTTP client can discover this - using the membershipSubject triple for example. 

regards, 
Roger

> A server might suggest they are related by returning both in a single GET response, but as a client I'd have no idea what use I can make of that.  Issue-51 certainly would help - I hedge only b/c (a) it is not yet so resolved (b) unless it's a MUST, the problem still exists, and getting consensus on MUSTs can be tricky. 
> 
> 
> > [*] I -really- think that in most cases the server will decide what I need, and offer it to me. And as a dumb client, I should just follow that lead. 
> 
> The trick may be in how one accomplishes that in code.  It assumes that the server knows something of the client's intent, and they have a shared name for that intent to facilitate communication of the offer.  I don't think LDP alone would be sufficient for that -- and we have enough problems doing that in meatspace.  I have no doubt people can define enough to cover specific cases, and add that onto LDP. 
>