Re: yet another sidetrack on what a URI identifies

On Tuesday, Jan 14, 2003, at 19:17 US/Eastern, Roy T. Fielding wrote:

>> I totally agree.  I think we got into this mess because people started
>> to think there was a single mapping function from each URI-syntax
>> string to the-one-thing-it-identifies.  But people can and do use one
>> http URI to identify many different things, most crucially including a
>> web site AND the main thing described on that web site (what I think
>> you would call the thing whose representation is retreived via the
>> URI).
> I just call it a resource and a representation.

We know.  Your "resource" is a vague thing which can be
a robot or a web page.  That vagueness makes a system
which is less useful than a system in which the URI
identifies specifically the web page.

>  There is no need to
> come up with any other, longer terms.

Your systems operate in a scope in which the resource
itself is never actually involved - the only things involved
in HTTP are URIs and representations. Nothing
in HTTP (as you agreed) allows one to make an experiment
to say what is or is not the resource.

My systems operate in a scope in which the resource *is*
involved, and your definition is too vague to be useful.
You say there is no need for another term.
Others need a distinction.   Various people on this
list have been crying out for clarity here.

>   URIs identify resources.  GET
> (or its semantic equivalent in non-HTTP protocols) can be used to
> obtain representations.  A web page is a representation at time t,
> often composed of other representations.  There is no magic involved.

Some of your terms are vague, but here I think I can say they are
just wrong.   A web page is not a representation at time t.
It is a a work which varies. It may have many representations.
It is not just a representation of its subject. It is
an important social thing in itself.  If your theory does not
include it (which it does not) then your theory is
inadequate as a theory of the web as a communications medium.

Nobody is saying there is any magic involved.
Have you actually considered and thought about the
model in which the URI identifies the web page?
You will find that all of HTTP and the functionality of REST
all works just as well.


> The identifier indirectly identifies a concept and, in response to
> GET, an HTTP server maps that identifier to a representation that
> has been assigned (somehow) by the authority.  A normal user doesn't
> care about this because they never see the method -- all they see is
> the link -- but their limits of perception do not define how the Web
> works.  The method is still required for Web software to make
> interoperable decisions and complete the request, and therefore it
> is part of the system whether or not the average user is aware of it.
>> I think you address this by ignoring the web page in the middle, and
>> saying the URI identifies the encryption algorithm, and what you see
>> when you put that address in your browser is a representation of the
>> algorithm (or maybe a rendering of that representation).
> That is hardly "ignoring" the issue.  It is a fundamental aspect of
> how HTTP works.  It is what makes caching possible, and defines why
> the "freshness" of a web page matters.  It is also the only model of
> URI that takes into account all of the other HTTP methods.

That is nonsense. You imply that if we take the URI as
identifying the web page, web caching will break.

It is also nonsense to say that your model in which the web page has no
existence is any easier to extent to other methods.

>> But that's just not how people think.  People think there is a web
>> page at
> No, they think that when they traverse that link they get a Web page
> of the W3C.  They don't care how W3C implements its server.

I don'tthink Sandro said anything about implementation of a server.
I read "People think there is a web page at"
to mean that people use a URI to identify a web page.
I must agree.

>>   Every published use of a URI I've seen
>> (away from W3C) in the past few weeks (since I started watching
>> carefully) frames the URI like "visit us at <web address>" or "my 
>> website
>> is <web address>" or "I read it at <web address>" or "<web address>
>> has some great stuff".  All of those forms demonstrate that people use
>> URIs to denote web pages, web locations, web sites, etc (*information*
>> resources), not the abstract entities (the weather, some car, some
>> dog, the moon) which we might learn about from those sites.
> They use such forms to denote what they are saying:
>    "visit us" == traverse.
>    "my website" == this is where I am the authority.
>    "I read it at" == what I got from URI at time t'.
>    "URI has some great stuff" == future GETs of this resource will
>                                  have useful representations.
> All of those statements are consistent with the REST model, but
> simply use more common (less precise) terminology.

A model in which URIs identify web pages is a REST model,
and a rather better one than one where they don't.  I would
really like you to work through the model and see that it doesn't
break anywhere. You may have to introduce another term.
But you;ll end up with something much more useful IMHO.


Received on Friday, 24 January 2003 00:15:06 UTC