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: Ross Singer <rossfsinger@gmail.com>
Date: Tue, 26 Jan 2010 21:35:49 -0500
Message-ID: <23b83f161001261835y24f56cfg56cace2eb9c21d15@mail.gmail.com>
To: Christoph LANGE <ch.lange@jacobs-university.de>
Cc: Georgi Kobilarov <georgi.kobilarov@gmx.de>, Linked Data community <public-lod@w3.org>, "Zholudev, Vyacheslav V." <v.zholudev@jacobs-university.de>, "Rabe, Florian" <f.rabe@jacobs-university.de>
On Tue, Jan 26, 2010 at 7:35 PM, Christoph LANGE
<ch.lange@jacobs-university.de> wrote:

> So far, I don't understand why it is recommended to have separate URIs for the
> non-information resource and the (RDF/XML) information resource.

This is because the URI for the RDF/XML is an identifier for the
_document describing_ the non-information resource, but not the actual
resource.  They need to be disambiguated, because otherwise you
wouldn't ever be able to assert anything about the RDF describing the
resource (e.g. provenance or quality) - the RDF is its own resource,
as well.

To use an example Ian Davis uses to describe this:

If you say http://iandavis.com/id/me sucks, you're saying Ian, the
human being, sucks.

If you say http://iandavis.com/id/me.rdf sucks, you are objecting to
the way he made his FOAF document.

(hey, it's his example, not mine)

"You are not your FOAF."

BTW the # uri style doesn't require all of your resources to be in
some long document; it just provides the same disambiguation as above,
without any need for .htaccess or redirects.  So while an HTTP client
requests:
http://id.loc.gov/authorities/sh2002000569 (which renders an HTML or
RDF document), the non-information resource's URI is
http://id.loc.gov/authorities/sh2002000569#concept -- distinct from
the former (they are different URIs), but available from the same HTTP
request.

-Ross.
Received on Wednesday, 27 January 2010 02:36:23 UTC

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