Re: Important Change to HTTP semantics re. hashless URIs

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

Received on Sunday, 24 March 2013 18:27:06 UTC