Re: Content negotiation: Why always redirect from non-information resource to information resource?

Damian Steer wrote:
> On 27/01/10 12:41, Kingsley Idehen wrote:
>> Richard Light wrote:
>
>>> If you see the URL as representing the subject of discourse (=
>>> non-information resource), there are also non-RDF representations of
>>> that subject which can be associated with the URL (and requested using
>>> the 303 mechanism, by specifying a suitable Accept header).
>> URLs Identify the Location (Address) of Information Resources (documents
>> or data containers). Thus, I don't see them as representing the subject
>> of discourse. I see them as containers of data which may or may not be
>> structured. Re. Linked Data, they are containers of structured
>> descriptions, and by virtue of Generic URI abstraction bound to the
>> Referent Identified by the entire Generic HTTP URI.
>
> You seem to be using URL and URI to make a distinction here? To the 
> best of my knowledge there is no difference (although the name 'URI' 
> is preferred).
>
> Damian
>
>
Damian,

**Not meaning to lecture, just clarifying my world view.**

Here goes:

A URL is a kind of URI, of course. Its an HTTP scheme URI, but it isn't 
Generic re. function, by definition its a Resource Locator.  Locators 
locate Things, these things are physical in a given realm.

A Generic URI, isn't Location specific, its an Identifier with Locator 
capabilities; this is why I go through the pain of typing "Generic" when 
communication about the Linked Data atom.

If you toss "information resource" term in the bin (my world view) and 
see a "Resource" as  physical Web medium Thing, compound in nature, then 
I think my view becomes clear:

1. URL (a kind of HTTP URI) -- Locator mechanism for something (which 
may be compound in nature re. constituency)
2. Generic HTTP URI -- An Identifier with Data Access capabilities 
courtesy of HTTP scheme.

I am splitting out the inherent duality (Identity / Access)  of Generic 
HTTP URIs as expressed above.

Linked Data, via Generic HTTP URI abstraction enables 
low-cost-specific-binding of a Data Object (Item, Entity, err... 
Resource) to its metadata (description) bearing Resource (or Information 
Resource).

A human being's embodiment is a physical Resource, but not in the Web 
Realm. Thus, a HTTP URI that has me as Referent cannot deem me as being 
a Web Resource (those realms of perception and comprehension are truly 
disjoint). At best, "I" can be referred-to from Web Resources containing 
descriptions of perceivable aspects of "Me"  -- expressed in an EAV/CR 
style graph pictorial. The data representation of the graph pictorial 
re, aforementioned Web Resource (that contains EAV/CR pictorial) is 
negotiable.

I can describe aspects of "Myself" (via an EAV/CR style graph pictorial) 
on a piece of paper (surface), and in my world view, the Paper (a 
Resource) sits at a Location (URL identifies that).

Personally, Data Object, Data Item, Entity are much clearer monikers -- 
re. Reference and Address related matters -- than Resource. Likewise, 
saying URI (without qualification or and never mentioning URLs) doesn't 
clarify key subtleties etc..  Hence my refusal to use "URI" without 
qualifying what kind I mean when communicating in  general.

A URL with a fragment identifier is a cheap route to Generic and 
unambitious HTTP scheme based Identifier. But, there is a critical role 
change that kicks in when the HTTP URI becomes generic i.e., it no 
longer solely about location identification.

A URL without the fragment identifier component is a *mentally 
disruptive* route to a Generic and unambiguous HTTP scheme based 
Identifier, but it works well due to its RESTfulness .

Again, not lecturing (since I know you understand of this in your own 
way), just clarify the underlying world view that fashions my 
terminology choices etc. :-)

Links:

1. http://bit.ly/eBLv1 -- old post titled: The URI, URL, and Linked Data 
Meme's Generic HTTP URI .

-- 

Regards,

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

Received on Wednesday, 27 January 2010 19:37:12 UTC