On 10/15/11 11:40 AM, David Wood wrote:
On Oct 14, 2011, at 18:22, Kingsley Idehen wrote:...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.Hmm, no. Please remember that the nasty use of multiple addresses needed to be present only because HTTP content negotiation wasn't (isn't?) reliable in many implementations.
David,I can't correlate your comments above with the sequence I outlined in my post above.
To clarify what I meant:I am saying that when DBpedia was introduced, as part of the entire LOD project bootstrap, the narrative to the form:
1. http://dbpedia.org/resource/Linked_Data --- a de-referencable URI2. http://dbpedia.org/page/Linked_Data -- a de-referencable URI for an HTML representation of the Subject Description.
Net effect of the above was that:1. http://dbpedia.org/resource/Linked_Data indirection to http://dbpedia.org/page/Linked_Data confused people i.e., the indirection in plain sight in the Address Bar of browsers
2. Bookmarking confusion 3. Cut and paste confusion.All of the confusion arising from the fact that our narrative started from indirection under the confusing moniker de-referencable URI. Yes, the URI de-references, but the levels of indirection matter re. conventional Web use and Browser UX patterns.
Thus, I said, and meant, we could have taken a less disruptive approach re. *introductory narrative* along the following lines:
1. http://dbpedia.org/page/Linked_Data -- to conventional users, a Web Page that describes the Subjec 'Linked Data' modulo any cut and paste, bookmark, or indirection in plain sight related confusion
2. via #1 the user would have a cue e.g., @href associated with "About: Linked Data" and then have the option (post understanding its additional level of indirection and its function as an Object/Resource Name) to use it for future reference.
That's it.
To my mind, conneg was and is the best solution to this problem.
To my mind, I've never said or implied anything contrary.HTTP's ability to let user agents and servers negotiate data representation its most powerful features.
Regards, Dave
-- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
