Re: Address Bar URI

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 URI
2. 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