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空間の管理と登録

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

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

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から実際の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の例を尊重しています。

永続性にこだわらない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]。

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

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