Re: URN single or multiple variants (was: four-part harmony?)
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Tue, 21 Sep 93 18:16:33 +0200
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9309211616.AA05662@www3.cern.ch>
To: jak@violet.berkeley.edu (John A. Kunze)
Subject: Re: URN single or multiple variants (was: four-part harmony?)
Cc: uri@bunyip.com, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
Status: RO
From: jak@violet.berkeley.edu (John A. Kunze)
To: uri@bunyip.com
Subject: four-part harmony? (was "URN single or multiple variants")
> Regarding the thread "URN single or multiple variants", I think
> I hear at least four-part harmony. Do I hear five? If you think
> of it as four-part cacophany, sing out now (but in key).
Laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Harmony with a note wrong somewhere...
> For now I for one would really like to restrict discussion to
> high-level
> requirements. Even if we reach only a provisional consensus, the
> lower-level discussions that need to follow won't make sense to me
> unless we fix these few data points.
These data points are a data model. Never mind the low-level
implementation, my model is as follows --
I think it differs slightly from yours.
Objects may (as Terry says) be transformed in an open set of ways.
We need a vocabulary of these transformations. A given URN or
URL (in fact lets just say URI) can refer, at the issuer's
discretion,
to any subset of the products of such transformations.
Terry gave examples, something like URIs for "the works of
Shakespeare" and "A postscipt rendition of the Collins 1992
annotated hardback edition with images at 400dpi,
with Forward by Joe, in French".
When the URI is given on a document, the issuer may specify the
set of transformations which define the set of documents
accessable under that URI. So (in english, to keep it "high
level"), the object may be give a URI "colour may vary"
or "price subject to fluctuation" or "available in several
languages". In another case, [like for a mail message-id]
one gets "This URI refers only to this bit stream"
There is no "variant specifiers" in the URI.
> Resource designators have the following properties:
>
> (a) two resources have identical designators if and only if the
> IdAuthority deems them the same in content (even if another
> IdAuthority would call them different),
That is too constraining. A given IdAuthority might
issue URIs some of which are generic and some of which
are specific, and so may have many concepts of "same
in content" for different URIs.
I am trying to define this more rigorously.
> (d) they may contain an optional *variant* specifier.
We are saying that it won't. The URI is basically opaque, if
it has variant encoding that is part of the opque bit
_because_ if we formalise a structure for a variant description
then we have to formalise the variant transformations which as
Terry points out, we can't as they are too diverse.
> The variant dimensions, each one optional, are: (a) format, (b)
> encoding or archive scheme, and (c) version number (1, 2, 3, etc.
> with -1 meaning the most recent, -2 the next most recent, etc.).
You have a serial set of version numbers a la VMS.
Many versions are more complex. Supposing we require that
branches (a la CVS-RCS) are not modelled by the version number,
we still probably want a multi-level system as most people
go from 1.9 to 1.10, for example. (I think these are basically
Ted Nelson's "tumblers")
> By using the variant dimensions, an IdAuthority can continue to
> inform others what it considers different resources (as before)
> while assisting users in making up their own minds.
>
> An important property of a designator containing a variant
> specifier is that the IdAuthority assigning it implicitly agrees
> to recognize the "root" designator obtained by stripping off the
> variant specifier. Because it is a logically distinct subpart,
> user systems can remove the variant specifier to derive the root
> designator, which can then be used to query the IdAuthority about
> the root document, or about other variants that might be avail-
> able. This is particularly important when an URN designates a
> variant that is unusable by the client (e.g., an unsupported for-
> mat), because it provides a backward pointer through which more
> suitable forms may be discovered.
This can be handled with more power by typed links. A mechanism
built into the URI is in my opinion not powerful enough. And
I _like_ the URI being a simple thing which when dereferences
produces an object -- with no other functionality. That has a
simplicity upon which one can build.
Defining a URN distributed database should keep the URI group
occupied enough before trying to widen the scope.
> -John
Tim