レベル: 初級 Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
2001年 2月 01日 今回から、XMLのナレッジ管理という側面を取り上げたUche Ogbuji氏のコラムが始まります。一言でナレッジ管理といっても、その中身は、メタデータ、意味体系、Resource Description Framework (RDF)、トピック・マップ、自動走行式エージェントなど多岐にわたります。特にこの最初の記事で取り上げるのは、XMLと意味体系です。タイトルは何やら哲学的ですが、実戦的な観点から論題に切り込むため、対象となっているのはあくまでもプログラマーです。
この新しいコラム「XML的思索」では、XMLとナレッジ・アーキテクチャー (KA) の接点を取り上げます。ナレッジ・アーキテクチャーと言えば、いかにも専門用語くさく聞こえるかもしれませんが、実際には、XMLが円熟期に差しかかっているこの時期に登場してきたいくつかの非常に便利なテクノロジーを総称するのに好都合な用語です。メタデータ管理も、意味体系の透明性も、自動走行式エージェントも、XML独特の概念だというわけではありませんが、構造化データや半構造化データの構文を統一する見込みを持っているのはまさにXMLであり、このXMLによって、これまでほとんど不可能だったことでも実現の可能性が出てくるのです。
この種の記事の多くは哲学者を対象としているようですが、このコラムについては、プログラマーを対象にしているというのが特徴です。XMLを使って、社内データベースやWeb上のデータ内に潜んでいる貴重な情報 (ナレッジ) を収集したり、検索したりするための開発用のツールやテクニックを取り上げていきます。こんなふうに言うと、かなり大掛かりなコラムになりそうだと思えるかもしれませんが、実際には少しずつ論議を進めていきますので、一般常識の範囲からかけ離れるということはありません。
今回と次回の記事では、舞台設定をします。したがって、「コードを多く、理念を少なく」という筆者の基本方針からは若干外れる内容になります。まず、最初の2つの記事で取り上げるのは、XMLの意味体系と関連ボキャブラリーです。この段階では既存の仕様をおおまかに紹介するだけにして、実戦的なコードやテクニックはおあずけということにしておきましょう。
意味体系がこれほど騒がれるのはなぜか
それにしても、意味体系とは何でしょうか。この言葉の恐ろしい呪いなのか、意味体系の定義については、ほとんど意見の一致を見ることがありません。一般的には、システム内の共通構文の上に存在するXMLデータの仕様層を指します。こうした考えからすれば、XMLの意味体系 と言われている概念がたくさんある中で、いくつかの概念が浮かび上がってきます。
たとえば、次のような概念です。
- 要素型の名前や属性の名前 (場合によっては、内容を指す用語) の解釈方法
- 妥当な文書に基づく取引を実行するための処理ルール (またはビジネス・ルール)
- 1つの文書の構造化要素と別の文書の構造化要素との関係
もちろん、上記の3つの概念には多少の重なりがあります。
鏡に映した意味体系
2年前になりますが、筆者は、Sunworld (現在のUnix Insider:参考文献を参照) の記事の中で、新しいXMLとElectronic Data Interchange (EDI) の世界との相性の良さを指摘していました。1970年代のEDIを持ち出した1つの理由は、さまざまな組織の情報システム間で電子通信の自動化を促進するために、商取引のボキャブラリーを統一するという意図がEDIにあったからです。
EDIとは、特定の業界の構文と意味体系を定義するための仕様です。もちろん、汎用性の高い構文や意味体系もあれば、専門性の高い構文や意味体系もあります。XMLには十分に定義された構文と構造がありますが、現時点でいわゆる意味体系の透明性 と言われるものは実現されていません。つまり、XMLマシンが、特定の要素とその要素に基づく処理との間に一定の関係を確立する機能です。たとえば、PurchaseOrder 要素またはPO 要素と、この要素に基づく特殊操作を実行する高位の処理との間に一定の関係を確立する、といった具合です。要するに、意味体系の透明性とは、データ内の表現が概念の意味を忠実に表している状態を指します。意味体系の透明性を確認する究極の方法は、人間がXML処理ソフトウェアに用意されているメカニズムだけ を使って、XMLデータの意味を正確に理解できるかどうかという点です。
XMLだけで意味体系の透明性が実現されていないのは明らかです。だからこそ、数多くのXML技術者が意味体系に没頭しています。XMLシステムが意味体系の透明性を実現できないのであれば、電子取引を自動化する手段としては、30年前のEDIよりも劣るということになってしまいます。
XMLで意味体系の透明性を実現する必要があるかどうかについては、ほとんど異論がありません。XML 1.0仕様の完成前でも、さまざまなグループが意味体系の透明性を実現するための仕組みを開発しようとしていました。実際のところ、そのような試みのいくつかは、XMLとは離れたところでも生まれています。過去においても、現在においても、SGML、XML、EDI、表形式レポート、その他のマシン形式といった枠を超えて、用語を統一するための全体的なよりどころを作ろうという意図がそこにはあるのです。
ISO BSRの活用
EDIに由来する長老格のマシン可読意味体系があります。ISO Basic Semantics Register (BSR) です。1998年に開発が始まり、設立趣意書にはその目的が、「商業、工業、管理といった枠を超えて、多言語で汎用的にデータを理解するための中心的な参照ポイントとしての役割を果たすこと」とうたわれています。確かに、ISOならではとも言える野心的な目標です。それだけに、BSRには遅れが付きまとっています。
現時点で、基本的なルールが確立されています (ISO 16668:2000)。また、AccountsPayables、ContactParty.CustomerAssigned.Identifier、Contract など、数千項目が予備的なセットとして収集されています。BSRが完成すれば、プログラマーは、次のDTDのような意味体系XMLスキーマを記述できるようになるはずです。
<!ELEMENTAccountsPayables.Contact (ContactParty.CustomerAssigned.Identifier)>
<!ELEMENTContactParty.CustomerAssigned.Identifier (#PCDATA)>
|
ここで、会計業務を別の会社に委託しているメーカーの例を考えてみましょう。上記の要素をレポート形式の中に組み込む場合、意味体系の透明性が確保されているので、XMLボキャブラリーの開発者には次のような利点があります。
- 使用する要素型の名前をBSRの概念に合わせることによって、要素の意味からあいまいさを排除できます。したがって、メーカーと会計会社がデータに関するやり取りをするときに、両者の間で意味の取り違えが起こらなくなります。
- 用語の意味が明確なので、メーカーの形式と会計会社の標準形式との対応関係を確立する作業が非常にシンプルになります。場合によっては、そのような作業を完全に自動化することさえできます。メーカーがEDIを使用し、会計会社がXMLを使用しているような場合でも、対応関係の設定作業をシンプルにすることは可能でしょう。
- BSRの中で意味が与えられているので、たとえば、
ContactParty.CustomerAssigned.Identifier 要素とContract 要素が同じレポートの中に存在する場合でも、別々の文書に存在する場合でも、両者の関係をある程度識別できます。
 |
UN/CEFACT
: United Nations Centre for Trade Facilitation and Electronic Business
CEN/ISSS: European Committee for Standardization / Information Society Standardization System
DISA: Data Interchange Standards Association |
|
まだ予備的な段階ではありますが、BSRを現時点で試してみる価値はありそうです。Global Information Locator Service (GILS) という仕様によって、予備的なBSR項目をRDF Schema形式やXML Schema形式でコンパイルできるようになっているからです。GILSとは、構造化情報を検索するためのテクニックやリソースを組み込んだアメリカ政府の仕様です。このGILSに基づいたBSRのコンパイルは貴重なリソースであり、政府機関や民間の取引全般で頻繁に使用されている用語をすでにかなりカバーしています。
ただし、この予備的なコレクションは、まだ実験段階にあります。記述がかなり大ざっぱであるばかりか、XSchemaやRDFSの表現には構文エラーも含まれています。
それでも、BSRは、UN/CEFACT (全世界)、CEN/ISSS (ヨーロッパ)、DISA (アメリカ) といった重要な団体に影響を与えているので、BSRの動向には目が離せないでしょう。
統一ヨーロッパとアメリカの巨大企業
CEN/ISSSという団体は、XML/EDIの分野でたくさんの業績を残しています。ヨーロッパ共同体の中で情報システムの標準化を進めている委員会です。XML/EDIにかかわる作業は、公式には試験的なプログラムという位置付けになっていますが、UN/EDIFACT流のEDIをXMLに変換するための包括的なフレームワークを作り上げてきました。その変換フレームワークには、EDIに詳しい開発者が活用できるDTD生成ルールやサンプルが用意されています。確かに変換結果は一筋縄ではいきませんが、EDIの長い歴史からして、XML/EDIで使用されるフィールドやメッセージ・フローはたいへんよく定義されていると言えます。
明らかに、EDI関連の人たちは、XMLの意味体系の扱いという点でかなり先を行っています。この分野でEDIという名誉あるバッジをつけずに登場したのがMicrosoftです。Microsoftは1999年に、BizTalkというフレームワークを発表しました。BizTalkは、Microsoftとその提携先や業界団体が、スキーマやプロセス記述やサンプルXMLファイルを登録するためのリポジトリーです。XMLのいろいろな形式や関連プロセスの集配センターのような役割を果たしており、意味体系の透明性を確立するための一大勢力になっています。
BizTalkはそもそも1企業に由来しており、業界内の主導権争いもからんで、これまでも大きな論争の的になってきました。一部には、Microsoftが意味体系の分野で主導権を握って、XMLを乗っ取ろうとしているという意見もあります。そのような主導権争いは別にして、BizTalkフレームワークの中で機能するツールがぼちぼち出始めているのも事実です。その多くは、対応関係を設定するためのソフトウェアであり、たとえば、XML Solutionsには、ボキャブラリー間の対応関係を設定するためのGUIが用意されています。さらに、SOAPに基づいたBizTalkのXMLメッセージング形式の仕様がすでに公開されているので、その仕様を使って作業を始めることもできます。ただし、BizTalkのメッセージング作業を本格的に始めるには、MicrosoftのBizTalk Serverという商用製品が必要です。
新規参入の仕様
OMGのXML Metadata Interchange (XMI) やUnisysのUniversal Repository (UREP) などもいくぶん関連のある仕様ですが、今回の記事では取り上げませんでした。それらの仕様の主な目的は、アプリケーション開発モデルのやり取りだからです (ただし、XMIもUREPもXMLといくらか関連があります)。
本稿では、XMLの意味体系という舞台に登場してきた長老格の仕様をいくつか取り上げました。とはいえ、この分野では、ebXML、UDDI、eCoといった新規参入の仕様や、縦割りの業界団体による仕様がかなり幅をきかせるようになっています。次回の記事では、こうした新規参入の仕様のさらに実用的な側面を取り上げる予定です。
参考文献
著者について | 
| | Uche Ogbuji は、次世代の Web 技術を専門とするサービスの会社である、Uli, LLC の代表者です。Ogbuji 氏は XML、RDF、およびナレッジ管理アプリケーション用のオープン・ソース・プラットフォームである 4Suite の開発リーダーであり、Versa RDF 照会言語の開発リーダーでもあります。ナイジェリア出身のコンピューター・エンジニア兼ライターで、米国コロラド州ボールダー在住です。彼に関して詳しくは、彼のブログである Copia を見てください。 |
記事の評価
| 
