Re: linking from resource -> container ..

While it is tempting to want to have "back links" - links from member 
resources to the containers they are member of - because it certainly can 
be convenient, we can't possibly require that of all implementations.

This would be like requiring that every web page out there links back to 
all the other web pages that link to it. That's impossible and it's just 
not the way the web works.

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

I have to admit not to understand what you mean. And for what it's worth, 
I don't think we have any such use cases, do we?
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Roger Menday <roger.menday@uk.fujitsu.com>
To:     John Arwe/Poughkeepsie/IBM@IBMUS, 
Cc:     "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
Date:   02/28/2013 05:54 AM
Subject:        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