A Guide to Creating Your First Ontology 私的日本語訳

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といったようなスロットを持たせることができる *1 ．

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 ) ．

• まずドメインにおける一般的な概念を定義し，次にその概念を特化するというトップダウンのアプローチ．例えば，我々はまずワインと料理に関する一般的な概念であるところのクラスを作り，次にWine クラスのサブクラス( 例えばWhite wine，Red wine，Rose wine ) を作ることでWine クラスを特化する．さらにRed wineクラスを，例えば Syrah，Red Burgundy}，Cabernet Sauvignon などのサブクラスに分類することもできる．
• まず最も特化されたクラスや階層の一部分を定義し，次にこれらのクラスをより一般的な概念でグルーピングするというボトムアップのアプローチ．例えば，まず始めに Pauillac Wine と Margaux Wine というクラスを定義する．そしてこれら二つのクラスのスーパークラスとして Medoc Wine クラスを定義する．ちなみに，この Medoc Wine クラスは Bordeaux Wine クラスのサブクラスである．
• トップダウンとボトムアップを組み合わせたアプローチ．つまり，まず顕著な概念を定義し，次にそれらを適切に汎化したり特化したりする．例えばまずWine というトップレベルの概念と，Margaux Wine のようないくつかの特定の概念から始める．次にこれらの概念をミドルレベルの概念，例えば Medoc Wine クラスを作ることで関連づけることができる．そしてフランスワインのように地方によって分類したいと思えば，さらにミドルレベルの概念を追加することで可能となる．

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

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

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

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

どのアプローチを選んだとしても， 我々はたいていクラスを定義することから始める． Step 3 で作ったリストから，オブジェクトを説明するのではなく， 独立した具体的なオブジェクトを定義する用語を選び出す． これらの用語はオントロジーにおいてクラスになるだろうし， クラスの階層構造においてアンカーとなるだろう *2 ． そして，あるクラスのインスタンスであるオブジェクトが 別のクラスのインスタンスであるか否かという問いを通して， クラスを階層構造の中で分類していく．

もしクラス 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 のメーカーはWine とワイナリーの関係を示し，葡萄はWine の原料を示す ) ．

このように，我々が既に用意しているプロパティに加え， 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 に設定することも時には有効である． こうすると， 特定のサブクラスでそのスロットが値を持ち得ないということを示すことができる

型制約

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

• String 型はNameスロットのようなスロットに使うことができる，最も単純な値である．値は単なる文字列である．
• Number 型 ( もしくはより詳しい Float 型や Integer 型 ) は数字を値として持つ．例えば，Wine のPriceは Float 型の値を持つ．
• Boolean 型は単純な true-false のフラグである．例えば，スパークリングワインを単独のクラスとして表現しないのであれば，そのワインが発泡であるか否かは Boolean 型を取るスロットを作ることで区別できる．もしその値が true であればそのワインは発泡であるし，false であればそのワインは発泡でない．
• 列挙型はスロット値となり得る値のリストを示す．例えば，Flavorスロットは強い，普通，弱いのいずれかの値を取ると定義することができる．Protege-2000 では列挙型は Symbol 型である．
• Instance 型を取るスロットは個体間の関係を定義するのに用いられる．Instance 型を取るスロットは，そのインスタンスの親クラスも指定しなければならない．例えば，WineryクラスのProducesスロットは，Wine クラスのインスタンスを値として取る *3 ．

図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 クラスを作ることを考えてみよう． ポートワインは赤ワインであり， 同時にデザートワインでもある *4 ． よって 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 というクラスを作り， その属性として順番と位置 ( 右か左か ) を持たせるだろうか *5 ． もしこのオントロジーで表わされる肋骨がそれぞれ全く別のものであるなら， もちろん肋骨の一本一本についてクラスを作るべきである． つまり， もしそれぞれの骨にどういった機能があるのか， どの器官を保護しているのかという情報と共に， 順番や位置に関する情報 ( これらは一本一本異なる ) を持たせたいというのであれば， 肋骨一本一本のクラスを作ればよい． もう解剖学のもう少し概念的なモデルを作ろうとしていて， 想定される使われ方では肋骨が一まとまりとして見なされるような場合 ( 単に肋骨のどの骨が折れたのかを診断するだけで， 別の器官への影響を推測するのに使われたりしない場合 ) ， 単に 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 命名規則

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

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

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

• クラスやスロット，インスタンスの名前空間は同一か．つまり，winery というクラスとスロットのように，同一の名前のクラスやスロットを作ることができるか
• 大文字小文字の区別があるか．つまり，Winery と winery のように，大文字小文字の違いを異なる名前として扱うか．
• 名前の中にどの区切り文字を含めることができるか．つまり，空白文字やコンマ，アスタリスクなどを名前に含めることができるか．

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

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

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

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

• 空白文字を用いる ( Meal course ) ．Protege-2000 を含む多くのシステムでは，概念の名前に空白文字を用いることができる．
• 単語を繋げ，それぞれの頭文字を大文字にする ( MealCource ) ．
• アンダースコア，もしくはハイフンを用いる ( Meal_Course, Meal_course, Meal-Course, Meal-course ) ．区切り文字を用いる場合，それぞれの単語の頭文字を大文字にするか否かを決める必要がある．

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

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 その他の命名規則

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

• 概念の名前に class や property，slot といった単語を入れてはならない．

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

• 例えば Cab ではなく Cabernet Sauvignon を使うように，概念の名前に略語を使わないのは大抵の場合良いアイディアである．

• 直接サブクラスの名前には，全てに親クラスの名前を含めるか，一切含めないかのいずれかであるべきである．例えば，Wine クラスのサブクラスとして赤ワインと白ワインの二つのクラスを作るとき，それぞれ Red wine と White wine，もしくは Red と White であるべきであり，Red wine と White は適切でない．

その他のリソース

今回の例では， オントロジーの作成環境として 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)

Name: Comment: