W3C home > Mailing lists > Public > www-tag@w3.org > March 2012

Re: URIs, used in RDF, that do not have associated documentation

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Wed, 28 Mar 2012 10:03:29 -0400
Message-ID: <4F731A31.20900@arcanedomain.com>
To: トーレ エリクソン <tore.eriksson@po.rd.taisho.co.jp>
CC: Jonathan A Rees <rees@mumble.net>, www-tag@w3.org, tore.eriksson@gmail.com

On 3/27/2012 10:44 PM, トーレ エリクソン wrote:
>> No, the representations can have characteristics that the resource doesn't.
> Sure, media type, length, MD5 checksum,&c.

...and maybe more. It's very common to have a URI that identifies some
document (speaking informally), and to find that the representations
include things like advertising, breadcrumbs pointing to related pages on
the "site" etc.

I don't think RFC 2616 is particularly clear on whether this is good
practice or not. You could make the case that surely the resource itself
"includes" the advertising and breadcrumbs. I think there's another
coherent point of view, which I tend to subscribe to, which is that a
representation may include information, including advertising, etc., that
we don't consider to be inherent in the state of the resource. Thus, if I
have a URI for, say, a press release from the US White House such as [1],
and I make an RDF statement that I "like" it, that doesn't necessarily mean
that I am commenting on all the navigation chrome on the top, or the
"blogroll" on the right.

I think the URI identifies just the press release if the White House says
it does, and it identifies the page with all the chrome if they say it
does. If they make no statements, it may be hard to tell from the outside
which is intended, in which case RDF statements about the URI may be
somewhat ambiguous.

Nonetheless, I think it's misleading to imply that the only interesting
things that a representation might add that aren't inherent in the state of
the resource are plumbing-related headers like checksums and Content-type.


Received on Wednesday, 28 March 2012 14:04:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:14 UTC