海外出張報告 - 東京国際大学

MFI Ontology registration Ed2
Evolution management について
東京電力・システム企画部
岡部雅夫
2007.5.28
Evolution management の目的
オントロジーは、進化するもの。
MFI Part3として進化そのものを管理したい・・・中国の趣旨？
どんな変更が要求され、その結果、オントロジー全体、あるいは、他のオ
ントロジーまで含め、どのように変化か？
オントロジーは、相互に参照(リユース）されるので、MFI Part3と
してマルチ・バージョンのサポート機能が必要・・・岡部の趣旨
たとえば、オントロジーAがオントロジーB（version1)を使用していたとし
て、オントロジーBがversion1からversion2に進化し、オントロジーB
version2がMFI Part3に登録されたとしても、オントロジーAはまだオント
ロジーB version1を使用していることはままある。
2005-07-13/14
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
2
マルチ・バージョン対応が必要となる例
最初のMFI Part3
オントロジーA
オントロジーB
version1
use
=>
オントロジーB
version1
オントロジーB
ersion2
に進化し、MFI Part3に登録（更新）され、また、
オントロジーB version2を使うオントロジーCもMFI Part3に登録されたが、
オントロジーAは、まだ、オントロジーB version1を使っているとする。
進化後のMFI Part3
オントロジーC
use
オントロジーB
Version2
evolve
オントロジーA
2005-07-13/14
use
MFI Part3として２versionの
オントロジーBを管理する必要
があるが、その機能が現状の
ED1にはない。
オントロジーB
version1
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
3
論点１：URI
オントロジーは、URIで識別されることになっているが、例えば、
オントロジーBのversion1とversion２には、同一のURIが割り当
てられていると考えるか、否か。
本来には、同一のオントロジーBであるから、同一のURIが割り
当てられて然るべき。
ただし、現実には、URIにversion管理機能がない(?)ので、例え
ば、W3Cのspec等でも、各versionに対して、日付を含んだ別々
のURLが割り当てられている。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
4
補足
URIを区別した場合の問題点
オントロジーBのversion1とversion2が別々のURIで識別されると、そこで
使用されるatomic construct(name, symbol)も、ほとんど共通であるにも
関わらず、URI別に別々に管理されることになり、煩雑になる。
URIを同一とした場合の問題点
もしURIを区別しないと、 MFI Part3は、記述言語のsyntaxを前提にした
semanticsを持っていないため、オントロジーが進化しても、MFI Part3の
登録情報としては、Administered Itemのeffective date 等以外は、２つ
のversionで全く同一になる場合がある。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
5
MFI Part3の登録（構成）情報に変化がない例 (1/2)
オントロジーBが以下のRC1, RC2, RC3からなっていて、
RC2が以下のように変更されたとする。
RC1
<owl:ObjectProperty rdf:ID="dimensionality">
<rdfs:domain rdf:resource="#Unit" />
<rdfs:range rdf:resource="#Dimensionality" />
</owl:ObjectProperty>
RC2
RC2
<owl:Class rdf:ID="KernelUnit">
<rdfs:subClassOf rdf:resource="#Unit"/>
</owl:Class>
<owl:Class rdf:ID="KernelUnit">
<owl:disjointWith rdf:resource="#Unit/>
</owl:Class>
RC3
i.e. KernelUnitは、Unitのサブクラスから、Unitと
排他に変更。（意味的には大きな違い）
<KernelUnit rdf:ID="metre">
<dimensionality>
<Dimensionality rdf:ID="length"/>
</dimensionality>
</KernelUnit>
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
6
MFI Part3の登録（構成）情報に変化がない例 (2/2)
MFI Part3上では、 rdfs:subClassOf と owl:disjointWith の差
を認識しないので、どちらも、以下の通りで同一。
オントロジーB
Ontology Whole
RC1
Ontology
Component
RC2
RC3
Ontology
Atomic
Construct
dimensionality
Unit
Dimensionality
KernelUnit
metre
length
逆に言うと、MFI Part3に、構成情報が同一でも、別versionとして管理で
きる機能が必要。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
7
先の例をすこし具体的に
Ontology Whole
Ontology
Component
オントロジーB
version1
RC1
version1
オントロジーB
Version2
RC2
version1
RC2
version2
RC3
version1
Ontology
Atomic
Construct
dimensionality
2007-05-28
Unit
Dimensionality
東京電力・システム企画部・岡部雅夫
KernelUnit
metre
目的外使用・複製禁止
length
8
Version管理の対象
Versionとして把握すべき変化
同一と認識される範囲での変化(evolution)
オントロジーそのものの内容の変化
Local => Referenceの変化
注：ＲｅｇｉｓｔｒａｔｉｏｎＡｕｔｈｏｒｉｔｈｙ等のAdministered Information のみの変更は、対象外。
Version管理の対象
Ontology Whole
Ontology Component
 ただし、先のRC2の例は、subclassがdisjointになるというのは、まったく別の
内容であるので、RC2の新versionではなく、別のComponentと考えるべき。
Ontology Atomic Construct
 名前がすべてなので、上のLocal=>Referenceを除いてはなし。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
9
論点２：MOF2.0 versioning
以下のような機能があり、それなりに使えそうな気はする。
Version管理のためのメタデータ
VersionのHistory（Branch, Merge)
粒度の小さいものに対するversionと、それらからconfigureされる粒度の
大きいものとしてのbaselineのversion.
ただし、そのためには、MOF2.0を待たなくてはならない。大した
ものでもないので、MFI Part3として独自に決めてもよいかもし
れない。
ちなみに、正式には、MOF™ 2.0 Versioning and
Development Lifecycleで、現状のstatusは、finalization
vote underway。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
10
中国の提案について
中国の提案は、オントロジーの整合のとれたevolutionの管理の
ための仕様（クラスをdeletesしたら、そのinstanceもdeleteしな
かればならない等）であり、オーバースペックのような気はする
が、まあ、あってもよいかという感じ。
ただし、OWLをかなり意識している部分があるので、一般化す
る必要がある。
例えば、class, instance, propertyといった（メタ）概念（構造）を意識して
いるが、Common Logicには必ずしもこのようなものはない。
提案されているメタクラス（Consistency Closure, Evolution
Strategy等）が、具体的にどんな情報を持つのかがよくわからな
い。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
11
Evolution以外で、ED2に取り込むべき内容
Reference, Localの２レベルの半順序関係への拡張
MFI Part3 Portalの運営上の考え
 まずは、安直にReference Ontologyを定めず、Local Ontologyをどんどん成長させ、
その中から、Reference Ontologyを生み出す。
そういう意味では、Local Ontology は、他から参照（再利用）できないとい
う条件は厳しすぎる。
そこで、Referenceを最上位とする半順序関係を導入し、
Ontology Whole (Component) AがOntology Component (Atomic
Construct) Bを利用できる。

Ontology Whole (Component) Aのレベル
≧ Ontology Component (Atomic Construct) Bのレベル
とする。
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
12
以上
2007-05-28
東京電力・システム企画部・岡部雅夫
目的外使用・複製禁止
13

Download Report