May 20, 2007

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 Guha 1999）を開発している。これは、情報を検索するエージェント等のプログラムに可読であるよう、Webページ上の知識を記述するための言語である。 W3Cと共同で研究を進めている高等研究計画局（DARPA）では、Web上でのエージェント同士の対話を促すことを目的として、RDFをより多様な表現が可能になるよう拡張したDARPA Agent Markup（DAML）を開発している（Hendlerand McGuinness 2000）。現在多くの分野で、専門家がその分野の情報を共有し注釈を付けるのに利用できる標準オントロジーが作られている。例えば薬学の分野ではsnomed（Price and Spackman 2000）やUnified Medical Language System（Humphreys, Lindberg 1993）の意味ネットワークのように、標準化・構造化された巨大な語彙が作られている。同様に、より広範で一般的なオントロジーも作られている。例えばUnited Nations DevelopmentProgramとDun & Bradstreetは、製品やサービスを分類するのに利用可能なUNSPSCオントロジーを共同で開発した（http://www.unspsc.org/）。

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

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

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

一つ目の要求は、オントロジーを開発する上で比較的一般的な目的である（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. 単純な知識エンジニアリングの手法

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

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

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

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

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で作ったリストから、オブジェクトを説明するのではなく、独立した具体的なオブジェクトを定義する用語を選び出す。これらの用語はオントロジーにおいてクラスになるだろうし、クラスの階層構造においてアンカーとなるだろう

（また、クラスを、引数を一つ取る質問を構成する述語と見ることができる（例えば "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のメーカーは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クラスのインスタンスを値として取る（システムによっては、特別にInstance型を指定するのではなく、単にClass型を指定するものもある）。

図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. 命名規則

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

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

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

クラスやスロット、インスタンスの名前空間は同一か。つまり、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）