Re: linking from resource -> container ..

Hi Arnaud,

On Feb 28, 2013, at 16:11, Arnaud Le Hors <lehors@us.ibm.com> wrote:

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


I think you may be over-reaching here.  The Web doesn't have back links, which is why it scales.  However, we use back-links widely whenever we can, such as with blog ping-backs or within a system that can manage bi-directional links such as wikis.

That being said, I don't support back-links in LDP because I don't see what value you get from them (but you do get a responsibility for maintaining them!).  I *think* it is sufficient for containers to link to resources within them and for those containers to be updated when a resource is deleted or moved.

There is still a practical problem of how to update client-side caches of a container when a member is deleted from that container, though.  Callimachus returns a 200 OK from a delete (after much discussion), but is currently forced to include an entity (body) that provides a list of container links that need to be invalidated.  That kind of status message is allowed by RFC 2616 for an HTTP DELETE, but it feels like a bit of a hack to get around browser caching.  Fortunately, browsers don't generally support DELETE directly, so the issue becomes one of defining a REST API and a social contract on how to use it from JavaScript and other clients.  That's exactly the same problem faced by LDP.

Regards,
Dave
--
http://about.me/david_wood



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