XML的思索 第5回: ナレッジ管理のための基本的なXMLおよびRDF技法

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.

2001年 9月 01日

今回の「XML的思索」コラムでは、複数のXMLソース文書から収集したメタデータを単一のResource Description Framework (RDF) モデルに組み込んで、効果的な照会を行えるようにする方法について説明します。著者のUche Ogbujiは、前回の記事で、XMLとRDFを一緒に使用してナレッジ管理を行う方法について述べましたが、今回の記事では、それに引き続き既存のXML形式のデータをRDFモデルに取り込む技法について解説します。この記事の目玉は、Webベースの問題追跡機能 (もともと、XMLのアプリケーション・データを扱うために開発されたもの) を拡張してRDFを利用する例を示すことです。XSLTとPythonによるサンプル・コード・リストは、XMLファイルのメタデータを単一のRDFモデルに集約する2つの方式 (1つはXSLTを使用し、もう1つはRDFを使用する) と、簡単なRDF照会の例を示したものです。

このコラムの前回の記事である 「ナレッジ管理のための基本的なXMLおよびRDF技法: 第1回」(今回の記事を読む前に、この記事を読むことをお勧めします) では、私は、XML形式のデータを基にした問題追跡アプリケーションの例を紹介しました。その次に、XSLTを使ってアプリケーション・データからRDFを抽出する方法を示しました。

このコラムではさらに詳しく掘り下げて、各XMLソース文書を変換して作成した別々のRDF断片を結合する方法を示します。また、基本的な照会技法も示します。

リソースのバッチ導出

前回のコラムでは、XMLソース・ファイルからRDFを直列化フォームとして抽出する基本演習を行いました。しかし、ナレッジ管理の最も実用的な利点は、個々の直列化ファイルではなくRDFステートメントの要約モデルを扱える点にあります。RDFモデルはグラフ構造になっていて、非常に簡単なものから非常に複雑難解なものまであります。(実際、極端な場合は、意味体系Webの将来像としては、少なくとも現行Webと同じくらいの大きさを持ったRDFモデルを作成したい、という場合もあります。ここまでくると、それを実行に移した場合、かつて使ったこともないような膨大なコンピューター・データ構造になってしまいます。)

しかし現在までのところ、例として示す問題追跡機能は、RDFモデルの一部を直列化したXMLファイルの集まりからなっています。各ファイルはジグソー・パズルの小片のようなもので、それらを組み合わせることで、問題追跡アプリケーションにあるすべてのデータのRDFモデルができ上がります。それぞれの小片自体はそれほど重要なものではないため、次のステップとして、真のナレッジ管理の産物である完成ピクチャーの作成方法を検討することにします。

XSLTによるバッチ変換

このピクチャーを組み立てるための1つの選択肢は、ジグソー・パズル小片を組み立てることなどでは全然なく、XSLTを使ってピクチャーを一気に作り上げることです。ユーザーは、各XML問題文書を収集し、前回の記事で説明したRDF変換処理を適用し、次に各変換処理の結果を1つの直列化RDF結果に累積する変換プログラムを作成することができます。それを行うには、標準のdocument() XSLT関数を使用します。この関数は、任意の文書を読み取って、変換処理用の補足XMLソース文書として処理することができます。

document() 関数は、読み取る文書の正確な名前を知っていなければなりません。XSLTには、標準のメカニズム、たとえば、ワイルドカードを使って複数の文書を読み取る機能が備わっていません。この問題を解決するためには、多くの方法があります (ワイルドカードや他の何らかのメカニズムを使ってバッチ文書ロードを可能にするXSLT拡張機能の使用も含む)。しかし、それはこの例の主要な問題ではありませんので、簡単な解決策として、各問題文書のリストを付けたハブXSLT文書を作成することにしました。　リスト1のissue-hub.xmlは、2つの例示問題文書 (前回の記事で紹介済み) を指定したハブ文書です。

                <issues>
  <issue>issue1.xml</issue>
  <issue>issue2.xml</issue>
</issues>

ハブ文書を作成したら、リスト2 metadata-batch.xsltの変換プログラムをそのハブ文書のソースとして使用し、リストされているすべての問題の集合RDFを作成することができます。

リスト2には見覚えがあるかもしれません。なぜなら、このリストの大部分は、前回の記事で示した変換プログラムと同じものだからです。この理由のために、私は細心の注意を払ってXML構造の処理をモジュール化しました。現在のルート・テンプレートは、ハブ文書内の各issue 要素を探します (ここでヌル・ネーム・スペースを使用している点に注意してください)。ルート・テンプレートは次に、各要素の内容に指定されているファイル名から文書をロードします。document(.) だけでではなく、document(.)/* も使用されている点に注意してください。このような構造になっているため、プロセッサーは問題文書のルート・ノードと一致するものを見つけられません。このため、ハブ文書のルート・ノード用に作成されたテンプレートの呼び出しが終了します。こういった点が、当コラムのバッチ変換プログラムにおける唯一の違いです。

ユーザーは、任意のXSLTプロセッサーを使用して変換プログラムを実行することができます。私は、以下のような4XSLTを使ってそれを処理しました。

$ 4xslt -o issues.rdf issue-hub.xml metadata-batch.xslt

変換プログラムを実行すると、issue1.xmlとissue2.xmlの両方から取得したメタデータが入っているissues.rdfの直列化RDFが作成されます。

RDFツールによるバッチ変換

複数のXML文書を単一のRDFモデルに集約するためのもう1つの選択肢は、前回の記事で示したように、各RDF文書を別々に作成してから、RDFパーサーを使用してすべての文書を構文解析して単一の要約モデルにまとめることです。したがって、たとえば、前回のコラムの例示問題ファイルで作成した2つのRDFファイルに対して4RDFを使用することにより、リスト3ができ上がります。

                
$ 4rdf -d 1.rdf 2.rdf
The following is a list of resulting tuples, each in the form "subject,
predicate, object".
[
("http://meta.rdfinference.org/ril/issue-tracker/ril-20010502",
"http://xmlns.rdfinference.org/ril/issue-tracker#issue",
"#i2001030423"),
("#anonymous:e08-e06-30b-90d-a060005104", "id", "i2001030423"),
("#anonymous:e08-e06-30b-90d-a060005104",
"http://xmlns.rdfinference.org/ril/issue-tracker#author",
"http://users.rdfinference.org/ril/issue-tracker#uogbuji"),
("#anonymous:1040d07-20b-909-407-b0e0402205",
"http://xmlns.rdfinference.org/ril/issue-tracker#author", "Alexandre
Fayolle <Alexandre.Fayolle@logilab.fr>"),
("#anonymous:1040d07-20b-909-407-b0e0402205",
"http://xmlns.rdfinference.org/ril/issue-tracker#body", "The
abbreviation in listing 8 doesn't seem necessary to Nico Chauvat or
me."),
("#anonymous:e08-e06-30b-90d-a060005104",
"http://xmlns.rdfinference.org/ril/issue-tracker#comment",
"#anonymous:1040d07-20b-909-407-b0e0402205"),
("#anonymous:60e0b06-50a-80c-90c-50a0a08602",
"http://xmlns.rdfinference.org/ril/issue-tracker#author",
"http://users.rdfinference.org/ril/issue-tracker#uogbuji"),
("#anonymous:60e0b06-50a-80c-90c-50a0a08602",
"http://xmlns.rdfinference.org/ril/issue-tracker#assignment",
"http://users.rdfinference.org/ril/issue-tracker#uogbuji"),
("#anonymous:e08-e06-30b-90d-a060005104",
"http://xmlns.rdfinference.org/ril/issue-tracker#action",
"#anonymous:60e0b06-50a-80c-90c-50a0a08602"),
("http://meta.rdfinference.org/ril/issue-tracker/ril-20010502",
"http://xmlns.rdfinference.org/ril/issue-tracker#issue",
"#i2001042003"),
("#anonymous:2030002-506-10a-201-f090809c08", "id", "i2001042003"),
("#anonymous:2030002-506-10a-201-f090809c08",
"http://xmlns.rdfinference.org/ril/issue-tracker#author",
"http://users.rdfinference.org/ril/issue-tracker#nchauvat"),
("#anonymous:c000706-b0b-d02-d0a-e050c0460b",
"http://xmlns.rdfinference.org/ril/issue-tracker#author", "Alexandre
Fayolle <Alexandre.Fayolle@logilab.fr>"),
("#anonymous:c000706-b0b-d02-d0a-e050c0460b",
"http://xmlns.rdfinference.org/ril/issue-tracker#body", "I agree"),
("#anonymous:2030002-506-10a-201-f090809c08",
"http://xmlns.rdfinference.org/ril/issue-tracker#comment",
"#anonymous:c000706-b0b-d02-d0a-e050c0460b"),
("#anonymous:b0c0c00-800-2-c08-20a0d0f209",
"http://xmlns.rdfinference.org/ril/issue-tracker#author",
"http://users.rdfinference.org/ril/issue-tracker#uogbuji"),
("#anonymous:b0c0c00-800-2-c08-20a0d0f209",
"http://xmlns.rdfinference.org/ril/issue-tracker#assignment",
"http://users.rdfinference.org/ril/issue-tracker#uogbuji"),
("#anonymous:2030002-506-10a-201-f090809c08",
"http://xmlns.rdfinference.org/ril/issue-tracker#action",
"#anonymous:b0c0c00-800-2-c08-20a0d0f209"),
]

リスト3の1行目にある-d オプションは、subject/predicate/objectの組を要約RDFモデルからコマンド行にダンプするように $RDFに指示します。このダンプ結果は、リスト3の残りの部分に表示されています。

問題追跡機能用の完全なRDFモデルを入手したら、リスト3のような表示ではなく、人間が理解できるような形にしてみたくなるでしょう。そこでたとえば、リスト3から集合RDFファイルを取得し、それにDan BrickleyのRDFビジュアライザー・ツール (参考文献を参照) を使用すれば、図1 のようなグラフが作成されます。このグラフは、普通のラップトップ画面には大きすぎますので、リンクをクリックして別のウィンドウでそれを開きます。

図1のビジュアライザー表示のすばらしい点は、ユーザー "uogbuji" の貢献と責任といった、特定のパターンを即時に見分けることができることです。もちろん、RDFのURIに伴う冗長なIDによってこの明確性が損なわれていることは否定できません。

上に戻る

システム全体にわたる照会

メタデータのRDFモデルを使用可能にすることによって得られるもう1つの直接的な利点は、XML文書の集合に対するXPath照会を書く場合や、そのデータをプロプラエタリー・データ構造に組み立てて照会する場合と比べ、多くのシステム規模の照会がより簡単かつ包括的になるということです。XML照会言語 (XQuery) の登場や、XMLリポジトリー・ベンダーによるプロプラエタリー文書収集照会ツールの登場が、このニーズの解決に役立っています。しかし現在は、RDFが使用でき、少なくとも基本モデルが標準化されています。

残念ながらRDFモデルの照会はまだ標準化されていないため、これが致命的な弱点となっていて、この解決がRDFコミュニティーの緊急の課題です。幸運なことに、RDFのモデルが単純であるため、基本パターン・マッチングを使用することにより、ほとんどすべての形式の照会を簡単に作成することができます。これが4RDFの基本的なアプローチです。このアプローチの場合、「照会」とは、所定の主語、述部、および目的語パターンと一致するステートメント・トリプルを見つけることです。たとえば、テーブル1で作成したばかりの統一モデルの一部をご覧ください。

これらのトリプルさえ与えられれば、「ユーザーuogbujiに割り当てられているアクションIDはどれか」、「各アクションの本文はどれか」と尋ねるのは簡単なことであるのが容易に分かります。最初の質問は、以下のパターンと一致するトリプルを検出することと翻訳されます。ここで、"*" は任意の値と一致するワイルドカードです。

これに対する応答の1つは、主語 "#anonymous:a0d010d-f0c-706-20e-80a0407606" を持つステートメントで、これは一致するアクションIDを示しています。ただし、これは4RDFによって作成された匿名リソース (つまり、アプリケーションによって明示的に割り当てられたIDを持っていないリソース) 用の特殊なIDです。"anonymous" というシーケンスの後には、全体的に固有なID (UUID) を構成する16進値が続いています。このIDが与えられた2番目の例示質問は、以下のパターンと一致することと等価であり、目的語 "Organize a vote on this topic" を持つステートメントを戻します。

この単純なアイデアに基づけば、ほとんどすべての形式のRDF照会を行うことができ、リレーショナル (SQL) 照会やオブジェクト (OQL) 照会と同じような照会さえ可能になります。

RDF照会のコーディング

リスト4のPythonプログラムquery1.pyは、4RDFを使用してこの照会技法を作動させます。この場合、作動させるためにパターン・マッチング、issues.rdfファイルの読み込み、およびすべてのuogbuji割り当ての本文の印刷が行われます。(もちろん、Pythonを使用しない場合は、他のRDF照会ツール、たとえば、RDFDbやJena、参考文献のDave Beckettの「RDF Resource Guide」にリストされている照会などを使用することができます。)

                
from Ft.Rdf import Util
#Returns an RDF model object, and the database instance it uses for
#persistence (in our case, it's just a memory data structure)
model, db = Util.DeserializeFromUri('issues.rdf')
db.begin()
USER_ID_BASE = 'http://users.rdfinference.org/ril/issue-tracker#'
IT_SCHEMA_BASE = 'http://xmlns.rdfinference.org/ril/issue-tracker#'
print 'Actions assigned to uogbuji:'
#None is used as the wild-card
matching_statements = model.complete(None,
                                     IT_SCHEMA_BASE+'assign-to',
                                     USER_ID_BASE+'uogbuji'
                                     )
for statement in matching_statements:
    id = statement.subject
    matching_statements = model.complete(id,
                                         IT_SCHEMA_BASE+'body',
                                         None
                                         )
    body = matching_statements[0].object
    print "*", body
db.commit()

リスト4では、まずRDFをissues.rdfファイルから読み込み (直列化解除し) ます。次に、照会を行ってどのアクションがuogbujiに割り当てられているかを示すステートメントを見つけます。その次に、各ステートメントの主語 (これがアクションID) を使って各アクションの本文を照会します。Pythonと4Suiteがインストールされていれば、これと同じ例を次のように実行します。

$ python query1.py
Actions assigned to uogbuji
* Organize a vote on this topic
* Correct all to use the "0/1" form in the next draft.

これは最も低レベルのRDFモデル照会であるため、すこし面倒です。リスト5のPythonプログラムquery2.pyは、関連する主語や目的語などを直接照会することによって、いくつかの近道を取っています。その結果、リスト4の場合とまったく同じ機能がさらに簡単になっています。

                  
from Ft.Rdf import Util
#Returns an RDF model object, and the database instance it uses for
#persistence (in our case, it's just a memory data structure)
model, db = Util.DeserializeFromUri('issues.rdf')
db.begin()
USER_ID_BASE = 'http://users.rdfinference.org/ril/issue-tracker#'
IT_SCHEMA_BASE = 'http://xmlns.rdfinference.org/ril/issue-tracker#'
print 'Actions assigned to uogbuji:'
actions = Util.GetSubjects(model, IT_SCHEMA_BASE+'assign-to',
                           USER_ID_BASE+'uogbuji')
for action in actions:
    body = Util.GetObject(model, action, IT_SCHEMA_BASE+'body')
    print "*", body
db.commit()

リスト5でも、やはり2つのレベルの照会が行われています。すっきりしていて効率的なやり方をするには、これらの照会を結合して単一の要求として使用します。(それを可能にするには、RDF Inference Language (RIL) を使用します。このソフトウェアについては、今後このコラムで取り上げる予定です。ちなみに、例示の問題追跡データではRILのドラフト・オープン仕様を参照しています。) リスト6は、APIショートカットがある場合と、ない場合の、基本照会を実行した結果を示しています。

                
$ python query2.py
Actions assigned to uogbuji
* Organize a vote on this topic
* Correct all to use the "0/1" form in the next draft.

RDF照会では、メタデータ・ステートメント・コンポーネントの完全な一致は必要ありません。ほとんどの照会言語は、これよりさらに柔軟性に富んでいます。たとえば、リスト7 の Pythonプログラム (query3.py) は、普通の表現ベースの照会を使って、本文に "vote" ストリングが含まれているuogbujiに割り当てられたすべてのアクションを検出します。

繰り返しになりますが、リスト7のコードは単一の照会であり、RILを使用して効率性を高めています。RILについては、次回のコラムで説明します。リスト8は、普通の表現を照会で使用する場合を示しています。

                
$ python query3.py
Actions assigned to uogbuji
* Organize a vote on this topic

上に戻る

そして次回は ...

このコラムでは、例示の問題追跡アプリケーションを基にしてRDFモデル全体を作り上げる方法を示し、このモデルの基本的な照会操作について説明します。次回の記事では、非常に安価にRDFの能力を利用して入手できる1つのすばらしい機能について説明します。

参考文献

• Dave Beckett著RDF Resource Guide は、RDF関連記事、ツール、仕様、ディスカッション、イベントなどへのリンクを示した包括的なセットです。
  
  
• Dan Brickley著RDF visualizer は、Webを基にしているもので、任意のプラットフォームで使用でき、このコラムの図1のように、RDFファイルをグラフィック表現に変えます。
  
  
• 照会言語では、RDFデータベース、およびRDFモデルを扱うための試験的なJava APIであるJena に対してCおよびPerlによるアクセスを行うことができます。
  
  
• この記事の例は、4Suiteの XSLTプロセッサーを使用してテストされています。
  
  
• Tom HalfhillによるIBM Researchの論文XML: the next big thing は、次世代検索エンジンを強化するためのRDFの可能性について論じています。
  
  
• このコラムのこれまでの記事を参照してください。それぞれのサブタイトルは以下のとおりです。
  • XMLと意味体系の出会い: その現状
  • XMLと意味体系の出会い: 新参者たち、および古い隣人の1人との出会い
  • 意味論の世界を行く
  • ナレッジ管理のための基本的なXMLおよびRDF技法: 第1回
  
  

著者について

		Uche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る