On 3/24/13 2:28 PM, Young,Jeff (OR) wrote:
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.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 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" <[email protected]> wrote:On 3/24/13 1:52 PM, Richard Cyganiak wrote:On 24 Mar 2013, at 17:39, Kingsley Idehen <[email protected]> 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, RichardTo 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
smime.p7s
Description: S/MIME Cryptographic Signature
