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





Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to