On 10/14/11 8:08 AM, Hugh Glaser wrote:
Hi. My colleague, Don Cruickshank asked me if it was good practice to rewrite the URI in the Address Bar to be the NIR, rather than the IR. I was surprised, but he tells me that it is permitted in HTML5. My response was "Er, yes, sounds great!"Finally we can get away from having to explain to users that the URL of the document cannot be cut and pasted as the URI! Yippeeee! Don is about to make the MyExperiment site move to this, so that URIs such as http://www.myexperiment.org/workflows/158.html will not show the ".html" And if sites such as dbpedia were to adopt this, it would mean I no longer make the mistake of doing things like "fbase:Italy owl:sameAs http://dbpedia.org/page/Italy"; when I cut and paste or whatever, and would find them in the wild a lot less. Not to mention me making the same mistake when I use my own RKBExplorer IDs. This sort of seems non-controversial - and I don't think I have seen no discussion of it here, either because it hasn't hit the radar, or it is a http://dbpedia.org/page/Slam_dunk (sic). So is it? Cheers
Hugh,How about the fact that "Address bar" implies: input capture mechanism for Resource (Object) Addresses. Thus, you should be putting: http://dbpedia.org/page/Linked_Data, in there in the first place. The indirection of a Resource (Object) Name is what users are supposed to discover post resolution of a Resource (Object) Address. That's the browser pattern as it exists today.
How about this simple sequence that doesn't break anything, bar tossing aside eternally confusing terminology:
1. http://dbpedia.org/page/Linked_Data -- address of a data object (what some like to call an Information Resource); 2. you resolve the data object address -- to a data object (actual structured data) endowed with a discernible sense of *self* via its object id property (a de-referencable URI) using good old object introspection via reflection; 3. having discovered the id of said data object (i.e., http://dbpedia.org/resource/Linked_Data) you can use it for future reference, courtesy of name indirection, with the advantage of context coherence to boot -- no brain and/or tongue twists.
Most of these problems lie in the adopted terminology bucket. "Non Information Resource" and "Information Resource" are broken terms that have arisen from provincial thinking.
-- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
