Re: Important Change to HTTP semantics re. hashless URIs

"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
>
>
>
>
>
>
>