On 10/14/11 9:09 AM, Ian Davis wrote:

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





Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to