RE: Site metadata; my preference

> -----Original Message-----
> From: ext Paul Prescod [mailto:paul@prescod.net]
> Sent: 20 February, 2003 00:44
> To: Stickler Patrick (NMP/Tampere)
> Cc: www-archive@w3.org
> Subject: 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.

Please cite any authoritative reference that reflects
that opinion. From what I can see in the authoritative
specs, there is no such constraint that representations
"say the same thing". 

An autogenerated abstract of an 800 page document is
just as valid a representation, according to the specs,
as is a PDF embodying the entire document. As is a JPEG
image of the cover page. As is an HTML document having
the document Table of Contents with links to the
relevant sections.

IMO, there are actually no formal constraints whatsoever
on what a representation might be, and that is why I don't
want my SW agents to depend on representations of resources,
even if those resources are supposedly bodies of knowledge.

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

But those cases do not violate the specs. They are perfectly
acceptable sets of variant representations.

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

A simple example (I hope ;-)

An RDF statement

  ex:foo ex:lastModified "2003-01-01"^^xsd:date .

is not part of the resource ex:foo. It is external knowledge
*about* ex:foo. Thus it has no place in a *representation*
of ex:foo (whatever that resource might be).

Thus, descriptive knowledge *about* a resource is not valid
content for any representation *of* that resource.

Now, if ex:foo' denotes the body of knowledge about ex:foo,
then the above statement *would* be acceptable content within
a representation of ex:foo' but not of ex:foo.

Is that clearer?

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

I'm sorry, but is 'get7' a typo, or are you referring to something 
other than GET?

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

Fair enough. And this view is fully compatible with MGET. If it
is strongly advised, as a matter of best practice, to always identify
all resources published/managed by a given server, then a server
supporting MGET could explicitly name both the body of knowledge
known about a resource as well as the particular response as well
as any other significant resource relevant to the request.

But users need not know any other URI but that of the resource in
order to get a description of it. Just as they need not know any
other URI but that of a resource in order to get a representation
of it.

There seems to be some kind of presumption that URIs are inextricably
tied to representations and that the only way one can interact with
a server in terms of a URI is to get a representation.

The URI denotes a *resource*. And any interaction with a server is
something indirect and separate from that actual resource. GET
interaction involves representations. MGET interaction involves
descriptions. This is a clean, intuitive distinction. In both
cases there is a *single* URI denoting the resource itself. But
one then specifies by the verb how one wishes to interact with
the server in terms of that URI.

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

That is a completely separate issue. Please don't confuse the
discussion about the merits of header tags versus new verbs with
this separate (albeit important) issue.


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

Again, this is a separate issue to that which I have been focusing
specifically on here.

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

Who ever said I was speaking of a print library? Digital libraries
also have "card catalogues". 

But regardless, the analogy still applies.

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

Too bad, but that's not a problem with using MGET for accessing
descriptions of resources -- no more so than not getting URIs denoting
each representation (or even each server response) is a problem with
the existing definition of GET.

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

My point is that this is not a problem with MGET. It is a more general
problem that should be addressed separately.

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

Just because most servers presently can't doesn't
mean we can't talk about those distinct resources...

Still, again, this is a separate issue, and not a problem with MGET.

Patrick

Received on Thursday, 20 February 2003 02:44:42 UTC