OK, qualified harmony. I also think we're agreeing more than it
appeared to you, but I'll get to that.
Here's the best opportunity I've seen in a while to capture the current
discussion focus and move a couple of crucial inches forward on URNs.
We're talking baby steps, but we'll save a hundred hours at the IETF
armed with the following basic premises about URNs. I'd like to open the
URI working group by voting on a resolution to adopt them (or on derivative
premises as this list see fit) before we begin the *next* stage of URN
definition. Procedurally this will let the group summarily terminate
some of our more inane tangential discussions (politely, of course).
Foundation premises. See if you can sing these verses, or maybe hum along:
(1) Documents, images, and other objects may be closely related enough that
many people would agree they have the "same intellectual content". An
absolute or universal concept of "sameness", however, does not concern
us since it's a Very Hard Problem and a Very Big Meeting Time Sink.
(2) Instead we're interested in "Who says What is the same or different".
That way users benefit from different points of view, but they know
whose point of view it is. Users will need more than one point of
view because Entity A may have an opinion about objects X and Y, but
not about Z, which Entity B may have an opinion about.
(3) An entity that has an opinion on this subject (I'll call it an
IdAuthority for now -- I can't find the URN paper) can be anybody
in principle; familiar examples will be publishers and libraries.
(4) Two entities may have different opinions about any set of objects.
(5) The creator or owner (whatever that means) of an object may be one of
several IdAuthorities for that object, or it may not be an IdAuthority.
(6) An IdAuthority assigns a unique string (call it an IdDesignator for now)
to each object that is "intellectually different" in its view. The
IdAuthority name plus the IdDesignator make up a URN.
(7) The IdDesignator string is "officially" opaque, in the sense that it
has no shared semantics across all URNs, *even* if it is widely known
how to crack some of them (e.g., a Library of Congress catalog number).
We've agreed on the above points many times, but still treat them as open
questions. I'm sure we'll all miss the pleasure of agreeing on them some
more, but can we try to ratify them soon in the interests of saving time?
Now for the baby step premises (building on the foundation premises).
(8) One URN may designate a set of "intellectually equivalent" objects
(to the IdAuthority) or may designate just one object.
(9) If a URN designates a set of objects, individual objects in the set are
called "variants" with respect to that URN.
(10)Variants may be derived from all sorts of transformations of one object
into another, either by machine or by hand, but we don't deal with that
Very Hard Problem.
(11)Instead we only need to know how to tell one variant from another in
the set of variants (intellectually equivalent objects). A string
(which I'll call a "variant specifier") is used to identify a variant.
(12)A variant specifer is *not* carried below the URN level. So a variant
specifier never meets a URL. Instead a lookup of the <URN plus variant
specifier> produces a URL for that particular variant. This Very
Common Mistake wastes vast quantities of discussion time.
OK, now I haven't said what a variant specifier looks like or where it
goes (only where it doesn't go). I believe there was some particularly
focussed agreement on the needs and issues up to this point: that
"The properties of a given URN should be a valid question between
client and server and beween the URN issuer and issuee." (Tim B-L)
These properties I've collectively called the variant specifier. Now to
continue with the list of cautious premises.
(13)To paraphrase Tim, given a URN you should be able to ask some server
to return you one or more variant specifiers, one for each variant.
You select the variant you want, and pass it off together with the
URN when you need to lookup the corresponding URL.
(14)For various reasons (e.g., optimization), you may get a variant
specifier at the same time as the URN and packaged together with it.
(15)If you like the variant specifier, you may use it without needing
to looking up other variants.
(16)If you don't like the variant specifier, you may want to go ahead
and look up the other variants to see what else is available.
(17)The variant specifier is thus a thing that optionally accompanies
a URN, at the same level in our UR* scheme of things.
(18)We need a new member of the UR* family for variants. How about URV?
In my original proposal, I confused everybody by proposing 17 above as an
optional *part* of a URN, in order to avoid creating a new member of the
UR* family. But people thought I was messing with the opaqueness
requirement when I only wanted to expand the URN concept. The operation
I listed as URNroot(URN) --> URN was the trivial mapping of a <URN plus
variant specifier> to just the URN. Whatever we agree on is fine with me.
Does the above list look like it can be formalized for the meeting?
If not, how do people feel about unbundling separate premises to vote
on a subset of them?
I sure would like to get these easy issues behind us, nailed down, dead.
Then we can move on to really interesting things, like URCs.
-John