Re: URN single or multiplevariants

timbl (Tim Berners-Lee)
Date: Thu, 23 Sep 93 20:55:26 MET DST
From: timbl (Tim Berners-Lee)
Message-id: <9309231855.AA13361@ >
Subject: Re: URN single or multiplevariants
Cc: timbl
(John's message is indented)

	Date: Thu, 23 Sep 93 00:46:56 -0700
	From: (John A. Kunze)
	Message-Id: <>

	> Date: Tue, 21 Sep 93 18:16:33 +0200
	> From: Tim Berners-Lee <>
	> ... Harmony with a note wrong somewhere...

	OK, qualified harmony.  I also think we're agreeing more than it
	appeared to you, but I'll get to that.

Wrong. We are I now see clearly *disagreeing*. You and I.
Check out what my last message actually said...
You say:

	(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".

*Disagree*. Whether two things arethe same should *NOT* be regarded
as a function of who you ask.  It is a function of what transformations
you are allowing which preserve "sameness".  As a person I reserve the
right to use different criteria for different purposes.  I want to
be able to give names to generic works, AND to particular translations,
AND to particular versions.  I want a richer world than you propose.
I don't want to be constrained by your two-level system of
"documents" and "variants". There are objects, which may be more or
less generic.  I may have many or no levels.

I was proposing that the properties of a name be given in terms
of the attributes of the document which may vary for the same
name.  This provdies a framework for actually talking about
what we *do* mean by "sameness".  It allows us to tackle the
problem without constraining ourselves. I feel your variant
specifier constrains the model without acually helping us much.

	    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.

If youtry to map my world onto yours, you will need a large
number of virtual "entities" for each combination of criteria.

	(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.

You certainly can't link "entities" to real peopl eor IdAuthorities.

	We've agreed on the above points many times, but still treat them as open

Wrong, John.  You have reiterated them, but noone has agreed them.
	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.

Hang on hang on hang on.  A property of a URN is like "any document
with this URN is in the same language".  Your variant specifier
spacifies a particular variant, not such a property.

	(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.

**NO**. This is more like contraphrasing me.  I don't believe in
variant specifiers, so I wouln't have said that.  I can imagine
saying "Give me a URN for a postscript version of document <urn>".
I can imagine saying "Give my a URN for a 600x300 pixel 5-colour GIF
of document <urn>".  I can imagine there being an infinite
number of possible variants on a document, so I wouldn't ask for a list.
But what I would get would be another, more specific, URN.

I guess this is abstract, but I think it is useful and simple.

	(18)We need a new member of the UR* family for variants.  How about URV?

Aaaaagh! :-)

	In my original proposal, I confused everybody [...]

Why stop now and spoil it :-) :-) :-)

	[...]Then we can move on to really interesting things, like URCs.

A good simple URN will take the world a lot futher than an
intricate gothic URC.  IMHO.  Because they will be used
for many other things than libraries.


Sorry for the strong emphasis... I want this to go places too.