RDF とは

Web ベースの標準的メタデータを探る

この記事では Resource Description Framework (RDF) についてご紹介します。RDF は Web ベースのメタデータとして W3C によって開発され、XML を交換構文として使用します。RDF の基本的な目的は自立走行式エージェントの作業を簡単にし、検索エンジンやサービス・ディレクトリーを改善することによって Web をさらに進歩させることです。著者 Uche Ogbuji が、RDF スキーマや使用方法のシナリオなど、RDF の概要を示します。この記事では、読者が XML についてよく知っていることを前提としています。

Uche Ogbuji, Co-founder, Fourthought, Inc.

Uche Ogbuji 氏は、企業のナレッジ管理アプリケーションのための XML ソリューションに特化したコンサルティング会社 Fourthought Inc. のコンサルタントであり、共同創立者です。Fourthought 社は、XML ミドルウェア向けのオープン・ソース・プラットフォーム 4Suite を開発しました。Ogbuji 氏はナイジェリア生まれのコンピューター・エンジニアであり、ライターでもありますが、現在はアメリカのコロラド州ボールダーに生活と仕事の拠点を構えています。



2000年 12月 01日

1989 年に Tim Berners-Lee 氏が Web を発明し、世界中のカジノ、ポルノ産業、そして驚いたことに企業までもが、前例のないパワーを秘めたメディアを見出しました (このお話は、今ではすっかり語り尽くされました)。広く認識されているように、Web には次のような制限があります。

  • コンテンツと表示方法を混合する HTML 文書が主流であること
  • 現実世界の必然的な変化に合わせて Web サイトを管理することの難しさ
  • 動的コンテンツを途切れなく提供することの難しさ
  • Web クローラー検索エンジンを使って本当に見たいものを正確に探し当てようとしても、無駄な努力に思えること

Berners-Lee 氏その他の Web 産業形成の先導者たちによって 1994 年に設立されたコンソーシアム W3C は、これら 4 つの制限を改善しようと努力を重ねてきました。最初の 2 点は、Web データの保守容易性と柔軟性を高める XML 主導の Web という形で、未来が開けようとしています。W3C は残る 2 点の改善を目指して Resource Description Framework (RDF) を開発しました。W3C によれば、RDF は構造化された Web メタデータを Web データに相当するものとして提供し、Web データの管理およびナビゲーションの自動化を容易にします。(メタデータ その他のわかりにくい用語については、欄外記事をご覧ください。)

今、XML が世間の注目を大いに集めています。しかし多くの XML スペシャリストが指摘するように (また、XML がマスコミをにぎわすのを見て、おそらく多くの人が感じているように)、XML はそれほど面白いものではありません。XML は、データ形式を標準化する 1 つの方法にすぎません。ある意味では、XML は (ASCII や Unicode などの平凡なテクノロジーによって同様に標準化された) 文字レベルの上にくる、別のデータ・レベルにすぎないのです。

決して XML のことを低く評価しているわけではありません。データ形式が標準化されるおかげで、数多くのより豊富なテクノロジーが利用できるようになるのです。こうしたデータ形式標準化の恩恵を受けるテクノロジーの典型的な例が、RDF です。RDF は XML のキラー・アプリケーションになるとよく言われますが、これにはもっともな理由があります。それでも RDF には、まだ不明瞭な面があります。その主な理由は、RDF が本質的にかなり抽象的で、ドライで、学術的 (アカデミック) だからです。私はこの記事で、XML に関心を寄せるすべての人にとって RDF がきわめて 重要なのはなぜかを説明したいと思います。

W3C はコンテンツ・レイティング・システム Platform for Internet Content Selection (PICS) をはじめとする Web 管理の先駆的テクノロジーを実装しようとしています。その一方で、コンテンツの自動フィルターや自動セレクターが使用できるような、Web ページ評価に関する統一的主張 (assertion) を定めることの難しさに直面しています。

シンプルさの持つ力

RDF はきわめてシンプルです。一連の単純な主張 (assertion) を表現して処理する 1 つの方法以上の何物でもありません。たとえば、This article is authored by Uche Ogbuji. (この記事は Uche Ogbuji によって執筆されている。)

RDF ではこれを文 (statement) と呼び、3 つの部分、つまり主語 (subject) (ここでは "This article")、述語 (predicate) ("is authored by")、および目的語 (object) ("Uche Ogbuji") から成ります。このような主張 (assertion) は、正式な論理学の分野でも、文法の分野でも、こうして分解できます (自動詞の場合はどうなるのか、という話は別として)。実際、RDF は、資源 (resource) (つまり Web を介してアクセス可能なすべての項目) の記述を目的とした研究分野の、長きにわたる結果を単に適用しただけです。

RDF では、資源は URI によって表現されます (URL はそのサブセット)。RDF 文の主語は資源でなければなりません。したがって、上の英文を RDF 文に変換すると図 1 のようになります。

図 1. RDF 文
RDF 文

図 1 は、RDF Model and Syntax 1.0 Recommendation (RDF M&S) で紹介された、一般的な RDF 文のグラフ表示です。目的語が文字列 "Uche Ogbuji" であることに注意してください。RDF ではこれをリテラル (literal) といいますが、資源を目的語とすることもできます。次に図 2 をご覧ください。

図 2. 小さな RDF モデル
小さな RDF モデル

図 2 は、いくつかの RDF 文を 1 つのダイアグラム (図) にまとめたところを示しています。あらゆる RDF は、これを基本とした拡張のようなものです。RDF は、Web ベースの資源を記述するいくつかの文からなる有向グラフを定義します。お気付きのように、元の文のリテラル "Uche Ogbuji" が、この人物を表す URI に置き換えられています。この URI は、他のいくつかの文の主語にもなっています。このような RDF 文の集まりを、RDF ではモデル (model) といいます。

これほど重要なテクノロジーにしては、ずいぶん単純に思えるかもしれませんが、まさにこの単純さゆえに RDF は強力なのです。コンピューター・サイエンスの世界では、情報をグラフで表すことの効果が力説されています。RDF によって多数の単純な文が集められ、マシン・エージェントは情報収集のための優れたグラフ走査手法を使用できるようになります。これらの文は 3 つの主要な部分 (主語、目的語、述語) から成るため、トリプル (triple) と呼ばれます。こうしたトリプルからなるデータベースは、数百万単位のトリプルにまで拡張できることがわかっています。これは主に、トリプルの情報が単純なためです。巨大な Web の世界をテクノロジーによって果たして手なずけられるかどうか、この拡張容易性には大きな期待がかかっています。


XML ではどのように見えるか

上記のような抽象的表記は RDF の基本ですが、RDF 記述を交換したり、そのような記述を HTML や XML のコンテンツに置き換える場合には、まったく非実用的です。このため RDF M&S では、RDF を XML で直列化 (シリアライズ) する形式も提供されています。この形式に従えば、図 2 のモデルはたとえばリスト 1 のように表すことができるでしょう。

リスト 2. 図 2 の RDF モデルの XML シリアライゼーション
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns="http://schemas.uche.ogbuji.net/rdfexample/">
  <rdf:Description about="http://uche.ogbuji.net/thisarticle">
    <authored-by>
      <rdf:Description ID="uche.ogbuji.net">
        <name>Uche Ogbuji</name>
        <nationality>Nigerian</nationality>
      </rdf:Description>
    </authored-by>
  </rdf:Description>
</rdf:RDF>

リスト 1 は、数多くの方法の 1 つにすぎません。他にも、より長い、あるいはより短縮された XML 表記があります。RDF 構文のこうした柔軟性のおかげで、RDF 処理を既存の XML に適用するのはきわめて簡単です (もっとも、この柔軟性ゆえに、RDF を習得して実装するのが難しいわけですが)。すべての RDF シリアライゼーション (直列化) に共通する 1 つの点は、rdf:RDF 要素を使って RDF 文をラップしていることです。

リスト 1 で、XML 名前空間を使用していることに注意してください。RDF は、名前を明確にするうえで XML 名前空間に大きく依存します。RDF M&S によって定義されている名前空間には、必須の要素名および属性名がいくつかあります (この例の接頭部 rdf もその 1 つですが、他にも多数あります)。例に示されているように、すべての RDF 述語は、意味を明確にするために名前空間を使用する必要があります。

RDF ラッパー要素の中の description 要素は、埋め込まれている文の主語を表します。この例では、主語として外部資源をポイントする about 属性が使われています。この資源を主語とする文が 1 つあり、述語を形成する <authored-by> 要素によって区切られます。この要素には、名前空間 http://schemas.uche.ogbuji.net/rdfexample/ があることに注意してください。RDF M&S によれば、これは抽象モデルに変換され、そこでは名前空間 URI と述語要素のローカル名とが結合されて、実際の述語を形成します。したがって、この文の本当の述語は、全体で http://schemas.uche.ogbuji.net/rdfexample/authored-by. となります。さらに、名前空間は、RDF のタイプや制約に関する情報を提供するスキーマともなります。

文の残りの部分は、もちろん目的語です。しかし最初の文の目的語は、リスト 1 では明確にわかりません。RDF は、文の目的語が資源であるものの、外部 URI が存在しないようなケースを処理します。この例では、Uche Ogbuji という名前の人物を表す資源がこのケースに当たり、実際には ID 属性を持つ Description という埋め込み要素によって表されます。この資源の URI は、RDF ファイル全般の URI と、ID 属性の値とを結合したものになります。これは難解な概念 (のほんの 1 つ) ですが、RDF は ID を持たないまったく匿名の資源をも許可することに注意してください。

ID "uche.ogbuji.net" を持つ資源そのものは、2 つの文の主語です。それらの述語は、子要素 name および nationality によって表されています。これらの述語は、http://schemas.uche.ogbuji.net/rdfexample/ 名前空間にも存在することに注意してください。これらの文の目的語は、それぞれ "Uche Ogbuji" および "Nigerian" というリテラルです。

以上が RDF の概要です。RDF の概要について、より詳しい情報は 参考文献 のリンクを参照してください。また、文のコンテナー、具体化 (reification)、スキーマなどの上級トピックもご覧いただけます。


見かけは単純。それで ?

すでに述べたように、RDF のパワーの源はそのシンプルさにあります。(リスト 1 のような) 簡単な記述を文書のヘッダーに埋め込むことによって、既存の Web データに RDF の注釈を付け始めるよう、W3C はウェブ・マスターたちに勧告しています。実際のところ、リスト 1 で私が使ったようなスキーマのサンプル名前空間を使用するよりも、ライブラリー的メタデータとしての標準仕様 Dublin Core を利用するよう推奨されています (参考文献を参照)。標準的なカタログ化メタデータを使用すれば、ちょうど HTML メタ・タグが検索エンジンによる Web ページの索引付けを容易にするように、検索エンジン Web クローラーその他のマシン・エージェントの作業が容易になります。RDF の利点は、やはりマシンが読み取ることのできるスキーマを使って簡単に拡張できることです。これによって、過去に例のないような自動化が可能になります。

資源の発見、記述、スキーマのこのような自動化は、Berners-Lee 氏および W3C がこれまで盛んに説いてきた次世代 Web (セマンティック Web) の基礎となるのです。この表現は議論の的になっていますが (欄外記事RDF の言葉遊びを参照)、セマンティック・ネットワークと呼ばれるよく確立された人工知能テクノロジーが、Web におけるデータ処理の自動化に適用されることを示しています。この進歩によって、Web クローラーは単なるプレーン・キーワード以上のものを収集できるようになるでしょう。RDF スキーマのおかげで、Web クローラーは、散在する RDF 文のさまざまなパーツの中に、何らかの形の意味 をつかむことができるようになるでしょう。意味 という言葉の意味 については、議論が繰り広げられています。しかし、少なくとも RDF スキーマは、Web 資源記述用の確立された規約を使ってナビゲートする 1 つのメカニズムを提供します。

もちろん、セマンティック Web というものはまだ存在せず、このビジョンがウェブ・マスターたちの無気力さ、拡張容易性のテスト、資源の転換の問題などに耐えて生き残れるかどうか、誰にもわかりません。資源の転換の問題とは、絶えず変化するドメイン名システムに URL が基づいていることに関連しています。実際、RDF 資源は URL のスーパーセットである URI ですが、他の URI 形式は URL と比べて非常にあいまいです。それらは、URL が広範な使用に耐えているような環境でテストされていません。


Y2K 時代の実用的な RDF

RDF の言葉遊び

メタデータ とは、RDF について語るときに避けて通れない紛らわしい用語の 1 つです。RDF とその適用形態は非常に抽象的であるため、用語の中にも明確で一貫性のある意味を持たないものがあります。メタデータの場合、データに関するデータを意味する、という点では明確です。問題は、一般のデータが終わってメタデータが始まるのはどこかかという点です。この区別に関して厳密な規則を定めている分野もあります。たとえばリレーショナル・データベースでは、メタデータと言えば各テーブルの名前、およびテーブル内の各列のタイプを含みます。これに対してデータとは、これらの列に格納される情報を指します。RDF の場合は内容モデルで XML を扱うので、データとメタデータの区別はユーザーの好みということになります。たとえば、本の著者名はデータかそれともメタデータかという点を考えると、by Uche Ogbuji が表紙カバーに現れるので、これはデータだと言えます。同時に、ほとんどの人は著者名がテキストの一部だとは見なさないでしょうから、これはメタデータであるとも言えます。

意味のつかみにくい RDF 用語は他にもあり、いわゆる「S の災難 (S curse)」と言われるものもあります。データ処理科学をちょっと意地悪な目で見る人たちの観察によれば、"S" で始まる用語の多くは意味が抽象的かつ不鮮明であり、明瞭な定義が不可能です。典型的な例を 3 つあげると、構文 (syntax)、セマンティクス (semantics)、スキーマ (schema) があります。RDF は「セマンティック Web」を構築するうえで鍵を握ると W3C は説きますが、これもまた "S" で始まる言葉で、セマンティック Web とは厳密に何を指すかをめぐって一向に合意が得られません。そのほかに、RDF で盛んに登場するスキーマもまた "S" で始まる用語であり、この場合も意味が不明瞭です。RDF スキーマ仕様の中に何らかのヒントを見出せるものの、その編集者自身が認めているように、この定義はゆるやか、非制限的、かつ未完成です。この仕様は RDF オブジェクトのデータ型を制限し、人間やマシンが理解できる RDF 述語の「意味」(これも不明瞭な用語ですが) を提供する、あるいは単にさまざまなボキャブラリーを互いに関連付ける方法を提供する可能性を持っています。

RDF の実装が進み、W3C が RDF スキーマ仕様を更新していくにつれて、これらの点はいくらか明瞭になるでしょう。しかし現状では、用語や概念のあいまいさゆえに、RDF に関する議論はアカデミックな印象が強すぎるようです。

RDF の野心的なビジョンは時代をかなり先取りしており、まだ不確定さが残されています。では、なぜ RDF は重要なのでしょうか?

すでに述べたとおり (また、さまざまな文献でしばしば議論されるとおり)、マクロのレベルでは、Web はすっかり管理しにくくなってしまいました。限定されたドメインにおいても、同じ問題があります。アプリケーション設計における、あのクライアント / サーバー革命によって、フォーム用コードや表示用コードがサーバー・データに追加されて保管される図式が定着しました。この手法、およびそれに関連するさまざまな開発手法は、固定的で高度に管理されたデータベース環境で操作することのみを意図しています。3 層システムや n 層システムに拡張されても、たいした変化はありませんでした。問題は、アプリケーションが次第に Web に移行していくうちに、硬直さが容易な保守を妨げるようになったことです。

ここでの Web アプリケーション とは、Web 上で動的コンテンツや対話式コンテンツを扱うあらゆる場所を指しています。つまり、ポータルから e-commerce サイトまで、さまざまなものを含みます。Web アプリケーションは、競争に勝ち残るために、ますます多様なソースやサービスからデータを集める必要が出てきました。その上、「インターネット時代」にあっては、そうしたアプリケーションの要件はますます流動的になっています。こうした環境では、XML や RDF の拡張性が本当に役立ちます。XML はデータ形式を柔軟に調整することを可能にし、RDF はデータ処理の規則を柔軟に調整できるようにします。

RDF によって Web 全体をセマンティック・ネットワークに変える構想に関する問題点をすでに見てきましたが、こうした問題のほとんどは、単一アプリケーションを使用する制御された環境では簡単に対処できます。つまり、トリプルを処理する中心的な RDF データベースを設置することができます。それらのトリプルが記述するさまざまな資源を結合して、Web アプリケーションのビューを形成することができます。実際、いくつかの重要なアプリケーション・オブジェクト (とくに、頻繁に変更されるもの) を RDF モデルで直接参照することができます。これはデータベース・インデックスとなり、しかも拡張がより簡単です。

基本的に、RDF は Web ベース・アプリケーションにとって従来のデータベース設計からの「脱出口」となり、アプリケーションの進歩を可能にします。一部の人たちは、従来のデータベース管理ツールがあまりに構造化されすぎているため、現実世界に合わせてアプリケーションを必然的に調整するとき、膨大な保守コストを要すると何年も前から指摘してきました。こう主張する一派 (筆者も含まれる) は長い間、データ管理の「半構造的な」手法を提唱してきました。こうした手法は保守コストを大幅に削減してくれるからです。従来型データベースと RDF データベースを併用する方法は、この問題に取り組むうえで大いに役立つテクノロジーの 1 つです。


結論

私はコンサルタントとして、制御された、しかし進歩してゆくシステムの従来型データベースを補強するために RDF を大いに利用してきました。RDF のおかげで、ポータル、Web ベースの検索アプリケーション、さらにメッセージ索引付けアプリケーションの保守コストが削減されるのを見てきました。私は Web のヘビー・ユーザーとして、XML、RDF、そして現在提唱されているセマンティック Web がもたらすであろう進歩を想像することができます。

RDF は決して完璧なテクノロジーではありません。シリアライゼーションには大ざっぱな面が多少あり、利用できる唯一の RDF スキーマ仕様はほとんど効果を発揮しません。しかし RDF には強力な機能が 2 つあります。まず、データ交換の主流になりつつある XML との間で、高い相互運用性を実現するよう設計されています。さらに、やっかいで例外的なケースをも処理できる十分なシンプルさを備えています。

すでにある程度の XML データを持っている読者にとって、XML から得られる RDF を使って XML 処理用の索引および規則を作成するパイロット・プログラムを構築するのも、さほど難しくないでしょう。数多くの RDF ツールがすでに登場していますから、自分の手で新しいものを発明する必要はほとんどありません。こうして、閉じたシステムにおける RDF の利点をいくらかでも実感できるでしょう。一方、HTML メタ・タグのほかに、RDF を使って Web コンテンツに注釈を付けるのはもっと簡単です。こうすれば、今後が有望なセマンティック Web にいち早く慣れることができるでしょう。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=293856
ArticleTitle=RDF とは
publish-date=12012000