- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 25 Mar 2013 07:12:31 -0400
- 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>
- Message-ID: <5150311F.5060905@openlinksw.com>
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. -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 25 March 2013 11:12:57 UTC