このドキュメントは

Resource Description Framework
(RDF) Model and Syntax Specification

W3C Recommendation 22 February 1999
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222

の和訳です。

このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。

Copyright (C)  1997,1998,1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。




W3C REC-rdf-syntax-19990222

 

Resource Description Framework
(RDF) Model and Syntax Specification

W3C Recommendation 22 February 1999

Status of this Document
This Version:
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Newest Version:
http://www.w3.org/TR/REC-rdf-syntax
Editors:
Ora Lassila <ora.lassila@research.nokia.com>, Nokia Research Center
Ralph R. Swick <swick@w3.org>, World Wide Web Consortium

Document Status

Copyright (C) 1997,1998,1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

本文書の位置付け

このドキュメントはW3Cメンバーと他の興味を持った団体によって再検討され、そして W3C勧告としてディレクターによって承認された。それは安定性があるドキュメントであって、そしてリファレンス材料として用いられるか、あるいは他のドキュメントから標準のリファレンスとして引用されることもある。 勧告作成におけるW3Cの役割は、仕様書に注目を引くこと、そしてその広範囲にわたる実装を促進することである。これは機能性とWebの互換性を拡張する。

この仕様書中のknowエラーのリストはhttp://www.w3.org/TR/1999/REC-rdf-syntax-19990222/errataで利用可能である。

この仕様書についてのコメントは<www-rdf-comments@w3.org>に送られたい。公のコメントの記録はhttp://www.w3.org/Archives/Public/www-rdf-commentsでアクセス可能である。


目次

  1. 序論
  2. 基本的なRDF
  3. コンテナ
  4. ステートメントについてのステートメント
  5. RDFのための正式のモデル
  6. RDFのための形式文法
  7. 謝辞
  8. 付録A:用語集
  9. 付録B:RDFの移動
  10. 付録C:使用法についての注釈
  11. 付録D:参考文献
  12. 付録E:前バージョンからの変更

1. 序論

World Wide Webは、元来人間の消費のために作られた。そしてその上のすべてがマシンが読むことが可能であるが、このデータはマシンが理解可能ではない。Webで何か自動化することは非常に難しく、そしてWebが含んでいる情報量の多さのために、手作業でそれを管理することは可能ではない。ここで提案する解決策は、Webで含まれるデータを記述するためにメタデータを使うことである。 メタデータは「データについてのデータ」のことであり(例えば、ライブラリカタログは、出版物について記述しているのでメタデータである)、とりわけこの仕様書のコンテキストでは「Webリソースを記述しているデータ」のことである。「データ」と「メタデータ」の間の区別ははっきりとしたものではない。それは特定のアプリケーションによって初めて生み出される区別であり、一つのリソースが同時に2つの仕方で解釈されることもしばしばあるだろう。

Resource Description Framework(RDF)はメタデータを処理するための基礎であり、Webでマシンが理解可能な情報を交換するアプリケーションの間に互換性を提供する。RDFはWebリソースの処理の自動化を容易に実現できることを強調する。RDF はいろいろな応用領域で使うことができる。例えば、(1)より良いサーチ・エンジン能力を提供するリソースリカバリーにおいて、(2)特定のWebサイトやWebページ、ディジタル図書館においてアクセス可能なコンテンツとコンテンツ関係の記述のためのカタログ作りにおいて、(3)知識の共有と交換を容易にするための知的なソフトウェアのエージェントによって、(4)コンテンツレイティングで、(5)論理的に単一な「ドキュメント」を表すひとまとまりのページを記述することにおいて、 (6)Webページの「知的財産権」を記述するために、(7)Webサイトのプライバシーポリシーとユーザのプライバシープリファレンスを表現するために、 などである。ディジタル署名を持っているRDFは電子商取引、コラボレーションと他のアプリケーションのために「信頼のWeb」を構築することの鍵となるであろう。

このドキュメントは、独立して開発されたWebサーバとクライアントの互換性を最大にする方法で、RDFメタデータを表すためのモデ ルと、RDFメタデータのコーディングと移植のための文法を紹介する。ここで提示された文法は、、Extensible Markup Language[XML]を使う。RDFの目標の1つが、標準化され相互互換性のある方法で、XMLに基づいたデータのためにセマンティクスを指定できるようにすることである。RDFとXMLは補足的である。RDFはメタデータのモデルであり、そしてただリファレンスによって移植とファイルストレージが必要とするコーディングの問題点の多くに言及するだけである(国際化、文字セットなどのような)。 これらの問題点のために、RDFはXMLのサポートに頼る。このXML文法がRDFのためにただ1つの可能な文法であることと、そして同じRDF データモデルを表現する代わりの方法が出現するかもしれないこととを理解することは同じく重要である。

RDFの広範囲の目標は、特定のアプリケーションドメインについていかなる仮定もせず、またいかなるアプリケーションドメインの セマンティクスも(前提として)定義しないような、リソースを記述するためのメカニズムを定義することである。メカニズムの定義はドメインに中立的であるべきであり、また、メカニズムはどんなドメインについての情報を記述することにも適しているべきである。

この仕様書に続く他のドキュメントによって、RDFフレームワークは完成するであろう。最も重要なことに、メタデータの定義を容易にするために、RDFは多くのオブジェクト指向プログラミングやモデリングシステムとほとんど同じようなクラスシステムを持つであろう。クラスの集まり(特定の目的あるいはドメインのために一般に著作された)は、スキーマと呼ばれる。クラスは階層的に組織化されており、そしてサブクラス詳細化を通して拡張性を提供する。このように、少し既存のものと異なったスキーマを作るために、わざわざ一から作り直すことは必要なく、ベーススキーマにただ追加的な修正を提供すればよい。スキーマの共有可能性を通してRDFはメタデータ定義の再使用可能性をサポートするであろう。RDFの追加的な拡張性のために、メタデータを処理しているエージェントは、見知らぬスキーマの起源を既知のスキーマに突き止め、元来は処理するよう設計されなかったメタデータに対しても意味のある動作を行うことが可能であろう。RDFの共有可能性と拡張性により、メタデータの作成者は、他の人たちによってなされた作業を利用して、データに様々な視点を提供するような複の定義を複合し、それらの多様な遺産を利用することができる。加えるに、多数のソース(すなわち、「インタリーブして」いる異なったタイプのメタデータ)に含まれる多数のスキーマに基づいてRDF事例データを作ることは可能である。 スキーマがそれ自体RDFに書かれるかもしれない。この仕様書とセットになったドキュメントである[RDFSchema]が、RDFスキーマを記述するためのプロパティとクラスの1つのセットを説明する。

多くのコミュニティが参加してメタデータ表記と移植の基本原理に合意した結果として、RDFはいくつかの異なったソースから影響を受けることとなった。主に影響力を及ぼしたコミュニティは、それ自身はHTMLメタデータとPICSの形をとったWeb標準化コミュニティ図書館コミュニティ、SGMLとより重要なXMLの形をとった構造化されたドキュメントのコミュニティ知識表現(knowledge representation,KR)コミュニティである。また、RDF構想に貢献した技術の他のエリアがある。これらには、オブジェクト指向プログラミングと、モデリング言語と、データベースが含まれる。RDFがKRコミュニティを取り込む間、そのフィールドに精通したリーダは、RDFが推論のためのメカニズムを指定しないことを注意される。RDFは単純なフレームシステムであると特徴づけることができる。このフレームシステムの頂点に、推論メカニズムを構築できるかもしれない。

2. 基本的なRDF

2.1 基本的なRDFモデル

RDFの基礎となるものは、指定されたプロパティとプロパティ値を表現するためのモデルである。RDFモデルは、種々のデータ表現コミュニティによって確立した原理の上に描かれる。 RDFプロパティは、リソースの属性と考えてよく、そしてこの意味では、従来の属性と値の対に相当する。RDF プロパティはまた、リソース間の関係を表す。従って、RDFモデルはエンティティ関係(ER)図に似ている場合もある。(より正確には;RDFスキーマ—それら自身RDFデータモデルのインスタンス—はER図である)オブジェクト指向デザイン用語では、リソースがオブジェクトに対応し、プロパティがインスタンス変数に対応する。

RDFデータモデルはRDF表現の意味を表す文法中立的な方法である。データモデル表記は意味において等価であることを評価するために使われる。もしそれらのデータモデル表記が同じである場合に限り、そしてその場合には必ず、2つのRDF表現は、等価である。この等価性の定義によって、RDF表現において、意味を変えることなく構文を若干変化させることが可能となる。(ストリング比較問題の追加ディスカッションについては6章を参照。)

基本的なデータモデルは、3つのオブジェクトタイプから成り立つ:

リソース RDF式によって記述されているすべてのものはリソースと呼ばれる。リソースは、例えば、HTMLドキュメント"http://www.w3.org/Overview.html"のような、 あるWebページ全体であるかもしれない。また、リソースは、例えばドキュメントソースの中の特定のHTMLあるいはXML要素のような、Webページの一部であるかもしれない。リソースはまた、あるWebサイトの全体のような、Webページの集合であるかもしれない。リソースはまた、Webによって直接アクセス可能でない対象、例えば印刷された本であるかもしれない。リソースは、URIとオプショナルなアンカーIDによって常に名前を付けることができる([URI]参照)。いかなるものもURIを持つことができる。URIの拡張性によって、考えられうるいかなる実体についても、識別子の導入することができる。
プロパティ プロパティはリソースを記述するために用いられる特定の側面や特徴、属性、関係性である。それぞれのプロパティは、特定の意味を持ち、その許された値、それが記述することができるリソースのタイプ、そして他のプロパティとの関係を定義する。 このドキュメントはどのようにプロパティの特徴が表現されるかについては言及しない。(このような情報については、RDF Schema specificationを参照されたい)。
ステートメント RDFステートメントとは、(1)指定されたプロパティと(2)リソースに対するプロパティの値とを伴った(3)特定のリソースのことである。これらステートメントの3つの個別のパーツは、それぞれ、subject((3)に対応)、predicate((1)に対応)、object((2)に対応)と呼ばれる。ステートメントのobject(すなわち、プロパティ値)はさらなる別のリソースであったり、あリテラルであったりする。すなわち、(URIによって指定された)リソースであったり、単純なストリングであったり、XMLによって定義された他のプリミティブなdatatypeであったりする。RDF用語で、リテラルは、XMLマークアップであるコンテンツを持っていてもよいが、それはそれ以上にRDFプロセッサによって評価されない。リテラルの中で許されているマークアップの表記方法については若干の文法的な制約事項がある。2.2.1章参照のこと。

2.1.1 例

リソースはresource identifier「リソース識別子」によって識別される。リソース識別子は1つの任意のアンカーIDをプラスしたURIである(2.2.1章 を参照のこと)。この章の目的に合わせて、ここではプロパティは単純な名詞によって表すものとする

単純な例として以下の文を考えられたい:

Ora Lassila はリソースhttp://www.w3.org/Home/Lassila.の作成者である。

この文は次のパーツを持っている:

 Subject (Resource)   http://www.w3.org/Home/Lassila 
 Predicate (Property)   Creator
 Object (literal)   "Ora Lassila"

このドキュメントでは、方向付けられ、ラベルをはられた図表を使って図式的にRDFステートメントを図解する(これは「ノードとアーク図」と呼ばれる)。これらの図で、(だ円として描かれた)ノードはリソースを表す、そしてアークが名前をつけられたプロパティを表す。文字列リテラルを表すノードが長方形として描かれる。上記の文はこのように図解されるであろう:

Simple node and arcD

図1: 単純なノードとアーク図

注: 矢印の方向は重要である。アークは常にsubjectに始まって、そしてステートメントのobjectを指し示す。上記の単純な図はく"http://www.w3.org/Home/Lassila は作成者Ora Lassilaを持つ"、あるいは一般に"<subject>は<predicate> <object>を持つ"と読むこともできる。

今、このリソースの作成者の特色についてこれ以上何かを言いたいケースを考えてみる。散文で、このような文は以下のようになるであろう:

Ora Lassilaという名前の人は、電子メール<lassila@w3.org>であり、http://www.w3.org/Home/Lassila.の作成者である。

この文の意図は作成者(Creator)プロパティの値を構造化されたエンティティーにすることである。RDFでこのようなエンティティーはもう1つのリソースであるとして表現される。上記の文はそのリソースに名前を与えない。それは名無しである。そこで下図のように、空白のだ円でそれを表現する:

Property with structured valueD

図2: 構造化された値を持っているプロパティ

注: 前の注意で読みに対応して、この図は「http://www.w3.org/Home/Lassilaはある作成者を持ち、ある作成者は名前Ora Lassilaと電子メールlassila@w3.orgを持つ。」と読むことができる。

前の例の構造化されたエンティティーはユニークな識別子を割り当てられることもできる。識別子の選択はアプリケーションデータベースデザイナーによってなされる。例を続けると、従業員IDがユニークな識別子として「人」というリソースのために使われると考えてみる。それぞれの従業員のためにユニークキー(組織によって定義される)の役をするURIは、http://www.w3.org/staffId/85740のようなものであるかもしれない。今、2つの文を書くことができる:

従業員id 85740によって参照された個人の名前はOra Lassilaであり、電子メールアドレスlassila@w3.orgを持っている。リソースhttp://www.w3.org/Home/Lassilaはこの個人によって作られた。

これらの文のためのRDFモデルは次のようになる:

Structured value with identifierD

図3: 構造化された値と識別子

この図が、以前の名無しのリソースにURIの付加をした前の図とまったく同じであることに注意。このモデルを検索する二次的なアプリケーションの立場からは、ひとつの文で作られたステートメントと、2つ以上の文で作られたステートメントの間の区別はない。 しかしながら若干のアプリケーションは、このような区別ができる必要があるだろう。そしてRDFはこのようなアプリケーションをサポートする。それ以上の細部については4章 ステートメントについてのステートメントを参照されたい。

2.2 基本的なRDF文法

RDFデータモデルはメタデータを定義し、使用するために抽象的、概念的なフレームワークを提供する。このメタデータを生成し、そして交換するためには具体的な文法も必要である。RDFのこの仕様は、その交換文法として拡張可能なマークアップ言語[XML]コーディングを使う。RDFはまた、正確にそれぞれのプロパティとプロパティを定義するスキーマとを結び付けるXMLネーム空間ファシリティを必要とする;2.2.3章, Schemas and Namespacesを参照されたい。

必須のRDF文法要素を記述するため[XML]の6章 Notationで定義されるように、このドキュメントでの文法解説は拡張されたバッカス・ナウア記法表記法を使う。 ここでのEBNFは人が読み易い様に要約される;特に、イタリック体で書かれた「rdf」はより正確なBNF 記法「'<' NSprefix ':...'」よりも、可変的なネーム空間接頭辞を表すために使われる。 エンドタグのプロパティと型名は、それに対応するスタートタグの名前と正確にマッチする、という必要条件は、XML規則によって暗示される。XML のすべての文法的柔軟性も、同じように暗黙のうちに含まれている;例えば、スペース規則、シングルクォート(’)あるいはダブルクォート(”)のいずれかを使っている引用、 キャラクタエスケープ、ケースセンシティビティ、言語タグ付けである。

RDFデータモデル事例のコード化に対して、この仕様は2つのXML文法を定義する。一連番号文法は非常に規則的な様式でデータモデルのフルの能力を表わす。省略形文法はデータモデルのサブセットを表現するためにいっそう簡潔なフォームを提供する追加の概念を含む。RDF インタプリターは、フルの一連番号文法と省略形文法との両方を実行することを期待される。 従って、メタデータの著者はこの2つを自由に混ぜることができる。

2.2.1.基本的な一連番号文法

単独の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, interpreted per [URI]
 [12] IDsymbol       ::= (any legal XML name symbol)
 [13] name           ::= (any legal XML name symbol)
 [14] NSprefix       ::= (any legal XML namespace prefix)
 [15] string         ::= (any XML text, with "<", ">", and "&" escaped)

RDF要素はXMLドキュメントに境界を作る単純なラッパーである。そしてXMLドキュメント間でその内容をRDFデータモデル事例に明らかに描かれるよう、意図されている。もし内容がアプリケーションコンテキストからのRDFであることを知られていることができるなら、RDF要素は任意である。

Descriptionは、モデル事例で文の作成をもたらすような残存要素を含んでいる。Description要素は、(基本的なRDF文法の目的のために)ただ記述されたリソースの識別を保持する場所であるとみなされる場合がある。 一般に、1リソースにつき1以上のステートメントが作られるだろう;Descriptionは、いくつかのステートメントにただ1度リソース名を与える方法を提供する。

about属性がDescriptionとともに指定されると、Description の中のステートメントは、識別子がaboutから決定されるリソースを参照する。about属性の値は、[URI]の4章毎にURI-referenceとして解釈される。その対応するリソース識別子は、[URI]によって指定されるように、絶対的な形式にURI-referenceを変換することによって得られる。 もしフラグメント識別子がURI-referenceに含まれるなら、リソース識別子は、リソースからなる対応するフラグメントID内部によって識別されたリソースのサブコンポーネントだけを参照する。([Dexter94]の最後を参照のこと)、 さもなければ識別子はURIによって指定された全部のリソースを参照する。 about属性のないDescription要素は、新しいリソースを表す。 このようなリソースは、識別可能なURIを持っていない何か他の物理的なリソースのための代理、あるいはプロキシである場合がある。 Description要素のID属性の値は、もし存在しているなら、この「インライン」リソースのアンカーidである。

もし別のDescriptionあるいはプロパティ値がインラインリソースを参照する必要があるなら、それは自身のabout属性の中でそのリソースのIDの値を使うであろう。 ID属性は新しいリソースの作成を示し、 about属性は、既存のリソースを参照する;そのため、IDあるいはaboutは、Description上に指定される場合があるが、同じ要素の中に一緒に指定されることはない。 それぞれのID属性のための値はひとつのドキュメントの中で1以上のID属性に現われてはならない。

単独のDescriptionが同じプロパティ名で1以上のpropertyElt要素を含んでいる場合がある。 このようなpropertyEltが図表にそれぞれ1つのアークを加える。この図表の解釈はスキーマデザイナーによって定義される。

propertyEltの中で、resource属性は何か他のリソースがこのプロパティの値であることを明示する;すなわち、ステートメントのobjectはリテラルではなく、URIによって識別される別のリソースである。 objectのリソース識別子はabout属性を得るために前述したものと同じように、resource属性URI-リファレンスを変換することによって、得られる。 Stringは適格なXMLでなければならない;もしストリングが適格性の規則に違反するか、さもなければマークアップのように見えるかもしれない文字列(例えば"<"と"&")を含んでいるなら、メカニズムを引用し、そしてそれから逃れている通常のXML コンテンツが使用される場合がある。マークアップがRDFによって解釈されないよう、マークアップを含む、適格なXML内容を持つプロパティ値指定のための追加の文法に関しては、6章を参照のこと。

プロパティ名はスキーマと結び付けられなくてはならない。ネーム空間接頭辞で要素名にプロパティ定義と対応するRDFスキーマとを明瞭に結び付けるとみなされることによって、あるいは、[NAMESPACES]で指定されるように、デフォルトネーム空間を表わすことによって、プロパティ名とスキーマの結合が可能である。

2.1.1章からの例文

Ora Lassilaはリソースの作成者である。http://www.w3.org/Home/Lassila.

は、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という名前のプロパティを定義することがある、そして2つのプロパティはそれらのスキーマ識別子によって区別されるであろう。 またスキーマが通常いくつかのプロパティを定義することに注意されたい;単独のネーム空間宣言は、プロパティの多くの用語の使用を可能にするのに十分であろう。

上の記述を含んでいる完全な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>

RDFネーム空間それ自身のために[NAMESPACES]で定義したデフォルトネーム空間文法の使用すると、このドキュメントは、同じく次のように書くことができる:

<?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フラグメントは、完全に独立できるようにRDF/XMLフラグメントが使うすべての ネーム空間 をはっきりと示すべきであることに注意を払われたい。読み易い様に、この章の残りの中に紹介している例は、説明している特定のポイントを不明瞭にしないためにネーム空間宣言を省略する。

2.2.2 基本的な省略形文法

一連番号文法は、最も明確にRDFモデルの構成を示すが、時々よりいっそう簡潔なXML形式を使うことが望ましい。RDF の省略形文法はこれを実現する。それ以上の利点として、省略形文法は、ある特定のうまく組み立てられたXMLDTDsに従っているドキュメントを、RDFモデルとして直接解釈することができる。

略語の3つの形式が基本的な一連番号文法のために定義される。 第1は、Descriptionとそれらのプロパティの値がリテラルである中で繰り返されないプロパティの使用の便利さである。 この場合、プロパティはDescription要素のXML属性として書かれることがある。その時前述の例は以下のようになる:

<rdf:RDF>
	<rdf:Description about="http://www.w3.org/Home/Lassila"
			s:Creator="Ora Lassila" />
</rdf:RDF>

CreatorプロパティがXML属性形式で書かれてしまえば、Description 要素が他のどのような内容も持っていないので、XMLの空の要素文法がDescription エンドタグを省くために用いられることに注意されたい。

ここにもう1つのこの同じ省略形式の使用の例がある:

<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>

これらの2つのRDF式が同等であるのに対して、それらが他の処理エンジンによって違う扱われかたをする場合があるということに注意されたい。 特に、もしこれら2つの式がHTMLドキュメントの中に埋め込まれていたなら、 non-RDF-aware ブラウザのデフォルトの振舞いは、最初のケースでのプロパティの値を表示するが、2番目のケースでは表示されたテキストがあるべきではない(あるいはせいぜいスペース文字)。

2番目のRDFの省略形式は収められたDescription要素に働く。 ステートメントのobjectが別のリソースであり、この2番目のリソースのためのインラインに与えられたあらゆるプロパティの値が連続していれば、この省略形式は特定のステートメントのために使用することができる。この場合、XML属性の中へのXML要素名の類似の変換が使われる:収められたDescriptionでのリソースのプロパティは、そのDescriptionを含んだpropertyElt要素のXML属性として書かれることがある。

2.1.1 章の2番目の例文

The individual referred to by employee id 85740 is named Ora Lassila and has the email address lassila@w3.org. The resource http://www.w3.org/Home/Lassila was created by this individual.

を、明確な一連番号形式を使って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つに分かれているリソースが記述されていることを読み手に明確にする、しかし2番目のリソースが最初のdescriptionの中で使われることは、それほど明確ではない。この関係を人が読むのによりわかりやすくするため、この同じ式を次の方法で書くことができた。マシンに、相違がないことに注意する:

<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>

この省略形式を使うとき、URIによって名前をつけられたリソースが両方のケースでCreatorプロパティの値であるとき、収められたDescription要素のabout属性はpropertyElt要素上のresource属性になる。RDFソースで上の3つの形式のどれが使われるかは、完全に書き手の好みの問題である。それらはすべて同じ内部的なRDFモデルを作り出す。

注意:このドキュメントの残りを勉強した観察力が鋭い読者は、ステートメントの明確な構文的分類を維持するためにDescription要素によって示される若干の付加的な関連があるのが分かるだろう。従って上の3つの形式は、重要でない方法においてはこの章での解説と少し異なっている。これらの相違は4章で記述されるように高次ステートメントを作るときにだけ重要になる。

3番目の基本的な省略形は、typeプロパティを含むDescription要素の共通のケースに当てはまる(typeの意味に関しては4.1章を参照)。 この場合、typeプロパティの値に対応しているスキーマで定義されたリソース種別は、要素名として直接用いられることができる。例えば、前述のRDFフラグメントを使って、もしリソースhttp://www.w3.org/staffId/85740が示す人間のインスタンスであるという事実を加えるならば、フルの一連番号文法でこれを次のように書くであろう:

<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 '>'

2.2.3.スキーマとネーム空間

我々が自然な言語で文を書くとき、ある意味を伝達する単語を使う。 その意味は、ステートメントを理解するのにきわめて重要であり、そして、RDF のアプリケーションの場合では、意図されるような正しい処理の発生を確立するのにきわめて重要ある。ステートメントのライタとリーダ両方が、Creator、approvedBy、コピーライトなどのような使用された用語を同じ意味に理解することはきわめて重要である、さもないと結果として混乱が生じるであろう。World Wide Webのような世界的なスケールのメディアでは、「creatorship」のようなコンセプトの共有された文化的な理解に頼ることでは十分ではない;可能な限り正確であるために注意を払う。

RDFでの意味がスキーマにリファレンスを通して明示される。スキーマを一種の辞書であると考えることができる。スキーマがRDF ステートメントで使われる用語を定義し、そしてそれらに特定の意味を与える。さまざまなスキーマ形式は、RDFを使って使用される。それには、RDFを使って自動化を可能にする若干の特定の 特徴を持つ別々のドキュメント[RDFSchema]で定義した特定のフォームがある。

スキーマは、プロパティの使用法の定義と制限が文書化される所である。同じ用語の独立した−そして多分相いれない−定義の間に混乱を避けるために、RDFはXMLネーム空間ファシリティを使う。ネーム空間は、ただコンテキストにおける単語の特定の用途を、意図した定義が見いだされる辞書(スキーマ)に結び付ける方法である。RDFで、ステートメントで使われたそれぞれのpredicateが正確に1つのネーム空間、あるいはスキーマと判断されなくてはならない。しかしながら、 Description要素は、多くのスキーマからpredicateを伴うステートメントを含んでいることがある。1以上のスキーマを使うRDF Descriptionsの例が7章に出ている。

2.3. 制限されたプロパティ値

しばしばプロパティの値はその値の「一部」であると思われる追加の文脈上の情報を持っている何かである。換言すれば、プロパティ値を制限する必要がある。 このような制限の例は、計量単位、特定の限定された用語、あるいは何か他の注釈に名前をつけることを含む。 若干の使用には、制限なしでプロパティ値を使うことは適当である。 例えば、ステートメント「その鉛筆の価格は75U.S.セントである」では、単に「その鉛筆の価格が75である」と言えば、十分である時もある。

RDF モデルで、制限的プロパティ値は、単に構造化された値のもう1つのインスタンスである。オリジナルのステートメントのobjectは、この構造化された値であり、制限はこの共通リソースのそれ以上のプロパティである。 制限されている主要な値はこの共通のリソースのvalueプロパティの値として与えられる。valueプロパティの使用例に関しては7.3章 非2項関係を参照のこと。

3. コンテナ

しばしばリソースの集まりを参照することは必要である;例えば、仕事は1人以上の人によってなされたと言うこと、あるいは1つのコース中の学生や、1パッケージ中のソフトウェアモジュールの一覧表を作るということである。 RDFコンテナは、このようなリソースあるいはリテラルのリストを保持するために使われる。

3.1 コンテナモデル

RDFはコンテナobjectの3つのタイプを定義する:

Bag リソースあるいはリテラルの無秩序なリスト。 Bagは、プロパティが多数の値を持っていること、そして値が与えられているオーダーに意味がないと明かに示すために使われる。 Bagは、パーツを処理するオーダーが重要ではないパート番号のリストを与えるために、使われるかもしれない。重複値が許される。
Sequence リソースあるいはリテラルの整然としたリスト。 Sequenceは、プロパティが多数の値を持っていること、そして値のオーダーが重要であることを明かに示すために使われる。 Sequenceは、例えば、値をアルファベット順に維持するために使われる場合がある。重複値が許される。
Alternative   リソースのリストあるいはプロパティの(シングル)値のために選択肢を表すリテラル のリスト。 Alternativeは、仕事のタイトルに代わりの言語翻訳を提供することか、あるいはリソースが見いだされるかもしれないインターネットミラーサイトのリストを提供することのために使われることがある。 その値がAlternativeの集まりであるプロパティを使用するアプリケーションは、リストの中の項目のどれでも適切であるとして選ぶことができるという認識がある。
注意:BagSequenceの定義は明かに重複値を許す。RDFは、重複がないBagであろうSetのコア概念を定義しない、なぜならRDFコアはこのような制約条件の違反が生じたとき、執行機構に権限を与えないから。RDFコアの上に積み重ねられる将来の仕事が、このようなファシリティを定義することがある。

リソースの収集を表すために、RDFは特定の収集を識別する追加のリソース(オブジェクトモデリング用語での集まりであるインスタンス)を使う。 このリソースは、上記に定義されるコンテナobjectタイプの1つの事例であると示されなくてはならない。下記で定義されているtypeプロパティは、この明示をなすために使われる。 このコンテナリソースとこの集まりの中に属するリソース間のメンバーシップ関係は、この目的のために特別に定義されたプロパティのセットによって定義される。 これらのメンバーシッププロパティは、単に"_1","_2","_3"等と名付けられる。 コンテナリソースは、メンバーシッププロパティとtypeプロパティのほかに他のプロパティを持っていることがある。 このような追加のステートメントがコンテナを記述する;メンバーそれら自身のそれぞれについてのステートメントのディスカッションに関しては3.3章、Distributiveリファレント、を参照のこと。

コンテナの共通の用途は、プロパティの値としてである。 このようにして使われるとき、ステートメントにはコンテナの中メンバーの数にかかわらずまだ単独のステートメントobjectがある;コンテナリソース自身はステートメントのobjectである。

例えば、文を表現するために

コース6.001での学生(students)はエイミー、ティム、ジョン、メアリーとスーである。

RDFモデルは、

Simple Bag containerD

図4: 簡単なBagコンテナ

Bagコンテナは同じtypeの繰り返されたプロパティと等しくない;相違のディスカッションに関しては3.5章を参照のこと。 著者は、ケースバイケースで、どれ(繰り返されたプロパティステートメントあるいはBag)が使うのにより適切であるか決める必要があるであろう。

X11のソースコードはftp.x.org、ftp.cs.purdue.edu、あるいはftp.eu.netにある場合がある。

は、次のようにRDFでモデルされる

Simple Alternative containerD

図 5: 簡単なAlternativeコンテナ

Alternativeコンテナは言語タグと共に頻繁に使われる。 そのタイトルがいくつかの言語に翻訳された仕事は、それぞれの言語変形を保持しているAlternativeコンテナを指し示しているタイトルプロパティを持っているかもしれない。

3.2 コンテナ文法

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などの必要なものとして、割り当てる。要素名liHTMLから用語「リスト項目」でニモニックであるように選ばれた。

Altコンテナは、少なくとも1つのメンバーを持つことを必要とされる。このメンバーはプロパティ_1によって識別されるであろう、そしてデフォルトあるいは優先の値である。

注意:RDFスキーマ仕様[RDFSCHEMA]はまたこれらのコンテナタイプの追加のサブクラスを示すためのメカニズムを定義する、そしてその場合プロダクション[18]がそれらの明示されたサブクラスの名前を含むために拡張される。属性形式に、リテラル値を書くための、構文もある;6章でのフルの文法を参照のこと。

3.2.1 例

文のためのモデル

コース6.001での学生(students)はエイミー、ティム、ジョン、メアリーとスーである。

は、RFD/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>

この場合、学生プロパティの値が1つの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のためのコンテナ値でリストしたどの項目でも、他の項目に関係なく受容できる値である。

3.3 分散型 リファレント:コンテナのメンバーについてのステートメント

コンテナ構成がステートメントについての問題を提議する:ステートメントが集まりに関係して作られるとき、ステートメントはどんな「もの」を記述しているか?あるいは換言すれば、どんなobjectがステートメントを参照しているのか?ということである。 ステートメントはコンテナそれ自身を記述しているか、あるいはステートメントはコンテナのメンバーを記述しているか?記述されているobject(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ページの作成者であると表現している。しかしそれは、個別のページ、Bagのメンバーについて何もふれていない。 Descriptionのリファレントはコンテナ(Bag)であり、そのメンバーではない。 1つは時々、コンテナそれ自身の代わりに、個々に含まれたobjectのそれぞれについてのステートメントを書くことを好むであろう。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>

望ましい意味を得るだろう。新しいリファレントタイプを分散型リファレントと呼ぶ。分散型リファレントは、RDFDescriptionで「構造を共有する」ことをできるようにする。 例えば、すべてが多くの共通のステートメントパーツ(predicateとobject)を持ついくつかの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>

3.4.URIパターンによって定義されるコンテナ

メタデータの1つの非常に頻繁な使用は、「私のWebサイトにおける全ページ」、あるいは「私のWebサイトのこのブランチのすべてのページ」についてステートメントを作ることである。 多くの場合、明示的にそれぞれこのようなリソースをリストし、それがコンテナのメンバーであると識別しようとすることは、非実用的であるか、それどころか望ましくない。 従ってRDFには2番目の分散型リファレントタイプがある。この2番目の分散型リファレントタイプは、当然そのメンバーがすべてのリソースであり、そのリソース識別子が指定されたストリングから始まるBagの事例を表す短縮形文法である:

  [26a] aboutEachAttr  ::= 'aboutEach="' URI-reference '"'
                         | 'aboutEachPrefix="' string '"'

メンバーが、属性の値として与えられた文字列で始まるリソース識別子が、完全に変換されているすべてのリソースであるBagがあることを、 aboutEachPrefix属性は、明らかに示す。aboutEachPrefix属性を持っているDescriptionでのステートメントは、このBagのメンバーのそれぞれに個々に当てはまる。

例えば、もし2つのリソースのhttp://foo.org/doc/page1とhttp://foo.org/doc/page2が存在するなら、以下のように書くことによって、それらのそれぞれがコピーライトプロパティを持っていると言うことができる

<rdf:Description aboutEachPrefix="http://foo.org/doc">
	<s:Copyright>(C) 1998, The Foo Organization</s:Copyright>
</rdf:Description>

もし、その文字列から始まるURLであるリソースが、ただ2つだけあるなら、上記のものは、次のAlternativeの両方ともと等しい:

<rdf:Description about="http://foo.org/doc/page1">
	<s:Copyright>(C) 1998, The Foo Organization</s:Copyright>
</rdf:Description>
<rdf:Description about="http://foo.org/doc/page2">
	<s:Copyright>(C) 1998, The Foo Organization</s:Copyright>
</rdf:Description>

そして

<rdf:Description aboutEach="#docpages">
	<s:Copyright>(C) 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>

3.5. コンテナ対繰り返されたプロパティ

リソースは、同じpredicateで多数のステートメントを持っていることがある。(例えば、同じプロパティを使う。)これは、そのobjectが多数のメンバーを含んでいるコンテナであるひとつのステートメントを持つことと同じではない。 特定の事情でいずれを使うべきかについての選択は、一部スキーマを設計する人と、一部特定のRDFステートメントを書く人によってなされる。

作家とその作家の出版物との関係の例を考えよ。次のような文があるとすると、

スーは「時間のアンソロジー(Anthology of Time)」、「動物学の推論(Zoological Reasoning)」、 「重力の反射(Gravitational Reflections)」を書いた。

すなわち、同じ作家によって書かれたそれぞれ独立した3リソースがある。

Repeated propertyD

図6:繰り返されたプロパティ

この例には、それらが同じ人によって書かれたこと以外、出版物の間の関係は書かれてない。

反対に

Fred、WilmaとDinoの委員会は決議を承認した。

という文は、ある方法で、3人の委員会メンバーが全体として投票したと言っている;それは、必ずしもそれぞれの委員会メンバーが条項に賛成して投票したとは述べていない。 この文が、それぞれ個々のメンバの票決の結果を述べているので、3つの別々のapprovedByステートメント(つまり委員会のメンバーの1人ずつという意味での)として、この文をモデルすることは正しくないであろう。 むしろ単独のapprovedByステートメントのobjectが、委員会メンバーのアイデンティティを含むBagであり、そのapprovedByステートメントとして、この文をモデルするほうが良い:

Using Bag to indicate a collective opinionD

図7: 総意を示すためのBagの使用

Bagあるいは繰り返されたプロパティのいずれの表現を使うべきかについての選択は、スキーマを考慮した後で、メタデータを作っている人によってなされる。 例えばもし、上記の出版物の例で、それらが出版物の完全セットであったと言うことを望んだなら、スキーマはその目的のために出版物と呼ばれるプロパティを含むかもしれない。出版物プロパティの値は、スーの仕事のすべてをリストする1つのBagになるであろう。

4 ステートメントについてのステートメント

Webリソースについてのステートメントを作ることに加えて、RDFは他のRDF ステートメントについてのステートメントを作るために使うことができる;これらを高次ステートメントとして参照する。 もう1つのステートメントについてのステートメントを作るために、実際にオリジナルのステートメントのモデルを構築しなければならない;このモデルは、追加のプロパティを加えることができる新しいリソースである。

4.1 モデリングステートメント

ステートメントはリソースについて作られる。 ステートメントのモデルは、設計されたステートメントについての新しいステートメント(高次ステートメント)を作ることを可能にするために必要とするリソースである。

例えば、次の文を考えよう

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 にこの事実を明示するために、4つのプロパティでリソースとしてのオリジナルのステートメントをモデルしなければならない。このプロセスは知識表現集合体で正式には具体的なものと呼ばれる。ステートメントのモデルは具体的なステートメントと呼ばれる。

ステートメントをモデルするためにRDFは次のプロパティを定義する:

subject subjectプロパティは設計されたステートメントによって記述されているリソースを識別する;すなわち、subjectプロパティの値はオリジナルのステートメントが作られたリソースである(例 http://www.w3.org/Home/Lassila)。
predicate  (述語) predicateプロパティは設計されたステートメントのオリジナルのプロパティを識別する。 predicateプロパティの値はオリジナルのステートメントの特定のプロパティを意味するリソースである(例:作成者)
object objectプロパティは設計されたステートメントでのプロパティ値を識別する。objectプロパティの値はオリジナルのステートメントでobjectである(例、Ora Lassila)。
type   (型) typeプロパティの値は新しいリソースのtypeを記述する。すべての具体的なステートメントはRDF:Statementの事例である;すなわち、それらにはそのobjectがRDF:Statementであるtypeプロパティがある。3章「コンテナ」に示したように、typeプロパティも、あらゆるタイプのリソースを明らかに示すためにより一般的に使われる。

上記の4プロパティを有する新しいリソースは、オリジナルのステートメントを表し、そして他のステートメントのobjectとして用いられることも、それについて追加のステートメントを作ることもできる。 これらの4プロパティを有するリソースは、オリジナルのステートメントの置換ではない、それはステートメントのモデルである。ステートメントとその対応する具体的なステートメントはRDF図表で独立して存在し、いずれかがもう一方なしで存在していることがある。対応する具体的なステートメントが存在しているかどうかにかかわらず、RDF 図表は、もしステートメントが図表に存在している場合に限り、そしてその場合には必ず、ステートメントで与えられた事実を含んでいると言える。

以上の事例を形にするために、適切な値でもう1つのプロパティを具体的なステートメント(「attributedTo」という)に付加することができた(この「Ralph Swick」のケースで)。基本的な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章で、ステートメントについてステートメントを作るための短縮形を示す。

Representation of a reified statementD

図8: 具体的なステートメントの表示

具体化も、明確にDescription要素によって暗示されたステートメントのグルーピングモデルで表すために、必要とされる。RDF図表モデルは、Descriptionのために特別な構造を必要としない;Descriptionが、本当はステートメントの集まりであるので、Bagコンテナはステートメントのセットが同じ(文法的に)Descriptionから来たことを示すために使われる。 Descriptionの中のそれぞれのステートメントが、具体化され、具体的なステートメントのそれぞれがそのDescriptionを意味するBagのメンバーである。例として、RDFフラグメントは、

<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>

図9で示した図表となるだろう。

Using Bag to represent statement groupingD

図9: ステートメントグルーピングを表現するためにBagを使う

新しい属性bagIDに注意されたい。この属性はコンテナリソースのリソースidを指定する:

  [2b] description    ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>'
                        | '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>'
                              propertyElt* '</rdf:Description>'
  [27] bagIDAttr      ::= 'bagID="' IDsymbol '"'

BagIDIDを混乱してはならない。IDは、そのプロパティがDescriptionでさらに詳述されるインラインリソースのアイデンティフィケーションを指定する。BagIDは、そのメンバーが別のリソースについての具体的なステートメントであるコンテナリソースのアイデンティフィケーションを指定する。Descriptionは、ID属性とbagID属性の両方を持っていることがある。

4.2.ステートメントについてのステートメントの文法的な短縮形

bagIDDescriptionに付けることはモデルにDescriptionの具体的なステートメントのBagを含めるという結果をもたらすので、ステートメントについてのステートメントを作るとき、これを文法的な短縮形として用いることができる。例えば、もし、Oraはhttp://www.w3.org/Home/Lassilaの作成者であるとRalphが述べることと、また彼がそのリソースのタイトルは「Oraのホームページ」であると述べることを言いたいならば、ただ上記の例に追加することができる

<rdf:Description aboutEach="#D_001">
	<a:attributedTo>Ralph Swick</a:attributedTo>
</rdf:Description>

この短縮形の例は、図8の例では示していないモデルの中に追加の事実を含んでいるということに注意されたい。 この短縮形使用法はラルフのステートメントについて事実、そしてOraのホームページについて同じく事実を表現する。

Representing statements about statementsD

図10: ステートメントについてのステートメントの表現

読者は、高次ステートメントと具体化をより正式に処理するため、この仕様書の5章("Formal Model")5章(「形式モデル」)を参照のこと。

5.RDFのための正式モデル

この仕様書は、3組(トリプル)とグラフとXMLとの、3つのデータモデルの表現を示している。これらの表現は同等の意味を持っている。 この仕様で使われた表現と表現の間のマッピングはどんな場合でもインプリメンテーションによって使われた内部表現を制限するように意図されてはない。

RDFデータモデルは次のように公式に定義される:

  1. リソースと呼ばれるセットがある。.
  2. リテラルと呼ばれるセットがある。.
  3. プロパティと呼ばれるリソース のサブセットがある。.
  4. ステートメントと呼ばれる、セットがある。そのステートメントのそれぞれの要素は{pred、sub、obj }というトリプルの形式となっている。

    pred がプロパティ(プロパティの一部)の場合、subがリソース(リソースの一部)であり、 そして obj がリソースあるいはリテラル(リテラルの一部)である。

ステートメントのセット(ステートメントのメンバ)を方向付けられた標示付きの図表だと 見なすことができる:それぞれのリソースとリテラルが頂点である; トリプル{p、s、o}が、p.に区別され、sからoへのアークである。 これは図11で例証する。

statement graph templateD

図11: 単純なステートメント・グラフ・テンプレート

これは同様に次のように読める。

oはsのためのpの値である。

あるいは(左から右へ)

sはoと同じ値を持つプロパティpを持っている

または

sのpはoである

とも読める。

例えば、

リソースhttp://www.w3.org/Home/Lassilaの作成者はOra Lassilaである。 という文は、

次のような図表で描ける。

Simple statement graphD

図12: 単純なステートメント・グラフ

そして対応するトリプル(ステートメントの要素)は作成者であり、{creator, [http://www.w3.org/Home/Lassila],"Ora Lassila"}であるだろう。

{creator,[http://www.w3.org/Home/Lassila], "Ora Lassila"}

表記法[I]はURLIによって識別されたリソースを意味する、そして引用符が リテラルを意味する。 {creator,[http://www.w3.org/Home/Lassila],"Ora Lassila"}

トリプルを使って、(4章で紹介したように)どのようにステートメントが具体化されるかを 説明することができる。

ステートメント

{creator,[http://www.w3.org/Home/Lassila],"Ora Lassila"}

を考えると、下記のようにこの具体性を新しいリソースXとして説明することができる:

{type,[X],[RDF:Statement]}
{predicate,[X],[creator]}
{subject,[X],[http://www.w3.org/Home/Lassila]}
{object,[X],"Ora Lassila"}

RDFプロセッサの見地から、事実(すなわち、ステートメント)はステートメントのメンバー であるトリプルである。そのため、オリジナルステートメントを示すトリプルがステートメント内に残っているので、 トリプルから具体化されているにもかかわらず、オリジナルステートメントは事実を残している。ただもう4つのトリプルを加えた。

「type」という名前のプロパティはプリミティブなタイピングを提供するために定義される。 typeの正式の定義は以下のようになる。:

  1. RDF:typeとして知られているプロパティの要素がある。
  2. 形式のステートメント{RDF:type,sub,obj}のメンバーが次のことを満たさなくてはならない:sub objはリソースのメンバーである。 [RDFSchema] はtype使用に制限を追加する。

さらに、具体化することの形式仕様は下記のようになる。:

  1. RDF:Statementとして知られているプロパティに含まれないリソース の要素がある。
  2. プロパティには、RDF:predicate、RDF:subject、RDF:objectとして知られている3つの要素がある。
  3. ステートメントのトリプル{pred、sub、obj}の具体化は、具体的なトリプルと下記に示す要素s1、s2、s3、s4を表わすリソースの要素rである。

    s1: {RDF:predicate, r, pred}
    s2: {RDF:subject, r, subj}
    s3: {RDF:object, r, obj}
    s4: {RDF:type, r, [RDF:Statement]}

上記の定義ではリソースrは具体的なステートメントと呼ばれるている。 リソースが具体的なステートメントを表すとき、すなわち、それは、RDFステートメントの値を持ったRDFtypeのプロパティである。そして、次にそのリソースが正確に、1つのRDF:subjectプロパティと、 1つのRDF:objectプロパティと、1つのRDF:predicateプロパティを持たなければならない。

3章で記述したよう、リソースあるいはリテラルの集まりを表すことは頻繁に必要となる;例えば、プロパティが規則 正しい連続した値を持つということである。RDFは3つの種類の集まりを定義する:Sequencesと呼ばれる規則正しいリスト、Bagsと呼ばれる無秩序なリスト、 Alternativesと呼ばれるプロパティの(シングル)値の代わりを表現しているリスト である。

公式に、これらの3つの収集typeは下記のように定義される:

  1. RDF:BagとRDF:Altとして知られているプロパティには含まれないリソースの 3つの要素がある。
  2. Ordと呼ばれる序数(1、2、3、...)に対応しているプロパティ のサブセットがある。RDF:_1、RDF:_2、RDF:_3、RDF:Seqのように Ordの要素を参照する。

収集cのを表わすためには、tが3つの収集type RDF:Seq、RDF:Bag、RDF:Alt のうちの1つであるトリプル{RDF:type、ct}を作る。 残りのトリプルが、{RDF:1、cr1}、{RDF:-n、crn}、...収集メンバrnのそれぞれを指し示す。 ひとつの収集リソースに対し、PredicateにOrd要素が与えられているトリプルが多くて1つはあることがある。 そしてOrdの要素はRDF_1から始まり、連続して使われなければならない。 リソースは、RDF:Alt収集typeの実例であるリソースのために、PredicateがRDF_1であるトリプルが正確に1つなければならない。 そして、(いつでも少なくとも一つの選択肢に違いない)であろうそれはAlternativesリソースとしてのデフォルト値である。

6.RDFのための正式な文法

RDFの完全なBNFは、前の章からここで再生される。正式なモデルに関する文法 の正確な解釈も同様に与えられる。XMLから継承された構文的な特徴がここでは再生されない。 これらには、属性値の周りの2つか1つの引用の使用と同じように、適格な制約、属性の周りのスペースと「=」の使用を含んでいる。 この章はRDF/XML構文論を読んで、解釈するツールを作っているインプリメンタのために意図しているつもりである。

以下に使用する場合は、[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 '"' (with embedded quotes escaped)
 [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, interpreted per [URI]
 [6.21] IDsymbol       ::= (any legal XML name symbol)
 [6.22] name           ::= (any legal XML name symbol)
 [6.23] NSprefix       ::= (any legal XML namespace prefix)
 [6.24] string         ::= (any XML text, with "<", ">", and "&" escaped)
 [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 '"' (where n is an integer)
 [6.32] parseLiteral   ::= ' parseType="Literal"'
 [6.33] parseResource  ::= ' parseType="Resource"'
 [6.34] literal        ::= (any well-formed XML)

この仕様で定義したプロパティとクラスの正式のネーム空間名はhttp://www.w3.org/1999/02/22-rdf-syntax-ns#である。 RDFプロセッサは、XML要素あるいは属性名と出逢う。その属性名はその名前がストリング"http://www.w3.org/TR/REC-rdf-syntaxで始まるネーム空間より明らかにされる。 そして、プロセッサは、その名前の意味を認識しない。 そして、プロセッサは、(tuplesを生成しないように)その名前が認められないか、または、その名前が認められない属性を持っているという コンテンツを含めてのXML要素を省略する必要がある。

Description要素によって含まれたそれぞれのpropertyEltEはトリプル{p、r、v}の生成をなした。それは次の場合である。

  1. pはEのネーム空間−資格のあるタグ名(一般的な識別子)の展開したものである。その展開は、 修飾名のLocalPartと一緒にネーム 空間明示で与えられたネーム空間名を連結することによって、生成される。
  2. rは
  3. もしEが空の要素(コンテンツが無い)なら、vは、その識別子がEのリソース属性によって与えられるリソースである。もしEのコンテンツがXMLマークアップを含んでいないか、あるいはparseType=「リテラル」がEのスタートタグで指定されるなら、vがEのコンテンツ(リテラル)である。そうでなければ、Eのコンテンツは別のDescriptionあるいはコンテナであるに違いない、そしてvが(多分暗黙の)IDによって、あるいはそのDescriptionによって、あるいはコンテナによって名前をつけられたリソースである。

parseType属性が要素コンテンツの解釈を変える。parseType属性は値「リテラル」あるいは「リソース」の1つを持っているべきである。その値は、大文字小文字の違いを識別する。値「リテラル」は要素のコンテンツがRDF/XMLリテラルとして処理されることを明示する;すなわち、コンテンツがRDFプロセッサによって翻訳されてはならないということである。値「リソース」は要素のコンテンツがDescription要素のコンテンツであるかのように、処理されなくてはならないことを明示する。parseTypeの他の値がRDFによって将来の仕様のために確保される。RDF1.0では、他の値が「リテラル」とまったく同じであるとして扱われなくてはならない。例外なく、parseType属性を持つ要素のコンテンツは、適格なXMLであるに違いない。parseType=「リソース」属性を持っている要素のコンテンツは、Description要素のコンテンツのためにさらにプロダクションと調和しなくてはならない。

RDFモデルとSyntax Working GroupはparseType=「リテラル」メカニズムがXMLマークアップを持っている値であるRDFステートメントを表現する要求事項に対する最小レベルの解決策であるということを認めている。スペースの標準化のようなXMLの付加的な複雑さは、まだ明瞭ではない。W3Cのこれからの仕事がXMLに基づいてすべてのアプリケーションのために同一の方法でこのような問題を解決することが予想される。RDFのこれからのバージョンがこの仕事を継承するであろう、そして、それ以上のアプリケーション経験から洞察を得るように、それを拡張するかもしれない。

RDFステートメントが現われるドキュメントの基本のURLを使って[URI]で指定した絶対形式へURI-Referencesを 最初に分解することによって、URI-Referencesはリソース識別子に分解される。もしfragment識別子がURI-referenceに含まれるなら、リソース識別子はリソースを含んでいるsubcomponentにだけ言及する。;このsubcomponentはリソースを含んでいる方へそれに対応した最後のid内部によって識別される、そしてsubcomponentの限度はリソースを含んでいるコンテンツの型と合致して、fragment識別子によって、定義される。そうでなければリソース識別子がURIによって明示された全部の項目に言及する。

注意:URI において非ASCII文字は、[URI],によって許されてないけれども、拡張URI文法で、[XML]は不必要な非互換性を避けるために規則を明示される。RDFのインプリメンタがそれ以上の非互換性を避け、そしてシステム識別子のためにXML規則を使うように促される。すなわち、URIでの非ASCII文字が1バイトあるいはそれ以上のバイト数でUTF-8内で表すことである。そして次にこれらのバイトは、URI escaping機構で逃避している。(すなわち、それぞれのバイトを、% HHに変換することによる。そして、その場合、HHはバイト値の16進法である。)

Description要素それ自身はBagリソースの事例を表す。このBagのメンバーはそのDescriptionにおいてそれぞれのステートメントの具体的なものに対応するリソースである。もしbagID属性が指定されるなら、その値はこのBagの識別子である、そうでなければBagは特徴がない。

aboutDescriptionで明示される時、Descriptionにおけるステートメントは、aboutで名付けられたリソースを参照する。about属性がないDescriptionの要素は、in-lineリソースを表す。このin-lineリソースは、もしあれば、Descriptionの要素のID属性の値と等しい最後のidを足したRDFステートメントを含んでいるドキュメントの基本のURLの値を使って形成されたリソース識別子を持っている。別のDescriptionあるいはプロパティ値がインラインリソースを参照するとき、それはabout属性で、IDの値を使うであろう。他のDescriptionは具体的なステートメント対応しているリソースのBagを参照するとき、それはabout属性でbagIDの値を使うであろう。IDaboutのどちらかがDescriptionで明示されても、同じ要素上には共存しない場合がある。IDbagIDの属性値はそれぞれ、1つのドキュメント内で、1つ以上の属性には表われないし、1つのドキュメント内でIDbagIDには同じ値を使うことがないこともある

aboutEachDescriptionで明示されるとき、DescriptionでのステートメントはaboutEachという名前のコナテナのメンバーのそれぞれに参照する。上記にDescriptionされたようにそれぞれ含まれたようなpropertyEltEによって表されるトリプル{p,r,v}は、コンテナのメンバであるそれぞれのrのために複写される。

aboutEachPrefixDescriptionで明示されるとき、Descriptionのステートメントは特徴のないBagコンテナのそれぞれのメンバーを参照する。このBagコンテナのメンバーは、その絶対の型のリソース識別子がaboutEachPrefixの値として与えられた文字列から始めるすべてのリソース識別子である。その絶対の形式のリソース識別子は、[URI]にて、5.2章Resolving Relative References to Absolute Formでアルゴリズムに従ってURIを解決することにより、作り出される。上記に示されたようにそれぞれに含まれたpropertyEltEによって表わされたトリプル {p,r,v}は、コンテナのメンバーであるそれぞれのrのために複写されるということである。

Seq,BagAltが、Sequence、Bag、あるいは、Alternativeコンテナリソース種別の例をそれぞれ表す。トリプル{RDF:type、c、t}がcが収集リソースであるところで作られる、そしてtはRDF:Seq、RDF:Bag、あるいはRDF:Altの1つである。集まりのメンバーはliによって示される。それぞれのli要素Eが集まりの1つのメンバーに対応し、トリプル{p、c、v}の作成をもたらす。それは以下の場合である。:

  1. pが、それぞれのコンテナのために、「RDF:_1」で始まるそれぞれのメンバーの語彙の外観の(XML)順序に従って連続して割り当てられる。
  2. cは収集リソースである。もし指定されるなら、ID属性は、c.のためにURL fragment識別子を用意する。
  3. (上に規則3と同じで)、もしEが空の要素(コンテンツがない)であるなら、vはその リソース識別子がE.のリソース属性によって与えられるリソースである。もしEのコンテンツがXMLマークアップを含んでいないか、あるいはもしparseType=「リテラル」Eのスタートタグで指定されるなら、vがE(リテラル)のコンテンツである。そうでなければ、Eのコンテンツは別のDescriptionあるいはコンテナであるに違いない。そしてvが(多分暗黙の)IDや、そのDescriptionaboutに、又はコンテナによって名前をつけられているリソースである。
URLは(分解の後に)ターゲットリソース、すなわち、Descriptionが適用するリソース、あるいはコンテナに含められるリソースを識別する。Descriptionの要素の上のbagID属性とコンテナ要素の上のID属性は、そのDescriptionあるいはコンテナが他のDescriptionによって参照されることを可能にしている。コンテナ要素上のIDは、そのプロパティ値の集まりを作るためプロパティ要素上にリソース属性内で使われる名前である。

propertyElt(プロダクション[6.12])の中で、リソース属性で使われたURIは(分解の後に)ステートメントの対象であるリソース(すなわち、このプロパティの値)を識別する。 ID属性の値は、もし指定されるなら、ステートメントの具体的なものを表すリソースの識別子である。 もしRDF式(すなわち、RDF/XMLマークアップを持っているコンテンツ)がプロパティの値として明示されるなら、オブジェクトは含まれたDescriptionabout属性か(多分暗黙に)含まれたDescriptionIDの属性か、コンテナリソースによってリソースを与えられたリソースである。 ストリングはよく形成されたXMLであるに違いない;もし、ストリングが適格な規則に反している、又は、マークアップのようにみえる文字列(例えば「<」と「&」)を 含んでいる場合、内容の引用とメカニズム(手順)から逃れている普通のXMLコンテンツが使用されることがある。 属性parseType=「リテラル」は要素のコンテンツがRDFリテラルであることを明示する。このコンテンツの一部であるあらゆるマークアップが リテラルの部分として包含されており、RDFによって解釈されない。

プロパティ名が常に対応したスキーマで、プロパティ定義を結び付けるためにネーム空間の接頭語で明瞭に制約することをすすめる。

XMLによって定義するように、RDFストリングの文字の量はISO/IEC10646[ISO10646]である。実際のRDFストリングが、XMLドキュメントであるいはRDFデータモデルの何か他の表現であっても、ISO/IEC10646の直接のコーディングあるいはISO/IEC10646にマップされることができるコーディングを使って格納されることがある。言語タグを付けることはストリング値の一部である;それはRDFストリングの中で文字のSequencesに適用されており、データモデルで明白な表示を持っていない。

もし、それらのISO/IEC 10646の表現がマッチするなら、2つのRDFストリングが同じであると思われる。それぞれのRDFアプリケーションがそれが「合う」の次の定義のどれを使うか明示しなくてはならない:

  1. 2つの表現は同一であるか、あるいは
  2. 2つの表現は規準的に、Unicode Standard[Unicode]によって定義されていることと同等である。
注意:W3C I18N WGは、ストリング同一性に関しての、定義に取り組んでいる。この定義はUnicode標準と、そして早くからの同一の標準化の原理によって最もありそうな規準的な同等なものに基づくであろう。RDFのユーザが規準的な同等物を使っているアプリケーション・マッチングに頼るべきではない、しかし、それらのデータが今度の定義に従って、正規形式であるということを確かにしようと試みるべきである。

この仕様は、このようなメカニズムが存在することを保証するか否かにかかわらず、マークアップを 含んでいるリテラルの間に同等物を決定する為に、メカニズムを述べているのではない。

[XML]によって定義されるように、xml:lang属性は言語を プロパティ値と関係づけるために使ってもよい。xml:lang(即ち、それはデータモデルにトリプルを加えないこと)のために特定のデータモデル表示がない。 ;リテラルの言語はRDFによってリテラルの一部であると考えられる。アプリケーションがストリングの言語タグを付けることを無視してもよい。 言語タグ付けが重要であろうとなかろうと、つまり文字照合又は他の処理を行う場合、言語が考慮されてもされなくても、すべてのRDFアプリケーションは明示されなくてはならない。

その名前がxmlnsで始まる属性はネーム空間明示であって、データモデル内でトリプルを表さない。このようなネーム空間明示のための特定のデータモデル表示はない。

それぞれのプロパティと値は、プロダクション[6.3]によってXML属性形式で表現した。そして、プロダクション[6.10]は、同じプロパティと等しい。そして、値は、プロダクション[6.12]に従って対応するDescriptionXMLコンテンツとして表現した。 特に;それぞれのXML属性Aは、属性ID,about,aboutEach,aboutEachPrefix,bagID,xml:lang以外で始まるDescriptionで指定された。あるいはキャラクタxmlnsから始めているどんな属性もトリプル{p、r、v}の作成において結果として生じる。
  1. pはA.のネーム空間によって修飾された属性名の拡張である。この拡張は、修飾名LocalPartであるネーム空間明示で与えられたネーム空間名を連結して、生成される。そして、[URI]の中で5.2章Resolving Relative References to Absolute Formにてアルゴリズムに従ってこのURIを分解している。
  2. rは、そのリソースの識別をもつリソースが、about属性値によって与えられ、上記に指定されるように解決されたリソースである。あるいは、リソースの最後のidがDescriptionのID属性の値によって与えられるか、あるいはaboutEachまたはaboutEachPrefix属性による集まりを明示したメンバーである。vはAの属性値(リテラル)である。

文法的に、プロダクション[6.11]はちょうどpropNameプロダクション[6.10]の特別なケースである。type属性の値は、URI-referenceと解釈されリソース属性の値として同じように拡張された。[6.11]の使用は、リソース属性とともにrdf:typeを要素(プロパティ)名として用いることに等しい。

typedNode形式(プロダクション[6.13])は特定のtypeのリソースの事例を表していて、そしてさらにそれらのリソースを記述するために使われることがある。typedNode形式で、プロダクション[6.13]によって表明されたDescriptionは、typeプロパティの値のDescriptionで、typeプロパティの値を足した、同じID,bagID,そしてabout属性は、識別子が十分に拡張され、typedNodeのtypeNameに対応して、URIを解決するリソースであるところのプロダクション[6.3]によって表明された同じDescriptionと同等である。特に、typedNodeがnがリソースであるトリプル{RDF:type、n、t}を表している。そのリソースの識別子は、about属性の値(分解後に)によって与えられる。または、そのリソースの最後のidはtypedNode要素のID属性の値によって与えられる。そして、tはネーム空間によって修飾されたタグ名の拡張である。typedNode属性とコンテンツの残りが、上記のDescription要素として処理される。

プロダクション[6.10]と[6.12]で空のXML要素Eの中でXML属性形式内で明示されたプロパティと値は、EのコンテンツになるべきひとつのDescription要素DのXMLのコンテンツとして、明示された同じプロパティと値とに等価である。 Dの対象は、プロダクション[6.17]、[6.2]、そして[6.3]に従ってEのXML要素名によって識別されたプロパティの値である。 特に、ID,resource,bagID,xml:lang、あるいは文字xmlnsから始めているある属性以外の属性仕様を含んでいるそれぞれのpropertyElt startタグは、トリプルのプロダクション{p、r1,r2}、{pa1,r2,va1}、...、 {pan,r2,van}をもたらす。
  1. pはネーム空間-qualifiedタグ名の拡張である。
  2. r1は、このpropertyElt式を含んでいる要素によって参照されるリソースである。
  3. r2は、もし存在しているか、あるいは新しいリソースであるなら、リソース属性によって名前をつけられたリソースである。もし、ID属性が与えられるなら、それはこの新しいリソースの識別子である。
  4. pa1...panは、ネーム空間で修飾した属性名の拡張である。
  5. va1...vanは、対応する属性値である。

もし指定されるなら、bagID属性の値は、DescriptionDに対応する Bagのための識別子である;ほかにBagは特徴がない。

7.例

次の事例は上記で説明したRDFの特徴をさらに例証する。

7.1 共有値

単独のリソースが1つ以上のプロパティの値であり得る;すなわち、それは1つ以上のステートメントであり得るしその結果、1つ以上のアークによって指し示されるオブジェクトであり得る。例えば、単独のWebページがいくつかのドキュメントと共有されることがあるし、1度以上「sitemap」で参照されるかもしれない。あるいは、同じリソースの2つの異なった(整然とした)Sequencesが 与えられるかもしれない。

かつて、発行年月日で分類し、再びアルファベット順にsubject別に分類した著者の著作集を明示した場合を考慮されたい。:

<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例は、ネーム空間接頭辞を省くためのデフォルト・ネーム空間明示文法も使う。

Sharing values between two sequencesD

図13: 2つのsequences間の共有値 

7.2 総計

さらに総計を例証するために、2人の著者がアルファベット順に指定したドキュメントの例、 2つの異なった言語で指定したタイトル、そしてWeb上の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>

	<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>

この例は収集の3つのtypeすべての使い方を例証する。作成者の順序は重要であると みなされるのでSequenceコンテナは、それらを保持するために使われる。Web上の位置は同等 である;順序は重要ではない、そのためBagが使われる。ドキュメントはただ単独の タイトルだけを持っており、そのタイトルは2つの変化形を持っている。そのため Alternativesコンテナを使う。

 注意:多くの場合、様々な言語の選択肢の間で望ましい言語を持つことは不可能である; すべての言語は厳密に同等であると考えられる。こういった場合、記述の著者はAlt コンテナの代わりにBagを使うべきである。

7.3 非2項関係

RDFデータモデルは本質的にただ2項関係をサポートするだけである;すなわち、ステートメントが2リソース間の関係を明示している。 次の事例で、2項関係を使って、RDF内のより高いarity関係を表わすために勧められた方法を示す。 推薦されたテクニックはこのリソースの追加のプロパティが残りの関係を与えるという状態で、中間のリソースを使うことである。 例として、ジョン・スミスの最近の論説の1つ−ライブラリ科学−を考慮されたい。 その論説を分類するためにライブラリ科学のためのDewey Decimal Codeを使うことができた。 Dewey DecimalCodeは唯一のsubjectのカテゴリ分類案から遠くかけ離れているので分類システム関係を保持するために、subjectプロパティの値として使われ、 使用されたカテゴリ分類を明示する付加的プロパティを使って、このリソースに注釈を付ける付加的リソースを識別する。 2.3章で明示したように、RDFコアは主な関係の主要値を示すためにvalueプロパティを含む。この結果の図はこのようになるであろう。

qualifying valuesD

図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>
注意:この例で上記の2つのネーム空間明示が同じネーム空間として存在する。 要素のネーム空間から来てない属性を明示しないこともあるので、デフォルトネーム空間が明示されると、上記のdc:Subject要素中でrdf:value属性と一緒の場合のようにこれは頻繁に必要となる。

このより高いarityの能力の共通して使用するのは、計測機器を扱うときである。人の重さは「200」のような数ではない、それには同じく使われた計測機器をも含む。この場合ポンドあるいはキログラムを使っているかもしれない。ジョン・スミスがどちらかと言うと頑健な紳士であるという事実を記録するために追加のアークとの関係を使うことができた:

unit-qualified valueD

図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>

リソース「ポンド」がURIのhttp://www.nist.gov/units/PoundsとともにNISTスキーマで定義されるなら。

7.4 ダブリンコアメタデータ

ダブリンコアメタデータはライブラリカードカタログに類似している方法で電子のリソースの発見を容易にするよう設計された。 これらの事例は用語がダブリンコアイニシアチブ.によって定義される用語を使ってRDFでリソースのセットの単純な記述を表す。 注意:ここで示した特定のダブリンコアRDF用語は正式であるように意図していない。ダブリンコアイニシアチブは正式な参照である。

ここにダブリンコアプロパティを使ってのWebサイトホームページの説明がある:

<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>

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/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>

3番目の例は前の例で参照した雑誌で特定の記事のことである。

<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ネーム空間qualified name省略形に対応したsyntaxを使う為に、ある特定のプロパティの値の明示を促されることがある。 これがこれからのXML datatypingメカニズムで非互換性を起こすことのある内部のプロパティ値の中にこれらのqualified nameを使わないように忠告する。 さらに、XML1.0の特徴を完全に精通したそれらは、ユーザ定義のエンティティーにおいて類似の略語メカニズムが存在することを識別することがある。 また、ユーザ定義されたエンティティーを含まないXMLのこれからのサブセットを定義するという提案があるので、エンティティーの用途に 頼らないようにすることを忠告する。

7.5 マークアップを含んだ値

プロパティ値が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>

7.6 PICSラベル

Platform for Internet Content Selection(PICS)は、Webページと他の資料の内容の記述を交換するための、 W3C勧告である。PICSはRDFの前身である、そしてそれがPICSラベルで表現することができる あらゆるものを表現することが可能であるRDFの明示的な必要条件である。

ここにPICSラベルがRDF形式でどうやって表現されているかの例を示す。 RDFのアプリケーションがRDF仕様の完成の後に続くかもしれないので、PICSそれ自身を再度明示するためのその仕事に注意されたい。 次の例がこれからの PICS スキーマの正式な例であると思われるべきではない。 この例は[PICS]から直接来る。PICSRating Service Descriptionが 正確にRDFスキーマに類似していることに注意されたい。;このようなRating Service Descriptionファイルで記述されたカテゴリーは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ラベルオプションは、個別の(rating)ステートメントを参照するが、それらのステートメントがたまたま供給されるコンテナを参照しているのではないことを示すためにaboutEachが使われることに注意されたい。

[PICS]はまたくgeneric labelと呼ばれるtypeを定義する。PICS generic labelはWebサイトの指定された部分の中ですべてのページに当てはまるラベルである。

下記にPICS generic labelが、aboutEachPrefix収集の構築者を使って、RDFに書かれるであろう方法の例を示す。この例は、[PICS]の付録Bでの「Generic request:一般的なリクエスト」例から引き出される :

<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は、そのURLが文字列"http://www.w3.org/WWW/で始めるすべてのリソースの上に現れる。各々のこのようなステートメント(「[I]のageが11である)に対応した具体化されたステートメントは、「abaird@w3.org」がそれらのステートメントを作ることに責任があったということを述べているプロパティを持っている。

7.7 HTML内のRDFのためのコンテンツ隠蔽

RDFは、適格なXMLであって、ユーザエージェントが、HTMLrecommendations for error handling in invalid documents に従う時、 HTMLドキュメントで直接の包括に適している。 RDFのフラグメントがHTMLドキュメントに取り入れられるとき、いくつかのブラウザがどんな露出したストリング内容でも表現するであろう。 露出したストリング内容は1つのタグを終了させる「>」と次のタグを始める「<」の間に現われるすべてのものである。 一般的に、ラインの終端文字を含んだ多数の連続したスペースが、1つのスペースとして、表現される。

RDFの省略された文法はよくXML属性形式でストリングであるプロパティ値を書き 込むのに使うことができ、そして露出した内容として、ただスペースだけを残すことができる。 例えば、7.4章からのダブリンコアの例の最初の部分は以下のように書かれる。:

<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>

露出した内容を避けるために書き直すことは、ほとんど普通のケースに有効であろう。1つの常識であるが、しかしそれほど明白でない場合は内容記述である。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要素が属性として用いられることができないことに注意されたい。 そのために明示的なRDFOrdはプロパティを使う。実際には、手動的に、li要素を拡大している。

自分自身を記述しているRDFメタデータを含んでいる完全なHTMLドキュメントが以下である:

<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に従っている全てのブラウザによって、容認されるべき である。そしてあとで、ただ、「これは素晴らしいドキュメントである」の文字を与えるべきである。

8.謝辞

この仕様書はW3C RDFモデルとSyntax Working Groupのなしたものである。 この作業グループは最もオンライン・コンピュータライブラリセンターのエリック・ミラーとIBMのボブスクロスによって立派にすすめられた。 グループが軌道に乗り続ける為に、彼らの疲れを知らない努力に対してエリックとボブに感謝する、そして、この努力で、彼らと我々をサポートすることに対して、特に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ブリストル)はRDFスキーマ活動に参加して、そしてこの仕事の最終の段階 に我々にたくさんの賢明なアドバイスを与えてくれた。 Martin Dürst(W3C)は、いくつかの実用的なドラフトを再検討して、そしてW3CInternationalization Working Groupを代表して改善のために多くの提案をした。 Janne Saarela(W3C)は、我々の実用的なドラフトから「クリーンルーム」implementationを作ることによって、この上なく貴重なサービスを行ってくれた。

このドキュメントはWorking Groupの共同作業である。この仕様書を作成し仕上げる手伝いをさせて頂いたことに関して、編集者はWorking Group に深く感謝している。

付録A:用語集

次の用語はさまざまな度合の直観的な意味と正確な意味をもってこの仕様で使われる。ここでのサマリー定義は、ガイダンスためのみである;それらは非標準である。 適切である場合は、正確な定義のドキュメント内のロケーションも与えられる。

Arc(アーク)
図表形式でのプロパティの表記;特に方向付けられた分類された図表内での端。
Attribute(属性)
objectの特徴チャプター6でこの用語は特定のXMLの構文的な概念にあてはまる;XMLタグのname="value"の一部。
Element(要素)
ここで使われるように、この用語は特定のXMLの構文的な概念、すなわち、一致するXML開始と終了タグとの間の素材に関係する。
Literal(リテラル)
RDFで表される最も旧式の値type、一般的に文字列。リテラルのコンテンツは、RDFそれ自身によって解釈されない、そして付加的なXMLマークアップを含んでいるかもしれない。RDFモデルはリテラルがステートメントのサブジェクトであるのを許さないという点で、リテラルが、リソースから識別される。
Node(ノード)
図表形式でのリソースあるいはリテラルの表記;特に、方向付けられた分類された図表での頂点。
Property(プロパティ)
他のリソースを記述するために使われることのある定義された意味を持っている特定の属性。プロパティそして特定のリソースのためのそのプロパティの値は、そのリソースについてのステートメントである。プロパティは、このプロパティで記述されるリソースのtypeと同様に、その許された値を定義することもある。
Resource(リソース)
人や本のような物理的なobject、あるいは、色や色を持つもののクラスのような概念的なobjectのどちらも表す抽象的なobject。Webページは、通常物理的なobjectであると考えられる、しかし物理的なobjectと、概念的あるいは抽象的なobjectの間の区別は、RDFには重要ではない。また、リソースは、より大きいobjectのコンポーネントでもあり得る;例えばリソースはドキュメントからある人の左手や特定のパラグラフを表現できる。この仕様で使われるように、もしURLがフラグメント(アンカー)id、あるいはフラグメントかアンカーidによって名前を付けられた特定のサブユニットを含んでいないなら、用語リソースはobjectの全体に関係する。
Statement(ステートメント)
特定のリソース、特定のプロパティ(属性)、に名前をつけ、そのリソースのためにそのプロパティの値を与える以下の1つの明示された文法1つの表現。さらに特にここでは、RDFステートメントは、このドキュメントで明示したRDF/XML文法を使うステートメントである。
Triple(トリプル)
順序で正にプロパティ、リソース識別子とプロパティ値から成り立って、RDFによって使われるステートメントの表現。

付録B:RDFの移動

Descriptionは、それが4つの方法の1つで記述するリソースと関係づけられることがある:

  1. Descriptionは、リソースの中に含まれてもよい。("embedded";e.g.in HTML例えばHTMLで、「埋め込まれた」)
  2. Descriptionは、リソースの外側にあってもよい、しかし、リソースを回復させるそれのように、同じ検索トランザクションでの トランスファー・メカニズムによって提供されるかもしれない。 ("along-with"; e.g. with HTTP GET or HEAD).
  3. Descriptionはリソース、含まれている異なったソースから独立して検索されてもよい。("service bureau"; e.g. using HTTP GET).
  4. Descriptionはリソースを含んでいてもよい。("wrapped"; e.g.RDF itself).

すべてのリソースはすべてのアソシエーション手順をサポートしないであろう;特に、多くの種類のリソースが埋め込みをサポートしないであろう、そしてただある特定の種類のリソースだけがラップされるかもしれない。

スキーマURLをdereferencingすることによって、RDFスキーマの人あるいはマシンが理解可能な記述は、内容ネゴシエーションを通してアクセスされるかもしれない。 もしスキーマがマシンが理解可能なら、アプリケーションが要求に応じてスキーマ内で名前をつけられたプロパティの意味のいくらかを学習することは、可能であるかもしれない。 RDFスキーマの論理と文法は、別のドキュメント[RDFSchema]で、記述される。

RDF式をHTMLドキュメント中に埋めるための勧告されたテクニックは、 Example7.7に示したように単にRFDインラインを挿入することである。これは、結果として生じるドキュメントがHTML4.0までを含んでいるHTML仕様には非conformantにするであろう、 しかしW3CはHTML仕様がこれをサポートするように展開するであろうと思う。 この技術がHTML4.0までを含んでいるHTML の仕様に従っているブラウザに関して用いられるとき、2つの実務的な問題が起こるであろう。代案はこれらの場合著者にとって入手可能である;[XMLinHTML]を参照のこと。 それぞれの事情で適切な代案を選択することは著者次第である。

  1. あるHTML2.0ブラウザは<HEAD>内に現われる最初のRDF要素のすぐ前に</HEAD>タグを想定するであろう。

    非常に古いブラウザについてかかわる著者は、ドキュメントヘッドの終わりにすべてのRDF式を置いてもよい。

  2. HTML4.0までを含む仕様に準拠しているすべてのHTMLブラウザはXML要素として表現されたRDFプロパティ値内に表われるあらゆる内容を描くだろう。(すなわち、プロダクション[6.12])。

    それらのRDFコンテンツが古いブラウザで表現するのを妨げることについて心配している著者は、プロパティ値を属性の中に移動させるために省略形文法(propAttr形式)を使ってもよい。すべてのプロパティがこのように表現されることができるわけではない。

上記の代案の一つも著者が望む性能を提供しない場合、RDF式は、HTMLドキュメントの外側に置いておかれて、 1つのHTML<LINK>要素をリンクされることがある。この目的のための勧告されたリレーションタイプは;例えば、REL="meta"である。

<LINK rel="meta" href="mydocMetadata.DC.RDF">

付録C: 使用法についての注釈

C.1 プロパティ名

RDF一連番号と省略形文法は、それらのコーディングとしてXMLを使う。XML要素と属性は大文字小文字の違いを識別するので、RDF プロパティ名は同じく大文字小文字の違いを識別する。 この仕様は、それらが正当なXMLnames名であるという以外、プロパティ名のために特定のフォーマットを必要としない。 それ自身の識別子のために、RDFはすべてのプロパティ名が使う規則「InterCapスタイル」を採用した;すなわち、プロパティ名と単語の残りの最初の文字は小文字である。;例えばsubject。 プロパティ名が単語の合成あるいは単語のフラグメントであるとき、単語は、それぞれの単語(最初の単語以外)の大文字化した最初の文字で連結し、句読点の付加はない。;例えばsubClassOf

C.2 Namespace URIs

RDFはすべてのプロパティのためにグローバルにユニークな識別子を実装するために提案されたXMLネーム空間メカニズムを使う。 ネーム空間名は対応するRDFスキーマのために識別子の役をする。[IRI]の5.2章 Resolving Relative References to Absolute Form のアルゴリズムによって指定したように、 ネーム空間名は絶対的な形式に変換される。RDF プロセッサがスキーマ内容にアクセスするためにスキーマURLを使うことを期待することができる。 この仕様は、そのURLで供給する内容に関してそれ以上の要求をしない(もしあったとしても)代わりの形式やスキーマのフラグメントを得るためにURLが修正されるということはない。

付録D: 参考文献

[Dexter94]
F. Halasz and M. Schwarz. The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):30--39, February 1994. Edited by K. Grønbæck and R. Trigg. http://www.acm.org/pubs/citations/journals/cacm/1994-37-2/p30-halasz/
[HTML]
HTML 4.0 Specification, Raggett, Le Hors, Jacobs eds, World Wide Web Consortium Recommendation; http://www.w3.org/TR/REC-html40/
[ISO10646]
ISO/IEC 10646. この標準の適用可能なバージョンはXML仕様 [XML]で定義される。
[NAMESPACES]
Namespaces in XML; Bray, Hollander, Layman eds, World Wide Web Consortium Recommendation; http://www.w3.org/TR/1999/REC-xml-names-19990114.
[PICS]
PICS Label Distribution Label Syntax and Communication Protocols, Version 1.1, W3C Recommendation 31-October-96; http://www.w3.org/TR/REC-PICS-labels.
[RDFSchema]
Resource Description Framework (RDF) Schemas; Brickley, Guha, Layman eds., World Wide Web Consortium Working Draft; http://www.w3.org/TR/1998/WD-rdf-schema
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels; S. Bradner, March 1997; RFC2119.
[Unicode]
Unicode標準。この標準の適用可能な版はXML仕様 [XML] によって定義されるバージョンである。
[URI]
Uniform Resource Identifiers (URI): Generic Syntax; Berners-Lee, Fielding, Masinter, Internet Draft Standard August, 1998; RFC2396.
[XML]
Extensible Markup Language (XML) 1.0; World Wide Web Consortium Recommendation; http://www.w3.org/TR/REC-xml.
[XMLinHTML]
XML in HTML Meeting Report; Connolly, Wood eds.; World Wide Web Consortium Note; http://www.w3.org/TR/NOTE-xh.

付録E: 変更

Proposed Recommendation が出版された後、若干の印刷用の変更がされた。前のバージョンでの周知の誤字は出版の時の時点で修正された。 6章の最終のパラグラフに対してわずかな明らかな変更が同じくなされた。


Ora Lassila <ora.lassila@research.nokia.com>
Ralph R. Swick <swick@w3.org>

Revision History:
1999年 2月17日: W3C勧告としての出版のための準備.
1999年 1月 5日: W3CProposed Recommendationとして出版
1998年12月16日: Proposed Recommendationを意図しての最終稿.
1998年10月30日: 最後のコールレビューコメントを組み入れ、parseTypeを加え、the I18N wordings改善。
1998年10月 8日: 最終のクリーンアップ、付録Eに対する変更を移動させて、ラストコールとして出版。
1998年10月 7日: futureproofingのためにスキーマURIスペースの1ビットを確保し、rdf:valueを付加。
1998年10月 2日: 主要なリネーム;statements,predicates,subjects,objects.
1998年 9月 4日: instanceOf->type,higher-arity関係モデルを修正、node識別子を付加.
1998年 8月19日: Ordプロパティ名に' 'を付加.
1998年 8月12日: より新しいXMLネーム空間宣言文法に更新。7章にコンテンツを付加。
1998年 7月20日: より多くの誤植を修正。3番目の公のドラフト
1998年 7月15日: コメントを組み入れ、誤植を修正。プロパティ名の最初の文字を小文字に変更。
1998年 6月15日: 主要なリライトと再編成
1998年 2月16日: 編集上のクリーンアップ、2番目の公の配布のための準備。
1998年 2月 6日: 編集上のクリーンアップ、いくつかの例の付加と修正。
1998年 1月11日: いくつかの要素についてリネームと不採用。
1997年11月14日: 特にアサーションに関して、より詳細化。
1997年11月 3日: 2番目の公の配布のために準備編集。
1997年10月 2日: 最初の公的なドラフト
1997年10月 1日: 最初の公の配布のために準備編集。
1997年 8月 1日: ワーキンググループへの初稿

Last updated: $Date: 1999/02/24 14:45:07 $