Re: What would break? Re: httpRange-14

On 3/26/12 2:09 PM, Leigh Dodds wrote:
> Hi Kingsley,
>
> On Mon, Mar 26, 2012 at 6:38 PM, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>> ...
>> Leigh,
>>
>> Everything we've built in the Linked Data realm leverages the findings of
>> HttpRange-14 re. Name/Address (Reference/Access) disambiguation. Our Linked
>> Data clients adhere to these findings. Our Linked Data servers do the same.
> By "we" I assume you mean OpenLink. Here's where I asked the original
> question [1]. Handily Ian Davis published an example resource that
> returns a 200 OK when you de-reference it [2].

Support was done (basically reusing our old internal redirection code) 
whenever that post was made by Ian.
>
> I just tested that in URI Burner [3] and it gave me broadly what I'd
> expect, i.e. the resources mentioned in the resulting RDF. I didn't
> see any visible breakage. Am I seeing fall-back behaviour?

As per comment above its implemented. We have our own heuristic for 
handling self-describing resources. My concern is that what we've done 
isn't the norm i.e., I don't see others working that way, instinctively. 
You have to be over the Linked Data comprehension hump to be in a 
position emulate what we've done.

TimBL can do the same re. his collection of tools, but the fundamental 
concern remains re. other developer profiles seeking to exploit Linked 
Data. Should they have to perform the following:

1. follow response headers
2. make sense of relations.

My example about rdfs:isDefinedBy remains, a majority of ontologies 
constructed by folks who grok the fundamentals still don't include 
rdfs:isDefinedBy relations. Thus, I've resorted to fixing those 
ontologies when ingested instead of pinging the ontology authors. The 
same thing applies (even more) to wdrs:describedby which ended getting 
fixed in response to my "tale of two missing predicates" post [1] around 
the time of the Toucan post etc..

>
> To answer your other question, I do understand the benefits that can
> acrue from having separate URIs for a resource and its description. I
> also see arguments for not always requiring both.

Yes, they are are important for the Linked Data system as espoused by 
TimBL's meme. They aren't so important in scenarios where said fidelity 
provides no value e.g., coarse-grained structured data. The issue is 
that we have multiple sub-systems (or dimensions) within this dexterous 
Web and we need to be able to exploit said dimensions based on an agreed 
set of rules.
> As a wider comment and question to the list, I'll freely admit that
> what I've always done when fetching Linked Data is let my HTTP library
> just follow redirects. Not to deal with 303s specifically, but because
> that's just good user agent behaviour.
>
> I've always assumed that everyone else does the same. But maybe I'm
> wrong or in the minority.
>
> Are people really testing status codes and changing subsequent
> processing behaviour because of that? It looks like there's little or
> no breakage in Sindice for example [3].
>
> Based on Tim's comments he has been doing that, are other people doing
> the same? And if you have to ask if we're not, then who is this ruling
> benefiting?

We do the same, but we also go beyond (i.e., what you call a fall-back). 
The prime concern though remains the requirement to name things 
unambiguously where the application realm is Linked Data. By this I 
mean: Linked Data oriented tools should adhere to Linked Data principles 
as espoused by the Linked Data meme. Failure to do that skews the 
essence of the meme and the specific fidelity it brings to the Web as a 
whole.

Data Integration is a realm that benefits immensely from the Linked Data 
meme principles. It is also one of the most important exploitation areas 
for enterprises. The equivalence fidelity of Linked Data which is 
basically about mundane inference exploitation via owl:sameAs and 
InverseFunctionalProperty based relations remains one of the most 
powerful demonstrations of Linked Data virtues to both Enterprise and 
Web customers. We lose the aforementioned capability if we conflate 
identifiers for Entity Names (generic URIs)  and Data Access Addresses 
(URLs). A 200 OK on any URI ultimately leads to this problem. Post 
processing HTTP response metadata alleviates the perceived 303 costs and 
issues with frameworks that partially support HTTP response codes, but I 
remained concerned about such heuristics being at the front door re. 
Linked Data introduction and eventual comprehension.

To conclude, the issue here is that we collectively seek to reducing the 
barrier of entry re. Linked Data comprehension and exploitation, the 
problem is that there are some misaligned concerns:

1. 303 redirection being problematic re. slash URIs -- what you, Ian, 
Jeni et al. are concerned about

2. Name/Address or Reference/Access disambiguation via HttpRange-14 
findings -- what others that worry about the proposal are concerned about

3. Adding yet another heuristic to a mercurial quest -- ditto.

As Tom indicated in his post, explaining the core Linked Data concepts 
(using anecdotes aligned to target audience) does work, and the end 
result is acceptance of the 303 redirection heuristic re. the 
fundamental indirection that Linked Data is fundamentally about.

Links:

1. http://www.mail-archive.com/public-lod@w3.org/msg06723.html - post 
re. tale of two missing predicates

2. http://lists.w3.org/Archives/Public/public-lod/2010Nov/0091.html - 
Phil Archers contribution to the conversation that lead to 
wdrs:describedby fixes.

>
> Tim, could you share more about what application behaviour your
> inferences support? Are those there to support specific features for
> users?
>
> Cheers,
>
> L.
>
> [1]. http://www.mail-archive.com/public-lod@w3.org/msg06735.html
> [2]. http://iandavis.com/2010/303/toucan
> [3]. http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan
> [4]. http://www.mail-archive.com/public-lod@w3.org/msg06746.html
>
>


-- 

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