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を使用していることはままある。 elementary beat around the bush 2005-07-13/14 東京電力・システム企画部・岡部雅夫

マルチ・バージョン対応が必要となる例 オントロジーA オントロジーB version1 use 最初のMFI Part3 オントロジーB => に進化し、MFI Part3に登録（更新）され、また、 オントロジーB version2を使うオントロジーCもMFI Part3に登録されたが、 オントロジーAは、まだ、オントロジーB version1を使っているとする。 進化後のMFI Part3 オントロジーA オントロジーB version1 Version2 use evolve オントロジーC MFI　Part3として２versionのオントロジーBを管理する必要があるが、その機能が現状のED1にはない。 elementary beat around the bush 2005-07-13/14 東京電力・システム企画部・岡部雅夫

論点１：URI オントロジーは、URIで識別されることになっているが、例えば、オントロジーBのversion1とversion２には、同一のURIが割り当てられていると考えるか、否か。 本来には、同一のオントロジーBであるから、同一のURIが割り当てられて然るべき。 ただし、現実には、URIにversion管理機能がない(?)ので、例えば、W3Cのspec等でも、各versionに対して、日付を含んだ別々のURLが割り当てられている。 2007-05-28 東京電力・システム企画部・岡部雅夫

補足 URIを区別した場合の問題点 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 東京電力・システム企画部・岡部雅夫

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 <owl:Class rdf:ID="KernelUnit"> <rdfs:subClassOf rdf:resource="#Unit"/> </owl:Class> RC3 <KernelUnit rdf:ID="metre"> <dimensionality> <Dimensionality rdf:ID="length"/> </dimensionality> </KernelUnit> RC2 <owl:Class rdf:ID="KernelUnit"> <owl:disjointWith rdf:resource="#Unit/> </owl:Class> i.e. KernelUnitは、Unitのサブクラスから、Unitと排他に変更。（意味的には大きな違い） 2007-05-28 東京電力・システム企画部・岡部雅夫

MFI Part3の登録（構成）情報に変化がない例 (2/2) MFI Part3上では、 rdfs:subClassOf と owl:disjointWith の差を認識しないので、どちらも、以下の通りで同一。 逆に言うと、MFI Part3に、構成情報が同一でも、別versionとして管理できる機能が必要。 Ontology Whole オントロジーB Ontology Component RC1 RC2 RC3 Ontology Atomic Construct dimensionality Unit Dimensionality KernelUnit metre length 2007-05-28 東京電力・システム企画部・岡部雅夫

先の例をすこし具体的に オントロジーB version1 オントロジーB Version2 Ontology Whole RC1 Component RC2 version1 RC2 version2 RC3 version1 Ontology Atomic Construct dimensionality Unit Dimensionality KernelUnit metre length 2007-05-28 東京電力・システム企画部・岡部雅夫

Version管理の対象 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 東京電力・システム企画部・岡部雅夫

論点２：MOF2.0 versioning 以下のような機能があり、それなりに使えそうな気はする。 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 東京電力・システム企画部・岡部雅夫

中国の提案について 中国の提案は、オントロジーの整合のとれたevolutionの管理のための仕様（クラスをdeletesしたら、そのinstanceもdeleteしなかればならない等）であり、オーバースペックのような気はするが、まあ、あってもよいかという感じ。 ただし、OWLをかなり意識している部分があるので、一般化する必要がある。 例えば、class, instance, propertyといった（メタ）概念（構造）を意識しているが、Common Logicには必ずしもこのようなものはない。 提案されているメタクラス（Consistency Closure, Evolution Strategy等）が、具体的にどんな情報を持つのかがよくわからない。 2007-05-28 東京電力・システム企画部・岡部雅夫

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 東京電力・システム企画部・岡部雅夫

以上 2007-05-28 東京電力・システム企画部・岡部雅夫