Re: Address Bar URI

On 10/14/11 4:28 PM, Michael Smethurst wrote:
>
> Have to say from a pragmatic point of view that using replaceState to 
> switch between IR and NIR (or whatever we're supposed to call them) 
> URIs feels like bad advice for most developers
>
> Users in older browsers are going to see (and copy and paste) one set 
> of URIs whilst users of more modern browsers are going to see (and 
> copy and paste) another
>
** Note intending to be rude or inflammatory etc.. **

Could I rephrase your statement for sake of clarity, due to context:

"Users in older browsers are going to see (and copy and paste) one set 
of *URLs* whilst users of Linked Data or URI abstraction aware browsers 
are going to see (and copy and paste) another"

>
> So you end up exposing two sets of URIs to the web and to Google et 
> al. Google only consolidates page rank for inbound links on 301s (and 
> not 302s or 303s) so you'd end up throwing your findability away for 
> an esoteric distinction that no-one quite understands. Or understands 
> but doesn't quite agree with :-)
>
Yes, basically, this is about putting the proverbial cart before the 
horse. A UX for handling resource locators (URLs i.e., a specific kind 
of URI) is now being used to handle URIs in a generic sense, courtesy of 
indirection.

>
> For now cross browser support for pushState and replaceState is pretty 
> shonky [1]. It's useful when product managers demand an "app like 
> experience" because you can do all the shiny ajax stuff without nasty 
> ajax #s and it all looks good on their iDevices. They don't need to 
> know that's not what most people see :-)
>
> With apologies for bringing up S*E*O on a Friday evening. And that 
> aside it just feels like asking people to add more complexity to 
> sidestep existing complexity that they don't understand / see the need 
> for in the first place.....
>
>
> [1] http://caniuse.com/#search=replaceState
>

+100

Especially as this ultimately impedes comprehension of the Web's 
evolution into a global data space of introspective resources (data 
objects that reflect a sense of self via their EAV/SPO pattern based 
structure, serializable across the wire in a variety of formats ).

I posted a while back (a year or so) that in retrospect, when 
introducing DBpedia the flow *should* have been:

1. http://dbpedia.org/page/Linked_Data -- a bookmark friendly and 
familiar address (URL) of an HTML based resource that describes 'Linked 
Data' .

2. #1 unveils: http://dbpedia.org/resource/Linked_Data -- basically a 
de-referencable resource (object) name endowed with self reflection 
that's discernible from the retrieved resource hence the About: XYZ 
pattern in DBpedia's HTML pages.

3. http://dbpedia.org/resource/Linked_Data -- then surfaces as an 
alternative data access mechanism courtesy of indirection (which now has 
functional/usage context) delivered by URI abstraction; basically, you 
have a generic and extremely powerful data source name added to the mix.

Browsers, with their current world views and associated UX patterns, are 
palatable with 1-3 above. People should leverage indirection when they 
have a clear sense of its existence and purpose. That (IMHO) helps 
reduce the riddle-like nature of Linked Data and the power of URI 
abstraction in general.

Kingsley
>
>
>
> -----Original Message-----
> From: public-lod-request@w3.org on behalf of Hugh Glaser
> Sent: Fri 10/14/2011 4:22 PM
> To: Norman Gray
> Cc: Linking Open Data; Don Cruickshank
> Subject: Re: Address Bar URI
>
> I am really no expert - really, so showing my ignorance here.
> I understand:
>
> JS:
> window.history.replaceState('Object', 'Title', '/another-new-url');
> will do it happily, but I guess HTML5 is required.
> You can use it to change path and search strings, but not protocol or 
> domain, I understand.
>
>
> On 14 Oct 2011, at 15:26, Norman Gray wrote:
>
> >
> > Hugh, greetings.
> >
> > On 2011 Oct 14, at 13:08, Hugh Glaser wrote:
> >
> >> 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.
> >
> > Can you expand on this a little?
> >
> > Is this some HTML5 cleverness that lets one declare in the HTML what 
> the address bar should display?  Or is it some Javascript 
> kludge^Wgadget that does it, in which case what is the sense in which 
> this is 'permitted' in HTML5 and wasn't before?
> >
> > All the best,
> >
> > Norman
> >
> >
> > --
> > Norman Gray  : http://nxg.me.uk
> > SUPA School of Physics and Astronomy, University of Glasgow, UK
> >
>
> --
> Hugh Glaser,
>               Web and Internet Science
>               Electronics and Computer Science,
>               University of Southampton,
>               Southampton SO17 1BJ
> Work: +44 23 8059 3670, Fax: +44 23 8059 3045
> Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
> http://www.ecs.soton.ac.uk/~hg/ <http://www.ecs.soton.ac.uk/%7Ehg/>
>
>
>
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain 
> personal views which are not the views of the BBC unless specifically 
> stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in 
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this. 


-- 

Regards,

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