- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Fri, 1 Mar 2013 09:06:59 -0500
- To: Arnaud Le Hors <lehors@us.ibm.com>, Roger Menday <roger.menday@uk.fujitsu.com>
- CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
hello arnaud. On 2013-02-28 22: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 don't think that's the appropriate way of looking at it. all we ask is that LDP exposes the membership of an entry, which is a reasonable thing to ask for. we do not ask that LDP exposes *all links from anywhere to the entry*, which of course would be neither a good idea nor possible. but assuming that LDP exposes the affordances that clients need to traverse the membership relations between LDP-managed resources is something that's definitely possible, and i would assume that it would make the protocol much more useful. [[ one of the usual atom sidenotes: atom has built-in support for maintaining the original membership of an entry http://tools.ietf.org/html/rfc4287#section-4.2.11 . this is extremely useful for aggregation and repurposing of entries, because you can take each entry out of its original context, preserve the relevant context in the source information, and then put it into a new context (i.e., add them to a new collection). somebody finding it in the new context can consume it from there, or learn about its original context if they are interested. ]] cheers, dret.
Received on Friday, 1 March 2013 14:07:54 UTC