Subject: URN Namespace for Structured Object Designators

From: Dieter Köhler<[email-masked]>
Date: Mon, 2 Jul 2001 15:45:52 +0200

I developed and attached to this posting a proposal of a formal URN namespace
for what I call "Structured Object Designators".   Because of its global scope I
wonder, (i) whether it is a candidate for the standards track and (ii) whether
it is an appropriate candidate for an URN namespace at all or should instead be
specified as a new type of an URI.

Any advice and comments on this proposal are welcome!

Dieter Köhler, M.A.

Philosophy Chair II Staff
University of Bamberg (Germany)

XXXXXXXXXXXXX                                             Dieter Koehler
Request for Comments: YYYY                         University of Bamberg
Category: Standards Track                                      July 2001

        URN Namespace for Structured Object Designators (SOD) 1.0

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes an URN (Uniform Resource Name) namespace for
   structured object designators.  A structured object designator is ...

1. Introduction

   Structured object designators are designed for dynamic linking of
   metadata about structured objects in an open hypertext system.
   These objects may or may not be identifiable by a network URL.
   Examples for objects which are not identifiable by a network URL
   are physical or abstract objects such as "London" or "The works
   of Plato".  However, such objects can be addressed in electronic
   hypertext systems by a digital alias.

   This document defines the framework for hierarchical structured
   reference systems for such objects, their parts, and different
   versions thereof.  For example: "London in the year 1776",
   "London - East End", "The beginning of Plato's Symposion",
   "The additions of hand two to manuscript W of Plato's Symposion".

   If a reference system is defined according to this framework, the
   syntactical form of a reference allows an user agent to search
   for related metadata not only based on the exact reference
   provided, but also on proximity with regard to the reference
   system.  For example: A search for metadata about "London in the
   year 1776" might also reveal proximity metadata about "England in
   the year 1776" or "London in the 1770s", or by using a widened
   scope: "Europe in the 18th century".

   XXX Question: Is a SOD an appropriate candidate for an URN
   namespace at all, or should it better be specified as a new
   type of an URI? XXX

2. Namespace ID

      "sod" requested.

3. Registration Information

      Registration Version Number: 1.0
      Registration Date: yyyy-mm-dd

4. Declared registrant of the namespace:

      Dieter Koehler
      [email-masked]
      Mittlerer Kaulberg 22
      D-96049 Bamberg
      Germany

5. Syntax

   The following syntax definitions are given in Augmented
   Backus-Naur Form (ABNF) according to [RFC2234].

   The URN syntax as described in [RFC2141] defines an URN as

      URN         = "urn:" NID ":" NSS

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.

   URNs in the SOD namespace can be identified by the following
   Namespace Identifier:

      NID         = "sod"

   All Namespace Specific Strings in the SOD namespace have the
   following syntax:

      NSS         = versionNum ":" OSS

      versionNum  = 1*( ALPHA / DIGIT / "_" / "." / "-" )

      OSS         = authorityId ":" dateId ":" reference

      authorityId = 1*( ALPHA / DIGIT / "." / "-" )

      dateId      = 8 ( DIGIT )

      reference   = div *( ":" div)

      div         = divName *1( "*" *1(divVersion) ) ;

      divName     = 1*divChars ;  XXX limit the number of divChars ? XXX

      divVersion  = 1*divChars ;  XXX limit the number of divChars ? XXX

      divChars    = ALPHA / DIGIT / escape / other

      escape      = "%" HEXDIG HEXDIG

      other       = "(" / ")" / "+" / "," / "-" / "." / "=" /
                    "@" / ";" / "$" / "_" / "!" / "'"

   The <versionNum> indicates conformance of the Object Specific
   String (<OSS>) to the labeled SOD namespace specification version.
   The version number "1.0" should be used to indicate conformance
   to this version of this SOD namespace specification; the value
   "1.0" must not be used if the URN does not conform to this
   version of this specification. It is intended to give later
   versions of this specification numbers other than "1.0", but this
   intent does not indicate a commitment to produce any future
   versions of SOD, nor if any are produced, to use any particular
   numbering scheme. Since future versions are not ruled out, this
   construct is provided as a means to allow the possibility of
   automatic version recognition, should it become necessary.
   Processors may signal an error if they receive URNs labeled with
   versions they do not support.

   The <authorityId> must be an Internet domain name, and must be
   owned by the organization creating the SOD reference system and
   allocating the URN to it, at the date identified by the DateId.

   <DateId> is a date in [ISO8601] Basic Format (CCYYMMDD), and must
   correspond to a date at which the organization allocating the
   URN owned the domain name specified in the <authorityId>.  The
   <DateId> "00000000" indicates an experimental SOD URN.  No
   provision is made for avoiding collision of experimental SOD
   URNs; they are intended for use within internal or limited
   experimental contexts.

   <reference> signifies a certain reference according to a
   reference system defined by the authority with owned the domain
   name specified in the <authorityId>.  The used reference system
   is uniquely identified by the combination of <authorityId> and
   <DateId>.

6. Basic Reference System Structure

   A reference consists of a sequence of division statements
   separated by colons (":").  The allowed values for these
   divisions form a reference system.  These divisions
   represent nested structure levels beginning with the most
   general and leading to the most specific.  In other words:
   The possible divisions of a reference system form one or
   more nested trees.

   Each division consists of a mandatory division name and an
   optional division version indicator separated by asterisk
   ("*").  If no division version indicator is given, the
   division name together with its parent divisions specify a
   certain object.  If a division version indicator is given,
   it indicates a certain version of the object specified by
   the division name and its parent divisions.  If only the
   asterisk, but no division version indicator is given, it
   refers to each of the individual versions of the object
   specified by the division name and its parent divisions,
   but not to the object as a whole.

   Division versions are local.  Literal equivalence between
   division versions indicates equivalent versions of an
   object only under the same parent division.  Equivalent
   division versions occurring on different division levels
   do not indicate the same global version.  Resource system
   specifications may introduce additional rules to define
   equivalence between literally different references.

   The literal values of references indicate no specific order.
   Resource system specifications may introduce additional rules
   for ordering references.

   More than one reference system for the same objects may be
   defined.  However, it is out of the scope of this documentation
   to define a mechanism to identify references based on different
   reference systems designating them same designat.

7. Examples

   For the following examples it is assumed that a fictitious
   authority owns the domain <x-test.org> at <20010101> and is
   declaring under this authorityId and dateId a simple sod
   namespace for bibliographic reference of the form
   "author:book:chapter:paragraph".

   (i) Thus

      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life:42:11

   is to be read as pointing to chapter 42, paragraph 11 of the
   book entitled "My Life" from an author named "Adams".  If
   there exist two editions of this book, both could for example
   be distinguished by different division versions "A" and "B":

      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life*A:42:11
      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life*B:42:11

   (ii) Note that these URNs do not necessarily mean the same as:

      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life:42:11*A
      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life:42:11*B

   This document makes no assumptions about the identity of
   literally identical division versions appearing on different
   division levels.  However, authorities specifying a reference
   system are free to do so.

   (iii) Varying the above example the URN

      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life

   is referring to all editions of Adams' book "My Life", while

      urn:sod:1.0:x-test.org:20010101:Adams:My%20Life*A

   is only referring to edition "A".

   (iv) The sod namespace also provides means to distinguish
   between e.g. a reference to the author "Adams" from a
   reference to all of his works.  To refer to the author
   "Adams" the URN

      urn:sod:1.0:x-test.org:20010101:Adams

   can be used, while

      urn:sod:1.0:x-test.org:20010101:Adams:

   refers to all of his books (individually).  However, it is
   up to the authority specifying a reference system to
   exactly define the meaning of the first of these two
   references, and so she might choose to treat it as a
   shortcut for the second.

8. Identifier uniqueness considerations

   The combination of AuthorityId and DateId serves to uniquely
   identify the organization that is allocating the URN.  That
   organization is responsible for ensuring the uniqueness of the
   designator.

9. Identifier persistence considerations

    A SOD URN may only be allocated by an organization that owns an
    Internet domain name.  The URN identifies a date on which the
    organization owned that domain name.  The combination of date
    and domain name will serve to uniquely identify that
    organization for all time.

10. Process of identifier assignment

   The organization identified by the AuthorityId/DateId combination
   is responsible for allocating a designator that is unique among
   all those that it allocates with that DateId.

11. Process of identifier resolution

   SOD providers are responsible for clearly specifying the designat
   of the designators, they define.  Since SOD URNs are primarily
   designed to identify abstract or physical objects SOD providers
   are responsible for the provision of a URN resolution service, if
   any, only if there exists a canonical network resource of the
   designat they have assigned with a SOD URN.

12. Rules for Lexical Equivalence

   Two SOD URNs are lexically equivalent if they are octet-by-octet
   equal after the following preprocessing:

           1. normalize the case of the leading "urn:sod:" token
           2. normalize the case of the versionNum
           3. normalize the case of the AuthorityId
           4. normalizing the case of any %-escaping

   Note that %-escaping MUST NOT be removed.

   Some SOD providers may define additional lexical equivalencies,
   such as case-insensitivity of the <designator> (or parts
   thereof).  Additional lexical equivalencies MUST be clearly
   documented, MUST always have the effect of eliminating some
   of the false negatives obtained by the procedure above, and
   MUST NEVER say that two URNs are not equivalent if the
   procedure above says they are equivalent.

13. Dynamic linking of documents containing SOD URNs

   Defining rules for dynamic linking of documents containing SOD
   URNs is out of the scope of this document.

14. Conformance with URN Syntax

   No special considerations beyond the syntax herein described.

15. Validation mechanism

   Organizations that allocate SOD URNs are responsible for the
   provision of a URN validation service, if any, for URNs they
   have assigned with a valid AuthorityId/DateId combination.

16. Scope

   Global

17. Security considerations

   This document proposes means of encoding structured object
   designators within the URN framework. This document does not
   discuss resolution; thus questions of secure or authenticated
   resolution mechanisms are out of scope.  It does not address
   means of validating the integrity or authenticating the
   source or provenance of URNs that contain structured object
   designators.

18. Acknowledgments

   ...

19. References

   [ISO8601] XXX

   [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2234] Crocker, D. and P. Overell, "Augmented BNF
             for Syntax Specifications: ABNF", RFC 2234,
             November 1997.

---

From: Michael Mealling <[email-masked]>
Date: Mon, 2 Jul 2001 12:05:22 -0400

On Mon, Jul 02, 2001 at 03:45:52PM +0200, Dieter Köhler wrote:
> wonder, (i) whether it is a candidate for the standards track

It looks general enough to be applicable to the standards track....

> and (ii) whether it is an appropriate candidate for an URN namespace at all
> or should instead be specified as a new type of an URI.

At first glance it looks to be very much appropriate as a URN. It has
many of the features that several example URN namespaces had. The
timestamped domain-name is a recurring theme and the psuedo hierarchy.
The only real question is do you want the namespace subject to the
non-reassignability requirements of URNs?

-MM

--
--------------------------------------------------------------------------------
Michael Mealling                       | mailto:[email-masked]
Advanced Naming Research Manager       | go:Michael Mealling
Verisign Applied Research              | urn:pin:1

---

From: Tim Kindberg <[email-masked]>
Date: Mon, 2 Jul 2001 10:44:01 -0700

Dieter,

At 12:05 PM 7/2/2001 -0400, Michael Mealling wrote:
>.....The
>timestamped domain-name is a recurring theme .......

You may not be aware of the tag URI scheme (see taguri.org), which your
proposal bears some similarity to (at least at first glance).

We also date-stamp an authority name to gain uniqueness over time, although
we allow email addresses as well as domain names as the authority names.
The essential difference seems to be that you mandate the syntax of what
appears after the dated authority, whereas we specifically avoid doing so.
We think that that is the business of the authority that mints the tag
identifier, and no-one else.

We went through some discussions with members of this list on the question
of whether tags are URNs. You may want to look at the archives on that subject.

Cheers,

Tim.

Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
[email-masked]
voice +1 650 857 5609
fax +1 650 857 2358