- 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>
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. -- Background: Based on both official and unofficial publications and discussions, my understanding of the classical view is as follows: Variant 1: Digital | Non-Digital | <--URL--------> | | <--URN-------------------------> | Variant 2: Digital | Non-Digital | <--URL-------------------------> | <--URN-------------------------> | 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 | <--URI-------------------------> | 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--------> | | |<--URP--------> | -- 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--------> | | <--URN-------------------------> | |<--URP--------> | 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. Cheers, Patrick -- 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