- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Wed, 19 Feb 2003 09:25:47 -0500
- 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 UTC