W3C home > Mailing lists > Public > public-lod@w3.org > October 2011

Address Bar URI

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 14 Oct 2011 18:48:25 -0400
Message-ID: <4E98BC39.8080601@openlinksw.com>
To: public-lod@w3.org
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 

> 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


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 Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 14 October 2011 22:48:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:17 UTC