Re: Important Change to HTTP semantics re. hashless URIs

On 3/24/13 2:26 PM, Barry Norton wrote:
> On 24/03/13 18:23, Kingsley Idehen wrote:
>> On 3/24/13 1:59 PM, Barry Norton wrote:
>>> On 24/03/13 17:52, Richard Cyganiak wrote:
>>>> On 24 Mar 2013, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> 
>>>> wrote:
>>>>> Thus, if a client de-references the URI 
>>>>> <http://dbpedia.org/resource/Barack_Obama> and it gets a 200 OK 
>>>>> from the server combined with 
>>>>> <http://dbpedia.org/page/Barack_Obama> in the Content-Location 
>>>>> response header, the client (user agent) can infer the following:
>>>>>
>>>>> 1. <http://dbpedia.org/resource/Barack_Obama> denotes the 
>>>>> real-world entity 'Barack Obama' .
>>>> Why can a client make this inference? I can't see any basis for the 
>>>> inference that the URI identifies a “real-world entity”. The 
>>>> described interaction does not provide any information regarding 
>>>> the nature of the identified resource, AFAICT.
>>>>
>>>> Best,
>>>> Richard
>>>
>>> Agreed. And I don't like the 'give a 200 and trust clients to spot 
>>> the header' approach. I especially don't like that the header will 
>>> become a 'we can add that later' academic ideal and we'll 
>>> effectively lose the NIR/IR distinction altogether (if we already 
>>> haven't).
>>>
>>> Barry
>>>
>>>
>>>
>> That's simply isn't the point.
>>
>> This is about incorporating more metadata into the Linked Data URI 
>> disambiguation process i.e., interpret what the Content-Location 
>> value delivers. The response header implies that the server is 
>> pointing you to the location of a document associated with the 
>> request URI.
>>
>> From a Linked Data perspective, it simply means that we have another 
>> heuristic for disambiguation.
>>
>> The goal is to have options, especially an option that kills the 303 
>> distraction with regards to hashless URIs.
>>
>> An optional heuristic is just that, an option.
>>
>> Aren't you fed up of 303 distractions re. Linked Data and hashless URIs?
>>
>
>
> I am. But half of the discussion is caused by having two different 
> 'options'. A third doesn't solve that.
>
> Barry
>
>
>
We need more options to solve this kind of politically-elastic problem. 
Here's the current list of options I am aware of:

1. use hash URIs -- here you have implicit indirection enabling implicit 
disambiguation.
2. use hashless URIs and 303 redirection - here you have explicit 
indirection via 303 redirection enabling disambiguation.
3. use hashless URIs, 200 OK, and Content-Location header -- here the 
indirection is aided by simply drawing inference from the existence of 
two URIs in the response metadata i.e., content-location URI and the 
request URI.
4. use .well-known/host-meta -- here the RDF document returned enables 
an agent disambiguate entity and description document URIs.
5. a variant of #3 whereby the client uses the RDF document returned to 
enable disambiguation of entity and description document URIs.

Bottom line, there isn't a golden solution, but from an architectural 
perspective it's always a win to be "horse for courses" [1] compliant :-)

We always get into trouble when we try to mandate a golden option. It 
never works. The Web works because when all is said an done it is 
"horses for courses" compliant.

Links:

1. http://en.wiktionary.org/wiki/horses_for_courses .

-- 

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