レベル: 中級 Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.
2002年 2月 01日 今回もUche Ogbuji氏が、ナレッジ管理を実現するためのXMLとRDFの組み合わせ技法について説明します。今回のコラムでは、RDFにおけるモデリングを詳しく解説し、問題追跡機能のためのスキーマを作成していきます。そして、RDFの モデリングについて、オブジェクト指向モデリングやリレーショナル・モデリングとの類似点、相違点を説明します。読者の皆様は、XMLデータを利用した効率的なナレッジ管理モデルを構築するための、ヒント、技法、最善の実践例を、このコラムから得られると思います。
これまでは、問題追跡機能アプリケーションの説明を通して、XMLデータから抽出されるRDFデータ、RDFデータの抽出方法、そして、RDFがもたらす、非常にセマンティックな（意味に基づく）検索能力について、例を挙げて述べてまいりました。これからは、RDFを利用してXMLアプリケーションにナレッジ管理機能を組み込む際に、スキーマがどんな役割を担うかについて詳しく説明していきます。
リレーショナル・データベースやオブジェクト指向データベースのスキーマ、およびXMLスキーマは、データ主導型のアプリケーションに対する、文書、ガイダンス、制御の手段を提供します。RDFのスキーマは、これらのスキーマよりも規制が緩く、より汎用的です。むしろRDFモデルに当てはめるリソースの分類について定めています。今回と次回のコラムでは、問題追跡機能のRDF文 (ステートメント 以下省略）のためのスキーマについて、W3C RDFスキーマ (RDFS) 仕様とDARPA Agent Markup Language/Ontology Inference Language (DAML+OIL) の両方を使って、考えていきます。RDFS仕様とDAML/OILは、W3C仕様に対する重要な拡張、改善であると位置付けられます。RDFSやDAML+OILの概念の大部分を、これから挙げる例や説明を通して紹介していく予定ですが、多少なりともRDFSやDAML+OILの知識があれば役に立ちます。
それがクラスの特徴です
RDFS、DAML+OILは共に、リソースの分類が中心になっています。これまでのコラムを読むと、問題追跡機能のRDFは分類にあまりウェイトを置いていないと感じたかもしれません。実際これまで、「クラス」や「タイプ」は一切使っていません。それでもRDFシステムにとっては、充分です。なぜなら、問題追跡機能の場合、どんなリソースも、「問題」でマークアップできるからです。さらに、問題には、著者、コメント、行動を付け足すことができ、厳密な分類は、おそらく人工的で、ただ邪魔になるだけだからです。
多くのオブジェクト指向（以下、OOと略します）言語で要求されるような厳密な分類を必要としないところが、RDFの一つの強みです。RDFのクラスとタイプの概念は、はるかに、モデル設計者が自由に解釈できます。リソースに対してどのような種類の編成を用いようと、クラスをその編成の中核にすることができます。生物の科学的分類のような、整然としたツリー編成である必要はありません。たとえば、XMLの世界では、「注文書」というのは、XMLという強じんな機能を使って、どんなに努力しても標準化がほとんど不可能な文書の一例として頻繁に挙げられます。その理由は、注文書の分類方法、それをさらに下位クラスに分類する方法、注文書のとらえ方は無数にあるからです。そのような無秩序な状態に対応するためにこそ、RDFは設計されました。
RDFSでは、タイプをごく自然に表示するものとしてクラスという概念を利用し、OO開発の世界観の一部を取り入れています。実際、RDFの実装の多くが、これを手本として使っています。これはOO技法が最近富みに有名になったからでしょう。しかし、私は、このパターンがRDF自身にとって決定的ではないことを強調しなければならないと考えています。
クラスとタイプは深みのある概念です。具体例を挙げて説明しましょう。電話番号を考えてみてください。一つの分類体系に当てはめようとした場合、さまざまな方向から電話番号をとらえることができます。
- 電話番号は、一種の番号である。
- 電話番号は、一種の連絡データである。
- 電話番号は、一種の資産である。(米国企業は、電話機のダイヤル上に記されたアルファベットで商標名をつづれば自社のフリーダイヤルにつながるような番号を必死に獲得しようとします。)
- フリーダイヤルは、一種の電話番号である。
- ファックス番号は、一種の電話番号である。
OO的な考えの象徴である典型的な階層がいくつか見えてきますね。また、実績のあるOOの実践においてすら、問題を生じてしまいそうな重複した分類と、不安定な分類にも気付くと思います。そのことは、OOの開発者に 「死のダイヤモンド」あるいは、「飛べない鳥」はどのように分類すればよいのかを聞いてみれば分かります。上記の 「一種の」は、しばしばOOのコンセプトである 「is-a」の関係にマップされます。これは、OO実装言語に備わっているセマンティクスの結果として、通常はオブジェクトのタイプを定義します。
しかし、実世界では、クラスよりもタイプの方が多く存在します。次の文を見てみましょう。
- 501-555-1111は、Markの職場の番号である。
- 500-555-1234は、Markの自宅の番号である。
- 500-555-1234は、Markの緊急連絡先の番号として使う。
- 555の交換局区外から555-1234へダイヤルする場合は、10桁の電話番号を使わなければならない。
これらの文はすべて電話番号の特性を定義しています。最初の例のグループと比べると、はっきりした分類はされていません。実際、OOの世界の考えでは、これらは（属性や関連を使った）様々な方法で表現され、タイプを使って分類されることはめったにありません。しかし、通常人間がこのような特性について考える場合、「2番目の文例のグループは1番目のグループに比べてタイプの分類になっていない」と判断する根拠は全くありません。「職場の番号は電話番号のタイプだ」という方が自然ですし、市外局番が501のエリアでは、「10桁の番号」は一つの電話番号の「タイプ」です。RDFの中では、このような特性を、rdf:type という述語を用いて表現してはならないという根拠は全くありません。事実、W3C noteのvCard/RDFのプロポーザルでは、評判の良いvCardの連絡仕様の計画をRDFに移行することを提案しています。vCard/RDFでは、職場の電話番号と自宅の電話番号の区別や、ファックス番号と音声用の番号の区別、インターネットのメールボックスとLotus Notesのメールボックスの区別にrdf:type を使用しています。また、RDFSの 常識としても（データ・モデル内の分類を表すために）rdf:type を使用します。
しかし、同じ述語 (rdf:type) がいろいろな使い方をされてしまうと、非常にあいまいになってしまわないでしょうか？このような状態では、rdf:type の多様な使い方について改善が必要であると思います。たとえば、RDFSでは、rdf:type のサブプロパティー、rdfs:type というのを導入したらどうでしょうか？もしそれが紛らわしければ、rdfs:classificationType という名前でもよいと思います。同様に、vCardもrdf:type のサブプロパティーvCard:contactType というのを導入すれば、使用されるさまざまなタイプの概念を区別できるのではないでしょうか。
「問題」のスキーマを作る
問題追跡機能では、タイプ分類やクラス分類に関して、綿密な作業は必要ありません。上記の説明は、タイプやクラス、その他スキーマに関係する項目を大雑肥に構築してもよいという考え方を推奨しているものです。確かに私が過去に参画してきたRDFプロジェクトの多くは、スキーマをひねり出すのに、山盛りのドーナツとカフェイン入りの飲み物を前に机を囲むという本格的な準備が常にありました。これは、OO開発やリレーショナルDBの世界から借用した厳格主義者の良心みたいなものでしょう。しかし、これまで問題追跡機能について考えていく中で、私は、スキーマの完成にたどり着かないような例もたくさん体験してきました。それでも問題はありませんでした。それでは、Webベースのリソースに「問題」を付加して、それらの「問題」に対して、厳密ではない文を作成してみましょう。
スキーマの話に移ります。リスト1は、XMLの断片です。issueというRDFSクラスを説明するものです。
リスト1. Issueクラス
<rdfs:Class ID="Issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>A problem, suggestion or other matter for action
or discussion relevant to a resource</rdfs:comment>
</rdfs:Class>
|
このコードは、issueに対するインライン（ID を使っているため）のRDFSクラスを宣言しています。ラベル (label) とコメント (comment) に注目してください。これらは非常に重要で、今までの私の経験では、定義するリソースにはすべて、この2つが必要になると考えています。スキーマ的な要素については特にそうです。特にラベルは重要です。高性能のRDFツールであれば、ラベルを使ってリソースの名前として、見た目に悪いURLではく、ユーザー・フレンドリーな名前を付けることができるからです。
リスト2. 著者（Author）クラスとissue、authorプロパティー
<rdfs:Class ID="Author">
<rdfs:label>Author</rdfs:label>
<rdfs:comment>A person raising or posting an issue</rdfs:comment>
</rdfs:Class>
<rdfs:Property ID="issue">
<rdfs:label>issue</rdfs:label>
<rdfs:comment>Associate an issue with its resource
</rdfs:comment>
<rdfs:range rdf:resource="#Issue"/>
</rdfs:Property>
<rdfs:Property ID="author">
<rdfs:label>author</rdfs:label>
<rdfs:comment>Associate an issue with whoever posted it
</rdfs:comment>
<!-- Where the <i>dc</i> entity has been set to the
Dublin Core metadata element base URI -->
<rdfs:subPropertyOf rdf:resource="&dc;creator"/>
<rdfs:domain rdf:resource="#Issue"/>
<rdfs:range rdf:resource="#Author"/>
</rdfs:Property>
|
ここで、プロパティーissue を定義しました。範囲（range）文では、述語issue を伴う文の目的語はIssue というrdf:type を持つ必要があると表明しています。ここでは、そのような文の主語にそのような制約は付けないので（制約を付ける場合は、ドメイン（domain）文）、すべてのリソースは、述語issue を持ってもよいことになります。これが私たちの狙いです。author プロパティーが、ドメインと範囲と共に定義されており、さらに、Dublin Coreの "creator" というメタデータの要素のサブプロパティーになるよう定義されています。その意味は、author プロパティーを持つissue はすべてdc:creator も持つと、自動的に表明することになります。これは一般的に使われる有用な技法で、この場合、Dublin Coreを知っているエージェント・ソフトウェアは、私たちの問題追跡機能のメタデータを問題なく、ある程度の部分までは解釈できるということになります。この仕掛けが、実際はセマンティックWebの基盤の一部になっています。
これまでの例のデータに戻って、今作成しているスキーマと対比させると、「今までやってきた例と合わないじゃないか」と困惑するかもしれません。たとえば、以下のリストを見てください。
リスト3. 前掲の例のコードの一部
<rdf:Description about='&ril-spec;ril-20010502'>
<rit:issue rdf:resource='#i2001030423'/>
</rdf:Description>
<rdf:Description ID='i2001030423'>
<it:author rdf:resource='&ril-users;#uogbuji'/>
</rdf:Description>
|
これは私たちが設定した制約に違反しているように見えます。なぜかと言うと、リソースID i2001030423というリソースは、Issue というrdf:type を持つと宣言されていないからです。同様に、ID "uogbuji" というリソースは、Author というrdf:type を持つと宣言されていません。
実際のところ、これが本当にスキーマに違反しているかどうかという問題は、私たちがスキーマをどう解釈するかに左右されるのかもしれません。「制約条件 (ドメインや範囲など) を順守する文がモデル内にない場合、そのモデルは矛盾している、つまりエラー状態である。」というのが、一般的な解釈です。これは、RDFスキーマの制約的役割と言われているものです。いわゆる「閉世界」仮説の一部でもあります。照会の際にモデル内で明白になっていないものは全く考慮されないからです。
あまり一般的ではありませんが、もう一つ面白いアプローチの仕方があります。今回のコラムで定義した制約の一つは、「リソースがauthor プロパティーを持つ場合、それは、rdf:type
Issue のものでなければならない」というものです。そうなると、i2001030423 のリソースがこのプロパティーを持つのを見て、このリソースに要求されるタイプを推測できます。つまり、プロセッサーは、制約が満たされるような文を効率的に生成できます。これは、RDFスキーマの生成的役割あるいは、推論的役割と言われているものです。人間が、変動する世界にどう対応しているかというのに似ています。したがって、セマンティックWebの裏に存在する強じんな着想力にも近いです。しかし、このパワーのおかげで、ナレッジの表現に困難な落とし穴が現れます。
ここで重要なことは、我々はRDFのプロトタイプインスタンスからはじめて、ボトムアップにスキーマを作ったにも関わらず、以前の成果と矛盾しなかったことです。RDFの寛大さ（私はこの言葉を軽々しくは使いません）のおかげです。経験を積んできたモデル作成者／設計者の一個人として、RDFは、昔からのOO思考者、リレーショナル思考者にとって理解し難いけれども、RDFのパワーと柔軟性は確固たる強みの一つであるということを、強調させてください。
結論
今回のコラムもスペースがなくなりました。私がこれまで時間をかけて紹介、説明してきた、モデリングに関する重要な概念が意義があることを願っています。私が、拡張可能なメタデータについてあれこれ考えを巡らせていた時の説明にお付き合いいただいたことに感謝します。次回は、RDFS形式の問題追跡機能のスキーマを完成させ、DAML形式のスキーマについても説明します。
参考文献
著者について  | 
| | Uche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。 |
記事の評価
| 
