- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 4 Mar 2013 19:30:16 +0100
- To: Roger Menday <roger.menday@uk.fujitsu.com>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
- Message-Id: <94C36C61-4B42-47D4-A02D-0CEA7335C28B@bblfish.net>
On 4 Mar 2013, at 18:41, Roger Menday <roger.menday@uk.fujitsu.com> wrote: > > My explanation of why this is an important issue was a bit of a ramble on the call just earlier, so, I'll have another go at explaining: > > Navigation is on the web is moving (i.e. browsing) between domain data resources. Along on the way we may want to interact to create new resources. This interaction is done using other methods POST, PUT, etc, via 'interaction' resources (which are discovered/linked inside the LD). > > The networth example of the spec (example 2) is a case in point. i.e. given a networth resource (by searching, navigation, ...), should I want to interact with the resource I need to know where the associated containers are. This isn't back-linking, it is linking in the flow of the application. Thanks that makes sense. I agree that backlinking (linking from an LDPR to its LDPC) should be possible, and use a well understood vocabulary, and it is very likely a good practice. Wether it should be mandatory is something I am not sure about. There will certainly be use cases where backlining will be essential for the software to work. In any case the rdfs:member property in my view is not clear enough for a backlinking to a container, since rdfs:member can be used to describe any type of membership property. So if your LDPR just said <.> ldp:member <> . Then this would not tell you that the resource <.> was a Container and that the life of this resource ( <> ) depended on it. So your LDPR would therefore need two relations to express this: <.> a ldp:Container; ld p:member <> . This is one other reason why I think one needs an ldp:contains relation. You would then only need to write <.> lpd:contains <> . hope that helps. > > Roger > >> > >> >>> 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. >>> >> >> Based on ex.2 in the spec: I believe that from a networth resource, it must be possible to discover the container(s) that a client then needs to interact with to manage its assets and liabilities details. >> >> I don't understand why you consider this to be a "back link" ? >> >> Roger >> >>> <> >>> 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>. >>> >> > Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 4 March 2013 18:30:56 UTC