このドキュメントは
Relational Databases on the Semantic Web
http://www.w3.org/DesignIssues/RDB-RDF.html
の和訳です。
この文書には和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ず正式版文書を参照して下さい。

Tim Berners-Lee

Date: September 1998. Last modified: $Date: 1998/09/17 20:10:41 $

Status: . Editing status: Comments please. An parenthetical discussion to the Web Architecture at 50,000 feet. and the Semantic Web roadmap.

Up to Design Issues


セマンティックウェブ上でのリレーショナルデータベース

RDFのDLGと非常に似ており、その上にRDFを位置付けられような多くのモデルというものが存在している。まとめは以下を参照のこと

一つは関係データベース (RDB) モデルである.

セマンティックウェブとエンティティ-リレーションシップなモデル

RDFモデルはエンティティ-リレーションシップモデルであろうか?yesでありnoである。それはERモデルの基礎としてすばらしいものであるが、RDFはその他の物事にも同様に用いられるために、RDFはより一般的である。 RDFはエンティティ(ノード)と関係のモデルである。もし、あなたがデータに対し"ER"モデリングシステムに慣れているのなら、そのRDFは基本的にWebで動作するERモデルの第一歩である。典型的なERモデルはエンティティタイプを含んでおり、エンティティタイプにはそれぞれにリレーションの(典型的なERダイアグラムに入る)集合がある。 RDFモデルもリレーションシップが第一クラスのオブジェクトであることを除いては同様であり、そのオブジェクトとは:URIによって特定され、誰もがそれを作成することができるものである。さらに、オブジェクトのスロットの集合は、あるオブジェクトのクラスが定義されている時には定義されない。けれどもWebというものは誰かが何かについて何かを言うことを(技術的に)可能にするように動作する。これは、二つのオブジェクト間の関係は、それら二つのオブジェクトについての他の全ての情報から離して保存されるべきであることを意味する。 これは、しばしばERモデルの実装として用いられるオブジェクト-オリエンテッドなシステムとは異なっており、それは一般的にオブジェクトに関しての情報はオブジェクトの内部(:そのオブジェクトのクラス定義はそのプロパティを暗示するストレージを定義するような)に蓄えられるべきと仮定されているものである。

例えば、ある人は車輪と重量と長さは定義してあるがしかし色に関しては言及していないような乗り物を定義するかもしれない。このことは、どこかで他人が色に関する語彙を用いることで、車が赤であるという主張を妨げるものではない。

この単純なだが重要な変更はさておき、ERのモデリングを含む多くの概念は直接セマンティックウェブモデルへと引き継がれている。

セマンティックウェブと関係データベース

セマンティックウェブデータモデルはまさに関係データベースと直結している。関係データベースはテーブルで構成されており、それは列かレコードとからなる。それぞれのレコードはフィールドの集合からなっている。レコードとはそのフィールド内容に過ぎず、それはまさにRDFノードがその関係:属性値に過ぎないのと同じである。そのマッピングは非常に直接的であり、

確かに、セマンティックウェブの主要な推進力の一つは、常にいわれている通り、ウェブ上で膨大な量の関係データベースの情報を機械で処理可能とすることである。

RDFのシリアル化形式 -- そのシンタックスはXMLであるが -- は関係データベースの情報を表現することに非常に適した形式である。

RDBモデルの特色ある一面

関係データベースシステムは、RDFデータを扱うが、非常に特化された方法による。テーブル内部では、同じプロパティの集合を持った多くのレコードが存在する。独立したセル(それはあるRDFプロパティと比較して)はそう度々自身について考慮されはしない。 SQLクエリーはテーブルを結合し、そこからデータを取り出すことができるが、その結果は一般的にテーブルである。それゆえ、現実的な利用状況では、RDBソフトウェアは典型的な利用状況に合わせて、たくさんのエレメントを保持できるような少数のテーブルの操作できるように最適化されている。

データベーステーブルの基本的な側面は、しばしばテーブル中のデータが決定的であることである。 RDFもRDBもこれを表現するのにシンプルな方法は無い。例えば、あるテーブル中の行は、マサチューセッツのナンバー"123XYZ"の赤い車があることを示すだけではなく、テーブルは暗に、もしマサチューセッツのプレートをもっているのならどんな車でもテーブル中に存在しなければならないことを示している。 (もしどんなRDFノードも”マサチューセッツプレートナンバー”プロパティをもっているのなら、ノードはテーブルのメンバーである)値のユニクエンスのスコープは実際に大変興味深いプロパティである。

E.F.CoddによるオリジナルのRDBモデルは継承のデータタイプを含んでおり、それは彼が意図していた以上に、RDB製品に実装されることになった。例えば典型的にある人の部屋番号は整数として型づけされ、その人の靴のサイズもまた整数として型が定められる。人はその結果としてこれらのフィールドを通じ、テーブルを結合したり、靴のサイズと部屋番号とが同じ人の目録を作ることもできる。実用上のRDBシステムは、それを意味のあるオペレーションのみを操作できるようアプリケーションビルダーに任せている。一旦、データベースがWeb上に拡張されれば、あらゆる奇妙な組み合わせが可能となるだろう、それゆえ強い型制約が大変有用になる:それは推論規則の集合になる。

純粋なRDBモデルでは、どのテーブルもプライマリキーを持つ:どの列に対しても一意に識別できるための値をもつカラムのことである。いくつかの製品ではこれを強制せずに、複製された列の重要性にあいまいさを招いている。プライマリキーの興味深い特徴は列の同一性を変更することなしにキーを変更し得るということである。(例えば人は自分の名前を変えることができる)。 SQLは関係の整合性を保つためにそのような変更がローカルシステムを通じ、カスケードに行われるようなテーブルの構築を認めている。この明確さはWeb上では働かない。一つの解決法は列のIDを用いることである--それは実際多くのシステムで用いられているが、SQLではそれを通常の方法では表に出してはいない。他の解決法はアプリケーションに対し、プライマリキーを変更できないよう制約を加えることである。その他の解決法はリンクが破壊されるのを我慢することである。

RDBシステムはRDFやXMLの現在あるいは今後がそうであるように、アトミック(構造をもたない)レベルでデータタイプを持つ。 RDBにおける結合法則は無秩序に強化される傾向にある。その枠組みでは、クエリーはテーブルをデータタイプが一致するどのカラムによっても結合させることができ--その際セマンティクスの検証が行われることはない。例えば従業員の靴のサイズと同じ部屋番号の家のリストを作成できる、どの従業員にとってもその意味は疑問符のつくものであるけれども。

新しいSQL99標準は、新たなオブジェクト-オリエンテッドの特徴として、そのような型の継承と構造化されたセル - 配列と構造体 - を含む。このRDBモデルはオブジェクト-オリエンテッドな世界に由来している。その内部でRDFモデルがどちらかあるいは両方を表現できる最も低レベルな共通のデノミネータとして動作するかを、ここでは言及しない。

スキーマとスキーマ

XML/RDF(とSGML)スキーマと一方データベースのスキーマの相違点は、比較的XML/RDFスキーマのほうが数が少なくなることを期待できることである。多くのウェブサイトは同じスキーマによって定義された構造のドキュメントをエクスポートしているが、それはこれが実際のところ、相互運用性を提供していることにほかならない。データベーススキーマは、筆者の知る限りでは、各々のデータベースに対して独立して生成される。例えば100万社が同じ顧客データベースのフォームをクローンとしてつくれば、そこには各々のデータベースに対して一つのスキーマ、よって100万のスキーマが存在する。

RDFは、各々データベーススキーマにおいて単にタームの等価性表現の際のシンプルな役割を果たすものであろう。

Web上でデータベースを公開すること

テーブルにアクセスするために、そしてより多くの手段で用いることを可能とすべく特別のステートメントを記述する場合には、テーブル中の欠くことのできないオブジェクトはウェブ上でのファーストクラスのオブジェクトとして公開されるべきである。

どんなシステムでもウェブへマッピングする場合には、URI空間へのマッピングはクリティカルなものとなる。ここで我々はこれを共通のオペレーションを全ての関係データベース一般に対して行う。これを複数のベンダーにとって役に立つ首尾一貫した形式で行うことが有用なのは明らかである。

ここでは、誤りを含んでいる可能性があるが、筆者がデータベースにおけるネーミングで理解している範囲で任意に例を挙げる。データベースそれ自身は、カタログ中に提示されているスキーマの内部で定義される。

RDBからWebへのマッピング - strawman
Catalog http://www.acme.com/mycat
Schema http://www.acme.com/mycat/schema1
Database http://www.acme.com/mycat/schema1/empdb/ Relative:
Table /mycat/schema1/empdb/emps emps
Column name /mycat/schema1/empdb/emps/shoe emps/shoe
View /mycat/schema1/empdb/emps2 emps2
Row /mycat/schema1/empdb/emps/rowid=123 emps/rowid=123
Cell /mycat/schema1/empdb/emps/rowid=123;col=shoe emps/rowid=123;col=shoe
Arbitrary query /mycat/schema1/empdb/?select+empno+from[...] ?select[...]

実物をより簡単にしていることの一つは、関連したURIシンタックスが都合よく用いられるようにマッピングされていることである。例えばここでは、データベース内部の全て(SQLステートメントのスコープ)は短いURIで記述される。

SQLqueryシンタックスのいくつを識別子に変えるべきかという、一つの疑問がある。例えば、プライマリキー上のクエリーは本当に識別子であるのか?単一のセルからの抽出は本当に識別子なのか?それらをそのように扱えられることは有用であろう。しかしながら、"?"規約を、一般化された一回性SQLクエリを示すために用いることはより賢明であろう。(URLは もちろん、UPDATEやDELETEといったテーブル-変更の操作結果を参照するために決して使われるべきではない。)この場合、もしHTTPが用いられるならば、データベースURIに対しSQLクエリはPOSTされるべきである。もちろん、読者は好みのネットワークデータベースアクセスプロトコルを用いることができる。

上で述べたように、テーブルのカラム名はテーブルを名前空間として参照することができ、列は例えば次のようになる

<foo
  xmlns:t="http://www.acme.com/mycat/schema1/empdb/emps/">
  <t:shoe>6</shoe>
  <t:waist>45</waist>
</foo>

そしてプライマリキーを用いて(人の)テーブルを結合した結果である一つの列と(人についての)その他のテーブルは、両テーブルからのネームスペースを用いるであろう。

<foo
  xmlns:t="http://www.acme.com/mycat/schema1/empdb/emps"
  xmlns:u="http://www.acme.com/mycat/schema1/empdb/likes">
  <t:shoe>6</t:shoe>
  <t:waist>45</t:waist>
  <u:music>blues</u:music>
</foo>


この文書はAndrew Eisenberg/SybaseによるRDBチュートリアルとディスカッションから構想が練られたものである。


これも参照のこと: Why RDF is more than XML

Up to Design Issues; back to Architecture from 50,000ft

timbl

$Id: RDB-RDF.html,v 1.7 2001/06/06 20:02:36 timbl Exp $