linking from resource -> container ..

hi John,

> Roger, I don't see the basis for the assertion that /nw1 is more "informational" than the container in the same example.  

By informational, I'm talking from the perspective of a accountant. 

Looking at the <> and the <../nw1> resources ... there is lot more information in the /nw1 resource which is of interest to an accountant. 

The <> resource only exists for interaction purposes in example 2 (because /nw1 needs to manage assets and liabilities). 

> The text following it is a bit problematic in its use of unqualified "resource" (RDF...?  certainly.  HTTP...?  possibly.  both?), but let us assume things follow LD best practices so it's both.

> Your assertion appears to then boil down to: given any HTTP resource, which might or might not be some form of container itself and/or whose state might be managed by HTTP interactions with other HTTP resources (containers), a client Must be able to introspect all this at run time using LDP. That seems like a pretty tall order, especially if you are at all interested in making existing resources do this - those are what they are, and any changes you require are adoption barriers.
> 
Actually, quite the opposite - respecting that is a very strong motivator.

So, there is a layer of completely 'normal' LD. i.e. read-only LD. 
And LDP should add the capabilities to change/write/update/evolve that LD. 

Roger
> If I try to simplify the latter to just LDPRs rather than all HTTP resources, it might feel incrementally less intrusive however it would also negate your original assertion (/nw1 is not asserted to be an LDP in the example AFAICS) so that doesn't seem to do much good.  
> 
> 
> If on the other hand I start out from <>, your original statement of need appears to be fulfilled.  This does not seems obviously different than many other things on the Web: depending on where you start and which links you follow, different information (including further capabilities) comes into your view.
> 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> hi John, 
> 
> > 
> > p.s. In the spec, why is only links from the container to the LDPR ?
> > I think the links in the other direction are the more important ones. 
> 
> Member-collection links can be more important, I think it just depends on what your favorite app happens to be.  The submission was trying to enable a very broad range of apps, 
> including those for example where the members have no idea what "collections" link to them. 
>  So again, from an interaction model standpoint, it seemed minimally necessary to define how a client navigates from collection to its members.  The (implicit) assumption was that some additional app-specific ontology would be layered on top to cover additional cases... and if those turn out to be widely interesting enough, those might even find their way into later specs layered on top of LDP.  There are lots of other groups doing discipline/app-specific ontologies, my goal certainly would be to enable re-use of all that existing work. 
> 
> 
> Looking at example 2 in the spec: 
> 
> <> 
>    a ldp:Container; 
>    ldp:membershipSubject <http://example.org/netWorth/nw1>; 
>    ldp:membershipPredicate o:asset. 
> 
> <http://example.org/netWorth/nw1> 
>    a o:NetWorth; 
>    o:asset <a1>, <a2>. 
> 
> 
> The /nw1 resource is the "informational resource" - the one which might be written on the side of a bus. Given only this URL, I need to know the address of the containers which are then used to manage assets and liabilities. 
> 
> Roger