人々は、URL、URI、およびURNについて、まるで違うものであるかのように話しますが、肉眼では同じに見えます。

それらの間の区別できる違いは何ですか？

RFC 3986から：

URIは、ロケーター、名前、またはその両方にさらに分類できます。「Uniform Resource Locator」（URL）という用語は、リソースの識別に加えて、その主要なアクセスメカニズム（たとえば、そのネットワーク「ロケーション」）を記述することによってリソースを特定する手段を提供するURIのサブセットを指します。用語「ユニフォームリソース名」（URN）は「URN」方式で、両方のURIを参照するために歴史的に使用されてきた[RFC2141]リソースが存在しなくなるか、使用不能になった場合にもグローバルに一意の永続的なままであることが要求される、および名前のプロパティを持つ他のURIに。

したがって、すべてのURLはURI（実際には完全ではない-以下を参照）であり、すべてのURNはURIですが、URNとURLは異なるため、すべてのURIがURLであるとは言えません。

編集：以前はすべてのURLが有効なURIであると思っていましたが、コメントの通り：

「すべてのURLがURIである」わけではありません。RFCの解釈に依存します。たとえば、Javaでは、URIパーサーは[or ]を好きではありません。これは、仕様に「すべきではない」および「すべきではない」ではないためです。

そのため、残念ながら水をさらに濁らせます。

Roger Pateの回答をまだ読んでいない場合は、同様に読むことをお勧めします。

URIが識別し、 URLが特定します。ただし、ロケーターは識別子でもあるため、すべてのURLもURIですが、URLでないURIもあります。

例

• ロジャー・ペイト

これは識別子である私の名前です。URIのようなものですが、私の場所や連絡方法について何も知らないため、URLにすることはできません。この場合、米国だけで少なくとも5人の他の人々を識別することも起こります。

• 4914 West Bay Street、ナッソー、バハマ

これはロケーターであり、その物理的な場所の識別子です。これは、（すべてのURLはURIのであるため）URLとURIの両方に似ている、とも私を識別し、間接的に「の住民..」。この場合、それは私を一意に識別しますが、ルームメイトを取得すると、それは変化します。

これらの例は必要な構文に従っていないため、「いいね」と言っています。

人気の混乱

ウィキペディアから：

コンピューティングでは、Uniform Resource Locator（URL）は、識別されたリソースが利用可能な場所とそれを取得するメカニズムを指定するUniform Resource Identifier（URI）のサブセットです。一般的な使用法や多くの技術文書や口頭での議論では、URIの同義語として誤って使用されることがよくあります... [強調]

この一般的な混乱のため、多くの製品とドキュメントでは、一方の用語を他方の用語ではなく誤って使用したり、独自の区別を割り当てたり、同義語として使用したりしています。

URN

私の名前、Roger Pateは、URN（Uniform Resource Name）のようなものである可能性がありますが、それらははるかに規制されており、空間と時間の両方で一意であることを意図しています。

私は現在この名前を他の人と共有しているため、グローバルに一意ではなく、URNとしては適切ではありません。ただし、他の家族がこの名前を使用していない場合でも、私は父方の祖父にちなんで名前が付けられているため、時間の経過によって一意となることはありません。そうでない場合でも、自分の子孫に名前を付ける可能性があるため、URNとしては不適切です。

URNは両方ともURIの構文を共有していますが、この厳密な一意性制約の点でURLとは異なります。

URI- Uniform Resource Identifier

URIは、数字、文字、記号の短い文字列を使用してドキュメントを識別するための標準です。それらはRFC 3986-Uniform Resource Identifier（URI）：Generic Syntaxによって定義されています。URL、URN、およびURCはすべてURIのタイプです。

URL- Uniform Resource Locator

その場所からリソースをフェッチする方法に関する情報が含まれています。例えば：

• http://example.com/mypage.html
• ftp://example.com/download.zip
• mailto:user@example.com
• file:///home/user/file.txt
• tel:1-888-555-5555
• http://example.com/resource?foo=bar#fragment
• /other/link.html （相対URL、別のURLのコンテキストでのみ有用）

URLは常にプロトコル（http）で始まり、通常はネットワークホスト名（example.com）、多くの場合ドキュメントパス（/foo/mypage.html）などの情報が含まれています。URLには、クエリパラメータとフラグメント識別子を含めることができます。

URN- 統一リソース名

一意の永続的な名前でリソースを識別しますが、必ずしもインターネット上でリソースを見つける方法を示しているわけではありません。通常は、プレフィックスで始まりますurn: 。次に例を示します。

• urn:isbn:0451450523 ISBN番号で本を識別するため。
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 グローバルに一意の識別子
• urn:publishing:book -ドキュメントを本のタイプとして識別するXML名前空間。

URNはアイデアと概念を識別できます。それらは文書の識別に限定されません。URNがドキュメントを表す場合、「リゾルバ」によってURLに変換できます。その後、ドキュメントをURLからダウンロードできます。

URC-統一リソース引用

ドキュメント自体ではなく、ドキュメントに関するメタデータを指します。URCの例は、次のようなページのHTMLソースコードを指すものです。view-source:http://example.com/

データURI

データをインターネットで検索したり、名前を付けたりするのではなく、データを直接URIに配置できます。例はですdata:,Hello%20World。

よくある質問

URLを言うべきではないと聞いたのですが、なぜですか？

HTMLのW3仕様でhrefは、アンカータグのに、URLだけでなくURIを含めることができると規定されています。などのURNを入力できるはず<a href="urn:isbn:0451450523">です。次に、ブラウザはそのURNをURLに解決し、書籍をダウンロードします。

ブラウザは実際にURNによってドキュメントを取得する方法を知っていますか？

私が知っていることではありませんが、最新のWebブラウザーはデータURIスキームを実装しています。

URLとURIの違いは、それが相対か絶対かに関係しますか？

いいえ。相対URLと絶対URLはどちらもURL（およびURI）です。

URLとURIの違いは、クエリパラメータがあるかどうかに関係がありますか？

いいえ。クエリパラメータのあるURLとないクエリのURLはどちらもURL（およびURI）です。

URLとURIの違いは、フラグメント識別子があるかどうかに関係がありますか？

いいえ。フラグメント識別子を含むURLと含まないURLはどちらもURL（およびURI）です。

URLとURIの違いは、許可されている文字に関係がありますか？

いいえ。URLは、URIの厳密なサブセットとして定義されています。パーサーがURLの文字を許可し、URIの文字を許可しない場合、パーサーにバグがあります。仕様では、URLとURIのどの部分でどの文字を使用できるかについて詳しく説明しています。一部の文字はURLの一部でのみ許可される場合がありますが、URLとURIの違いは文字だけではありません。

しかし、W3CはURLとURIが同じものであると今言っていませんか？

はい。W3Cは、これについては多くの混乱があることに気づきました。彼らは、URIとURIを（URIを意味するために）交換可能に使用できるようになったと述べたURI明確化文書を発行しました。URIをURL、URN、URCなどの異なるタイプに厳密にセグメント化することは、もはや役に立ちません。

URIをURLとURNの両方にすることはできますか？

URNの定義は、上記で述べたものよりも緩くなっています。URIに関する最新のRFCは、任意のURIは、今（かかわらず、それはで始まるかどうかのURNことができることを述べているurn:限り、それは持っているとして）「名前のプロパティを。」つまり、リソースが存在しなくなったり使用できなくなったりした場合でも、グローバルに一意で永続的です。例：などのHTML doctypeで使用されるURI http://www.w3.org/TR/html4/strict.dtd。そのURIは、w3.org Webサイトのページが削除された場合でも、HTML4移行Doctypeを引き続き指定します。

要約すると、URIは識別し、URLは識別して特定します。

シェークスピアの劇 『ロミオとジュリエット』の特定のエディションについて考えてみましょう。これらのエディションのホームネットワークにデジタルコピーがあります。

テキストはとして識別できますurn:isbn:0-486-27557-4。
それはURIですが、より具体的にはURN * はテキストに名前を付けるためです。

テキストをとして識別することもできますfile://hostname/sharename/RomeoAndJuliet.pdf。
これはURIでもありますが、より具体的にはテキストを見つけるためのURL です。

*統一リソース名

（私の例はWikipediaから採用されていることに注意してください）

これらはいくつかの非常によく書かれているが長続きする答えです。CodeIgniterに関する限り、以下の違いがあります。

URL - http://example.com/some/page.html

URI- /some/page.html

簡単に言えば、URLはリソースをどこにでも特定するための完全な方法であり、FTP、HTTP、SCPなどの異なるプロトコルを持つことができます。

URIは現在のドメインのリソースであるため、見つけられる情報が少なくて済みます。

CodeIgniterがURLまたはURIという単語を使用するすべてのインスタンスで、これは彼らが話している違いですが、Webのグランドスキームでは100％正しくありません。

まず第一に、あなたの心を混乱から解放し、それを単純にしてください、そしてあなたは理解するでしょう。

URI => Uniform Resource Identifier リソースの完全なアドレス、つまり場所、名前、またはその両方を識別します。

URL => Uniform Resource Locator リソースの場所を識別します。

URN => Uniform Resource Nameリソースの名前を 識別します

例

https://www.google.com/folder/page.htmlというアドレスがあります。

URI（Uniform Resource Identifier）=> https://www.google.com/folder/page.html

URL（Uniform Resource Locator）=> https://www.google.com/

URN（Uniform Resource Name）=> /folder/page.html

URI =>（URL + URN）またはURLのみまたはURNのみ

すでに投稿されている回答に少し加えて、理論を要約するためのベンの図を次に示します（Prateek Joshiの美しい説明から）：

そして例（同じくPrateekのウェブサイトから）：

これは、私がWebプロフェッショナルとして遭遇した中で最も混乱し、おそらく無関係なトピックの1つです。

私が理解しているように、URIは何かの説明であり、受け入れられた形式に従って、何かの一意の名前（識別）とその場所の両方またはいずれかを定義できます。

2つの基本的なサブセットがあります。場所（特にWebページを検索しようとしているブラウザー）を定義するURLと、一意の名前を定義するURNです。

私はURNをGUIDに似ていると考える傾向があります。これらは、物事に一意の名前を付けるための標準化された方法論にすぎません。会社の名前を使用する宣言的な名前空間のように-テキスト行に対応するリソースがサーバーのどこかにあるのとは異なり、単に何かを一意に識別します。

また、URIという用語は完全に避け、混乱を招くため、必要に応じてURLまたはURNの観点からのみ説明します。私たちが実際に人々のために答えてみるべき質問は、それほど意味論ではありませんが、用語に遭遇したときに、プログラミング状況へのアプローチを変えるそれらの実用的な違いがあるかどうかを識別する方法です。たとえば、会話の中で誰かが私を訂正して「ああ、それはURLではなく、URIだ」と言った場合、私は彼らがそれで一杯であることを知っています。「URNを使用してリソースを定義している」と誰かが言った場合、サーバーに配置するのではなく、一意に名前を付けるだけであると理解する可能性が高くなります。

ベースから外れている場合はお知らせください。

アイデンティティ=名前と場所

すべてのURL（U niform R esource L ocator）は、抽象的に言えばURI（U niform R esource I identifier）ですが、すべてのURIはURLではありません。URIの別のサブカテゴリにはURN（U niform R esource N ame）があります。これは名前付きリソースですが、mailto、ニュース、ISBNはURIのようにそれらを見つける方法を指定しません。 ソース

URN：

• URN形式： urn:[namespace identifier]:[namespace specific string]
• urn：と：は自分自身を表します。
• 例：
  • urn：uuid：6e8bc430-9c3a-11d9-9669-0800200c9a66
  • urn：ISSN：0167-6423
  • urn：isbn：096139210x
  • Amazonリソースネーム（ARN）は、AW​​Sリソースを一意に識別するものです。
    • ARN形式： arn:partition:service:region:account-id:resource

URL：

• URL形式： [scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
• ：、// ,? と＃は自分自身を表します。
• スキームは、https、ftp、gopher、mailto、ニュース、telnet、ファイル、man、info、whatis、ldap ...です。
• 例：
  • http：// ip_server / path？query
  • ftp：// ip_server / path
  • mailto：email-address
  • ニュース：ニュースグループ名
  • telnet：// ip_server /
  • file：// ip_server / path_segments
  • ldap：// hostport / dn？attributes？scope？filter？extensions

類推：人
に到達するには：運転（他のプロトコルSMS、電子メール、電話）、アドレス（ホスト名他の電話番号、電子メールID）および人名（相対パスを持つオブジェクト名）。

URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

URLは、URIのサブセットです（URNも含まれます）。

基本的に、URIは一般的な識別子であり、URLは場所を指定し、URNは名前を指定します。

URIについて考えるときに使用したいもう1つの例は、XMLドキュメントのxmlns属性です。

<rootElement xmlns:myPrefix="com.mycompany.mynode">
    <myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>

この場合、com.mycompany.mynodeは、XMLドキュメント内でそれを使用するすべての要素の「myPrefix」名前空間を一意に識別するURIになります。これは、それ自体を特定するためだけに使用され、それ自体を見つけるためではないため、URLではありません。

URIとURLを明確に区別することが難しいため、覚えている限りでは、W3CはURIとURLの間にもはや違いを生じません（http://www.w3.org/Addressing/）。

それらは同じものです。URIはURLを一般化したものです。元々、URIはURL（アドレス）とURN（名前）に分割される予定でしたが、URLとURIにはほとんど違いがなく、実際にはリソースが見つからなかったとしても、URIは名前空間として使用されました。

URI、URL、URN

上の画像が示すように、ここでは3つの異なるコンポーネントが機能しています。このような問題について話し合うときは、通常、ソースに行くのが最善です。そのため、ここではTim Berners-Leeなどからの抜粋です。al。 RFC 3986：統一資源識別子（URI）：一般的な構文：

Uniform Resource Identifier（URI）は、抽象リソースまたは物理リソースを識別するコンパクトな文字シーケンスです。

URIは、ロケーター、名前、またはその両方にさらに分類できます。「Uniform Resource Locator」（URL）という用語は、リソースの識別に加えて、そのプライマリアクセスメカニズム（たとえば、そのネットワーク「ロケーション」）を記述することによってリソースを特定する手段を提供するURIのサブセットを指します。

URIは、URLとURNのスーパークラスの一種です。ウィキペディアには、RFCの正しいセットへのリンクを含む、それらに関するすばらしい記事があります。

ウィキペディアはここに必要なすべての情報を提供します。http://en.wikipedia.org/wiki/URIからの引用：

URLは、リソースの識別に加えて、その主要なアクセスメカニズムまたはネットワークの「場所」を説明することにより、リソースに作用する、またはリソースの表現を取得する手段を提供するURIです。

URL

URLは、特定のリソースのネットワークロケーションを定義するURIの特殊化です。URNとは異なり、URLはリソースの取得方法を定義します。私たちは毎日http://example.comなどの形式でURLを使用していますが、URLは必ずしもHTTP URLである必要はありftp://example.comません。

URI

URIは、場所または名前、あるいはその両方でリソースを識別します。ほとんどの場合、私たちのほとんどは、リソースの場所を定義するURIを使用します。URIが名前と場所の両方でリソースを識別できるという事実は、私の意見では多くの混乱を招いています。URIには、URLとURNと呼ばれる2つの特殊化があります。

URLとURIの違い

URIはリソースの識別子ですが、URLはそのリソースを取得するための特定の情報を提供します。URIはURLであり、1人のコメンターが指摘したように、アプリケーションを記述するときにURLを使用するのは正しくないと見なされています。一般に、URLがリソースの場所と名前の両方を記述している場合、使用する用語はURIです。これは一般的に私たちのほとんどが日常的に遭遇するケースであるため、URIが正しい用語です。

RFC 3986に従って、URIは次の要素で構成されています。

scheme://authority/path?query

URIは、サーバー（機関）上のリソース（パス）またはアプリケーション（クエリ）にアクセスするためのプロトコルを記述します。

すべてのURLはURIであり、すべてのURNはURIですが、すべてのURIはURLではありません。

詳細については参照してください：

ウィキペディア

URIは、場所または名前、あるいはその両方でリソースを識別します。ほとんどの場合、私たちのほとんどは、リソースの場所を定義するURIを使用します。URIが名前と場所の両方でリソースを識別できるという事実は、私の意見では多くの混乱を招いています。URIには、URLとURNと呼ばれる2つの特殊化があります。

URLは、特定のリソースのネットワークロケーションを定義するURIの特殊化です。URNとは異なり、URLはリソースの取得方法を定義します。私たちは毎日http://stackoverflow.comなどの形式でURLを使用しています。ただし、URLは必ずしもHTTP URLである必要はありませんftp://example.com。

URIとURLという用語は厳密に定義されていますが、多くの場合、定義されている以外の用語を使用します。

Apacheを例にとってみましょう。Apacheサーバーからhttp://example.com/fooがリクエストされた場合、次の環境変数が設定されます。

• REDIRECT_URL： /foo
• REQUEST_URI： /foo

mod_rewriteを有効にすると、次の変数も得られます。

• REDIRECT_SCRIPT_URL： /foo
• REDIRECT_SCRIPT_URI： http://example.com/foo
• SCRIPT_URL： /foo
• SCRIPT_URI： http://example.com/foo

これが混乱の原因かもしれません。

このドキュメントを参照してください。具体的には

URLは、ある種の属性ではなく、その主要なアクセスメカニズム（ネットワークの「場所」など）の表現を介してリソースを識別するURIの一種です。

本当に、それは非常に明確な用語ではありません。

投稿を読んだ後、私はいくつかの非常に関連するコメントを見つけました。つまり、URL定義とURI定義の混同は、ソフトウェア開発におけるURIの単語の非公式な使用に依存する定義に部分的に基づいています。

定義上、URLはURI [RFC2396]のサブセットです。URIにはURNとURLが含まれます。URIとURLの両方に、URIまたはURLのステータスを付与する固有の構文があります。URNはリソースを一意に識別するためのものであり、URLはリソースを見つけるためのものです。リソースは複数のURLを持つことができますが、URNは1つだけであることに注意してください。[RFC2611]

Web開発者およびプログラマーとして、私たちはほとんど常にURLに、したがってURIに関心があります。これで、URLは、たとえばhttps://stackoverflow.com/questionsのように、すべてのパーツのschema：scheme-specific-partを持つように明確に定義されました。これはURLであり、URIでもあります。次に、.. / index.htmlなどの、ページに埋め込まれた相対リンクを考えます。これはもはや定義上URLではありません。それはまだ「URI参照」[RFC2396]と呼ばれているものです。

相対パスを参照するためにURIという単語が使用されている場合、「URI参照」は実際に考えられていることだと思います。したがって、非公式に、ソフトウェアシステムはURIを使用して相対パスと絶対アドレスのURLを参照します。したがって、この意味で、相対パスはURLではなくURIです。

これが私の単純化です：

URN：一意のリソース名、つまり「何を」（たとえばurn：issn：1234-5678）。これは一意であることを意味します。2つの異なるドキュメントが同じurnを持つことはできないためです。「uuid」のようなもの

URL：それを見つける「場所」（例：https: //google.com/pub?issnid=1234-5678 ..または ftp://somesite.com/doc8.pdf）

URI：URNまたはURLのいずれかです。このあいまいな定義は、W3CおよびIETFによって作成されたRFC 3986のおかげです。

URIの定義は長年にわたって変更されているため、ほとんどの人が混乱するのは当然のことです。ただし、http：//somesite.com/somethingをURLまたはURIのいずれかとして参照できるので、安心することができます。どちらにしても正しいでしょう（少なくとも、とりあえずはとりあえず）。 。）

私は同じことについて疑問に思っていて、これを見つけました：http : //docs.kohanaphp.com/helpers/url。

url::current()メソッドを使用して明確な例を見ることができます。このURLがある場合：http://example.com/kohana/index.php/welcome/home.html?query=stringを使用すると、ドキュメントによると、url:current()次のURIが提供されます：welcome / home

URIは、Web 上のリソース、および電子メールボックスなどの他のインターネットリソースを統一された一貫した方法で識別する必要性から生まれました。そのため、新しいタイプのウィジェット： URIを導入してウィジェットリソースを識別したり、tel： URIを使用してWebリンクで呼び出し時に電話をかけたりすることができます。

一部のURIはリソースを見つけるための情報（DNSホスト名やそのマシン上のパスなど）を提供しますが、一部のURIは純粋なリソース名として使用されます。URLは識別子のために予約されているリソースロケータあるなど、「HTTP」のURLを含む、http://stackoverflow.comホスト上の指定されたパスにWebページを識別し、。別の例は、特定のアドレスのメールボックスを識別するmailto：fred@mail.orgなどの「mailto」URLです。

URNは、ロケーターではなく純粋なリソース名として使用されるURIです。たとえば、URI：mid：0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.comは、「Message-Id」フィールドに含まれている電子メールメッセージを識別するURNです。URIは、そのメッセージを他の電子メールメッセージと区別するのに役立ちます。ただし、それ自体はどのストアでもメッセージのアドレスを提供しません。

これに答えるために、私は別の質問に変更した答えに頼ります。URIの良い例は、Amazon S3リソースを識別する方法です。取りましょう：

s3://www-example-com/index.html _[図。1]

のキャッシュコピーとして作成した

http://www.example.com/index.html _[図。2]

AmazonのS3-US-West-2データセンター。

StackOverflowによってs3:// プロトコルスキームへのハイパーリンクが許可されたとしても、リソースの場所を特定することはできません。リソースを識別するため、図 1は有効なURIです。Amazonではバケット（URI の一部を表す用語）がデータセンター全体で一意である必要があるため、これも有効なURNです。それを見つけるのに役立ちますが、データセンターを示すものではありません。したがって、URLとして機能しません。authority

では、この場合、URI、URL、およびURNはどのように異なるのでしょうか。

• 図。1はURIです
• 図。1はURNです
• 図。2はURIです
• 図。2はURLです
• イチジクのURL 1はhttp://www-example-com.s3-website-us-west-2.amazonaws.com/です
  • また、http：//www-example-com.s3.amazonaws.com/index.html
  • ではなくhttp://www-example-com.s3.amazonaws.com/（何のデータセンターとなしのファイル名は、Amazon S3のための一般的すぎるではありません）

注： RFC 3986はURIを次のように定義していますscheme://authority/path?query#fragment

説明が簡単：

以下を仮定しましょう

URIはあなたの名前です

URLは、あなたと通信するためにあなたの名前を入れたあなたのアドレスです。

• 私の名前はロヨラです

  ロヨラはURIです

• 私の住所はTN、チェンナイ600001です。

TN、チェンナイ600 001、ロヨラはURL

ご理解いただければ幸いです。

正確な例を見てみましょう

http://www.google.com/fistpage.html

あなたが呼ばれるページと通信することができます上記でfirstpage.html （URI次使用）http://www.google.com/fistpage.html（URLを）。

したがって、URIはURLのサブセットですが、その逆はありません。

Uniform Resource Identifier（URI）は、インターネットリソースを識別する文字列です。

最も一般的なURIは、インターネットドメインアドレスを識別するUniform Resource Locator（URL）です。別の、あまり一般的ではないタイプのURIは、ユニバーサルリソース名（URN）です。

私が見つけた：

Uniform Resource Identifier（URI）は、全体像を表しています。URIを分割できます。URIは、ロケーター（ユニフォームリソースロケーター-URL）、名前（ユニフォームリソース名-URN）、またはその両方に分類できます。つまり、基本的に、URNは人の名前のように機能し、URLはその人のアドレスを表します。要するに、URNはアイテムのIDを定義し、URLはそれを見つける方法を定義し、最後にこれら2つの概念をカプセル化するのがURIです。

最高の（技術的な）要約imoはこれです

IRI、URI、URL、URN、および Jan Martin Keil との違い：

IRI、URI、URL、URNおよびそれらの違い

セマンティックWebを扱う誰もが繰り返しIRI、URI、URL、URNという用語に出くわします。それにもかかわらず、私は頻繁にそれらの正確な意味についていくつかの混乱があることに気づきます。そしてもちろん、他の人たちもそれに気づきました（RFC3305やGoogleで検索などを参照）。正直なところ、最初は戸惑っていました。しかし、実際には問題はそれほど複雑ではありません。上記の用語の定義を見て、違いを見てみましょう。

URI

ユニフォームリソース識別子は、抽象的又は物理的リソースを識別する文字のコンパクトな配列です。文字のセットは、一部の予約文字を除いてUS-ASCIIに制限されています。許可された文字セット以外の文字は、Percent-Encodingを使用して表すことができます。URIは、ロケーター、名前、またはその両方として使用できます。URIがロケーターの場合、それはリソースの主要なアクセスメカニズムを記述します。URIが名前の場合、一意の名前を付けることでリソースを識別します。URIの構文とセマンティクスの正確な仕様は、最初のコロンの前の文字で定義される、使用されるスキームによって異なります。[RFC3986]

URN

ユニフォームリソース名は、スキームURNにおけるURIが永続的、位置に依存し、リソース識別子として機能することが意図されています。歴史的に、この用語は任意のURIも指していました。[RFC3986] URNは、名前空間識別子（NID）と名前空間固有の文字列（NSS）で構成されています。urn :: NSSの構文とセマンティクスは、各NIDに固有です。登録されたNIDのほかに、正式な登録プロセスを通過しなかったNIDがさらにいくつか存在します。[RFC2141]

URL

ユニフォームリソースロケータは、リソースを識別することに加えて、その主要なアクセスメカニズム[RFC3986]を記述することにより、リソースの位置を特定する手段を提供し、URIです。一連のスキームによるURLの正確な定義がないため、「URLは有用ですが非公式な概念です」。通常、URNを含まないURIのサブセットを指します[RFC3305]。

IRI

アン国際化リソース識別子は、 URIと同様に定義されていますが、文字セットは、ユニバーサル符号化文字セットに拡張されます。したがって、予約文字を除くすべてのラテン文字と非ラテン文字を含めることができます。URIの定義を拡張する代わりに、IRIという用語が明確な区別を可能にし、非互換性を回避するために導入されました。IRIは、ユニバーサルコード化文字セットがサポートされている状況でリソースを識別する際にURIを置き換えることを目的としています。定義により、すべてのURIはIRIです。さらに、IRIからURIへの定義された全射マッピングがあります。すべてのIRIは、正確に1つのURIにマッピングできますが、異なるIRIが同じURIにマッピングされる場合があります。したがって、URIからIRIに戻す変換では、元のIRIが生成されない場合があります。[RFC3987]

要約すると次のようになります。

IRI is a superset of URI (IRI ⊃ URI)
URI is a superset of URL (URI ⊃ URL)
URI is a superset of URN (URI ⊃ URN)
URL and URN are disjoint (URL ∩ URN = ∅)

セマンティックWebの問題に関する結論

RDFはIRIを使用してエンティティーに名前を付けることを明示的に許可しています[RFC3987]。つまり、エンティティ名にはほとんどすべての文字を使用できます。一方、初期状態のソフトウェアを扱わなければならないことがよくあります。したがって、非ASCII文字を使用して問題が発生する可能性は低くありません。したがって、エンティティの非URI名を避けることをお勧めし、http URI [リンクされたデータ]を使用することをお勧めします。簡単に言うと、エンティティの名前にはURLのみを使用します。もちろん、URNで指定された既存のエンティティを参照できます。ただし、この種類の識別子を新しく作成することは避けてください。