URNについての簡単な説明

URN (Uniform Resource Name) とはネットワーク上のリソースを、「場所」という概念に依存せず、「名前」によって永続的(persistent)に特定しようという識別子です。リソースを永続的に特定できればそれをURNと呼ぶ広い意味での用法もありますが、IETFで討議されRFC化された意味では、定められた書式に則り、登録された名前空間のもとでそれぞれのルールに従って記述することになっています。

URNの一般概念

URIの概念を定義している[RFC2396]では、URNは次のように定義されています:

A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces, each of which has its own set name structure and assignment procedures. The "urn" scheme has been reserved to establish the requirements for a standardized URN namespace, as defined in "URN Syntax" [RFC2141] and its related specifications. (Section 1.2)

ここでは (1) URNはリソースを永続的に識別することが第一目的で、識別子はそれぞれ固有の体系と登録手続きを持つ名前空間のどれかに属する; (2) 特にurn:スキームは、RFC 2141に定められたURNの標準名前空間のために予約されている;ということが述べられています。

2001年9月のW3Cノート[URI-NOTE]では、URNとはURIの1つのスキームであることが明記されました。

〔補足〕

RFC 2396の定義を受けて、W3CのURIアクティビティのホームページ[NAMING]では、URI, URL, URNの概念について次のように説明しています。

URI
Uniform Resource Identifier. リソースを指し示す短い文字列からなる名前/アドレスの総称
URL
Uniform Resource Locator. 良く知られたURIスキームであるhttp, ftp, mailto などを指す非公式な(技術仕様文書では使われることのない)用語
URN
Uniform Resource Name.
  1. 何らかの組織がその永続性、可用性を保証しているURI。この種類のURIは、URLでもあり得ることに注意。たとえば[PURLs]を参照
  2. 永続的で場所に依存しないリソース指定のために用意されているスキーム「urn:」のこと。RFC 2141および関連文書で定義される

このように従来URNは「永続性が保証されているURI」という広い意味と、「RFC2141ほかで定義されるurn:スキームによるURI」という狭い意味の両方で使われていましたが、最新の見解では基本的に後者の意味になります。

〔以上補足〕

URNの構文と登録

URNスキームの構文

[RFC2141]urn:スキームを使うURNの構文を定義します。基本定義は

<URN> ::= "urn:" <NID> ":" <NSS>

という式で示されます。

urn:
urnスキームによるURIであることを示します。http:等と同じです。
<NID>
名前空間の識別子です。英数字で始まり英数字とハイフンで構成される32字以内の文字列で、大小文字を区別しません。次に述べるように、このNIDは登録制で、URNに管理可能な仕組みを導入するものです。
<NSS>
その名前空間に固有の、リソースを識別する文字列です。URIとほぼ同様の文字で構成され、特殊な文字は%HHの形でエスケープする点も同様です。

URNを識別子としてだけでなく、リソースを取得するために使うには、NAPTR[RFC2915]などの方法でURNを解決(アクセス手段の割り出し)しなければなりませんが、その方法はNIDごとに定義することになっています。

〔補足〕

スキームurn:は厳密には小文字で定義されているものですが、RFC 2396では、For resiliency, programs interpreting URI should treat upper case letters as equivalent to lower case in scheme names と、大小文字を区別せずに扱うよう定めています。RFC 2141ではもっとシンプルに、The leading "urn:" sequence is case-insensitive. としています。

〔以上補足〕

URN空間の管理と登録

たとえばhttp:スキームのURIは、ローカル部の管理責任を持つ部分をドメイン名システムに登録されるホスト名とすることで、識別子の一意性を確保しています。ドメイン名の登録は公式に管理されており、重複や解決不能のないことが保証されるからです。

urn:の場合も[RFC3406]において、<NID>の部分をIANAへの登録制とし、<NSS>部分をその登録主体が管理することで、URN空間の一意性・一貫性を確保するようにしています。<NID>の登録に際しては、<NSS>部分の構文やその解決法(ネットワーク上でアクセスするための方法)も定義して公開することになっているので、<NID>がわかればそれ以下の<NSS>も解釈ができるようになります。

登録されているURNのいくつか

抽象構文だけではイメージが湧かないので、実際にIANAに登録されているURN名前空間をいくつか見てみることにしましょう。公式なNIDとして登録されているのは、2002年8月現在で10あります[IANA-URN]

OASIS空間

XMLやSGMLによるさまざまな標準仕様を定めているOASISは、その文書などのリソースを識別する方法としてoasisというURN空間(NID)を登録し、その仕様が[RFC3121]として発行されています。

この空間は、OASISによる文書を登録するnames階層ツリーと、OASISのメンバー組織による文書のためのmember階層ツリーとに分かれます。namesの下には仕様書を示すspecification、技術委員会によるtc、その他の技術文書technicalというサブクラスがあり、それぞれが名前(ID)記述のルールを持ちます。memberの下にはOASISから割り当てられるmember IDがあり、それ以降はメンバー組織によってURNの構文に従った一意の識別子を割り当てることになっています。

  • oasis:
    • names:
      • specification:
      • tc:
      • technical:
    • member:
      • {member-id}:
      • ...

この名前空間による具体的なURNの例としては、仕様書では次のようなものがあげられています。URNのイメージがつかめるでしょうか。

urn:oasis:names:specification:docbook:dtd:xml:4.1.2
urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1
urn:oasis:names:technical:memo:9502:1995
urn:oasis:member:A00024:x

これらのURNを使ってリソースを取得できるようにするために、IDの所有者はOASISカタログ(OASIS TR9401 Catalogs)にURLなどへのマッピングを記述することになっています。

公開識別子空間

文書型宣言でお馴染みの公開識別子(Public Identifier)は、文書型を一意に定義するための識別子です。特にHTMLなどのSGML文書型で必要なFPIは、その永続性からしてURNの考え方に近いものですが、URIの構文とは全く異なるので、そのままではURNとして使うことができません。これを、一部の区切り文字などを変換して公式のURNとして通用させるpublicid空間が定められ、[RFC3151]として発行されています。

URNの書式は

urn:publicid:{transcribed-public-identifier}

で、{transcribed-public-identifier}の部分は、公開識別子の空白文字を正規化した上で、次のルールで変換します。

  • 正規化の後に残るスペース文字は+に変換
  • //:に変換
  • ::;に変換
  • + : / ; ' ? # %の各文字は%HHとしてエスケープ(:://の場合を除く)

このルールに従って変換すると、HTML 4.01 StrictのFPIは次のように表現できることになります。

(例)urn:publicid:-:W3C:DTD+HTML+4.01:EN

このURNから実際のDTDなどを取得するためには、URNをいったんFPIに変換し、それをOASISカタログと照らし合わせるなどの方法をとることができるでしょう。見慣れた文字列(識別子)が具体的にURNとして示されると、URNが少し身近に感じられませんか?

IETF空間

RFCなどを発行するIETFの文書に対するURNは、[RFC2648]によって名前空間を定義しています。登録URN空間の第一号でもあります。

IETF文書の名前空間は、ietfというURN空間(NID)のもとに、(1)RFC;(2)RFCの分類カテゴリーである参考情報(FYI:For Your Information)、インターネット標準(STD: Standard)、現状(BCP: Best Current Practice);(3)RFC以前のドラフトであるInternet Draft、会議議事録;をサブクラスとして持ちます。

  • ietf:
    • rfc:
    • fyi:
    • std:
    • bcp:
    • id:
    • mtg:
    • {other string}

この名前空間による具体的なURNの例としては、次のようなものがあげられています。

urn:ietf:rfc:2141
urn:ietf:std:50
urn:ietf:id:ietf-urn-ietf-06
urn:ietf:mtg:41-urn

URNの解決には、IETFの提供するインデックスファイル(のコピー)を用います。FYI,BCP,STDがどのRFCに対応するかも、それぞれの対応インデックスを使うことになります。RFC 2648には、URN解決に使うためのPerlスクリプトが付録として掲載されています。

ISBN空間

書籍のための国際識別コードであるISBN (International Standard Book Numbers) は、早くからURNの例として取り上げられていましたが、2001年10月には[RFC3187]が発行され、IANAに正式登録されました。その書式は単純に

URN:ISBN:4-8399-0454-5

という具合に、ISBNコードをそのままURNとしたものです。ISBNのURNについては、[RFC2288]も参照。

〔補足〕 この場合 urn:isbn:4-8399-0454-5 と小文字で書いても等価ですが、RFCの例を尊重しています。

永続性に関するノート

URNを語るときによく言われるのが「アドレスを示すURLはサーバーが変わったりして変更されやすい。名前を使うURNは、場所にかかわらずリソースを一意に特定でき、永続性がある」という比較です。URLがしょっちゅう変更されてしまってリンク切れが多いことは事実ですし、名前の方がどこでも通用する可能性が高いことも確かでしょう。

ただし、名前もたとえば組織やプロジェクトの変更などによって変わってしまうことがありますし、逆にURLも少しの工夫でむやみに変更されないものにすることは可能です。URIの一貫性、永続性は、そのスキームが保証してくれるのではなく、IDの管理者自らが「変更不要のURI」を考えなければならないのです。

以下を参考にしてください。いずれもバーナーズ・リーによる重要なノートです。

永続性にこだわらないinfo:スキーム

URNの考え方とは逆に、リソース(のID)によっては永続性の保証が第一目的ではないものもあることを考慮し、これらにURIを与える新しいスキームinfo:も登場しています[RFC4452]

The "info" URI scheme, on the other hand, does not assert the persistence of the identifiers created under this scheme but rather of the public namespaces grandfathered under this scheme. It exists primarily to disclose the identity of information assets and to facilitate a lightweight registration mechanism for public namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. The "info" URI scheme is neutral with respect to identifier persistence.

構文としては、'info:' + <名前空間ID> + '/' + <ローカル識別子(パス)>という形で、名前空間IDを登録するというのもURNと同じ。例として、DDC(Dewey's Decimal Classification)を表記する、次のようなものが挙げられています。

info:ddc/22/eng//004.678

URIの時間スライスで「永続性」を確保する試み

※ここでとりあげているDURIのドラフトは、RFCにならないまま2003年に廃棄されました。以下は、ちょっとした記録としての記述です。復活してました。時間軸を組み込んだURIスキームtag:についてのメモ「時間軸を使うURIスキーム、tag:がRFCに」もご覧ください。

URIの永続性が問題になるのは、時間が経過するとその内容やロケーションが変わってしまうというところに原因があります。逆の観点に立つと、対象となる時刻さえ指定すれば、URIが意味するところに疑問の余地はないと言えるでしょう。この考え方に基づき、従来のURIの「タイムスライス」とでもいうべきものを指定することで永続性を確保するurnの仕組みが、インターネットドラフトとして提案されています[DURI]

duri

最初のスキームは、既存のURIの前に日付情報を付け加えようというものです。書式は

urn:duri:<date>:<encoded-URI>

というもので、<date>の部分に年、年月、年月日といった形での日付を示す文字列を記述し、<encoded-URI>にその時点で識別したいURIを記述します。日付文字列は、YYYY[MM[DD[hh[mm[ss[fraction]]]]]]という形式で、年という大まかなものから秒以下の細かい単位まで、曖昧さなしに表現できるようになっています(年などの大きな単位の場合、その最初の最後の瞬間を示すものとされます)。

(例)

urn:duri:2001:http://www.inpaku.go.jp/        (1)
urn:duri:19951215:http://www.kanzaki.com/     (2)

たとえば上記の(1)は、2001年初の「インパク」のサイトを示します。イベントが終わったら、このサイトはなくなってしまうかも知れないのですが、こうやって時期を特定することで、「永続的」な識別子の働きを担わせようというわけです。(2)の例は、当サイトの開設日のスナップショットを示します。同じURLで示されるこのサイトも、当時と今とではずいぶん変化していますが、こうして日時を特定することで、曖昧さなく原初のリソースを識別できるわけです。

tdb

URIはあらゆるリソースを識別することになっているので、ネットワーク上でアクセス可能ではない、組織や人間もURIを与えることができます。実際にそのような使い方は、XML名前空間などでも行われているわけですが、たとえば「総務省大臣官房管理室新千年紀記念行事推進室」をhttp://www.inpaku.go.jp/で示したり、「神崎正英」をhttp://www.kanzaki.com/で識別するというのは、どうもしっくりきません。

そこで提案されているのが、"Things Described By"というurnスキームです。「あるURIによって表現される(ネットワーク上の実体ではない)もの」を、urnとして示そうというものです。書式は

urn:tdb:<date>:<encoded-URI>

という形で、<date>以下の意味はduriの場合と同じです。

(例)

urn:tdb:2001:http://www.inpaku.go.jp/        (3)
urn:tdb:19951215:http://www.kanzaki.com/     (4)

例の(3)は21世紀がスタートしたときの総務省大臣官房管理室新千年紀記念行事推進室」(もしかしたら総理府?)、(4)はウェブを公開したその日の「神崎正英」を示しているわけです。

参照文献

[RFC2396]
R. Fielding, U.C. Irvine and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, , RFC Standards Track, The Internet Society
<http://www.ietf.org/rfc/rfc2396.txt>
[URI-NOTE]
URI Planning Interest Group, URIs, URLs, and URNs: Clarifications and Recommendations 1.0, , W3C Note, W3C/IETF
<http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/>
[NAMING]
Tim Berners-Lee and Dan Connolly, Naming and Addressing: URIs, URLs, ..., , W3C Note
<http://www.w3.org/Addressing/>
[PURLs]
The PURL Team, Persistent Uniform Resource Locator
<http://purl.oclc.org>
[RFC2141]
R. Moats, URN Syntax, , RFC Standard Track, The Internet Society
<http://www.ietf.org/rfc/rfc2141.txt>
[RFC2915]
M. Mealling and R. Daniel, The Naming Authority Pointer (NAPTR) DNS Resource Record, , RFC Standards Track, The Internet Society
<http://www.ietf.org/rfc/rfc2915.txt>
[RFC3406]
L. Daigle et al., Uniform Resource Names (URN) Namespace Definition Mechanisms, , RFC Best Current Practice, The Internet Society
<http://www.ietf.org/rfc/rfc3406.txt>
[IANA-URN]
IANA, URN Namespaces,
<http://www.iana.org/assignments/urn-namespaces>
[RFC3121]
K. Best and N. Walsh, A URN Namespace for OASIS, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc3121.txt>
[RFC3151]
N. Walsh et al., A URN Namespace for Public Identifiers, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc3151.txt>
[RFC2648]
R. Moats, A URN Namespace for IETF Documents, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc2648.txt>
[RFC3187]
J. Hakala and H. Walravens, Using International Standard Book Numbers as Uniform Resource Names, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc3187.txt>
[RFC2288]
C. Lynch et al., Using Existing Bibliographic Identifiers as Uniform Resource Names, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc2288.txt>
[RFC4452]
Herbert Van de Sompel, et.al., The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces, , RFC Informational, The Internet Society
<http://www.ietf.org/rfc/rfc4452.txt>
[NAME-MYTH]
Tim Berners-Lee, The Myth of Names and Addresses, , personal view
<http://www.w3.org/DesignIssues/NameMyth.html>
[DURI]
L. Masinter, "duri" and "tdb": URN Namespaces based on dated URIs, , Internet Draft, The Internet Society
<http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-05.txt>