RE: Site metadata; my preference

> > 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.

Eh? What?

And what if the resource is an RDF/XML instance?!!! Or an XTM
instance for which an RDF/XML representation is available?

How then do you differentiate between the RDF that is the
representation of the resource from the RDF that is the
description of the resource?!

The semantics of GET simply do not fit the needs of 
knowledge retrieval about resources. GET is for getting
*representations* not descriptions, and any attempt to
make it do double duty will result in confusion.

> 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 also strongly prefer one URI, but if we only have one URI
then IMO we cannot use the representation-specific verbs
GET, PUT, etc. and must have new verbs to interact with
descriptions of resources.

> (I'm not sure I like the 
> term "metadata"
> as it implies some secondary importance to that *data*)

I agree. That's why I've been using the terms 'description'
or 'body of knowledge' about a resource. Yes, it is metadata,
but it's not a second class citizen of the web.

Patrick

Received on Thursday, 20 February 2003 02:21:05 UTC