Re: Address Bar URI

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