1.オントロジバージョン管理ワーキンググループの目的
　
　一昨年から程度表現オントロジの設計と公開を次世代Web委員会で、またSPIAフォーラムでは情報家電オントロジの公開を開始した。
　このオントロジの公開に伴い「オントロジの開発」から「オントロジの共有」「オントロジの管理」が委員会において現実な課題となってきた。
　そこで本年度より「オントロジの共有」としてはオントロジリポジトリの構築(オントロジリポジトリワーキンググループ)と、「オントロジの管理」をテーマとしては本ワーキンググループが委員会内に設置されることとなった。
　最初に本テーマに関して委員会内で議論を行ったが「オントロジバージョニング」に関して、現在公開している各オントロジの開発・公開の前提などから各メンバーの注目する問題点や課題は多岐にわたることがわかった。（表１）
　そこで初年度として「オントロジバージョニング」の対象について整理することを目標として活動を行った。

表１　オントロジバージョニングに関しての問題（抜粋）
バージョニングでの課題	委員会で出された疑問点
オントロジバージョン管理の開始時点	1.オントロジバージョン管理は、どの時点から開始すべきであるか。公開した時点において、継続的なオントロジ変更が想定されている場合にバージョン管理を開始することは有効であるのか
オントロジバージョン管理の対象	1.URIで公開されているものに限定して管理をしていいのかどうか 2.URIで公開しているファイルとURIで利用している語彙（語彙）との関係はどうなるのか 3.namespaseが変更された場合にも変更対象とするのか 4.管理対象の階層性が存在するが、それぞれの具体的な管理項目は何か i)ファイルレベル　ii)構造レベル iii)意味レベル
オントロジバージョン変更のパターン	1.基本的なオントロジは変更せず追加するだけのパターンクラス追加型、インスタンス追加型などなど 2.大元のオントロジが変更される場合は想定していいのか
オントロジの運用とバージョン管理	1.新しいオントロジが古いオントロジに置き換わるときのバージョン管理対象　前述の構造レベル、意味レベルの部分的な修正より大幅な修正があった場合の提供側、利用者での対象方法は 2.import時のおける整合性については、どこまで対応するのか 3.import先のオントロジの整合性については、管理責任を持つのか、またはもてるものか
オントロジバージョン管理の支援tool（開発環境）	1.バージョニングのためのツール機能は　古いバージョンのオントロジが前提で、日付が入っていないオントロジを叩くと最新のバージョンが得られるなどのCVSレベルの差分抽出機能で済むのか 2.半自動的なオントロジのバージョン管理技法の研究などは行われているのか 3.マニュアルで行う管理技法として実践的に利用可能な文献資料があるか
オントロジの特徴とバージョン管理	次世代Web委員会で公開しているそれぞれのオントロジは、その特徴が異なるためバージョン管理の目的も方法論をかなり異なるのではないか。 1.情報家電オントロジ　現実の世界をマッピングしているようなオントロジであり、オントロジ公開後において変更すること自体ができないタイプのものがあるのではないか 2.程度表現オントロジ　利用者による複数のオントロジがあるのが前提であり、またバージョン自体の複数あることが前提である。.smoogleで公開されている各オントロジのように、変更は利用側の自由であり開発公開時点で、バージョン管理に対する責任は発生しない
複数のオントロジのバージョン管理方法	全項目「オントロジの特徴とバージョン管理」のおける2.程度表現オントロジーのタイプを複数利用している場合の管理方法は
程度表現オントロジとバージョン管理	程度表現オントロジがVer0.7 ,Ver0.8と変わっていった場合は、これまでの課題も踏まえて利用者側に公開する情報は具体的には何が必要となるか

２. オントロジバージョニングとは

2.1 研究対象としての観点

　参考資料[1]ではオントロジバージョンニング自体を研究テーマのひとつとして定義している。
　ここではオントロジのバージョンが複数ある場合の適切なバージョンの選択問題として捉えている。
　例えば図１のように、パソコンの基本的な構造・属性がオントロジーとして類似している場合において、対象となるオントロジーを選択するということになる。
　smoogleなどオントロジポータルを利用する場合、または今回の情報家電やワーキンググループのリポジトリのオントロジーを利用する場合になどで、特定ドメインのオントロジーが複数提供されている場合には必要となる技術と言える。
　しかし、本委員会でのテーマとしては、オントロジを公開提供する側としてのより広義の意味としてのオントロジ管理することにまずは焦点をあてることとした。

2.2 オントロジバージョンニングの技術的な位置づけ

　ここで「広義」とした場合に、再度オントロジバージョニング管理の対象が問題となる。
　例えば参考資料[3]などでは、以下のように４つの観点でバージョニング技術を分類するとともに、現状（４）レベルは困難な課題とされている。

（１）純粋に構造的なバージョニングを対象とする
　これはソフトウェアのメンテナンスと同様の技術となり、比較的に簡単に実装できる。しかし管理対象となるのは構造レベルであり、意味的な管理はできない。
(2)トランザクションベースのでバージョニング
　データベースの管理技術を適用する。すなわちトランザクションにおいて既存データを損失することなしにスキーマの変更を管理することなる。
(3)マージベースのバージョニング
　(2)に対してより汎用的なアプローチに基づいた既存の（または半自動生成した場合の）オントロジをマージする技術となる。
(4)構造的は変更とともに意味的な拡張にも対応したバージョニング
　構造的な差分とともに、RDF.RDF/S,OWL,F-logicの各意味表現における意味的な変更、整合性をオントロジの各バージョンにおいて帰納的に対処する技術

　ここで(1)(2)は、オントロジに特有な課題でないため（ただし、実運用上は必要となる）(3)について参考資料[2]参考資料[5]を元に整理を行った。（各技術対象は「備考　オントロジ技術対象」参照）
　非常に大雑把なとらえ方としては、オントロジ工学(Ontology Engineerring)としてのオントロジ進化(Evolution)/変化(Change)という方法論的なアプローチがあり、中分類としては、こうした方法論を実現するためにオントロジのマージ(Merge)や統合(Integration)の課題、そしてマージや統合の要素技術として連携技術(Alignment)、変換技術(translation)と整理される。
　対象となるオントロジ自体が変更することだけを考えると全てにおいてバージョン管理の問題が発生することになるが、今回委員会で対象としているのは、より上位レベルにおける、つまり方法論レベルでの問題と、またマージや統合処理以前の「公開オントロジの変更」における対応（Mediation）となる。

3.オントロジバージョニング
　方法論としてはオントロジバージョンニングの「フレームワーク」、メディエーションとしてはOWLにおける変更点の影響について以降では記述する。

3.1　フレームワーク
　
　オントロジの進化/変化（ライフサイクル）ではオントロジ開放提供時における課題としては、オントロジ定義/変更記述/変更の明確化が、そして利用者との関係においては、タスクの認識/変更履歴のサポート、そして具体的なオントロジの変更支援として推論の整合性や同期とデータ変換のサポートが必要となる。　参考資料[4]

表2 オントロジバージョニング　フレームワーク
オントロジ定義(Identification)	オントロジを構成する要素についてはあらかじめ明確にその意図を定義する。これによって何を変更するのかということが明確に記述できることになる。
変更記述 (Change specification)	オントロジ定義に従って可能性がある変更は記述されなければいけない。なぜなら異なるオントロジーの表現が異なっていれば、提供するコンポーネントも異なり、変更の記述も異なることになるからである。
変更の明確化（Transparent evolution)	ある特定の変更によって何を行うべきかを明確にしておかなければいけない。このため、変更記述は、オントロジー構成要素の異なるバージョンの違いや関係の判定に利用されることになる。
タスクの認識（task awareness)	互換性には多くの要因(例えば、インスタンスデータの保存、質問結果の保存、結果の保存など)があるので、フレームワークは、適切な変換をバージョンの間に提供するために具体的なタスクを意識していなければならない。
変更履歴へのサポート(support for untraced change)	1つのバージョンから新しいバージョンまでの変更のステップを表す変化履歴がないケースがしばしばある。そのような場合、verバージョン管理のフレームワークでは2つのバージョンが互換性があるかどうか決定するためにメカニズムを提供するべきである。
推論の整合性(Consistent reasoning)	オントロジを使った推論に影響がないことを保証するのを目的とする。これを実現する方法としては、少なくとも特定のセットの質問の答えが異なったバージョンでも同一結果を返すことで保証できる。
同期とデータ変換サポート(synchronisation and data translation support)	分散環境では必要である。これまでの機能は、ローカルにオントロジをリモートにアップデートするものであるが、本機能は影響があるデータソースを新しいバージョンのオントロジと整合性があるように自動的変換する。

3．2　オントロジの変更操作とインスタンスデータへの影響
　OWLベースでの影響を考えると、階層性、クラス、プロパティ、その他として以下の各変更が仕様上では発生する。
　
(1)階層性
　(i)クラスまたはプロパティの追加
　(ii)クラスまたはプロパティの削除
　(iii)クラスまたはプロパティのマージ
　(iv)ひとつのクラスを分割する

表3 OWLでの変更の影響　+:影響がない　-:影響あり　~:他の要因で決定される
操作	影響	説明
新しいクラスCの作成	+	データは失われない
クラスを削除する	-	クラスC自体が特別でなければ上位クラスのインスタンスとなるだけすむ場合もある
スロットSの作成	+	データは失われない
スロットSの削除	-	すべてのインスタンスに対するスロット値は失われる
クラスCにスロットSを加える	+	データは失われない
クラスCからスロットSを削除する	-	クラスCのインスタンスのスロットSの値は失われる
スーパークラスCとサブクラスC間にあたらな上位下位関係を加える	+	サブクラスは上位クラスから新しいスロットを継承する。多くの場合は、新しいスロットを加えることと同じ操作となる
スーパークラスCとサブクラスC間にあたらな上位下位関係を削除する	-	サブクラスは上位クラスからの継承ができなくなる。サブクラスCのインスタンスにおけるスロット値は失われる。
インスタンスIを新しいクラスにまとめあげる	+	データは失われない
クラスCをインスタンスとして整理する	-	クラスCのインスタンスの型定義が失われる
C1とC2を排他として宣言する	-	C1とC2双方に属していたインタンスの妥当性が失われる
スロットSを遷移または対称と定義する	-	遷移対称でないスロットSのスロット値との不整合が発生する
サブクラスCから上位クラスCへスロットを移動させる	+	サブクラスCは依然スロットSを継承する
上位クラスからサブクラスCへスロットを移動させる	-	上位クラスからはスロットCがなくなり、上位クラスCのインスタンスのスロットCの値は失われる
クラスC1から参照クラスC2へスロットSを移動する	～	スロット値が移動しなければデータは失われない
新しいクラスにスロットの集合を隠蔽する	～	スロットの値が移動しなればデータは失われない
クラスCの上位クラスをより上位の階層へ変更する	-	Cはこれまでの直接に継承していたクラスからのスロットを保持することはできない。クラスCのこれらのインスタンスにあるスロットは失われる
クラスCの上位クラスをより上位の階層へ変更する	+	Cには新しいクラスが継承されることになるはずである。データは失われない
スロットSの制約を緩める	+	スロット値はすべて整合性を保ったままである。
スロットSの制約を強める	-	スロット値はすべて整合性を保ったままである。
クラスをマージする	～	スロットの値に移動がなければデータは失われない
クラスを分割する	～	スロット値を移動しなければデータは失われない

4.次年度の活動予定

　今年度の調査結果をオントロジのライフサイクルとして整理すると図３となる。
　各フェーズにおいて
(i)方法論としての提供者側からの各規定
(ii)利用者側との同意に基づく情報提供
(iii)(i)(ii)　各支援環境
　が要求されることなる。
　しかし、これら全てが現実的に必要かどうか、また対応すべき範囲/対応可能な範囲については今年度は未着手であった。
　そこで、次年度以降は次世代Web委員会で提供を開始した情報家電オントロジ・程度表現オントロジー・リポジトリ管理を実践的な事例として検討を行うとともに、またProtegePROMPT などのオントロジバージョン管理toolの適用可能性の検討を行う予定である。

[備考]オントロジ技術概要

用語	定義
Matching （マッチング）	異なったオントロジのエンティティー間の関係や対応を検出するプロセス。
Alignment （アライメント）	ふたつまたはそれ以上の(細胞の配列アライメントのように)のオントロジの対応の集合。アライメントはマッチングプロセスの出力結果である。
Correspondence (対応)	ある特定のマッチングアルゴリズムまたは異なるオントロジのエンティティ間のインスタンスにおいて保持している（していると判定できる）関係。これらエンティティは、クラス、インスタンス、プロパティまたは式によって異なる。他ではマッピングの意味で使われることがあるが、本書ではこの意味で利用する。
Mapping (マッピング)	アライメントの基本であり、実際の処理。マッピングは一つのオントロジを少なくともひとつのオントロジにマップする。一般的な関係に対して数学的な定義や写像の概念を含む。数学的な定義では原則としてマッピング対象はその像と等価であることが要求される。すなわち、関係と等価関係を指す。マッピングは、同一方向へのマッピングルールの集合として捉えることができる。すなわちひとつのオントロジーから他のオントロジに、元のオントロジのエンティテイが他のオントロジーの一回以上写像されることになる。
Mapping Rule (マッピングルール)	1つのオントロジのエンティテイを他のオントロジのエンティテイへ対応させること
Ontology merging（オントロジのマージ）	二つのオントロジからひとつのオントロジを作成することであり、大体はもとのオントロジへ上書きすることになる。初期のオントロジは変更がない。マージされたオントロジは初期のオントロジの知識を含むべきである。例えば、マージしたオントロジを使った結果は、それぞれのオントロジを使った結果になる。この概念はデータベースのスキーマ統合と非常に近い
Ontology integration （オントロジ統合）	他のオントロジへあるオントロジを包含することである。これらオントロジは宣言的に表現されて、普通はブリッジとなる公理により繋がれる。統合されたオントロジーには双方の知識が含まれていなければならない。オントロジのマージと違い、初期のオントロジは２番目のオントロジへの変更があっても変化することはない。
Bridge axioms （ブリッジの公理）	ブリッジとなる公理、または明示的な公理は、あるオントロジ言語における公式であり、これらはあるオントロジを他のオントロジのエンティテイに統合化することができるよう表現されたアライメントである。同じ言語表現で記述されたオントロジのマージにおいてブリッジ公理が基盤となる。
Ontology translation (オントロジ解釈）	あるオントロジを別のオントロジ言語へ変換するプロセスのこと。オントロジを解釈するためのプログラムへも用いられる。
ontology transformation （オントロジー変換）	あるオントロジのエンティティを他のオントロジのエンティティの観点で表現するプロセスである。すなわち最初のオントロジに対して二番目のオントロジが追加された場合の関係となる。よって最初のオントロジによって導かれる結論は変換結果と同じである。二つの初期のオントロジは変更されないそして、オントロジ変換結果から生成されたオントロジが作成される。オントロジを変換するためのプログラムとしても用いられる。
Data translation （データ解釈)	あるオントロジから対応するデータやインスタンスを変換するプロセス。またはそのために用いられるプログラム。
Mediation （メディエイション）	情報ストリームを動的に変更すること、そのためのインターフェースをソフトウェア要素として持つ。メディエイトするためのプログラムも指す。WEBサービスではあるオントロジを使ったサービス結果を別のオントロジの入力へと変換を行う。そのためのデータ変換も行う。ＱＡシステムでは、質問と回答での２重での変換を行う。
Ontology version （オントロジのバージョン）	オントロジのバージョンは、オントロジを変更するアプリケーションの結果である。
Ontology reconciliation (オントロジ調整)	ふたつまたはそれ以上のオントロジを調和させること。通常は、ひとつまた双方のオントロジの変更が要求される。この場合、オントロジのマージではなく、ともに進化する。オントロジ調整は二つのオントロジをマージするためまたはそれぞれ独立してつくるために実行されるであろう。