Subject: URN Namespace for Hierarchical Object Designators

From: Dieter Köhler <[email-masked]>
Date: Wed, 7 Aug 2002 16:24:35 +0200

About one year ago I sent the proposal of what I called a "URN Namespace for
Structured Object Designators" to this list (see
"http://lists.netsol.com/cgi-bin/wa?A2=ind0107&L=urn-ietf&D=1&T=0&O=D&F=&S=&P=52"). 
Meanwhile I revised this proposal and called it: "URN Namespace for Hierarchical
Object Designators (HOD) 1.0".  I still wonder whether it is an appropriate
candidate for an URN namespace at all or should instead be specified as a new
type of an URI.  In particular RFC 1737 states about the relation of URNs and
URLs: "It is strongly recommended that there be a mapping between the names
generated by each naming authority and URLs."  However, Hierarchical Object
Designators do not require that the designated objects are identifiable by a
network URL.  They are especially designed for metadata to address objects which
are not digital resources.

Any advice and comments on the new proposal are welcome!

Dieter Köhler, M.A.

Institute of Philosophy
University of Karlsruhe
Germany

XXXXXXXXXXXXX                                             Dieter Koehler
Request for Comments: YYYY                       University of Karlsruhe
Category: Standards Track                                    August 2002

        URN Namespace for Hierarchical Object Designators (HOD) 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 a Uniform Resource Name (URN) namespace 
   [RFC2141] for Hierarchical Object Designators (HODs).  HODs are 
   intended to serve as reference pointers to structured objects.  This 
   document sets forward the canonical syntax for HODs.

1. Introduction

   Hierarchical Object Designators (HODs) are intended to serve as 
   reference pointers to structured objects by using Uniform Resource
   Names (URNs) [RFC2141] within a HOD URN Namespace.
   
   HODs are designed especially for dynamic linking of metadata about 
   complex objects in an open hypertext systems.  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".

2. Namespace ID

   "hod" requested.

3. Registration Information

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

4. Declared registrant of the namespace

   The HOD namespace is reserved by the IETF.

5. Terms and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in [RFC2119].

6. 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 HOD namespace can be identified by the following
   Namespace Identifier:

      NID         = "hod"

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

      NSS         = versionNum ":" OSS

      versionNum  = 1*( ALPHA / DIGIT / "_" / "." / "-" )
     
      OSS         = authorityId ":" dateId reference

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

      dateId      = 8 ( DIGIT )

      reference   = "/" *1( div *( "/" div ) *1"/")

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

      divName     = 1*divChars ;

      divVersion  = 1*divChars ;

      divChars    = ALPHA / DIGIT / escape / other

      escape      = "%" HEXDIG HEXDIG

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

   The <versionNum> indicates conformance of the Object Specific 
   String (<OSS>) to the labeled HOD namespace specification version.
   The version number "1.0" indicates conformance to this version of 
   this HOD 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 HOD, 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 SHOULD 
   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 HOD 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 HOD URN.  No 
   provision is made for avoiding collision of experimental HOD 
   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>.

7. Basic Reference System Structure

   A reference consists of a sequence of division statements 
   separated by slash ("/").  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 semicolon
   (";").  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
   semicolon, 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.

8. 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 hod 
   namespace for bibliographic reference of the form 
   "author/book/chapter/paragraph".
   
   (i) Thus
   
      urn:hod: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:hod:1.0:x-test.org:20010101/Adams/My%20Life;A/42/11
      urn:hod: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:hod:1.0:x-test.org:20010101/Adams/My%20Life/42/11;A
      urn:hod: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:hod:1.0:x-test.org:20010101/Adams/My%20Life

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

      urn:hod:1.0:x-test.org:20010101/Adams/My%20Life;A

   is only referring to edition "A".
   
   (iv) The hod 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:hod:1.0:x-test.org:20010101/Adams

   can be used, while 

      urn:hod: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.
   
9. 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.

10. Identifier persistence considerations

   A HOD 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.

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

12. Process of identifier resolution

   HOD providers are responsible for clearly specifying the designat 
   of the designators, they define.  Since HOD URNs are primarily 
   designed to identify abstract or physical objects HOD 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 HOD URN.

13. Rules for Lexical Equivalence

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

           1. normalize the case of the leading "urn:hod:" 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 HOD 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.

14. Dynamic linking of documents containing HOD URNs

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

15. Conformance with URN Syntax

   No special considerations beyond the syntax herein described.

16. Validation mechanism

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

17. Scope

   Global

18. Security considerations

   This document proposes means of encoding hierarchical 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 hierarchical object
   designators.

19. Acknowledgments

   ...

20. References

   [ISO8601] "Date Elements and Interchange Formats -- 
             Information Interchange -- Represantation 
             of Dates and Times", ed. International 
             Organization for Standardization (ISO), 
             ISO 8601, 2000-12-21.

   [RFC2119] Bradner, S., "Key words for use in RFCs to 
             Indicate Requirement Levels", RFC 2119, 
             1997-03. 

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

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

21. Author's Address

    Dieter Koehler
    Institut fuer Philosophie
    Universität Karlsruhe (TH)
    D-76128 Karlsruhe
    GERMANY