Resource Description Framework
(RDF) Schema Specification 1.0
W3C Candidate Recommendation 27 March 2000
http://www.w3.org/TR/2000/CR-rdf-schema-20000327
の和訳です。
このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。
Copyright(C) 1998,1999,2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C 責任, 登録商標, 文書の使用 and ソフトウエアライセンスに関する規則が適用される。
Copyright(C) 1998,1999,2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
本仕様書は、RDFを使ってRDFボキャブラリを記述する方法について規定する。また本仕様書は、この目的としての基本ボキャブラリと、 将来RDFに追加することを想定しての拡張可能なメカニズムについて規定している。
本文書は、World Wide Web Consortiumの 勧告候補である。 この仕様書のレビューコメントは、2000年6月15日までに、 <www-rdf-comments@w3.org>に送付すること。 共通なコメントの記録はhttp://lists.w3.org/Archives/Public/www-rdf-commentsにおいてまとめて参照することができる。 編集者、ワーキンググループ長、W3Cスタッフだけへの個人的なコメントを希望する場合は、 <w3c-rdf-review@w3.org>へ送付すること。
この仕様書は、1999年3月3日版から、 レビューコメントを受け、編集者の提案を組み入れて、 勧告候補とした改訂版である。 この作業についての前回の版以来の主な変更点についての概要は別の文書によって提供する。 このドキュメントの出版物とともに、RDFスキーマ仕様書は、W3Cによる勧告候補フェーズに入っている。 W3Cは、この仕様書のテストを行うために勧告候補のレビュー期間中、活動的なインプリメントを促進している。 インプリメントでの経験によるレポートは、レビューアドレス にお願いしたい。
このResource Description Frameworkは、W3Cメタデータ活動の一部である。この活動特にRDFの主な目標は、マシンが理解可能(machine-understandable)なWeb上のリソースの記述を交換する言語を作ることにある。 data model and syntaxという別の仕様書において、RDFを使ったメタデータの交換について規定されている。
この節では、本文書の出版時の本文書の位置付けを規定する。その他のドキュメントはこのドキュメントに取って代わるだろう。このドキュメントにおける確認された誤字と、このドキュメントに関連する最新ステータスは W3C において保守される。 W3C技術レポート発表方針の記述のためのW3Cドキュメントに関しては、付録 Bを参照されたい。
W3C勧告候補を、参考文献資料として使用したり、またはその他の"進行中の作業"ではないとして引用することは不適切である。これは、進行中の作業であって、裏書をほのめかすものでもW3Cの総意でもない。 ドキュメントを勧告候補にするのは、インプリメントへの明示的な呼びかけと技術的なフィードバックである。 仕様をテストするか、精通することを目的として、この仕様に基づくインプリメントをすることは適切である。 現在のW3C勧告とその他の技術ドキュメントのリストはhttp://www.w3.org/TRを参照されたい。
RDF（Resource Description Framework）は、メタデータの処理の基礎である。 それはWeb上のマシンが理解可能な情報を互いに交換するアプリケーション間での通信を可能にする。 RDFはWebリソースの記述の交換にXMLを使うが、そのリソースは、XMLかXMLでないものも含むどんなタイプでもありうる。 RDFはWebリソースの自動的な処理を可能にすることに大変便利である。 RDFは様々なアプリケーション領域で使われる。例えば: 検索エンジンの能力向上を提供するためのリソース発見のため、あるいは、知識の共有と交換によって容易にするインテリジェントなソフトウェアエージェントによる特定のWebサイト、ページ、デジタルライブラリに関係したコンテンツとコンテンツ関連を説明したカタログ、あるいは、コンテンツのレイティング、あるいは、 Webページの知的財産権を記述したり、Webサイトのプライバシーポリシーと同様に、ユーザのプライバシープリファレンスを表現することに対して、ひとつの論理名「ドキュメント」を表すページの収集を記述することである。 デジタル署名(digital signatures)を有するRDFは、電子商取引、共同研究、その他のアプリケーションのための「信頼のWeb」を構築する キーになるであろう。
これらのアプリケーションによって使用された記述は、Webリソース間の関係としてモデルとなりうる。 [RDFMS]で説明しているように、RDFデータモデルは、名前がついたプロパティと値に関してリソース間の関係を 規定するための単純なモデルを定義している。 RDFプロパティは、リソースの属性に相当するもの、と考えられ、その意味では従来からの属性-値のペアに相当するものである。 RDFプロパティはまた、リソース間の関係について表現する。それゆえにその意味では、RDFデータモデルは、実在するものとの関係の図解に似ている。 しかしながら、RDFデータモデルは、これらのプロパティを明らかに示すメカニズムを提供しない。 また、これらのプロパティやその他のリソースの間の関係を定義するメカニズムも提供しない。 これがRDFスキーマの役目である。
リソース記述の集まりは、確かなリソースの種類については、間違いないものであるといえるための能力を必要とする。 例えば、bibliographicリソースの記述をするには、"author"、"title"、"subject"を含む記述属性が共通であるようにする。デジタル認証は、"checksum" や "authorization" のような属性がしばしば必要となる。 このようなプロパティ（属性）、およびそれらに関係するセマンティクスの明示は、RDF schemaのようにRDFのコンテキストで定義されている。 スキーマは、リソースのプロパティのみ（例えば、title, author, subject, size, colorなど）に限らず、記述されたリソースの種類（例えば、books, Web pages, people, companies,など)についても定義してもよい。
この仕様書は、"author"のような記述エレメントのボキャブラリについては説明していない。その代わりに
一緒に使えるリソースのクラスについての定義や、クラスと関連についての可能な組合せを限定するためのメカニズム、およびそのような制限の違反を見つけるメカニズムといったような、エレメントを定義するために必要なメカニズムについて説明している。
従ってこの仕様書は、schema specification languageを定義している。もっと簡潔に説明すると、RDFスキーマメカニズムは、RDFモデルの中で使われる基本的なtype systemを提供する。
それは、アプリケーション特有のスキーマを定義している中で使われるrdfs:Class と rdfs:subClassOfのような、リソースとプロパティを定義している。
リソースやプロパティのような分類分けされたシステムは、基本RDFデータモデルで定義されている。 このように、この分類分けされたシステムを構成するリソースは、それを使うあらゆる記述がRDFモデルの一部となる。 スキーマの記述言語は、基本データベーススキーマ記述言語(例えば、NIAM)とグラフデータモデルと同様、 知識表現（例えば、semantic nets, frames, predicate logicのような）から、観念によって影響を受ける明示的な知識表現言語である。 RDF スキーマ記述言語は、表現が豊かとは言えないが、しかし、CycL[CycL] と KIF[KIF] のような完全な述語計算言語より、インプリメントすることはシンプルである。
RDFとRDFスキーマ言語は同じくディジタル図書館コミュニティのメタデータリサーチに基づいていた。 特にRDFは、Warwick Framework ［WF］の実装である と思えるメタデータへのモジュール式のアプローチを採用する。 Warwick Framework がそれぞれのメタデータ用語を異なったシンタックスで 表現できるようにしたという点で、RDFはWarwick Framework モデルの進化を示す。 RDFでの、すべての用語は単独の明瞭なモデルの中で表現される。 これによって、マシン - 処理可能 用語のよりきめ細かい混合を可能にし、 そしてステートメントが専門的知識の独立したコミュニティによって分散した様式で 管理されている多数の用語を引き出すことができるメタデータを作る必要性 ［EXTWEB］に取り組む。
RDFスキーマは、XML Document Type Definitions （ DTDs ）［ XML ］と XMLスキーマ［ XMLSCHEMA ］と対比されるかもしれない。 XML DTD あるいは XMLドキュメントの構成の上に特定の制約条件を 与えるスキーマと異なり、RDFスキーマは、RDFデータモデルで与えられたステートメントの 解釈についてのインフォメーションを提供する。 XMLスキーマが、RDF/XML式の文法の妥当性を検査するために使われることが できるのに対して、構文的スキーマだけではRDFの目的として十分ではない。 RDFスキーマは、同じくこれらのデータモデルによって意味を理解されるべきである 制約条件を明示するかもしれない。 RDF スキーマと XML スキーマの将来のworkは、両方の［SCHEMA-ARCH］から 構文的な、そして意味的な規則の単純な結合を可能にするかもしれない。
この RDF スキーマ仕様は意図的にプリミティブ datatypes のセットを 特定しないままにしておいた。 RDFがそのインターチェンジコーディングのために XML を使うように、 XML［XMLDATATYPES］それ自身における データタイピングのworkは、このような能力のための基礎になるべきである。
RDFスキーマ仕様は、理論上の問題に対してではなくて、小数の当面の問題を解くことに向けられる。 その作成者は、他の問題(いくつかは、以下の例で説明している) が類似の特性を共有するであろうことと、 それらが、同じくこの仕様で記述された基本的なクラスを使うことが できるかもしれないことを予想する。
RDF スキーマ仕様は直接以下の問題の考察によって影響を受けた：
RDF モデルと文法は、どんなにそれが PICS rating systemsから RDF 表記へ 汎用マッピングを提供しないとしても、PICSラベル［PICS］を 表すために適切である。 そのようなマッピングを1つ、separate document（別のドキュメント）に記述する。
RDFの1つ明白なアプリケーションが Web ページの記述にある。 これは、Dublin Core［DC］Metadata Initiativeの 基本的な目標の1つである。 Dublin Core Element Setは、Webリソースの発見を可能にするために、Webリソースの記述を 統括的に適用できると考えられている、15要素の1セットである。 Dublin Coreは（今まで）RDFの発達に対する主要な影響力であった。 Dublin Coreの開発での重要な考察は、単純な記述を可能にすることだけでなく、 ドメインの特定の綿密さと記述の正確さ両方を提供するために記述を 制限する能力を提供することであった。
RDF スキーマ仕様は、Dublin Coreのような記述的な用語のためのスキーマを定義するための マシン-理解可能なシステムを提供する。 それはデザイナーに、リソースタイプのクラスとそれらのクラスの記述を伝えるためのプロパティ、 それらのプロパティとクラスの間の関係、クラスとプロパティと値の許された組み合わせでの 制約条件を指定することを可能にする。
sitemapは、Web サイトの階層的な説明である。 サブジェクト分類法は、組織化するか、あるいは Web リソースを分類するために内容作成者 あるいはトラステッドサードパーティーによって使われることのある分類システムである。 RDF スキーマ仕様は、このようなアプリケーションに必要とされる用語を定義するための メカニズムを提供する。
シソーラスとライブラリ分類体系は、 名前をつけられた概念の間の関係に関して、 サブジェクト分類法を意味するための、 階層的なシステムのよく知られている例である。 シソーラス（そして他のライブラリ分類システム）の論理構造を表現する RDFモデルを作るために、 RDF スキーマ仕様は十分なリソースを提供する。
Privacy Preferences Project (P3P)のための W3Cプラットホームは、構造化されたデータを交換するためのシンタックスと同様、 それらの practices の上に働かせたように、サイトのデータ収集の practices と 個人的な選択についてステートメントを組み立てるための文法を明示した。
個人的なデータ収集のpracticesは、アプリケーション特定のXML tagsetを使っているP3Pで記述されたが、 このデータのための一般的なメタデータモデルを使うことへの利点がある。 P3Pポリシー の構成は RDFモデルと解釈することができる。 プライバシーpractices descriptionsのセマンティックスを記述するためにメタデータスキーマを使うことによって、 プライバシーpracticesデータをリソース発見の間に照会で他のメタデータとともに使うことができるだろう、 そして一般的なソフトウェアのエージェントが他の記述的なメタデータに使われるのと同じ 技術を使って、プライバシーメタデータに作用できるようにするだろう。 サイトによって集められた特定のデータ要素を記述するP3Pへの拡張は、さらにどのように それらのデータ要素が使われるか明示するためにRDFスキーマを使うことができた。
RDFスキーマは、 RDFモデルとシンタックス[RDFMS]仕様で記述された データモデルによって表現される。 スキーマ記述言語は、単に、RDFスキーマ仕様と暗黙的にRDFスキーマ機構を使っているすべての RDFモデルの一部によって定義されたリソースとプロパティのセットである。
このドキュメントは、それらの関連の上にRDFスキーマメカニズムをRDF リソース （クラスとプロパティを含めて）と制約条件のセットとして明示する。 抽象的なRDFスキーマコア用語はDublin Core Element Setのようなアプリケーション特定の 用語を定義して、そして記述しているRDFステートメントを作るために使うことができる。
この仕様で定義したRDFスキーマは、アプリケーション特定のRDF用語を定義する他のRDFリソース
（プロパティを含めて）のプロパティを記述するために使われることができるRDFリソースの
収集である。
コアスキーマ用語は、ここで非公式に「 rdfs 」と呼ばれるネーム空間で定義され、
URIリファレンスhttp://www.w3.org/2000/01/rdf-schema#によって識別される。
この仕様も、同じくコアRDFネーム空間http://www.w3.org/1999/02/22-rdf-syntax-ns#を
参照するための接頭辞「 rdf 」を使う。
RDFモデルとシンタックス仕様［RDFMS］で記述されるように、
リソースは、1つあるいはそれ以上のクラスの事例であるかもしれない；
これは rdf:type プロパティで示される。
クラスは、それら自身階層的な様式でしばしば系統立てられる、例えばクラスDogが、
rdf:type Dog であるどんなリソースでも同じく
rdf:type Animalであると考えられることを意味して、
Animalのサブクラスである Mammal のサブクラスであると
思われるかもしれない。
この仕様はこのようなクラスの間の関係を示すために、プロパティ rdfs:subClassOfを記述する。
RDFスキーマタイプシステムは、Javaのようなオブジェクト指向プログラミング言語の
タイプシステムに類似している。
しかしながら、RDFは、そのインスタンスが持っているかもしれないプロパティに関して
クラスを定義する代わりに、RDFスキーマはそれらが適用するリソースのクラスに関して
プロパティを定義するであろうという点で、多くのこのようなシステムとは違っている。
これが、 3章で記述したrdfs:domain と
rdfs:range の制約条件の 役割である。
例えば、BookのドメインとLiteralの範囲を持つために
author（著者）プロパティを定義することができたのに対して、古典のOOシステムは、一般に
タイプ Literal のauthorと呼ばれた属性で
クラスBook を定義するかもしれない。
RDFプロパティ中心のアプローチの1つの利点は、既存のリソースについて欲する何かを
言うことは、誰にとっても非常に容易であるということである、そしてそれは
Web［BERNERS-LEE98］の構築の原理の1つである。
この仕様は datatypes のセットに対応しているクラスのセットの開発に先行する。
この仕様は特定の datatypes を定義しない、しかし datatypes が rdfs:rangeプロパティの
値として用いられることがあるということを示す。
rdf:typeプロパティが存在する。
（これらのプロパティは、図２で方向付けられたラベルをはられた図表表現中でアークとして示される）。
図1で描写しているRDFリソースは、この仕様の残りの中か
またはRDFモデルと文法仕様の中かで記述される。
図1: セットとしてのクラスとリソース と要素
図2は、図1のようなクラス階層についての同じインフォメーションを示すが、 RDFデータモデルの「ノードとアーク」図表表現を使って示す。 もし１つのクラスがもう1つのサブセットであるなら、第1のクラスを表わすノードから 第2のクラスを表しているノードまで rdfs:subClassOfアークがある。 同様に、もしリソースがクラスの事例であるなら、リソースからクラスを意味しているノードまで rdf:type アークがある。 このようなアークがすべて描かれるわけではない。 最もしっかりとクラスを取り囲むアークだけを示し、 そして、残りを提供するためのrdfs:subClassOf関係の推移性に依存する。
図2 ： RDFスキーマのためのクラス階層
次のリソースは RDF スキーマ用語の一部と定義されるコアクラスである。 （暗黙的に）RDFスキーマネーム空間の上に描くあらゆるRDFモデルがこれらを含む。
RDF式によって記述されているすべてのものはリソースと呼ばれ、
そしてクラス rdfs:Resource の事例であると考えられる。
RDFクラス rdfs:Resource はモデルとシンタックス仕様
［RDFMS］の5章で示した
RDFのための正式モデルで「リソース」と呼ばれるセットを表す。
rdf:Property は、プロパティ、すなわちすべてのセットの要素がモデルとシンタックス仕様
［ RDFMS ］の5章で「プロパティ」として紹介したRDFリソースのサブセットを表す。
これは、Javaのようなオブジェクト指向プログラミング言語で、クラスの概念に類似しているタイプ あるいはカテゴリーの一般的なコンセプトに対応する。 スキーマが新しいクラスを定義するとき、そのクラスを表現しているリソースは、その値が リソースrdfs:Classであるrdf:typeプロパティを持っていなくてはならない。 RDFクラスは、Webページ、人々、文書タイプ、データベースあるいは抽象的な概念のような、 ほとんど何でもを表現するために定義することができる。
（暗黙的に）同じくスキーマメカニズムを使うあらゆるRDFモデルは、次のコアプロパティを含む。 これらは、rdf:Propertyクラスの事例であり、クラスとそれらの事例、 あるいはスーパークラスとの間の関係を表現するためのメカニズムを提供する。
これは、リソースがクラスのメンバーであり、それでそのクラスのメンバーに期待されるはずである
すべての特徴を持っていることを示す。
リソースが、その値が若干の特定クラスであるrdf:typeプロパティを持っているとき、
リソースは指定されたクラスの事例であると言う。
若干のリソースのための rdf:type プロパティの値は、rdfs:Classの
インスタンスであるに違いないもう1つのリソースである。
rdfs:Classとして知られているリソースは、それ自身rdf:type
rdfs:Classのリソースである。
個別のクラス（例えば、「Dog」）は、常にその値が rdfs:Class である
rdf:typeプロパティ（あるいは、2.3.2章で記述したのと同じような
rdfs:Class の若干のサブクラス）を持つであろう。
リソースは、1以上のクラスの事例であるかもしれない。
このプロパティはクラスの間のサブセット/スーパーセット関係を指定する。
rdfs:subClassOf プロパティは他動詞である。
もし、クラスAが若干のより広いクラスBのサブクラスであり、
そしてBがCのサブクラスであるなら、Aは同じく暗黙的にCのサブクラスである。
従って、Aは、BとC両方のサブセットであるので、クラスAの事例であるリソースは、
同じくCのインスタンスであるであろう。
ただ rdfs:Class のインスタンスだけは、rdfs:subClassOfプロパティを
持つことができ、
そしてプロパティ値は常に rdf:type rdfs:Classのものである。
クラスは、1以上のクラスのサブクラスであるかもしれない。
クラスは、決してそれ自身のサブクラスであると明らかに示されることはできない、 そしてそれ自身のサブクラスのいずれも同様である。 この制約条件は、下記に提供したRDFスキーマ制約条件ファシリティを使用して表現できない、 それゆえ付録 Aで与えられたこの仕様のRDFバージョンに現われないことに注意されたい。
これは次のクラス階層を表現する非常に単純な例である。
最初にクラス MotorVehicle を定義する。
それから MotorVehicle の3つのサブクラス、すなわち、PassengerVehicle、
Truck とVan を定義する。
それからVan と PassengerVehicle 両方のサブクラスであるクラス
Minivan を定義する。
ここで示すRDF/XMLは、RDF一連番号シンタックスが提供した モデルとシンタックス仕様［RDFMS］省略メカニズムの2.2.1章で 定義された基本的なRDFシンタックスを使う。
|
プロパティ rdfs:subPropertyOf は、あるプロパティがもう１つの特殊化であることを
明示するために使われる rdf:Property の事例である。
プロパティはゼロ、1あるいはそれ以上のプロパティの特殊化であるかもしれない。
もし、若干のプロパティP2が、もう1つのより一般的なプロパティP1のsubPropertyOfであるなら、
そして、もしリソースAが、値Bを伴うP2プロパティを持っているなら、
これは、リソースAが同じく値Bを伴うP1プロパティを持っていることを意味する 。
プロパティは、決してそれ自身のサブプロパティであると明らかに示されることができない、 そしてそれ自身のサブプロパティのいずれも同様である。 この制約条件が下に提供されたRDFスキーマ制約条件ファシリティを使って 表現可能ではなく、 それで付録 Aで与えられたこの仕様のRDFバージョンに現われないことに注意されたい。
もしプロパティ biologicalFather がより広い範囲のプロパティ
biologicalParent のサブプロパティであるなら、
そして、もしフレッドがジョンの biologicalFatherであるなら、
それならフレッドは、同じくジョンの biologicalParent であることが意味される。
|
プロパティrdfs:seeAlsoは、サブジェクトリソースについての追加のインフォメーションを
提供するかもしれないリソースを指定する。
このプロパティは、オブジェクトリソースがサブジェクトリソースについて持っている
インフォメーションの特性をいっそう正確に示すためにrdfs:subPropertyOfの
使用を特殊化することがある。
オブジェクトとサブジェクトリソースはただクラス rdfs:Resource の
インスタンスであることだけをconstrained（強制）される。
プロパティrdfs:isDefinedByは、rdfs:seeAlsoのサブプロパティであり、
サブジェクトリソースを定義しているリソースを示す。
rdf:seeAlsoと同じように、このプロパティはrdfs:Resourceの
あらゆる事例に適用されることができ、そしてその値としてあらゆる
rdfs:Resourceを持つかもしれない。
最も共通の予期された使用法は、そのスキーマによって定義されたプロパティ あるいはクラスの1つの名前という条件のもとで、 RDFスキーマを識別することである。 XMLネーム空間宣言は、一般にRDF用語リソースが定義されているURIを提供するだろうが、 追加のインフォメーションが必要とされるケースがある。
例えば、
<rdfs:subPropertyOf
rdf:resource="http://purl.org/dc/elements/1.0/Creator"/>
のような概念は、用語項目Creatorを含むスキーマのURIを示さない。
(すなわち、http://purl.org/dc/elements/1.0/)
このような場合、rdfs:isDefinedByプロパティは、明示的にそのインフォメーションを
表現するために使われることができる。
ネーム空間のURIとそのコンポーネントが、明白な関係を持っていないとき、
もし、それらがGUIDあるいはMD-5ハッシュのような体系を使って識別されるケースであったなら、
このアプローチもうまくいくであろう。
この仕様は、RDFデータの中でのプロパティとクラスの使用における制約条件について ステートメントを作るためのRDF用語を紹介する。 例えば、RDFスキーマは、いくつかのプロパティのために妥当である値のタイプにおいての、 またはそのようなプロパティに帰すると気づかせるクラスにおいての制限を記述する。
RDFスキーマは、このような制約条件を記述するためのメカニズムを提供するが、
しかしアプリケーションが制約条件インフォメーションを処理しなくてはならないかどうか、
あるいはもしそうなら、どのような方法をとるかは述べない。
例えば、RDFスキーマは、author（著者）プロパティがクラスPerson の
メンバーであるリソースを示すために使われると断言することができるのに対して、
そのクラスインフォメーションを処理することにおいて、アプリケーションが
作用するべきであるかどうか、あるいはもしそうなら、どのような方法で行うかは言わない。
異なった方法で異なったアプリケーションが制約条件を使うであろうと
予想する − 例えば、validatorがエラーを探すであろうこと、
対話型のエディタが正規値を示唆するかもしれないこと、
そして推論アプリケーションがクラスを推論し、
そして次にあらゆる矛盾を知らせるかもしれないことなどである。
RDFスキーマは、多数の独立して開発されたスキーマから用語項目を関係づける
制約条件を表現することができる。
URIリファレンスがクラスとプロパティを識別するために使われるので、
別のネーム空間でそのdomain（ドメイン）あるいは
range（範囲）制約条件リファレンスクラスを
定義した新しいプロパティを作ることは可能である。
次の制約条件は、RDFスキーマ1.0で指定される：
プロパティ使用法上のrdfs:domainとrdfs:range
制約条件、rdfs:subPropertyOfと
rdfs:subClassOfプロパティがループを形成するべきでない規則、
プラスrdfs:ConstraintResource拡張性メカニズムを使って定義した
それ以上の制約条件。
RDF制約条件を扱うとき、異なったアプリケーションは、
異なった行動を示すかもしれない。
制約条件の例は以下を含む：
author（著者）プロパティに適用している範囲制約条件は、
author（著者）プロパティの値がクラスPerson のリソースで
なければならないと表現してもよい。
author（著者）プロパティは、ただクラスBookのインスタンスで
あったリソースからだけ起源することができたこと。
この仕様は、あらゆるRDF用語説明に適用できる制約条件の可能な形式を列挙することを試みはしない。 その代わりに、若干の基本的な制約条件メカニズムが、新しいタイプの制約条件の今後の付加を考慮するために、 extension facility（拡張子ファシリティ）を伴ってここで定義される。
RDFデータモデルは、明示的なプロパティ（rdf:typeプロパティのような）が
リテラル（原子の値）に帰されることを許さないが、にもかかわらずこれらのエンティティーが
クラスのメンバーであると考える。
（例えば、ストリング「ジョン・スミス」はクラスrdfs:Literalのメンバーであると考えられる）
注意: RDFとXMLデータ-タイピングにおける将来のworkがこのエリアで解明することを予想する。
このリソースは、その事例が制約条件の表現に関与する
RDFスキーマ概念であるrdfs:Resourceのサブクラスを定義する。
このクラスの目的は、RDFプロセッサがRDFモデルと結び付けられた制約条件インフォメーションを
使うそれらの能力を評価することを可能にするメカニズムを提供することである。
この仕様は、制約条件の新しい形式のダイナミックな発見のためのメカニズムを提供しないので、
以前にrdfs:ConstraintResourceの未知の事例に遭遇している
RDFスキーマ 1.0 プロセッサは、それらの制約条件の意味を
決定するのに不適当であることが確かであり得る。
rdf:Propertyのサブクラスを定義する。
このクラスは、rdfs:ConstraintResourceのサブクラスであり、
そしてプロパティを表現しているそのクラスのサブセットに対応する。
rdfs:domainとrdfs:rangeの両方が
rdfs:ConstraintPropertyの事例である。
プロパティの値がメンバーであるに違いないクラス（または複数のクラス）を示すために使われる
ConstraintPropertyの事例。
range（範囲）プロパティの値は、常にClassクラスである。
範囲制約条件は、ただプロパティに適用されるだけである。
プロパティは、せいぜい1個のrange範囲プロパティを持つことができる。 範囲を持たないことは可能であり、 そしてその場合、プロパティ値のクラスは制限されない。
rdfs:rangeのrdfs:domainは、クラスrdf:Propertyである。
これは、範囲プロパティがそれら自身プロパティであるリソースに当てはまることを示す。
rdfs:rangeのrdfs:rangeは、クラスrdfs:Classである。
これは、範囲プロパティの値であるどんなリソースでもクラスであろうことを示す。
プロパティの上に、２あるいはそれ以上のrange（範囲）制約条件を 表現することは許されないが、若干のプロパティのために適切な値を表すどんなクラスのためにでも、 共通のスーパークラスを定義することによって、類似の結果を得ることができる。 例えば、プロパティxyz:drivesMotorVehicleがVans、Trucks あるいはPassengerVehiclesである値を持つことができるという制約条件を表現するために、xyz:drivesMotorVehicleがMotorVehicle のrdfs:rangeを持っている、と断言する。 もしVan、TruckとPassengerVehicleが MotorVehicleのサブクラスであることを知られているなら、 これらすべてのタイプのリソースは、xyz:drivesMotorVehicleのために受容できる値である。 共通のスーパークラスが存在しないケースでは、1つは標準的な方法でのスキーマで定義されることができる。
そのメンバーでプロパティが使われることができるクラス（または複数のクラス）を示すために使われる
ConstraintPropertyのインスタンス。
プロパティは、そのドメインとしてゼロ、1、あるいは1以上のクラスを持っているかもしれない。 もしドメインプロパティがないなら、それはどんなリソースででも使われるかもしれない。 もし確かに1ドメインプロパティがあるなら、それはただそのクラス（ドメインプロパティの値である）の インスタンスの上で使われるだけであるかもしれない。 もし1以上のドメインプロパティがあるなら、制限されたプロパティは、 クラス（それらのドメインプロパティの値である）のいずれの インスタンスででも使われることができる。
rdfs:domain の rdfs:domain は、
クラス rdf:Property である。
これは、ドメインプロパティがプロパティであるリソースの上で使われることを示す。
rdfs:domain の rdfs:range は、クラス rdfs:Class である。
これは、ドメインプロパティの値であるどんなリソースでも、クラスであろうことを示す。
注意：この仕様は、プロパティが持っているかもしれないrdfs:domainプロパティの数を制約するのではない。 もし、domain（ドメイン）プロパティがないなら、 プロパティが使われるクラスについて何もわからない。 もし1以上のrdfs:domainプロパティがあるなら、 制限されたプロパティは、示されたany（あらゆる）クラスのメンバーであるリソースで 使うことができる。range（範囲）と異なりこれが非常に弱い制約条件であることに注意されたい。
RDFスキーマは、どのようにそれ自身のプロパティが使われるかを制限するために
制約条件プロパティを使う。
これら制約条件は、以下の図4中で示す。
太い輪郭を持っているノードはrdfs:Classの事例である。
図3: RDFスキーマ中の制約条件(Constraints)
以前のMotorVehicleの例に続いて、この例では、2つのプロパティを定義する：
registeredToとrearSeatLegRoomである
registeredToプロパティは、どんなMotorVehicleにでも適用でき、
その値は、Person（下の例で定義される）である。
この例のために、rearSeatLegRoomは、ただMinivanと
PassengerVehicleに応用するだけである。
値はNumber数である（若干のこのようなコンセプトがデータタイプの将来のworkによって
提供されるであろうことを期待する）、そしてそれは後部座席の足もとの広さのセンチメートルの数である。
|
RDFスキーマ仕様は、XMLによってそしてRDFモデルとシンタックスによって 提供された基礎をもとに作り上げる。個々のRDF用語とこのドキュメントで紹介したコアRDFスキーマ仕様用語の 両方の進化をサポートするために、若干の追加のファシリティを提供する。
Resource Description Frameworkは柔軟で、そして容易に拡大可能であるように意図される； これは、スキーマの多大な多様性が作られるであろうことと、 これらのスキーマの新しく、そして改善されたバージョンが、Web上で共通の同類発生であろうことを示唆する。
フレーズ「RDF用語」は、長い時間にわたって進化するそれらのリソースを参照するためにここで使われる； 「RDFスキーマ」は、どんな時点にでもRDF用語の特定の（不変の）バージョンを構成するそれらの リソースを示すために使われる。 このように、Dublin Core用語の進化について話をしたかもしれない。 Dublin Core用語のそれぞれのバージョンは、異なったRDFスキーマであるであろう、 そして対応するRDFモデルと具体的な構文的表現を持つであろう。
RDFは、プロパティとクラスが定義されるスキーマを識別するためにXMLネーム空間ファシリティ [XMLNS]を使う。 スキーマの論理構造を変えることは、そのスキーマに依存する他のRDFモデルを破壊する危険を冒すので、 この仕様は、RDFスキーマが変えられるときはいつでも、新しいネーム空間URIが 明示されるべきであることを勧告する。
結果において、スキーマを構成するRDFステートメントを変えることは、新しいそれを作成する； 新しいスキーマネーム空間は、あいまいさを避けるために、それら自身のURIを持つべきである。 RDFスキーマURIは、明白にスキーマの単一バージョンを識別するので、RDFを使うか あるいは管理するソフトウェア（例えば、キャッシュ）は、不明確な周期のための RDFスキーマモデルのコピーを安全にストアすることができるべきである。 RDFスキーマ進化の問題は、XML DTDバージョン管理における多くの特性と、 Webリソースバージョン対応の一般的な問題を共有する。 これらの問題への一般的なアプローチは、この仕様の視野を越えている。
それぞれのRDFスキーマがそれ自身の不変のURIを持っているので、 これらは、スキーマで定義されたリソースのためにユニークなURIリファレンスを 組み立てるために使うことができる。 リソースのためのローカルな識別子と、そのスキーマネーム空間と結び付けられたURIとを 一緒にすることによって、これは達成される。 RDFのXML表記は、使われたそれぞれの用語項目のために、 要素と属性をURIリファレンスと関係づけるためのXMLネーム空間メカニズムを使う。
RDFスキーマで定義されたリソースは、それら自身Webリソースであり、
そして他のRDFスキーマで記述されることができる。
この原理は、RDF用語進化に基本的なメカニズムを提供する。
スキーマの間にマッピングを表現することのために、
この仕様は、フルのフレームワークを提供することを試みはしない；
しかしながら、rdfs:subClassOfとrdfs:subPropertyOf
プロパティを提供する。
このようなリソースがどのようにそれらの以前のものにマップするかについて、
クラス（subClassOf）の間のそしてプロパティ（subPropertyOf）の間の
特殊化関係を表現する能力は、ステートメントを作ることに対して、単純なメカニズムを提供する。
これらの単純なメカニズムが適切ではない多くのシナリオがある； RDFのためにメカニズムをマップしているもっと幅広いスキーマが、 将来のW3Cアクティビティで開発されるかもしれない。
いくつかの用語のバージョン1.0を表現しているスキーマは、多くのvehicle（車両）タイプに
対応しているクラスを定義するかもしれない。
この用語のバージョン2.0のためのスキーマは異なったWebリソースを構成する。
もし新しいスキーマが、例えば、バージョン1.0でメンバーがクラス「Van」のメンバーの
サブセットであるクラス「Van」を定義するなら、
rdfs:subClassOfプロパティを、V2:Vanのすべての事例も
V1:Vanの事例である、と述べるために使うことができる。
用語がプロパティを定義するところで、 RDF用語の連続したバージョンで定義したプロパティの間の関係についてのステートメントを 作るためのrdfs:subPropertyOfの使用して、同じアプローチをとることができる。
この仕様は「制約条件リソース」（3.1章）として
知られているリソースのサブクラスを定義する。
これは、RDF制約条件の新しい表現方法の付加を考慮するために供給される。
Resource Description Framework への将来の拡張が、rdfs:ConstraintResourceクラスの
事例である新しいリソースをもたらすかもしれない。
RDFのこのバージョンで利用可能なそれらとは別に、制約条件を使って定義された
プロパティあるいはクラスをRDFコンテンツが引き出すのを予想することは必要である。
まだ、未知の制約条件が、RDF制約条件を
指定するためのより表現に富むフレームワークに、貢献するかもしれない。
従って、それらの未知の制約条件を使って用語項目が定義されるとき、
rdfs:ConstraintResourceの未知のインスタンスのセマンティックスに通じていない
RDFのエージェントは、制約条件充足を評価する知識に欠けるかもしれない。
RDFそれ自身が明らかにこれらの制約条件リソースのフルの意味を表現しないかもしれないので、
新しいConstraintResourceについてのRDFステートメントの取得は、
その使用を可能にするのに十分なインフォメーションを提供しないかもしれない。
例えば、RDF3:mysteryConstraintと呼ばれる以前は未知の制約条件プロパティタイプに
遭遇するとき、スキーマからそれがrdfs:Classの範囲とrdf:Propertyの
ドメインを持っているという情報をつかむかもしれない。
範囲とドメイン制約条件は、もし単独で遭遇するなら、
RDF3:mysteryConstraintをどのように合法的に使うべきか教えるのに十分であろう、
しかし、その様式で使われるとき、表現された制約条件の特性については何も教えない。
rdfs:ConstraintResource概念は、単純な将来を校正するメカニズムと、
Extensible Web Languages W3C NOTE［EXTWEB］で長々と論じられた
問題のいくつかがアドレスとしてここで提供される。
制約条件の新しい形式をこのクラスのメンバーとしてフラグを付けることによって、
それらは、起こりうるかの制約条件チェックをするために
その意味が理解されなくてはならないRDFスキーマ言語制約条件を
表現するように意図されることを示す。
rdfs:ConstraintResourceクラスにおけるメンバーシップは、
それらセマンティクスが叙述の形式で言い表せないかもしれないことを提案する、
しかし暗示はしない、
RDFの中でそうすることに即応できる表現に富むファシリティも進化する可能性が高いので、
この区別それ自身は可動のターゲットを表現している。
すべてのRDFのエージェントは、RDFのあるバージョンの中では表記の能力があるかもしれない、
あるいはないかもしれないある特定の制約条件の暗黙の知識を持っているであろう。
（例えば、この仕様はsubClassOfプロパティがRDF図表でループを
形成してはならないと宣言する）若干の将来のRDF仕様がまだ未考案の制約条件プロパティのために
RDFのエージェントが平叙文仕様書を理解することができるファシリティを
提供することはその事例である。
このような場合、これらのエージェントは、安全に（いくつかの）あらかじめ
遭遇しない制約条件の形式を理解することができた。
基本的なrdfs:ConstraintResourceクラスの提供によって、
そのような展開に前もって対処する。
この仕様がRDFステートメントの解釈を通してこのような制約条件に
ついての知識のためにメカニズムを提供しないので、単にこの仕様に書き込まれたすべてのRDFの
エージェントは、そのクラスの未知の事例の意味のそれらの無知を正しく認識するであろう。
そのようなファシリティを提示するべきであるが、将来の仕様書は、
同じくそれらが言い表せないセマンティックスを持っていたか否かにかかわらず新しい概念を
分類するべきConstraintPropertyのサブクラスを定義することができるかもしれない。
次のプロパティは、RDFスキーマの中で単純な文書化と ユーザ・インタフェース関連の注釈をサポートするために提供される。 スキーマの多言語の文書化ドキュメンテーションは、xml:lang言語のタグ付けファシリティの 使用を通して構文的なレベルにおいてサポートされる。 RDFスキーマが、RDFデータモデルの中で表現されるので、他のネーム空間で定義された用語が より豊かな文書化を提供するために使われるかもしれない。
これは、人間が読むことができるリソースの記述を提供するために使われる。
これは、人間が読むことができるリソース名のバージョンを提供するために使われる。
RDFモデルとシンタックス仕様［RDFMS］は、RDFの基本コンセプトを紹介する。
これらのいくらかは、そのネーム空間URIがhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
であるRDFスキーマで公式に定義される。
加えるに、若干のそれ以上の概念は、RDFモデルとシンタックス仕様で紹介される、
しかし、RDFモデルとシンタックススキーマには現われない。
これらはスキーマネーム空間に公式に属する（例えば、rdfs:Literalと
rdfs:Resource）。
RDFリソースが、http://www.w3.org/1999/02/22-rdf-syntax-ns#
ネーム空間に属するケースでは、このドキュメントは、単にそのリソースの定義の
コンビニエンスコピーだけを提供することができる。
付録 Aが、Literal（リテラル）と
Resource（リソース）のようなRDFモデル概念を含めてこのドキュメントで
定義されたRDFリソースにRDF/XMLスキーマを提供する。
付録 AでのRDF/XMLスキーマは、同じくRDFモデルとシンタックスネーム空間で
定義されたリソースについてのRDFステートメントを作る。
これらはdefinitions（定義）よりどちらかと言うと、
annotations（注釈）のステータスを持っている。
これは、モデルとシンタックス仕様［RDFMS］の5章で提示した RDFのための正式モデルで「Literals」（リテラル）と呼ばれるセットに対応する。 原文のストリングのような原子の値は、RDFリテラルの例である。
これはモデルとシンタックス仕様［RDFMS］の5章で提示した RDFのための正式モデルで「Statement」（ステートメント）と呼ばれるセットに対応する。
これはモデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「subject」（サブジェクト）と呼ばれるプロパティに対応する。
そのrdfs:domainは、rdf:Statementであり、
そしてrdfs:rangeは、rdfs:Resourceである。
これは具体的なステートメントによって記述されたリソースを指定するために使われる。
これはモデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「predicate」（述部）と呼ばれるプロパティに対応する。
そのrdfs:domainは、rdf:Statementであり、
そしてrdfs:rangeは、rdf:Propertyである。
これは、モデルされたステートメントで使われたプロパティを識別するために使われる。
これは、モデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「object」（オブジェクト）と呼ばれるプロパティに対応する。
そのrdfs:domainは、rdf:Statementである。
これはモデルをされたステートメントでプロパティ値を識別するために使われる。
このクラスはモデルとシンタックス仕様［RDFMS］の3章で記述した
コンテナクラスを示すために使われる。
それは、rdfs:Classの事例と、rdfs:Resourceの
rdfs:subClassOfである。
これは、モデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「Bag」と呼ばれるクラスに対応する。
それは、rdfs:Classとrdfs:subClassOf
rdfs:Containerの事例である。
これは、モデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「Sequence」（シーケンス）と呼ばれるクラスに対応する。
それは、rdfs:Classとrdfs:subClassOf
rdfs:Containerの事例である。
これは、モデルとシンタックス仕様［RDFMS］の5章で提示した
RDFのための正式のモデルで「Alternative」と呼ばれるクラスに対応する。
それは、rdfs:Classとrdfs:subClassOf
rdfs:Containerの事例である。
モデルとシンタックス仕様［RDFMS］の3章で
記述されるように、このクラスはコンテナメンバーシップを示すためにメンバーとして
使われたプロパティ_1, _2, _3 ...を持っている。
これは、rdfs:subClassOf rdf:Propertyである。
これはモデルとシンタックス仕様［RDFMS］の2.3章で 記述した「value」（値）プロパティに対応する。
このセクションは、若干の起こり得るアプリケーションのためのクラスとプロパティを 定義するためにRDFスキーマ機構を使うことについていくつかの短い例を述べている。 これらの例のいくつかが、クラスメンバーシップを表現するために 省略形RDFシンタックス（2.3.2.1で前述した）を使うことに注意されたい。
この例で、Personは、対応する「人々のクラス」の人間が読むことができる記述を
持っているクラスである。
Animalは、別のスキーマで定義されると推測されるクラスである。
すべての人々は動物である、それゆえPersonは、Animalの
サブクラスである、と宣言する。
Personは、年齢プロパティを持っているかもしれない。
年齢の値は整数である。
Personは、またssn（「社会保障番号」）プロパティを持っているかもしれない。
ssnの値はinteger（整数）である。
Personの婚姻状態は、{Single, Married, Divorced, Widowed}のうちの1つである。
これは、rdfs:range制約条件の使用を通して達成される：
maritalStatusプロパティと、クラスMaritalStatusの両方を定義する
（プロパティの名前の始まりは小文字、クラスは大文字を使うことについての
規則を採用している）。
そのとき、maritalStatusプロパティがただ、それがクラス
MaritalStatusのインスタンスである値を持っているとき
「意味をなす」ことだけを述べるために、rdfs:rangeを使う。
スキーマはそのとき、このクラスの多くの事例を定義する。
もう1つの図表でタイプMaritalStatusのことであると宣言されたリソースが
信頼されるかどうかは、アプリケーションレベル判断である。
|
この例では、サーチ可能なインターネットサービスを伴う使用のためのRDF用語のアウトラインを述べる。
SearchQueryは、クラスであると宣言される。
あらゆるSearchQueryは、その値がrdfs:Literalである
queryStringと、その値がSearchServiceである
queryServiceとの両方を持つことができる。
SearchServiceは、InternetService（他のところに定義される）の
サブクラスである。
SearchQueryは、若干数の結果プロパティ（その値はSearchResultである）
を持っている。
それぞれのSearchResultは、title（タイトル）
（値はrdfs:Literalである）、rating（評価）と、
もちろん、ページそれ自身を持つ。
RDFのモジュール化は、他の用語がより完全にネットワークで結ばれたリソースの プロパティを特徴づけるためにこれのような単純なスキーマと結び付けられることを可能にする。 例えば、Dublin Coreあるいはライブラリベースの分類用語は、 それぞれのSearchServiceのためにサブジェクト有効範囲あるいは 収集−レベル プロパティを記述するために使われるかもしれない、 一方では、独立して管理された「サーチプロトコル」用語は、サービスによって提供された LDAP 、 WHOIS++ あるいは Z39.50 サーチインタフェースのための（say） 接続細部を記述するために使われることができただろう。 種々のドメインから専門的なスキーマを引き出すステートメントの作成を許すことによって、 RDFは、専門的知識の多様なコミュニティが機械可読用語の分散したwebに貢献することを可能にする。
|
注意：このドキュメントは、W3C RDFスキーマ作業グループ（ WG ）によって 準備され、そして刊行のために承認された。 このドキュメントのWG承認は、必ずすべてのWGメンバーがその承認に賛成票を 投じたことを意味しない。
IBMのDavid Singerは、この仕様の開発の大部分を通じてグループの議長であった； 我々は彼の努力に対してDavid に感謝し、そしてこの試みで彼と我々へのサポートに対して、 IBMに感謝する。 同じく、この仕様より以前のバージョンの編集の仕事をしたAndrew Layman に特別に感謝する。
作業グループメンバーシップ：
Nick Arnett (Verity), Dan Brickley (ILRT / University of Bristol), Walter Chang (Adobe), Sailesh Chutani (Oracle), Ron Daniel (DATAFUSION), Charles Frankston (Microsoft), Joe Lapp (webMethods Inc.), Patrick Gannon (CommerceNet), RV Guha (Epinions, previously of Netscape Communications), Tom Hill (Apple Computer), Renato Iannella (DSTC), Sandeep Jain (Oracle), Kevin Jones, (InterMind), Emiko Kezuka (Digital Vision Laboratories), Ora Lassila (Nokia Research Center), Andrew Layman (Microsoft), John McCarthy (Lawrence Berkeley National Laboratory), Michael Mealling (Network Solutions), Norbert Mikula (DataChannel), Eric Miller (OCLC), Frank Olken (Lawrence Berkeley National Laboratory), Sri Raghavan (Digital/Compaq), Lisa Rein (webMethods Inc.), Tsuyoshi Sakata (Digital Vision Laboratories), Leon Shklar (Pencom Web Works), David Singer (IBM), Wei (William) Song (SISU), Neel Sundaresan (IBM), Ralph Swick (W3C), Naohiko Uramoto (IBM), Charles Wicksteed (Reuters Ltd.), Misha Wolf (Reuters Ltd.)
上記の人々のすべてが作業グループの全部の期間を通じて メンバーであったわけではない、しかし全員がこのドキュメントの発展に貢献した。
コアRDFスキーマモデルのRDF仕様は、RDF/XML一連番号シンタックスでここに与えられる。 RDFスキーマ仕様のためのネーム空間URIは、この仕様の将来のバージョンで、 もしスキーマが変化したら変化するであろうことにどうか注意されたい。 このRDFスキーマは、新しいリソースがRDFスキーマネーム空間に属するための定義と同様、 RDFモデルとシンタックスの仕様で公式に定義されたRDFリソースを記述している注釈を含んでいる。
それら自身RDFスキーマ仕様を使って完全に表現可能ではないある特定のRDFスキーマリソースの 上にいくつかの制約条件（前に2.3.2で与えられたそれらのような）があることに注意されたい。 例えば、RDFは、以下のようにアークのsubClassOfが（ノードとアーク表記からの専門用語を使用すること） RDFモデルでループを形成するべきではないと告げはしない。
|
信頼性と安定性を促進するために、W3Cが次の出版方針を制定した：