RE: Site metadata; my preference

> -----Original Message-----
> From: ext Paul Prescod [mailto:paul@prescod.net]
> Sent: 19 February, 2003 03:43
> To: Stickler Patrick (NMP/Tampere)
> Cc: www-archive@w3.org; distobj@acm.org
> Subject: Re: Site metadata; my preference
> 
> 
> Patrick.Stickler@nokia.com wrote:
> > 
> > ...
> > 
> > Oh, come now. Were the authors of that statement thinking 
> "GET vs. any
> > possible arbitrary verb that might every be added to HTTP" 
> or "GET vs. POST"?!
> 
> Actually it was probably "GET vs. any possible arbitrary verb 
> that might 
> ever be added to SOAP." The point is that the Web has a _single_ 
> namespace. Every URI identifies one resource. If you put an 
> MGET there, 
> then you've got two resources at the same URI: "X" and 
> "metadata about 
> X".

Not at all.

If that were so, then you could argue that to server multiple
variant representations -- each of which is a distinct resource
separate from that denoted by the URI, and each could have their
own URI -- that you have one URI and many resources at that URI.

The URI only denotes one resource. GET returns a representation
of that resource (*not* the resource) and MGET returns a description
of that resource (*not* the resource). I see no issue.

> What if I want to refer to "metadata about X" as its own 
> first-class 
> resource, do I need a whole new URI scheme?

This has been addressed already in these discussions. If a server
wishes to specify a URI to denote the body of knowledge known
about a given resource, and return that URI to identify that
body of knowledge explicitly, it can. Just as a server is free
to return URIs to denote individual representations returned by
GET. No difference.

Though, if you read my comments to Tim regarding Books vs.
Dictionaries vs. Cards, I think it is likely that even though
folks *could* assign URIs to the body of knowledge known
about a resource by a server, they won't generally want or
need to.

> > I'm going to be hard to convince that it was the former.
> > 
> > And this argument is not even applicable against MGET because with
> > MGET documents *are* identified by URI!
> > 
> >  HTTP GET  {URI} -> resource
> >  HTTP MGET {URI} -> description
> 
> Look, if I want to say that {URI} is wrong, then I can express that
> 
> {URI} <full:of> shit
> 
> Now what if I want to say that the URI's metadata is wrong? 

  {URI'} <full:of> shit .

And whatever {URI'} is, is up to the owner of the site hosting
the resource denoted by {URI}. It could be autogenerated according
to some regular transformation of the resource URI, such as
a (very ugly) infix:

   http://example.com/foo             the resource 'foo'
   http://example.com/META/foo        description of 'foo'
   http://example.com/META/META/foo   description of description of 'foo'
   ...

or any other means that the server wishes. It doesn't matter.

> If I don't 
> have a URI for that metadata, I can't do it. 

True. But the same is true for any resource. The point is that
most folks wont want/need any URI denoting that body of knowledge
explicitly, so why force every server implementation to provide
them. 

How many cards in card catalogues have unique identifiers denoting
the card itself?

> What if I want 
> to say that 
> the document is authored by one person but the metadata is 
> authored by 
> another?

No problem. Go ahead. If you have the URI denoting that metadata.

> You've said that "sometimes" the metdadata could have its own 
> URI. This 
> implies that the person owning the metadata can choose whether other 
> people can make statements about it. But that's not the way the Web 
> works. If the thing is on the Web, people should be able to make 
> statements about it, whether the owner wants them to or not.

Well, what about representations that are not given explicit URIs
by the server?!

If a PNG representation of a photo is great, but the GIF representation
is crap, and I want to say so, I have no guaruntee that I'm going to
be provided any unique URIs by the server in a response to GET which
explicitly denote those representations.

How is this any different?! It's not.

Perhaps this is a fundamental flaw of the entire Web architecture. Perhaps
every response should have its own unique URI, such as a uuid: URI. After
all, one might want to also say something about each and every response
one might get from a server...

Patrick

Received on Wednesday, 19 February 2003 03:25:04 UTC