W3C home > Mailing lists > Public > public-lod@w3.org > January 2010

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 27 Jan 2010 07:41:22 -0500
Message-ID: <4B603472.5090506@openlinksw.com>
To: Richard Light <richard@light.demon.co.uk>
CC: Christoph LANGE <ch.lange@jacobs-university.de>, Linked Data community <public-lod@w3.org>, Vyacheslav Zholudev <v.zholudev@jacobs-university.de>, Florian Rabe <f.rabe@jacobs-university.de>
Richard Light wrote:
> In message <4B5F84B9.9020601@openlinksw.com>, Kingsley Idehen 
> <kidehen@openlinksw.com> writes
>>
>> As for the HTML part, this is about providing an HTML representation 
>> of the Object (Resource) metadata rather than being confined to a 
>> single representation. Note, these days RDF based resource 
>> descriptions are served up in quite a few representations: HTML, HTML 
>> + RDFa, N3/Turtle, JSON, RDF/XML, TriX, TriG etc..
>
> 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.
>
> A Topic Map fragment (in various serializations) would be one obvious 
> candidate.  Topic Maps and RDF can be seen as complementary ways of 
> supporting search, inference, etc., each with its own strengths.
>
> In addition, it recently occurred to me that the same mechanism can 
> also be used to deliver an XML representation of the non-information 
> resource. In other words, a machine-processible version of the rich, 
> textual, human-readable HTML representation mentioned above.  This 
> could simply be in XHTML, or more interestingly in an XML application 
> format such as TEI, EAD or Docbook.
>
> Bringing full XML into the infochain would allow machine processes 
> access to a fuller story, whether they are reasoning with the data 
> they have found or constructing data views to present to end-users.  
> At present, Linked Data browsers seem to be limited to displaying sets 
> of RDF triples as their "result sets".
>
> 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.

I am still sensing that we continue to pay dearly for the 
incomprehension that the term "Information Resource" accords. One such 
example is the assumption that an Information Resource doesn't have a 
Generic HTTP URI, it only has a URL (translation: you don't describe 
information resources in triples).  Taking this statement further, its 
akin to saying, re. "Bottle of Milk":  the Milk has a URI while the 
bottle has a URL, whereas in reality  you need distinct Identifiers 
(URIs) for the Milk and the Bottle, should you seek to describe both of 
these items, properly. Then, whenever you seek the actual data 
representing the description (Milk of Bottle) you de-reference the 
associated Generic HTTP URIs because the URL is part of said URI.

Kingsley
>
> Richard


-- 

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 12:41:57 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:24 UTC