Re: linking from resource -> container ..

On 3/1/13 11:58 AM, Ashok Malhotra wrote:
> Back links can be useful but are expensive.

Isn't that perception an application oriented implementation detail?

Imagine if that consideration drove the design of HTTP  :-)

> Here is a usecase we may want to consider.
> If a LDPR can belong to several containers then if the LDPR is to be 
> deleted
> we would want to remove it from the containers before deletion. A back 
> link
> from the LDPR to the containers it belongs to would allow you to do that.

That's application behavior.

Kingsley
> All the best, Ashok
> On 3/1/2013 11:03 AM, David Wood wrote:
>> Hi Arnaud,
>>
>> On Feb 28, 2013, at 16:11, Arnaud Le Hors <lehors@us.ibm.com 
>> <mailto: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 
>>> <mailto:roger.menday@uk.fujitsu.com>>
>>> To: John Arwe/Poughkeepsie/IBM@IBMUS,
>>> Cc: "public-ldp-wg@w3.org <mailto:public-ldp-wg@w3.org> Working 
>>> Group" <public-ldp-wg@w3.org <mailto: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_ 
>>> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
>>> 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
>>>
>>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen