RDF 1.2 の概念と抽象データモデル

W3C 勧告候補スナップショット

この文書に関する詳細
このバージョン:
https://www.w3.org/TR/2026/CR-rdf12-concepts-20260407/
最新公開バージョン:
https://www.w3.org/TR/rdf12-concepts/
最新編集者草案:
https://w3c.github.io/rdf-concepts/spec/
履歴:
https://www.w3.org/standards/history/rdf12-concepts/
コミット履歴
テストスイート:
https://w3c.github.io/rdf-tests/rdf/rdf12/
実装報告:
https://w3c.github.io/rdf-tests/rdf/rdf12/reports/
最新勧告:
https://www.w3.org/TR/rdf11-concepts
編集者:
Gregg Kellogg（2025-09-06まで）、追悼
Olaf Hartig
Pierre-Antoine Champin
Andy Seaborne
以前の編集者:
Richard Cyganiak（RDF 1.1）
David Wood（RDF 1.1、議長）
Markus Lanthaler（RDF 1.1）
Graham Klyne（RDF 1.0）
Jeremy J. Carroll（RDF 1.0）
Brian McBride（RDF 1.0、議長）
フィードバック:
GitHub w3c/rdf-concepts （プルリクエスト、 新しい課題、 未解決の課題）
public-rdf-star-wg@w3.org 件名行を[rdf12-concepts] … メッセージのトピック …として送信してください（アーカイブ）

Copyright © 2004-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

Resource Description Framework（RDF）は、Web上の情報を 表現するためのフレームワークです。 この文書は、すべてのRDFベースの言語および仕様を結び付ける役割を果たす 抽象データモデルを定義します。 抽象データモデルには、2つの主要なデータ構造があります:

RDF 1.1と比較して、RDF 1.2では、あるRDFトリプルを、 別のトリプルの 目的語位置における トリプル項として使用できるようになります。 RDF 1.2では、方向付き言語タグ付き文字列も導入されます。 これは、ユーザーエージェントによる表示のために 初期テキスト方向を指定できる基底方向コンポーネントを含みます。 最後に、RDF 1.1からRDF 1.2への移行を容易にするために、 この仕様は、与えられたデータ片で使用されるRDFのバージョンを 明示的に伝達する ための仕組みを導入します。

この仕様は、RDF 1.2の主要な概念と用語を導入し、その後、 データ型付けと、RDFグラフ内のIRIにおけるフラグメント識別子の扱いについて 議論します。

この文書のステータス

この節は、この文書の 公開時点におけるステータスを説明します。現在のW3C 出版物の一覧と、この技術報告の最新改訂版は、 W3C標準および草案 インデックスで確認できます。

この文書はRDF 1.2文書群の一部です。 これはRDF 1.2の中心的な仕様であり、RDFの中核概念を定義します。 この文書を土台に構築されるいくつかのRDF 1.2 仕様のテストスイートと実装報告は、 各仕様で参照されているように、 rdf-testsリポジトリの rdf-tests/rdf/rdf12 で入手できます。

RDF 1.2 Concepts（この仕様）は抽象データモデルを説明するものであり、 ソフトウェアで直接実装されるものではないため、独立したテストスイートはありません。 代わりに、その上に構築される仕様によって実装されます。 その結果、W3C勧告候補 段階を終了するには、 W3C RDF & SPARQL Working Groupは、 [RDF12-SEMANTICS]および具象構文の少なくとも1つの仕様 （例: [RDF12-N-TRIPLES]）が、 W3C勧告候補段階に関する それぞれの終了基準を満たしていることを要求します。

RDF 1.2 Conceptsは[RDF11-CONCEPTS]の更新であり、 それ自体は[RDF-CONCEPTS-20040210]の更新でした。

この文書は、RDF & SPARQL Working Groupによって、 Recommendation trackを使用する 勧告候補スナップショットとして公開されました。

勧告候補としての公開は、 W3Cおよびそのメンバーによる承認を意味しません。 勧告候補スナップショットは 広範なレビューを受けており、 実装経験を 集めることを目的としており、 実装に対するロイヤリティフリーライセンスについて ワーキンググループメンバーからのコミットメントを得ています。

この今後の勧告に対する将来の更新では、 新機能が組み込まれる可能性があります。

この勧告候補は、2026年5月5日より前に 勧告へ進むことは想定されていません。

この文書は、 W3C Patent Policyの下で運営される グループによって作成されました。 W3Cは、 当該グループの成果物に関連して行われた 特許開示の公開リスト を維持しています。そのページには、 特許を開示するための手順も含まれています。個人が、 その個人が実際に知る特許に Essential Claim(s) が含まれると考える場合、 その情報を W3C Patent Policy第6節に従って開示しなければなりません。

この文書は、 2025年8月18日版W3C Process Documentに準拠します。

1. 導入

この節は非規範的です。

Resource Description Framework（RDF）は、Web上の情報を 表現するためのフレームワークです。

この文書は、すべてのRDFベースの言語および仕様を結び付ける役割を果たす 抽象データモデルを定義します。 これには以下が含まれます:

1.1 グラフベースの抽象データ モデル

抽象データモデルの中核構造は、 トリプルの集合であり、それぞれが主語、 述語、および目的語から構成されます。このようなトリプルの集合は、 RDF グラフと呼ばれます。RDFグラフはノードと 有向弧の図として視覚化でき、この図では各トリプルが ノード-弧-ノードのリンクとして表されます。

図 1 2つのノード（主語と目的語）と、それらを接続する弧（述語）を持つRDFグラフ。

ノードには、 RDF グラフ内に存在できる4種類があります: IRI、リテラル、 空白 ノード、およびトリプル項です。

この定義から、1つの項が複数の トリプルに現れる場合、それらは単に同じ項の複数の出現であることが分かります。例えば、 2つのトリプルを含むグラフ（ここでは一般的な 集合および タプル表記で表し、 個別の項として抽象名を使用しています）では: 

{ (R1, P1, R3),
  (R2, P2, R3) }

項R3は2回使用されている同一の単一項であり、合計で5つの項があります。 これは2次元のグラフ図でより分かりやすく示され、 そこでは1つのノードが、ラベル付き弧を使用して複数の他の ノードから、または複数の他のノードへ単純に接続できます。

図 2 3つのノード（R1、R2、R3）と2つの弧（P1、P2）を持ち、 それらの弧がそれぞれR1およびR2をR3に接続しているRDFグラフ。

この抽象データモデルは、 1.9 RDF文書 と構文で説明されるように、同じ構造を保持しながら さまざまな方法でエンコードできます。

注記

1.2 リソースと文

任意のIRIまたはリテラルは、 世界（「議論領域」）の何かを示します。 これらのものは リソースと呼ばれます。物理的なもの、文書、抽象概念、数値、 文字列など、何でもリソースになり得ます。この用語は、 RDF 1.2 Semantics [RDF12-SEMANTICS]で使用される 「エンティティ」と同義です。 IRIによって示されるリソースはその 指示対象と呼ばれ、 リテラルによって示されるリソースはその リテラル値と呼ばれます。リテラルには、 文字列、数値、日付など、取り得る値の範囲を定義する データ型があります。特殊な種類のリテラル — 言語タグ付き文字列および方向付き言語タグ付き文字列 — は、それぞれ自然言語の平文文字列、および初期テキスト方向を含む 自然言語の平文文字列を示します。

RDFトリプルを表明することは、 述語によって示される何らかの関係が、 主語および目的語によって 示される リソース間に成り立つことを述べます （後述するように、すべてのトリプルが表明されるわけではありません）。 RDFトリプルに対応するこの文は、RDF文として知られています。 述語自体はIRIであり、 プロパティ、 すなわち二項関係と考えられるリソースを示します。 （2つを超えるエンティティに関わる関係は、RDFでは 間接的に 表現 [SWBP-N-ARYRELATIONS]することしかできません。）

IRIおよびリテラルとは異なり、 空白 ノードは特定の リソースを識別しません。空白ノードを含む 文は、 与えられた関係を持つ何かが存在することを、 それを明示的に名付けずに述べます。

1.3 IRIの指示対象

IRIによって示されるリソースは、 その指示対象とも呼ばれます。XSDデータ型を識別するものなど、 特定の意味を持つ一部のIRIについては、指示対象は この仕様によって固定されます。それ以外のすべてのIRIについては、 任意の与えられたIRIによって何が正確に 示されるかは、 この仕様では定義されません。他の 仕様がIRIの指示対象を固定したり、 任意のIRIの指示対象になり得るものに 他の制約を適用したりする場合があります。

IRIの 指示対象を決定するための指針は、 Architecture of the World Wide Web, Volume One [WEBARCH] やCool URIs for the Semantic Web [COOLURIS]のような 他の文書で提供されています。 以下に、非常に簡潔で非公式かつ部分的な説明を示します:

WebアーキテクチャにおけるIRIの おそらく最も重要な特性は、それらが 逆参照でき、 したがってリモートサーバーとの対話の出発点として機能することです。 この仕様はそのような対話には関与しません。 相互作用モデルを定義するものではありません。これは、リソースを記述するグラフデータモデルにおいて、 IRIをグローバルに一意な識別子としてのみ扱います。 しかし、そのような対話は、 Linked Data Design Issues [LINKED-DATA]の概念にとって重要です。 これはRDFの抽象構文と具象RDF 構文を使用し、 後者はシリアル化形式とも呼ばれます。

1.4 RDF語彙と 名前空間IRI

RDF語彙は、 RDFグラフで使用することを意図したIRIの集合です。 例えば、[RDF12-SCHEMA]で文書化されているIRIは、RDF Schema語彙です。 RDF Schema自体を使用して、追加の RDF語彙を定義および文書化できます。そのような語彙の一部は、 RDF 1.2 Primer [RDF12-PRIMER]で言及されています。

RDF語彙内のIRIは、 しばしば名前空間IRIとして知られる 共通の部分文字列で始まります。 一部の名前空間IRIは、慣習により 名前空間接頭辞として知られる短い名前に関連付けられます。

この仕様で使用されるいくつかの名前空間接頭辞とIRI
名前空間接頭辞 名前空間IRI RDF語彙
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF組み込み語彙 [RDF12-SCHEMA]
rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema語彙 [RDF12-SCHEMA]
xsd http://www.w3.org/2001/XMLSchema# RDF互換XSD型

一部のシリアル化形式では、 いくつかの名前空間IRIを任意の名前空間接頭辞に関連付け、 その名前空間IRIの いずれかで始まるIRIを、対応する名前空間接頭辞を使用して省略することで、 可読性を向上させることが一般的です。 例えば、 上の表の接頭辞対応に基づけば、 IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral はrdf:XMLLiteralと省略されます。 ただし、このような省略形は、IRIとして直接処理されることを 意図したものではなく、 IRIが期待される構文上の文脈で使用されるべきではありません。 また、名前空間IRIおよび名前空間 接頭辞は、RDF抽象データモデルの正式な一部ではないことにも注意してください。 これらは単にIRIを省略するための構文上の便宜にすぎません。 処理のためには、各名前空間接頭辞を対応する名前空間IRIに置換することによって、 実際のIRIが再構築されます。

「名前空間」という用語だけでは、RDFの文脈において 明確に定義された意味を持ちませんが、非公式に 「名前空間IRI」または「RDF語彙」を意味するために 使用されることがあります。

1.5 トリプル項と具象化

トリプル項とは、別のトリプル内で RDF項として使用される RDFトリプルです。 それはRDFトリプルであるため、 命題を示します。

具象化トリプルとは、述語が rdf:reifies であり、目的語がトリプル項であるトリプルです。 そのトリプルの主語は具象化子と呼ばれ、 他のトリプルの主語または目的語になり得ます。

具象化子は、トリプル項の命題に関連するさまざまなものを示し得ます。 例えば、その命題が成り立つという文や信念などです。 さらなる文では、（トリプル項ではなく） 具象化子が使用されることが想定されています。 この節では、この一般的な用法を簡潔に説明します。 より多くの例については、RDF 1.2 Primer [RDF12-PRIMER]を参照してください。

例えば、次の図は、トリプル項の具象化トリプルと、 具象化子を 主語として含むトリプルを合わせて表しています。 後者は、具象化されたトリプル項によって示される命題が成り立つという、 :Bobによる主張として具象化子を記述します。言い換えれば、:Bobは :Aliceの姓が"Liddell"であると主張しています。

図 3 具象化子から トリプル項（表明されておらず、 灰色の破線の弧で描かれる）を参照する具象化 トリプルと、この具象化子を記述するトリプルを含む RDFグラフ。

この例では、トリプル項によって示される 命題（すなわち、 :Aliceの姓が"Liddell"であるという命題）は、 真であると主張されていません。 それが真であるとされるのは、トリプル項として使用されたトリプルがRDFグラフ内の 表明済みトリプルでもある場合に限られます。 図のように表明されていないトリプル項を使用することで、 表明されていない文についての文を作ることができます。 例えば、:Aliceの姓が実際に "Liddell"であるか不確かな場合などです。

図 3に示したグラフの変形を以下に示します。これは、 表明済みトリプルが 具象化トリプルのトリプル項目的語に 対応するグラフを表します。 この場合、 これらの例に示されるように、具象化子を主語として含むトリプルの部分集合は、 トリプル注釈と呼ばれます。

図 4 具象化トリプルのトリプル項が 表明済みトリプルに対応する、 トリプル 注釈を含むRDFグラフ。 表明済みトリプルにより、この図は命題を事実として表し、関係が成り立つことを意味します。

Turtle [RDF12-TURTLE]のような具象構文には、 具象化トリプルおよびトリプル注釈を より簡潔に指定するための省略記法がある場合があります。

最後に、トリプル項内に現れる RDF項は、 表明済みトリプル内の グラフに現れる場合と同じ 指示を持ちます。 例えば、トリプル項内の :Aliceという項と、 表明済みトリプル内の :Aliceは、どちらも同じリソースを示します。 このため、トリプル項は 透明であると言います。

注記

すでに述べたように、具象化子は広範なユースケースに対応することを意図しています: ある命題が真であるという文や信念、 その命題が真である状況、 その命題が真になる原因となった出来事などです。 この多様性のため、 rdf:reifiesプロパティの意味は意図的に汎用的です。

同じ抽象命題に関連する複数の別個の具象化子が存在する場合があります。 例えば、異なる出典を持つ文や、 異なる特性を持つ状況などです。1つの具象化子を 複数の別個の命題を具象化するために使用することもあり、 例えば同じ状況が異なる命題に由来し得るという事実を表現します。

具象化された命題は成り立つ必要がないため、 表明されているか否かにかかわらず、別の文と矛盾する 表明されていない文を含め、あらゆる種類の文について 文を作ることが可能です。

1.6 RDFと時間に伴う変化

RDF抽象データモデルは無時間的です。RDFグラフは 情報の静的なスナップショットです。

しかし、RDFグラフは、適切な語彙項が与えられれば、 出来事や他のエンティティの時間的側面に関する情報を 表現できます。

RDF グラフは数学的な集合として定義されるため、 RDFグラフにトリプルを追加または削除すると、 異なるRDFグラフが得られます。

私たちは、非公式にRDFソースという用語を、 永続的でありながら可変である RDF グラフのソースまたはコンテナーを指すために使用します。RDFソースは リソースであり、 時間とともに変化し得る状態を持つと言うことができます。 その状態のスナップショットはRDFグラフとして表現できます。 例えば、RDFを含む表現を持つ任意のWeb文書は RDFソースと見なすことができます。すべてのリソースと同様に、RDFソースは IRIで名前付けでき、したがって 他のRDFグラフで記述できます。

直感的に言えば、議論領域における変化は 次のような方法で反映できます:

1.7 複数のRDF グラフの扱い

RDFグラフはトリプルの集合であるため、 容易に組み合わせることができ、複数のソースからの データの利用を支援します。それでも、時には内容を分離したまま 複数のRDFグラフを扱うことが望ましい場合があります。 RDF データセットはこの要件を支援します。

RDF データセットは、 RDF グラフのコレクションです。これらのグラフのうち1つを除くすべてには、 関連付けられたIRIまたは空白ノードがあります。それらは 名前付き グラフと呼ばれ、そのIRIまたは空白ノードは グラフ名と呼ばれます。 残りのグラフには関連付けられたIRIがなく、RDFデータセットの デフォルトグラフと呼ばれます。

RDFデータセットには多くの可能な用途があります。 その1つは、複数の RDF ソースのスナップショットを保持することです。

1.8 同値性、 含意および不整合

RDF トリプルは、命題 — 2つのエンティティ間の関係を記述する単純な論理式 — を示します。 表明済みトリプルは、対応する命題が 真であるという主張です。 RDF グラフは、その表明済みトリプルによってなされる すべての主張の連言（論理的なAND）です。 RDFトリプルおよびRDFグラフのこの意味の正確な詳細は、 RDF 1.2 Semantics [RDF12-SEMANTICS]の主題であり、そこから RDFグラフ間の次の関係が得られます:

含意
RDFグラフAは、 Aを真にする世界のあらゆる可能な配置がBも真にする場合、 別のRDFグラフBを含意します。Aが Bを含意するとき、Aの真理が仮定または証明されれば、 Bの真理が確立されます。
同値性
2つのRDFグラフAおよびBは、 世界について同じ主張をする場合に同値です。 AがBと同値であるのは、 AがBを含意し、 かつBがAを含意する場合、かつその場合に限ります。
不整合
RDFグラフは、内部矛盾を含む場合に不整合です。 その式を真にする世界の可能な配置は存在しません。

含意レジーム [RDF12-SEMANTICS]は、 これらの関係を成立させる正確な条件を定義する仕様です。 RDF自体は、含意、同値性 および不整合のいくつかの基本的な場合のみを認識します。 RDF 1.2 Schema [RDF12-SCHEMA] やOWL 2 [OWL2-OVERVIEW]などの 他の仕様は、より強力な含意レジームを追加します。 一部のドメイン固有の語彙も同様です。

この仕様は、実装が 含意レジームによって定義される 論理的関係をどのように使用するかを制約しません。 実装は、 不整合を検出する場合もあれば検出しない場合もあり、 含意された情報の すべて、一部、またはまったく提供しない場合があります。

1.9 RDF文書と構文

RDF文書とは、 RDF グラフまたはRDFデータセットを N-Triples [RDF12-N-TRIPLES]、Turtle [RDF12-TURTLE]、RDFa [RDFA-CORE]、JSON-LD [JSON-LD11]、 またはTriG [RDF12-TRIG]などの具象RDF 構文でエンコードする文書です。RDF文書は、RDFグラフおよび RDFデータセットをシステム間で交換できるようにします。

具象RDF構文は、 同じRDFグラフまたは RDF データセットをエンコードする多くの異なる方法を提供する場合があります。 例えば、 名前空間接頭辞、 IRI 参照、空白ノード識別子、 および異なるトリプル順序の使用を通じたものです。これらの側面は RDF文書を扱う利便性に 大きな影響を与えることがありますが、 その意味にとって重要ではありません。

具象RDF構文の基礎は 抽象データモデルの構造であり、 抽象構文と呼ばれます。 これは次の2つの表にまとめられています。

RDFグラフの抽象構文
生成規則 定義
RDF graph 0個以上のトリプルの集合
triple 主語、述語、および目的語の3タプル
subject IRI または空白ノード
predicate IRI
object IRI または空白ノード またはリテラル またはトリプル

RDFデータセットの抽象構文
生成規則 定義
RDF dataset デフォルトグラフと 0個以上の名前付きグラフの集合のペア
default graph RDFグラフ
named graph グラフ名とRDFグラフの ペア
graph name IRI または空白ノード

1.10 RDFバージョン告知

RDFパーサーが未対応のRDFバージョンについてできるだけ早くエラーまたは警告を出せるように、 RDFシリアル化形式には、 メディア型パラメーター、 形式固有の構文におけるバージョン告知、 またはその両方によって、バージョンを指定できることが期待されます。

バージョンがメディア型パラメーターと構文の両方で示される場合、 それらは同じであることが期待されます。 それらが異なる場合、 パーサーはメディア型パラメーターのバージョンを使用し、不一致について警告を発することがあります。

古いパーサーとの互換性をできるだけ広く保持するため、 RDF 1.2固有の機能を使用するRDF文書のみが バージョンを告知することを推奨されます（すなわち、RDF 1.2固有の機能を 使用しないRDF文書については、バージョンを告知することは推奨されません）。

Content-Typeヘッダーを使用してHTTPレスポンスでバージョンを告知するには、 サーバーは、次のレスポンス例に示すように、 versionパラメーターを使用することが期待されます。 

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2
Location: http://example.com/document.ttl

サーバーは、形式がインラインのバージョン告知をサポートする場合 （RDF 1.2 Turtle [RDF12-TURTLE]など）、 インラインでもバージョンを告知することが期待されます。

HTTPサーバーからRDF文書を要求する際、クライアントは 次の要求例に示すように、Accept要求ヘッダーに versionパラメーターを含めることで、 コンテンツネゴシエーション [WEBARCH]中に versionパラメーターを使用できます。 

GET /document.ttl HTTP/1.1
Host: example.com
Accept: text/turtle; version=1.2

2.1 バージョンラベル節は、 versionパラメーターおよび具象RDF 構文で使用されるバージョンラベルを定義します。

注記

HTTPのコンテンツネゴシエーションは助言的であるため、 文書を受け取るクライアントは、要求されたメディア型の文書であっても、 要求されたものとは異なるversionを持つ可能性がある文書を 適切に扱う準備をしておくべきです。 クライアントは、2.1.1 サーバーに関する考慮事項で説明されるように、 自身で適切なバージョンへコンテンツをダウングレードすることを検討できます。

2. 適合性

非規範的と明示された節に加えて、この仕様内のすべての著作ガイドライン、図、例、および注記は非規範的です。 この仕様内のそれ以外のすべては規範的です。

この文書におけるキーワードMAY、MUST、MUST NOT、RECOMMENDED、SHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174]で説明されるように 解釈されるものとします。

この仕様、RDF 1.2 Concepts and Abstract Data Modelは、 他の仕様、例えば 具象RDF構文、 API仕様、およびクエリ言語で使用するための 抽象データモデルと関連語彙を定義します。 実装はRDF 1.2 Concepts and Abstract Data Modelに 直接適合することはできませんが、 ここで定義される用語を規範的に参照するそのような他の仕様には 適合できます。

この仕様は2つの適合レベルを確立します:

2.1 バージョンラベル

バージョンラベルとは、RDFデータの 構文および意味論の適合性を識別する文字列です。

バージョンラベル
バージョンラベル 構文 意味論
"1.2" RDF 1.2構文 RDF 1.2 Semantics
"1.2-basic" トリプル項を含まないRDF 1.2構文 RDF 1.2 Semantics
"1.1" バージョン指令の使用を除くRDF 1.1構文 RDF 1.1 Semantics

バージョン"1.1"に適合するデータは、バージョン"1.2-basic"のデータとして有効であり、 バージョン"1.2-basic"に適合するデータは、バージョン"1.2"のデータとして有効です。 バージョン"1.1"に適合するデータは、 RDF 1.1 Semanticsの下でもRDF 1.2 Semanticsの下でも 同じ意味論を持ちます。

"1.2"を"1.2-basic"としてエンコードする詳細については、 RDF 1.2 Interoperabilityを参照してください。

インラインのバージョン告知をサポートするシリアル化では、 バージョン告知は文書の早い段階で、 そして必ずそのバージョンに依存する機能をシリアル化する前に行うSHOULDです。

2.1.1 サーバーに関する考慮事項

この節は非規範的です。

要求されたバージョンと互換性のない機能を使用するグラフまたはデータセットを シリアル化する場合、サーバーは異なる代替案を検討できます:

  1. RDF 1.2 Interoperabilityで定義される basic encodingなどのアルゴリズムを使用して、 トリプル項を除去する （バージョン"1.2"から"1.2-basic"へのダウングレード）。
  2. 方向付き言語タグ付き文字列を、 [JSON-LD11]で定義されるように i18n名前空間を使用する データ型IRIを持つ リテラルで置換する （バージョン"1.2"または"1.2-basic"から"1.1"へのダウングレード）。
  3. 406 "Not Acceptable"を返す。
  4. 要求されたバージョンを無視し、ネイティブ表現を返す。
注記

ここでの提案は、 堅牢性原則 （Postelの法則としても知られる）に従うことです: サーバーは送信するものについて保守的であり、受け入れるものについて寛容であるべきです。

2.1.2 クライアントに関する考慮事項

この節は非規範的です。

文書に（HTTPヘッダーまたは内部のいずれによっても）versionが明示されていない場合、 システムはバージョンが"1.2"であると仮定できます。 これは以前のすべてのRDFバージョンを引き続きサポートします。

矛盾するバージョンを持つ文書を解析する場合、 または未対応のバージョンを使用する文書を解析する場合、パーサーは 次のいずれかを行うことができます:

  • バージョン指令を無視する。
  • エラーを発生させて中止する。
  • 警告を発し、そのトリプルを無視する。
  • 構造を解析し、宣言されたバージョンと一致するトリプルのみを出力する。

2.2 RDFにおける文字列

RDFは、文字列値の基本表現としてUnicode [Unicode]を使用します。 この仕様および関連仕様内では、RDF文字列、 または単に文字列という用語は、 0個以上の Unicodeコードポイントの順序付きシーケンスを記述するために使用され、 それらはUnicodeスカラー値です。 Unicodeスカラー値には、 サロゲートコードポイントは含まれません。 なお、ほとんどの具象RDF構文は UTF-8文字エンコーディング [RFC3629]の使用を要求し、 特定の非文字値を表現するために\u0000または\U00000000形式を使用します。

ある文字列は、同じコードポイントのシーケンスで構成される場合、 別の文字列と同一です。 実装は、文字列を Unicodeコードポイントシーケンスへデコードせずに、 同じUnicode文字エンコーディング （UTF-8またはUTF-16）を使用する2つの文字列の コード ユニットを比較することで、 文字列の等価性を判定してMAYです。

3. RDFグラフ

RDFグラフは、RDFトリプルの集合です。

RDFトリプルがRDFグラフの要素である場合、そのRDFグラフ内で表明されているとも言います。

3.1 トリプル

RDFトリプル （しばしば単に「トリプル」と呼ばれます）は、 次のように帰納的に定義される3タプルです:

RDFトリプルの 3つの構成要素（s, p, o）は、 それぞれそのトリプルの主語、述語、および目的語と呼ばれます。

注記

トリプルの定義は再帰的です。 つまり、トリプルはそれ自体、 別のトリプルである 目的語 構成要素を持つことができます。 ただし、この定義により、トリプルの循環は作成できません。

RDFグラフのノードの集合は、 そのグラフの表明済みトリプルの 主語および目的語の集合です。 述語のIRIが同じグラフ内のノードとして現れることも可能です。

トリプル 等価性: 2つのトリプル（s, p, o）と（s', p', o'）は、 次の3つの条件がすべて成り立つ場合、かつその場合に限り、 等価（同じRDFトリプル）です。

3.2 RDF項

IRI、リテラル、 空白 ノード、およびトリプル項は、総称して RDF項と呼ばれます。

IRI、リテラル、および空白ノードは、 基本RDF項であると言います。

RDF項の等価性: 2つのRDF項tとt'は、 次の4つの条件のいずれかが成り立つ場合、かつその場合に限り、 等価（同じRDF項）です:

注記

RDFトリプルtに現れるRDF項の集合は、 次のように帰納的に定義されます:

拡張して、あるRDF項は、 RDFグラフの表明済み トリプルに現れる場合、そのRDFグラフに現れると言います。 RDFトリプルは、それがそのグラフの表明済み トリプルであるか、 そのグラフに現れる トリプル項である場合、 RDFグラフに現れると言います。

RDF項は、次の3つの条件のいずれかが成り立つ場合、 グラウンドであると言います:

拡張して、RDFトリプルは、その主語、述語、および目的語 がすべてグラウンドである場合、グラウンドであると言います。 RDFグラフは、そのすべての表明済みトリプルがグラウンドである場合、 グラウンドであると言います。

3.3 IRI

RDFグラフ内のIRI （Internationalized Resource Identifier）は、RFC 3987 [RFC3987]で定義される構文に 適合する文字列です。

RDF抽象構文内のIRIは、 [RFC3986]に従って 解決済みであるMUSTであり、 相対参照であってはMUST NOTです。 IRIは フラグメント識別子を含んでMAYです。 IRIは、 IRI スキームによって定義される規則に従うSHOULDです。

IRI等価性: 2つのIRIは、[RFC3987]の 5.3.1節のSimple String Comparisonと同様に、 同じ Unicodeコードポイントのシーケンスで構成される場合、 かつその場合に限り等価です。 （これは抽象構文で行われるため、IRIはエスケープやエンコードのない 解決済みIRIです。） この比較の前に、さらなる正規化を実行してはMUST NOTです。

注記

便宜上、[ABNF]の完全な文法が、 [RFC3987]から F. IRI文法に示されています。

注記

URIとIRI: IRIは、より広い範囲のUnicode文字 [UNICODE]を許容する URI [RFC3986]の一般化です。 すべてのURIとURLはIRIですが、すべてのIRIがURIであるわけではありません。 RDFでは、[RFC3987] 1.3節で定義されるように、 IRIはIRI参照として使用されます。 IRI参照は、 Internationalized Resource Identifierの一般的な用法です。 IRI参照は、 解決済みIRIまたは 相対IRI参照のいずれかを指し、 F. IRI文法におけるIRI-reference生成規則によって記述されます。 抽象構文では、完全に解決済みのIRIのみを使用します。 IRIがURIに対してのみ定義された操作で使用される場合、 まず[RFC3987]の 3.1節 で定義されるマッピングに従って変換されなければなりません。 注目すべき例はHTTPプロトコルによる取得です。 このマッピングには、非ASCII文字のUTF-8エンコード、 URIで許可されないオクテットの%-エンコード、および ドメイン名のPunycodeエンコードが含まれます。

URL: URL Standardは、[RFC3987]のIRIと おおむね互換性がありますが、Webブラウザー内での実装に重要な処理モデルに基づいており、 [ABNF]文法を使用して 記述されるものではありません。

3.3.1 RDF参照IRI

この節は非規範的です。

この節は、データ公開者への助言を提供します。

IRIは リソースを示すために使用され、各IRIは、 そのIRIがどこで使用されるかに関係なく、 同じリソースを識別すべきです。 [RFC3987]で定義されるIRIの一般構文は、 グローバル参照であるという要件を満たさないIRIを表現できることに注意してください。 一部のURIスキームは追加の要件を加えます。 例えば、 HTTP URIスキームは http-URIを定義し、 これは空でないホスト名の存在を要求し、その結果として パス構成要素は/で始まります。 [RFC3987]構文は、 http:abcdやhttp:///abcdのようなIRIを許容しますが、 これらはHTTP URIスキーム定義を満たさないため無効です。

RDF参照IRI、 ときには単にRDF参照と呼ばれるものは、 グローバル参照としての使用に適したIRIです。

参照解決: RDF参照IRIは、 参照解決によって変化しません。 httpやhttpsなどのURIスキームでは、 パス構成要素は、 解決アルゴリズムに見える階層の一部です。解決されると、 パス構成要素は /文字で始まり、.または..セグメントを含みません。 例えば、https://example/dataは任意の基底IRIに対して解決しても https://example/data（不変）ですが、https://example/path/../dataを 任意の基底IRIに対して解決すると https://example.com/dataになります。

相対IRI参照: 一部の具象RDF構文は、 RDF文書を最終的な公開場所を知らずに作成できる便利な省略記法として、 相対IRI参照 （IRI文法の irelative-ref生成規則を参照）を許可します。 相対IRI参照は、 基底IRIに対して 解決されなければなりません。 したがって、そのような構文でシリアル化されたRDFグラフは、 基底IRIを確立できる [RFC3986]場合にのみ 明確に定義されます。

URIスキーム: 実装は、 HTTP/HTTPSのスキーム規則や DID 構文など、一般的なスキームのスキーム固有規則に従うことが推奨されます。 実装は、認識しないスキームについてはURIスキーム規則を 無視します。

IRI正規化: [RFC3987]の 第5節 に従って正規化されたIRIのみを作成することで、 相互運用性の問題を避けられます。

  • スキーム名には小文字を使用する。
  • IRI構文で必要とされる場合にのみ、文字のパーセントエンコードを使用する。
  • HTTPまたはHTTPSのデフォルトポートを省略する。http://example:80/より http://example/が望ましい。
  • パーセントエンコードの トリプレット内では大文字の16進文字を使用する。 「%3f」より 「%3F」が望ましい。
  • HTTP IRIにおける空のパスは、 パスがないhttp://exampleよりも http://example/が望ましい。
  • IRIのパス 構成要素内の「/./」および「/../」を取り除くようにIRIを正規化する。
  • ドメイン名には小文字を使用する。 なお、ドメイン名内のASCII文字は大文字小文字を区別しませんが、 ドメイン名内の非ASCII文字は大文字小文字を区別します [RFC5890]。 ドメインは一般に小文字でのみ登録されます [RFC5892]。
  • Internationalized Domain Names [RFC5890]について、 IRI内で A-label （ASCII、punycodeエンコード名）を使用することを避ける。
  • Unicode Normalization Form C [I18N-Glossary]のIRIを使用する。

3.4 リテラル

リテラルは、文字列、数値、日付などの値に使用されます。

リテラルは、 次のように、2つ、3つ、または4つの構成要素から成ります:

  1. RDF文字列である 字句形式。
  2. 字句形式がリテラル値へどのように対応付けられるかを決定する データ型を識別するIRIである データ型IRI。
  3. データ型IRIが http://www.w3.org/1999/02/22-rdf-syntax-ns#langStringまたは http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangStringである場合、かつその場合に限り、 [BCP47]で定義される 空でない言語タグがあります。 言語タグは、[BCP47]の 2.2.9節に従って 整形式であるMUSTであり、 それに応じて、すなわち大文字小文字を区別しない方法で扱われるMUSTです。 大文字小文字のみが異なる2つの[BCP47]適合文字列は、同じ 言語タグを表します。
  4. データ型IRIが http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangStringである場合、かつその場合に限り、 次のいずれかであるMUSTの 基底方向があります:
    • ltr。初期テキスト方向が左から右に設定されることを示す
    • rtl。初期テキスト方向が右から左に設定されることを示す

リテラルは、言語タグ が存在し、基底方向が存在しない場合、 言語タグ付き文字列です。 リテラルは、言語タグと基底方向 の両方が存在する場合、 方向付き言語タグ付き文字列です。

リテラル項の等価性: 2つのリテラルは、次のすべてが真である場合、かつその場合に限り、 項として等価（同じRDF項）です:

3.4.1 リテラルの表現

一部の具象構文は、 データ型IRI、言語タグ、または基底方向を持たず、 字句形式のみから成る 単純リテラルをサポートします。 単純リテラルは、一般にxsd:stringと省略される データ型IRI http://www.w3.org/2001/XMLSchema#stringを持つ 抽象構文の リテラルのための構文糖衣です。

同様に、ほとんどの具象構文は、 言語タグ付き文字列および方向付き言語タグ付き文字列を、 データ型IRIなしで表します。 なぜなら、それは常にそれぞれ http://www.w3.org/1999/02/22-rdf-syntax-ns#langString（rdf:langString） またはhttp://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString （rdf:dirLangString）だからです。

[BCP47]に適合する任意の 文字列は、 具象構文または実装において言語タグを表すために使用してMAYです。 そのような文字列は、大文字小文字を正規化してMAYです （例えば、 BCP 47 4.5節で定義されるように正準化することによって）。 あるいは、実装は、大文字小文字を区別しない方法で処理することを条件として、 元の表現から大文字小文字を保持してMAYです。

注記

3.4.2 リテラル値

リテラルに関連付けられる リテラル値は、 次のように定義されます。

  • リテラルが言語タグ付き文字列である場合、 リテラル値は、その字句形式 とその言語タグから成るペアであり、その順序もこの通りです。
  • リテラルが方向付き言語タグ付き文字列である場合、リテラル 値は、その字句形式、その言語タグ、 およびその基底方向のタプルであり、 同様にその順序です。
  • リテラルのデータ型がRDF実装によって処理される場合、次のいずれかが適用されます:
    • リテラルの字句形式がその データ型の字句空間内にある場合、リテラル値は、 そのデータ型の 字句から値への写像を 字句形式に適用した結果です。
    • そうでない場合、リテラルは不正型付きであり、リテラル値を そのリテラルに関連付けることはできません。このような場合は意味論的な 不整合を生じさせますが、 構文的に不正形式であるわけではありません。 実装は、不正型付きリテラルを受け入れて、それらからRDF グラフを生成するSHOULDです。実装は 不正型付きリテラルに遭遇したときに 警告を生成してMAYです。
  • リテラルのデータ型IRIがRDF実装によって 処理されない場合、リテラル値は この仕様では定義されません。実装は、 未知のデータ型IRIを持つリテラルを受け入れて、それらからRDFグラフを生成するSHOULDです。

上記から、2つのリテラルが同じ値を持ちながら、 同じRDF項ではない場合があることが分かります。 例えば:

"1"^^xsd:integer
"01"^^xsd:integer

これらは同じ値を示しますが、 字句形式が異なるため、 同じリテラルRDF項ではありません。

3.4.3 初期テキスト方向

この節は非規範的です。

方向付き 言語タグ付き文字列の基底方向は、 右から左および左から右の文字体系が混在するテキストを含め、 テキストの初期方向を確立する手段を提供します。 Unicode双方向アルゴリズム [I18N-Glossary]は、 文字列を論理順序で自動的にレンダリングし、 期待される視覚順序で表示するためのサポートを提供しますが、 これは双方向テキストを正しくレンダリングするには常に十分であるとは限りません。

書籍タイトル"HTML and CSS: Designing Websites"のアラビア語訳を考えてください。 左から右の文脈（英語のWebページなど）で、 適切なbidi分離はあるが、明示的な 基底方向がない場合、 次のように誤って表示されます:

HTML و CSS: تصميم مواقع الويب

一方、正しいレンダリングは次の通りです:

HTML و CSS: تصميم مواقع الويب

この例は、双方向テキストに遭遇する可能性がある文脈では、 単純な言語タグ付き文字列 ではなく、方向付き 言語タグ付き文字列を使用することの重要性を示しています。

言語および基底方向は、 文字列を文脈内で正しく表示することに関連する 文字列外部の双方向問題（例えば、波及 問題の回避）に対処することに注意してください。 これは、次のようなより複雑な例で生じる可能性がある、 文字列内部の方向問題には対処しません:

"HTML و CSS: تصميم مواقع الويب" is the Arabic title of the book.

その例を表す方向付き言語タグ付き文字列は、 言語タグenと基底方向 ltrを持ちますが、 引用符の間のテキストをrtlとして分離し標示するために、 特定のUnicode双方向書式制御文字も必要とします。

注記
他のデータ型は、言語および双方向テキストをエンコードする独自の方法を提供します。 例えば、rdf:HTMLやrdf:XMLLiteralです。

3.5 空白ノード

空白ノードは、 IRIおよびリテラルと互いに素です。それ以外については、 可能な空白ノードの集合は任意です。RDFは 空白ノードのいかなる内部構造にも言及しません。

空白ノード 等価性: 2つの空白ノードは、それらが同じ空白ノードである場合、かつその場合に限り等価です。

注記

空白ノード識別子は、 一部の具象RDF構文 またはRDFストア実装で使用されるローカル識別子です。 それらは常にファイルまたはRDFストアにローカルにスコープされ、 空白ノードのための永続的または移植可能な識別子ではありません。 空白ノード識別子はRDF抽象データモデルの一部ではなく、 具象構文または実装に完全に依存します。 したがって、空白ノード識別子に対する構文上の制約がある場合も、 具象RDF構文または実装に依存します。具象構文で空白ノード 識別子を扱う実装は、構文でサポートされる状況を除き、 同じ空白ノード識別子の複数の出現から 同じ空白ノードを作成しないよう注意する必要があります。

「blank node label」という用語は、 空白ノード識別子という用語の代替として 非公式に使用されることがあります。 この代替語は、[SPARQL11-QUERY]など、 いくつかのRDF関連仕様の以前のバージョンでも使用されていました。 一貫性のため、この代替用語の使用は現在推奨されません。

3.6 トリプル項

別のトリプルの目的語として使用される RDFトリプルは、 トリプル項と呼ばれます。 与えられたRDFグラフ内で、トリプルは トリプル項、表明済み トリプル、またはその両方として現れることができます。

トリプル項の等価性: トリプル項はトリプルであるため、トリプル項の等価性は トリプル等価性と同じです。

3.7 グラフ比較

この節では、RDFグラフについて、 RDF項間の写像に基づく グラフ同型の概念を導入します。 この写像は空白ノードを空白ノードへ写し、 IRIおよびリテラルについては恒等関数です。

すべてのRDF項の集合から同じ集合への関数Mは、 次のすべての性質を持つ場合、 同型RDF項写像と呼ばれます:

2つのRDFグラフGとG'は、 次の条件を満たす同型RDF項写像 Mが存在する場合、 同型 （すなわち、同じ形を持つ）です: トリプル(s, p, o)がGに含まれることと、 トリプル( M(s), M(p), M(o) )が G'に含まれることが同値である。

この定義により、MはG内の各空白ノードを 新しい空白ノードに置き換えてG'を得る方法を示します。 グラフ同型は、RDF Test Cases [RDF11-TESTCASES] 仕様をサポートするために必要です。

4. RDFデータセット

RDFデータセットは、 RDF グラフのコレクションであり、次のものから構成されます:

空白 ノードは、RDF データセット内の複数のグラフ間で共有できます。

注記

「名前付きグラフ」で 「名前」という語が使われているにもかかわらず、 グラフ名は、そのグラフを示す必要はありません。 それは単に構文上グラフと対にされているだけです。RDFは、 グラフ名がどのリソースを示し得るか、 またそのリソースとグラフとの関係について、 いかなる形式的な制限も課しません。 さまざまなRDFデータセット意味論に関する議論は、 [RDF11-DATASETS]にあります。

一部のRDFデータセット実装は、 空の名前付きグラフを追跡しません。 アプリケーションは、空の名前付きグラフの有無に 重要性を付与しないことで、相互運用性の問題を避けられます。

SPARQLバージョン1.2 [SPARQL12-CONCEPTS]は、 RDFバージョン1.1および1.2と同じ RDFデータセットの概念 を使用します。 そこでは、名前付きグラフのグラフ名はIRIまたは空白ノードであってよいものです。 これに対して、SPARQL Query Languageのバージョン1.1 [SPARQL11-QUERY]では、 グラフ名にIRIのみを許可していました。

4.1 RDFデータセット比較

2つのRDFデータセットD1とD2 （それぞれデフォルトグラフDG1およびDG2と、 名前付きグラフの集合 NG1およびNG2を持つ）は、 次のすべての性質を満たす同型RDF項写像 Mが存在する場合、かつその場合に限り、 データセット同型です:

4.2 RDFデータセットの コンテンツネゴシエーション

この節は非規範的です。

Webリソースは、 コンテンツネゴシエーション [WEBARCH]を通じて利用可能にされる 複数の表現を持つことがあります。表現は、 RDFデータセットと RDF グラフの両方の表現をサポートするRDFシリアル化 形式で返される場合があります。RDFデータセットが 返され、利用者がRDFグラフを期待している場合、 利用者はRDFデータセットの デフォルトグラフを使用することが期待されます。

4.3 クワッドの集合としてのデータセット

この節は非規範的です。

クワッドとは、任意のグラフ 名に関連付けられたトリプルであり、 RDFデータセット内のトリプルを参照するときに 使用されます。

クワッドは、 主語、述語、目的語、 および任意のグラフ名で構成されるタプルとして表現できます。

RDFデータセットは、 クワッドの 集合であると考えることができます。 グラフ名を持たないクワッドはデフォルトグラフのトリプルを提供し、 同じグラフ名を持つクワッドは、 その名前を持つ名前付きグラフのトリプルを提供します。

注記

グラフ名を持たないクワッドは、 トリプルと同じ3つの構成要素から成りますが、 それは別個の概念です。 なぜなら、それはRDFデータセットのデフォルトグラフ 内のトリプルという概念を特に捉えるものだからです。

5. データ型

データ型は、文字列、数値、日付などの値を表すために、RDFリテラルとともに使用されます。 RDFで使用されるデータ型抽象化は、XML Schema [XMLSCHEMA11-2]と互換性があります。 この抽象化に適合する任意のデータ型定義は、 XML Schemaの観点で定義されていなくても、RDFで使用してMAYです。 RDFはXML Schemaの多くの組み込みデータ型を再利用し、 さらに3つの追加データ型、 rdf:JSON、 rdf:HTML、 および rdf:XMLLiteral を定義します。

データ型は、字句空間、 値 空間、および字句から値への写像から成り、 1つ以上のIRIによって識別されます。

データ型の字句空間は、文字列の集合です。

データ型の字句から値への写像は、 その第1要素が字句空間に属し、 第2要素がそのデータ型の値空間に属する ペアの集合です。字句空間の各メンバーは正確に1つの値と対にされ、 その値の字句表現です。この写像は、 字句空間から値空間への関数と見ることができます。

注記

言語タグ付き文字列は、データ型IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#langString （一般にrdf:langStringと省略されます）を持ちます。 このIRIについて形式的に定義されたデータ型はありません。 なぜなら、データ型の定義は、 字句空間内の 言語タグを扱えないからです。 このデータ型IRIに関連付けられる 値空間は、文字列と言語タグから成る すべてのペアの集合です。 同様に、方向付き言語タグ付き文字列 http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString （一般にrdf:dirLangStringと省略されます）も、 値空間に基底方向を持ちます。 このデータ型IRIに関連付けられる 値空間は、 文字列、言語タグ、基底方向から成るすべての3タプルの集合です。

例えば、XML Schemaデータ型xsd:booleanは、 値空間の各メンバーが2つの字句表現を持つものであり、 次のように定義されます:

字句空間:
{"true", "false", "1", "0"}
値空間:
{true, false}
字句から値への写像
{ <"true", true>, <"false", false>, <"1", true>, <"0", false>, }

このデータ型を使用して定義できるリテラルは 次の通りです:

この表はxsd:boolean型のリテラルを列挙します。
リテラル 値
<"true", xsd:boolean> true
<"false", xsd:boolean> false
<"1", xsd:boolean> true
<"0", xsd:boolean> false

5.1 XML Schema組み込み データ型

http://www.w3.org/2001/XMLSchema#xxxという形式のIRIは、 ここでxxxがデータ型の名前である場合、 W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]で 定義される組み込みデータ型を示します。 次の表に列挙されるXML Schema組み込み型は、 RDF互換XSD型です。それらの使用はRECOMMENDEDです。

読者は、バイナリ情報の転送に安全な唯一のデータ型が xsd:hexBinaryおよびxsd:base64Binaryであることに注意するとよいでしょう。

RDF互換XSD型の一覧と簡単な説明
データ型 値空間（参考情報）
中核型 xsd:string 文字列
xsd:boolean true, false
xsd:decimal 任意精度の十進数
xsd:integer 任意サイズの整数
IEEE浮動小数点
数		 xsd:double ±Inf、±0、NaNを含む64ビット浮動小数点数
xsd:float ±Inf、±0、NaNを含む32ビット浮動小数点数
時刻と日付 xsd:date タイムゾーンの有無を問わない日付（yyyy-mm-dd）
xsd:time タイムゾーンの有無を問わない時刻（hh:mm:ss.sss…）
xsd:dateTime タイムゾーンの有無を問わない日付と時刻
xsd:dateTimeStamp タイムゾーンを必須とする日付と時刻
反復および
部分日付		 xsd:gYear グレゴリオ暦の年
xsd:gMonth グレゴリオ暦の月
xsd:gDay グレゴリオ暦の月内の日
xsd:gYearMonth グレゴリオ暦の年と月
xsd:gMonthDay グレゴリオ暦の月と日
期間 xsd:duration 時間の期間
xsd:yearMonthDuration 時間の期間（月と年のみ）
xsd:dayTimeDuration 時間の期間（日、時、分、秒のみ）
範囲制限付き
整数		 xsd:byte -128…+127（8ビット）
xsd:short -32768…+32767（16ビット）
xsd:int -2147483648…+2147483647（32ビット）
xsd:long -9223372036854775808…+9223372036854775807（64ビット）
xsd:unsignedByte 0…255（8ビット）
xsd:unsignedShort 0…65535（16ビット）
xsd:unsignedInt 0…4294967295（32ビット）
xsd:unsignedLong 0…18446744073709551615（64ビット）
xsd:positiveInteger 0より大きい整数
xsd:nonNegativeInteger 0以上の整数
xsd:negativeInteger 0より小さい整数
xsd:nonPositiveInteger 0以下の整数
エンコード済みバイナリデータ xsd:hexBinary 16進エンコードされたバイナリデータ
xsd:base64Binary Base64エンコードされたバイナリデータ
その他の
XSD型		 xsd:anyURI 解決済みまたは相対のURIおよびIRI参照
xsd:language [BCP47]に従う言語タグ
xsd:normalizedString 空白が正規化された文字列
xsd:token トークン化された文字列
xsd:NMTOKEN XML NMTOKEN
xsd:Name XML名
xsd:NCName XML NCName

xsd:float およびxsd:doubleの 字句から値への写像は、 doubleLexicalMapと整合する方法を使用するMUSTであり、 これはfloatPtRound [XMLSCHEMA11-2]で 説明される丸め方法に厳密に適合するMUSTです。

その他の組み込みXML Schemaデータ型は、 さまざまな理由により不適切であり、使用すべきではSHOULD NOTです:

注記

xsd:doubleおよび xsd:floatの 値空間には、 すべての十進数が含まれるわけではありません。 これら2つのデータ型のいずれかの任意のリテラルについて、 そのリテラルの値は、対応する精度の IEEE 754-2008 バイナリ浮動小数点表現として表せる値です。 例えば、字句形式"0.1"とデータ型xsd:floatを持つリテラルは、 数値0.100000001490116119384765625を示します。 xsd:double またはxsd:floatではなく、 データ型xsd:decimalを使用して、 任意の十進数を正確に捉えることができます。

5.2 データ型IRI

データ型はIRIによって識別されます。

http://www.w3.org/2001/XMLSchema#xxxという形式の任意のIRIが RDF実装によって処理される場合、 5.1節に列挙されるすべてのXSD型について、 それはxsd:xxxという名前のRDF互換XSD型を参照するMUSTです。

以下の3つのIRIによって識別されるデータ型は、 付録 A. 追加データ型で定義されます:

RDF実装は、すべてのデータ型を処理する必要はありません。 RDF実装によって処理されないデータ型で型付けされた任意のリテラルは、 未知のIRIと同じように扱われます。 すなわち、未知のものを参照しているものとして扱われます。 アプリケーションは、型付きリテラルで使用されるIRIの 指示対象を決定できない場合、警告メッセージを出してMAYです。 RDF実装は、未知のデータ型を持つリテラルを構文的または 意味論的なエラーとして拒否すべきではSHOULD NOTです。

他の仕様は、 データ型IRIに追加の制約を課してMAYです。 例えば、特定のデータ型のサポートを要求する場合があります。

注記

RDFの意味論的拡張は、 他のデータ型IRIを認識することを選択し、 それらの各々が固定されたデータ型を参照することを要求する場合があります。 意味論的拡張に関する詳細については、 RDF 1.2 Semantics [RDF12-SEMANTICS]を参照してください。

注記

Web Ontology Language [OWL2-OVERVIEW] は、RDFで使用できる カスタム データ型を形式的に定義するための機能を提供します。さらに、 ユーザー定義の単純XML Schemaデータ型 を識別するための慣行が、[SWBP-XSCH-DATATYPES]で提案されています。 RDF実装は、これらの機能のいずれもサポートする必要はありません。

注記

RDF 1.1では、認識済みデータ型IRIが RDF Conceptsで定義されており、 RDF Semanticsのデータ型IRIの「認識」 と、意味論的拡張について重なりがありました。

6. フラグメント識別子

この節は非規範的です。

RDFは、リソース識別子として、 フラグメント 識別子を含み得る IRIを使用します。 フラグメント識別子の意味論は、 RFC 3986で 定義されています [RFC3986]: それらは、 通常、一次リソースの一部、ビュー、そこで定義されるもの、またはそこで記述されるもの である二次リソースを識別し、正確な意味論は、一次リソースに対する 取得操作から得られ得る表現の集合に依存します。

この節では、RDFグラフをエンコードする表現における フラグメント識別子の扱いについて説明します。

一次リソースのRDFを含む表現、例えば <https://example.com/foo>において、 フラグメント識別子、例えばbarによって識別される二次リソースは、 RDFグラフ内の完全な IRIによって 示される リソースであり、この場合は <https://example.com/foo#bar>です。 RDFグラフ内のIRIは何でも示すことができるため、これは 表現の外部にあるもの、さらにはWebの外部にあるものである場合もあります。

このように、RDFを含む表現は、Webアクセス可能な一次リソースと、 RDFグラフが記述し得る、 Web上にない可能性のある、または抽象的なエンティティの集合との間の 仲介役として機能します。

他の仕様が、RDFを含む表現における フラグメント識別子の意味論に制約を課す場合、 エンコードされた RDF グラフは、これらの制約と整合する方法でフラグメント識別子を使用すべきです。 例えば、HTML+RDFa文書 [HTML-RDFA]では、 chapter1のようなフラグメント識別子は、HTMLの@nameまたは@id 属性の意味論を通じて文書の節を識別する場合があります。そのような IRI、例えば <#chapter1>は、同じ文書内のRDFaでエンコードされた トリプルにおいて、その同じ節を 示すものと 解釈されるべきです。 同様に、フラグメント識別子は、 コンテンツ ネゴシエーション [WEBARCH]を通じて利用可能にされる 複数の表現を持つリソースにおいても、一貫して使用されるべきです。例えば、 フラグメント識別子chapter1が一次リソースのHTML表現において 文書の節を識別する場合、 IRI <#chapter1>は、 同じ一次リソースのすべてのRDFを含む表現において、その同じ節を 示すものと 解釈されるべきです。

7. RDFトリプル、 グラフ、およびデータセットの一般化

この節は非規範的です。

RDF トリプルに対する要件を緩めることが便利な場合があります。例えば、 RDFS含意規則の完全性は、 対称RDFトリプルの概念を用いる方が示しやすくなります。

7.1 対称RDF

対称RDFトリプルは、主語として、 目的語位置で許可される任意のRDF 項を許可します。すなわち、 IRI、 空白ノード、 リテラル、 またはトリプル項 （それ自体が対称RDFトリプルである場合があります）のいずれかです。 対称RDFグラフは、対称RDFトリプルの集合です。 対称RDFデータセットは、 区別された対称RDFグラフと、0個以上のペアから構成され、 各ペアはIRIまたは空白 ノードを対称RDFグラフに関連付けます。

対称RDFトリプル、グラフ、およびデータセットは、 主語および目的語位置に IRI、 空白 ノード、 リテラル、 およびトリプル項を 許可することだけが、標準の規範的なRDFトリプル、 グラフ、および データセット と異なります。

7.2 一般化RDF

一般化RDFトリプルは、主語、述語、および目的語を持つトリプルであり、 それぞれがIRI、 空白ノード、 リテラル、 またはトリプル項 （それ自体が一般化RDFトリプルである場合があります）であり得ます。 一般化RDFグラフ は、一般化RDFトリプルの集合です。 一般化RDFデータセットは、 区別された一般化RDFグラフと、0個以上のペアから構成され、 各ペアはIRI、 空白ノード、 リテラル、 またはトリプル項 （それ自体が一般化RDFトリプルである場合があります）を、 一般化RDFグラフに関連付けます。

一般化RDFトリプル、グラフ、およびデータセットは、 任意の位置、すなわち主語、述語、目的語、またはグラフ名として、 IRI、 空白 ノード、 リテラル、および トリプル項が現れることを 許可することだけが、標準の規範的なRDFトリプル、 グラフ、および データセットと異なります。

注記

対称または一般化RDFトリプル、グラフ、またはデータセットの利用者は、 これらの概念がRDFの非標準的な拡張であり、 その使用が相互運用性の問題を引き起こす可能性があることを 認識しておく必要があります。 いかなるRDFツールにも、標準の規範的なRDFトリプル、グラフ、およびデータセットを超えるものを 受け入れ、処理し、または生成する要件はありません。

A. 追加データ型

この節では、RDF実装がサポートしてMAYである追加の データ型を定義します。

A.1 rdf:HTMLデータ型

RDFは、HTMLコンテンツを可能なリテラル値として扱えるようにします。 これにより、リテラル値内にマークアップを含めることができます。そのようなコンテンツは、 RDFグラフ内で、リテラルを使用して示されます。そのデータ型は rdf:HTML に設定されます。

rdf:HTMLデータ型は次のように定義されます:

このデータ型を示すIRI
はhttp://www.w3.org/1999/02/22-rdf-syntax-ns#HTMLです。
値空間
は、DOM DocumentFragment ノード [DOM]の集合です。2つの DocumentFragment ノードnodeとotherNodeは、 DOMメソッド node.isEqualNode(otherNode) [DOM]がtrueを返す場合、かつその場合に限り 等価と見なされます。
字句から値への写像

字句空間の各メンバーは、次のアルゴリズムを適用した結果に関連付けられます:

注記

HTMLコンテンツ内で望まれる任意の言語注釈（lang="…"）、 テキスト方向性注釈（dir="…"）、または XML名前空間（xmlns）は、 HTMLリテラル内に明示的に含めなければなりません。 hrefなどの属性内の相対URLには明確に定義された 基底URLがないため、避けるのが最善です。 RDFアプリケーションは、同じ文字列の単一テキストノードに対応する rdf:HTMLリテラルとxsd:stringを関連付けるものなど、 追加の等価関係を使用してもよいです。

A.2 rdf:XMLLiteral データ型

RDFは、XMLコンテンツを可能なリテラル値として扱えるようにします。 そのようなコンテンツは、RDFグラフ内で、 データ型が rdf:XMLLiteral に設定されたリテラルを使用して示されます。

rdf:XMLLiteralデータ型は次のように定義されます:

この データ型を示すIRI
はhttp://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteralです。
字句空間
は、整形式に対応し、自己完結した XMLコンテンツ [XML11]である すべての文字列の集合です。 また、任意のXML開始タグと終了タグの間に埋め込むと、 Namespaces in XML 1.0 (Third Edition) [XML-NAMES]に適合する文書が 得られるものです。
値空間
は、DOM DocumentFragment ノード [DOM]の集合です。2つの DocumentFragment ノードnodeとotherNodeは、DOMメソッド node.isEqualNode(otherNode) がtrueを返す場合、かつその場合に限り等価と見なされます。
字句から値への写像

字句空間の各メンバーは、次のアルゴリズムを適用した結果に関連付けられます:

注記

XMLコンテンツ内で望まれる任意のXML名前空間宣言（xmlns）、 言語注釈（xml:lang）、または基底URI宣言 （xml:base）は、XMLリテラル内に明示的に含めなければなりません。 なお、一部の具象RDF構文は、それらをコンテキストから継承するための仕組みを 定義する場合があります（例えば、RDF/XML [RDF12-XML]における @parseType="literal"）。

A.3 rdf:JSONデータ型

RDFは、JSONコンテンツを可能なリテラル値として扱えるようにします。 これには、リテラル値内にマークアップを許可することが含まれます。そのようなコンテンツは、 RDF グラフ内で、データ型が rdf:JSON に設定されたリテラルとして示されます。

rdf:JSONデータ型は次のように定義されます:

このデータ型を示すIRI
はhttp://www.w3.org/1999/02/22-rdf-syntax-ns#JSONです。
字句空間
は、[RFC8259]の 第2節 JSON Grammarで説明される JSON Grammarに適合し、 さらにThe I-JSON Message Format [RFC7493]の要件にも適合する すべてのRDF文字列の集合です。
注記
The JavaScript Object Notation (JSON) Data Interchange Format [RFC8259] は、RDF文字列で許可されない サロゲートコードポイントを 文字列に含めることを許可しますが、 これは[RFC7493]でも 除外されています。したがって、JSONリテラルの字句表現は、 サロゲートコードポイントを含むものを除外します。
値空間
は、 文字列、 数値（xsd:double）、 文字列を値 空間内の値に写像する有限非順序マップ、 リスト （値空間内の値のリスト）、および Infra Standard [INFRA]およびW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XMLSCHEMA11-2]の リテラル値（true, false、およびnull） を含む最小の集合です。
注記

有限非順序マップおよびリストの 値空間には、自分自身をメンバーとして持つ値は含まれません。 そのような値はJSONで表現できません。

2つの値は、それらが値空間の同じ要素である場合、かつその場合に限り等価と見なされます。

字句から値への写像
は、字句空間のすべての要素を、それを 文字列、 数値（xsd:double）、 有限非順序マップ、 リスト、または リテラル値（true, false、およびnull）へ解析した結果に写像します。
  • JSON Objectは、各オブジェクトメンバーを、 メンバー名から取得されたキーと、 メンバー値にこの写像を実行して取得された 値を持つ マップエントリーに変換することによって、 有限非順序マップに写像されます。
  • JSON Arrayは、 そのJSON Arrayと同じ数の 要素を含むリストである リストに 写像されます。また、 配列内の各位置iについて、 リスト内の i番目の位置にある要素は、 配列のi番目の要素に この写像を適用した結果の値です。
  • JSON Numberは、 doubleLexicalMapと整合する方法を使用して、 xsd:doubleに写像されます。 これは、floatPtRound [XMLSCHEMA11-2]で 説明される丸め方法に厳密に適合するMUSTです。
    注記
    一部の数値は、有限のxsd:double値として 表現できず、+INFまたは-INFに写像される場合があります。 そのような値はJSON Numberとして表現できず、そのような値をJSONへ戻してシリアル化する能力を制限します。
  • JSON Stringは、任意のエスケープシーケンスを 対応する Unicodeコードポイントに変換した後、 文字列に写像されます。
  • JSONリテラル名は、 JSONのtrue、false、およびnull値を、 それぞれ[INFRA]の true、 false、および null値に写像します。
注記

有限非順序マップは、キーと値のペアをキーによって（Unicodeコードポイント順を使用して） 体系的にソートすることで、順序付き マップ [INFRA]を用いて実装できます。 これにより、オブジェクトメンバーの順序のみが異なる字句形式（例えば、 {"a": "b", "c": "d"}と{"c": "d", "a": "b"}）が同じ値に写像されることが 保証されます。

B. 空白ノードのIRIによる置換

空白ノードはRDF抽象データモデルにおいて識別子を持ちません。 一部の具象構文によって導入される 空白ノード識別子は、 ローカルスコープのみを持ち、シリアル化の成果物にすぎません。

より強い識別が必要な状況では、システムはRDFグラフ内の一部またはすべての空白ノードを IRIで 体系的に置換してMAYです。 これを行おうとするシステムは、そのように置換される各空白ノードに対して、 新しいグローバルに一意なIRI （Skolem IRI）を作成するSHOULDです。

この変換は、元のグラフを含意する新しいグラフを生成します （Skolemizationも参照）。 この文脈では、Skolem IRIと空白ノードは性質が異なることに注意することが重要です: IRIはリソースを直接示す一方で、空白ノードはリソースの存在のみを示します。 Skolem IRIを生成することにより、この存在の具体的な証人を作成します。 Skolem IRIはローカルではないため、他のグラフが後でそれらを使用できるようになりますが、 これは空白ノードでは不可能です。

システムは、Skolem IRIが空白ノードの置換のみを目的として導入されたものとして 認識できるように、それらを作成したい場合があります。 一部の文脈では、これにより必要に応じてシステムがSkolem IRIを空白ノードへ 戻して写像できます。

Skolem IRIをシステム境界の外部で認識可能にしたいシステムは、 登録名genidを持つwell-known IRI [RFC8615]を使用する SHOULDです。これは、HTTPまたはHTTPSスキーム、 またはwell-known IRIを使用するよう指定された別のスキームを使用し、 パス構成要素が/.well-known/genid/で始まるIRIです。

例えば、ドメインexample.comに責任を持つ権威は、 次の認識可能なSkolem IRIを作成できます: 

http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6
注記

RFC 8615 [RFC8615]は well-known URIのみを規定しており、 IRIは規定していません。この文書の目的において、well-known IRIとは、IRIからURIへの写像 [RFC3987]後にwell-known URIとなる任意の IRIです。

C. プライバシーに関する考慮事項

この節は非規範的です。

RDFは任意のアプリケーションデータを表現するために使用され、 これには個人識別情報（PII）や、機微であると見なされ得るその他の情報の表現が 含まれる場合があります。 そのような情報を公開する著者は、そのような情報を公開する必要性と用途、 ならびにデータが消費され、潜在的に開示されることが想定される地域に適用される規制 （例えば、 GDPR、 CCPA、 その他）を 慎重に検討すること、特にデータへのアクセスに認可措置が必要かどうかを検討することが推奨されます。

D. セキュリティに関する考慮事項

この節は非規範的です。

RDF抽象データモデルは、情報を伝達するために直接使用されるものではありません。 具象シリアル化形式は、特にその目的のために意図されています。

アプリケーションは、与えられたデータを評価して、さらなる表明を推論したり、 IRIを逆参照したりできます。 これにより、そのIRIのスキームに関するセキュリティ上の 考慮事項が呼び出されます。 特にHTTP IRIについては、[RFC3023]第10節の プライバシー問題に注意してください。 不正確または悪意のあるデータソースから得られたデータは、不正確または誤解を招く結論、 ならびに意図しないIRIの逆参照につながる可能性があります。 参照されるリソースへの信頼を、データの意図された使用の機微性に合わせるよう注意しなければなりません。 潜在的な医療処置に関する推論には、旅行計画のための推論とは異なる信頼が 必要になる可能性が高いでしょう。

RDFは任意のアプリケーションデータを表現するために使用されます。 セキュリティ上の考慮事項は使用領域によって異なります。 テキストに適用可能なセキュリティツールおよびプロトコル （例えば、PGP暗号化、チェックサム検証、パスワード保護付き圧縮）は、 RDF文書にも使用できます。 埋め込まれた情報の機微性を反映するセキュリティ/プライバシープロトコルを課すべきです。

RDFは、RDF Schemaラベルなど、ユーザーに提示されるデータを表現できます。 信頼されていないRDF文書から取得した文字列をレンダリングする、 またはエスケープされていない文字を使用するアプリケーションは、 悪意のある文字列が読者を誤解させるために使用される可能性を制限するため、 警告その他の適切な手段を使用すべきです。 XMLのメディア型登録におけるセキュリティ上の考慮事項 （[RFC3023]第10節）は、 任意のデータおよびマークアップの表現に関する追加の指針を提供します。

RDFは用語識別子としてIRIを使用します。 RDFで表現されたデータを解釈するアプリケーションは、 Internationalized Resource Identifiers (IRIs) [RFC3987] 第8節、および Uniform Resource Identifier (URI): Generic Syntax [RFC3986] 第7節のセキュリティ問題に対処すべきです。

複数のIRIが 同じ外観を持つ場合があります。 異なる文字体系の文字は似て見える場合があります（例えば、 キリル文字の「о」はラテン文字の「o」に似て見える場合があります）。 文字に結合文字が続くものが、別の文字と同じ視覚表現を持つ場合があります （例えば、LATIN SMALL LETTER "E"にCOMBINING ACUTE ACCENTが続くものは、LATIN SMALL LETTER "E" WITH ACUTEと同じ視覚表現を持ちます）。 RDFでデータを書いたり解釈したりする人またはアプリケーションは、 意図された意味論に一致するIRIを使用し、 類似して見えるIRIを避けるよう注意しなければなりません。 視覚的に類似する文字の照合に関する詳細情報は、 Unicode Security Considerations [UNICODE-SECURITY]および Internationalized Resource Identifiers (IRIs) [RFC3987] 第8節にあります。

グラフの比較、 またはそれらを用いた推論は、 しばしば（部分）グラフ同型の計算に依存し、 これは最悪の場合に計算量が複雑であることが知られています。 グラフへのクエリも、計算量の複雑な操作を 含む場合があります。 これは、悪意のあるグラフを構築してRDF実装を停止させたり、 メモリ不足に陥らせたりできることを意味します。 信頼されていないソースからのグラフを処理する実装は、緩和策を提供することが期待されます。 例は、[RDF-CANON]の Dataset Poisoningに関する節に示されています。

注記

これらの考慮事項は、[RDF12-TURTLE]、[RDF12-TRIG]、 [RDF12-N-TRIPLES]、 および[RDF12-N-QUADS]に対するセキュリティ上の考慮事項の より一般的な形です。

E. 国際化に関する 考慮事項

この節は非規範的です。

Unicode [UNICODE]は、文字列内の方向を示すための仕組みを提供します （Unicode Bidirectional Algorithm [I18N-Glossary]を参照）。 RDFは、文字列の初期テキスト方向を示すために、 方向付き言語タグ付き文字列の 基底方向を指定する仕組みを提供します。 ほとんどの人間言語の文字列、特に文字列内容から基底方向を正確に判定できないものについては、 値の適切な表示と分離を得るために外部の指標を持つことが有用です。 そのような指標の一例は、 [HTML]の dir属性です。 [STRING-META]を参照してください。

JSON-LD 1.1 [JSON-LD11]は、 i18n 名前空間を導入し、データ型を使用して RDF リテラルの基底方向と 言語タグの両方を指定しました。

F. IRI文法

この節は非規範的です。

次の[ABNF]文法は、 [RFC3987]および[RFC6874]からの 変更を、 [RFC3986]の URIの収集ABNFの節に適用し、 IRIの統合文法を与えるものです。

これは便宜のためにのみ提供されます。 これが[RFC3986]、 [RFC3987]、 またはその後の更新における定義と異なる場合、 それらの定義が使用されるべきです。 

IRI            = scheme ":" ihier-part [ "?" iquery ] [ "#" ifragment ]

ihier-part     = "//" iauthority ipath-abempty
               / ipath-absolute
               / ipath-rootless
               / ipath-empty

IRI-reference  = IRI / irelative-ref

absolute-IRI   = scheme ":" ihier-part [ "?" iquery ]

irelative-ref  = irelative-part [ "?" iquery ] [ "#" ifragment ]

irelative-part = "//" iauthority ipath-abempty
               / ipath-absolute
               / ipath-noscheme
               / ipath-empty

scheme         = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

iauthority     = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo      = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost          = IP-literal / IPv4address / ireg-name
port           = *DIGIT

IP-literal     = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

ZoneID         = 1*( unreserved / pct-encoded )

IPv6addrz      = IPv6address "%25" ZoneID

IPvFuture      = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

IPv6address    =                            6( h16 ":" ) ls32
               /                       "::" 5( h16 ":" ) ls32
               / [               h16 ] "::" 4( h16 ":" ) ls32
               / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
               / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
               / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
               / [ *4( h16 ":" ) h16 ] "::"              ls32
               / [ *5( h16 ":" ) h16 ] "::"              h16
               / [ *6( h16 ":" ) h16 ] "::"

h16            = 1*4HEXDIG
ls32           = ( h16 ":" h16 ) / IPv4address
IPv4address    = dec-octet "." dec-octet "." dec-octet "." dec-octet

dec-octet      = DIGIT                 ; 0-9
               / %x31-39 DIGIT         ; 10-99
               / "1" 2DIGIT            ; 100-199
               / "2" %x30-34 DIGIT     ; 200-249
               / "25" %x30-35          ; 250-255

ireg-name      = *( iunreserved / pct-encoded / sub-delims )

ipath          = ipath-abempty   ; begins with "/" or is empty
               / ipath-absolute  ; begins with "/" but not "//"
               / ipath-noscheme  ; begins with a non-colon segment
               / ipath-rootless  ; begins with a segment
               / ipath-empty     ; zero characters

ipath-abempty  = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty    = 0

isegment       = *ipchar
isegment-nz    = 1*ipchar
isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims / "@" )
               ; non-zero-length segment without any colon ":"

ipchar         = iunreserved / pct-encoded / sub-delims / ":" / "@"

iquery         = *( ipchar / iprivate / "/" / "?" )

ifragment      = *( ipchar / "/" / "?" )

iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
               / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
               / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
               / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
               / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
               / %xD0000-DFFFD / %xE1000-EFFFD

iprivate       = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD

pct-encoded    = "%" HEXDIG HEXDIG

unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved       = gen-delims / sub-delims
gen-delims     = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims     = "!" / "$" / "&" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="

ABNFはiri-grammar.abnfから直接アクセスすることもできます。

G. 謝辞

この節は非規範的です。

G.1 RDF 1.0への謝辞

この節は非規範的です。

この仕様の元のバージョンの編集者は、 Graham Klyne（Nine by Nine）および Jeremy J. Carroll（Hewlett Packard Labs）でした。

この文書には、Pat Hayes、Sergey MelnikおよびPatrick Sticklerからの重要な貢献が含まれており、 彼らの指導の下で、整数や日付などのデータ型付き値を表現するための RDF仕様群で説明されるフレームワークが開発されました。

編集者は、以下からの貴重な貢献に感謝します: Frank Manola、Pat Hayes、Dan Brickley、Jos de Roo、Dave Beckett、 Patrick Stickler、Peter F. Patel-Schneider、Jerome Euzenat、Massimo Marchiori、 Tim Berners-Lee、Dave ReynoldsおよびDan Connolly。

Jeremy Carrollは、イタリアのW3Cオフィスおよび Istituto di Scienza e Tecnologie dell'Informazione "Alessandro Faedo"でのホストである Oreste Signoreに感謝します。同研究所はConsiglio Nazionale delle Ricercheの一部であり、 Jeremyはそこで客員研究員を務めています。

この文書は、RDFcore Working Groupによる長期にわたる熟議の成果物であり、 そのメンバーには以下が含まれていました: Art Barstow（W3C）、Dave Beckett（ILRT）、Dan Brickley （ILRT）、Dan Connolly（W3C）、 Jeremy Carroll（Hewlett Packard）、Ron Daniel（Interwoven Inc）、Bill dehOra（InterX）、 Jos De Roo（AGFA）、Jan Grant（ILRT）、Graham Klyne（Nine by Nine）、 Frank Manola（MITRE Corporation）、Brian McBride（Hewlett Packard）、 Eric Miller（W3C）、Stephen Petschulat（IBM）、Patrick Stickler（Nokia）、 Aaron Swartz（HWG）、Mike Dean（BBN Technologies / Verizon）、 R. V. Guha（Alpiri Inc）、Pat Hayes（IHMC）、Sergey Melnik（Stanford University）および Martyn Horner（Profium Ltd）。

この仕様はまた、Ora LassillaおよびRalph Swickが編集した以前の RDF Model and Syntax文書、ならびにDan BrickleyおよびR. V. Guhaが編集した RDF Schemaにも基づいています。 この以前の作業に貢献したRDF and RDF Schema Working Groupのメンバーは以下の通りです: Nick Arnett（Verity）、Tim Berners-Lee（W3C）、Tim Bray （Textuality）、 Dan Brickley（ILRT / University of Bristol）、Walter Chang（Adobe）、Sailesh Chutani（Oracle）、 Dan Connolly（W3C）、Ron Daniel（DATAFUSION）、Charles Frankston（Microsoft）、 Patrick Gannon（CommerceNet）、 R. V. Guha（Epinions、以前はNetscape Communications）、Tom Hill（Apple Computer）、 Arthur van Hoff（Marimba）、Renato Iannella（DSTC）、Sandeep Jain（Oracle）、 Kevin Jones、（InterMind）、Emiko Kezuka（Digital Vision Laboratories）、 Joe Lapp（webMethods Inc.）、Ora Lassila（Nokia Research Center）、Andrew Layman（Microsoft）、 Ralph LeVan（OCLC）、John McCarthy（Lawrence Berkeley National Laboratory）、 Chris McConnell（Microsoft）、Murray Maloney（Grif）、 Michael Mealling（Network Solutions）、Norbert Mikula（DataChannel）、 Eric Miller（OCLC）、Jim Miller（W3C、名誉職）、 Frank Olken（Lawrence Berkeley National Laboratory）、Jean Paoli（Microsoft）、 Sri Raghavan（Digital/Compaq）、Lisa Rein（webMethods Inc.）、 Paul Resnick（University of Michigan）、Bill Roberts（KnowledgeCite）、 i Tsuyoshi Sakata（Digital Vision Laboratories）、Bob Schloss（IBM）、 Leon Shklar（Pencom Web Works）、David Singer（IBM）、Wei（William）Song（SISU）、 Neel Sundaresan（IBM）、Ralph Swick（W3C）、Naohiko Uramoto （IBM）、 Charles Wicksteed（Reuters Ltd.）、Misha Wolf（Reuters Ltd.）および Lauren Wood（SoftQuad）。

G.2 RDF 1.1への謝辞

この節は非規範的です。

RDF 1.1バージョンの仕様の編集者は、 Richard Cyganiak（DERI）、 David Wood（3 Round Stones）、および Markus Lanthaler（Graz University of Technology）でした。

編集者は、Thomas Baker、Tim Berners-Lee、David Booth、Dan Brickley、Gavin Carothers、Jeremy Carroll、 Pierre-Antoine Champin、Dan Connolly、John Cowan、Martin J. Dürst、 Alex Hall、Steve Harris、Sandro Hawke、Pat Hayes、Ivan Herman、Peter F. Patel-Schneider、 Addison Phillips、Eric Prud'hommeaux、Nathan Rixham、Andy Seaborne、Leif Halvard Silli、 Guus Schreiber、Dominik Tomaszuk、およびAntoine Zimmermannからの貴重な貢献に感謝します。

RDF Working Groupのメンバーには、Thomas Baker、 Scott Bauer、Dan Brickley、Gavin Carothers、Pierre-Antoine Champin、 Olivier Corby、Richard Cyganiak、Souripriya Das、Ian Davis、Lee Feigenbaum、 Fabien Gandon、Charles Greer、Alex Hall、Steve Harris、Sandro Hawke、 Pat Hayes、Ivan Herman、Nicholas Humfrey、Kingsley Idehen、Gregg Kellogg、 Markus Lanthaler、Arnaud Le Hors、Peter F. Patel-Schneider、 Eric Prud'hommeaux、Yves Raimond、Nathan Rixham、Guus Schreiber、 Andy Seaborne、Manu Sporny、Thomas Steiner、Ted Thibodeau、Mischa Tuffield、 William Waites、Jan Wielemaker、David Wood、Zhe Wu、およびAntoine Zimmermannが含まれていました。

G.3 RDF 1.2への謝辞

この節は非規範的です。

編集者に加えて、以下の人々がこの仕様に貢献しました: Denis Ah-Kang, doerthe, Dominik Tomaszuk, Enrico Franconi, james anderson, Niklas Lindström, Peter F. Patel-Schneider, Ruben Taelman, Sarven Capadisli, Ted Thibodeau Jr, Thomas Tanon, and William Van Woensel

RDF & SPARQL Working Group Groupのメンバーには以下が含まれていました: Vladimir Alexiev、 James Anderson、 Amin Anjomshoaa、 Julián Arenas-Guerrero、 Dörthe Arndt、 Bilal Ben Mahria、 Erich Bremer、 Dan Brickley、 Kurt Cagle、 Sarven Capadisli、 Rémi Ceres、 Pierre-Antoine Champin、 David Chaves-Fraga、 Souripriya Das、 Daniil Dobriy、 Enrico Franconi、 Jeffrey Phillips Freeman、 Fabien Gandon、 Benjamin Goering、 Damien Graux、 Adrian Gschwend、 Olaf Hartig、 Timothée Haudebourg、 Ian Horrocks、 Gregg Kellogg、 Mark Kim、 Jose Emilio Labra Gayo、 Ora Lassila、 Richard Lea、 Niklas Lindström、 Pasquale Lisena、 Thomas Lörtsch、 Matthew Nguyen、 Peter Patel-Schneider、 Thomas Pellissier Tanon、 Dave Raggett、 Jean-Yves ROSSI、 Felix Sasaki、 Andy Seaborne、 Alan Snyder、 Stuart Sutton、 Ruben Taelman、 Ted Thibodeau Jr、 Dominik Tomaszuk、 Raphaël Troncy、 William Van Woensel、 Gregory Williams、 Jesse Wright、 Achille Zappa、および Antoine Zimmermann。

編集者注

Task Forceのメンバーを確認するか？貢献者の一覧は見つけにくい。

H. RDF 1.1とRDF 1.2の間の変更点

この節は非規範的です。

注記

RDFバージョン 1.1と1.2の違いの詳細な概要は、 What’s New in RDF 1.2 [RDF12-NEW]にあります。

I. 索引

I.1 この仕様で定義される用語

I.2 参照により定義される用語

J. 参照文献

J.1 規範的参照文献

[BCP47]
Tags for Identifying Languages. A. Phillips, 編; M. Davis, 編. IETF. 2009年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[DOM]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 2018年3月27日. W3C勧告. URL: https://www.w3.org/TR/html5/
[I18N-GLOSSARY]
Internationalization Glossary. Richard Ishida; Addison Phillips. W3C. 2024年10月17日. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RDF11-TESTCASES]
RDF 1.1 Test Cases. Gregg Kellogg; Markus Lanthaler. W3C. 2014年2月25日. W3C Working Group Note. URL: https://www.w3.org/TR/rdf11-testcases/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3629]
UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF. 2003年11月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3629
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]
Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. 2005年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
[RFC7493]
The I-JSON Message Format. T. Bray, 編. IETF. 2015年3月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7493
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, 編. IETF. 2017年12月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. 2019年5月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[Unicode]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[XML-NAMES]
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson ほか. W3C. 2009年12月8日. W3C勧告. URL: https://www.w3.org/TR/xml-names/
[XML11]
Extensible Markup Language (XML) 1.1 (Second Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau; John Cowan ほか. W3C. 2006年8月16日. W3C勧告. URL: https://www.w3.org/TR/xml11/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron ほか. W3C. 2012年4月5日. W3C勧告. URL: https://www.w3.org/TR/xmlschema11-2/

J.2 参考参照文献

[ABNF]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, 編; P. Overell. IETF. 2008年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[COOLURIS]
Cool URIs for the Semantic Web. Leo Sauermann; Richard Cyganiak. W3C. 2008年12月3日. W3C Working Group Note. URL: https://www.w3.org/TR/cooluris/
[did-core]
Decentralized Identifiers (DIDs) v1.0. Manu Sporny; Amy Guy; Markus Sabadello; Drummond Reed. W3C. 2022年7月19日. W3C勧告. URL: https://www.w3.org/TR/did-core/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML-RDFA]
HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 2015年3月17日. W3C勧告. URL: https://www.w3.org/TR/html-rdfa/
[JSON-LD11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 2020年7月16日. W3C勧告. URL: https://www.w3.org/TR/json-ld11/
[LINKED-DATA]
Linked Data Design Issues. Tim Berners-Lee. W3C. 2006年7月27日. W3C内部文書. URL: https://www.w3.org/DesignIssues/LinkedData.html
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 2012年12月11日. W3C 勧告. URL: https://www.w3.org/TR/owl2-overview/
[OWL2-SYNTAX]
OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 2012年12月11日. W3C勧告. URL: https://www.w3.org/TR/owl2-syntax/
[RDF-CANON]
RDF Dataset Canonicalization. Gregg Kellogg; Dave Longley; Dan Yamamoto. W3C. 2024年5月21日. W3C勧告. URL: https://www.w3.org/TR/rdf-canon/
[RDF-CONCEPTS-20040210]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 2004年2月10日. W3C勧告. URL: https://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 2014年2月25日. W3C勧告. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF11-DATASETS]
RDF 1.1: On Semantics of RDF Datasets. Antoine Zimmermann. W3C. 2014年2月25日. W3C Working Group Note. URL: https://www.w3.org/TR/rdf11-datasets/
[RDF11-MT]
RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 2014年2月25日. W3C勧告. URL: https://www.w3.org/TR/rdf11-mt/
[RDF12-INTEROP]
RDF 1.2 Interoperability. Pierre-Antoine Champin. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-interop/spec/
[RDF12-N-QUADS]
RDF 1.2 N-Quads. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年3月20日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-n-quads/
[RDF12-N-TRIPLES]
RDF 1.2 N-Triples. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年3月26日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-n-triples/
[RDF12-NEW]
What’s New in RDF 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/rdf-new/spec/
[RDF12-PRIMER]
RDF 1.2 Primer. Niklas Lindström; Pierre-Antoine Champin. W3C. 2025年4月3日. DNOTE. URL: https://www.w3.org/TR/rdf12-primer/
[RDF12-SCHEMA]
RDF 1.2 Schema. Dominik Tomaszuk. W3C. 2026年3月20日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-schema/
[RDF12-SEMANTICS]
RDF 1.2 Semantics. Peter Patel-Schneider; Dörthe Arndt; Enrico Franconi. W3C. 2026年3月26日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-semantics/
[RDF12-TRIG]
RDF 1.2 TriG. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年3月20日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-trig/
[RDF12-TURTLE]
RDF 1.2 Turtle. Gregg Kellogg; Dominik Tomaszuk. W3C. 2026年3月20日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-turtle/
[RDF12-XML]
RDF 1.2 XML Syntax. Gregg Kellogg; Jerven Bolleman. W3C. 2026年3月26日. W3C作業草案. URL: https://www.w3.org/TR/rdf12-xml/
[RDFA-CORE]
RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman ほか. W3C. 2015年3月17日. W3C勧告. URL: https://www.w3.org/TR/rdfa-core/
[RFC3023]
XML Media Types. M. Murata; S. St. Laurent; D. Kohn. IETF. 2001年1月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3023
[RFC5890]
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. IETF. 2010年8月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc5890
[RFC5892]
The Unicode Code Points and Internationalized Domain Names for Applications (IDNA). P. Faltstrom, 編. IETF. 2010年8月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc5892
[RFC6874]
Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter; S. Cheshire; R. Hinden. IETF. 2013年2月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6874
[rfc7230]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, 編; J. Reschke, 編. IETF. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[SPARQL11-QUERY]
SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 2013年3月21日. W3C勧告. URL: https://www.w3.org/TR/sparql11-query/
[SPARQL12-CONCEPTS]
SPARQL 1.2 Concepts. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-concepts/spec/
[SPARQL12-ENTAILMENT]
SPARQL 1.2 Entailment Regimes. Peter Patel-Schneider. W3C. 2025年8月14日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-entailment/
[SPARQL12-FEDERATED-QUERY]
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 2026年1月26日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-federated-query/
[SPARQL12-GRAPH-STORE-PROTOCOL]
SPARQL 1.2 Graph Store Protocol. Andy Seaborne; Thomas Pellissier Tanon. W3C. 2024年12月19日. W3C 作業草案. URL: https://www.w3.org/TR/sparql12-graph-store-protocol/
[SPARQL12-NEW]
What’s New in SPARQL 1.2. The W3C RDF & SPARQL Working Group. W3C. W3C編集者草案. URL: https://w3c.github.io/sparql-new/spec/
[SPARQL12-PROTOCOL]
SPARQL 1.2 Protocol. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025年8月14日. W3C作業 草案. URL: https://www.w3.org/TR/sparql12-protocol/
[SPARQL12-QUERY]
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026年3月23日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-query/
[SPARQL12-RESULTS-CSV-TSV]
SPARQL 1.2 Query Results CSV and TSV Formats. Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025年8月14日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-csv-tsv/
[SPARQL12-RESULTS-JSON]
SPARQL 1.2 Query Results JSON Format. Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2025年8月14日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-json/
[SPARQL12-RESULTS-XML]
SPARQL 1.2 Query Results XML Format. Ruben Taelman; Dominik Tomaszuk; Thomas Pellissier Tanon. W3C. 2024年12月27日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-results-xml/
[SPARQL12-SERVICE-DESCRIPTION]
SPARQL 1.2 Service Description. Ruben Taelman; Gregory Williams. W3C. 2026年3月19日. W3C作業 草案. URL: https://www.w3.org/TR/sparql12-service-description/
[SPARQL12-UPDATE]
SPARQL 1.2 Update. Ruben Taelman; Andy Seaborne; Thomas Pellissier Tanon. W3C. 2025年8月14日. W3C作業草案. URL: https://www.w3.org/TR/sparql12-update/
[STRING-META]
Strings on the Web: Language and Direction Metadata. Richard Ishida; Addison Phillips. W3C. 2024年10月17日. W3C Working Group Note. URL: https://www.w3.org/TR/string-meta/
[SWBP-N-ARYRELATIONS]
Defining N-ary Relations on the Semantic Web. Natasha Noy; Alan Rector. W3C. 2006年4月12日. W3C Working Group Note. URL: https://www.w3.org/TR/swbp-n-aryRelations/
[SWBP-XSCH-DATATYPES]
XML Schema Datatypes in RDF and OWL. Jeremy Carroll; Jeff Pan. W3C. 2006年3月14日. W3C Working Group Note. URL: https://www.w3.org/TR/swbp-xsch-datatypes/
[UNICODE-SECURITY]
Unicode Security Considerations. Mark Davis; Michel Suignard. Unicode Consortium. 2014年9月19日. Unicode Technical Report #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[VOCAB-ORG]
The Organization Ontology. Dave Reynolds. W3C. 2014年1月16日. W3C勧告. URL: https://www.w3.org/TR/vocab-org/
[WEBARCH]
Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 2004年12月15日. W3C勧告. URL: https://www.w3.org/TR/webarch/