この標準情報(TR)は, 1999年2月にWorld Wide Web Consortium(W3C)から公表された Resource Description Framework (RDF) Model and Syntax Specification勧告を翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。
WWWは，元来，人間が使用するために構築された。 WWWにおけるすべてのデータは 計算機で読むことができる が， 計算機が理解できる とは限らない。 ウェブ上のすべてを自動化することは非常に困難だが，ウェブが含む情報の量を考えると， 手動で管理することはできない。この規定では，ウェブに含まれるデータを記述するために， メタデータ を使うことを提案する。 メタデータとは，"データについてのデータ"とする。 例えば，図書目録は，出版物について記述しているので，メタデータである。 特にこの規定では，メタデータとは，"ウェブ資源を記述するデータ"とする。 "データ"と"メタデータ"との区別は，絶対的なものではない。 その区別は，特定のアプリケーションによって最初に与えられるが， 同じ資源が同時に両方の方法で解釈されることも少なくない。
資源記述の枠組み(Resource Description Framework，以降RDF)は， メタデータを処理するための基盤とする。 特に，計算機が理解可能なウェブ上の情報を交換するアプリケーションに対して，RDFは， それらの間の相互運用性を提供する。RDFは，ウェブ資源を自動的に処理できる機能を促進する。 例えば，次の様々なアプリケーション領域で使用できる。
| a) | 高機能な検索エンジン機能を提供する 資源の探索。 |
| b) | 特定のウェブサイト，ページ又は電子図書館で使用可能な，内容と内容の関係とを記述する カタログの作成。 |
| c) | 知識共有及び知識交換を促進する 知的ソフトウェアエージェント。 |
| d) | 内容の格付け。 |
| e) | 一つの論理的な"文書"を表現する ページの集まりの記述。 |
| f) | ウェブページの 知的財産権 の記述。 |
| g) | ユーザの プライバシに関する個人の好み の表現。 |
| h) | ウェブサイトの プライバシ保護方策 の表現。 |
この規定では，RDFメタデータを記述するモデルを示し，さらに， 独立に開発されたウェブサーバとクライアントとの相互運用性を最大とする， このメタデータを符号化し転送するための構文を示す。 この規定で示す構文には，拡張可能なマーク付け言語 (Extensible Markup Language，以降XML)[XML]を使用する。 RDFの目的の一つに，XMLに基づいたデータのセマンティクスを， 標準化され相互運用可能な方法で規定することがある。 RDFとXMLとは相補的とする。RDFはメタデータのモデルであって， 転送及びファイル格納で要求される符号化の問題(国際化，文字集合など)の多くは， 参照によって対処するだけとする。これらの問題に対しては，RDFはXMLに依存する。 XMLはRDFの一つの可能な構文でしかなく，同じRDFデータモデルを表現する他の方法が考案されてもよい。 このことを理解しておくことも重要である。
RDFのゴールは広く，それは，特定のアプリケーション領域について仮定せず， どんなアプリケーション領域のセマンティクスをも(あらかじめ)定義せずに， 資源を記述する機構を定義することにある。 この機構の定義は，アプリケーション領域に依存しないが， 任意の領域の情報を記述するのに適していることが望ましい。
この規定に続いて，この枠組みを補う他の規定が作成されることになっている。 最も重要なことは，メタデータの定義を容易にするために， 多くのオブジェクト指向プログラミング及びモデル化システムと同様に， クラスシステムをもたせようとしていることにある。 (通常は特定の目的又は領域のために書かれた)クラスの集まりを スキーマ という。 クラスは階層的に組織化され，下位クラスへの洗練によって拡張可能性を提供する。 これによって，既存のスキーマから少しだけ違ったスキーマを生成するために， "車輪を再発明する"必要は無くなる。 基底スキーマに増加的修正を与えるだけでよい。 スキーマの共有可能性によって，RDFは，メタデータ定義の再利用性をサポートする。 RDFの増加的拡張可能性のために，メタデータを処理するエージェントは， 未知のスキーマの出所を追跡し，既知のスキーマにたどり着き， メタデータの意味のある動作が元来は処理する設計がされていなくても， その動作を実行できる。 RDFの共有可能性及び拡張可能性によって，メタデータの著者は， 他者によってなされた仕事をもとに， 多重継承を使用して，定義を"混合"したり， そのデータに複数のビューを与えたりできる。 さらに，複数の情報源からの複数のスキーマに基づいたRDFインスタンスデータを生成すること (すなわち，異なる型のメタデータを"差し挟む"など)ができる。 スキーマそれ自体がRDFで定義されていてもよい。この規定と対になる規定 [RDFSchema]は， RDFスキーマを記述するための特性及びクラスの組みを示す。
多くの団体が集まってメタデータの表現及び転送の基本原理を合意した結果として， RDFは，次のいくつかの異なる出所からの影響を受けた。
| a) | HTMLメタデータ及びPICSという形で，ウェブ標準化の団体。 |
| b) | 図書館の団体。 |
| c) | SGML及びより重要なXMLという形で，構造化文書の団体 。 |
| d) | 知識表現(Knowledge Representation，以降KR)の団体。 |
RDF設計に貢献したこれ以外の技術領域も存在する。 これには，オブジェクト指向プログラミング， モデル化言語，及びデータベースが含まれる。 RDFは，KRの領域から影響を受けてはいるが，推論 のための機構を規定しないことに， この分野に精通している人は注意。 RDFは，単純なフレームシステムとして特徴付けることができる。 推論機構は，このフレームシステムの上に構築できる。
RDFの基盤は，名前付きの特性及び特性値を表現するためのモデルとする。 RDFモデルは，様々なデータ表現の団体からの十分に確立された原理の上に展開される。 RDF特性は，資源の属性として考えてよく，この意味で，伝統的な属性及び値の対と対応する。 RDF特性は，資源の間の関係も表現する。それゆえ，RDFモデルは，実体関連図に似ている。 より正確には，RDFスキーマがER図であり，RDFスキーマ自体がRDFデータモデルのインスタンスとなる。 オブジェクト指向設計の用語では，資源はオブジェクトに対応し，特性はインスタンス変数に対応する。
RDFデータモデルは，RDF式を表現する構文非依存の方法とする。 データモデルの表現は，意味における等価性を評価するために使用する。 二つのRDF式は，それらのデータモデルの表現が同じ場合に限って，等価とする。 等価性のこの定義によって，意味を変えずに，構文的な式の変形を行うことができる。 文字列比較の問題の付加的な議論については，6. を参照すること。
基本的なデータモデルは，表1の三つのオブジェクト型から構成される。
表1 基本的なデータモデルにおける三つのオブジェクト型 資源 RDF式が記述するすべてのものを，資源 という。 資源は，一つのウェブページ全体，例えば，一つのHTML文書 "http://www.w3.org/Overview.html"，であってよい。 資源は，一つのウェブページの部分，例えば，文書ソース内の特定のHTML要素又はXML要素， であってもよい。 資源は，ページの集まり全体，例えば，一つのウェブサイト全体，であってもよい。 さらに資源は，ウェブ経由では直接にはアクセスできないオブジェクト，例えば， 印刷された本，であってもよい。 資源は，常に，URI([URI]を参照) に付加的なアンカー識別子を追加して名前付けされる。いかなるものもURIをもつことができる。 URIの拡張可能性によって，任意の想像可能な実体に対して，識別子を導入できる。 特性 特性 は，資源を記述するために使用する，固有の様相，特徴，属性又は関係とする。 各特性は，固有の意味をもち，許容値を定義し，特性が記述できる資源の型及び他の特性との関係をもつ。 この文書は，特性の特徴を表現する方法を示さない。 この情報に関しては，RDFスキーマ規定を参照。 文 特定の資源に，名前付けされた特性とその特性の値とを一緒にしたものを， RDF 文 とする。 文におけるこれらの三つの個別部分をそれぞれ， 主語(subject)，述語(predicate) 及び 目的語(object) という。 文の目的語(すなわち特性の値)は，他の資源又はリテラルとすることができる。 すなわち，文の目的語には，(URIで指定される)資源，単純な文字列又は XMLによって定義されるプリミティブなデータ型が可能とする。 RDFの用語では，リテラル は， XMLでマーク付けされた内容をもってもよいが， RDFプロセサがそれ以上は評価しないものとする。 リテラルにおけるマーク付けの表現法に関して，構文的な制限が存在する。 2.2.1を参照。
資源は，資源識別子 によって識別する。 資源識別子は，URIにオプションのアンカー識別子(2.2.1参照) を付加したものとする。2.1.1では，特性を単純な名前によって参照する。
単純な例として，次の自然言語文を考える。
Ora Lassilaは，資源http://www.w3.org/Home/Lassilaの作者(Creator)である。
この自然言語文は，表2に示す部分をもつ。
表2 文の構成部分 主語(資源) http://www.w3.org/Home/Lassila 述語(特性) 作者(Creator) 目的語(リテラル) "Ora Lassila"
この規定では，ラベル付き有向グラフ("節及び弧の図"ともいう。)を使い， RDF文を図として示す。図1では，だ円で示した節は資源を，弧は名前付けされた特性を表現する。 文字列リテラルを表現する節は，長方形で示す。例の自然言語文は，図1のとおりに図示される。
図1 単純な節及び弧の図
備考 矢印の向きは重要である。弧は常に主語から始まり，文の目的語を指す。 この単純な図は，"http://www.w3.org/Home/Lassilaは，作者Ora Lassilaをもつ。"， 又は一般に，"<主語>は，<述語> <目的語>をもつ。" とも読める。
次に，この資源の作者の特徴について何か言いたい場合を考える。例として，次の自然言語文を示す。
名前がOra Lassilaであって，電子メールが<lassila@w3.org>の人は， http://www.w3.org/Home/Lassilaの作者(Creator)である。
この自然言語文の意図は，Creator特性の値を構造化された実体とすることである。 RDFでは，構造化された実体を他の資源として表現する。 例の自然言語文では，その資源の名前は存在せず， 匿名になっている。それで，図2では，空のだ円でこれを表現する。
図2 構造化された値をもつ特性
備考 先の備考の読み方に対応して，図2は，次のとおりに読むことができる。 "http://www.w3.org/Home/Lassilaは，作者(Creator)の 何かをもち， その何か は，名前Ora Lassila及び電子メールlassila@w3.orgをもつ。"
この例の構造化された実体に，一意な識別子を割り当てることもできる。 識別子の選択は，アプリケーションデータベースの設計者が行うことになる。 例を継続して使用するために， "人物"資源に対し，一意な識別子として従業員識別子を使うことを考える。 各従業員に対して一意なキーとしての役をはたす(組織によって定義された)URIが， http://www.w3.org/staffId/85740となっていたとする。 このとき，次の二つの自然言語文を書くことができる。
従業員識別子85740で参照される個人は，Ora Lassilaという名前であって， 電子メールアドレスlassila@w3.orgをもつ。 資源http://www.w3.org/Home/Lassilaは，この個人によって作成された。
これらの自然言語文に対するRDFモデルを，図3に示す。
図3 識別子をもつ構造化された値
図3は，図2の匿名資源に対してURIを追加したものと同等なことに注意。 このモデルを問い合せる他のアプリケーションから見ると， 一つの自然言語文から作成されたRDF文と複数の自然言語文から作成された RDF文との間に違いはない。 しかし，それらを区別することが必要なアプリケーションもあり，RDFは，これをサポートする。 詳細に関しては，4. 文についての文を参照。
RDFデータモデルは，メタデータを定義し使用するための抽象的で概念的な枠組みを提供する。 このメタデータを作成し交換するためには，具象構文も必要となる。 このRDFの規定では，交換用構文として， 拡張可能なマーク付け言語(Extensible Markup Language，以降XML)[XML]符号化を使用する。 RDFは，各特性とその特性を定義するスキーマとを正確に関連付けるために， XML名前空間機能も必要とする。 2.2.3. スキーマ及び名前空間を参照すること。
この規定の構文を記述する場合，本質的なRDF構文要素を記述するために， [XML]の 6. 記法 で定義された拡張Backus-Naur形式(Extended Backus-Naur Form，以降EBNF)記法を使用する。 ただし，この規定では，人間が読みやすいようにEBNFを短縮する。 特に，変更可能な名前空間接頭辞を表現するために， より正確なBNF記法"'<' NSprefix ':...'"の代わりに， イタリック体の"rdf"を使用する。 終了タグの中の特性名及び型名が，対応する開始タグの中の名前と正確にマッチするという要件は， XMLの規則に暗黙的に含まれる。XMLのすべての構文上の柔軟性も，暗黙的に含まれる。 例えば，空白の規則，一重引用符(')又は二重引用符(")のいづれかを使う引用， 文字の別扱い, 大文字・小文字の区別， 言語タグ付けなどを含む。
この規定では，RDFデータモデルのインスタンスを符号化するための二つのXML構文を定義する。 直列化構文 は，大変に整然とした方法で，データモデルの完全な能力を表現する。 短縮構文 は，データモデルの部分集合を表現する， よりコンパクトな形式を提供する付加的な要素を含む。 RDFインタプリタは，完全な直列化構文及び短縮構文の両方を実装することを期待される。 その結果，メタデータの著者は，二つの構文を自由に混合してよい。
一つのRDF文が独立に出現することはほとんどない。 最も一般的なのは，一つの資源の複数の特性がまとまっている場合である。 同じ資源の複数の文をDescription要素へグループ化することによって， 特性をまとめることを容易にするために，RDF XML構文は設計された。 Description要素は，about属性で，各文を適用する対象となる資源に名前を付ける。 資源がまだ存在しない場合(すなわち，資源がまだ資源識別子をもたない場合)には， Description要素は，ID属性を使用して，資源に対する識別子を提供できる。
基本的なRDF直列化構文は，次の形式とする。
[1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
[2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt*
'</rdf:Description>'
[3] idAboutAttr ::= idAttr | aboutAttr
[4] aboutAttr ::= 'about="' URI-reference '"'
[5] idAttr ::= 'ID="' IDsymbol '"'
[6] propertyElt ::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr '/>'
[7] propName ::= Qname
[8] value ::= description | string
[9] resourceAttr ::= 'resource="' URI-reference '"'
[10] Qname ::= [ NSprefix ':' ] name
[11] URI-reference ::= string, ただし，[URI]に従って解釈する
[12] IDsymbol ::= (文法に合った任意のXML名前シンボル)
[13] name ::= (文法に合った任意のXML名前シンボル)
[14] NSprefix ::= (文法に合った任意のXML名前空間接頭辞)
[15] string ::= ("<"，">"及び"&"を別扱いした任意のXMLテキスト)
RDF要素は，XML文書における境界にマークを付ける単純なラッパーであって， その境界の間の内容をRDFデータモデルのインスタンスに対応付けできると意図しているものとする。 アプリケーションの文脈から内容がRDFと分かる場合は，RDF要素はオプションとする。
Descriptionは，モデルインスタンスにおいて文の生成を引き起こす残りの要素を含む。 Description要素は，基本的なRDF構文にとって， 記述される資源の識別を保持する単なる場所と考えてもよい。 通常は，一つ資源に対して複数の文が存在する。 Descriptionは，複数の文に対して，ただ一度だけ資源名を与える方法を提供する。
Descriptionでabout属性を指定する場合は， 識別子がabout属性から決定される資源を， Descriptionの中の文が参照する。 about属性の値は，[URI]の 4.に従ってURI-referenceとして解釈する。 対応する資源識別子は，そのURI-referenceを解決し， [URI]が規定する絶対的な形式とすることによって得られる。 素片識別子がURI-referenceに含まれる場合は， その資源識別子は， 包含資源にとって内部的な対応素片識別子が識別する，その包含資源の部分構成要素だけを参照する ([Dexter94] におけるアンカーを参照)。 それ以外の場合は，識別子は，URIが指定する資源全体を参照する。 about属性をもたないDescription要素は，新しい資源を表現する。 その資源は，認識可能なURIをもたない他の物理的な資源のための，代理又はプロキシであってもよい。 Description要素のID属性の値が存在する場合は，この値は"行内" 資源のアンカー識別子とする。
他のDescription又は特性値が行内資源を参照する必要がある場合は， それ自体のabout属性の値として，その行内資源のIDの値を使用する。 ID属性は新しい資源の生成を示し，about属性は既存の資源を参照する。 それで，ID属性又はabout属性のいずれかを，Descriptionで指定してよいが， 同じ要素の中で両方をいっしょに指定してはならない。 各ID属性に対する値は，一つの文書内では二つ以上のID属性に出現してはならない。
一つのDescriptionは，同じ特性名をもつ二つ以上の propertyElt 要素を含んでもよい。 それらpropertyElt要素の各々は，一つの弧をグラフに追加する。このグラフの解釈は，スキーマ設計者が定義する。
一つのpropertyElt内では，resource属性によって， 他の資源がこの特性の値であることを指定する。 すなわち，この文の目的語は，リテラルではなくて，URIによって指定される他の資源である。 目的語の資源識別子は，about属性と同じ方法で， resouce属性のURI-referenceを解決することによって得られる。 string は，整形式のXMLでなければならない。 その文字列が，"<"及び"&"などの， 整形式規則を乱す文字の並び， 又はマーク付けと紛らわしい文字の並びを含む場合は， 通常のXML内容の引用機構及び別扱い機構を使用してもよい。 特性値が，整形式のXML内容であって，その内容が，RDFではマーク付けとは解釈しない (XMLの)マーク付けを含むことを指定する付加的な構文については， 6.を参照すること。
特性名は，一つのスキーマと関連していなければならない。 これは，特性定義を対応するRDFスキーマにあいまいなく結合するために， 要素名を名前空間接頭辞で修飾することによって行うことができる。 また，[NAMESPACES] に規定されるデフォルト名前空間を宣言することによってもできる。
次は，2.1.1の自然言語文の例である。
Ora Lassilaは，資源http://www.w3.org/Home/Lassilaの作者(Creator)である。
これをRDF/XMLで表現すると次のとおりとなる。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</rdf:Description>
</rdf:RDF>
ここで，名前空間接頭辞 's ' は，このRDF式の著者によって選択された特定の名前空間接頭辞を参照する。 その名前空間接頭辞は，XML名前空間宣言で次のとおりに定義される。
xmlns:s="http://description.org/schema/"
この名前空間宣言は，通常は，rdf:RDF要素のXML属性として含まれるが， 特定のDescription要素又は個々のpropertyElt式の中に含まれてもよい。 名前空間宣言における名前空間名のURIは，特定スキーマに対する大域的に一意な識別子で，このメタデータの著者がCreator特性の使用を定義するために使用している。 他のスキーマがCreatorという名前をもつ(他の)特性を定義する場合は， これら二つのCreator特性をそれらのスキーマ識別子を通じて区別する。 スキーマは，通常はいくつもの特性を定義することにも注意すること。 それで，一つの名前空間宣言だけで，多くの語彙数の特性が利用可能となる。
前述の名前空間宣言の記述を含む完全なXML文書は，次のとおりとなる。
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</rdf:Description>
</rdf:RDF>
[NAMESPACES] で定義するデフォルト名前空間構文を使用して， RDF名前空間自体を記述すると， この文書は次のとおりに書くこともできる。
<?xml version="1.0"?>
<RDF
xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<Description about="http://www.w3.org/Home/Lassila">
<s:Creator>Ora Lassila</s:Creator>
</Description>
</RDF>
さらに，名前空間宣言は，個々のDescription要素又は個々のpropertyElt要素とさえも， 次のとおりに関連させることができる。
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Description about="http://www.w3.org/Home/Lassila">
<s:Creator xmlns:s="http://description.org/schema/">Ora Lassila</s:Creator>
</Description>
</RDF>
XML名前空間宣言は入れ子にしてもよいので，この例は次のとおりに短縮してもよい。
<?xml version="1.0"?>
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Description about="http://www.w3.org/Home/Lassila">
<Creator xmlns="http://description.org/schema/">Ora Lassila</Creator>
</Description>
</RDF>
しかし，RDF/XML符号化を人手で記述したり，簡易テキストエディタで編集する場合は， このかなり短縮した式は好ましくない。 あいまい性はないものの，接頭辞を矛盾なく明示的に使用する場合よりも誤りの可能性が増加する。 RDF/XML素片を他の文書に挿入する意図があるときは，完全に自己完結とするために， 使用するすべての名前空間を宣言するほうがよいことに注意。 2.のこれ以降の例では，読みやすさを考慮し， 説明すべき要点があいまいにならないように，名前空間宣言を省略する。
直列化構文は，RDFモデルの構造を最も明確に示すが，よりコンパクトなXML形式を使うことが望ましい場合も多い。 RDFの 短縮構文 はこれを行う。更なる利点として，短縮構文を使うと， 正しく構造化されたXMLのDTDに従う文書が，RDFモデルとして直接に解釈できる。
基本的な直列化構文に対して，三つの短縮形式を定義する。 最初の短縮形式は，Descriptionの内に特性が繰り返されず，これら特性の値がリテラルの場合に使用できる。 この場合，特性は，Description要素のXML属性として書いてもよい。 2.2.1の例は，次のとおりとなる。
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila" s:Creator="Ora Lassila" /> </rdf:RDF>
Creator特性をXML属性の形式で書いてしまうと，Description要素は他の内容をもたないので， XMLの空要素構文を用い，Description終了タグを省略できることに注意。
これと同じ短縮形式を使用する例を次に示す。
<rdf:RDF>
<rdf:Description about="http://www.w3.org">
<s:Publisher>World Wide Web Consortium</s:Publisher>
<s:Title>W3C Home Page</s:Title>
<s:Date>1998-10-03T02:27</s:Date>
</rdf:Description>
</rdf:RDF>
これは，RDFとしては，(短縮した)次の例と等価となる。
<rdf:RDF>
<rdf:Description about="http://www.w3.org"
s:Publisher="World Wide Web Consortium"
s:Title="W3C Home Page"
s:Date="1998-10-03T02:27"/>
</rdf:RDF>
これら二つのRDF式は等価だが，処理エンジンによって取扱いが異なるかもしれないことに注意。 特に，これら二つの式がHTML文書の中に埋め込まれた場合， RDFを感知しないブラウザのデフォルトの振る舞いは，最初の例では特性値を表示するが， 2番目の例ではテキストを表示しないか，空白文字だけが表示される。
RDF短縮形式の二つ目の形式は，入れ子になったDescription要素に適用される。 この短縮形式が用いられる場合は，文の目的語が他の資源であって， この新たな資源に対して行内で与えられた特性値が文字列であるという 特定の文である。 この場合，XML要素名をXML属性へと変換する，最初の短縮形式と同様の方法を使用する。 すなわち，入れ子になったDescription中の資源の特性は， そのDescriptionを含んでいるpropertyElt要素のXML属性として書いてよい。
次に示す2.1.1の2番目の例を検討する。
従業員識別子85740で参照される個人は，Ora Lassilaという名前であって， 電子メールアドレスlassila@w3.orgをもつ。 資源http://www.w3.org/Home/Lassilaは，この個人によって作成された。
明示的な直列化形式を使用したRDF/XMLでは，この例は次のとおりとなる。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator rdf:resource="http://www.w3.org/staffId/85740"/>
</rdf:Description>
<rdf:Description about="http://www.w3.org/staffId/85740">
<v:Name>Ora Lassila</v:Name>
<v:Email>lassila@w3.org</v:Email>
</rdf:Description>
</rdf:RDF>
この形式では，二つの別の資源が記述されていることは明らかであるが， 2番目の資源が最初の記述の中で使用されていることは，それほど明らかではない。 この関係を人間に対してより明確にするために，これと同じ式を次のとおりに書くことができる。 ただし，機械にとっては違いがないことに注意。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>
<rdf:Description about="http://www.w3.org/staffId/85740">
<v:Name>Ora Lassila</v:Name>
<v:Email>lassila@w3.org</v:Email>
</rdf:Description>
</s:Creator>
</rdf:Description>
</rdf:RDF>
2番目の基本的な短縮構文を使うと，内部のDescription要素及びそれが含む特性の式は， Creator要素の属性として書くことができる。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator rdf:resource="http://www.w3.org/staffId/85740"
v:Name="Ora Lassila"
v:Email="lassila@w3.org" />
</rdf:Description>
</rdf:RDF>
この短縮形式を使う場合は，入れ子にされたDescription要素のabout属性が， propertyElt要素のresource属性になる。これは，URIによって名前を付けられた資源が， (先の二つの例の)どちらの場合でもCreator特性の値であることによる。 これら三つの形式のいずれをRDFソースの中で使用するかは，完全に記述者の好みの問題である。 これらはすべて，内部的には同じRDFモデルを生成する。
備考 この規定の残りを検討した注意深い読者は， Description要素が表現する付加的な関係があり，それが文の構文上のグルー プ化を保持していることに気付くだろう。 その結果として，2.の議論では重要でなかった点において，前述の三つの形式は微妙に異なっている。 この違いは，4.で示す高次の文を作る場合にだけ重要となる。
3番目の基本的な短縮構文は，Description要素がtype特性(typeの意味については 4.1を参照)を含むというよくある場合に適用される。 この場合は，type特性の値に対応する，スキーマの中で定義された資源の型を， 要素の名前として直接に使用できる。例えば，先に例として挙げたRDFの素片を使って， 資源http://www.w3.org/staffId/85740が Personのインスタンスを表現するという事実を付け加えたいと思う場合， これを完全な直列化構文では，次のとおりに書く。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>
<rdf:Description about="http://www.w3.org/staffId/85740">
<rdf:type resource="http://description.org/schema/Person"/>
<v:Name>Ora Lassila</v:Name>
<v:Email>lassila@w3.org</v:Email>
</rdf:Description>
</s:Creator>
</rdf:Description>
</rdf:RDF>
3番目の短縮形式を使うと，次のとおりとなる。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<s:Creator>
<s:Person about="http://www.w3.org/staffId/85740">
<v:Name>Ora Lassila</v:Name>
<v:Email>lassila@w3.org</v:Email>
</s:Person>
</s:Creator>
</rdf:Description>
</rdf:RDF>
基本的な短縮構文のためのEBNFは，基本的な直列化構文に対する文法の生成規則[2]及び[6]を， 次のとおりに置き換える。
[2a] description ::= '<rdf:Description' idAboutAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6a] propertyElt ::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr? propAttr* '/>'
[16] propAttr ::= propName '="' string '"'
(with embedded quotes escaped)
[17] typedNode ::= '<' typeName idAboutAttr? propAttr* '/>'
| '<' typeName idAboutAttr? propAttr* '>'
property* '</' typeName '>'
自然言語で文を書く場合，何らかの意味を伝えることを意図する言葉を使う。 意味は，その文を理解するために非常に重要だが，RDFのアプリケーションの場合には， 意味は，正しい処理が意図したものと同じになることを確証するために非常に重要となる。 文の著者及び読者の両方が，Creator，approvedBy，Copyright などの用語を同じ意味に理解することが，非常に重要となる。 そうでなければ，混乱が生じてしまう。WWWなどの大域的なメディアでは， "creatorship(作成者であること)"などの概念を共有の文化的理解に頼るのでは十分でない。 可能な限り厳密なほうが有益である。
RDFにおける意味は， スキーマ を参照することを通じて表現される。 スキーマとは，ある種の辞書と考えることができる。スキーマは，RDF文で使用する用語を定義し， それら用語に特定の意味を与える。スキーマの様々な形式がRDFで使用できる。 この形式の一つに，独立の文書 [RDFSchema]で定義される特別の形式があり， RDFを使った作業の自動化を支援するある特別の特徴をもつ。
スキーマは，特性の用法に関する定義及び制限を文書化する場所とする。 同じ用語の独立した，そして衝突を起こす可能性のある，複数の定義の間での混同を避けるために， RDFは，XMLの名前空間機能を使う。名前空間は，単に，文脈中における言葉の特定の用法を， 意図した定義を見出せる辞書(スキーマ)に結び付ける方法とする。 RDFでは，文の中で使用する各述語は，ちょうど一つの名前空間， すなわちスキーマ，で識別されなければならない。 しかし，Description要素は，述語が多くのスキーマから由来する文を含んでもよい。 一つ以上のスキーマを使用するRDF Description 要素の例を，7.に示す。
特性値は，その値の"一部"と考えられる付加的な文脈情報をもつことが多い。 言い換えると，特性値を修飾することが必要である。修飾の例に，計測単位の名前付け， 特定の制限された語彙又はその他の注記がある。特性値を修飾子なしに使用するのが適切な場合もある。 例えば，"その鉛筆の値段は75USドルである。"という文は， 単に，"その鉛筆の値段は75である。"と言えば十分な場合が多い。
RDFモデルでは，修飾された特性値は，単に，ある構造化された値の他のインスタンスとする。 元の文の目的語がこの構造化された値であり，更に，修飾子はこの共通資源(目的語)の特性である。 修飾されているおおもとの値は，この共通資源の value 特性の値として与えられる。 value 特性の使用例は，7.3 3項以上の関係を参照すること。
複数の人々が作品を作成したことを述べる，課程を履修している学生のリストを示す， パッケージ中のソフトウェアモジュールのリストを示すなど， 資源の集まりを参照する必要がある場合が多い。RDFのコンテナは， 資源又はリテラルのリストを保持するために使用する。
RDFは，表3に示す，三つの型のコンテナオブジェクトを定義する。
備考 Bag 及び Sequence の定義は，重複値を明示的に許可する。 RDFは，重複値をもたない Bag である Set(集合) の概念を定義しない。 これは，RDFコアがこの(重複をもたないという) 制約に違反した場合の強制機構を必すとしないことによる。 RDFコアの上位層における将来の作業では，この機能を定義するかもしれない。
資源の集まりを表現するために，RDFは，特定の集まり(オブジェクトモデル化の用語では，集まりの インスタンス という)を識別する 付加的な資源を利用する。 この資源は，表3で定義されたコンテナオブジェクト型の一つのインスタンスと宣言しなければならない。 4. 文についての文で定義する type 特性を，この宣言を行うために使用する。 このコンテナ資源とその集まりに属する資源との所属関係は， この目的のために明確に定義された特性の集合によって定義される。 これらの所属関係特性は， 単純に，"_1"，"_2"，"_3"などと名前付けされる。 コンテナ資源は，所属関係特性及び type 特性のほかに，他の特性をもってもよい。 これらの付加的な文はいずれもコンテナを記述する。 各メンバ自体に関する文については，3.3 分散的指示対象 を参照すること。
コンテナは，特性値として一般に使用する。この方法で使用する場合は， コンテナ中のメンバの数に関係なく，文は一つの目的語をもつ。すなわち，コンテナ資源自体が， 文の目的語となる。
例えば，次の自然言語文を表現することを考える。
課程6.001の履修学生は，Amy，Tim，John，Mary及びSueである。
このRDFモデルは，図4のとおりとなる。
図4 単純なBagコンテナ
Bagコンテナは，同じ型の特性を繰り返したものと等価でない。 この違いに関しては，3.5を参照すること。 RDF文の著者は，(特性を繰り返す文又はBagの)どちらを使用するのがより適切かを， 1 件ずつ慎重に決定する必要がある。
さらに，次の自然言語文を考える。
X11のソースコードは，ftp.x.org，ftp.cs.purdue.edu又はftp.eu.netで見つけられる。
この文は，RDFでは図5のとおりにモデル化される。
図5 単純なAlternativeコンテナ
Alternativeコンテナは，言語タグ付けと連携して使用することが多い。 作品のタイトルが複数の言語に翻訳されている場合，その作品は， それぞれの言語のタイトルを収納するAlternativeコンテナを指すTitle特性をもつかもしれない。
RDFコンテナ構文の形式を，次に示す。
[18] container ::= sequence | bag | alternative [19] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' [20] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' [21] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' [22] member ::= referencedItem | inlineItem [23] referencedItem ::= '<rdf:li' resourceAttr '/>' [24] inlineItem ::= '<rdf:li>' value '</rdf:li>'
コンテナは，Descriptionが許される任意の場所で使用してよい。
[1a] RDF ::= '<rdf:RDF>' obj* '</rdf:RDF>' [8a] value ::= obj | string [25] obj ::= description | container
RDF/XMLは，各メンバを明示的に番号付けなければならないことを避けるために， 簡便な要素としてliを使用する。li要素は，必要に応じて， 特性_1，_2などが割り当てられる。要素名liは， HTMLの用語"リスト項目(list item)" のニーモニックであるために選択された。
Altコンテナ(Alternativeコンテナのこと)は，少なくとも一つのメンバをもつことが要求される。 このメンバは，特性_1によって識別され，デフォルト値又は好ましい値とする。
備考 RDFスキーマ規定[RDFSCHEMA]では， これらのコンテナ型の付加的な下位クラスを宣言する機構も定義する。 それで，生成規則[18]は，それらの宣言された下位クラスの名前を含むために拡張される。 属性形式でリテラル値を書くための構文も存在する。 6.の完全な文法を参照すること。
次の自然言語文を例として示す。
課程6.001の履修学生は，Amy，Tim，John，Mary及びSueである。
このモデルは，RDF/XMLでは次のとおりになる。
<rdf:RDF>
<rdf:Description about="http://mycollege.edu/courses/6.001">
<s:students>
<rdf:Bag>
<rdf:li resource="http://mycollege.edu/students/Amy"/>
<rdf:li resource="http://mycollege.edu/students/Tim"/>
<rdf:li resource="http://mycollege.edu/students/John"/>
<rdf:li resource="http://mycollege.edu/students/Mary"/>
<rdf:li resource="http://mycollege.edu/students/Sue"/>
</rdf:Bag>
</s:students>
</rdf:Description>
</rdf:RDF>
この場合，students特性の値はBagとして表現されているので， 各学生のURIに対してここで与えられた順序は重要でない。
次に，他の例を示す。
X11のソースコードは，ftp.x.org，ftp.cs.purdue.edu又はftp.eu.netで見つけられる。
このモデルは，RDF/XMLでは次のとおりとなる。
<rdf:RDF>
<rdf:Description about="http://x.org/packages/X11">
<s:DistributionSite>
<rdf:Alt>
<rdf:li resource="ftp://ftp.x.org"/>
<rdf:li resource="ftp://ftp.cs.purdue.edu"/>
<rdf:li resource="ftp://ftp.eu.net"/>
</rdf:Alt>
</s:DistributionSite>
</rdf:Description>
</rdf:RDF>
ここで，DistributionSiteに対するコンテナ値の中にリストされた項目のどれか一つが， 他の項目とは関係なく，受理可能な値となる。
コンテナ構造によって，文についての問題が生じる。すなわち，ある集まりを参照する文を作成する場合， その文はいかなる"もの"を記述するのか？ 換言すれば，その文はいかなるオブジェクトを参照しているのか？ その文は，コンテナ自体を記述しているのか？ 又は，コンテナのメンバを記述しているのか？ (XML構文でabout属性によって示される)このオブジェクトを， RDFでは 指示対象 と呼ぶ。
次に例を示す。
<rdf:Bag ID="pages"> <rdf:li resource="http://foo.org/foo.html" /> <rdf:li resource="http://bar.org/bar.html" /> </rdf:Bag> <rdf:Description about="#pages"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
これは，"Ora Lassila"がBag "pages"の作者であることを表現する。 しかし，個々のページ，つまりそのBagのメンバについては何も述べていない。 Descriptionの指示対象は，コンテナ(Bag)であって，そのメンバではない。 コンテナ自体の代わりに，その中に含まれる各オブジェクトについての文を個々に書きたいときもあるだろう。 "Ora Lassila"が各ページの作者であることを表現するためには， コンテナのメンバ上に分散する異なる種類の指示対象を必要とする。 RDFでは，この指示対象は，aboutEach特性を使って，次のとおりに表現する。
[3a] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [26] aboutEachAttr ::= 'aboutEach="' URI-reference '"'
例えば，次のとおり書けば，望む意味が得られる。
<rdf:Description aboutEach="#pages"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
この新しい指示対象の型を 分散的指示対象 と呼ぶ。分散的指示対象によって， RDF Descriptionで"構造を共有する"ことが可能となる。 例えば，共通な文の部分(述語及び目的語)を多くもつ， 複数のDescriptionを書く場合には， 共通の部分は，すべてのDescriptionの間で共有できる。 この結果として，場所を節約でき， 維持管理がより容易なメタデータとなりうる。aboutEach属性の値は， コンテナでなければならない。コンテナ上で分散的指示対象を使うことは， 各メンバについての文を別々に作ることと同じとする。
分散的指示対象の明示的なグラフ表現は定義しない。その代わり，作成された文の面では， 分散的指示対象は，コンテナの各メンバが個別の文へと展開される。 すべての文を個々に作成したものと同様に，問合せ機能が機能する限り， 例えば，場所を節約するために， 分散的指示対象についての情報を保持することは，実装の自由とする。 従って，上の例は，資源"foo"及び"bar"に関して， 次と等価となる。
<rdf:Description about="http://foo.org/foo.html"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description> <rdf:Description about="http://bar.org/bar.html"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
"私のウェブサイトにおける全ページ"， "私のウェブサイトのこの分岐におけるすべてのページ" などについての文を作るために，メタデータは非常によく使用される。 それらの資源のリストを明示的に作り，各資源をコンテナのメンバとして識別しようと試みることは， 実行可能ではないし，望ましくさえない場合が多い。それで，RDFには，2番目の分散的指示対象の型がある。 この2番目の分散的指示対象は，Bagのインスタンスを表現する構文の簡略形であり，そのBagのメンバは， 定義によって，指定された文字列で開始する資源識別子をもつすべての資源である。
[26a] aboutEachAttr ::= 'aboutEach="' URI-reference '"'
| 'aboutEachPrefix="' string '"'
aboutEachPrefix属性の値として指定された文字列で始まり，完全に解決した資源識別子に対して， それらによって示される資源をすべてのメンバとするBagが存在することを， aboutEachPrefix属性は宣言する。 aboutEachPrefix属性をもつDescriptionの中の文は， このBagの各メンバに個々に適用される。
例えば，二つの資源http://foo.org/doc/page1及びhttp://foo.org/doc/page2が存在する場合， 次のとおりに書くことによって，それらの各々がCopyright特性をもつことを表現できる。
<rdf:Description aboutEachPrefix="http://foo.org/doc"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description>
aboutEachPrefix属性における文字列で開始するURIが先の二つの資源だけの場合， これは，次の書換えと等価となる。
<rdf:Description about="http://foo.org/doc/page1"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Description about="http://foo.org/doc/page2"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description>
また，これは次の書換えとも等価となる。
<rdf:Description aboutEach="#docpages"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Bag ID="docpages"> <rdf:li resource="http://foo.org/doc/page1"/> <rdf:li resource="http://foo.org/doc/page2"/> </rdf:Bag>
資源は，同じ述語をもつ(すなわち，同じ特性を使用する)複数の文をもってもよい。 これは，複数のメンバを含むコンテナを目的語とする一つの文をもつことと同じではない。 特定の状況でどちらを使用するかの選択は，ある部分はスキーマを設計する者によって， ある部分は特定のRDF文を書く者によって，行われる。
例として，著者とその出版物との関係を考える。 次の自然言語文を例として示す。
Sueは，"Anthology of Time"，"Zoological Reasoning"， "Gravitational Reflections"を書いた。
すなわち，同じ著者が別々に書いた三つの資源が存在する。
図6 繰返し特性
この例では，出版物が同じ人間によって書かれたという以外の関係は述べられていない。
一方，次の自然言語文を考える。
Fred，Wilma及びDinoからなる委員会は，その決議を承認した。
この文は，委員会の三人のメンバがまとまって，ある方法で票決したことを述べている。 すなわち，必ずしも，委員会のメンバそれぞれがその条項に賛成の投票をしたということではない。 この文を，委員会の各メンバに対して一つずつ， 三つの別々のapprovedBy文としてモデル化することは誤りとなる。 個々のメンバの投票を示すからである。 むしろ，この文は，委員会メンバを識別するものを含むBagを目的語とする一つの approvedBy文としてモデル化したほうがよい。
図7 団体の意見を示すためのBagの使用
Bag又は繰返し特性のどちらを使用するかの選択は，スキーマを検討した後でメタデータを作成する人間が行う。 例えば，出版物の例で，出版物の完全な集合があることを述べたい場合は，その目的のために， publications という特性をスキーマに含めるかもしれない。 publications 特性の値は，Sueの著作物すべてをリストするBagとする。
ウェブ資源について記述した文を作ることに加えて，RDFは， 他のRDF文についての文を作るために使用できる。 これを，高次の文 と呼ぶ。他の文についての文を作るためには， 実は，元の文のモデルを構築しなければならない。 このモデルは，付加的な特性を付け加えることができる新しい資源である。
文は，資源について記述するために作成される。文のモデルは，そのモデル化された文についての新しい文 (高次の文)を作成可能とするために必要な資源とする。
例えば，次の自然言語文を考える。
Ora Lassilaは，資源http://www.w3.org/Home/Lassilaの作者である。
RDFは，この文を一つの事実とみなす。この代わりに，例えば，次の文を書くとする。
Ralph Swickが，Ora Lassilaは資源http://www.w3.org/Home/Lassilaの作者である，と言う。
この場合は，資源http://www.w3.org/Home/Lassilaについては何も言っていない。 代わりに，Ralphが作成した文についての事実を表現している。この事実をRDFで表現するためには， 元の文を四つの特性をもつ資源としてモデル化しなければならない。 この処理は，正式には，知識表現の分野で 具体化 (reification) と呼ばれている。 文のモデルを，具体化された文 と呼ぶ。
文をモデル化するために，RDFは，表4の特性を定義する。
表4 文のモデル化用の特性 subject(主語) subject(主語) 特性は，モデル化された文が記述する資源を識別する。 すなわち，subject 特性の値は，元の文が作成対象とした資源 (例では，http://www.w3.org/Home/Lassila)とする。 predicate(述語) predicate(述語) 特性は，モデル化された文における元の特性を識別する。 predicate 特性の値は，元の文で特定された特性を表現する資源(例では，作者)とする。 object(目的語) object(目的語)特性は，モデル化された文における特性値を識別する。 object特性の値は，元の文における目的語(例では，"Ora Lassila")とする。 type(型) type(型)特性の値は，新しい資源の型を記述する。すべての具体化された文は， RDF:Statementのインスタンスとする。すなわち，具体化された文は， type 特性をもち，その目的語はRDF:Statementである。また，type 特性は， 3. "コンテナ"で示すとおり， 任意の資源の型を宣言するために，より一般的に使用される。
表4の四つの特性をもつ新しい資源は，元の文を表現し，他の文の目的語として使用したり， その資源についての付加的な文を作成することもできる。これら四つの特性をもつ資源は， 元の文の置換ではなく，その文のモデルとする。文及びそれに対応する具体化された文は， RDFグラフにおいて独立に存在し，それぞれは他方なしに存在してよい。 RDFグラフは，対応する具体化された文が存在するかどうかに関わらず，文がそのグラフに存在する場合にだけ， 文が与える事実を含むという。
例をモデル化するために， 適切な値(この場合は"Ralph Swick")をもつ他の特性(例えば"attributedTo")を具体化された文に付加できる。 基本的なRDF/XML構文を使うと，これは次のとおりに書くことができる。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:a="http://description.org/schema/">
<rdf:Description>
<rdf:subject resource="http://www.w3.org/Home/Lassila" />
<rdf:predicate resource="http://description.org/schema/Creator" />
<rdf:object>Ora Lassila</rdf:object>
<rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<a:attributedTo>Ralph Swick</a:attributedTo>
</rdf:Description>
</rdf:RDF>
図8は，グラフ形式でこれを表現する。構文的には，これはむしろ冗長である。 4.2に，文についての文を作るための簡略形を示す。
図8 具体化された文の表現
具体化は，Description要素が暗黙的に含む文のグループ化を， モデルにおいて明示的に表現するためにも必要となる。 RDFグラフモデルは，Descriptionのための特別な構成要素を必要としない。 実際，Descriptionは文の集まりなので，文の集合が(構文的に)同じ Descriptionに由来することを示すために，Bagコンテナを使用する。 Description内の各文は具体化され，具体化された文は，それぞれ， そのDescriptionを表現するBagのメンバとなる。その例を，次に示す。
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila" bagID="D_001">
<s:Creator>Ora Lassila</s:Creator>
<s:Title>Ora's Home Page</s:Title>
</rdf:Description>
</rdf:RDF>
このRDF素片は，図9で示すグラフとなる。
図9 文のグループ化を表現するためのBagの使用
新しい属性bagIDに注意。この属性は，コンテナ資源の資源識別子を指定する。 この構文を，次に示す。
[2b] description ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
[27] bagIDAttr ::= 'bagID="' IDsymbol '"'
bagIDとIDとを混同するのは望ましくない。 IDは，Descriptionにおいて特性を更に詳細化する行内資源の識別性を指定する。 bagIDは，他の資源についての具体化された文をメンバとするコンテナ資源の識別性を指定する。 Descriptionは，ID属性及びbagID属性の両方をもってもよい。
DescriptionにbagIDを付加することによって， そのDescriptionの具体化された文をメンバとするBagがモデルの中に含まれるので， 文についての文を作る場合に，これを構文の簡略形として使用できる。 例えば，Ralphは，Oraがhttp://www.w3.org/Home/Lassilaの作者であると述べており， また，彼は，その資源の題名が"Ora's Home Page"であると述べていることを言いたい場合， 単に，4.1の例に，次を追加すればよい。
<rdf:Description aboutEach="#D_001"> <a:attributedTo>Ralph Swick</a:attributedTo> </rdf:Description>
この簡略形の例は，図9の例で表現されていない付加的な事実をモデルに含めていることに注意。 この簡略形の利用法では，Ralphの文についての事実を表現するだけでなく， Oraのホームページについての事実も表現している。
図10 文についての文の表現
高次の文及び具体化のより形式的な取扱いについては，この規定の5. RDFのための形式モデル を参照すること。
この規定は，データモデルの三つの表現，すなわち，三つ組(トリプル)，グラフ及びXMLの各表現を示す。 これらの表現は等価な意味をもつ。この規定で使用する表現の間の対応付けは，いかなる点でも， 実装が使用する内部表現に制約を与えることを意図しない。
RDFデータモデルは，形式的には，次のとおりに定義する。
文( Statements のメンバ)の集合を，ラベル付き有向グラフとして表現できる。 資源及びリテラルの各々は，頂点とする。トリプル{p, s, o}は，pとラベルの付いた，sからoへの弧とする。 これを図11に示す。
図11 単純な文のグラフテンプレート
これを，次のとおりに読む。
oは，sに対するpの値とする。
これを，次のとおりに左から右に読んでもよい。
sは，値oの特性pをもつ。
さらに，次のとおりに読んでもよい。
sのpをoとする。
例として，次の自然言語文を示す。
Ora Lassilaは，資源http://www.w3.org/Home/Lassilaの作者である。
これのグラフ表現を図12に示す。
図12 単純な文のグラフ
対応するトリプル(Statementsのメンバ)を，次に示す。
{creator, [http://www.w3.org/Home/Lassila], "Ora Lassila"}
記法[I ]は，URI I で識別される資源を示し，引用符は，リテラルを示す。
トリプルを使って，(4.で導入した)文を具体化する方法を示すことができる。 例として，次の文を示す。
{creator, [http://www.w3.org/Home/Lassila], "Ora Lassila"}
新しい資源をXとして，この文の具体化を，次のとおりに表現する。
{RDF:type, [X], [RDF:Statement]}
{RDF:predicate, [X], [creator]}
{RDF:subject, [X], [http://www.w3.org/Home/Lassila]}
{RDF:object, [X], "Ora Lassila"}
RDF処理系の観点からは，事実(すなわち文)は，Statements のメンバであるトリプルとする。 それゆえ，元の文は，その文が具体化されていたとしても，事実として存続する。 それは，元の文を表現するトリプルが Statements の中に残存していることによる。 つまり，四つのトリプルが更に追加されただけとする。
"type(型)"という名前の特性を，プリミティブな型付けを提供するために定義する。 型の形式的な定義を，次に示す。
|
さらに，具体化の形式的な規定を，次に示す。
|
この定義における資源rを 具体化された文 と呼ぶ。資源が具体化された文を表現する場合， すなわち，資源がRDF:Statementを値とするRDF:type特性をもつ場合，その資源は， ただ一つの，RDF:subject，RDF:object及びRDF:predicateを特性とする文ををもたなければならない。
3.に示すとおりに，資源又はリテラルの集まりを表現することがたびたび必要になる。 例えば，特性が値の順序付き列をもつことを述べる必要がある。集まりの3種類の定義を，次に示す。
これら三つの集まり型の形式定義を，次に示す。
|
集まりcを表現するためには，トリプル{RDF:type, c, t}を生成する。 ここで，tは，三つの集まり型，RDF:Seq，RDF:Bag又はRDF:Altの一つとする。 残りのトリプル，{RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ... は，集まりの各メンバrn を示す。 一つの集まり資源に対して，Ordの既知の任意の要素を述語とする たかだか一つのトリプルが存在してもよい。ただし，Ordの要素は， RDF:_1から順々に使用しなければならない。 資源がRDF:Alt集まり型のインスタンスの場合，述語がRDF:_1であって， Alternatives資源に対するデフォルト値となるただ一つのトリプルが存在する。 すなわち，少なくとも一つの選択肢が常に存在していなければならない。
RDFのための完全なBNFを，6.で再構成する。形式モデルによる文法の正確な解釈も示す。 XMLから継承される構文機能は，6.に転載しない。 これには，すべての整形式制約，属性及び'='の前後の空白の使用， 並びに属性値の前後の2重引用符又は1重引用符のいずれかの使用を含む。 6.は，RDF/XML構文を読み込み解釈するツールを構築する実装者を意図している。
以降で使用するキーワード"することが望ましい(SHOULD)"， "しなければならない(MUST)"及び"してはならない(MUST NOT)"は， RFC 2119 [RFC2119] で示されるとおりに解釈しなければならない。
[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
[6.2] obj ::= description | container
[6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6.4] container ::= sequence | bag | alternative
[6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr
[6.6] idAttr ::= ' ID="' IDsymbol '"'
[6.7] aboutAttr ::= ' about="' URI-reference '"'
[6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"'
| ' aboutEachPrefix="' string '"'
[6.9] bagIdAttr ::= ' bagID="' IDsymbol '"'
[6.10] propAttr ::= typeAttr
| propName '="' string '"' (埋め込まれた引用符は別扱い)
[6.11] typeAttr ::= ' type="' URI-reference '"'
[6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>'
| '<' propName idAttr? parseLiteral '>'
literal '</' propName '>'
| '<' propName idAttr? parseResource '>'
propertyElt* '</' propName '>'
| '<' propName idRefAttr? bagIdAttr? propAttr* '/>'
[6.13] typedNode ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>'
| '<' typeName idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</' typeName '>'
[6.14] propName ::= Qname
[6.15] typeName ::= Qname
[6.16] idRefAttr ::= idAttr | resourceAttr
[6.17] value ::= obj | string
[6.18] resourceAttr ::= ' resource="' URI-reference '"'
[6.19] Qname ::= [ NSprefix ':' ] name
[6.20] URI-reference ::= string, ただし，[URI]に従って解釈する
[6.21] IDsymbol ::= (文法に合った任意のXML名前シンボル)
[6.22] name ::= (文法に合った任意のXML名前シンボル)
[6.23] NSprefix ::= (文法に合った任意のXML名前空間接頭辞)
[6.24] string ::= ("<"，">"及び"&"を別扱いした任意のXMLテキスト)
[6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
| '<rdf:Seq' idAttr? memberAttr* '/>'
[6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
| '<rdf:Bag' idAttr? memberAttr* '/>'
[6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
| '<rdf:Alt' idAttr? memberAttr? '/>'
[6.28] member ::= referencedItem | inlineItem
[6.29] referencedItem ::= '<rdf:li' resourceAttr '/>'
[6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>'
| '<rdf:li' parseLiteral '>' literal </rdf:li>'
| '<rdf:li' parseResource '>' propertyElt* </rdf:li>'
[6.31] memberAttr ::= ' rdf:_n="' string '"' (ここでnは整数)
[6.32] parseLiteral ::= ' parseType="Literal"'
[6.33] parseResource ::= ' parseType="Resource"'
[6.34] literal ::= (任意の整形式XML)
この規定で定義する特性及びクラスのための名前空間の正式な名前は， http://www.w3.org/1999/02/22-rdf-syntax-ns#とする。 文字列"http://www.w3.org/TR/REC-rdf-syntax" で始まる名前をもつ名前空間から出所とすると宣言されたXML要素名又はXML属性名に， RDF処理系が出会ったとき，処理系がその名前の意味を認識しない場合，処理系は， 認識しない名前をもつXML要素，又は認識しない名前の属性をもつXML要素を， その内容を含めて，すべて読み飛ばす。 すなわち，これらXML要素に対しては，タプルを生成しない。
Description要素がpropertyElt E を含む場合， トリプル{p,r,v}を生成する。ここで，p，r及びvは，次による。
| a) | pは，タグ名(一般識別子)を名前空間で修飾した，Eの展開形とする。 この展開形は，名前空間宣言で与えられる名前空間名に，修飾される名前の LocalPartを連結して生成する。 |
| b) |
rは，次のいずれかとする。
|
| c) |
vは，次のいずれかとする。
|
parseType属性は，要素内容の解釈を変更する。parseType属性は， 値'Literal'又は'Resource'のいずれかをもつことが望ましい。その値は，大文字・小文字が区別される。 値'Literal'は，要素内容をRDF/XMLリテラルとして取り扱うことを指定する。 すなわち，その内容はRDF処理系によって解釈されてはならない。値'Resource'は， 要素内容をDescription要素の内容であるものとして取り扱わなければならないことを指定する。 parseTypeの他の値は，将来の規定のためにRDFで予約する。RDF1.0では，他の値は， 'Literal'と同じものとして取り扱わなければならない。 parseType属性をもつ要素の内容は，いずれの場合でも，整形式なXMLでなければならない。 parseType="Resource"属性をもつ要素の内容は， Description要素の内容のための生成規則とマッチしなければならない。
参考 RDFモデル及び構文の作業グループは，parseType='Literal'機構が， XMLマーク付けを値とするRDF文を表現するという要件への最低限の解であると認識している。 空白の正準化などのXMLにおける付加的な複雑さについては，まだ正しく定義していない。 W3Cの将来の作業が，XMLに基づくすべてのアプリケーションに対して同一の方法で， これらの課題を解決するものと期待する。 RDFの将来の版が，この作業を引き継ぎ，アプリケーションが経験を積むことで洞察を得て， この作業を拡張するかもしれない。
URI-referenceは，RDF文が出現する文書の基底URIを使用して，まず， [URI] が規定する絶対形式に解決されることで，資源識別子に解決される。 素片識別子がURI-referenceに含まれる場合は，その資源識別子は，資源の部分構成要素だけを参照する。 すなわち，この部分構成要素は，その部分を含む資源にとって内部的な，対応するアンカー識別子で識別し， 部分構成要素の範囲は，その部分を含む資源の内容型と素片識別子とで定義する。 それ以外の場合は，資源識別子は，URIが示す項目全体を参照する。
備考 [URI]は， 非ASCII文字をURIで使用することを許していないが， [XML]は，URI構文を拡張し，不必要な非互換性を避けるための規約を規定している。 RDFの実装者は，非互換性が更に増すことがないように，システム識別子に対するXML規約を使用するほうがよい。 すなわち，URIの中の非ASCII文字は，1バイト以上のUTF-8で表現し，これらバイトは， URI別扱い機構で別扱いするのがよい。 すなわち，HHをバイト値の16進記法とするとき，各バイトを%HHに変換する。
Description要素自体は，Bag資源のインスタンスを表現する。 このBagのメンバは，Descriptionの中の各文を具体化したものに対応する資源とする。 bagID属性を指定した場合，この値はこのBagの識別子とする。 指定しない場合は，Bagは匿名とする。
Descriptionでaboutを指定した場合，Descriptionの中の文は， aboutにおいて名前付けされた資源を参照する。 about属性のないDescription要素は，行内資源を表現する。 Description要素のID属性値が存在する場合， この行内資源の資源識別子は， RDF文を含む文書の基底URIに，その属性値に等しいアンカー識別子を加えた値を使って作る。 他のDescription又は特性値が行内資源を参照する場合は， IDの値をabout属性で使用する。 Descriptionがそれ以外のとき，具体化された文に対応する資源のBagを参照する場合は， bagIDの値をabout属性で使用する。 ID又はaboutのいずれかをDescriptionで指定してもよいが， 同じ要素で両方をいっしょに指定してはならない。 ID及びbagID属性の値は，それら属性では，一つの文書では二つ以上出現してはならない。 一つの文書内では，ID及びbagIDで同じ値を使用してはならない。
DescriptionでaboutEachを指定する場合，Descriptionの中の文は， aboutEachによって名前付けられたコンテナの各メンバを参照する。 前述のとおり， Descriptionに含まれる各propertyElt E が表現するトリプル{p,r,v}は， コンテナのメンバの各rに対して複製される。
DescriptionでaboutEachPrefixを指定する場合，Descriptionの中の文は， 匿名のBagコンテナの各メンバを参照する。このBagコンテナのメンバは，aboutEachPrefix の値として与えられた文字列で開始する絶対形式の資源識別子をもつすべての資源とする。 この絶対形式の資源識別子は，[URI]の"5.2 相対参照の絶対形式への解決" に記述されたアルゴリズムに従い，URIを解決することによって生成される。 前述のとおり，Descriptionに含まれる各propertyElt E が表現するトリプル{p,r,v}は， コンテナのメンバである各rに対して複製される。
Seq，Bag及びAltは，それぞれ，コンテナ資源型のSequence，Bag及びAlternative のインスタンスを表現する。cを集まり資源とし， tをRDF:Seq，RDF:Bag又はRDF:Altの一つとすると，トリプル{RDF:type,c,t}が生成される。 集まりのメンバは，liで示す。各li要素 E は， 集まりの一つのメンバに対応し，トリプル{p,c,v}が生成される。 ただし，p，c及びvは，次による。
| a) | pは，各メンバのXML構文上の出現順序に従って， 各コンテナに対して"RDF:_1"から連続的に割り当てる。 |
| b) | cは，集まり資源とする。 ID属性が指定された場合は，この属性がcに対するURI素片識別子を提供する。 |
| c) | vは，次のいずれかによる。
これは，Description要素が含むpropertyElt E が生成するトリプルに対する，前述の規則c)と同じである。
|
(解決の後の)URIは，ターゲット資源， すなわち，Descriptionを適用する資源又はコンテナに含まれる資源を識別する。 Description要素のbagID属性及びコンテナ要素のID属性は， そのDescription又はコンテナを他のDescriptionが参照することを可能とする。 コンテナ要素のIDは，その集まりを特性要素の値とするために， その特性要素のresource属性で使用する名前とする。
生成規則[6.12]のpropertyEltにおいて，resource属性の値として使用されるURIは， 文の目的語(すなわち，この特性の値)となる資源を(解決後に)識別する。 ID属性の値が指定された場合は，その値は，文の具体化を表現する資源の識別子とする。 RDF式(すなわち，RDF/XMLマーク付けで記述した内容)を特性値として指定する場合， その目的語は，RDF式に含まれるDescriptionのabout属性が与える資源， 又はRDF式に含まれるDescription若しくはコンテナ資源のID(暗黙的な場合もあるが) が与える資源とする。 Stringは，整形式のXMLでなければならない。 文字列が，"<"，"&"などの整形式規則を乱す文字の並び， 又はマーク付けとみなされるかもしれない文字の並びを含む場合は， 通常のXML内容の引用機構及び別扱い機構を使用してもよい。 属性parseType="Literal"は， 要素内容がRDFリテラルであることを指定する。 この内容の一部となる任意のマーク付けは， リテラルの一部として含まれ，RDFでは解釈されない。
特性名は，常に名前空間接頭辞で修飾し， あいまい性なく，特性定義と対応するスキーマとを結び付けることが望ましい。
XMLで定義するとおり，RDF文字列の文字レパートリは，ISO/IEC 10646 [ISO10646]とする。 実際のRDF文字列は，XML文書の中にあろうとRDFデータモデルの他の表現の中にあろうと， ISO/IEC 10646の直接の符号化又はISO/IEC 10646に対応付け可能な符号化を使用して記憶してよい。 言語タグ付けは，文字列値の一部とする。すなわち，これは，RDF文字列内の文字の並びに適用されるが， データモデルでは明示的に表明されない。
二つのRDF文字列は，それらのISO/IEC 10646表現がマッチする場合に，同じとする。 各RDFアプリケーションは，次に示す'マッチ'の定義のどちらを使用するかを指定しなければならない。
| a) | 二つの表現は，同一である。 |
| b) | 二つの表現は，Unicode規格[Unicode]が定義するとおりに，正準的に等価である。 |
備考 W3C I18N WGは， 文字列同一性(string identity)のマッチングの定義に関して作業している。 この定義は，まず間違いなく， Unicode規格に従う正準的等価性(canonical equivalences)， 及び事前の一様正規化(uniform normalization)の原理に基づくことになる。 RDFのユーザは，使用するデータが，正準的等価性を使用する任意のアプリケーションのマッチングに依存せずに， 将来の定義に従った正規化形式(normalized form)であることを確実とするのが望ましい。
この規定は，マーク付けを含むリテラル間の等価性を決定するための機構も， その機構の存在を保証することも示さない。
言語を特性値と関連付けるために， xml:lang属性を [XML]が定義するとおりに使用してもよい。 xml:langに対する特定のデータモデル表現は存在しない。 すなわち，それはデータモデルにトリプルを追加しない。 RDFは，リテラルの言語をリテラルの一部とみなす。 アプリケーションは，文字列の言語タグ付けを無視してもよい。すべてのRDFアプリケーションは， リテラルにおける言語タグ付けが重要かどうかを指定しなければならない。 すなわち，文字列マッチングなどの処理を実行する場合， 言語を考慮するかどうかを指定しなければならない。
名前が"xmlns" で始まる属性は，名前空間宣言であって，データモデルにおけるトリプルを表現しない。 これら名前空間宣言に対する特定のデータモデル表現は存在しない。
生成規則[6.3]及び[6.10]によってXML属性形式で表現される特性及び値の各々は， 生成規則[6.12]に従って，対応するDescriptionのXML内容として表現される同じ特性及び値に等価とする。 特に，Description開始タグにおいて指定された各XML属性A が， ID属性，about属性，aboutEach属性， aboutEachPrefix属性，bagID属性，xml:lang属性， 又は文字列xmlnsで始まる属性以外の場合は， トリプル{p,r,v}を生成する。 ここで，p，r及びvは，次による。
| a) | pは，A の属性名を名前空間で修飾した展開形とする。 この展開形は，名前空間宣言で与えられる名前空間名に， 修飾される名前のLocalPartを連結し， このURIを，[URI]の"5.2 相対参照の絶対形式への解決"に従って解決することで生成される。 |
| b) |
rは，次のいずれかとする。
|
| c) | vは，A の属性値(リテラル)とする。 |
文法的には，生成規則[6.11]は，単に，propName生成規則[6.10]の特殊な場合である。 type属性の値は，URI-referenceとして解釈され，resource属性の値と同じ方法で展開される。 [6.11]の使用は，resource属性とともに，要素(特性)名として rdf :type を使用することと等価とする。
typedNode形式(生成規則[6.13])は，特定の型の資源のインスタンスを表現するために， さらに，それらの資源を記述するために使用してよい。 生成規則[6.13]によってtypedNode形式で表現されるDescriptionは， 生成規則[6.3]によって表現される，次に示すDescriptionと等価とする。
| a) | Descriptionが，同じID属性，bagID属性及びabout属性をもつ。 |
| b) | 更に，Descriptionが付加的なtype特性をもつ。 なお，この付加的なtype特性の値は，typedNodeのtypeNameに対応するURIで， 完全に展開され解決されたURIによって識別子が与えられた資源とする。 |
生成規則[6.10]及び[6.12]によって，特性及び値が，空XML要素 E 内のXML属性形式で表現された場合， 一つのDescription要素 DをE の内容として仮に表現したとき， そのDのXML内容として表現された同じ特性及び値と等価とする。 Dの指示対象は，生成規則[6.17]，[6.2]及び[6.3]に従って， E のXML要素名で識別された特性の値とする。 特に，各propertyElt開始タグが， ID属性，resource属性，bagID属性，xml:lang属性， 又は文字列xmlnsで始まる任意の属性以外の属性規定を含む場合， トリプル{p,r1,r2}，{pa1,r2,va1}，...， {pan,r2,van}を生成する。 ここで，トリプルの要素は次による。
| a) | pは，名前空間で修飾されたタグ名の展開形とする。 |
| b) | r1は，このpropertyElt式を含む要素が参照する資源とする。 |
| c) | r2は，resource属性が存在する場合は，それによって名前付けされた資源とする。存在しない場合は，新しい資源とする。 ID属性が与えられた場合は，この属性の値を新しい資源の識別子とする。 |
| d) | pa1，...，panは，名前空間で修飾された属性名の展開形とする。 |
| e) | va1，...，vanは，対応する属性値とする。 |
bagID属性の値が指定された場合は，この値は，Description D に対応するBagの識別子とする。 指定されない場合は，Bagは匿名とする。
RDFの機能を更に説明する例を，7.に示す。
一つの資源を二つ以上の特性の値とすることができる。 すなわち，一つの資源を二つ以上の文の目的語とし， それで，二つ以上の弧で参照することができる。 例えば，一つのウェブページを複数の文書の間で共有し， 一つの"サイトマップ"で2回以上参照してもよい。 同じ複数の資源に対して，二つの異なる(順序付きの)列を与えてもよい。
一人の著者の作品集を示し，最初は出版日付で並べ， 再び主題のアルファベット順で並べる場合の例を，次に示す。
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Seq ID="JSPapersByDate">
<li resource="http://www.dogworld.com/Aug96.doc"/>
<li resource="http://www.webnuts.net/Jan97.html"/>
<li resource="http://www.carchat.com/Sept97.html"/>
</Seq>
<Seq ID="JSPapersBySubj">
<li resource="http://www.carchat.com/Sept97.html"/>
<li resource="http://www.dogworld.com/Aug96.doc"/>
<li resource="http://www.webnuts.net/Jan97.html"/>
</Seq>
</RDF>
このXMLの例では，名前空間接頭辞を省略するために，デフォルト名前空間宣言構文も使用している。
図13 二つの例の間での変数の共有
集約を説明するために，アルファベット順に記述した二人の著者をもち， 二つの異なる言語で記述した題名をもち，さらに，ウェブ上で二つの等価なロケーションをもつ文書の例を，次に示す。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="http://www.foo.com/cool.html">
<dc:Creator>
<rdf:Seq ID="CreatorsAlphabeticalBySurname">
<rdf:li>Mary Andrew</rdf:li>
<rdf:li>Jacky Crystal</rdf:li>
</rdf:Seq>
</dc:Creator>
<dc:Identifier>
<rdf:Bag ID="MirroredSites">
<rdf:li rdf:resource="http://www.foo.com.au/cool.html"/>
<rdf:li rdf:resource="http://www.foo.com.it/cool.html"/>
</rdf:Bag>
</dc:Identifier>
<dc:Title>
<rdf:Alt>
<rdf:li xml:lang="en">The Coolest Web Page</rdf:li>
<rdf:li xml:lang="it">Il Pagio di Web Fuba</rdf:li>
</rdf:Alt>
</dc:Title>
</rdf:Description>
</rdf:RDF>
この例では，集まりの三つの型すべての使用法が示されている。 作者の順序は重要なので， 彼らを保持するために Sequence コンテナを使用する。 ウェブ上のロケーションは等価としている。つまり，順序は重要ではないので，Bag を使用する。 文書は唯一つの題名をもち，題名は二つの表示形式をもつ。 それで，Alternatives コンテナを使用する。
備考 多くの場合，様々な代替言語のなかからより好ましい言語を選択することは不可能である。 すなわち，すべての言語を厳密に等価とみなすことがある。この場合，記述をする著者は， Altコンテナの代わりにBagコンテナを使用したほうがよい。
RDFデータモデルは，本来，2項関係だけをサポートする。 すなわち，文は二つの資源の間の関係を規定する。 次の例では，2項関係だけを使用して，RDFで多項関係を表現するために推奨する方法を示す。 この推奨する技法では，ある資源の残りの関係を与える付加的な特性をともなった中間資源を使用する。 例として，John Smithの最近の著作の一つのsubject訳注，図書館学，を取り上げる。 図書館学ではその著作を分類するためにDewey十進コードを使用できる。 Dewey十進コードは，単なる著作の内容の分類スキームではない。 それは，分類システム関係を保持するために， subject特性の値として使用する付加的な資源を特定し， 使用した分類スキームを識別する付加的な特性でこの資源を注記する。 2.3で示したとおり，RDFコアは，主たる関係のもとの値を示するために value 特性を含む。 結果として生じるグラフは，図14のとおりになるだろう。
訳注 このsubjectは，著作物の内容の意味での主題のこと。RDF文における主語としてのsubjectと混同してはならない。
図14 3項関係
これは，次の形式で交換できる。
<RDF
xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#"
xmlns:l="http://mycorp.com/schemas/my-schema#">
<Description about="http://www.webnuts.net/Jan97.html">
<dc:Subject
rdf:value="020 - Library Science"
l:Classification="Dewey Decimal Code"/>
</Description>
</RDF>
備考 この例では，二つの名前空間宣言が同じ名前空間に対して存在する。 これは，デフォルト名前空間を宣言する場合， 要素の名前空間と異なる名前空間で定義された属性を指定するために必要となることが多い。 この例では，dc:Subject要素の中のrdf:value属性がこの場合となる。
この多項関係をよく使用するのは，測度の単位を処理する場合である。 人間の体重は，"200"などの単なる数ではなく，使用する測度の単位も含む。 この場合，ポンド又はキログラムのいずれかを使用するかもしれない。 John Smithが大柄の紳士である事実を記録するために，付加的な弧をもつ関係を使用できる。 これを図15に示す。
図15 3項関係としての測度の単位
これは，次の形式で交換できる。
<RDF
xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:n="http://www.nist.gov/units/">
<Description about="John_Smith">
<n:weight rdf:parseType="Resource">
<rdf:value>200</rdf:value>
<n:units rdf:resource="http://www.nist.gov/units/Pounds"/>
</n:weight>
</Description>
</RDF>
ただし，資源"Pounds"は，URI http://www.nist.gov/units/Poundsをもつ NISTスキーマで定義されるものとする。
Dublin Core メタデータは，図書館カードカタログに似た方法で電子的な資源の発見を促進するために設計された。 この例では，Dublin Core Initiative によって定義された語彙を使用して，資源の集合の単純な記述をRDFで表現する。
備考 ここで示すDublin Core RDFの特定の語彙は，権威付けられていることを意味しない。 ただし，Dublin Core Initiativeは，権威ある参照先である。
次に，Dublin Core特性を使用する，ウェブサイトホームページの記述を示す。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="http://www.dlib.org">
<dc:Title>D-Lib Program - Research in Digital Libraries</dc:Title>
<dc:Description>The D-Lib program supports the community of people
with research interests in digital libraries and electronic
publishing.</dc:Description>
<dc:Publisher>Corporation For National Research Initiatives</dc:Publisher>
<dc:Date>1995-01-07</dc:Date>
<dc:Subject>
<rdf:Bag>
<rdf:li>Research; statistical methods</rdf:li>
<rdf:li>Education, research, related topics</rdf:li>
<rdf:li>Library use Studies</rdf:li>
</rdf:Bag>
</dc:Subject>
<dc:Type>World Wide Web Home Page</dc:Type>
<dc:Format>text/html</dc:Format>
<dc:Language>en</dc:Language>
</rdf:Description>
</rdf:RDF>
次の例は，出版された雑誌に関するものである。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#"
xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#">
<rdf:Description about="http://www.dlib.org/dlib/may98/05contents.html">
<dc:Title>DLIB Magazine - The Magazine for Digital Library Research
- May 1998</dc:Title>
<dc:Description>D-LIB magazine is a monthly compilation of
contributed stories, commentary, and briefings.</dc:Description>
<dc:Contributor rdf:parseType="Resource">
<dcq:AgentType
rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#Editor"/>
<rdf:value>Amy Friedlander</rdf:value>
</dc:Contributor>
<dc:Publisher>Corporation for National Research Initiatives</dc:Publisher>
<dc:Date>1998-01-05</dc:Date>
<dc:Type>electronic journal</dc:Type>
<dc:Subject>
<rdf:Bag>
<rdf:li>library use studies</rdf:li>
<rdf:li>magazines and newspapers</rdf:li>
</rdf:Bag>
</dc:Subject>
<dc:Format>text/html</dc:Format>
<dc:Identifier>urn:issn:1082-9873</dc:Identifier>
<dc:Relation rdf:parseType="Resource">
<dcq:RelationType
rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf"/>
<rdf:value resource="http://www.dlib.org"/>
</dc:Relation>
</rdf:Description>
</rdf:RDF>
次は，2番目の例で参照した雑誌の特定記事に関するものである。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#"
xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#">
<rdf:Description about=
"http://www.dlib.org/dlib/may98/miller/05miller.html">
<dc:Title>An Introduction to the Resource Description Framework</dc:Title>
<dc:Creator>Eric J. Miller</dc:Creator>
<dc:Description>The Resource Description Framework (RDF) is an
infrastructure that enables the encoding, exchange and reuse of
structured metadata. rdf is an application of xml that imposes needed
structural constraints to provide unambiguous methods of expressing
semantics. rdf additionally provides a means for publishing both
human-readable and machine-processable vocabularies designed to
encourage the reuse and extension of metadata semantics among
disparate information communities. the structural constraints rdf
imposes to support the consistent encoding and exchange of
standardized metadata provides for the interchangeability of separate
packages of metadata defined by different resource description
communities. </dc:Description>
<dc:Publisher>Corporation for National Research Initiatives</dc:Publisher>
<dc:Subject>
<rdf:Bag>
<rdf:li>machine-readable catalog record formats</rdf:li>
<rdf:li>applications of computer file organization and
access methods</rdf:li>
</rdf:Bag>
</dc:Subject>
<dc:Rights>Copyright @ 1998 Eric Miller</dc:Rights>
<dc:Type>Electronic Document</dc:Type>
<dc:Format>text/html</dc:Format>
<dc:Language>en</dc:Language>
<dc:Relation rdf:parseType="Resource">
<dcq:RelationType
rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf"/>
<rdf:value resource="http://www.dlib.org/dlib/may98/05contents.html"/>
</dc:Relation>
</rdf:Description>
</rdf:RDF>
備考 スキーマ開発者は，XML名前空間の 修飾された名前 の短縮形に対応する構文を使用するために， ある特性の値を宣言したくなるかもしれない。 しかし，特性値の内部でこれら修飾された名前を使用しないことを推奨する。 これは，将来のXMLのデータ型付け機構と互換性が無くなるかもしれないことによる。 さらに，XML 1.0機能に十分に精通した者は，同様の短縮形機能がユーザ定義実体に存在することに気付くかもしれない。 同様に，(ユーザ定義)実体の使用に依存しないことを推奨する。これは，ユーザ定義実体を含まないXMLの部分集合を， 今後定義するという提案が存在することによる。
特性値がXMLマーク付けを含むリテラルの場合，そのマーク付けを解釈せず， 値の一部のままにしておくことを，RDFインタープリタに知らせるために，次の構文を使用する。 その結果として生じる値の正確な表現は，ここでは規定しない。
次の例では，Title特性の値を，MATHML マーク付けを含むリテラルとする。
<rdf:Description
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#"
xmlns="http://www.w3.org/TR/REC-mathml"
rdf:about="http://mycorp.com/papers/NobelPaper1">
<dc:Title rdf:parseType="Literal">
Ramifications of
<apply>
<power/>
<apply>
<plus/>
<ci>a</ci>
<ci>b</ci>
</apply>
<cn>2</cn>
</apply>
to World Peace
</dc:Title>
<dc:Creator>David Hume</dc:Creator>
</rdf:Description>
インタネット内容選択のためのプラットフォーム (Platform for Internet Content Selection，以降PICS)は， ウェブページなどのデータの内容記述を交換するためのW3C勧告である。 PICSは，RDFに先行する勧告であって，PICSラベルで表現可能なものをRDFで表現できることが， RDFの明示的な要件となっている。
次に，PICSラベルをRDF形式で表現する方法の例を示す。
備考 PICS自体をRDFの応用として再規定するという作業が， RDF規定の完成後に起こるかもしれないことに注意。 それで，次の例は，将来のPICSスキーマの権威付けられた例と考えないほうがよい。
この例は，[PICS]に直接に由来する。 PICS格付けサービス記述(Rating Service Description)が， RDFスキーマに非常に類似することに注意。 格付けサービス記述ファイルなどで示される分類は，RDFモデルにおける特性と等価である。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#"
xmlns:gcf="http://www.gcf.org/v2.5">
<rdf:Description about="http://www.w3.org/PICS/Overview.html" bagID="L01"
gcf:suds="0.5"
gcf:density="0"
gcf:color.hue="1"/>
<rdf:Description about="http://www.w3.org/PICS/Underview.html" bagID="L02"
gcf:subject="2"
gcf:density="1"
gcf:color.hue="1"/>
<rdf:Description aboutEach="#L01"
pics:by="John Doe"
pics:on="1994.11.05T08:15-0500"
pics:until="1995.12.31T23:59-0000"/>
<rdf:Description aboutEach="#L02"
pics:by="Jane Doe"
pics:on="1994.11.05T08:15-0500"
pics:until="1995.12.31T23:59-0000"/>
</rdf:RDF>
PICSラベルオプションは，個々の(格付け)文を参照し，これらの文を供給するコンテナを参照しているのではないことを示すために， aboutEachを使用することに注意。
[PICS]は， 包括的ラベル(generic label) という型も定義する。 PICSの包括的ラベルは，ウェブサイトの指定部分の内部のすべてのページに適用されるラベルとする。
次に，aboutEachPrefix集まりコンストラクタを使って， PICSの包括的ラベルをRDFで記述する方法の例を示す。 この例は，[PICS] の附属書Bに記述された"包括的要求"の例から抽出した。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#"
xmlns:ages="http://www.ages.org/our-service/v1.0/">
<rdf:Description aboutEachPrefix="http://www.w3.org/WWW/" bagID="L03"
ages:age="11"/>
<rdf:Description aboutEach="#L03"
pics:by="abaird@w3.org"/>
</rdf:RDF>
値"11"をもつ特性ageが，文字列"http://www.w3.org/WWW/" で始まるURIをもつすべての資源に出現する。"[ I ]の年齢は11である。" などの各文に対応する具体化された文は， "abaird@w3.org"がこれらの文の作成に責任があったことを述べる特性をもつ。
RDFは，整形式XMLであるので， 妥当でない文書におけるエラー処理に対して，ユーザエージェントがHTML 勧告 に従っている場合，HTML文書に直接に取り込むのに適している。 RDFの素片がHTML文書に取り込まれている場合，ブラウザの中には， 任意の開示文字列内容を表示するものがある。 開示文字列内容とは，一つのタグを終了する">"と次のタグを開始する"<" との間の任意のものとする。一般に，行末文字を含む複数の連続する空白文字は， 一つの空白として表示する。
XML属性形式では文字列である特性値を記述し，開示内容として空白だけを残すために， RDF短縮構文はたびたび使用される。 例えば，7.4のDublin Coreの例の最初の部分は， 次のとおりに書くことができる。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="http://www.dlib.org"
dc:Title="D-Lib Program - Research in Digital Libraries"
dc:Description="The D-Lib program supports the community of people
with research interests in digital libraries and electronic
publishing."
dc:Publisher="Corporation For National Research Initiatives"
dc:Date="1995-01-07"/>
</rdf:RDF>
内容を開示しないために，通常の場合は書き換えることができる。 一般的だがあまり明確ではない例に，コンテナ記述がある。 7.2における例の最初の部分を次に検討する。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="http://www.foo.com/cool.html">
<dc:Creator>
<rdf:Seq ID="CreatorsAlphabeticalBySurname">
<rdf:li>Mary Andrew</rdf:li>
<rdf:li>Jacky Crystal</rdf:li>
</rdf:Seq>
</dc:Creator>
</rdf:Description>
</rdf:RDF>
これを開示内容なしに書き換えるためには，次の形式を使用する。
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="http://www.foo.com/cool.html">
<dc:Creator>
<rdf:Seq ID="CreatorsAlphabeticalBySurname"
rdf:_1="Mary Andrew"
rdf:_2="Jacky Crystal"/>
</dc:Creator>
</rdf:Description>
</rdf:RDF>
ここで，一つのタグ内に同じ属性名が複数出現すること禁止するXML規則のために， li 要素は属性として使用できない。それで，明示的なRDF Ord 特性を使用する。これは，実際上，li 要素を展開したことになる。
完全なHTML文書で，それ自体を記述するRDFメタデータを含むものを，次に示す。
<html>
<head>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/metadata/dublin_core#">
<rdf:Description about="">
<dc:Creator>
<rdf:Seq ID="CreatorsAlphabeticalBySurname"
rdf:_1="Mary Andrew"
rdf:_2="Jacky Crystal"/>
</dc:Creator>
</rdf:Description>
</rdf:RDF>
</head>
<body>
<P>This is a fine document.</P>
</body>
</html>
このHTML文書は，HTML3.2及びそれ以降に準拠するすべてのブラウザで受理され， 文字列"This is a fine document."だけが表示されることが望ましい。
この規定は，W3C RDFモデル及び構文作業グループの成果である。 この作業グループは，Online Computer Library CenterのEric Miller及びIBMのBob Schlossによって非常に巧みに運営された。Eric及びBobのグループを順調に運営する弛みない努力に感謝するとともに, この試みにおいて支援してくれたOCLC，IBM及びNokiaに特に感謝する。
この規定の設計，提案討議，文書化， 多くの原案校正及び最終的な合意までの過程で支援してくれた作業グループのメンバを次に示す。 Ron Daniel (DATAFUSION), Renato Iannella (DSTC), Tsuyoshi SAKATA (DVL), Murray Maloney (Grif), Bob Schloss (IBM), Naohiko URAMOTO (IBM), Bill Roberts (KnowledgeCite), Arthur van Hoff (Marimba), Charles Frankston (Microsoft), Andrew Layman (Microsoft), Chris McConnell (Microsoft), Jean Paoli (Microsoft), R.V. Guha (Netscape), Ora Lassila (Nokia), Ralph LeVan (OCLC), Eric Miller (OCLC), Charles Wicksteed (Reuters), Misha Wolf (Reuters), Wei Song (SISU), Lauren Wood (SoftQuad), Tim Bray (Textuality), Paul Resnick (University of Michigan), Tim Berners-Lee (W3C), Dan Connolly (W3C), Jim Miller (W3C, emeritus), Ralph Swick (W3C)。 Dan Brickley (UK Bristol)は，RDFスキーマ活動に参加し， この作業の最終段階で多くの思慮深い助言をしてくれた。 Martin Dürst (W3C)は，作業素案をレビューし， Internationalization Working Groupに代わって多くの改良点を提案してくれた。 Janne Saarela (W3C)は，作業素案から'クリーンルーム' 実装を作成することで， 計り知れない貢献をしてくれた。
この規定は，作業グループの成果を集めたものである。 この規定の著者は，この規定の作成及び改良の支援において作業グループに負うものがある。