- From: Roger Menday <roger.menday@uk.fujitsu.com>
- Date: Tue, 5 Mar 2013 01:41:47 +0800
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
- Message-ID: <A97C79BD-F9B3-4B36-A9AB-87537987A659@uk.fujitsu.com>
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. 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>. >> >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 4 March 2013 17:44:48 UTC