Re: Address Bar URI

On 10/14/11 9:09 AM, Ian Davis wrote:
>
> On Fri, Oct 14, 2011 at 1:57 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     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.
>
>
> Wow. I find this breathtaking. I agree that "Most of these problems 
> lie in the adopted terminology bucket. " but you state that at the end 
> of a post that is laden with opaque terminology that only you seem to 
> use in this community and throws up barriers for new people.
Ian,

Yes, opaque technology to you. Luckily, not for the rest of the 
computing universe.

Kingsley
>
>
> Ian


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen