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

In message <4B603472.5090506@openlinksw.com>, Kingsley Idehen 
<kidehen@openlinksw.com> writes

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

Quite right: sorry.  I meant URI here.

>> In general, allowing a single non-information resource URL to be 
>>associated with a wide variety of machine-processible formats gives us 
>>the potential to expand the power and expressiveness of the Linked 
>>Data web in new ways.
>Not totally following you, bearing in mind Linked Data is about 
>entity-attribute-value model graph tapestry and representation 
>(various). That said, I do agree that multiple representations of the 
>content of information resources is a good and powerful thing courtesy 
>of HTTP's inherent sophistication etc.. Any two uniquely identified 
>things can participate in a 3-tuple claim (triple) via a uniquely 
>identified predicate.

Maybe that's just a matter of how we choose to scope the term "Linked 
Data".  My point relates to what you might term the machine-processible 
web, and the information engineering that it allows you to do.  If you 
want to confine the term "Linked Data" to the EAV bit of that world, no 
problem.

My key point is the unique, persistent URIs have a practical utility 
that goes beyond what you can do with them in Linked Data mode (in your 
sense).  And that mixing and matching Linked Data, Topic Maps and 
full-text XML (etc.) can potentially take us to some exciting new 
places.  (But then that's hardly news.  I remember discussing the value 
of URNs for this sort of purpose some time around 1994.)

Best wishes,

Richard

-- 
Richard Light

Received on Wednesday, 27 January 2010 12:57:53 UTC