Re: Symbolic vs Numeric identifiers

[Daniel LaLiberte <[e-mail]>]

 > On Mon, 24 Feb 1997, Daniel LaLiberte wrote:
 > > Another way to describe this division is symbolic versus numeric
 > > identifiers.  URLs are already symbolic, and as such, they belong in
 > > the column with filenames and domain names.

Gregory J. Woodhouse writes:
 > Actually, I think the fact that URLs are symbolic is quite incidedntal to
 > this argument.

This statement is correct in that even numeric identifiers are
symbolic - in two different ways: the digits symbolize a number, and
the identifier symbolizes something else that is not a number.

But that is not your argument.  Instead, you are arguing that a URL is
symbolic because (at least some of) its components are symbolic.  This
may be true, but I'd much rather use the argument that everything is
symbolic.  (But not everything is equally meaningful, to humans or to
computers.)

In any case, we are agreed that either a symbol or a number can be a
name or location.

 > What i-nodes and URLs have in common is tht they both contain the
 > information actually used in retrieving a file.

Well, "location" is relative.  Since we are talking about i-nodes
(which I don't know too much about, but enough to get in more
trouble), there are still more levels of indirection involved before
you get to the real data.  The i-node is looked up in whatever
structure it is contained in, and that maps to some sector/track
location on a disk, or some other data dependent on the actual media.
Now I'll bet that in some fancy file systems (e.g. RAID?), even that
is not the end of the story because pieces of one file may be distributed
across several disks.

Similarly, the URL as a "location" involves many more levels of
indirection before you get the "real" location.  This is true even if
you start at the hostname given (which must be mapped to IP number,
etc).  The "real" location is hidden on the server, and may involve
several indirections through a directory tree, or through some
executed CGI code.  Or the resource may not be at this location at
all, and the server could give a redirection to another URL or URN.

So "locations" are always relative to some context, just as "names"
are relative to some context.  All identifiers are always relative to
some context.  When people think of a "location" they are thinking of
a relatively fixed context, whereas a "name" is a more flexible
context.  (This might be the key to defining names and locations in a
way that makes everyone happy.)

 > [...] The problem is that the URN of a resource may be the "real"
 > name is not sense that it is the official name, but an i-node is a
 > "real" refernce to a file in the sense that it gives the physical
 > location of the file. These senses of "real" are quite different.

I'm having trouble guessing what you meant to say.  I argued above
that you don't have the "real" location when you thought you did.
So how are these senses of "real" all that different?  Certainly the
i-node is a lot closer to the real data.

You don't know that you (effectively) have the "real" location of a
resource until you resolve the location and get back what you wanted.

 > The URL encodes protocol specific information on how to actually
 > retrieve a resource.

I'll agree that there is an association between the symbols in the URL
and a standard protocol.  But that protocol need not be used at all if
the client knows of an alternative it can use.  In previous mail, I
listed several alternatives that clients actually do use.

dan