Re: URNs and Meta-Information

Kevin Altis (kevin@scic.intel.com)
Sun, 17 Oct 1993 03:06:47 -0800

Message-Id: <9310171010.AA13195@rs042.scic.intel.com>
Date: Sun, 17 Oct 1993 03:06:47 -0800
To: Peter Deutsch <peterd@bunyip.com>,
From: kevin@scic.intel.com (Kevin Altis)
Subject: Re: URNs and Meta-Information

At 12:30 AM 10/17/93 -0400, Peter Deutsch wrote:
>Personally, I think the current format of
>"prefix:authority:publisher:id" fits the bill nicely
>(modulo the final debate on syntax). I also think that it
>is perfectly feasible to build a dereferencing system
>based upon this and known technologies such as DNS (see
>below).

In "prefix:authority:publisher:id" what is the definition of publisher?
Once you introduce another "domain" below "authority", you introduce a form
of hierarchy that won't be valid for a long period of time, possibly a
shorter period of time than an URL pointing directly to the item.

The 3:00am example
Let's say I create a media piece called "Virtual Bud Light" (VBL) and form
a company called Short Lived Productions to publish it. Then I get an URN
from the MOLT (Media Of Little Taste) authority, VBL is put up on the local
artists server, the URL is http://backwater.anarchy.com/SLP/VBL, but most
people know the URN urn:molt:slp:1, which they saw in a "Mondo 3000"
article. Suddenly, VBL becomes a cult piece and Gannett buys the rights to
VBL, which decides to leave it on the original server because there main
server is out of space, but I have to withdraw the original URN as part of
my contract because Gannett is now the publisher and the new URN is
urn:molt:gannett:6347632. Eventually, sales fall off and Gannett sells the
rights back to me, but I've since become a big corporation myself and SLP
no longer exists, so I get yet another URN. Funny though, through all of
this, the piece still exists at its original location.

What's the point. Well, publishers come and go, rights to product change
frequently, more so with the new medium. If we want URNs to be persistent,
then the labeling that we use has to hide various changing elements
associated with a published item that can be resolved when the URN is
looked up.

This is sort of the same kind of problem we have with changing email
addresses today. Right now, I can be reached at kevin@ssd.intel.com (which
really points to kevin@rs042.scic.intel.com), but pretty soon it will be
altis@ibeam.intel.com. As long as I stay within the authority for my email,
I would prefer that I be able to pick some unique id within the email
authority, say altis@inside.intel.com and my email address wouldn't ever
change, no matter how many times my *actual* mail destination changes,
unless I leave the company (my email authority).

The reason the email aliasing works for a fairly large number of addresses
is that there are "hidden domains" so I expect a given authority to have
sub-authorities, but those sub-authorities will not be part of the URN;
they will only be known to the authority.

ka