Message-Id: <aaffe4fe080210030fb9@[165.227.40.13]>
Date: Mon, 28 Nov 1994 19:06:36 -0800
To: uri@bunyip.com
From: goph-mn@proper.com (Paul Hoffman, Gopher/Web maintainer)
Subject: Re: going too far?
Your two concerns (giving background for discussion, URLs as long-lived
entities) are interesting. I agree with you and your arguments on the
background issue. However, it seems to me that you are *too* concerned
about the lifespan of URLs.
One of the mixed blessings of URLs is that most of them are *not*
transparent. I can tell from most URLs, certainly http: ones, which site we
are talking about. URLs, if well designed, can include valuable information
in them. For example, consider:
<http://www.bigstate.edu/chris-rogers/uri-discussion>
I can guess who is the maintainer of the document, and even sort of what
the document is probably about. Of course, many URLs aren't that well
designed, that I put the responsibility for that directly on the content
providers. All it takes is a bit of creativity and the help of the sysadmin
staff. If you can't get those, you can hire them in the commercial Internet
market.
The following discussion assumes the use of http: URLs, although many of
the same arguments work for gopher: URLs as well. Both these schemes allow
an information provider to add a significant amount of interface to the
information gathering process.
>We now see a move toward
>providing location information in potentially long-lived documents (eg
>published in journals and magazines and probably books, but especially
>online documents). We of all people ought to understand that that is
>a bad idea. We should *NEVER* be putting URLs into documents.
I disagree here. URLs are not inherently long-lived, but many of them will
be. I believe that your admonition should be along the line of "don't use
URLs in documents unless you can be reasonably sure that the URL will
outlive the document."
In the continuing absence of URNs, there is still plenty we can do with
URLs. For example, a bad URL would be:
<http://www.bigstate.edu/chris-rogers/uri-to-dollars-draft-01>
while a good one would be:
<http://www.bigstate.edu/chris-rogers/current-uri-to-dollars-draft>
All this takes is about 30 seconds on Chris Rogers' part to duplicate the
current version and give it a new name or, if the OS supports it, make a
symbolic link. Assuming that the bad URL was published before the good one
was created, the old file, uri-to-dollars-draft-01, is left around so that
old links don't break. Even better, Chris might replace
uri-to-dollars-draft-01 with a short message telling the reader to look at
current-uri-to-dollars-draft, or, if they really want to see
uri-to-dollars-draft-01, to look at
<http://www.bigstate.edu/chris-rogers/uri-to-dollars-draft-01-old>.
Another example of a bad URL is one that points only to a PostScript
document. A better URL would point to a metadocument that lets the user
then choose the representation: text, PostScript, sound, and so on. Of
course, this was all supposed to have been built into Web and Gopher
clients and servers, and by and large hasn't been or is univerally ignored.
In other words, there is plenty that can be done *today* with URLs that
make them somewhat URN-like.
- Making them to "the most current" version of a document
- Making them to metadocuments that let the user choose which form they
want the data
- Adding useful information in the URL itself, such as names and
indications of hierarchies
Granted, there are still some problems with the good URL. For example,
Chris Rogers might not work at Big State next year and they remove her user
account, or the sysadmins at Big State might move the web server to a
different domain name. However, these problems are no worse than listing
your current postal address in a paper that you publish in a journal.
>Unfortunately, if we use URLs for URNs we may be hosing our
>credibility, so we should be extremely careful about this, and make
>absolutely clear what we are doing.
Agreed, but only for bad URLs. Quite frankly, I expect that many of the
first URNs will be bad as well (ignoring user requests in the resolution,
not really being what the referencing document said they were, in a single
language or format, ...) Good URL design, and possibly a few commercial
Internet sites who one can assume will be here in five years, can overcome
many of your objections to using URLs in documents.
--Paul Hoffman
--Proper Publishing