Re: Site metadata; my preference

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 UTC