Re: Site metadata; my preference

Patrick.Stickler@nokia.com wrote:
> 
> ...
> 
> 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.

I have two responses to this:

1. The various representations say _the same thing_. That's why they are 
multiple representations. But the metadata presumably says something 
different or it would be just another representation. That's the 
argument from theory.

2. To the extent that they do not say the same thing, the fact that they 
live at the same URI actually _does_ cause real-world problems. For 
instance there is the problem of XPointers into resources that only 
return XML "sometimes". That's the argument from practice.

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

Among other issues, it isn't even clear what the distinction is between 
representation and description.

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

You think that get7 doesn't apply to this situation, but I was one of 
the people who agitated for get7 and it was exactly this kind of 
thinking that lead to it. "I _could_ assign URIs to stock quotes and 
purchase orders, but I generally won't want or need to."

You're missing the key point that forcing people to give URIs to data is 
a _good thing_ because it allows _other_ people to refer to that 
information later. It is _never_ the right decision to hide information 
without a URI. Yes, this includes representations. In my opinion, every 
represenation should have its own URI and to the extent that this isn't 
enforced in the HTTP specs, it is just a bug.

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

That's fine. But they should not have the right to prevent me from 
trash-talking their metadata by merely choosing not to give it a URI.

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

Because it costs little and pays great dividends.

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

I don't know, I haven't used one in years. But we're trying to build a 
system that is better than a print library. Let's use the tools at our 
disposal.

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

And if I don't?

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

You're right. And this is a problem. Let's not perpetuate it. Content 
negotiation isn't used enough for the problem to seem serious but if it 
was, it would.

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

That isn't useful because the response is ephemeral. Servers have no way 
of giving you "old responses". Nevertheless, the useful bit of this idea 
is in fact captured with the etag construct.

  Paul Prescod

Received on Wednesday, 19 February 2003 17:44:39 UTC