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 <kide...@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: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.1. <http://dbpedia.org/resource/Barack_Obama> denotes the real-world entity 'Barack Obama' .Best, RichardAgreed. 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? -- 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
smime.p7s
Description: S/MIME Cryptographic Signature
