On Mar 24, 2013, at 12:39 PM, Kingsley Idehen wrote: > All, > > Here is a key HTTP enhancement from Hypertext Transfer Protocol (HTTP/1.1): > Semantics and Content note from IETF [1]. > > " > 4. If the response has a Content-Location header field and its > field-value is a reference to a URI different from the effective > request URI, then the sender asserts that the payload is a > representation of the resource identified by the Content-Location > field-value. However, such an assertion cannot be trusted unless > it can be verified by other means (not defined by HTTP). > " > > > Implications: > > This means that when hashless (aka. slash) HTTP URIs are used to denote > entities, a client can use value from the Content-Location response header to > distinguish a URI that denote an Entity Description Document (Descriptor) > distinct from the URI of the Entity Described by said document. 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:
I think not quite exactly as you describe it: > 1. <http://dbpedia.org/resource/Barack_Obama> denotes the real-world entity > 'Barack Obama' . > 2. <http://dbpedia.org/page/Barack_Obama> denotes the Web Document that > describes real-world entity 'Barack Obama' -- by virtue of the fact that the > server has explicitly *identified* said resource via the Content-Location > header . I think in fact all it can infer is 1. <http://dbpedia.org/resource/Barack_Obama> denotes an entity, and 2. <http://dbpedia.org/page/Barack_Obama> denotes the Web Document that describes that entity. You can't actually get referents from HTTP protocols: for that, you have actually read (and understand) the documents that specify the referents. Still, this is all excellent progress. Pat > > Basically, the Toucan Affair [2][3][4] has now been incorporated into HTTP > thereby providing an alternative to 303 redirection which has > troubled/challenged many folks trying to exploit Linked Data via hashless > HTTP URIs. > > Implementations: > > As per my comments in the Toucan Affair thread, our ODE [5] Linked Data > client has always supported this heuristic. In addition, I am going propose > implementing this heuristic in DBpedia which will simply have the net effect > of not sending a 303 to user agents that look-up URIs in this particular > Linked Data space. > > Linked Data Client implementation suggestions: > > I encourage clients to support this heuristic in addition to 303 with regards > to Linked Data URI disambiguation. Implementation costs are minimal while the > upside extremely high re., Linked Data comprehension, appreciation, and > adoption. > > Links: > > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#page-15 . > 2. http://blog.iandavis.com/2010/11/04/is-303-really-necessary/ -- Is 303 > Really Necessary post by Ian Davis. > 3. http://lists.w3.org/Archives/Public/public-lod/2010Nov/0090.html -- > mailing list thread . > 4. > http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan > -- example of heuristic handling . > 5. http://ode.openlinksw.com -- ODE Linked Data consumer service, > bookmarklets, and cross-browser extensions. > 6. http://bit.ly/YxW21k -- Illustrating Semiotic Triangle using DBpedia's > Linked Data 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 > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
