Re: Issue-34 Back_to_Basics proposal

Roger, I don't see the basis for the assertion that /nw1 is more 
"informational" than the container in the same example.  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.
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




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/27/2013 06:35 PM
Subject:        Re: Issue-34 Back_to_Basics proposal




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