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: Peter Ansell <ansell.peter@gmail.com>
Date: Wed, 27 Jan 2010 12:45:26 +1000
Message-ID: <a1be7e0e1001261845k34deef69o4808baf3ce49c75@mail.gmail.com>
To: Ross Singer <rossfsinger@gmail.com>
Cc: Christoph LANGE <ch.lange@jacobs-university.de>, 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>
2010/1/27 Ross Singer <rossfsinger@gmail.com>:
> 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."

Taken from a different angle, this issue might be caused by the lack
of a domain specific way to say that a "document sucks" as opposed to
saying that a "person sucks". Disambiguating everything is a pipe
dream IMO. We would be much better to focus on domain specific
vocabularies, as the RDF user can actually choose what to utilise for
the property even if they can't always disambiguate the object URI
they are focusing on.


Received on Wednesday, 27 January 2010 02:45:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:55 UTC