Re: Address Bar URI

Fri, 14 Oct 2011 15:23:53 -0700 

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: [email protected] 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








Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature























					Reply via email to