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 <[email protected]>
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
