Re: Address Bar URI

On Fri, Oct 14, 2011 at 1:57 PM, Kingsley Idehen <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<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 <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<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<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<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