Address Bar URI

On 10/14/11 6:22 PM, Kingsley Idehen wrote:
>>
>>
> ** Note intending to be rude or inflammatory etc.. **
Meant to say:

** NOT 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.

-- 

Regards,

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