RDF（Resource Description Framework;リソース記述フレームワーク）
とは、リソースに関する情報をワールドワイドウェブで表現するための言語であり、特に、表題、著者、Webページの更新日、Web文書の著作権やライセンス情報、共有リソースの有効スケジュールなどのようなWebリソースに関してのメタデータを表現することを目的としている。しかし、「Webリソース」という概念を一般化することによって、RDFは、Webで直接検索できない場合でもWebで識別することのできることについての情報を表現するのにも使用できる。RDFは、Webでの情報を表現するための共通な枠組みを備えているので、意味を喪失することなしにアプリケーション間で情報を交換することができる。
この入門書は、RDFを効果的に使用するのに必要な基礎知識を読者に提供するために考案された。RDFの基本概念を紹介し、そのXMLシンタックス、RDFボキャブラリ記述言語を使用したRDFボキャブラリの定義方法、RDFを導入したアプリケーションの概要について述べている。また、その他のRDF仕様文書の概念と目的についてもふれている。
特に、行った変更が現行の実装やコンテンツにどのように反映されるかについてのフィードバックやコメントの推進のため、本書は、W3Cの会員とその他関連団体のレビュー用に作成された。
本書はW3Cの会員やその他の関連団体によるレビュー用の公的なW3Cの最終ワーキングドラフトである。本節では、発行時の本書の位置づけを述べている。ドラフトの文書のため、本書はいつでも改版、置換、
または他の文書により陳腐化することがある。従って、W3Cのワーキングドラフトを参考文献資料として使用したり、
"進行中の作業"以外のものとして引用することは不適切である。W3Cの提案やその他の技術文書のリストは、http://www.w3.org/TR/で参照できる。
1. 序論
RDF（Resource Description Framework;リソース記述フレームワーク）
とは、リソースに関する情報をワールドワイドウェブで表現するための言語であり、
特に、表題、著者、Webページの更新日、Web文書の著作権やライセンス情報、共有リソースの有効スケジュールなどのようなWebリソースに関してのメタデータを表現することを目的としている。
しかし、「Webリソース」という概念を一般化することによって、RDFは、Webで直接検索できない場合でもWebで識別することのできることについての情報を表現するのにも使用できる。例として、オンラインショッピング機能からの項目（例えば、仕様や価格、可用性など）の情報や、情報発信のためのWebユーザの嗜好の記述などがある。
RDFは、Webでの情報を表現するための共通な枠組みを備えているので、意味を喪失することなしにアプリケーション間で情報を交換することができる。
RDFは共通の枠組みなので、アプリケーション設者は共通のRDFパーサや処理ツールを利用することができる。異なるアプリケーション間で情報交換を行う機能は、つまり、情報はもともとアプリケーション用に作成されるが、そのアプリケーション以外のアプリケーションで情報が利用できると言うことである。
RDFは、Webの識別子（URI）使用して物事を識別するということと、簡単なプロパティやプロパティ値に関してのリソースを表記するという考えに基づいている。この考えによって、RDFは、リソースを表現するノードとアークのグラフや、そのプロパティとプロパティ値として、リソースについての簡単なステートメントを表現できる。できる限り迅速にこの討議を具体的にするために、「メールアドレスが
em@w3.org、役職が博士である、Eric Millerという名前の人がいる。」というステートメントのグループは、図
1のRDFグラフで表すことができる。
図
1では、RDFがURIを使用して以下を特定していることを示している。
- 個人、例えば、Eric Miller、は
http://www.w3.org/People/EM/contact#meで特定される。
- 物事の種類、例えば、人、は
http://www.w3.org/2000/10/swap/pim/contact#Personで特定される。
- メールボックスなどのようなもののプロパティは、
http://www.w3.org/2000/10/swap/pim/contact#mailboxで特定される。
- 上記プロパティの値、例えば、mailboxのプロパティの値としてのmailto:em@w3.org(また、RDFは"Eric Miller"などのように、一部のプロパティの値として文字列を使用する)
さらに、RDFはこういったグラフを記録し、交換するためのXMLベースのシンタックス（RDF/XMLとよばれる）も提供する。例
1 は、図
1のグラフに対応するRDF/XMLのRDFの一部分である。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">
<contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
<contact:fullName>Eric Miller</contact:fullName>
<contact:mailbox rdf:resource="mailto:em@w3.org"/>
<contact:personalTitle>Dr.</contact:personalTitle>
</contact:Person>
</rdf:RDF>
mailboxと、（省略形の）fullName
、そしてそれぞれの値em@w3.orgとEric
Millerと同様に、このRDF/XMLにもURIが含まれるということに注意。
HTMLと同様に、このRDF/XMLはマシンが処理でき、URIを使用してWeb中の情報の一部分にリンクできる。しかし、従来のハイパーテキストと違ってRDFのURIはWeb上で直接検索できないもの（例えば、Eric
Millerという人）を含む特定可能なものを参照することができる。結果として、Webページなどのようなものの記述に加え、車、ビジネス、人、ニュース
イベントなどの記述も可能である。さらに、RDFのプロパティ自身、URIがあり、結びついている項目間での関係の種類を正確に識別する。
以下の文書は、RDFの仕様書に役立つ。
本入門書は、RDFへの入門について述べ、現行のRDFのアプリケーションを記述し、情報システムの設計者やアプリケーション開発者がRDFの機能とその使用法を理解するのに役立つことを目的としている。特に、以下の質問に答えることもその目的に含まれる。
- RDF様相は？
- RDFはどんな情報を表現できるのか？
- RDFの情報がどのように作成、アクセス、処理されるのか？
- 現行の情報はどのようにしてRDFと組み合わせられるのか？
本入門書は標準非準拠の文書である。つまり、本書はRDFの最終的な仕様書ではない、ということである。本書の例やその他説明資料は、RDFへの理解を促進するためのものであるが、いつも最終的で、完全な回答を提供するわけではない。最終的で完全な回答については、RDFの標準準拠の対応する部分を参照する必要がある。そのため、標準準拠の仕様書の相当部分のリンクを設けた。
2. リソースについてのステートメントの作成
RDFの目的は、WebページなどのWebリソースについてのステートメントを作成する簡単な方法を提供することである。本節では、RDFがこの機能（この概念を記述する規範となる仕様書はRDF Concepts and Abstract Syntax
[RDF-CONCEPTS]である)を提供する方法の背景となる基本的な考察について述べている。
2.1 基本概念
John
Smithという名前の人が特定のWebページを作成したという事実を述べたいと仮定する。英語でそれを述べる簡単な方法は、以下のように簡単なステートメント形式となる。
http://www.example.org/index.html has a
creator whose value is John Smith
物事のプロパティを記述するために、以下の様に、いくつかのことに名前を付けたり特定する必要があるということを表すため、このステートメント部分に下線を引いた。
- 記述したいことを特定するための方法が必要である。 (この場合、Webページ）
- 記述したいことの特定のプロパティ(この場合、creator（作者））を特定するための方法が必要である。
- 記述したいものに対し、このプロパティの値（creator（作者）は誰か）として割り当てるものを特定するための方法が必要である。
このステートメントでは、WebページのURL(Uniform Resource Locator)
を使用して特定した。また、話題にするプロパティを特定するために「creator（作者）」を使用し、話題にしたい物事（人）を特定するために二語「John
Smith」はこのプロパティの値である。
ページを特定するURLとプロパティとその値を特定するための言葉（または、他の表現）を使用して、同じような一般的な形式の英語のステートメントを追加することによって、このWebページの他のプロパティを述べることができる。例えば、ページを作成した日とページが作成された言語を指定するために、以下のステートメントを追加することができる。
http://www.example.org/index.html has a
creation-date whose value is August 16,
1999
http://www.example.org/index.html has a
language whose value is English
RDFは、記述するものには値を持つプロパティがあるということと、ステートメントの作成や、上記と同じようなことでリソースが記述できる、ということ、そして、このプロパティと値を指定するという考えに基づいている。RDFは、ステートメントの様々な部分について述べるために特別な用語を使用する。特に、ステートメントが何かということを特定する部分（この例では、Webページ）を主語
(subject)という。ステートメントが明記する主語のプロパティや特徴を特定する部分（この例では、creator、creation-date、や、language)
を述語
(predicate)、プロパティの値を特定する部分を目的語 (object)
という。従って、英語のステートメントは以下になる。
http://www.example.org/index.html has a
creator whose value is John Smith
ステートメントのいろんな部分のRDF用語は以下となっている。
- 主語（subject）はURL http://www.example.org/index.html。
- 述語（predicate） は、「creator」という言葉。
- 目的語（object）は、「John Smith」というフレーズ。
なお、英語は（英語を話す）人での間でコミュニケーションをとるのに便利だが、RDFはマシンが処理できるステートメントを作成しようとしている。マシンが処理するのに適するステートメントを作成するには、以下の二つのことが必要である。
- 他の誰かがWebで使用している可能性のある同じような識別子と混乱することなくステートメント内で主語、述語、目的語を識別できる、マシンが処理できる識別子の仕組み。
- これらのステートメントを表現し、マシン間で交換するためのマシンが処理できる言語。
幸い、現行のWeb構造では必要な機能が備わっている。
これまで見てきたように、Webはすでに、URL
(Uniform Resource Locator)という、一つの識別子の形式を有している。 オリジナルの例を使用してJohn
Smitが作成したWebページ特定する。URLとは、主なアクセスの仕組み（基本的には、そのネットワークの「存在場所」）を表現することによってWebリソースを識別する文字列のことである。Webページとは違って、様々な事柄についての情報を記録したいと考えているため、ネットワークの存在場所やURLを持ってはいない。
こういった目的のため、Webは、Uniform Resource Identifier（URI）という、識別子のより一般的な形式を有している。URLは、URIの特別な種類のことである。URIは、様々な人や組織が物事を識別するために個々に作成し使用することのできるプロパティを共有する。しかし、URIはネットワークの場所を有するもの識別したり、他のコンピュータのアクセスメカニズムを使用することに制限されてはいない。事実、URIを作成して、以下のようなことを含む伝えたいことを参照することができる。
- 電子文書や画像、サービス（例えば「ロスアンゼルスの今日の天気」など）やその他のリソースのグループなどのような、ネットワークでアクセス可能なもの。
- 人や会社、図書館の製本簿などのようなネットワークでアクセスできないもの。
- 「作者」の概念などのような、物理的に存在しない抽象的な概念。
この一般性から、RDFは、主語 (subject)、述語 (predicate)、および目的語 (object)
をステートメント内で識別するためのメカニズムの基礎として、URIを使用する。より正確にするために、RDFはURI 参照 [URIS]を使用する。URI参照
(URIref)は、URIであり、その末尾に任意のフラグメント識別子が付加されている。例えば、URI参照http://www.example.org/index.html#section2は、URI
http://www.example.org/index.htmlと("#"で区切られている )
フラグメント識別子Section2で構成されている。RDFは、リソースをURI参照で識別できるものとして定義するため、URIrefを使用すると、RDFは物事を実質的に記述でき、同時にその物事の間の関係を述べることができる。URIrefとフラグメント識別子に関しては、付録 Aと [RDF-CONCEPTS]で述べる。
RDFステートメントをマシンが処理できる方法で表現するために、RDFはExtensible Markup
Language [XML]を使用する。XMLは、誰もが自身の文書形式を設計し、その形式で文書を書くことができるようにするためにデザインされた。RDF情報を表現する際に使用したり、マシン間で交換したりするために、RDFは、RDF/XMLと呼ばれる特定のXMLマークアップ言語を定義する。RDF/XMLの例は、第1節で述べている。その例(例
1)では、
<contact:fullName>と<contact:personalTitle>などのタグを使用しテキストコンテンツ
Eric
MillerとDr.をそれぞれ区切っている。このようなタグを使用すると、タグの意味を理解して書かれたプログラムはそのコンテンツを適切に解釈できる。
付録
Bでは、一般的なXMLについての背景を詳しく述べている。RDF用に使用される特定のRDF/XMLシンタックスについては、 第3節で取り扱っている。
2.2 RDFモデル
RDFステートメントの基本概念、伝えるものをWeb上で識別するためのURI参照とRDFステートメントを表現するマシンが処理する方法としてのRDF/XML、を紹介したので、URIを使ってRDFでどのようにリソースについてのステートメントを作成できるかについて述べることができる。序論では、RDFはリソースについての簡単なステートメントを表現する考えに基づいており、ステートメントは主語 (subject)、述語 (predicate)、目的語 (object) を使用して構成されている、ということを述べた。RDFでは、オリジナルの英語でのステートメントを以下の様に表現できる。
http://www.example.org/index.html has a
creator whose value is John Smith
RDFステートメントによる表現には、以下が含まれている。
- 主語 (subject)http://www.example.org/index.html
- 述語 (predicate) http://purl.org/dc/elements/1.1/creator
- 目的語 (object) http://www.example.org/staffid/85740
「creator」や「John Smith」のかわりに、オリジナルのステートメントの主語 (subject)だけでなく述語 (predicate)や目的語 (object) を特定するために、どのようにURIrefを使用したかについて注意すること。この件に関しては、本節の後のほうで述べることにする。
RDFは、ステートメントをグラフの中でノードやアークとして表している。RDFのグラフモデルは、[RDF-CONCEPTS]で定義されている。この表記では、ステートメントは以下によって表現される。
- URIrefでラベル付加されている主語 (subject)のノード
- URIrefでラベル付加されている目的語 (object) のノード
- 主語 (subject)ノードや 目的語 (object) ノードから向けられた、URIrefでラベル付加されている述語 (predicate)のアーク
そのため、上記のRDFステートメントは、図
2のグラフで表現される。
ステートメントのグループは対応するノードとアークのグループで表現される。そのため、さらにステートメントを表現する場合は、
http://www.example.org/index.html has a
creation-date whose value is August 16,
1999
http://www.example.org/index.html has a
language whose value is English
図
3のグラフで、適応するURIrefを使用して「creation-date」や「language」などのプロパティを指定することができる。
図
3ではRDFステートメントの目的語 (object) が、URIrefで識別されるリソースであるか、または、文字列で表現される(リテラルといわれる)一定の値であるかを示して、ある種のプロパティ値を表現している。リテラルはRDFステートメントの主語
(subject)や述語 (predicate)にはなりえない。(使用している簡潔な文字列のリテラルは現在、型付き（typed）リテラル と区別するために、プレーンなリテラルという。型付き（typed）リテラルについては、第2.4節で紹介する。RDFで使用できる様々なリテラルは、[RDF-CONCEPTS]で定義されている。)
RDFグラフ作成の際、URIrefで識別されるリソースを表現するノードを楕円で示し、リテラルを表現するノードを（リテラル自身でラベル付けされた）箱で示す。
こういったことに関して、グラフを描くのが不便な場合があるので、トリプルというステートメントを書く別の方法も使用される。トリプル表記では、グラフのステートメントはそれぞれ、主語（subject）ノードラベル、述語（predicate）ノードラベル、目的語（object）ノードラベル(URIref
または、リテラル)の順番で、この三つを使った簡単なトリプルで表現される。 図
3 のステートメントを表現するトリプルの全容は以下のようになる。
<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> .
<http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" .
<http://www.example.org/index.html> <http://www.example.org/terms/language> "English" .
各トリプルはグラフ内で一つのアークに対応し、アークの最初と最後のノード（ステートメントの主語（subject）と目的語（object））を備えている。描いたグラフとは違って（しかし、オリジナルのステートメントと同じ様に）、トリプルの表記には、ノードは表示される各ステートメント様に別々に識別されなければならない。従って、例えば、http://www.example.org/index.htmlはトリプルの中で三回（各トリプルで一回ずつ）表示されるが、描いたグラフには一度しか表示されない。しかし、トリプルはグラフと同じ情報を正確に表現する。このことが重要な点である。つまり、RDFにとって欠かせないものは、ステートメントのグラフモデルであるということである。グラフを表現したり、描いたりするために使用される表記は補助的なものである。
完全なトリプル表記では、上記で示しているように、完全にかぎ括弧に書き込まれたURI参照が非常に長い行となるようにしなければならない。便宜上、本入門書の残りの部分や、他のRDF仕様書でトリプル表記の省略形を使用する。この省略形では、かぎ括弧を使用しない修飾された名前 (QName)を完全なURI参照の省略として代用できる。
QNameには、ネーム空間URIに割り当てられているプリフィックス(接頭辞)が含まれており、その後にコロン、そして、 ローカル名が続く(QNamesは付録 Bで詳しく述べる)。
従って、例えば、QNameプリフィックス(接頭辞)fooがネーム空間URIhttp://example.org/somewhere/に割り当てられている場合、QName
foo:barは、URIrefhttp://example.org/somewhere/barの省略形となる。また、
次に定義されているように、（いつも明示的に指定しなくても使用できる）「周知の」QNameプリフィックス(接頭辞)の例でより広く使用する。
プリフィックス（接頭辞）
rdf:、ネーム空間 URI:
http://www.w3.org/1999/02/22-rdf-syntax-ns#
プリフィックス（接頭辞）
rdfs:、ネーム空間 URI:
http://www.w3.org/2000/01/rdf-schema#
プリフィックス（接頭辞）
dc:、ネーム空間 URI:
http://purl.org/dc/elements/1.1/
プリフィックス（接頭辞）
daml:、 ネーム空間 URI:
http://www.daml.org/2001/03/daml+oil#
プリフィックス（接頭辞）
ex:、ネーム空間 URI:
http://www.example.org/ (または、http://www.example.com/)
プリフィックス（接頭辞）
xsd:、ネーム空間 URI:
http://www.w3.org/2001/XMLSchema#
また、必要であれば、混乱を招かない場合は、プリフィックス（接頭辞）ex: の例に関して変更を行う。例えば、
プリフィックス（接頭辞）exterms:、ネーム空間URI:
http://www.example.org/terms/
(例として出している組織で使用している用語用)、
プリフィックス（接頭辞）exstaff:、ネーム空間URI:
http://www.example.org/staffid/
(例として出している組織のスタッフの識別子用)、
プリフィックス（接頭辞）ex2:、ネーム空間URI:
http://www.domain2.example.org/ (二番目に例として出した組織)、など
この新しい省略形を使用して、以下の様に上記のトリプルのセットを書くことができる。
ex:index.html dc:creator exstaff:85740 .
ex:index.html exterms:creation-date "August 16, 1999" .
ex:index.html exterms:language "English" .
RDFステートメントについて例では、物事を識別するRDFの基礎的な方法としてURIrefを使用する長所について述べている。例えば、この場合「John Smith」という文字列で最初の例にあるWebページの作者を識別する代わりに、作者をURIrefと割り当てる。この場合（作者の社員番号を使用して）http://www.example.org/staffid/85740。 この時のURIrefを使用する利点は、識別がより正確にできるということである。つまり、ページの作者は「John Smith」や 何千人といるJohn Smithという名前の誰かではなく、（URIrefを作成した誰が人この関連を定義したとしても）このURIrefに関連付けられている特定のJohn Smithであるということである。さらに、ページの作者のURIrefがあるので、それは正真正銘のリソースであり、図 4にあるグラフの様に、名前や年齢などといった作者に関する詳細情報を記録することができる。
また、この例では、RDFがRDFステートメントの中でURIrefを述語（predicate）として使用していることも示している。つまり、プロパティを識別するのに「creator」や「name」などのような文字列（または、文字）を使用するのではなく、RDFはURIrefを使用する。いろんな理由から、URIrefsを使用してプロパティを識別することは重要である。まず、URIrefを使用すると、同じ文字列で識別されそうな、別の誰かが使用している可能性のあるプロパティと自分が使用しているプロパティを区別することができる。例えば、
example.orgは誰かのフルネームを示すための文字列リテラルとして書き出された「name」を使用するが、別の誰かは「name」を他の違ったもの（例えば、プログラムテキストの一部分の変数の名前など）を示すものとして表すかもしれない。Web上で「name」をプロパティ識別子として認識するプログラムは、「name」の使用法については区別しなくてもよい。しかし、example.orgが、「name」のプロパティにhttp://www.example.org/terms/nameを書き込み、他の人が
http://www.domain2.example.org/genealogy/terms/nameを自分自身に書き込んだ場合、（プログラムが自動的に別々の意味と判断できなくても）別々のプロパティが関係している事実をそのまま維持することができる。プロパティを識別するのにURIrefを使用することが重要であることのもう一つの理由は、リソース自身をRDFプロパティとして処理できる、ということがある。プロパティはリソースなので、それらに関する決定的な情報を単に、RDFステートメントをプロパティのURIreに主語（subject）として追加することによって、記録することができる。(例えば、example.orgが「name」で何を意味しているかということの英語表記など）
RDFステートメントで、URIrefを主語（subject）、述語（predicate）、目的語（object）として使用すると、伝える概念の理解の共有を反映（作成）し、共有ボキャブラリを開発し、Web上で使用することができる。例えば、トリプルでは、
ex:index.html dc:creator exstaff:85740 .
URIrefとして完全に展開した場合の述語（predicate）dc:creatorは、Dublin
Coreメタデータ属性セット（詳細は第6.1節で述べている）の「creator」属性への明白な参照である。Dublin Coreメタデータ属性セットは、様々な情報を記述するために広く使用されている属性のセットである。 このトリプルの作者は、(http://www.example.org/index.htmlで識別されている )Webページとページの作者（http://www.example.org/staffid/85740で識別される別個の人物）の関係はまさに、http://purl.org/dc/elements/1.1/creatorで識別される概念であるということを効果的に述べている。また、
http://purl.org/dc/elements/1.1/creator
を理解する誰か、または、いずれかのプログラムは、この関係が意味していることを正確にわかる。
もちろん、URIrefがRDFを使用することで問題がすべて解決するわけではない。その理由は、例えば、未だに同じことを参照するのに異なるURIrefを使用することができるからである。しかし、こういった異なるURIrefは共通にアクセス可能な「Web領域」で使用されるという事実は、別々の参照での同等性を識別したり、一般的な参照を使用する方に移行したりするための機会を作り出す。
こういったことから、RDFは、アプリケーションがより簡単に処理できるステートメントを作成する方法を提供するのである。もちろん、アプリケーションは、現在、そういったステートメントを実際には「理解」できないが、理解できるような方法で処理することができる。例えば、あるユーザが本のレビューのためにWeb検索ができ、各本の平均格付けができた場合。そのユーザはその情報をWebに返すことができる。別のWebサイトでは、本の平均格付けのリストを掲載し、「本のランキング、トップ10」というページを作成できる。そこで、格付けに関する共有ボキャブラリの有用性と使用、そして、適用される本を識別するURIrefの共有グループを使用することによって、（さらに貢献がなされるため）個人個人は双方で理解することができ、ますます強力な本に関する「情報ベース」をWebで構築することができる。毎日Webで何千もの主題について作成されている大量の情報にも同じ原理が応用される。
RDFステートメントは情報を記録するための他の多くの形式と似ている。例えば、
- 簡単な記録でのエントリーやデータ処理システムでリソースを記述するカタログリスト。
- 簡単なリレーショナルデータベースの列。
- 正式な論理での簡単な表明。
そして、こういった形式の情報によって、RDFが多くのソースからのデータをまとめるために使用できるようになり、RDFステートメントとして取り扱うことができる。
2.3
構造化されたプロパティ値と空白のノード
記録しなければならないある事についての情報の種類だけが、これまで説明してきた簡単なRDFステートメントの形式で明らかであれば、それは非常に簡単であるかもしれない。しかし、実際の世界でのデータは、少なくとも表面では、ほとんどそれ以上に複雑な構造を必要とする。例えば、オリジナルの例では、Webページが作成された日付をその値としてのプレーンなリテラルで一つのexterms:creation-dateプロパティ と記録したとする。
exterms:creation-dateプロパティの値、月、日、年を別々の情報の部分として示したいと仮定するか、または、John
Smithの個人情報の場合 John Smithの住所を記録したいと仮定してみる。私たちは、John Smithのアドレスをすべてプレーンなリテラルとして以下の様にトリプルで書くことができる。
exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" .
しかし、Johnの住所をストリート、都市、州、郵便番号の値などの別々のシートで構成されている構造 として記録する場合を仮定してみると？RDFでどうすればいいのだろうか？
（John
Smithの住所などのような）記述したいものの集合をリソースとして考え、新しいリソースについてのステートメントを作成することによって、この構造化された情報をリソースとしてRDFで表現できる。そのため、RDFグラフでは、John Smithの住所を構成要素に分解するため新しいノードを作成してJohn Smithのアドレスの概念を表現し、その概念を新しいURIrefに割り当てて識別を行う。例えば、http://www.example.org/addressid/85740 (略してexaddressid:85740)の場合。 図 5のグラフを作成して、そのノードで（さらにアークとノードを作成する）RDFステートメントを主語（subject）として以下の様に書く。
または、トリプルでは以下の様になる。
exstaff:85740 exterms:address exaddressid:85740 .
exaddressid:85740 exterms:street "1501 Grant Avenue" .
exaddressid:85740 exterms:city "Bedford" .
exaddressid:85740 exterms:state "Massachusetts" .
exaddressid:85740 exterms:Zip "01730" .
この方法を使用すると、構造化された情報をRDFで表現することができるが、Johnの住所などの概念の集合を表現するために「中間の」のURIrefが多く発生する。こういった概念は特定のグラフ外から直接参照する必要はないため、「universal」識別子を必要としない。また、図 5 のステートメントのグループを表現するグラフの作成時には、図 6のグラフのように簡単に作成できるため、「John Smith」の住所を識別するために割り当てているURIrefは実際には必要はない。
完璧なRDFグラフ、図
6では、「John
Smith」の住所という概念を意味するラベルのないノードを使用した。ノード自身はグラフのほかの部分の重要な連結性を提供するため、このラベル付加されていないノード、空白のノードは、URIrefを必要としなくてもグラフ作成時の目的を果たす。（空白のノードは[RDF-MS]では、匿名リソースと呼ばれていた）しかし、このグラフをトリプルとして表現する場合はそのノード用に明示的な識別子の形式がいくつか必要になるかもしれない。これを理解するために、図
6で示しているものに対応するトリプルを書いてみることができる。以下のようなことが得られる。
exstaff:85740 exterms:address ??? .
??? exterms:street "1501 Grant Avenue" .
??? exterms:city "Bedford" .
??? exterms:state "Massachusetts" .
??? exterms:Zip "01730"
???
が空白ノードの存在を示すものを意味する場合。複雑なグラフには複数の空白ノードが含まれるため、グラフのトリプル表現で複数の空白ノードを区別する方法が必要になる。そのためには、_:name形式を持つ空白ノード識別子を使用してトリプルの空白ノードの存在を示す。例えば、この例では、空白ノード識別子_:johnaddress
を使用して空白ノードを参照する。その場合、結果として生じるトリプルは以下のようになる。
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" .
_:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" .
_:johnaddress exterms:Zip "01730" .
グラフのトリプル表現では、グラフの別個の空白ノードには空白ノード識別子が与えられている。URIrefやリテラルと違って、空白のノード識別子はRDFグラフの実際の部分とは考えられない(これは、図
6のグラフを参照したり、空白ノードには空白ノード識別子がないということに注意することによって理解できる）。空白のノード識別子は、グラフがトリプル形式で描かれる場合は、グラフで空白ノードを表現するだけの方法でしかない。また、空白ノード識別子は、一つのグラフを表現するトリプル内でのみ意味を持つ（空白ノードを同じだけ持つ異なる二つグラフでは、独自に同じ空白ノード識別子を使用して区別し、同じ空白ノード識別子を持つ異なるグラフからの空白ノードが同じであると考えることは適切ではない。グラフのノードがグラフ外から参照される必要がある場合、URIrefを割り当ててグラフを識別する必要がある。
本節の初めに、話題にするものをリソースとして考え、その新しいリソースについてのステートメントを作成することによって、John Smithの住所など集合構造を表現できると述べた。本例では、RDFの重要な特徴について説明する。その特徴とは、RDFは2項関係（例えば、John Smithとその住所を表現するリテラルとの間の関係など
項）を表現するということである。Johnとその住所の別々の構成要素との関係を表現しようとする場合、Johnとストリート、市、州、電話番号などの構成要素間のn項 (n方向) 関係（この場合n=5）を取り扱っている。RDFでこういった構造を（例えば、住所をストリート、市、州、郵便番号などのサブ構成要素として考えて）直接表現するには、このn方向関係を別々の2項関係に分解する必要がある。空白のノードは、それを行うための方法を提供する。n項関係がある場合は必ず、その関係の主語（subject）として関係しているものを選ぶことができ（この場合、John）、空白ノードを作成して残りの関係（この場合、Johnの住所）を作成できる。そして、関係の中の残りのもの（この例では、市）を空白ノードで表現されている新しいリソースの別々のプロパティとして表現できる。
また、空白ノードはURIを持たないリソースについて正確にステートメントを作成する方法も提供するが、
URIを有するその他のリソースとの関係に関して記述されるリソースについても同じことが言える。例えば、Jane Smithという人についてのステートメントを作成する場合、 mailto:jane@example.orgなどといったその人のE-mailアドレスを元にURIを使用するのが当然のように思われる。しかし、この方法では、問題がある。例えばJane自身（例、Janeの現在の住所）と同様に彼女のメールボックス（例、メールボックスがあるサーバ）についての情報を記録する場合、E-mailアドレスをもとにJaneのURIrefを使用すると何を述べたいのかがわからなくなる。会社のWebページ、例えば、http://www.example.com/を会社自身のURLとして使用する場合、同じ問題がおきる。繰り返すが、会社についてと同様にWebページ（例、誰がいつ作成したか）についても記録する必要があり、http://www.example.com/をその二つの識別子として使用すると何について述べているかがわからなくなる。
根本的な問題は、JaneのメールボックスをJaneの代わりに使用することは実際は正確ではないということである。つまり、JaneとJaneのメールボックスは同じものではないので、これら二つの識別子も同じではいけない。Jane自身がURIを持たない場合、空白ノードはこの状態を正確に模倣する方法を提供する。私たちは、Janeを空白ノードで表現でき、その値としてURIref mailto:jane@example.orgを持つexterms:mailboxプロパティを空白ノードに入力できる。また、以下のトリプルで示しているように、空白のノードに、exterms:Person（タイプについての詳細は次の節で述べる）の値でプロパティを、"Jane Smith"の値でexterms:nameを、提供するその他の記述情報を割り当てて以下のトリプルのようにもできる。
_:jane exterms:mailbox mailto:jane@example.org .
_:jane rdf:type exterms:Person .
_:jane exterms:name "Jane Smith" .
_:jane exterms:empID "23748"
_:jane exterms:age "26" .
これは、実際には、「タイプexterms:Personのリソースがあり、その電子メールボックスはmailto:jane@example.orgで識別され、その名前はJane
Smithである。など」を示している。つまり、空白ノードは、「リソースがある」と読むことができ、主語（subject）として空白ノードを持つステートメントは、そのリソースの特徴についての情報を提供する。
実際には、こういった事例でURIrefではなく空白ノードを使用してもこの種の情報を正確に処理する方法が変わるわけではない。例えば、（特に、アドレスが再利用さる可能性がない場合に）E-mailアドレスが一意にexample.orgである人を識別するということを知っている場合、そのE-mailアドレスがその人のURIでなくても、複数の情報元からその人に関しての情報を関連付けるため事実を使用できる。例えば、E-mailアドレスが一意にexamle.orgのある人を特定することを知っている場合（特に、アドレスが再使用される可能性がない場合）は、そのE-Mailアドレスがその人のURIでなくても、その事実を使用して複数のソースからその人についての情報を関連づけることができる。
例えば、ある本について述べたWebでRDFの別の部分を検索し、著者の連絡先情報をmailto:jane@example.orgと提供しようとする場合、その著者の名前はJane
Smithだと合理的に判断するかもしれない。ポイントは、「本の著者は、mailto:jane@example.orgである」ということを述べることは、「本の著者は、mailto:jane@example.orgというメールボックスを持つ誰かのことである」ということの短縮形である。空白ノードを使用してこの「誰か」を表現することは、現実世界の状態を表現するより正確な方法なのである。（偶然にもRDFベースのスキーマ言語を使用すると、あるプロパティが一意の識別子であるということを指定できる。これについては第5.5節で述べる。)
2.4 型付き（Typed）リテラル
前節では、プレーンなリテラルで表現されているプロパティ値をとる必要がある場合への対処法とこれらのプロパティ値の個々の部分を識別する構造化された値にプロパティ値を分解する方法を述べた。例えば、Webページが作成された日付を、その値として一つのプレーンなリテラルで一つのexterms:creation-dateプロパティとして記録するといった方法ではなく、この方法をその値として一つのプレーンなリテラルとして使用すると、月、日、年で構成されている値を構造を情報の別々な部分として表現することができる。しかし、プロパティの値を数字（例えば、year
プロパティや
ageプロパティ）やその他、より特殊な値などにするつもりがあったとしても、今まで私たちは、これらのプレーンな（型付きではない）リテラルでRDFステートメント内で目的語 (object) としての役割を果たす一定の値を表現する習慣に従ってきた。
例えば、図
4では、John Smithについての情報を記録しているRDFグラフについて示した。図
7で示しているように、そのグラフでは、John
Smithのexterms:ageプロパティをプレーンなリテラル「27」としてその値を記録した。
この場合、仮の組織、example.orgは、「7」が後に続く「2」という文字で構成された文字列としてではなく、「27」を番号として使用したいと考えている。しかし、リテラル「27」を読み込むアプリケーションは、リテラル「27」が文字を表すいう情報を与えられ、どの番号がリテラル「27」を表す必要があるのかということを理解することになる。プログラミング言語やデータベースシステムで共通の習慣は、データタイプとリテラルを関連づけることによってこの種の情報を提供することである。この場合、データタイプは、decimal
やintegerなど。そして、データタイプを理解するアプリケーションは、例えば、リテラル「10」が数字の10を表すのか、または、、数字2を表すのか、または、「0」が後に続く「1」で構成されている文字列を表すのかは、指定したデータタイプが整数なのか、二進数なのか、文字列なのかで決まる。RDFでは、型付き（typed）リテラルを使用して、この種の情報を提供する。
型付き（typed）リテラルを使用して、 John
Smithの年齢を以下のトリプルを使用して、整数27として記述することができる。
<http://www.example.org/staffid/85740> <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .
または、長いURIを記述するためのQName仕様を使用して以下の様にもできる。
exstaff:85740 exterms:age "27"^^xsd:integer .
または、図
8の様にもできる。
同じ様に、Webページについての情報を示している図
3のグラフでは、そのページのexterms:creation-dateプロパティの値を「August 16, 1999」で記録した。しかし、型付き（typed）リテラルを使用すると、Webページの作成日をトリプルでAugust 16,
1999と記述することができる。
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
または、図
9の様にもできる。
以上の例では、RDFの型付き（typed）リテラルは、特定のデータタイプ（この場合、XML Schema Part 2: Datatypes [XML-SCHEMA2]からのデータタイプ
integerとdate）と表している値を表現するためにデータタイプが使用するリテラルを明示的に組み合わせて形づくられるということを示している。この場合、ラベルとしてその組み合わせを備えているRDFグラフの一つのノードになる。
一般的なプログラミング言語やデータベースシステムと違って、RDFにはそれ自身のデータタイプのセット、例えば、整数、実数、文字列、日付などのデータタイプが組み込まれてはいない。 そのかわり、データタイプ URIで識別できるどこかに定義されているデータタイプに依存する。RDFの型付き（typed）リテラルは、解釈を行うためにどのデータタイプが使用されるべきかを任意のリテラルに対して明示的に示すための方法を示しているだけである。RDFが関係している限り、URIrefとリテラルの一組を型付き（typed）リテラルとして書くことができる。そうすることによって、RDFは異なるソースやRDFデータタイプの元からセット間でタイプの変換を行うことなしに異なるソースからの情報を直接表現できるようになる。（タイプ変換は、異なるデータシステムでシステム間での情報を移動する際に必要であるが、RDFはRDF元来のセットにタイプ変換を行うことはない。）
（表現する値を決定する）型付き（typed）リテラルに関しての実際の解釈は、データタイプを「理解する」ためにプログラムされたRDFプロセッサで行わなければならない。特に、先ほど示した二つの例でXMLスキーマデータタイプを使用し、同様に他の例でもXMLスキーマデータベースを使用するつもりである（例えば、XMLスキーマデータタイプには参照するために使用できるURIrefがある。これは、 [XML-SCHEMA2]で述べている)
。XMLスキーマデータタイプは、RDFでは「第一の」の位置づけがなされており、他のデータタイプと扱いは同じだが、最も広く使用されているため、異なるソフトウエア間でも相互運用ができる可能性が高い。その結果、RDFプロセッサの多くはこれらのタイプを認識するためにプログラムされることになるだろう。しかし、RDFのソフトウエアは同様にデータタイプの他のセットを処理するためにもプログラムできる。
また、RDFデータタイプの概念は、XMLスキーマデータタイプ[XML-SCHEMA2]からの概念的フレームワークを借用してより正確にデータタイプの要件を記述する。このフレームワークのRDFの使用法については、RDF Concepts and Abstract Syntax
[RDF-CONCEPTS]で定義している。
RDFの型付き（typed）リテラルが提供している柔軟性は、かなりの代償となる。例えば、RDFには型付き（typed）リテラルのURIrefが実際にデータタイプを識別しているかどうかを知る方法がない。さらに、URIrefがデータタイプを識別したとしても、RDF自身はそのデータタイプと特定のリテラルの組み合わせの妥当性を定義することはない。この妥当性は、データタイプを理解するために構築されたソフトウェアによってのみ定義できる。例えば、以下のようにトリプルを書くことができる。
exstaff:85740 exterms:age "pumpkin"^^xsd:integer .
または、図 10の様にもできる。
図
10の型付き（typed）リテラルは有効なRDFであるが、「pumpkin」は
xsd:integerとして合法なリテラルであると定義されていないため、xsd:integerデータタイプが関係する限り、これはエラーである。
一般的に、RDFソフトウェアは理解するためにプログラムされたわけではないデータタイプを含むRDFデータを処理するために必要とされることがある。この場合、ソフトウェアが行うことのできないことがいくつかある。それには、特定の文字列が特定のデータタイプに対し合法な値かどうかを認識することが含まれている。この場合、xsd:integerデータタイプを理解するために構築されたわけではないRDFソフトウェアは、「pumpkin」が有効な
xsd:integerであることを認識することはできない。
3.RDFのXMLシンタックス: RDF/XML
第2節で述べたように、RDFのコンセプチュアルモデルは、グラフである。RDFはRDF/XMLというRDFグラフを作成し、交換するためのXMLシンタックスを提供する。省略形として表されるトリプルと違って、RDF/XMLは、RDFを作成するための標準準拠のシンタックスである。RDF/XMLは、RDF/XML Syntax Specification
[RDF-SYNTAX]で定義されている。本節では、このRDF/XMLシンタックスについて述べる。
紹介している例のいくつかを使用して、RDF/XMLシンタックスの基本構想について説明することができる。最初のステートメントのうちの一つを以下の様に表現すると、
http://www.example.org/index.html has a
creation-date whose value is August 16, 1999
URIrefをcreation-dateプロパティに割り当てた後の一つのRDFグラフは、図 11のようになる。
トリプル表現では、以下の様になる。
ex:index.html exterms:creation-date "August 16, 1999" .
例
2では、図
11のグラフに対応するRDF/XMLシンタックスを示している。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.org/terms/">
4. <rdf:Description rdf:about="http://www.example.org/index.html">
5. <exterms:creation-date>August 16, 1999</exterms:creation-date>
6. </rdf:Description>
7. </rdf:RDF>
(例を説明するのに行番号を付けている。)
これは、オーバーヘッドが大きいように思われる。
かわりにこのXMLの各部分を考慮することによって、何が起こるかをより理解できる（付録
BにXMLへの簡単な紹介を述べている)。
1行目の<?xml
version="1.0"?>は、XML宣言であり、以下のコンテンツはXMLであるということと、XMLのバージョンが何かということを述べているある。
2行目では、rdf:RDF要素を開始している。ここでは以下の（ここから始まり、7行目の</rdf:RDF>で終わる)
XMLコンテンツはRDFを表現することを意味する。同じ行のrdf:RDFの後に続くのは、XMLネーム空間宣言で、rdf:RDFスタートタグのxmlns属性として表現されている。この宣言では、rdf:がプリフィックス(接頭辞)についているこのコンテンツのタグはすべてURIref
http://www.w3.org/1999/02/22-rdf-syntax-ns#で識別されているネーム空間の一部であるということを明記している。このネーム空間は、RDF/XMLで使用されているRDF専用の用語のソースである。
3行目では、別のネーム空間宣言を明記している。この場合は、プリフィックス(接頭辞)exterms:。これは rdf:RDF要素の別のxmlns属性として表現されており、ネーム空間URIref
http://www.example.org/terms/は、exterms:プリフィックス(接頭辞)と関連付けるためのものであると指定している。このネーム空間は、例として使用している組織example.orgのが定義している専用の用語である。3行目の末尾の「>」は
rdf:RDFスタートタグの末尾を示している。1行目から3行目は、XMLコンテンツを定義しているということを示し、使用している用語のソースを識別するのに必要な全般的な「ハウスキーピング」である。
4行目から6行目では、表現している特定のステートメントのRDF/XMLを示している。RDFステートメントについて述べるための明確な方法は、これは、description(記述)であり、ステートメントの主題にabout（ついて）のものであり、
(この場合、http://www.example.org/index.htmlについてのものであり）RDF/XMLがステートメントを表現する方法であるということを述べることである。4行目のrdf:Descriptionスタートタグは、リソースのdescription（記述）を開始するということを示しており、ステートメントが主題のリソースのURIrefを指定するためのrdf:about属性を使用している（ステートメントの主題）について のものであるリソースの特定を続けている。5行目では、タグとしてQName
<exterms:creation-date>でproperty
element（プロパティ要素）を示し、ステートメントの作成日プロパティ、プレーンなリテラル August 19,
1999を維持する。これは、
含有rdf:Description要素内にネストされ、このプロパティはrdf:Description要素のrdf:about属性で指定されているリソースに適用ことを示している。QName
<exterms:creation-date>
に対応する作成日プロパティのURIrefは、http://www.example.org/terms/creation-dateを入力し、名前creation-dateをexterms:プリフィックス(接頭辞)(http://www.example.org/terms/)のURIrefに追加することによって取得される。6行目では、この特定のrdf:Description要素の末尾を示している。
最後に7行目は、2行目で開始したrdf:RDF要素の終了を示す。
例 2では、RDFグラフをXML要素、属性、要素コンテンツ、属性値として符号化するためにRDF/XMLで使用されている基本構造を示している。付録
Bで述べているように、プロパティと目的語 (object) ノードのURIrefラベルは、ネーム空間で修飾した要素や属性を示しているローカル名と一緒に、ネーム空間URIを示す短いプリフィックス(接頭辞)で構成されているXML
QNamesとして書き込まれる。(ネーム空間URIrefとローカル名）一組が選択されるので、これらを結びつけるとオリジナルのノードのURIrefができる。主語 (subject)ノードのURIrefは、XML属性値として書き込まれる。（いつも目的語 (object) ノードとなっている）リテラルでラベル付加されているノードは、要素テキストコンテンツまたは属性値となる。(これらのオプションについては、[RDF-SYNTAX])で述べている。
例
2の4行目から6行目と同じRDF/XMLを使用して各要素を別々に表現することによって、複数のステートメントで構成されているRDFグラフをRDF/XMLで表現することができる。例えば、以下の二つのステートメントを書く場合、
ex:index.html exterms:creation-date "August 16, 1999" .
ex:index.html exterms:language "English" .
RDF/XMLを例
3の様に書くことができる。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.org/terms/">
4. <rdf:Description rdf:about="http://www.example.org/index.html">
5. <exterms:creation-date>August 16, 1999</exterms:creation-date>
6. </rdf:Description>
7. <rdf:Description rdf:about="http://www.example.org/index.html">
8. <exterms:language>English</exterms:language>
9. </rdf:Description>
10. </rdf:RDF>
例
3は、7行目や8行目が追加されているだけで、後は例 2と同じである。二番目のrdf:Description要素は二番目のステートメントを表現するものである。追加のステートメント各々に別々のrdf:Description要素を使用して同じ方法で任意の個数追加したステートメントを表現できる。
例
3で示しているように、XMLネーム空間宣言を書き込む手間に取り掛かると、追加でRDFステートメントをRDF/XMLに書き込むことは、簡単になり、そんなに複雑ではなくなる。
RDF/XMLシンタックスでは、たくさんの省略を提供してより書き込みが簡単にできる共通の使用法とする。 例えば、例
3の様に同じリソースを複数のプロパティや値で同時に記述することは普通である。
この場合、リソースex:index.htmlは複数のステートメントの主語 (subject)である。このような場合に対処するため、RDF/XMLは、これらのプロパティを表現する複数のプロパティ要素を主語 (subject)リソースを識別するrdf:Description要素内にネストすることができる。例えば、
http://www.example.org/index.htmlについて以下のステートメントのグループを書く場合、
ex:index.html dc:creator exstaff:85740 .
ex:index.html exterms:creation-date "August 16, 1999" .
ex:index.html exterms:language "English" .
(図
3と) このグラフは、図
12に示す。
RDF/XMLを例
4の様に書くことができる。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:dc="http://purl.org/dc/elements/1.1/"
4. xmlns:exterms="http://www.example.org/terms/">
5. <rdf:Description rdf:about="http://www.example.org/index.html">
6. <exterms:creation-date>August 16, 1999</exterms:creation-date>
7. <exterms:language>English</exterms:language>
8. <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
9. </rdf:Description>
10. </rdf:RDF>
前述の2つの例と比べて、例
4では、ネーム空間宣言（3行目）とcreatorプロパティ要素（8行目）が追加されている。また、主語 (subject)がhttp://www.example.org/index.htmlである三つのプロパティのプロパティ要素を一つの
rdf:Description要素にネストした。rdf:Description要素は、各ステートメントに対して
別のrdf:Description要素を書き込むのではなく、その主語 (subject)を認識する。
また、8行目では、プロパティ要素の新しい形式を導入している。(要素タグは、異なるネーム空間プリフィックス(接頭辞)と3行目で定義している新しいネーム空間プリフィックス(接頭辞)dc:も使用する）7行目のexterms:language要素は例
2で定義しているexterms:creation-date要素と似ている。これら二つの要素は、プロパティをプロパティ値としてプレーンなリテラルで表現し、プロパティ名に相当するスタートタグとエンドタグでリテラルを挟むことによって指定される。しかし、8行目のdc:creator要素は、リテラルではなく別のリソースである値をもつプロパティを表現する。他の要素のリテラル値を書いたのと同じ方法で、このリソースのURIrefをスタートタグとエンドタグの間にプレーンなリテラルで書き込んだ場合、dc:creator要素の値は、URIrefとして解釈されているリテラルで認識されたリソースではなく、文字列
http://www.example.org/staffid/85740であるということを述べていることになるだろう。
この相違点を示すため、XMLが空の要素タグ（エンドタグで区切られていない）を呼び出すものを使用してdc:creator要素を書き、空の要素内でrdf:resource属性を使用してプロパティ値を定義した。rdf:resource属性では、プロパティ要素の値が別のリソースであり、URIref自身で識別されるということを示す。RDF/XMLでは、URIrefが属性値として使用されるため、要素と属性名を書く際に行ったようにQNameとしてURIrefを省略するのではなく、URIrefを書き込むことが必要である。
例
4のRDF/XMLは、省略形であるということを理解することが重要である。 各ステートメントが別々に書かれている例
5のRDF/XMLでは、全く同じRDFグラフを記述している。
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:exterms="http://www.example.org/terms/">
<rdf:Description rdf:about="http://www.example.org/index.html">
<exterms:creation-date>August 16, 1999</exterms:creation-date>
</rdf:Description>
<rdf:Description rdf:about="http://www.example.org/index.html">
<exterms:language>English</exterms:language>
</rdf:Description>
<rdf:Description rdf:about="http://www.example.org/index.html">
<dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
</rdf:Description>
</rdf:RDF>
次の節では、RDF/XMLの省略形をいくつか記述する。しかし、使用できる省略形の記述の詳細は、[RDF-SYNTAX]を参照する必要がある。
また、RDF/XMLを使用すると、空白のノードなどURIrefsを持たないノードを含むグラフを表現することができる。例えば、図
13（から取り出した[RDF-SYNTAX])では、「文書'http://www.w3.org/TR/rdf-syntax-grammar'のタイトルは'RDF/XML
Syntax Specification (Revised)'で、著者が存在し、その著者の名前は'Dave
Beckett'で、ホームページは'http://purl.org/net/dajobe/'である」というグラフを示している。
この図では、第2.3節で述べた構想を説明している。その構想とは、URIrefがないものを表現するが他の情報に関して記述できる空白のノードの使用法である。この場合、空白のノードは人、文書の編集者が表現され、その人は名前やホームページで記述される。
RDF/XMLは、空白ノードを表現する方法をいくつか提供する。この方法は、[RDF-SYNTAX]で述べる。ここで説明するのは（一番直接的な方法である）空白のノードに空白ノード識別子を割り当てる方法である。空白ノード識別子は、特定のRDF/XMLの文書にある空白ノードを識別する役割をするが、URIrefと違って、割り当てられている文書外では不明である。空白ノードは空白ノード現れる場所以外ではRDF/XMLへ参照できる。特に、主語 (subject)として空白ノードをもつステートメントは、rdf:Description要素を使用して
RDF/XMLに書くことができる。
rdf:Description要素は、rdf:about属性ではなくrdf:nodeID
属性を指定する。同じように空白ノードを目的語 (object) として持つステートメントは、rdf:resource属性ではなくrdf:nodeID属性を持つプロパティ要素を使用して書くことができる。rdf:nodeIDを使用して、例
6では、図
13に対応するRDF/XMLを書く。:
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:dc="http://purl.org/dc/elements/1.1/"
4. xmlns:exterms="http://example.org/stuff/1.0/">
5. <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
6. <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
7. <exterms:editor rdf:nodeID="abc"/>
8. </rdf:Description>
9. <rdf:Description rdf:nodeID="abc">
10. <exterms:fullName>Dave Beckett</exterms:fullName>
11. <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>
12. </rdf:Description>
13. </rdf:RDF>
例
6では、空白ノード識別子abcが複数のステートメントの主語 (subject)として9行目に、空白ノードはリソースのexterms:editorプロパティの値である、ということを示すために7行目に使用されている。[RDF-SYNTAX]で述べている方法以外のものに関しての空白ノード識別子を使用する利点とは、同じ空白ノードが同じRDF/XML文書内で複数の場所で参照できることである。
最後に、第2.4節で述べた型付き（typed）リテラルは、これまでの例で使用したプレーンなリテラルの替わりのプロパティ値として使用することができる。型付き（typed）リテラルは、データタイプURIrefを指定するrdf:datatype属性をそのリテラルを含むプロパティ要素に付加することによって、RDF/XMLで表現される。
例えば、例
2からステートメントを変更してcreation-dateプロパティのプレーンなリテラルの替わりに型付き（typed）リテラルを使用するには、
トリプルの表現は以下の様になる。
ex:index.html exterms:creation-date "1999-08-16"^^xsd:date .
のRDF/XMLシンタックスに相当するものは例
7の様になる。:
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.org/terms/">
4. <rdf:Description rdf:about="http://www.example.org/index.html">
5. <exterms:creation-date rdf:datatype=
"http://www.w3.org/2001/XMLSchema#date">1999-08-16
</exterms:creation-date>
6. </rdf:Description>
7. </rdf:RDF>
例
7の5行目では、データタイプを指定するためにrdf:datatype属性を要素のスタートタグに追加することによって、型付き（typed）リテラルは、ex:creation-dateプロパティ要素の値として与えられている。この属性の値はデータタイプのURIrefである。この例の場合、XMLスキーマdateデータタイプのURIref。これは属性値なので、トリプルで使用したQNameの省略形xsd:dateを使用するのではなく、URIrefを書き込まなければならない。そして、このデータタイプに適切なリテラルは要素のコンテンツとして書き込まれる。この例の場合、1999-08-16。これは、XMLスキーマdateデータタイプの1999年8月16日をリテラル表現したものである。
ほとんどの例では、プレーンな
(型付きではない)リテラルの使用を続けているが、XMLスキーマデータタイプなど、適切なデータタイプからの型付き（typed）リテラルはいつもプレーンなリテラルの替わりに使用できるということに注意する必要がある
RDF/XMLを書くための省略形は他にも使用できるが、これまで説明してきた機能はRDF/XMLでグラフをシリアライズするための簡単でより一般的な方法を提供する。この機能を使用して、RDFグラフはRDF/XMLに以下のように書くことができる。
- 空白ノードはすべて空白ノード識別子に割り当てられる。
- ノードはそれぞれ順番にネストされていない
rdf:Description属性の主語 (subject)としてリストされる。ノードにURIrefがある場合はrdf:aboutを使用し、ノードが空白の場合は、rdf:nodeIDを使用する。
主語 (subject)としてノードを持つ各トリプルに対して、リテラル コンテンツ（恐らく空の）か、（目的語 (object) ノードにURIrefがある場合）トリプルの目的語 (object) を指定するrdf:resource属性、か、（目的語 (object) ノードが空白の場合）トリプルの目的語 (object) を指定するrdf:nodeID属性のいずれかを使用して、適切なプロパティ要素が作成される。
[RDF-SYNTAX]で述べているより省略されたシリアライゼーション方法に比べ、このシンプルなシリアライゼーション方法は、実際のグラフ構造のもっとも直接的な表現であり、出力されたRDF/XMLが以降のRDF処理に使用されるアプリケーション様に特に推奨される。
これまで、私達が推測するリソースはすでにURIref与えられているということを述べてきた。例えば、最初の例では、URIrefが
http://www.example.org/index.htmlであるexample.orgのWebページに関する記述的な情報について述べた。完全なURIrefを引用しているrdf:about属性を使用して、このリソースについて触れた。RDFはURIrefがリソースに割り当てられる方法を指定したり、制御したりしないが、URIrefのリソースの組織化されたグループの一部への割り当ての効果を発揮したいと思うときがある。例えば、スポーツ商品の会社example.comがテントやハイキング用のブーツなど自社製品のRDFベースの型カタログをhttp://www.example.com/2002/04/productsで認識される（にある）RDF/XML文書として提供したがっているということを想定する
。そのリソースでは、各製品は別のRDFに与えられる。これらの記述と一緒に、このカタログ、「Overnighter」というテントの型のカタログエントリ、は、例
8で示すようにRDF/XMLで書くことができる。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.com/terms/">
4. <rdf:Description rdf:ID="item10245">
5. <exterms:model>Overnighter</exterms:model>
6. <exterms:sleeps>2</exterms:sleeps>
7. <exterms:weight>2.4</exterms:weight>
8. <exterms:packedSize>14x56</exterms:packedSize>
9. </rdf:Description>
...other product descriptions...
10. </rdf:RDF>
(1行目から3行目、そして、10行目には周囲のxml、RDF、そしてネーム空間の情報が含まれているが、この情報は全カタログ中では一度定義すればよい。カタログの各エントリごとに繰り返し定義しなくてよい。)
例
8は、記述されるリソース（テント）のプロパティ（型、寝るスペース、重さ）を表現する方法において、前回説明した例と似ている。
しかし、4行目では、rdf:Description要素には、rdf:about属性ではなく、rdf:ID属性がある。rdf:IDを使用すると、rdf:ID属性の値で与えられたフラグメント識別子が、記述されているリソースの完全なURIrefの省略形として使用されているということを示すことになる(この場合、item10245。これはexample.comで割り当てられているカタログ番号である）。フラグメント識別子item10245は、基本
URIに関連して解釈される。この場合、含んでいるカタログのURI。テントに関しての完全なURIrefは、（カタログの）基本URIを取り、（後に続くのはフラグメント識別子であると述べるために）#とその後にitem10245を追加し、絶対URIref http://www.example.com/2002/04/products#item10245を与えることによって形成される。
rdf:ID属性は、XMLやHTMLのID属性と幾分か似ている。この中では、定義されている文書（この場合、カタログ）内で一意でなければならないということを定義している。この場合、rdf:ID属性は、名前(item10245)をテントの特定の種類に割り当てられているように見える。このカタログ内の他のRDF/XMLは、rdf:about内の相対URIref
#item10245を使用してテントを参照できる。これは、カタログの基本URIrefに相対する定義されたURIrefであると認識される。
同じ省略形を使用して、
カタログエントリ内（例えば、相対URIrefを直接指定することによって）にrdf:ID="item10245"ではなく、rdf:about="#item10245"を指定することによって、テントのURIrefを与えることができたかもしれない。この二つの方法は、基本的には同義語である。つまり、どちら場合でもRDF/XMLで作成する完全なURIrefは同じhttp://www.example.com/2002/04/products#item10245である、ということである。どちらの場合でも、example.comは、二段階の過程でテントに対しURIrefを与える。最初に全カタログに対し、URIrefを割り当てる、そして、カタログのテントの記述の中で相対URIrefを使用してこの特別な種類のテントを示す。
また、この相対URIrefの使用法は、相対URIrefをRDFから独立してテントに割り当てられた完全なURIreの省略形である、か、または、カタログ内のURIrefのテントへのに割り当てであると考えることができる。
カタログ外にあるRDFは、完全なURIrefを使用して、例えば、絶対URIrefhttp://www.example.com/2002/04/products#item10245を作り、テントの相対URIref #item10245をカタログの基本URIに結びつけることによって、このテントを参照できる。例えば、アウトドアスポーツのWebサイトexampleRatings.comは、RDFを使用して様々なテントの格付けを行うことができる。例
8で示しているテントへの(五つ星)格付けは、例
9のように、exampleRatings.comのWebサイト上で表示することができる。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:sportex="http://www.exampleRatings.com/terms/">
4. <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
5. <sportex:ratingBy>Richard Roe</sportex:ratingBy>
6. <sportex:numberStars>5</sportex:numberStars>
7. </rdf:Description>
8. </rdf:RDF>
例
9では、4行目では、rdf:Description要素と、テントの完全URIrefがその値であるrdf:about属性が使用されている。このURIrefを使用すると、格付けで参照されるテントは正確に認識できる。
これらの例では、いくつかのポイントを説明している。まず、RDFがURIrefのリソース（この場合、カタログのいろいろなテントとその他のアイテム）への割り当て方法を指定したり、制御したりしなくても、一つの文書（この場合、カタログ）をこれらのリソースの記述のソースとして識別する（RDF外の）プロセスとその文書内のリソースの記述における相対URIrefの使用法を組み合わせることによって、RDFでのURIrefのリソースへの割り当ての効果は期待できる。例えば、example.comはこのカタログを、製品のアイテム番号がカタログの中にない場合、その製品はexample.comで周知の製品ではない、という理解のもとに、製品について述べている中心となる情報源として使用することができる。
(RDFは、二つのリソース間に特定の関係が存在することを想定しない。なぜなら、これらのリソースのURIrefは全く同じ基礎を持っているか、似ているからである。この関係はexample.comでは周知だが、RDFでは直接定義はしていないということに注意。）
また、これらの例では、Webの構造上の基本原理を説明している。その原理とは、現行のリソース [BERNERS-LEE98]について、誰もが述べたいことを述べることができる、というものである。さらに、これらの例では、特定のリソースを記述するRDFはすべて一つの場所におく必要はなく、変わりに、Web上に配布されるということも示している。これは、ある組織が他の組織が定義したリソースに格付けをしたり、コメントしたりするような場合にだけ当てはまるものではなく、リソースの最初の定義者（または誰か）が、そのリソースについての詳細を提供することによって、リソースの記述を詳述したい場合などにも当てはまる。このことは、リソースが最初に記述されているRDF文書を変更して、詳細情報を記述するためにプロパティや値を追加したり、この例の様に、別の文書を作り、rdf:aboutを使用してURIref経由でオリジナルのリソースを参照するrdf:Description要素にプロパティや値を追加することによって行うことができる。
上記の協議では、#item10245などのフラグメント識別子は基本URIと関連して解釈される。デフォルトでは、この基本URIはフラグメント識別子が使用されているリソースのURIとなる。しかし、明示的にこの基本URIを指定できるようになることが望ましい場合もある。例えば、http://www.example.com/2002/04/productsにあるカタログに加え、example.orgがミラーサイト、例えば、http://mirror.example.com/2002/04/productsにカタログを複写したいと思う場合、カタログはミラーサイトからアクセスされる場合例に挙げているテントのURIrefは、http://www.example.com/2002/04/products#item10245ではなく、http://mirror.example.com/2002/04/products#item10245が作成され、収容する文書のURIから発生するため、障害が起こる。
そのため、明らかに意図したリソースとは違うものを参照することになる。
その代わり、example.orgは、その場所がベースを定義する一つのソース文書を発行することなく製品のURIrefのセットのために基本URIrefを割り当てたいと思うかもしれない。
そういった場合に対処するため、RDF/XMLは、XML文書が文書のURI以外の基本URIを指定することのできるXML ベース [XML-BASE]に対応している。
例
10では、XMLベースを使用したカタログの定義法を示している。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.com/terms/"
4. xml:base="http://www.example.com/2002/04/products">
5. <rdf:Description rdf:ID="item10245">
6. <exterms:model>Overnighter</exterms:model>
7. <exterms:sleeps>2</exterms:sleeps>
8. <exterms:weight>2.4</exterms:weight>
9. <exterms:packedSize>14x56</exterms:packedSize>
10. </rdf:Description>
...other product descriptions...
11. </rdf:RDF>
例
10では、4行目のxml:base宣言で、rdf:RDF要素（もう一つのxml:base属性が指定されるまで）内のコンテンツ用の基本URIは、http://www.example.com/2002/04/productsであり、そのコンテンツ内で引用されている相対URIrefは、たとえ収容している文書のURIが何であっても、すべてそのベースに相対的だと解釈される。その結果、テント#item10245の相対URIrefは、カタログ文書の実際のURIが何であっても、また、基本URIrefが多少なりとも特定の文書を識別しても、同じ絶対URIrefhttp://www.example.com/2002/04/products#item10245と解釈される。
これまで一製品の記述、example.comのカタログからのテントの特定の型、について述べてきた。しかし、example.comは、バックパックやハイキングブーツなどのような他の製品のカテゴリの複数のインスタンスと同様に、テントの異なる型も提供するだろう。物事を異なる種類や
カテゴリに分類するという考え方は、異なるタイプやクラスを持つ目的語 (object) のプログラミング言語の考え方と似ている。RDFは、あらかじめ定義されているプロパティrdf:typeを提供することによって、この考えに対応している。RDFリソースがrdf:typeプロパティで記述されると、そのプロパティの値は物事のカテゴリやクラスを表現するリソースだと考えられ、そのプロパティの主語 (subject)はそのカテゴリやクラスの
インスタンスであると考えられる。rdf:typeを使用して、例
11では、example.comが、製品の記述がテントの記述であることをどのように述べているかを示している。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.com/terms/"
4. xml:base="http://www.example.com/2002/04/products">
5. <rdf:Description rdf:ID="item10245">
6. <rdf:type rdf:resource="http://www.example.com/terms/Tent" />
7. <exterms:model>Overnighter</exterms:model>
8. <exterms:sleeps>2</exterms:sleeps>
9. <exterms:weight>2.4</exterms:weight>
10. <exterms:packedSize>14x56</exterms:packedSize>
11. </rdf:Description>
...other product descriptions...
12. </rdf:RDF>
例
11では、6行目のrdf:typeプロパティはインスタンスが、URIrefhttp://www.example.com/terms/Tentで識別されたクラスに属していることを示している。この場合、 example.comは（プロパティexterms:weightなどの）他の用語を表記するために使用するのと同じボキャブラリの一部として、そのクラスを記述し、そのため、それを参照するためにクラスの絶対URIrefを使用するということを考えてみる。
RDF自身、例であげているような、Tentなどの物事のアプリケーションン専用のクラスを定義するボキャブラリを定義しない。替わりに、そういったクラスはRDFスキーマで記述される。RDFで有しているアプリケーション専用のクラスやそのプロパティを記述するため機能については、第5節で述べている。DAML+OIL言語やOWL言語などのクラスを記述するための他の機能については、第5.5節で述べている。
特定のタイプやのインスタンスとしてリソースを記述していたり、クラスがかなり共通であるため、RDF/XMLはrdf:typeプロパティを使用してインスタンスの特別な省略形をクラスのメンバーとして提供している。この省略形では、rdf:typeプロパティとその値は削除され、rdf:Description要素が、クラスURIrefに相当するQNameという名前の要素で置き換えられる。また、この省略形を使用して、例
11example.comのテントは、以下の例
12の様に記述される。
1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3. xmlns:exterms="http://www.example.com/terms/"
4. xml:base="http://www.example.com/2002/04/products">
5. <exterms:Tent rdf:ID="item10245">
6. <exterms:model>Overnighter</exterms:model>
7. <exterms:sleeps>2</exterms:sleeps>
8. <exterms:weight>2.4</exterms:weight>
9. <exterms:packedSize>14x56</exterms:packedSize>
10. </exterms:Tent>
...other product descriptions...
11. </rdf:RDF>
例
11と例
12はどちらも、XMLで直接書くことことのできる記述に非常に良く似た方法で、RDFステートメントをRDF/XMLに書き込むことができるということを示している。情報が構造化される方法で大きな変更を行わずにアプリケーションでRDFが使用できることを提案いるため、様々なアプリケーションでXMLの使用が増えているということを考えると、これは、重要な検討材料である。
上記の例では、RDF/XMLシンタックスの背景にある基本構想の一部について説明している。これらの例では、役に立つRDF/XMLを書き始めることができるよう十分な情報提供をしている。他に利用できるRDF/XMLの省略形と同様に、（ストライピングという）XMLでのRDFステートメントのモデリングの背景にある原理の詳細と、XMLでRDFを書き込むことについての詳細とその例に関しては、RDF/XML Syntax Specification [RDF-SYNTAX]を参照のこと。
4. その他RDFの機能
RDFには、リソースやRDFステートメントのグループを表現するための内蔵のタイプやプロパティ、ワールドワイドウェブにRDFを導入する機能などを含む、さらにたくさんの機能がある。
こういった機能については以下の節で述べる。
物事のグループを記述する必要が出てくる。例えば、複数の著者が本を作成したということを述べたり、あるコースの生徒や、パッケージのソフトウェアをリストしたりする場合があるかもしれない。RDFには、そういったグループを記述するために使用できるあらかじめ定義されたタイプやプロパティをいくつかある。
まず、RDには、あらかじめ定義されている三つのタイプ（と数個のあらかじめ定義されている関連のプロパティと一緒に）で構成されるコンテナ言語がある。コンテナとは、物事を含んでいるリソースのことである。含まれているものは、メンバーという。コンテナのメンバーはリソースまたは、リテラルであることができる。RDFは次の三つの種類のコンテナを定義している。
Bag (タイプrdf:Bagを持つリソース)
とは、メンバーの順序が重要ではない場合の複製のメンバーを含むリソースまたは、リテラルのグループのことである。例えば、Bagを使用してパート番号のエントリや処理の順番を重要視しないメンバーのグループを記述するために使用する。
Sequenceまたは、Seq
(タイプrdf:Seqを持つリソース)とは、メンバーの順序が重要である場合の複製メンバーを含むリソースやリテラルのグループのことである。例えば、Sequenceを使用してアルファベット順を維持しなければばらないグループを記述することができる。
Alternativeまたは、Alt (タイプrdf:Altを持つリソース)とは、
代替であるリソースまたは、リテラルのグループのことである(特に、プロパティの一つの値の場合)。例えば、Altを使用して本のタイトルの代替言語の翻訳を記述したり、リソースを検索できる代替のインターネットサイトのリストを記述したりできる。値がAltコンテナとなっているプロパティを使用したアプリケーションは、グループのメンバーのいずれか一つを適切なものとして選択できるということを認識する必要がある。
リソースをこのタイプのコンテナの一つとして記述するには、あらかじめ定義されたリソース、rdf:Bag、rdf:Seq、または、rdf:Alt（どれでもよい）のうちの一つを値とするrdf:typeプロパティを記述する。コンテナリソース(空白ノード、または、URIrefを持つリソース）は、グループを全体として表す。コンテナのメンバーは、コンテナリソースで各メンバーにコンテナメンバーシッププロパティを主語 (subject)として、そのメンバーを目的語 (object) として定義することによって、記述できる。このコンテナメンバーシッププロパティには、rdf:_nの形式の名前がある。nは、0より大きな整数で、0を伴わない。例えば、rdf:_1、rdf_2、rdf_3など。また、nは、特にコンテナのメンバーを記述するために使用される。コンテナメンバーシッププロパティとrdf:typeプロパティに加え、コンテナリソースにもコンテナを記述するプロパティが他にもある。
これらのタイプのコンテナがあらかじめ定義されたRDFタイプやプロパティを使用して記述される一方で、Altのメンバーが代替値などのようなコンテナと関連する特別な意味は、意図した意味であるということを理解することが重要である。これらの特別なコンテナタイプとその定義は物事のグループを記述する必要のある人達の間で共有の慣習を作ることを目的として提供される。RDFはすべて、コンテナの各タイプを記述するためのRDFグラフを作るために使用されるタイプやプロパティを提供する。RDFは、第3.2節で述べているタイプex:Tentのリースに関して理解している位にしか、タイプrdf:Bagのリースに関して理解はしていない。どの場合でも、各タイプに必要な特別な意味に従って動作するようにアプリケーションを書き込まなければならない。この点に関しては、以下の例で展開する。
コンテナの一般的な使用法として、プロパティの値が物事のグループであるということを示すということがある。例えば、「6.001コースにはAmy、Tim、John、Mary、そして、Sueがいる」という文章を表現するには、タイプrdf:Bag（生徒のグループ）のコンテナを値とするs:studentsプロパティを与えることによってコースを記述し、コンテナメンバーシッププロパティを使用し、個々の生徒をそのコンテナのメンバーであるとして、図
14のRDFグラフの様に記述することができる。
この例にあるs:studentsプロパティの値はBagと記述されているため、グラフのプロパティが名前に整数を含んでいても各生徒のURIrefに与えられている順番は重要ではない。それは、メンバーシッププロパティの名前の（明白な）順番を無視することは、rdf:Bagコンテナを含んでいるグラフを作成し、処理するアプリケーションによる。
RDF/XMLには、そういったコンテナをより簡単に記述することのできる特別なシンタックスや省略形がいくつかある。例えば、例
13では、 図
14のグラフについて示す。
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://example.edu/students/vocab#">
<rdf:Description rdf:about="http://example.edu/courses/6.001">
<s:students>
<rdf:Bag>
<rdf:li rdf:resource="http://example.edu/students/Amy"/>
<rdf:li rdf:resource="http://example.edu/students/Tim"/>
<rdf:li rdf:resource="http://example.edu/students/John"/>
<rdf:li rdf:resource="http://example.edu/students/Mary"/>
<rdf:li rdf:resource="http://example.edu/students/Sue"/>
</rdf:Bag>
</s:students>
</rdf:Description>
</rdf:RDF>
例
13では、RDF/XMLはliを各メンバーシッププロパティを明示的に番号をつける必要性を回避するための便利な要素として与えることを示している。
番号をつけたプロパティrdf:_1、rdf:_2、などは、対応するグラフ作成時はli要素から発生する。要素名liは、HTMLからの用語「リスト項目」で ニーモニックとなるよう選択された。また、<s:students>プロパティ要素内での<rdf:Bag>要素の使用にも注意のこと。<rdf:Bag>要素は、
rdf:Description要素とrdf:type要素の両方を一つの要素で置き換えることのできる例
12で使用した省略形の別の例である。URIrefが指定されていないため、Bagは空白ノードである。<s:students>プロパティ要素内でBagをネストすることは、空白ノードがこのプロパティの値であることを示す省略法である。この省略の詳細については [RDF-SYNTAX]で述べている。
rdf:Seqコンテナのグラフの構造と、対応するRDF/XMLは、rdf:Bagのものと似ている (唯一の違いは、タイプrdf:Seqにある)。繰り返すが、rdf:Seqコンテナはシーケンスを記述するためのものであるが、適切に整数値のプロパティ名のシーケンスを解釈するのはグラフを作成し処理するアプリケーションによる。
Altコンテナの図の様に、「X11のソースコードは、ftp.example.org、
ftp.example1.org、または、ftp.example2.orgで参照できる」という文章は、図
15のRDFグラフで表すことができる
例
14では、図
15のグラフがどのようにRDF/XMLで書くことができるかを示す。
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://example.org/packages/vocab#">
<rdf:Description rdf:about="http://example.org/packages/X11">
<s:DistributionSite>
<rdf:Alt>
<rdf:li rdf:resource="ftp://ftp.example.org"/>
<rdf:li rdf:resource="ftp://ftp.example1.org"/>
<rdf:li rdf:resource="ftp://ftp.example2.org"/>
</rdf:Alt>
</s:DistributionSite>
</rdf:Description>
</rdf:RDF>
Altコンテナは、プロパティrdf:_1で識別されているメンバーを少なくとも一つ持つにようにするためのものである。このメンバーは、デフォルト値、または、優先した値として考えられるようにするためのものである。rdf:_1として認識されているメンバー以外、残りの要素の順番は重要ではない。
書いている様に、図
15のRDFでは、単に、s:DistributionSiteのサイトプロパティの値はAltコンテナリソース自身であるとの述べている。別の意味としては、例えば、Altコンテナのメンバーのうちの一つはs:DistributionSiteサイトプロパティの値と考えられる、または、ftp://ftp.example.orgがデフォルトまたは優先された値であるというこのグラフが、特定のプロパティ(この場合、s:DistributionSite）に対して定義された意味にAltがどのような意図で挙動するかということの理解に組み込まれなければならない。そして、アプリケーションからも理解されなければならないということである。
Altコンテナは、言語タグとの連結で頻繁に使用される。例えば、タイトルが複数の言語に翻訳されている著作物には、各言語を持つAltコンテナを指し示すTitleプロパティがある。
BagとAltの意図した意味の違いについては、「ハックルベリーフィン」という本の原作者を考慮して詳細に説明できる。この本の著者は一人だが、二つの名前（マーク・トウェインとサミュエル・クレメンス）を持っている。どちらの名前も著者を指定するのに差し支えないものである。そのため、著者名のAltコンテナを使用すると(二つの別々の著者があることを意味する）Bagを使用するより正確にその関係を表すことができる。
ユーザは、ここで述べている方法を使用するよりも自由にリソースのグループを記述する方法を選択できる。RDFコンテナは、一般的に使用される場合、リソースのグループを含むデータをより相互運用可能にできる共通の定義として単に提供されているだけである。
これらのRDFコンテナタイプを使用するよりもはっきりとした代替がある場合がある。例えば、同じプロパティを使用して最初リソースを複数のステートメントの主語 (subject)にすることによって、特定のリソースと他のリソースのグループとの関係を示すことができる。これは、目的語 (object) が複数のメンバーを含んでいるコンテナである一つのステートメントの主語 (subject)であるリソースとは構造的には同じではない。これらの二つの構造は同じ意味を持つことが時々あるが、そうでない場合もある。任意の状態でどちらを使うかはこれを頭に置いて選択する必要がある。
作者と発行者との関係に関する例として考えると、以下の文章の様になる。:
Sueは、「Anthology of Time」と、「Zoological Reasoning」、「Gravitational
Reflections」を書いた。
この場合、同じ作者が別々に書いた三つのリソースがある。これは、以下の様に繰り返したプロパティを使用して表現できる。
exstaff:Sue exterms:publication ex:AnthologyOfTime .
exstaff:Sue exterms:publication ex:ZoologicalReasoning .
exstaff:Sue exterms:publication ex:GravitationalReflections .
この例では、同じ人が書いたという事以外、発行物の関係を述べてはいない。ステートメントはそれぞれ、独立した事実なので、プロパティを繰り返し使用することは当然の選択である。しかし、このことは、Sueが書いたリソースについてのステートメントとして以下の様に合理的に表現される。
exstaff:Sue exterms:publication _:z
_:z rdf:type rdf:Bag .
_:z rdf:_1 ex:AnthologyOfTime .
_:z rdf:_2 ex:ZoologicalReasoning .
_:z rdf:_3 ex:GravitationalReflections .
逆に、以下の文章
Fred、Wilma、Dinoが所属している議事運営委員会で、決議案が承認された。
では、委員会は全体でその決議を承認したことを述べているが、各委員会のメンバーのそれぞれがその決議に賛成したということを必ずしも述べているわけではない。この場合、この文章を次のように三つのexterms:approvedByステートメント、（その内一つが書く委員会のメンバー）として作成することは、恐らく誤解を招く可能性がある。
ex:resolution exterms:approvedBy ex:Fred .
ex:resolution exterms:approvedBy ex:Wilma .
ex:resolution exterms:approvedBy ex:Dino .
なぜなら、上記のステートメントでは、各メンバーが個々に決議を承認しているからである。
この場合、主語 (subject)が決議、目的語 (object) が委員会自身である 、一つのexterms:approvedBy ステートメントとして、以下のトリプルの様に文章を作成する方が良いだろう。委員会のリソースは、委員会のメンバーがそのメンバーとなっているBagとして以下の様にトリプルで記述することができる。
ex:resolution exterms:approvedBy ex:rulesCommittee
ex:rulesCommittee rdf:type rdf:Bag .
ex:rulesCommittee rdf:_1 ex:Fred .
ex:rulesCommittee rdf:_2 ex:Wilma .
ex:rulesCommittee rdf:_3 ex:Dino .
最後に、プログラミング言語データ構造を構築しているので、これらのRDFコンテナを使用する際は、コンテナを構築しているのではなく、実際に存在するコンテナ（物事のグループ）を記述しているということを理解することが大切である。例えば、上記の議事運営委員会例では、RDFでそのように記述しているかしていないかに関係なく議事運営委員会は、不規則なグループである。値がrdf:Bagである議事運営委員会のリソースrdf:typeプロパティを入力場合は、グループのメンバーを含むための特定のデータ構造を構築しているのではなく、単に議事運営委員会をタイプrdf:Bagのものと関連させる文字を何でも持っているとして記述しているだけである（議事運営委員会は、メンバーをまったく記述していないBagであると示すことができる）。同じように、コンテナ・メンバーシップ・プロパティを使用する場合は、単位コンテナリソースがあるものをメンバーとして持っていると記述しているだけである。メンバーとして記述するものは存在するメンバーだけである、と必ずしも述べる必要は無い。例えば、上記のトリプルを入力して、議事運営委員会ではFred、Wilma、DinoがBagのメンバーであるが、Bagの唯一のメンバーではないと記述する。
第4.1節
で述べたコンテナの制限とは、コンテナをクローズする
方法がないということである。例えば、「これらはコンテナのメンバーすべてである」と述べることなど。なぜなら、一つのグラフでは、メンバーの一部を述べることができるが、その他のメンバーを記述する別のグラフの存在の可能性を排除する方法がないからである。RDFは、指定したメンバーだけを含むグループをRDFコレクションの形で記述することに対応する。RDFコレクションとは、RDFグラフのリスト構造として表現されている物事のグループのことである。このリスト構造はあらかじめ定義されているコレクション・ボキャブラリを使用して構築される。このコレクション・ボキャブラリは、あらかじめ定義されているタイプrdf:List、あらかじめ定義されているプロパティrdf:firstと、rdf:rest、あらかじめ定義されているリソースrdf:nilで構成されている。
このことを説明するために、図16のグラフを使用して「コース6.001の生徒は、Amy、Tim、Johnである」という文章を表現することができる。
s:Amyなどのコレクションのそれぞれのメンバーに関しては、対応するタイプrdf:Listが存在する。このリストリソースは、rdf:first プロパティでコレクションメンバーと、rdf:rest
プロパティでリストの残りとそれぞれリンクしている。リストの終わりは、リソースrdf:nilであるrdf:restプロパティで示している。この構造はLispプログラミング言語を知っている人にはお馴染みのものである。Lispでは、rdf:firstプロパティとrdf:restプロパティでアプリケーションはこの構造をトラバースできる。
RDF/XMLは、コレクションの記述を簡単にする表記を実現する。
RDF/XMLでは、コレクションは、属性rdf:parseType="Collection"を持ち、コレクションのメンバーを表現しているネストされた要素のグループを含む。rdf:parseType="Collection"属性は、囲まれた要素を使用して対応するリスト構造をRDFグラフに作成するということを示している。
これがどう作用するのかを説明するため、図 16のRDF/XMLが例 15のRDFグラフになることを示す。
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://example.edu/students/vocab#">
<rdf:Description rdf:about="http://example.edu/courses/6.001">
<s:students rdf:parseType="Collection">
<rdf:Description rdf:about="http://example.edu/students/Amy"/>
<rdf:Description rdf:about="http://example.edu/students/Tim"/>
<rdf:Description rdf:about="http://example.edu/students/John"/>
</s:students>
</rdf:Description>
</rdf:RDF>
rdf:parseType="Collection" を使用すると、図
16で示しているようなリスト構造の構成を示すことになる。これは、固定された項目の制限されたリストを任意の長さで定義し、rdf:nilで終了し、リスト構造自身に一意である”新しい”空白ノードを使用する。
しかし、RDFはRDFコレクションボキャブラリを使用する特別な方法を強制 しないので、他の方法でこのボキャブラリを使用することができる。
その方法の中にはリストを記述しなくてもよいものもある。例えば、任意のノードにはrdf:firstプロパティの異なる二つの値があることを断言したり、単にコレクションの記述の一部を省略しても違法ではない。
そのため、一般的には、よく構成される構造を必要とするRDFアプリケーションは、完全に強力なものにするため収集ボキャブラリが適切に使用されていることを確認するために作成される必要がある。
RDFアプリケーションは、ステートメントに関するステートメントを作成する必要がある場合がある。例えば、ステートメントがいつ作成されたのか、誰が作成したのか、または、そういった情報などを記録する場合など。
例として、第3.2節で述べたテントについてのステートメントを考える。
product item10245 has a weight whose value is
2.4
トリプル表現では、以下のようになる。
exproducts:item10245 exterms:weight "2.4" .
このステートメントはJohn SmithがRDFで作成した、と述べるとする。RDFでは、リソースについてのステートメントを作成できるので、以下の様にできる。
[[exproducts:item10245 exterms:weight "2.4" .]] dc:creator exstaff:85740 .
つまり、オリジナルのステートメントをリソースに変えることができるので、オリジナルのステートメントをリソースについて述べている別のRDFステートメントの主語 (subject)にすることができる。
RDFは、ステートメントをリソースとしてモデリングする内蔵するボキャブラリを持っている。このモデリングをRDFでの具体化 と言い、ステートメントのモデルをステートメントの具体化と言う。
RDF具体化ボキャブラリは、rdf:Statementタイプと
rdf:subjectプロパティ、rdf:predicateプロパティ、
rdf:objectプロパティで構成されている。このボキャブラリでは、トリプルは以下の形式になる。
foo rdf:type rdf:Statement .
これは、リソースfooは一部のRDFではRDFトリプルであるステートメントであるということである。rdf:subject、rdf:predicate、rdf:objectの三つのプロパティはfooに適用されると、トリプルfoo主語 (subject)コンポーネント、述語 (predicate)コンポーネント、目的語 (object) コンポ-ネントを指定する。
このボキャブラリを使用して、オリジナルのトリプルの具体化は以下の様になる。
exproducts:item10245 exterms:weight "2.4" .
グラフにで記述すると、
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
(最初のトリプルを参照するために表すノード、つまり、具体化の空白ノード
_:xxx は空白ノードでもURIrefのどちらでもよい。）
このような意図された具体化の解釈は、
_:xxx が具体化の主語 (subject)、述語 (predicate)、目的語 (object) で記述されるオリジナルのトリプル（全体的な）への参照として理解される必要があるということである。そのため、具体化を使用すると、以下の様にオリジナルのステートメントがグラフを使用してJohnSmithによって作成されたという事実を表現できる。
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
意図された解釈は、_:xxx が参照するトリプルが同じ主語 (subject)や述語 (predicate)、目的語 (object) を持つ任意のトリプルである、ということではなく、特定のRDF文書のトリプルの特定なインスタンス であるということであるとうことに注意。 同じ主語 (subject)、述語 (predicate)、目的語 (object) を持つトリプルがあるかもしれない。グラフがトリプルのセットだと定義されているが、同じトリプル構造を持つインスタンスの中には、異なる文書で発生するものがある。そのため、これを理解していないと、_:xxxが最初のグラフのトリプルを参照しないが、同じ構造を持つ他のトリプルのいくつかを参照するということが重要になるかもしれない。具体化は（例にあるような）編成日やソース情報などのプロパティを表現するのに使用することを目的としていて、これらのプロパティはトリプルの特定のインスタンスに適用される必要があるため、この特別な具体化の解釈が使用される。
また、具体化されたステートメントを主張することはオリジナルのステートメントを主張することでもないし、その他を意味することでもないということにも注意。それは、Johnがfooについての述べたということを誰かが主張する場合、Johnが述べたのはfoo自身であるということを主張していない。逆に、誰かがfooを主張した場合、その具体化を主張しているのではない。なぜなら、fooを主張することによって述べるつもりのステートメントとしてそういったことが存在すると述べているわけではないからである。
上記では、具体化の表現された解釈についての述べた。その理由は、この解釈は、具体化が使用される際に一般的に使用される解釈であるが、RDF具体化は実際にはこの意味すべてを捉えているわけではないからである。特にRDFシンタックスはそれ自身に、RDFトリプルとその具体化を”結びつける”方法がないからである。以下はそのグラフである。
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
ここでは、実際に「主語 (subject)exproducts:item10245と述語 (predicate)exterms:weight目的語 (object) 2.4があり、Johnが作成したステートメントがある」ということを述べている。(_:xxxが参照している) ステートメントは、特定のRDF文書の特定のいくつかのステートメントと同じであるといういことを述べてはいない。
これを理解するには、オリジナルのトリプルを以下の様に入力する。
exproducts:item10245 exterms:weight "2.4" .
そして、その具体化は、具体化をもつJohnと関連する更なるトリプルと一緒に以下のようになる。
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
_:xxxとオリジナルのトリプルが明示的に関連するものはまったく無いので、これをJohnが作成したと述べることができる。
これは、こういった”由来”の情報がRDFでは表現できないというわけではなく、具体化ボキャブラリと関連する意味のRDFを使用するだけでは表現できないと言う意味である。例えば、RDF文書（例、Webページ）にはURIがあり、そのURIで識別されるリソースについてのステートメントを作成し、こういったステートメントがどの様に解釈されるべきかということについてのアプリケーション依存の理解を元に、まるでステートメントがその文書の中で（平等に適用する）ステートメントすべてをめぐって”紛争”するかの様に作用することができる。また、URIを個々のRDFステートメントに割り当てるための（RDF外に）メカニズムがいくつか存在する場合、認識を行うためのURIを使用してそのステートメントに関するステートメントを確かに作成することができる。
そういった場合、具体化ボキャブラリを使用する必要は全くない。
これを理解するには、オリジナルのトリプルがURIを持つ場合、例えば、ex:statementfoo、Johnへのステートメントはステートメントによるものだと考えることができる。
ex:statementfoo dc:creator exstaff:85740 .
上記では、具体化ボキャブラリを使用していない。
更に、上記の意図された解釈に従って直接的に具体化ボキャブラリを使用することもできるし、特定のトリプルをその具体化に関連付ける方法に関してのアプリケーション依存の理解をすることもできる。しかし、このRDFを受ける他のアプリケーションは、必ずしもこのアプリケーション依存の理解を共有する必要はないので、適切にグラフを解釈する必要もない。
最後に、RDFグラフやグラフのトリプルとトリプルの具体化との間の関係が一対一である必要はないので、具体化で記述されているいくつかのリソースに関するプロパティは、同じコンポーネントを持っていても同じプロパティが他のリソースを適用しているということを述べる必要はない。例えば、以下のグラフについて考えると、
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject exproducts:item10245 .
_:xxx rdf:predicate exterms:weight .
_:xxx rdf:object "2.4" .
_:yyy rdf:type rdf:Statement .
_:yyy rdf:subject exproducts:item10245 .
_:yyy rdf:predicate exterms:weight .
_:yyy rdf:object "2.4" .
_:xxx dc:creator exstaff:85740 .
以下の様にはならない。:
_:yyy dc:creator exstaff:85740 .
第2.3節では、RDFモデルが元来2項関係のみをサポートしているということを述べた。つまり、ステートメントは二つのリソース間の関係を指定すると言うことである。例えば、以下のステートメント
exstaff:85740 exterms:manager exstaff:62345 .
は、「manager」には二人の雇用者がいる（恐らく、一人がもう一人を管理している）ということを述べている。
しかし、RDFでより高い項目の関係（三つ以上のリソース間の関係）を含む情報を表現する必要がある場合がある。これについては第2.3節で述べている。ここでは、Smithとそのアドレス情報の関係を表現することが問題であり、Johnのアドレスの値はその住所のストリート、市、州、郵便番号の構造化された値である。これを関係として書く場合、アドレスは以下の形の5項関係であるということがわかる。
address(exstaff:85740, "1501 Grant Avenue", "Bedford",
"Massachusetts", "01730")
述べる物事の集合（ここでは、Johnのアドレスを表現するコンポーネントのグループ）を別々のリソースとして考え、以下の様にトリプルで新しいリソースについて別々のステートメントを作成することで、こういった構造化された情報をRDFで表現できるということを述べた。
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" .
_:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" .
_:johnaddress exterms:Zip "01730" .
(ここでは、_:johnaddressは Johnのアドレスを表現している空白ノードの空白ノード識別子である。）
これは、n項関係をRDFで表現する一般的な方法である。つまり、参加しているもの（ここではJohn）の一つを選び、オリジナルの関係（ここではaddress）の主語 (subject)として扱う。そして、中間のリソースを選択して残りの関係（URIを割り当てても割り当てなくても）を表現し、その関係の残りのコンポーネントを示す新しいプロパティを与える。
Johnのアドレスの場合、構造化された値の個々の部分をexterms:addressプロパティ「主な」値とは考えられない。すべて等しくその値の原因となる。しかし、他の文脈上の情報を提供する関係や主な値を修飾するその他の情報がある場合の構造化された値の部分の一つが「主な」値として考えられることもある。例えば、第3.2節のテントの例では、プレーンなリテラル「2.4」などとして記述している特定のテントの重さを取り扱っている。
exproduct:item10245 exterms:weight "2.4" .
事実、重さに関するより複雑な記述としては、単に「2.4」ではなく、「2.4キログラム」というのがある。これを述べるには、
exterms:weightプロパティにリテラル「2.4」と測定単位の記述（キログラム）の二つのコンポーネントが存在する必要がある。この場合、リテラル「2.4」は、プロパティの「主な」値と考えることができる。なぜなら、述べていない情報を埋めるためにこの値は文脈の理解に依存し、（上記のトリプルの様に）単に値「2.4」として頻繁に記録されるからである。
RDFモデルでは、この種の修飾されたプロパティ値は、ただ単に他の種類の構造化された値だと考えられる。それを示すには、別のリソースを使用して全体（この場合重さ）として構造化された値を表現し、オリジナルのステートメントを目的語 (object) として取り扱う。その後、構造化された値の個々の部分を表現するリソースプロパティを入力する。この場合、リテラル”2.4”のプロパティと、単位”キログラム”の値が必要である。RDFはあらかじめ定義されているrdf:valueプロパティを提供し構造化された値の主要となる値（もし一つあれば）を記述する。そのため、リテラル”2.4”をrdf:valueプロパティの値として、リソースexunits:kilogramsを
exterms:unitsプロパティとして入力する(リソース
exunits:kilogramsは、example.org スキーマにURIref
http://www.example.org/units/kilogramsで定義されている)。結果として以下のトリプルとなる。
exproduct:item10245 exterms:weight _:weight10245 .
_:weight10245 rdf:value "2.4" .
_:weight10245 exterms:units exunits:kilograms .
RDF/XMLを使用すると 例
16の様に置き換えることができる。
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:exterms="http://www.example.org/terms/">
<rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
<exterms:weight rdf:parseType="Resource">
<rdf:value>2.4</rdf:value>
<exterms:units rdf:resource="http://www.example.org/units/kilograms" />
</exterms:weight>
</rdf:Description>
</rdf:RDF>
(例 16 では、第3節
で紹介していないが、[RDF-SYNTAX]で述べている他のRDF/XMLの省略形を使用している。)
分量を表現するために、異なる分類スキーマやレイティングシステムからの値や主な値をプロパティにに与えるためにrdf:valueプロパティを使用したり、または、別のプロパティを使用して分類スキーマや値を詳しく述べるためにほかの情報を識別したりするのと同様に、測定単位を使用して、同じ方法が使用できる
その目的で、rdf:valueを使用する必要はない（例えば、上記の例のex:amountなど自身のプロパティ名を割り当てることができる）、RDFは、特定の意味とそれを関連付けない。
こういった良くある状況では、rdf:valueは単に便宜上で提供されたものである。
