統一リソース名

統一リソース名( URN ) は、スキームを使用する統一リソース識別子(URI)です。URN は、定義された名前空間内に割り当てられるグローバルに一意な永続識別子であり、識別対象のリソースが存在しなくなったり、利用できなくなったりした後でも、長期間使用できます。^{[ 1 ]} URN は、アイテムを直接見つけるために使用することはできず、解決可能である必要もありません。これは、別のパーサーがアイテムを見つけるために使用できる単なるテンプレートだからです。urn

URNは、当初、 Uniform Resource Locator（URL）およびUniform Resource Characteristics（URC）というメタデータフレームワークとともに、インターネットの3部構成の情報アーキテクチャの一部として構想されました。RFC 1737 ^{[ 2 ]}、そして後にRFC 2141 [ ^{3 ]}で説明されているように、 URNは、 HTTPやFTPなどの特定のアクセスプロトコルのコンテキストでリソースの場所を指定することでリソースを識別するURLとは区別されます。対照的に、URNは、定義された名前空間内で、通常は名前空間を担当する機関によって割り当てられる、永続的で場所に依存しない識別子として構想されました。そのため、^URNは、識別対象のリソースが存在しなくなったり利用できなくなったりした後でも、長期間にわたってグローバルに一意で永続的です。^{[ 1 ]}  

URC は概念段階から進展せず、^{[ 4 ]}リソース記述フレームワークなどの他の技術が後にその地位を占めるようになりました。2005年のRFC 3986 ^{[ 5 ]}以降、「Uniform Resource Name」と「Uniform Resource Locator」という用語の使用は技術標準では非推奨となり、両方を包含する Uniform Resource Identifier (URI) という用語が使われるようになりました。これは、World Wide Web Consortium (W3C) とInternet Engineering Task Force (IETF) の合同ワーキンググループが 2001 年に提案した見解です。^{[ 4 ]} 

URIとは、インターネット上のリソースを識別または命名するために使用される文字列です。URIは、多くのインターネットプロトコルで情報リソースを参照およびアクセスするために使用されます。URIスキームには 、およびプロトコルのほか、数百ものプロトコルが含まれます。httpftp

いわゆる「現代的な見方」では、すべてのURIはリソースを識別または命名するものであり、おそらく一意かつ永続的に識別され、その一部は特定のプロトコルと連携してリソースの表現に解決可能な「ロケーター」でもある。

その他のURIはロケーターではなく、必ずしもそれが存在するシステムの範囲内で解決できるとは限りません。これらのURIは、リソースの名前または識別子として機能する場合があります。リソースは移動する可能性があるため、ロケーターではなく特定の場所に紐づいていない不透明な識別子は、ロケーターである識別子よりも、時間の経過とともに一意性と永続性を維持する可能性が高いと言えます。しかし、URIが解決可能かどうかは、「名前」と呼ばれるか「ロケーター」と呼ばれるかに関わらず、多くの運用上および実務上の詳細に依存します。現代の見解では、「名前」と「ロケーター」の間に明確な境界線はありません。

この考え方に基づき、インターネット技術タスクフォース（IETF）の正式な技術標準では、統一リソース名（Uniform Resource Names）と統一リソースロケータ（Uniform Resource Locator）の区別はもはや用いられていないが、後者の用語であるURLは依然として非公式に広く使用されている。

「URN」という用語は、現在も100を超えるURI「スキーム」の1つとして使われておりurn:、、などと並行しています。このスキームのURIはロケータではなく、特定のプロトコルやアクセス方法に関連付けられる必要はなく、解決可能である必要もありません。それらは、一意性を維持し、長期間にわたって同じリソースを永続的に識別することをある程度保証する手順によって割り当てられる必要があります。などのスキームのネームスペースの中には、登録機関を必要としない方法で識別子を割り当てるものもありますが、ほとんどは必要とします。典型的なURNネームスペースは、国際標準図書番号（ISBN）です。この見解はRFC 8141（2017）にも引き継がれています。^{[ 1 ]}http:ftp:urn:urn:urn:uuid:urn:isbn 

tag:URI スキームには、 (info:現在ではほとんど非推奨) やni:^{[ 6 ]}urn:など、ロケーターではなく、特定の解決プロトコルやアクセス プロトコルに関連付けられていない点でスキームに似たものもある。

urn:スキームURIの構文は、拡張バッカス・ナウア記法で次のように表されます。^{[ 5 ] [ 7 ]}

namestring = assigned-name [ rq-components ] [ "#" f-component ] assigned-name = "urn" ":" NID ":" NSS NID = ( alphanum ) 0*30 ( ldh ) ( alphanum ) ldh = alphanum / "-" NSS = pchar * ( pchar / "/" ) rq-components = [ "?+" r-component ] [ "?=" q-component ] r-component = pchar * ( pchar / "/" / "?" ) q-component = pchar * ( pchar / "/" / "?" ) f-component = fragment; 一般的な URI 構文規則 (RFC3986) fragment = * ( pchar / "/" / "?" ) pchar = unreserved / pct-encoded / sub-delims / ":" / "@" pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="alphanum = ALPHA / DIGIT ; 非推奨、使用は推奨されません

または、構文図の形式では、次のようになります。

• 先頭のスキーム（urn:）は大文字と小文字を区別しません。
• <NID>は名前空間識別子であり、文字、数字、および を含むことができます-。
• NID の後には名前空間固有の文字列が続きます<NSS>。この文字列の解釈は、指定された名前空間によって異なります。NSS には、ASCII 文字と数字、および多くの句読点と特殊文字を含めることができます。使用が禁止されている ASCII 文字とUnicode文字は、パーセントエンコードされている場合に含められることがあります。

2017年にURNの構文が更新されました。^{[ 1 ]}

• /NSSでは、非URN識別子システムからのスラッシュを含む名前を表すために、スラッシュ文字（ ）の使用が許可されるようになりました。
• qコンポーネントは、名前付きリソースにパラメータを渡せるようにするために追加されました。
• rコンポーネントは、リゾルバにパラメータを渡せるようにするために追加されました。ただし、更新された仕様では、さらなる標準化によってその意味が定義されるまでは使用すべきではないとされています。

URN名前空間のグローバルな一意性を保証するために、その識別子（NID）はIANAに登録する必要があります。登録された名前空間は「正式な」名前空間または「非公式な」名前空間のいずれかになります。以前は「実験的な名前空間」に対して登録要件の例外が設けられていましたが^{[ 8 ]} 、 RFC 8141によって撤回されました^{[ 1 ]。}

• アーカイブリソースキー（ARK）
• .arpa  – urn.arpa は動的検出用です
• 拡張可能なリソース識別子（XRI）
• ハンドルシステム
• 情報URIスキーム
• ライフサイエンス識別子（LSID）
• URNを使用するMagnet URIスキーム
• 永続的統一リソースロケータ（PURL）
• タグURIスキームはurnに似ています。URIがリソースロケータではないという点で。
• デジタルオブジェクト識別子（DOI）
• EPC識別キー

• IANA公式URN名前空間レジストリ
• IETFのUniform Resource Namesワーキンググループ
• ウェブオーサリングにおけるURNと書誌情報引用
• サーバー側のURNリゾルバの例はRFC 2169に記載されています。