- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 27 Jan 2010 07:41:22 -0500
- 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