On 3/24/13 2:26 PM, Barry Norton wrote:
We need more options to solve this kind of politically-elastic problem. Here's the current list of options I am aware of: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: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).BarryThat'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
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
smime.p7s
Description: S/MIME Cryptographic Signature
