W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

Re: Site metadata; my preference

From: Jonathan Borden <jonathan@openhealth.org>
Date: Wed, 19 Feb 2003 09:25:47 -0500
Message-ID: <008801c2d822$cebb1510$b6f5d3ce@L565>
To: "Yves Lafon" <ylafon@w3.org>, "Mark Baker" <distobj@acm.org>, <timbl@w3.org>
Cc: <www-tag@w3.org>

Yves Lafon wrote:

> >
> > And moreover, if representations were to vary in the way that GET+Meta
> > requires, that suggests to me that we're dealing with two resources, not
> > one.  Hence my preference for the response header solution, which uses
> > two URIs.

GET+Meta is a nice lightweight, relatively clean way to get the job done.
TimBL has provided a nice (albeit slightly hackish) technique of appending a
",foo" onto a URI to create the meta-URI. That is neat -- at the end of the
day when the bits hit the silicon, most grand architectures turn into a
series of hacks.

>
> And why, instead of adding a new HTTP method or header, why not simply use
> content-negotiation? the meta-info will have its own ETag (provided ETages
> are consistent in the server), its own URI. Even if it is automatically
> generated (see XMP extraction of a JPEG or whatever format).
>

This is an excellent argument. If there ever was a use case for conneg, this
is it. I'd say that

Accept: application/xml+rdf

is a strong indication that the "metadata" about the URI is what is desired.

How to decide between the above two approaches? Is there any *benefit* to
giving the "metadata" a different URI than the "data"? I'd say I prefer the
RDF to be the authoritative data/description about some resource so conneg
gets my preference for that reason. (I'm not sure I like the term "metadata"
as it implies some secondary importance to that *data*)

Jonathan
Received on Wednesday, 19 February 2003 09:26:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT