Re: Important Change to HTTP semantics re. hashless URIs

On 3/24/13 2:28 PM, Young,Jeff (OR) wrote:
> Wouldn't the real world entity identifier get confused with the content-negotiable generic document identifier (genericResources-53)? The latter use case should also uses the Content-Location header.
If a user agent receives HTTP metadata that includes a URI in the 
Content-Location header that's different from the URI in the request 
there won't be such confusion.

If the user bookmarks the request URI it will always resolve to the 
actual content associated with said URI. Of course, what the user sees 
in their browser's address bar will change when a hashless URI denotes 
and entity isn't of type: Web or Internet document.

As I stated a long time ago, there's no reason to start Linked Data 
oriented narratives from the entity URI (when said entity isn't of type: 
Web or Internet Document). Instead, simply start with the URI (or URL) 
of a Linked Data description document since said document will 
explicitly indicate what it describes via a description subject URI.

Kingsley
>
> Jeff
>
> Sent from my iPad
>
> On Mar 24, 2013, at 2:20 PM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>
>> On 3/24/13 1:52 PM, Richard Cyganiak wrote:
>>> On 24 Mar 2013, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>> 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:
>>>>
>>>> 1. <http://dbpedia.org/resource/Barack_Obama> denotes the real-world entity 'Barack Obama' .
>>> Why can a client make this inference? I can't see any basis for the inference that the URI identifies a “real-world entity”. The described interaction does not provide any information regarding the nature of the identified resource, AFAICT.
>>>
>>> Best,
>>> Richard
>> To be a little clearer, "real-world entity" isn't the focal point of the comment per se. This is about disambiguating description document and description document subject URIs. Thus, if the request URI and the Content-Location URI are both hashless and the status returned is 200 OK a client can also infer that the request URI denotes a Web Document (or entity of type: Web Document).
>>
>> Re. #1 above, it just denotes an entity that isn't of the Web realm i.e., not of type: Web Document.
>>
>> Hope that's clearer?
>>
>> -- 
>>
>> 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
>>
>>
>>
>>
>>


-- 

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