レベル: 中級 Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.
2001年 7月 01日 著者のUche Ogbujiは、XMLによるナレッジ管理の実践的な検討を開始し、手始めにResource Description Framework (RDF) モデルに既存のXML形式からのデータを移植するための技法を説明します。3つのコード・リストで示すように、RDFは、特定のタイプのデータの決められた表記としてだけでなく、カスタマイズされたXMLのコンパニオンとして使用することができます。このコラムでは、コード・サンプルを紹介しながらRDFによりナレッジ管理をジャンプ・スタートさせることが、開発作業の比較的後の段階でも非常に簡単であることを示します。
Resource Description Framework (RDF) は、汎用のメタデータ・モデル記述化機能としてW3Cによって設計されたものですが、XMLデータの理想的なコンパニオンとしてふさわしい多くの機能を提供します。多くの新興XMLアプリケーションでは、アプリケーションの存続期間全体にわたってその中にカプセル化されたナレッジが、データベースまたはリポジトリー内のXML文書に保管されます。ナレッジ管理ツールとしてのRDFの効力の基礎は、ユーザーがこのナレッジを編成し、相互に関連させ、分類し、注釈することができるため、保管されたデータの総合的な価値が向上することにあります。RDFは複雑であると言われていますが、この評価は、XMLベースのアプリケーションにRDFサポートを簡単に追加できることからも、誤りであることが分かります。この記事で、RDFとXMLの間の共生関係の探求を開始します。まず、XMLからRDFを生成するためのXSLTの使用方法を説明します。
この記事を読むためにはRDFおよびXSLTをよく理解している必要があります。前にdeveloperWorksに掲載された私の
RDFとは、および参考文献でリンクされた他の論文を参照することをお勧めします。
レガシーとは必ずしも古い遺物ではありません
技術仕様のオープンな開発過程に関する問題追跡機能を例に考えてみます。この仕様はオンラインで掲載され、関係者はそれを読んで、仕様に関する問題を追加し、オープンな問題についてコメントし、問題に関連するアクション項目を割り当てるなどのことができます。
XMLは、この問題追跡機能を組み合わせるのに大変適したツールです。問題およびアクション項目の記述、およびそれらに関連したディスカッションのためには、柔軟な表記方法が必要ですが、データの意味体系を維持するための構造も大切です。私たちの例では、アプリケーションの開発はすでに行われていて、アクション項目の注意をユーザーに送信したり、検索やブラウズをサポートしたりするなどのタスクのために、基本的な技法が使用されています。しかし、開発者は、RDF処理に使用可能な多くの既存のツールや技法を利用するために、アプリケーションでRDFの使用を開始することに決定しました。
RDFの使用を選択する際に、開発者たちは、すべてのアプリケーション・データおよび論理を再設計することは望んでいません。可能なものを追加し、おそらく、RDF処理を段階的にアプリケーションの中核に移行することを考えるはずです。したがって、彼らが直面するタスクの1つとして、すでに集められているXMLデータから有益なRDFを生成することが必要となります。
XML形式の例
リスト1 は追跡機能における1つの問題をXML形式で表したものです。これには、その問題がどの文書、または文書の一部に関連しているのかを示す、固有IDと参照要素が含まれています。また、問題の最初の記述者が注記されています。このことは、システムのユーザー管理機能が使用されていることを意味しています。この文書には誰でも寄与することができますが、登録ユーザーは特別に注記され、特別に扱われます。問題の主要な記述と、ユーザーが付けたコメントはインラインで表示され、ユーザーに関連のアクションが割り当てられます。
データを種まきしてメタデータを収穫する
問題追跡機能で使用されているXMLファイルからRDFメタデータを抽出するには、いくつかの方法があります。おそらく最も簡単な方法は、次のセクションで示すような、ファイルを読み取ってメタデータのRDF/XMLシリアライゼーションを出力するXSLT変換プログラムを書くことです。
RDFは (良くも悪くも) URIにアンカーされますので、メタデータ・ノードのための何らかのURI構造が必要になります。問題が指摘された仕様の個所などのように、すでにURIができているものもあります。また、すでに特別なXML表現が行われているものもあります。私たちの例では、ユーザー・オブジェクトが個別のXMLファイルとして管理されています。さらに、メタデータ・ノード以外に応用の仕組みが存在しない、完全に抽象的なものもあります。この最後のカテゴリーの例として、私がリソースについて作成をお勧めするRDFタイプがあります。このRDFで使用するURIは以下のとおりです。
- 批評されている仕様のアドレス。例: http://rdfinference.org/ril/ril-20010502。
- 問題のXMLソースのアドレス。例: http://rdfinference.org/ril/issue-tracker/issues/i2001030423。
- 登録ユーザーのプロファイルのXMLソースのアドレス。例: http://rdfinference.org/ril/issue-tracker/users/uogbuji。
- 記述者、問題、割り当てなどを表すRDFタイプ。例: http://rdfs.rdfinference.org/ril/issue-tracker#Author。
可能なRDFシリアライゼーションの例
上のような条件のもとで、リスト1 から得られるメタデータを表現するRDFモデルのシリアライゼーションとして、リスト2 のようなものが考えられます。
いくつかの場合、私はコメントおよびアクション・リソースなどのような匿名リソースを使用しています。これは、モデル化の選択肢の1つです。たとえば、タスク・スケジューリングのためにアクションの索引を中央に集中させたい場合などには、アクションを匿名にしておくよりも、抽象アクションのためのURIを使用したほうがよいと思います。
XSLT変換プログラム
RDFがどのようなものであるのかが分かったと思いますので、問題記述を適切なRDFファイルに変換するための変換プログラムを構成することにします。リスト3 は、このような変換プログラムをXSLTで表したものです。
このリストで使用する技法のいくつかは、Web Services Description Language (WSDL) のXMLへの変換に関するセクションを含む、XSLTを使ったWSDLの処理 というdeveloperWorks記事ですでに説明されています。その記事では、RDFシリアライゼーションの結果をできるかぎり元のWSDL XMLに近いものにすることを目指していました。今回は、そのような制約がありませんので、変換プログラムはあまり難解ではありません。さまざまなXML要素を順番に訪れ、それに相当するRDF記述を少しずつ作成しています。
最も重要なトップレベル操作は、issue 要素の突き合わせです。これは、単に指定されたテンプレートを呼び出して、対応する問題に関するRDF記述を実際に作成させる操作です。このような間接的な方法を使用するのは、この変換プログラムのカスタマイズと拡張を柔軟に行えるからです。たとえば、次回の私のXML的思索 で示すように、問題文書をRDFにバッチ変換する別の変換プログラムで、名前付きテンプレートを使用することができます。
この例では、問題追跡プログラムで、オンライン仕様自体のほかにさまざまなリソースに関する問題を追跡することができます。(問題追跡プログラム自体で、バグ・レポートなどの形で問題をオープンすることができます。)このため、この設計では、参照要素の取り扱いをきわめて柔軟に行うことができます。テンプレートが、(参照要素が正しい個所でのみ解決されるようにするために) 別個のXSLTを使用して 、reference 要素の拡張可能な内容を検査します。現在のところ、この例のアプリケーションは、該当の問題からの参照を使用してRDF記述を作成するという簡単な方法によって、仕様が参照されている事例を扱うようになっています。より多くの拡張可能な参照を処理することが必要になると、xsl:when 文節を追加してそれらの事例を扱うようにすることができます。
ユーザー記述をプロファイルで登録することも、単にフリー・フォーム・テキストで登録することもできるようにするために使用される基本的な仕組みも示されています。
今後の予定
私はこのコラムで、XSLTを使用してXMLインスタンスからRDFを抽出する単純な例を示しました。XMLベースのアプリケーションがますます多く使用されるようになると、ナレッジ管理機能によってアプリケーションを拡張するために、このような技法が役立つようになります。
次回は、引き続き問題追跡プログラムを扱い、問題文書のバッチ処理、およびこのような処理に便利ないくつかのオープン・ソース・ツールを示します。
今回の記事および今後の記事で使用する例は、rdfinference.orgで行っている、RDF Inference Language 仕様のための問題追跡プログラムを作成する実際のプロジェクトを基にしたものです。プロジェクトの実際の成果は、まもなくこの公開サイトで入手可能になる予定です。しかしそれまでの間は、この記事に示すコード例を自由に試して、疑問、コメント、およびアイデアを私にお送りください。
参考文献
著者について  | 
| | Uche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。 |
記事の評価
| 
