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