- From: Seth Russell <russell.seth@gmail.com>
- Date: Mon, 25 Mar 2013 09:53:17 -0700
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-lod@w3.org" <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>, "public-webid@w3.org" <public-webid@w3.org>, "dbpedia-discussion@lists.sourceforge.net" <dbpedia-discussion@lists.sourceforge.net>
- Message-ID: <CACfYUR4UnrPHRgPJU9=3bRcoeejR83zBNVTd6BGn95P+fW=1xA@mail.gmail.com>
"You can't actually get referents from HTTP protocols: for that, you have actually read (and understand) the documents that specify the referents." -- Pat Hayes I am sure that is true for some value of "You" and some value of "get". But can not some automated process actually "get" that which it uses and publishes as a reference from the proposed HTTP protocol? Seth Russell Podcasting: tagtalking.net Facebook ing: facebook.com/russell.seth Twitter ing: twitter.com/SethRussell Blogging: fastblogit.com/seth/ Catalog selling: www.speaktomecatalog.com Google profile: google.com/profiles/russell.seth On Sun, Mar 24, 2013 at 9:12 PM, Pat Hayes <phayes@ihmc.us> wrote: > > 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 > > > > > > >
Received on Monday, 25 March 2013 16:54:28 UTC