Re: Site metadata; my preference

On Wed, 19 Feb 2003, Mark Baker wrote:

> But "Accept: application/rdf+xml" says "Send me an RDF representation
> of this resource", which is different than "Send me an RDF
> representation of the metadata about this resource".  You wouldn't
> expect that if "Accept: text/plain" gave you "I'm Dan's car", and
> "Accept: image/gif" gave you a picture of the car, that
> "Accept: application/rdf+xml" would give you some RDF about the
> metadata about the car; you'd expect RDF about *the car* (or
> more technically, the state of the car), such as its colour,
> its location, its mileage, etc..

Well... As I said earlier, I consider that http:// points to an HTTP view
of a resource, which is already a protocol view of this resource. So
information about the methods supported are indeed part of the same set of
metadata you may expect from this particular view. So it's not "this car"
vs "the car" but what we be retreived is the particular HTTP view of this
instance of a car.

> RDF gets a bum rap as a "metadata" solution, when it's a perfectly good
> data solution.
>
> > > To Yves;
> > >
> > > Re OPTIONS, that's a good example, but it appears to me (as I've used
> > > it quite extensively), that it falls on the other side of the equation
> > > that evaluates the trade offs with respect to latency.  In the uses I
> > > made of it, an extra round trip was a non-starter.
> >
> > Well OPTIONS is intended to be extensible, may have a body both in request
> > and reply (even if it is undefined right now) and is mainly about
> > cummunication options on either the esrver or a specific resource.
> > But what is communication option?
>
> Some aspect of the protocol in use.
>
> > In the light of a HTTP URI, which is to
> > me an HTTP view of a more generic object, it is metadata of this
> > particular HTTP view of the resource. Also when you get a representation
> > of the metadata of a resource you only get a facet of it. How the metadata
> > of the HTTP view and the HTTP view of the metadata of this object collide?
>
> They collide by not being representations of the same resource.  For
> one, it makes assertions with the URI ambiguous; are they about the
> data or the metadata?  (as has been discussed ad nauseum)
>
> > If they are _clearly_ distinct, then OPTIONS has its use as being part of
> > a subset specific only to HTTP and accessible only via HTTP means.
>
> OPTIONS isn't about resource metadata, it's about communication options,
> like which methods are implemented.  It could be extended to communicate
> WSDL-like stuff, like the acceptable/supported data formats, or other
> supported protocols, protocol upgradeability, etc..  None of those
> have anything to do with resource metadata, AFAICT.

For an HTTP view, it would just be a part of the metadata of this
particular view, even if it is not part of the metadata of the general
resource that will be viewed through this HTTP filter.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Monday, 24 February 2003 09:34:43 UTC