[3] [DFN[URN]] ([DFN[Uniform Resource Names]], [DFN[統一資源名]]) は、 [ABBR[[[URI]]][Uniform Resource Identifiers]] の [Q[名前]]としての性質を指した言葉です。 [ABBR[URI][Uniform Resource Identifiers]] は[Q[識別子]]ですが、 [[Webブラウザ]]のように物理的な[RUBY[番地][アドレス]] (所在を表す記号) として使われることがよくあります (この性質を指して [DFN[[ABBR[[[URL]]][Uniform Resource Locators]]]] といいます)。それに対して、[[資源]] ([Q[もの]]) の'''名前'''として [ABBR[URI][Uniform Resource Identifiers]] を捉えるのが [ABBR[URN][Uniform Resource Names]] 的考え方です。 もちろん、所在地と名前は対立するものではなく、 時には所在地が名前となったり、名前を所在地に使えたりします。 以前には所在地 (URL) と名前 (URN) を別のものと考えていた時代もありましたが、 現在ではあらゆる識別子 (URI) を名前と見なし得るので、 [Q[URN]] という概念自体があまり使われなくなっています。 * 古い考え方 [18] 以前は、よく [Q[URI = URL + URN]] ということが言われていました。 [[資源]] ([Q[もの]]) の[Q[識別子]]である [[URI]] は、 [[資源]]を位置で識別する [[URL]] と名前で識別する [[URN]] の (たぶん重ならない) 2つの集合の和であると考えられていたのです。 [[URL]] が先に実用化・標準化されたのですが、元々は URL と URN というようなことは考えられなかったので、 URL の識別方法を表す [[scheme]] ([SAMP(URI)[[[http]]:]] など) は[Q[[[根]]]]名前空間に定義され、 後から定義される URN は [CODE(URI)[[[urn]]:]] [[URI scheme]] に収納 (例: [[ISBN]] を使って書式を識別する [SAMP(URI)[[[urn:isbn]]:]] URN scheme ([[NID]])。) して名前空間を分けることが予定されていました。 しかし、 >>3 のような URI は URL でもあり、 URN でもあるという考え方が一般的になり、分かりやすい [Q[URI = URL + URN]] という式も、 [CODE(URI)[urn:]] [[URI scheme]] に [[URN]] を納めるという話も怪しくなってきました。 というより元々 [CODE(URI)[[[mid]]:]] ([CODE(822)[[[Message-ID]]]] を使って[[メッセージ]]を識別。) のような URN らしい [Q[[[URL]]]] があったり、最初から怪しかったといえば怪しかったのです。 第一 [[URI]] の発明者である [[TimBL]] は、最初から [[URL]] ではなく [[URI]] [WEAK[(当初は [[UDI]])]] を提案していました。 [32] '''[[URN]]と[CODE(URI)@en[[[urn]]:]] scheme''' 歴史的経緯はともかく、現代的な考え方では[[URL]] ([[番地]]) と[[URN]] ([[名前]]) に明確な区別は''なく''、 個々の[[URI]]が[[番地]]的性質を持っていたり、 [[名前]]的性質を持っていたり、両方の性質を持っていたりするに過ぎません。 従って、[[URN]]的性質を持った[[URI]]が必ずしも[CODE(URI)@en[[[urn]]:]] [[URI scheme]]をつかって要る必要は''ありません''。 例えば[CODE(URI)@en[[[tag]]:]] [[URI scheme]]は[[URN]]的性質を持っています。 また、[CODE(URI)@en[[[http]]:]] [[URI scheme]]も[[名前空間URI]]として使われる時は[[URI]]的性質を持っています。 ** メモ - [7] URN と [[URL]] の違いは、あるものを論理的に命名するか物理的に命名するか。参考 (にはあまりならないかも): >>150-170 - [8] URI を URL と URN に二分する考えからすると、 URN は [[urn:]] [[scheme]] の URI ということになる。 URN/URL をもっと概念的に捉えると、 URL と URN の区別は一意には定まらない。 (例えば [SAMP(URI)[http://foo.example/nanika/no/namae>]] は一見 URL だが、意味的に URN かもしれない。) この2つの考え方はどちらが正しいというものでもない。 [17] ''WIRE - W3 Identifier Resolution Extensions'' : [[HTTP]] を微妙に拡張して URN の解決に使おうという I-D。 * [CODE(URI)[urn:]] URL scheme ** NID [28] [CODE(URI)[urn:]] shceme の URI で 文字列 [SAMP(URI)[urn:]] の直後にくる文字列は、 [DFN[名前空間識別子]] ([DFN[[[NID]]]]) といいます。 詳しくは [[NID]] をごらんください。 ** 不正な URN [29] [[名前空間]] [SAMP(URI)[[[urn:mozilla]]]] の URN では、 [CODE(URI)[/]] が使われることがありますが、これは URN 構文では認められていません。 [30] 名前空間名 (NID) [CODE(URI)[x-suika.fam.cx]], [CODE(URI)[x-tomikou.net]] が以前使われていましたが、 文字 [CODE(URI)[.]] は NID では認められていないので [CODE(URI)[[[urn:x-suika-fam-cx]]]] と [CODE(URI)[[[urn:x-tomikou-net]]]] に変更されました。 ** メモ [16] Q: [SAMP(URI)[''urn'':[VAR[nid]]:[VAR[*]]]] の [Q[[SAMP(URI)[urn]]]] の部分と [Q[[SAMP(URI)[[VAR[nid]]]]]] の大文字・小文字は区別されますか? [27] A: >>16 どちらもされません。但し、その後の [SAMP(URI)[[VAR[*]]]] の部分で区別されるかされないかは、 その個々の定義によるので一概には言えません。 (一般には区別されます。) * 普遍資源名機能 (Web SGML) [13] [[WebSGML]] では、 [[SGML宣言]]の[[他機構]]で宣言できる機能に [CODE(SGML)[URN]] が加わりました。 -[14] [CODE(ABNF)[[DFN[urn feature]] = 1*[[ps]] 'URN' 1*ps ('NO' / 'YES') ;; Web SGML [198.1] (K.3.8.1)]] この機能が有効である場合、[[公開識別子]]は [[RFC 2141]] の普遍資源名として解釈されます。 なお、旧来の [[SGML]] から存在する [CODE(SGML)[[[FORMAL]]]] も有効になっている場合は、公開識別子は、 [[公式公開識別子]]又は URN のいずれかとして解釈されます。 [WEAK[URN は必ず [CODE(ABNF)["urn:"]] から始まり、一方公式公開識別子は [[ISO所有者識別子]]が使われない限り絶対に衝突しません。 ISO 所有者識別子は、 [[ISO]] の気が狂いでもして、その出版物の名前の最初の4文字を [CODE(ABNF)["urn:"]] にしたりでもしない限り、衝突しません。仮にこの部分で衝突したとしても、公的公開識別子は絶対に[[間隔]]を含みますが、逆に正しい URN は絶対に含まないので、確実に区別できます。]] [15] この機能は悪くはありませんが、実際には URN NID の登録は成功しておらず、色々な人が勝手に使っています。従って URN を使っても、[[未登録所有者識別子]]と同程度しか一意性の保証ができません。従って、公開識別子に URN を使用するくらいなら、[[インターネット・ドメイン名所有者識別子]]を使う方が賢明でしょう。 * 解決 [40] [[URN]] は「名前」であり、 [[URL]] とは違って[[プロトコル]]によるアクセス方法の記述では無いとされていました。 [DFN[URNの解決]]によって[[資源]]を得るためには、 そのための[[プロトコル]]が必要であるとされ、いくつかの方法が提案されました。 [FIG(short list)[ [41] - [CODE[/uri-res/]] - [[DDDS]] ]FIG] * 関連 - [19] [[XRI]] - [20] [[PURL]] -[21] [[FPI]] * 歴史 [REFS[ - [[RFC2141]] -- 『URN Syntax (URN 構文)』 -- R. Moats, 1997年5月。提案標準。 ]REFS] [43] [CITE[Link Reliability - Why URNs are Not the Answer]], [TIME[1997-08-09T17:55:05.000Z]], [TIME[2024-08-15T15:18:48.315Z]] [22] [CITE[IRC logs: freenode / #whatwg / 20100131]] ([TIME[2010-02-02 22:30:53 +09:00]] 版) [23] [CITE@en[Uniform Resource Names, Revised (urnbis) - Charter]] ( ([TIME[2011-03-05 16:21:56 +09:00]] 版)) [24] [CITE@en[draft-ietf-urnbis-semantics-clarif-00 - URN Semantics Clarification]] ( ([TIME[2014-10-17 02:49:34 +09:00]] 版)) [25] [CITE@en[draft-ietf-urnbis-ns-reg-transition-03 - Uniform Resource Name (URN) Namespace Registration Transition]] ( ([TIME[2014-10-16 23:13:55 +09:00]] 版)) [26] [CITE@en[draft-ietf-urnbis-rfc2141bis-urn-08 - Uniform Resource Names (URNs)]] ( ([TIME[2014-12-30 21:52:42 +09:00]] 版)) [1] [CITE@en[RFC 3404 - Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application]] ([TIME[2017-04-23 18:20:18 +09:00]]) [2] [CITE@en[RFC 1737 - Functional Requirements for Uniform Resource Names]] ([TIME[2017-04-16 16:25:02 +09:00]]) [4] [CITE@en[RFC 2169 - A Trivial Convention for using HTTP in URN Resolution]] ([TIME[2017-04-24 00:22:00 +09:00]]) [5] [CITE@en[RFC 2483 - URI Resolution Services Necessary for URN Resolution]] ([TIME[2017-04-16 16:20:23 +09:00]]) [6] [CITE@en[RFC 2168 - Resolution of Uniform Resource Identifiers using the Domain Name System]] ([TIME[2017-04-23 19:27:05 +09:00]]) [9] [CITE[Uniform Resource Names (URN) Progress Report]] ([TIME[2013-05-10 03:59:13 +09:00]]) [10] [CITE@en[RFC 2276 - Architectural Principles of Uniform Resource Name Resolution]] ([TIME[2017-04-16 22:04:11 +09:00]]) [11] [CITE@en[RFC 2611 - URN Namespace Definition Mechanisms]] ([TIME[2017-04-24 03:36:15 +09:00]]) [12] [CITE@en[RFC 8141 - Uniform Resource Names (URNs)]] ([TIME[2017-05-07 23:08:37 +09:00]]) [31] [CITE@ja[Protocol Handlers for Microsoft Internet Explorer - misuzilla.org]] ([[Mayuki Sawatari]] 著, [TIME[2007-04-28 12:45:30 +09:00]] 版) [33] [CITE[URN supported w3m - Ancient library]] ([[KONDOU, Kazuhiro]] 著, [TIME[2010-04-20 00:45:28 +09:00]] 版) [34] [CITE@en[Features | AXR: Arbitrary XML Rendering | AXR Project]] ( ([[Miro Keller]] 著, [TIME[2012-06-23 18:07:31 +09:00]] 版)) [35] [CITE[OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 3: Packages]] ([TIME[2011-09-29 13:00:00 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [36] [CITE[OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 3: Packages]] ([TIME[2011-09-29 13:00:00 +09:00]] 版) ]FIGCAPTION] > urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish: The same algorithm as identified by Blowfish CFB.  ]FIG] [FIG(quote)[ [FIGCAPTION[ [37] [CITE@en[GetOrders - API Reference - Trading API]] ([TIME[2017-04-22 03:17:58 +09:00]]) ]FIGCAPTION] > > ]FIG] [FIG(quote)[ [FIGCAPTION[ [38] ( ([TIME[2017-05-11 16:25:46 +09:00]])) ]FIGCAPTION] > > ]FIG] [FIG(quote)[ [FIGCAPTION[ [39] [CITE@en[RFC 6241 - Network Configuration Protocol (NETCONF)]] ([TIME[2017-05-07 18:00:15 +09:00]]) ]FIGCAPTION] > The :url capability is identified by the following capability string: > urn:ietf:params:netconf:capability:url:1.0?scheme={name,...} > ]FIG] [FIG(quote)[ [FIGCAPTION[ [42] [CITE@en[Media RSS Specification]] ([TIME[2018-04-30 17:31:16 +09:00]]) ]FIGCAPTION] > scheme is the URI that identifies the role scheme. It is an optional attribute and possible values for this attribute are ( urn:ebu | urn:yvs ) . ]FIG] [44] [CITE[VRML97, ISO/IEC 14772-1:1997 -- Annex F, Recommendations for non-normative extensions]], [TIME[2014-01-30T22:20:50.000Z]], [TIME[2025-11-07T09:00:18.695Z]]