MFI Ontology registration Ed2 Evolution management について

Presentation on theme: "MFI Ontology registration Ed2 Evolution management について"— Presentation transcript:

1 MFI Ontology registration Ed2 Evolution management について
東京電力・システム企画部 岡部　雅夫

2 Evolution management の目的
オントロジーは、進化するもの。 MFI　Part3として進化そのものを管理したい・・・中国の趣旨？ どんな変更が要求され、その結果、オントロジー全体、あるいは、他のオントロジーまで含め、どのように変化か？ オントロジーは、相互に参照(リユース）されるので、MFI Part3としてマルチ・バージョンのサポート機能が必要・・・岡部の趣旨 たとえば、オントロジーAがオントロジーB（version1)を使用していたとして、オントロジーBがversion1からversion2に進化し、オントロジーB　version2がMFI　Part3に登録されたとしても、オントロジーAはまだオントロジーB version1を使用していることはままある。 elementary beat around the bush /14 東京電力・システム企画部・岡部雅夫

3 マルチ・バージョン対応が必要となる例 オントロジー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 /14 東京電力・システム企画部・岡部雅夫

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

5 補足 URIを区別した場合の問題点 URIを同一とした場合の問題点
オントロジーBのversion1とversion2が別々のURIで識別されると、そこで使用されるatomic construct(name, symbol)も、ほとんど共通であるにも関わらず、URI別に別々に管理されることになり、煩雑になる。 URIを同一とした場合の問題点 もしURIを区別しないと、 MFI Part3は、記述言語のsyntaxを前提にしたsemanticsを持っていないため、オントロジーが進化しても、MFI Part3の登録情報としては、Administered　Itemのeffective date 等以外は、２つのversionで全く同一になる場合がある。 東京電力・システム企画部・岡部雅夫

6 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と排他に変更。（意味的には大きな違い） 東京電力・システム企画部・岡部雅夫

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

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

9 Version管理の対象 Versionとして把握すべき変化 Version管理の対象 同一と認識される範囲での変化(evolution)
オントロジーそのものの内容の変化 Local => Referenceの変化 注：Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｈｙ等のAdministered Information のみの変更は、対象外。 Version管理の対象 Ontology Whole Ontology Component ただし、先のRC2の例は、subclassがdisjointになるというのは、まったく別の内容であるので、RC2の新versionではなく、別のComponentと考えるべき。 Ontology Atomic Construct 名前がすべてなので、上のLocal=>Referenceを除いてはなし。 東京電力・システム企画部・岡部雅夫

10 論点２：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。 東京電力・システム企画部・岡部雅夫

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

12 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のレベル とする。 東京電力・システム企画部・岡部雅夫

13 以上 東京電力・システム企画部・岡部雅夫