88171.net

Ontology Development 101: 初めてオントロジーをつくる人のためのガイド

Ontology Development 101: A Guide to Creating Your First Ontology の私的な日本語訳です.図表などは 原文 を参照してください.

誤訳や解釈の間違いなどありましたら是非教えてください.

1 何故オントロジーを作るのか

ここ数年,オントロジー ( あるドメインにおける用語やその関係の明示的・形 式的な表現 [Gruber 1993] ) は人工知能の分野から他のドメインの専門家の手 へと移りつつある.オントロジーは World Wide Web 上で一般的なものとなっ た.Web 上におけるオントロジーは,Yahoo! のように Web サイトをカテゴラ イズするといった大きな分類から,Amazon.com のように販売する製品やその特 徴をカテゴライズするといった用途にまで用いられている.WWW コンソーシア ム ( W3C ) ではResource Description Framework ( Brickley and Guha1999 ) を開発している.これは,情報を検索するエージェント等のプログラムに可 読であるよう,Web ページ上の知識を記述するための言語である.W3C と共同 で研究を進めている高等研究計画局 ( DARPA ) では,Web 上でのエージェント 同士の対話を促すことを目的として,RDF をより多様な表現が可能になるよう 拡張した DARPA Agent Markup ( DAML ) を開発している (Hendlerand McGuinness 2000) .現在多くの分野で,専門家がその分野の情報を共有し注釈 を付けるのに利用できる標準オントロジーが作られている.例えば薬学の分野 では snomed ( Price and Spackman 2000 ) やUnified MedicalLanguage System ( Humphreys, Lindberg 1993 ) の意味ネットワークのように,標準化・ 構造化された巨大な語彙が作られている.同様に,より広範で一般的なオント ロジーも作られている.例えば United Nations DevelopmentProgram と Dun & Bradstreet は,製品やサービスを分類するのに利用可能な UNSPSC オントロ ジーを共同で開発した ( http://www.unspsc.org/ ) .

オントロジーは,あるドメインにおける情報を共有する必要がある研究者向け の,一般的な語彙を定義する.それにはそのドメインにおける基本的な概念や それらの関係の,機械可読な定義も含む.

何故人はオントロジーを開発したいと思うのか.理由は例えば以下のようにな るだろう.

  1. 人やエージェントプログラムの間で,情報の構造の基本的な理解を共有した い
  2. そのドメインにおける知識の再利用を可能にしたい
  3. そのドメインにおける前提・仮定を明示したい
  4. そのドメインの知識と実践的な知識を分離したい
  5. そのドメインの知識を検証したい

一つ目の要求は,オントロジーを開発する上で比較的一般的な目的である ( Musen 1992; Gruber 1993 ) .例えば,医薬品の情報を持った,もしくは医薬 品の E コマースサービスを提供する複数の Web サイトがあるとしよう.もし これらの Web サイトが皆使っているような用語について基礎的なオントロジー を用い,共有しているとしたら,エージェントプログラムはこれらの異なるサ イトから情報を収集し展開することができる.エージェントはこの収集された 情報を,ユーザからの問い合わせに答えたり,他のアプリケーションに対して の入力として用いることもできる.

二つ目の要求は,最近のオントロジーの研究の発展以前には強力な推進力の一 つであった.例えば,多くの異なるドメインにおけるモデルでは時間の概念を 定義することが必要である.これには時間の間隔の概念や時間の中のある一点, 相対的な時間の長さなどが含まれる.もしある研究者のグループがそういった 概念を細かく定義したオントロジーを作ったとすれば,他の人々はそれぞれの 領域で単にそのオントロジーを再利用すれば良いだけである.加えて,もし巨 大なオントロジーを作る必要がある場合には,既に存在する複数のオントロジー を大きな一つのドメインの部分部分を記述するのに使い,それらを統合するこ とができる.さらに,UNSPSC オントロジーのような一般的なオントロジーを再 利用することができ,自分が扱うドメインを記述するために拡張することもで きる.

三つ目は,もしあるドメインに関する我々の知識が変わった場合にも,実装に よって前提を簡単に変更することができることに起因する.プログラミング言 語の中にハードコーディングされた世界の前提は,見つけにくく理解しにくい だけでなく,特にプログラミングの専門知識がない人にとっては変更すること が難しい.また,あるドメインの知識に関する明示的な記述は,そのドメイン で用いられる用語の意味を学ばねばならない初心者にとって便利である.

四つ目もオントロジーにおける一般的な利用法である.製品を要求された仕様 に応じてコンポーネントから設定する作業を記述することもできるし,製品や コンポーネント自身とは独立してこれらの設定を行なうプログラムを実装する こともできる ( McGuinness, Wright 1998 ) .そして PC のコンポーネントや 特性に関するオントロジーを作り,オーダーメイドの PC を設定するアルゴリ ズムを適用することができる.また同様のアルゴリズムを用いると,エレベー ターにエレベーターのコンポーネントに関するオントロジーを feed する ことでエレベーターの設定をすることもできる ( Rothenfluh et al. 1996 ) .

五つ目の要求は,用語の宣言が利用できれば可能である.用語の形式的な分析 は,既に存在するオントロジーを再利用しようとしたり拡張しようとしたりす るとき,非常に価値あるものである ( McGuinness et al. 2000 ) .

ドメインにおけるオントロジーが最終的な目標でないことはままある.オント ロジーを作ることは,他のプログラムが利用するためにデータセットやその構 造を定義することと同義である.問題解決メソッド,特定のドメインに閉じな いアプリケーション,そしてソフトウェアエージェントは,オントロジーやオ ントロジーで構成される知識ベースをデータとして使う.例えば,この論文に おいて我々はワインと料理,そしてワインと料理のおいしい組み合わせについ てのオントロジーを作る.このオントロジーはレストラン管理ツールなどのア プリケーションの基礎として用いることができるだろう.あるアプリケーショ ンは今日のメニューに合うお薦めのワインを選んだり,ウェイターや客の質問 に答えたりできる.また別のアプリケーションはワインセラーに保管されてい るワインの在庫を分析し,今後のメニューと照らし合わせてどの種類のワイン を増やしたり,どのワインを特に仕入れるべきかを提案してくれる.

このガイドについて

オントロジーを編集する環境として Protege-2000 ( Protege 2000 ) , Ontolingua ( Ontolingua 1997 ) , Chimaera ( Chimaera 2000 ) を開発した が,ここでは Protege-2000 を例に用いる.

ここで用いるワインと料理の例は,CLASSIC ( 記述論理のアプローチに基づく 知識記述システム ) ( Brachman et al. 1991 ) に関する論文で示されている 知識ベースの例に大まかに沿っている.CLASSIC チュートリアル ( McGuinness et al. 1994 ) ではこの例をより深く掘り下げている. Protege-2000 や他のフレームベースのシステムはオントロジーを宣言的に記述 する.つまりクラス階層や個体がどのクラスに属するかというような内容の明 記から始める.

このガイドにおけるオントロジーデザインのアイディアはオブジェクト指向デ ザインに関する文献を元にしている ( Rumbaugh et al. 1991; Booch et al. 1997 ) .しかしながら,オントロジーの作成はオブジェクト指向プログラ ミングにおけるクラスやその関係をデザインすることとは異なる.オブジェク ト指向プログラミングではクラスの持つメソッドが重視される.つまりプログ ラマーはクラスの 操作可能なプロパティを中心にしてデザインを考える. 一方オントロジーのデザイナーはクラスの構造的な プロパティを中心とし てそのデザインを考える.結果的に,たとえ同じドメインを扱っていても,オ ントロジーのクラス構造やクラス間の関係は,オブジェクト指向プログラムの それとは異なる.

オントロジーの作成者が対峙する必要のある問題を全てカバーすることは不可 能であり,我々もそれをこのガイドで目指しているわけではない.その代わり, スタートポイントを提供する.これからオントロジーを作ろうと思っているデ ザイナーの役に立つだろうガイドである.ドメインにより複雑な構造やデザイ ンのメカニズムが必要な場合に見るべきところを最後の方に纏めてある.

最後に,オントロジーデザインにおいて唯一の手法などありはしないし,我々 もそれを見つけだそうとしているのではない.ここで示すアイディアは,我々 がオントロジーを作る実験を経験した中で便利だと思ったことに過ぎない.巻 末に別の手法についてのリストを用意してある.

2 オントロジーとは何か

人工知能に関する文献にはオントロジーの定義がたくさん載っている.それら の多くは互いに否定しあっている.このガイドの目的に鑑みると,オントロジー とは,特定のドメインにおける概念 ( クラス ) ,その概念の様々な特徴や属 性を示すプロパティ ( スロット ( slot:属性と属性値の組,もしくは,プロパ ティ ) ,そしてスロットの制約 ( ファセット,もしくはロール制約 ) ,これ らの明示的・正規的な記述であるとする.オントロジーはクラスの個々のイン スタンスとセットで知識ベースを構成する.実際には,どこまでがオントロジー でどこからが知識ベースであるかという明確な境界がある.

クラスは多くのオントロジーにおいて重視されるべきものである.クラスは領 域における概念を定義する.例えば,Wine クラスは全てのワインを代表する. ある特定のワインはこのクラスのインスタンスである.このドキュメントを読 んでいる傍ら,あなたの目の前にあるグラスに注がれたボルドーワインは, Bordeaux Wine クラスのインスタンスである.あるクラスは,そのスーパーク ラスと比べてより狭い概念を持つサブクラスと呼ばれるクラスを持つことがで きる.例えば,Wine クラスはRed wineクラス,White wineクラス,Rose wine クラスというサブクラスに分けることができる.これとは別に,Wine クラスを スパークリングワインとそうでないワインのクラスに分けることもできる.

スロットはクラスやインスタンスのプロパティを定義する.シャトーラフィッ トロートシルトのポイヤックワインはコクのあるワインである.これはシャトー ラフィットロートシルトワイナリーで生産される.この例で,Wine を表す二つ のスロットが登場した.Body のスロットはコクという値を持ち,メーカーのス ロットはChateau Lafite Rothschild} Wineryという値を持つ.クラスレベルで 言えば,Wine クラスのインスタンスにはそのFlavor,Body ,Sugar level,そ してMakerといったようなスロットを持たせることができる (ここではクラス名 の頭文字を大文字にし,スロット名を小文字で表現する).

Wine クラスやそのサブクラスの Pauillac Wine クラスの全てのインスタンス は,メーカーというスロットの値としてWineryクラスのインスタンスを持つ ( 図1 ) .Wineryクラスの全てのインスタンスはProducesというスロットを持ち, そのワイナリーで生産している全てのワイン ( Wine クラスもしくはそのサブ クラスのインスタンス ) をスロットの値として持つ.

実践的な立場からすれば,オントロジーを作るということは

ということである.

ここまでくれば,これらのクラスの各々のインスタンスのスロットの値を決め たりスロットの制約を追加するなどして,知識ベースを作ることができる.

( 図1: ワインのドメインにおけるクラス,インスタンス,そしてそれらの間の 関係.クラスは黒,インスタンスは赤で示してある.矢印はスロットや, instance-of や subclass-of などの内部的な関係を示している. )

3 単純な知識エンジニアリングの手法

前に述べたように,オントロジーを作る上での唯一の正しい方法など存在しな い.ここでは考えるべき一般的な問題について言及し,オントロジーを作る上 での一つのプロセスを提供する.まずオントロジーの下書きから始め,次にそ のオントロジーを修正・改訂して詳細を埋めていく.その途中で,賛否や別の 手法での実装,またデザイナーに求められるモデリング上の決定についても言 及する.

まず,これから何度も思い返すことになるであろう,オントロジーデザインに おける基本的なルールについて述べる.これらのルールは些か教条主義的に思 えるかもしれない.しかしこれらは,多くの場面でデザインを決める上で役に 立つことだろう.

  1. ドメインのモデルを作る上で唯一絶対の方法はない.常に明確な別の方法が ある.最良の方法とは常に,あなたが思い描いているアプリケーションやあ なたが期待している拡張に依存する.
  2. オントロジーを作る作業とは,くり返しの作業である.
  3. オントロジーにおける概念は,対象となるドメインのオブジェクト ( 物理 的もしくは論理的な ) や関係により近いほど望ましい.対象となるドメイ ンを説明する文章には大概名詞 ( オブジェクト ) や 動詞 ( 関係 ) が含 まれているだろう.

つまり,我々が何のためにオントロジーを使おうとしているのか,そしてその オントロジーが詳細を定義するのかより一般化されるのかという点が,これか らのモデリングにおける判断のガイドとなるだろう.他の実用的なもの中から, どれがよりプロジェクトに見合う働きをするか,より直感的か,より拡張可能 か,そしてよりメンテナンス性が高いかという判断をする必要がある.また同 時に,オントロジーはこの現実世界のモデルに過ぎず,オントロジーにおける 概念はこの現実性を反映している必要があるということを覚えておかねばなら ない.最初のバージョンのオントロジーをどのようにするかを決めたら,次に アプリケーションや問題解決手法,対象のドメインの専門家との話し合い ( も しくはこれらの組み合せ ) によって,そのオントロジーを評価・デバッグする. 結果的に,そのオントロジーを修正する必要に迫られるだろう.この繰り返し デザインするプロセスは,恐らくそのオントロジーが存在する限り続くことだ ろう.

Step 1. オントロジーのドメイン及びスコープを決める

まずドメインとスコープを決めることからオントロジーの作成を始めることを 勧める.つまりこれらの簡単な質問に答えることだ.

これらの質問への答えは実際にオントロジーをデザインする過程で変わること もあるだろう.しかしこれらの質問は常にモデルのスコープを狭めるという点 で役に立つはずだ.

前に述べたワインと料理のオントロジーについて考えてみよう.料理とワイン について説明するというのがこのオントロジーのドメインであり,ワインと料 理のおいしい組み合わせを提案するアプリケーションがこのオントロジーのこ こでの利用目的である.

様々な種類のワインや主な料理の種類,ワインと料理のおいしい,もしくはお 薦めできない組み合わせといった概念は,当然このオントロジーに含まれるこ とになる.同時に,例えワインや料理の概念と近かろうとも,ワイナリーのワ インの在庫やレストランの従業員などの概念は,このオントロジーには含まれ ないだろうことがわかるだろう.

もし今デザインしているオントロジーがワインマガジンの記事の自然言語処理 に用いられるのであれば,オントロジーの概念として類義語やスピーチのパー ト情報を含めるのは重要だろう.レストランの客がワインを選ぶ手引きとして 用いられるのであれば,ワインの小売価格を含める必要があるだろう.バイヤー がワインセラーにワインを補充するときに使われるのであれば,卸売価格や手 に入るか否かという情報が必要になる.もしオントロジーの保守をする人々が, ユーザが用いる言語と異なる言語でオントロジーを記述した場合,言語間のマッ ピングを用意せねばならないかもしれない.

competency questions

オントロジーのスコープを判断する一つの方法は,オントロジーを基礎とした 知識ベースが答えられるべき質問 ( competency questions ) をリストアップ することである ( Gruninger, Fox 1995 ) .これらの質問は後にリトマスとし て働くこととなる.オントロジーはこれらの種類の質問に答えられるだけの十 分な情報を持っているか.質問への答えは一定以上詳細あったり,特定の範囲 についての説明を含む必要があるか.これらの質問はあくまでスケッチであっ て,厳密である必要はない.

ワインと料理のドメインでは,質問は以下のようになる.

この質問のリストから判断すると,オントロジーにはワインの様々な特徴,ワ インの種類,ビンテージイヤー ( 良い年 / 悪い年 ) ,合うワインを選ぶ上で 問題となる料理の分類,料理とワインのお薦めの組み合わせを含める必要があ る.

Step 2. 既にあるオントロジーを再利用することを考える

他の誰かが何を作っていて,我々の特定のドメインやタスクに流用するために そのソースを磨いたり拡張したりすることができるかを考えることは,常に価 値あることである.既に存在するオントロジーを再利用することは特に,既に 特定のオントロジーや管理された語彙を使うよう作られた他のアプリケーショ ンと我々のシステムが協調するような場合には,必要なことである.既に多く のオントロジーがデジタルデータとして公開されていて,あなたが使っている オントロジー開発環境にインポートすることができる.オントロジーが表現さ れる形式というのは,しばしば問題とならない.というのも,多くの知識表現 システムはオントロジーをインポートしたりエクスポートしたりできるからで ある.ある知識表現システムが特定の形式を扱えなかったとしても,オントロ ジーをある形式から別の形式に変換するのは,それほど困難な作業ではない.

再利用可能なオントロジーは Web 上や文献の中で見つけることができる.例え ば,Ontolingua オントロジーライブラリー ( http://www.ksl.stanford.edu/software/ontolingua ) や DAML オントロジー ライブラリー ( http://www.daml.org/ontologies ) を使うことができる.他 にも一般に公開された商用オントロジー ( e.g., UNSPSC ( http://www.unspsc.org ) , RosettaNet ( http://www.rosettanet.org ) , DMOZ ( http://www.dmoz.org ) ) がある.

例えば,フレンチワインに関する知識ベースは既に存在するかもしれない.も しその知識ベースや,その基礎となるオントロジーをインポートすることがで きれば,フレンチワインの分類だけでなく,ワインを区別したり説明するのに 使えるワインの特徴の分類の手掛かりも得ることができる.商用の Web サイト, 例えばワインの販売を行なっている www.wines.com のようなサイトでは,それ ぞれのワインのプロパティのリストが手に入るかもしれない.

しかしながら,このガイドではまだ関連するオントロジーが存在せず,スクラッ チからそのオントロジーを作ることを考える.

Step 3. オントロジーにおいて重要な用語を列挙する

言及したりユーザに説明したい全ての用語を列挙することは役に立つ.どの用 語について話をしたいのか.これらの用語はどんなプロパティを持っているの か.その用語について何を言いたいのか.例えば,ワインに関する重要な用語 として,ワイン,葡萄,ワイナリー,地方,ワインの色,味,香り,糖度など が挙げられる.料理の種類としては魚料理や肉料理があるし,ワインには白ワ インのようなサブタイプもある.考えてみれば他にもあるだろう.まずは,概 念間の重複や用語同士の関連,概念が取り得るプロパティや,そもそもその概 念がクラスなのかスロットなのかというようなことは全て忘れて,用語を纏め た包括的なリストを作ってみることが大切だ.

次の二つのステップ,つまりクラスの階層構造を考えることと概念の持つプロ パティ ( スロット ) を決める作業は,密接に絡み合っている.まず最初にあ る用語について考えてから別のものを考えるという方法は簡単ではない.通常 は,まず階層構造の中でいくつかの概念の定義を決め,次にそれらの概念のプ ロパティを決めるといったように進めるのが良いだろう.これらの二つのステッ プは,オントロジーデザインの過程で最も重要なステップである.ここではそ れらについて簡単に述べるに留め,次の二つのセクションで,考えるべきより 複雑な問題や一般的な落とし穴,判断すべきことなどについて述べることにす る.

Step 4. クラスやその階層構造を決める

クラスの階層構造を考えるにはいくつかのアプローチがある ( Uschold, Gruninger 1996 ) .

図2は階層の異なる概念の例を示している.

( 図2: ワインの概念の階層構造.ワイン,赤ワイン,白ワイン,ロゼワインは より一般的な,トップレベルの概念である.一方ポイヤックワインやマルゴー ワインは階層の中でも特化された,ボトムレベルの概念である. )

この三つの手法のなかで,他のものより本質的に良い手法はない.どの手法を 使うべきかという判断は,その人がどのようにドメインを見ているかに大きく 依存する.もし開発者がそのドメインをシステマティックでトップダウン的な ものだと見ているのであれば,トップダウンのアプローチを用いるのが最も簡 単だろう.組み合わせのアプローチは,しばしば多くのオントロジー開発者に とって簡単だろう.なぜならミドルレベルの概念というのは,ドメインにおい てより説明的な概念であることが多いからである ( Rosch 1978 ) .

もし,まず最も一般的な分類で分けることでワインを考えようとしているので あれば,トップダウンのアプローチが使いやすいだろう.ある特定の例をベー スにして考えようとしているのであれば,ボトムアップのアプローチがより適 切だろう.

どのアプローチを選んだとしても,我々はたいていクラスを定義することから 始める.Step 3 で作ったリストから,オブジェクトを説明するのではなく,独 立した具体的なオブジェクトを定義する用語を選び出す.これらの用語はオン トロジーにおいてクラスになるだろうし,クラスの階層構造においてアンカー となるだろう

(また,クラスを,引数を一つ取る質問を構成する述語と見ることができる ( 例えば "Is this object a wine?" ) .同様に,スロットを,引数を二つ取る 質問を構成する述語と見ることができる ( 例えば "Is the flavor if this object strong?","What is the flavor of this object?" ) )

そして,あるクラスのインスタンスであるオブジェクトが別のクラスのインス タンスであるか否かという問いを通して,クラスを階層構造の中で分類してい く.

もしクラス A がクラス B のスーパークラスであるなら,B の全てのインス タンスは同時に A のインスタンスでもある.

言い換えれば,B は A の 一種の 概念を表現している.

例えば,ピノノワールワインは必ず赤ワインである.よって,Pinot Noir Wine クラスはRed wineクラスのサブクラスである.

図2はWine オントロジーにおけるクラス階層の一部を示している.セクション 4 では,クラスの階層構造を決める上で必要なことについて詳しく述べる.

( 図3: Wine クラスのスロットとこれらのスロットのファセット.Makerスロッ トの隣にある I のアイコンは,そのスロットが inverse を持っていることを 示している.( セクション 5.1 を見よ ) )

Step 5. クラスのプロパティ ( スロット ) を決める

単独で存在するクラスは Step. 1 で示したようなcompetency questions に答 えるだけの十分な情報を持っていない.クラスを定義したら,次に概念の内部 的な構造を定義する必要がある.

既に Step 3. で作った用語のリストからクラスを作ってある.残りの用語の多 くは,これらのクラスのプロパティであることが多い.これらの用語には,例 えばワインの色,味,香り,糖度,ワイナリーの場所などが含まれるだろう.

リストに含まれるそれぞれのプロパティについて,それがどのクラスについて 述べたものなのかを判断せねばならない.これらのプロパティはクラスに付随 するスロットとなる.このように,Wine クラスはColor,Body ,Flavor, Sugar level というスロットを持つことになり,WineryクラスはLocationとい うスロットを持つことになる.

一般的に,オントロジーのスロットとなり得るオブジェクトのプロパティには, いくつかのタイプがある.

このように,我々が既に用意しているプロパティに加え,Wine クラスには Name,Area,Maker,Grapeの各スロットも追加する必要がある.図3はWine ク ラスのスロットを示している.

あるクラスの全てのサブクラスは,そのスーパークラスのスロットを *継承 * する.例えば,Wine クラスの全てのスロットは,Red wineやWhite wineな ど,そのサブクラスによって継承される.Red wineクラスにはTannin levelの スロット ( 低,中もしくは高 ) を加えることになるだろう.そしてTannin levelのスロットは,Red wineクラスの全てのサブクラス ( Bordeaux や Beaujolais のような ) によって継承される.

あるスロットは,そのプロパティを持ち得る最も一般的なクラスによって定義 されるべきである.つまり,Wine クラスは全てのインスタンスが味や色といっ たプロパティを持ち得る最も一般的なクラスなので,それらのスロットはWine クラスで定義されるべきである.

Step 6. スロットの制約を決める

スロットは,値の型,取り得る値,値の数 ( 個数制約 ) などを定義したファ セットを持つことができる.例えば,Nameスロット ( つまりここではワインの 名前 ) の値は一つの文字列である.つまり,Nameスロットは String 型の値を 取るスロットであると言える.Producesスロット ( つまりここではワイナリー がワインを生産する ) は複数の値を取り,その値はWine クラスのインスタン スである.つまり,ProducesスロットはWine クラスに属する Instance を値と して取り得る.

では,一般的なファセットをいくつか見てみよう.

個数制約

個数制約とはそのスロットがいくつの値を取り得るかという制約である.いく つかのシステムでは一つの個数制約 ( 多くて一つの値 ) と複数の個数制約 ( いくつの値でも取り得る ) しか区別しない.Wine のBody スロットの個数制約 は一つである(ある一種類のワインの味は常に一つ ) .あるワイナリーで生産 されたワインは,そのWineryクラスの生産スロットの複数の値となり得る.

いくつかのシステムでは,より詳細にスロットの値を定義するため,値の最小 個数と最大個数を定義することができる.N 個の最小個数制約は,そのスロッ トには少なくとも N 個の値があるということである.例えば,Wine クラスの Grapeスロットには少なくとも一つの値が含まれなければならない.ワインは少 なくとも一種類の葡萄から作られるからである.M 個の最大個数制約は,その スロットには多くても M 個までの値しかないということである.バライエタル のワインのGrapeスロットの値の最大個数は一つである.これらのワインは単一 品種の葡萄から作られているからである.最大個数を 0 に設定することも時に は有効である.こうすると,特定のサブクラスでそのスロットが値を持ち得な いということを示すことができる

型制約

型制約とは,どのような型の値がこのスロットの値となり得るかという制約で ある.一般的な型を以下に示す.

図4はWineryクラスのProducesスロットの定義を示している.

( 図4: ワイナリーで生産されたワインを示すProducesスロットの定義.このス ロットは複数の,Instance 型で且つWine クラスのインスタンスを取る. )

スロットのドメインとレンジ

Instance 型の値を取るスロットが取り得るクラスは,しばしばそのスロットの レンジと呼ばれる.図4の例ではWine クラスがProducesスロットのレンジであ る.いくつかのシステムでは,特定のクラスにスロットが属する場合に,その スロットのレンジを制約することができる.

あるスロットが付随するクラス,もしくはあるスロットがそのプロパティを定 義するクラスは,そのスロットのドメインと呼ばれる.Wineryクラスは Producesスロットのドメインである.クラスにスロットを付随させるようなシ ステムにおいて,スロットが付随するクラスはたいていそのスロットのドメイ ンである.ドメインを個々に明記する必要はない.

あるスロットのドメインやレンジを判断する方法は似ている.

あるスロットについてドメインやレンジを定義する際には,最も一般的なク ラス,もしくは単独でそのスロットのドメインやレンジとなり得るクラスを探 すべきである.一方,過度に一般的なドメインやレンジを定義すべきではない. スロットのドメインとなる全てのクラスはスロットによって定義されるべきで あり,スロットのレンジに含まれる全てのクラスのインスタンスは,潜在的に そのスロットの値となり得る.レンジに対する過度に一般的なクラス ( 例えば, 誰も THING というレンジを作ろうとは思わないだろう ) は,全ての値となり 得るクラスを選ぼうとするだろう.

Producesスロットのレンジである全てのWine クラスのサブクラスを列挙する代 わりに,Wine クラスだけを列挙すべきである.同時に,オントロジーにおいて 最も一般的なクラスである THING クラスを,あるスロットのレンジとしたいと は思わないだろう.

より一般的に言えば,

あるスロットのレンジやドメインを定義したリストにあるクラスとそのサブ クラスが含まれているのであれば,サブクラスを取り除け.

もしスロットのレンジにWine クラスとRed wineクラスが両方とも含まれている のであれば,それは新たな情報が加えられているわけではないので,Red wine クラスを取り除いてしまって良い.Red wineクラスはWine クラスのサブクラス であるから,そのスロットのレンジは既に,他のWine クラスのサブクラスと同 様に,暗黙的にRed wineクラスを含んでいるからである.

もしあるスロットのレンジやドメインであるクラスのリストに,A クラスが 含まれていないが A クラスの全てのサブクラスが含まれている場合,レンジに は A クラスのみを含め,サブクラスは取り除くべきである.

そのスロットのレンジとしてRed wine,White wine,Rose wine ( これはWine クラスの直接のサブクラスを列挙している ) を含める代わりに,レンジを Wine クラスそのものに指定することができる.

あるスロットのレンジやドメインとなるクラスのリストに,A クラスのほと んどのサブクラス ( しかし全てではない ) が含まれるとき,A クラスでより 適切なレンジの定義ができるかもしれないと考えよ.

スロットのドメインとしてクラスを付けるのと同様の方法でクラスにスロット を付けるようなシステムでは,スロットを付けるのにも同様のルールが適用さ れる.その際,できるだけそれを一般化することを考えねばならないし,同時 に,そのスロットを付けようとするクラスは,そのスロットが示すプロパティ を確かに持っていることを確認せねばならない.Red wineクラスのサブクラス ( 例えば Bordeaux, Merlot, Beaujolais など ) にはそれぞれTannin levelス ロットを付けることができる.しかし,全ての赤ワインはTannin levelプロパ ティを持っているので,このスロットはより一般的なクラスであるRed wineク ラスに付けるべきである.Tannin level スロットをこれ以上一般化すること ( 例えばこのスロットを代わりに Wine クラスに付けること ) は適当でない. なぜなら,例えば白ワインについて述べるときにタンニンの度合いを用いるこ とはないからである.

Step 7. インスタンスを作る

最後のステップは,その階層の中のそれぞれのクラスから個々のインスタンス を作ることである.クラスからインスタンスを作るには以下のようなことが必 要である.

例えば,Beaujolais ワインの具体的な種類の一つとして Chateau-Morgan-Beaujolais というインスタンスを作ることができる. Chateau-Morgan-Beaujolais は全ての Beaujolais ワインを示すBeaujolais ク ラスのインスタンスである.このインスタンスは以下のようなスロットの値を 持つ ( 図5 ) .

Body Light
Color Red
Flavor Delicate
Tannin level Low
Grape Gamay ( Wine grape クラスのインスタンス )
Maker Chateau-Morgon ( Winery クラスのインスタンス )
Region Beaujolais ( Wine-Region クラスのインスタンス )
Sugar Dry

( 図5: Beaujolais クラスのインスタンスの定義.このインスタンスは, Beaujolais 地方の Chateau Morgan ワイナリーで Gamay 種の葡萄から作られ る Chateau Morgan Beaujolais というワインを示している.味は軽く,微妙な 香りで,色は赤く,タンニンは少ない.そしてこのワインはドライである. )

4 クラスやクラスの階層構造を定義する

このセクションでは,クラスやその階層構造を定義する ( セクション 3 の Step 4 ) 際に注意すべきこと,及び簡単に対処できる間違いについて述べる. 前に述べたように,あるドメインにおいて,唯一絶対的なクラスの階層構造と いうのは存在しない.どのような階層構造が適するかは,そのオントロジーが どのように利用されるか,アプリケーションや個人的な設定においてどのくら いの詳細度が必要なのか,そして時には他のモデルとの互換性などにも依存す る.しかしここでは,クラス階層を考えるときに覚えておくべきいくつかのガ イドラインを示す.新しいクラスをある程度定義したら,一度立ち止まって, それらのクラスがガイドラインに沿うものか否かを判断してみると,きっと役 に立つことだろう.

4.1 クラス階層が正しいか確認する

``is-a'' 関係

クラス階層は ``is-a'' 関係を示す.つまり,B クラスの全てのインスタンス が同時に A クラスの全てのインスタンスである場合,A クラスは B クラスの サブクラスであるということである.例えば,Chardonnay は White wine クラ スのサブクラスである.これを分類学以外の視点で考えると,kind-of ( ~の一種 ) の関係として見ることができる.つまりシャルドネは白ワイン * の一種* であると考えることができる.同様にジェット機は飛行機の一種であ るし,肉は食べ物の一種である.

あるクラスのサブクラスが示す概念は,そのスーパークラスが示す概念 の一 種 である.

一本のワインは全てのワインのサブクラスではない

モデリングにおける一般的なミスの一つは,ある概念が単数の場合と複数の場 合を分け,前者を後者のサブクラスとして両方ともクラス階層の中に含めてし まうことである.例えば Wines というクラスを定義して,さらに Wine という クラスを Wines クラスのサブクラスとして定義するのは間違いである.クラス 階層が kind-of の関係を示しているということを考えれば,ここでのモデ リングの間違いは自ずと明らかになるだろう.一本の Wine は Wines の一種で はない.このような間違いを防ぐには,クラスに名前を付ける際,名詞の単数 形もしくは複数形を常に統一して使うことである.( 概念の名前の付けかたの 議論は Section 6 を見よ. )

階層関係の推移性

サブクラスの関係は推移的である.

B が A のサブクラスであり,C が B のサブクラスであるなら,C は A のサ ブクラスである.

例えば,Wine クラスを定義し,そのサブクラスとして White wine を定義した とする.そして Chardonnay を White wine のサブクラスとして定義する.サ ブクラスの関係の推移性とは,ここでは Chardonnay が Wine のサブクラスで もあるということである.時には,直接サブクラスと間接サブクラスを区別す ることもある.直接サブクラスとは,あるクラスに対して最も近いサブクラス である.つまり,そのクラスとサブクラスの間に他のクラスは存在しない.こ こでの例で言えば,Chardonnay は White wine の直接サブクラスであるが, Wine の直接サブクラスではない.

クラス階層の変化

一貫したクラス階層を維持することは,ドメインが発展するに従って難しくなっ ていくだろう.例えば,全てのジンファンデルワインは長い間赤ワインだった. なので,我々は Zinfandel クラスをRed wine クラスのサブクラスとして定義 した.しかし,ワインメーカーは葡萄を圧搾し,葡萄の色を左右する要素を取 り除いて,ワインの色を変えるようになった.このようにして,色としてはロ ゼの,ホワイトジンファンデルというワインも手に入るようになった.そこで 我々は,Zinfandel クラスを二つのクラス,White zinfandel と Red zinfandel に分け,それぞれ Rose wine クラス,Red wine クラスのサブクラ スとして再定義せねばならない.

クラスとその名前

あるクラスとその名前を区別することは重要である.

クラスはドメインにおける概念を表わすもので,これらの概念に名前として 付けられた単語を表わすものではない.

クラスの名前は,もし我々が異なった用語法を選んだ場合には,変更され得る ものである.しかし用語それ自体はこの世に現に存在する対象を示している. 例えば,Shrimps というクラスを作ったとする.そしてそのクラス名を Prawns に変えたとしても,そのクラスは依然として同じ概念を表現している. Shrimp の料理を参照していた,お薦めのワインの組み合せは,これからは Prawn の料理を参照すれば良い.より実践的に言えばこのようになる.

一つの概念についての複数の同意語は,異なるクラスを表わすもの ではない.

同意語とは,ある概念や用語につけられた複数の名前に過ぎない.であるから, Shrimp というクラスと一緒に Prawn や,ともすれば Crevette ( 訳注: 海老 のフランス語名 ) というクラスを作るべきではない.むしろ,Shrimp か Prown のいずれかの名前を持ったクラスを一つだけ作るべきである.多くのシ ステムでは同意語や翻訳語,表示名などのリストをクラスと関連づけることが できる.このような関連づけができないシステムでは,クラスのドキュメント に同意語のリストを含めてもよい.

クラスの循環を避ける

クラス階層において,循環 は避けねばならない.あるクラス A がサブク ラス B を持ち,同時に B が A のスーパークラスであるようなとき,この階層 構造には循環があると言う.階層構造の中にこのような循環を作ることは,A と B のそれぞれのクラスが等価であるということに等しい.つまりここでは, A の全てのインスタンスは B のインスタンスでもあり,また B のインスタン スも全て A のインスタンスである.もちろん,B は A のサブクラスであるか ら,B の全てのインスタンスは A のインスタンスでなければならないし,A は B のサブクラスであるから,A の全てのインスタンスは B のインスタンスでな ければならない.

4.2 クラス階層の中で兄弟を分析する

クラス階層の中での兄弟

クラス階層における兄弟とは,ある一つのクラスに対する複数の直接サブ クラスである ( セクション 4.1 ) .

階層の中の全ての兄弟 ( root に位置するものを除く ) は,一般性の観点で 同じレベルでなければならない.

例えば,White wine と Chardonnay は同じクラス ( つまり Wine ) のサブク ラスであってはならない.White wine は Chardonnay より一般的な概念だから である.例えば本の中で同じレベルのセクションが同じ一般性を持っているの と同様に,兄弟は同じラインの概念を表わすべきである.この点では,クラス 階層に求められることと本のアウトラインに求められることは似ていると言え る.

しかし階層構造の root に位置する概念( これはしばしば非常に一般的な,例 えば Thing のようなクラスの直接サブクラスであると表現される ) はそのド メインの主要な部分を表わしており,この概念に似た概念は存在しない.

どのくらいだと多過ぎてどのくらいだと少な過ぎるか

あるクラスが持つ直接サブクラスについて,いくつ持てばよいかというような 厳密なルールはない.しかし,良く構成されたオントロジーでは,あるクラス は大体 2 ~ 12 の直接サブクラスを持つ.したがって,以下のようなガイドラ インができる.

もしあるクラスが直接サブクラスを一つしか持たない場合,モデリング上の 問題があるか,オントロジーが完璧でない.もしあるクラスに 12 個以上のサ ブクラスがある場合,中間的なカテゴリを追加することを考えた方が良い.

一つ目のルールは,「項目が一つしかない箇条書きは作るな」という組版のルー ルに似ている.例えば,バーガンディの赤ワインのほとんどはコートドールワ インである.バーガンディワインのこの多数のみを表わすことを考えた場合, まず Red Burgundy クラスを作りそのサブクラスとして Cotes d'Or クラスを 作る ( 図6a ) .しかし,もしバーガンディの赤ワインとコートドールワイン が本質的に同じものであると表わせる場合 ( つまり,全てのバーガンディの赤 ワインはコートドールワインであり,全てのコートドールワインはバーガンディ の赤ワインである場合 ) ,Cotes d'Or クラスを作ることは必ずしも必要では なく,作ったところで何らかの新しい情報を持つことにはならない.コートドー ルのすぐ南の地方で生産される,より安価なコートシャロネーズワインを考え ると,Burgundy クラスの二つのサブクラスを作ることになる: Cotes d'Or ク ラスと Cotes Chalonnaise クラスである ( 図6b ) .

( 図6: Red Burgundy クラスとそのサブクラス.あるクラスにサブクラスが一 つしかないモデルには,大抵何らかの問題がある. )

さて,全ての種類のワインを Wine クラスの直接サブクラスとする場合を考え てみよう.この場合,サブクラスのリストには,ボジョレーやボルドーといっ たより一般的なタイプのワインと,ポイヤックやマルゴーといったより限定的 なタイプのワインが混在することになる ( 図7a ) .Wine クラスはあまりに多 くのサブクラスを持つこととなり,そしてもちろん,より構造化された形でワ インの種類を表わすオントロジーとしては,Medoc は Bordeaux のサブクラス であるべきであり,Cotes d'Or は Burgundy のサブクラスであるべきである. また,赤ワインや白ワインといった中間的なカテゴリを作ることで,多くの人 が一般的に持っているワインというドメインの概念モデルを表わすことができ る ( 図7b ) .

しかし,兄弟の関係にある多くの概念をグループ化するのに適したクラスが存 在しない場合は,敢えて新しいクラスを作り出す必要はなく,そのままにして おけばよい.つまるところ,オントロジーは実世界を反映するものに過ぎない ので,もし実世界において分類がされていないのであれば,オントロジーにお いても分類がされる必要はない.

( 図7: ワインの分類.分類によって階層化されていない例と,階層化された例. )

4.3 複数の継承関係

多くの知識表現システムでは,クラスの階層構造において複数の継承関係が許 可されている.つまり,ある一つのクラスは複数のクラスのサブクラスとなる ことができる.Dessert wine クラスを作ることを考えてみよう.ポートワイン は赤ワインであり,同時にデザートワインでもある (このオントロジーでは, 赤のポートワインのみを扱うことにする.白のポートワインも存在はするが, 全く一般的ではない) .よって Port wine クラスは,Red wine と Dessert wine の二つの親クラスを持つ.Port wine クラスの全てのインスタンスは,同 時に Red wine と Dessert wine の二つのクラスのインスタンスとなる.Port wine クラスはスロットとファセットを,両方の親クラスから継承する.つまり, Sugar スロットには Dessert wine クラスから SWEET という値を継承し, tannin level スロットと色の値を Red wine クラスから継承する.

4.4 いつ新しいクラスを作るべきか

モデリングの中で最も難しいのは,いつ新しいクラスを作るか,また異なる属 性値を区別するか決めることである.多くの独立したクラスを持つ複雑な階層 構造と,逆にスロットに多くの情報を含めた少数のクラスを持つ平坦な階層構 造とを,同時に満足させるような指針を示すことは困難である.適切なバラン スを見出すことは決して容易ではない.

階層構造の中でいつ新しいクラスを作るか決めるには,いくつかのルールがあ る.

あるクラスのサブクラスは大抵 (1) 親クラスが持っていない属性を持ってい る, (2) 親クラスとは異なる制約をもっている,もしくは (3) 親クラスとは 異なる関係に含まれている,のいずれかの条件に該当する.

赤ワインは種類によってタンニンの度合いが異なるが,一方でこの属性は,ワ インを一般的に表現するのには用いられない.Dessert wine クラスの sugar スロットの値は SWEET であるが,これは Dessert wine クラスの親クラスには 当てはまらない.ピノノワールワインはシーフードに合うが,他の赤ワインは そうではない.言い換えれば,そのクラスには当てはまるが,その親クラスに ついては当てはまらないことがある場合に,新しいクラスを作ればよい.

より実践的に言えば,全てのサブクラスは独自のスロットを持っているか,独 自のスロット値が定義されているか,親クラスから継承されたスロットのファ セットをオーバーライドしているべきである.

しかし,新しい属性を持たない場合でも,新しいクラスを作ることが有用な場 合がある.

用語の階層構造では新しい属性を作る必要はない.

例えば,あるオントロジーはそのドメインで用いられる用語のについて,巨大 な階層構造を持つとする.例えば,電子医療記録システムのオントロジーには, さまざまな疾病に関する定義が含まれるとする.これらの定義は,属性を持た ない ( もしくは共通の属性をもった ) 単なる用語の階層構造となる.このよ うな場合でも,用語を階層構造としてまとめることは有用である.なぜなら (1) 検索や探索が容易となり, (2) 医師が状況に応じて,用語の一般性の度合 いを選ぶことが容易となるからである.

新しい属性を定義することなくクラスを新たに作る別の理由は,我々がその特 質をモデル化しないと決めた場合でも,そのドメインの専門家によってモデル 化され得るような概念をモデル化するためである.我々がオントロジーを作る 理由は,ドメインの専門家の間や,ドメインの専門家と知識ベース化されたシ ステムの間のコミュニケーションを促進することであるので,そのドメインの 専門家の視点をオントロジーに反映することが望ましい.

最後に,全ての新しい制約について新しいサブクラスを作るべきではない.例 えば,これまでに Red wine,White wine,Rose wine というクラスを作ったが, これらがワインの世界において自然な区別だからである.なので,delicate wine や moderate wine といったクラスは作らなかった.クラスの階層構造を 定義する際に我々が行なうべきは,クラスをまとめるために有用なクラスを作 ることと,あまりに多くのクラスを作りすぎてしまうことの間のバランスを見 極めることである.

4.5 新しいクラスを作るか,それとも属性を作るか

ドメインをモデリングする際,そのドメインの範囲や扱う内容に応じて,ある 特質 (ワインの赤,白,ロゼのような) を属性値として定義するのか,はたま たクラスとして定義するのかという決定をせねばならないことがしばしばある.

White wine という一つのクラスを作るべきなのか,はたまた単に Wine という クラスを作って,その color というスロットに異なる値を入れるべきなのか. その答えは大抵,オントロジーを作り始める際に定義した,そのオントロジー が扱う範囲にある.白ワインという概念はこのドメインにおいてどれくらい重 要なものだろうか.もしワインがドメインの中でそれほど重要な位置付けでは なく,そのワインが白であるかどうかが,他のオブジェクトとの関係において 特に意味を持たないのであれば,わざわざ白ワインに独立したクラスを定義す るべきではない.ワインラベルを生産する工場で用いられるモデルであれば, ラベルはワインの色とは無関係なので,色の区別はそれほど重要ではない.一 方,ワインと料理,それらの適切な組み合わせを表わすモデルでは,赤ワイン と白ワインの違いは非常に重要である.色の違いによって,適した料理との組 み合わせや属性の種類などが大きく変わるからである.同様に,テイスティン グの注文に使われるワインの知識ベースでも,ワインの色が重要になる.その ため,これらのモデルでは白ワインを独立したクラスとして定義する.

ある概念のスロットの異なる値が,別のクラスのスロットの制約となる場合 がある.そうでなければ,その特質はスロットの値で表わす.

同様に,我々のワインのオントロジーには,一つの Merlot というクラスでは なく,Red Merlot や White Merlot といった異なるクラスがある.赤のメルロー ワインと白のメルローワインは ( 同じ葡萄から作られるが ) 全く別のワイン であり,我々が詳細なワインのオントロジーを作ろうとしているのであれば, この特徴は重要である.

もしある特質がドメインにおいて重要であり,異なる特質を持ったオブジェ クトが異なる種類のオブジェクトであると言えるのであれば,その特質に応じ て異なるクラスを新たに作るべきである.

あるクラスの潜在的且つ具体的なインスタンスを考えることも,新しいクラス を作るべきか否かの判断に役立つ.

特定のインスタンスが属するクラスは頻繁に変更されてはならない.

概念の本質的でない属性をクラス間の区別として用いると,それらのクラスに 属するインスタンスが,別のクラスに移動せねばならない状況がしばしば起こ る.例えば,レストランにあるワインボトルについてのオントロジーでは,冷 えているワインは Chilled wine といったクラスとして定義されるべきではな い.Chilled wine クラスに属するインスタンスは,その状態によって簡単に Chilled wine クラスのインスタンスであったりなかったりするので,冷えてい るという特徴は単にワインボトルの属性であるべきである.

大抵の場合,数や色,場所はスロットの値であり,新しいクラスを作る要因と はならない.しかし,ワインに関して言えば,色はワインの特徴として非常に 重要であるため例外である.

別の例として,人体解剖学のオントロジーを考えよう.肋骨を表わすとき,左 側の一番目の肋骨,左側の二番目の肋骨といったクラスを作るだろうか.それ とも単に Rib というクラスを作り,その属性として順番と位置 ( 右か左か ) を持たせるだろうか ( ここでは,John の右第一肋骨のような使い方をするこ とを考えて,解剖学的な器官は全てクラスとしている.ある特定の人の器官は, このオントロジーにおいては一つのインスタンスとなる).もしこのオントロジー で表わされる肋骨がそれぞれ全く別のものであるなら,もちろん肋骨の一本一 本についてクラスを作るべきである.つまり,もしそれぞれの骨にどういった 機能があるのか,どの器官を保護しているのかという情報と共に,順番や位置 に関する情報( これらは一本一本異なる )を持たせたいというのであれば,肋 骨一本一本のクラスを作ればよい.もう解剖学のもう少し概念的なモデルを作 ろうとしていて,想定される使われ方では肋骨が一まとまりとして見なされる ような場合( 単に肋骨のどの骨が折れたのかを診断するだけで,別の器官への 影響を推測するのに使われたりしない場合 ) ,単に Rib というクラスを作り, そこに位置と順番という二つのスロットを持たせればよい.

4.6 クラスのインスタンス?

ある概念がオントロジーにおいてクラスであるのか,それとも特定のインスタ ンスであるのかという判断は,そのオントロジーの用途に左右される.どこま でがクラスでどこからがインスタンスか判断するには,まずどこまで表現する かという粒度の最低ラインを決めねばならない.表現の粒度は,今度は想定さ れるオントロジーの用途によって決めねばならない.言い換えれば,知識ベー スで表現される中で最も具体的なものは何だろうか.セクション 3 の Step 1 に立ち戻ってみると,これらの質問への答えとなる最も具体的な概念が,この 知識ベースにおけるインスタンスの非常に良い候補となるだろう.

個々のインスタンスが,知識ベースにおける最も具体的な概念である.

例えば,ワインと料理の組み合わせのみを考えるのであれば,物理的なワイン ボトルに興味はない.よって,スターリング・ヴィンヤード・メルローといっ たような単語が,最も具体的な用語になるだろう.故に,スターリング・ヴィ ンヤード・メルローが知識ベースにおけるインスタンスの一つであると言える.

また,ワインと料理の組み合わせ以外にも,レストランのワインの在庫管理も したいとすると,個々のワインボトルが知識ベースにおけるインスタンスとな るだろう.

同様に,スターリング・ヴィンヤード・メルローの生産年毎の属性を記録した いとすると,ワインの生産年が知識ベースにおけるインスタンスとなり, Sterling Vineyards Merlot が,全ての生産年のインスタンスを含んだクラス ということになる.

別のルールがインスタンスをクラスに「引き込む」こともある.

概念が自然に階層構造を成す場合,それらはクラスとすべきである.

ワインの生産地について考えてみよう.まず,フランス,アメリカ,ドイツと いった主要なワインの生産地をクラスとして定義し,より詳細な生産地をこれ らのインスタンスとして定義する.例えば,ブルゴーニュ地方は French region クラスのインスタンスとなる.しかし,コートドール地方もブルゴーニュ 地方である.なので,Bourgogne region は ( サブクラスやインスタンスを持 つために ) クラスでなければならない.しかし,ブルゴーニュ地方をクラスに し,コートドール地方をブルゴーニュ地方のインスタンスとするのは,些か気 まぐれにも見える.どの地方がクラスで,どの地方がインスタンスであるかを 明確に決めるのは非常に難しい.なので,ここでは全ての地方をクラスにして しまう.Protege-2000 では,直接のインスタンスを持たない抽象クラスを作る ことができる.この場合,全ての地方クラスは抽象クラスである ( 図8 ) .

( 図8: ワインの生産地の階層構造.クラス名の横の A というアイコンは,そ のクラスが抽象クラスであり,直接インスタンスを持ち得ないことを示してい る. )

クラス名から region という語を取り除くと,同様のクラスの階層構造は正し くないものになる.Alsace クラスが France クラスのサブクラスであるとは言 えない.アルザスはフランスの一種とは言えないからである.しかし,アルザ ス地方はフランス地方の一種であると言うことができる.

サブインスタンスの概念を持たない階層構造の知識表現システムでは,クラス のみが配置できる.それ故,セクション 4.2 で示した用語の階層構造のように もし用語の間に自然な階層構造があるのであれば,それ自身インスタンスを持 たない場合であっても,これらの用語をクラスとして定義すべきである.

4.7 スコープの制限

クラスの階層構造の定義の最後に,オントロジーの定義が完了したかを判断す る方法として,常に以下のルールが有用である.

オントロジーにはドメインに関する全ての情報を含めるべきではない.想定 される利用法が求める以上 ( 多くても一階層まで ) に特殊化したり一般化し たりする必要はない.

我々のワインと料理の例では,ワインのラベルにどのような紙が使われている かや,エビの料理法を知る必要はない.

同様に,階層構造に含まれるクラスに考えられる全ての属性を持たせるべきで はない.

我々のオントロジーでは,確かにワインや料理が持ちうる全ての属性を含めて はいない.それぞれ主要な属性のみを持たせるに留めている.ワインに関する 本には,例えば原料となる葡萄の大きさが書いてあるかもしれないが,こういっ た知識はオントロジーには含めていない.同様に,我々のシステムの中の全て の用語から想像できるような,全ての関係性を追加しているわけではない.例 えば,我々が定義した用語同士の関係をより完璧に表現するためだけに,好き なワインや好きな料理といった関係をオントロジーに含めてはいない.

最後のルールは,既にオントロジーに含めた概念の間の関係を構築するのにも 使われる.生物学の実験についてのオントロジーを考えてみよう.このオント ロジーには生物の概念が含まれるだろう.また,実験を行なう実験者という概 念も ( 氏名や所属などと共に ) 含まれる.実験者は人であるが,それと同時 に生物でもある.しかし,この区別をオントロジーに含めるべきではないだろ う.そうしようとすると,実験者は生物ではなくなり,実験者に対して実験を 行なうことができなくなってしまう.もし,あるクラスについて言えること全 てをオントロジーに反映すると,Experimenter クラスは Biological Organism クラスのサブクラスとなる.しかし,オントロジーの想定される利用 法を考えると,この情報をオントロジーに反映する必要はない.事実,こういっ た情報を現存するクラスに追加するのは害を伴う.Experimenter クラスは weight や age,species といった,生物に付随するスロットを持つことになる が,実験について描写する場合,これらの情報は完全に見当違いである.しか し,我々はオントロジーを作る際,こうしたデザインの過程における決定をド キュメントに起こしておかねばならない.このオントロジーをみて,我々の想 定した利用法とは異なる利用法を考えたユーザの利益のためである.

4.8 独立したサブクラス

多くのシステムでは,クラスの独立を指定することができる.複数のクラスが 共通のインスタンスを持ち得ない場合,それらのクラスは独立している.例え ば,Dessert wine クラスと White wine クラスは独立していない.両方のクラ スに属する多くのワインが存在するためである.Sweet Riesling クラスのイン スタンスである Rothermel Trochenbierenauslese Riesling はその例である. 同時に,Red wine クラスと White wine クラスは互いに独立している.赤ワイ ンであると同時に白ワインであるワインは存在しない.クラスの独立を指定す ることで,システムはオントロジーをより正確に検証することができる.Red wine クラスと White wine クラスが独立であると指定しておけば,後に Riesling クラス ( White wine クラスのサブクラス ) と Port クラス ( Red wine クラスのサブクラス ) の両方を親クラスに持つクラスを定義しようとす ると,システムはモデリング上のエラーを検出することができる.

5 属性を定義する

このセクションでは,オントロジーの中でスロットを定義する際に覚えておく べき詳細 ( セクション 3 の Step 5,6 ) について述べる.主に,逆スロット とスロットのデフォルト値に関してである.

5.1 逆スロット

あるスロットの値は,他のスロットの値に依存する場合がある.例えば,ある ワインがあるワイナリーで生産されると,同時にそのワイナリーはそのワイン を生産したことになる.この生産者と生産のような二者間の関係を,逆スロッ トと呼ぶ.これらの双方向の情報を保持するのは冗長である.あるワインがあ るワイナリーで生産されたいう情報があれば,知識ベースを利用する際に,そ のワイナリーでそのワインが生産されたという情報を類推することができる. しかし,知識収集の観点では,双方の情報を利用できることもまた便利である. このアプローチでは,ワインの情報とワイナリーの情報をそれぞれ別に入力す ることができる.知識収集システムは,知識ベースの一貫性を保証しつつ,逆 関係にある値を自動的に入力することができる.

我々の例には,一組の逆スロットがある.Wine クラスの maker スロットと, Winery クラスの produces スロットである.Wine クラスのインスタンスが作 られ,maker スロットに値が入力されると,システムは対応する Winery クラ スのインスタンスの produces スロットに,先程作られた Wine クラスのイン スタンスを入力する.つまり,スターリング・メルローがスターリング・ヴィ ンヤード・ワイナリーで生産されたと入力すると,システムは自動的に,スター リング・ヴィンヤード・ワイナリーで生産されたワインのリストにスターリン グ・メルローを加える ( 図9 ) .

( 図9: 逆スロットを持ったインスタンス.Winery クラスの produces スロッ トは,Wine クラスの maker スロットの逆スロットである.一方のスロットに 値を入力すると,もう一方のスロットにも自動的に値が入力される. )

5.2 デフォルト値

フレームベースのシステムの多くでは,スロットにデフォルト値を設定するこ とができる.あるクラスのある特定のスロットの値が,ほとんどのインスタン スで等しい場合,その値をスロットのデフォルト値として設定することができ る.このスロットを持つクラスのインスタンスが作られる度に,システムは自 動的にスロットにデフォルト値を入力する.ファセットの制約を満たす限り, デフォルト値を別の値に設定することもできる.つまり,デフォルト値は利便 性のためにある.モデルに新たな制約を要求することはないし,決してモデル を変更もしない.

例えば,対象とするワインの多くがこくのあるものだとすると,ワインの味と して full というデフォルト値を設定しておくことができる.そうすることで, 特に指定しない限り,全てのワインはこくがあるものとして定義できる.

これがスロットの値とは異なることに注意が必要である.スロットの値は変更 することができない.例えば,Dessert wine クラスの sugar スロットには SWEET という値を設定できる.すると,Dessert wine クラスの全てのインスタ ンスは,sugar スロットに SWEET という値を持つことになる.この値は,クラ スに属するどのサブクラスやインスタンスでも変更することはできない.

6 命名規則

オントロジーにおける概念の命名規則と,その規則に厳格に従うことは,その オントロジーについて理解する助けになるだけでなく,モデリングにおける一 般的な間違いを防ぐことにも繋がる.命名規則には多くの手法がある.どういっ た手法を用いるかという選択は,しばしば明確な理由なしに行なわれる.しか し,必要なのは以下の原則である.

クラスやスロットの命名規則を決め,必ずそれに従うこと.

知識表現システムの以下の特徴によって,命名規則の選択が左右される.

例えば,Protege-2000 では,全てのフレームで一つの名前空間を共有している. また,名前の大文字小文字の違いは区別される.そのため,winery というクラ スとスロットを同時に定義することはできない.しかし,Winery というクラス と winery というスロットを定義することはできる.一方,CLASSIC では大文 字小文字の違いは区別されず,クラス,スロット及びインスタンスで異なる名 前空間を用いることができる.そのため,システムの観点から見れば,Winery という名前をクラスとスロットに同時に問題なく用いることができる.

6.1 大文字小文字と区切り文字

まず,概念の命名の際に大文字小文字の使い分けを行なうことで,オントロジー の可読性を大きく向上させることができる.例えば,クラス名には大文字を用 い,スロット名には小文字を用いるのが一般的である ( システムが大文字小文 字の区別をする必要がある ) .

概念が,例えば Meal cource のように複数の単語からなる場合,単語の間を区 切る必要がある.これにはいくつかの選択肢がある.

知識表現システムが名前に空白文字を含めることができるならば,開発者にとっ て空白文字を用いる方法が最も直感的だろう.しかし,あなたのシステムがや り取りを行なう可能性のあるシステムについて考えることも重要である.それ らのシステムが空白文字を用いることができない場合や,プレゼンテーション メディアが空白文字を上手く扱えない場合は,他の手法を用いる必要がある.

6.2 単数形と複数形

クラス名はオブジェクトの集合を表わす.例えば,Wine というクラスは実際に は wines を表わしている.それ故,デザイナーによっては Wine ではなく Wines という名前を用いる方が,より自然だと感じるだろう.どちらがより良 い,より悪いということはない ( 事実上クラス名には,単数形が用いられるこ とが多い ) .しかし,どちらを選んだとしても,オントロジー全体を通して同 じ規則を用いるべきである.システムによっては,前もって単数形と複数形の いずれを用いるかを尋ね,選択していない形式を許さないものもある.

常に同じ規則を用いることは,例えば Wines というクラスに Wine というサブ クラスを作ってしまうといった,モデリング上の間違いを防ぐことにも繋がる ( セクション 4.1 ) .

6.3 プレフィックスとサフィックス

いくつかの知識ベースの方法論では,クラスとスロットの区別をつけるために, 名前にプレフィックスもしくはサフィックスをつけることを提案している.一 般的な方法は,スロット名に has- や -of をつけることである.我々が定義し たスロットに has- というプレフィックスをつけると,スロットの名前は has-maker や has-winery となる.同様に -of というサフィックスをつけると, maker-of や winery-of となる.このアプローチにより,名前を見るだけでそ れがクラスなのかスロットなのかが判断できるようになる.しかし,名前が若 干長くなるという弊害もある.

6.4 その他の命名規則

これまで紹介した以外にも,命名規則を考える上で考慮に入れるべきことがあ る.

例えば,ある概念がクラスなのかスロットなのかというコンテクストを形成す ることは,常に明快である.加えて,( 例えば大文字小文字の区別のように ) クラスとスロットに異なる命名規則を用いることで,名前それ自身が,その概 念が何なのかを表わすようになる.

その他のリソース

今回の例では,オントロジーの作成環境として Protege-2000 を用いた. Duineveld と彼の同僚が,多くのオントロジー作成環境についての調査及び比 較を行っている ( Duineveld et al. 2000 ) .

この文書では,オントロジー作成の基礎的な部分にのみ説明し,それ以外の踏 み込んだトピックや,数ある方法論の詳細については触れていない. Gomez-Perez ( Gomez-Perez 1998 ) と Uschold ( Uschold and Gruninger 1996 ) は,別のオントロジー作成の方法論を紹介している.Ontolingua tutorial ( Farquhar 1997 ) では,知識モデリングの公式な解釈について論じ られている.

現在,研究者の間ではオントロジーの作成だけでなく,オントロジーの分析に ついても注目されている.より多くのオントロジーが作成され,再利用されて いく中で,オントロジーの分析を行なうより多くのツールも開発されていくだ ろう.例えば,Chimaera ( McGuinness et al. 2000) では,オントロジーの分 析を行なうツールが提供される.Chimaera は,オントロジーの論理的妥当性の 検証や,オントロジーのデザイン上の一般的なエラーの探索を行なうことがで きる.オントロジーの作成者は,作成中のオントロジーに対して Chimaera を 用いて分析を行なうことで,一般的な作成手法に合致しているかを確認するこ とができる.

まとめ

この文書では,宣言型のフレームベースシステムで,オントロジーの作成を行 なう方法論を提示した.また,オントロジー作成の際に踏むべき手順や,クラ スの階層構造,クラスの属性及びインスタンスの階層構造を定義する際の,複 雑な問題についても触れた.しかし,この文書で解説したことに従うことは重 要だが,覚えておくべき最も重要なことは,あるドメインに対して唯一絶対に 正しいオントロジーは存在しない,ということである.オントロジーの作成と は実にクリエイティブな作業であり,たとえ同一のドメインについてであって も,作成者が異なれば異なるオントロジーができて当然である.オントロジー の利用法,作成者の理解,また対象のドメインに対する視点が異なれば,もち ろんオントロジー作成の手法も異なってくる.確かなことは,オントロジーの 出来不出来は,作成する際に想定されていた利用法で用いられて初めて吟味さ れ得るということである.

謝辞

(snip)

参考文献

(snip)