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

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

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


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Roger Menday <roger.menday@uk.fujitsu.com>
To:     John Arwe/Poughkeepsie/IBM@IBMUS, 
Cc:     Linked Data Platform Working Group <public-ldp-wg@w3.org>
Date:   04/30/2013 05:04 PM
Subject:        Re: ldp-ISSUE-62 (siblings): Creating Sibling Containers 
[Linked Data  Platform core]




hi John, 

> What happens if I want to record some new/other information about a 
Networth resource ? Then I need a way to create a new container. 

I think that's a non sequitir.  The reason you'd need a new container is 
if you needed a new HTTP interaction point with LDPC semantics. 


But, that is what I need [*] - a new HTTP interaction point with LDPC 
semantics !!
- e.g. a container called 'options' (or some other financial term), which 
has some stated membershipSubject, and which operates like the asset or 
liability ones. 


 I can record info about a NetWorth member anywhere (at any URL) using 
RDF.... including on a different server. 


> Sibling containers share a common membershipSubject. For example, the 
Asset and Liability containers are siblings 'inside' a Networth resource. 

LDP does not constrain the storage ("inside").  It gives you no guarantee 
that the state of /nw1 includes the triples in the container resources; 
nor does it impede doing so.  It's logical/common sense enough to do so, 
just not guaranteed by the spec


Wrt "inside": 
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'. 

Anyway, I understand that by de-referencing /nw1, you are *not* guaranteed 
to see the triples about the container resources. Infact this was one of 
motivators for raising issue-51. If we resolve issue-51 by specifying that 
there should be links from a resource to its containers, then it this lack 
of guarantee doesn't matter. 



This appears to devolve back to "how do I create containers".  We've had 
conversations about that before, and had some level of consensus IIRC that 
the spec would remain silent and the primer/deployment document might well 
show how the "spec as it is" could be used by implementations to create 
containers.

I've been implementing LDP recently, and this is definitely an issue. 

*IF* we choose to resolve this issue with PUTting a new LDPC resource, 
then I can see that the resolution would be something for the deployment 
guide. 

But, this sibling case isn't the same as the 
container-creating-another-container case.

thanks, 
Roger 


[*] 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. 

Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 




From:        "Linked Data Platform (LDP) Working Group Issue Tracker" <
sysbot+tracker@w3.org> 
To:        public-ldp-wg@w3.org, 
Date:        04/29/2013 11:32 AM 
Subject:        ldp-ISSUE-62 (siblings): Creating Sibling Containers 
[Linked Data Platform core] 



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

http://www.w3.org/2012/ldp/track/issues/62

Raised by: Roger Menday
On product: Linked Data Platform core


Sibling containers share a common membershipSubject. For example, the 
Asset and Liability containers are siblings 'inside' a Networth resource. 

What happens if I want to record some new/other information about a 
Networth resource ? Then I need a way to create a new container. 

A simple solution might be to PUT a new sibling Container to some explicit 
address. Alternatively, as the LDPC siblings are form a container, POSTing 
to a networth could also do this sibling creation. This has the 
implication that every LDPR is an LDPC ...

see also 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0068.html for 
another example.