W3C home > Mailing lists > Public > public-lod@w3.org > March 2013

Re: Important Change to HTTP semantics re. hashless URIs

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 25 Mar 2013 07:12:31 -0400
Message-ID: <5150311F.5060905@openlinksw.com>
To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
CC: "public-lod@w3.org" <public-lod@w3.org>, "public-rww@w3.org" <public-rww@w3.org>, "public-webid@w3.org" <public-webid@w3.org>
On 3/25/13 5:18 AM, ☮ elf Pavlik ☮ wrote:
> Excerpts from Pat Hayes's message of 2013-03-25 04:12:37 +0000:
>> 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.
> sounds to me like enough to connect WebID and WebID profile but it will still take second request to get that profile, just like 303 pattern... apologies if I miss something!
> http://www.w3.org/2005/Incubator/webid/spec/#the-webid-profile

Yes, this enables us bury the hashless HTTP URI distraction that still 
swirls around WebID. It also enables looser coupling between a denoted 
entity and its profile document.

This is all about a standardized heuristic for killing off the concerns 
about 303 re. hashless HTTP URIs.



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

Received on Monday, 25 March 2013 11:12:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:31 UTC