W3C home > Mailing lists > Public > uri@w3.org > January 2002

The Neo-Classical View of URI Classification

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 25 Jan 2002 12:13:09 +0200
To: URI <uri@w3.org>, URN <urn-ietf@lists.netsol.com>, <www-archive@w3.org>, <www-talk@w3.org>
Message-ID: <B876FC55.C4BD%patrick.stickler@nokia.com>

This document outlines what I am calling the "Neo-Classical View"
of URI Classification, which is a revised version of that outlined
in draft-pstickler-uri-taxonomy-00 motivated by recent discussions
on this list and elsewhere.



Based on both official and unofficial publications and discussions,
my understanding of the classical view is as follows:

Variant 1:

  Digital        |  Non-Digital
 <--URL--------> |

Variant 2:

  Digital        |  Non-Digital

These two variants appear to have co-existed from early on in the
history of the internet, if not from the very beginning. Some may
argue to the contrary, that only variant 2 has existed, but common
confusion and consternation by a non-trivial segment of the web
population regarding URLs which do not resolve to anything (because
they denote non-digital, possibly abstract, resources) is sufficient
to establish the existence of the first variant.

The first two variants were, as a result of much debate, merged
into the contemporary view, which really is just the removal of
any distinction between URI classes in terms of resolution to
digital versus non-digital resources; i.e.:

  Digital        |  Non-Digital

Thus, the prior debate was not really resolved, but simply abandoned.

Furthermore, the contemporary view, as did the classical view
before it, totally disregards the notion of a non-resolvable URI,
correlating to a kind of constant, i.e. the URP.


My own recent proposal, in draft-pstickler-uri-taxonomy-00, can be
considered a third variant of the classical view, which admittedly
is not entirely compatible with either of the above two variants,
due to the restriction on URNs to denote only digital resources:

Variant 3: 

  Digital        |  Non-Digital
 <--URL--------> |
 <--URN--------> |


The Neo-Classical View:

In light of the recent discussions regarding the nature of URNs
and their denotation of digital versus non-digital resources, I
would like to offer a revised model for URI classification which
allows for URNs to denote either digital or non-digital (accessible
or non-accessible) resources.

I will call this new view the "Neo-Classical View":

  Digital        |  Non-Digital
 <--URL--------> |

Clearly, this is an adoption and extension of the first variant of
the classical view -- but the criteria for differentiation between
these URI classes is different than traditionally applied to the
variants of the classicial view, and thus may be more palatable
to proponents of the second variant of the classical view.

A common theme or topic in the debates between the first two variants
of the classical view was the notion of name versus location, such
that e.g. a URL denotes a location and therefore must resolve to
a resource.

However, in draft-pstickler-uri-taxonomy-00, I propose a different
set of criteria for differentiation which I feel is better suited
than the name vs. location distinction.

The following table shows the differentiation of URI Classes
per the Neo-Classical View based on the criteria of resolvability
to digital resource and indication of agencies/authorities in the
URI itself for scheme definition, minting, and resolution:

                               |          URI          |
                               |     |     |    URP    |
                               |     |     |-----------|
                               | URL | URN | URT | URV |
| Resolves to Digital Resource |  *  |  o  |  x  |  x  |
| Scheme Authority in URI      |  *  |  *  |  *  |  *  |
| Minting Authority in URI     |  *  |  *  |  *  |  x  |
| Resolution Agency in URI     |  *  |  x  |  x  |  x  |
where   * = required
        o = allowed
        x = disallowed

Note that the compromise is the presence of 'o' rather than '*' in
the first row for URN. My previous variant of the classical view
disallowed URNs from denoting non-digital resources.

Because knowledge about the binding of URNs to URLs must be defined
on an instance by instance basis, it is also reasonable to provide
the clarification of resolvability to digital resource to be
specified on an instance by instance basis -- i.e. it is no less
economical in the case of URN interpretation, which always requires
instance specific knowledge.

However, by requiring URLs to resolve to digital resources and
disallowing URPs from resolving to digital resources we are able
to achieve a significant economy in definition, being able to assume
such an interpretation for all instances of each type, without
recourse to definition on an instance by instance basis.

Since URNs tend to denote either digital resources which are
diligently managed and/or non-digital resources which are widely
significant and fairly static, this requirement of instance by
instance definition is not untenable.

In contrast, as URLs and URPs may be minimally managed and/or highly
transient identifiers, maximal economy in their interpretation is
highly desirable.

It should be noted that, although the URN class is agnostic about
whether a given instance does or does not resolve to a digital
resource, a subclass of URN or a URN scheme may itself make resolution
to a digital resource a requirement. Neither 'urn:', 'tag:', nor
"hrn:' assert such a requirement (the I-D for the latter will be
revised to reflect this).

The above refinements corresponding to the Neo-Classicial view will
be reflected in the next revision of draft-pstickler-uri-taxonomy-00.

Further discussion is, of course, both anticipated and welcomed.



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 25 January 2002 05:59:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC