Issues to be discussed on MFI-Part10 Core model and basic mapping and transformation

1. Issues to be discussed on MFI-Part10Core model and basic mapping and transformation OKABE, Masao Editor MFI Part 10 2010.5.16 2010.5.20 r 2010.8.27 r2 2010.11.16 r4 OKABE, Masao

2. entries of process model D entries of process model C entries of ontology B entries of process model D entries of process model E entries of ontology A process model D ontology B ontology A process model C Role & Goal F Role & Goal E Basic Structure of MFI • MFI presupposes the existence of complete repositories of models outside MFI. • All the parts (except Part1 and 6) inherit Part10. • Part10 is not necessarily abstract (meta)classes. <MFI> Part10 Core model (and basic mapping) Part3 Ontology registration registry Part8 Role &Goal registry Part5 Process model registry ・・・ ・・・ ・・・ ・・・ Only common semantics (essential subsets) are registered in MFI registry with some additional information. <Outside MFI> ・・・ ・・・ ・・・ Common Logic ontology repository i* role & goal repository OWL　 ontology 　 repository　 RM-ODP process model repository PSL process model repository KAOS role & goal repository OKABE, Masao

3. Administered Item Context Model Component Our tentative consensus at WG2 London meeting in November, 2009 　　　(1 of 2) • The scope of new Part2 (now Part10) covers the ones of old Part2 (Core) and old Part4(Mapping) • About old Part2 • Make it simpler so that other parts of MFI (excluding Part1 (Reference model) and Part6 (Registration procedure)) can inherit all (?) the metaclasses of new Part2. • Tentative agreement on high-level metamodel. • About old Part4 • Proposal from Baba-san. • Any mappings can be classified into 6 categories. • M1->M1, M2->M2, M1->M2->M2->M1, etc. • We need more discussions. 1:1 1:* OKABE, Masao 3

4. Our tentative consensus at WG2 London meeting in November, 2009 　　　(2 of 2) • If some part of MFI defines its own metacalass that inherit Administered Item, it shall inherit Administered Item through Context, Model, or Component, and shall not directly. • Some part of MFI may define its own metacalass that does not inherit Administered Item. ○ Non Administered Item Administered Item Model Component Context × ○ Specialized Item Specialized Model OKABE, Masao

5. Issues that need to be discussed • Issues on Core model • Issues on Basic mapping OKABE, Masao

6. Issues on Core model OKABE, Masao

7. Current Candidate of High-level Metamodel • From Keith based on MDR Part3 Ed3 Identified Item Designatable and Classifiabled not Registered Item Unregistered Model Component Unregistered Model Unregistered Ontology Atomic Construct Unregistered Ontology Whole OKABE, Masao

8. Issues on Core model 　　　(1 of 4) • About the current candidate metamodel • Context---Use Context of MDR • Even today, it is still controversial what is a context? • The definition of context in MDR Part3 may change substaitially in Ed3. • Practically, it is difficult to identify a context. • If there are two context, it is difficult to determine whether these two are identical or not. • We have to get a good consensus on what a context is and to clearly define the mataclass “Context”. Otherwise, it may become a trash with many uncontrolled natural language descriptions. • Currently, none of Part3, 5, 7, 8 use the metaclass “Context”. • Do we really need the metaclass “Context” in the Core? OKABE, Masao

9. Issues on Core model 　　　(2 of 4) • About the current candidate metamodel • Superclass of Atomic_Construct • There is no superclass of Registered_Ontology_Atomic_Construct of Part3, which inherits Administered Item. • Since all the Administered Items shall inherit some metaclass of Prat10, Part10 needs to have a metaclass that Registered_ Ontology_Atomic_Construct of Part3 inherit. OKABE, Masao

10. Issues on Core model 　　　(3 of 4) • About the current candidate metamodel • In MDR Part3, “Registered Item” is an abstract class and has mece direct subclasses “Attached Item” and “Adminitered Item” which is a composition of “Attached Item”. • This structure of MDR Part3 Ed3 is too strict to MFI, because MFI Part 3 has a metaclasses “Unregistered_Ontology_Whole” and “Unregistered_Ontology_Atomic_Construct”, which are registered in MFI and are not Administered Items but are also not attached to any Administered_Item. • If “Registered Item” is an abstract class (i.e. “Attached Item” and “Adminitered Item” are not collectively exhasutive), it is fine to MFI. OKABE, Masao

11. Issues on Core model 　　（4 of 4) • Whether some facilities (metaclasses) of Part3 which is applicable to other parts should be moved to nwePart10 or not? • Distinction of Unregistered_xxx(Item), Reference_xxx(Item) and Local_Item. --- will not be introduced to Part10 • autoritativeLevel of Local_Item --- will not be introduced to Part10. • Item_Evolution --- Something will be introduced to Part2, but not exactly the same as Item_Evolution in Part3 Ed2. • No---Keith (Process model, I-model do not need the information of evolution) • Yes- Denise (if it is not covered by mapping) • Evolution is just a kind of mapping---Kevin • Language --- will be added to Partt2. • Ontology_Language of Part3 and Process_Model_Language of Part5 are almost the same. • Each part has a specialized Language inherited from Language of Part2. OKABE, Masao

12. Issues on Basic mapping OKABE, Masao

13. Issue Raised by UK at Wuhan Project Meeting entries of mapping from A to B entries of mapping from A to B entries of ontology A entries of ontology B ontology B ontology A Policy 2 on Mapping To register a complete mapping from abstracted A to abstracted B in MFI Policy 1 on Mapping To register common semantics of a complete mapping from A to B Basic Policy of MFI A generic registry independent of languages that describe modeles Part3 Ontology registration registry Exmaple： Part10 Basic mapping registry Part10 Basic mapping registry ・・・ ・・・ ・・・ Common semantics abstracted <Outside MFI> OWL ontology repository Common Logic ontology repository ・・・ Complete repository depending on a language OKABE, Masao

14. What is interoperability? • SE VOCAB • the ability of two or more systems or components to exchange information and to use the information that has been exchanged (ISO/IEC 24765:2009 Systems and software engineering vocabulary) • the ability for two or more ORBs to cooperate to deliver requests to the proper object (ISO/IEC 19500-2:2003 Information technology -- Open Distributed Processing -- Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP), 3.2.19) • the capability to communicate, execute programs, and transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units. (ISO/IEC 2382-1:1993 Information technology--Vocabulary--Part 1: Fundamental terms, 01.01.47) Note • Basically, interoperability is about information (or object or data) OKABE, Masao

15. What is interoperability? • Wikipdia • a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation. • Note • generic and not limited to information • http://en.wikipedia.org/wiki/Interoperability • IEEE Glossary • the ability of two or more systems or components to exchange information and to use the information that has been exchanged. • Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.(iftikahr) • Note • focuses only on information • Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.(iftikahr) OKABE, Masao

16. Interoperability • In summary, interoperability is; • a property of a system (or component, ORB, functional unit, product) • to exchange information (or object, data) • or communicate each other • or execute a program • or whose interfaces are completely understood • so that they can work properly. OKABE, Masao

17. Interoperability in MFI • In MFI, interoperability is; • a property of who(?) • to exchange what(?). • That is, does MFI intend to embody whose interoperability about what can be understood by them? • Who = a user of a repository that is a target of a MFI registry, which can be a human or a computer system • What = a content (complete model) in a repository that is a target of a MFI registry OKABE, Masao

18. entries of process model D entries of ontology B entries of process model E entries of process model D entries of process model C entries of ontology A process model D ontology B ontology A process model C Role & Goal F Role & Goal E Basic Structure of MFI What to be exchanged in MFI interoperability are not but are . <MFI> Part10 Core model (and basic mapping) are; Part3 Ontology registration registry Part8 Role &Goal registry Part5 Process model registry ・・・ ・・・ ・・・ Only common semantics (essential subsets) are registered in MFI registry with some additional information. <Outside MFI> ・・・ ・・・ ・・・ Common Logic ontology repository i* role & goal repository OWL　 ontology 　 repository　 RM-ODP process model repository PSL process model repository KAOS role & goal repository OKABE, Masao

19. What to be exchanged in MFI interoperability • A full model in a complete repository outside a MFI registry • Not an entry in a MFI registry because it has only common semantics (an essential subset) and is not enough to be understood for its proper use. • An entry in a MFI registry is just an entry to a full model and helps to find a full model to provide its common semantics (essential subset), independent of its language (syntax). • A full model, including an ontology, an information model, a role & goal model, a process model, a service model, as a kind of information • Not a process nor a service itself • A process model and a service model to be exchanged help to find and reuse a proper process or service. OKABE, Masao

20. What MFI does • One of the basic policies of MFI is that it only has common semantics of targets, independent of the languages that describe them. • Hence, MFI registry does not have enough information to define a mapping from actual A to actual B. • Moreover, since complete targets are out of the scope of MFI and MFI only registers their common semantics, complete mappings between targets is also out of the scope of MFI and MFI only registers the common semantics of complete targets? • If so, we need complete mapping repositories depending on C(n,2) language combinations. n=number of language OKABE, Masao

21. Issue Raised by UK at Wuhan Project Meeting entries of mapping from A to B entries of mapping from A to B entries of ontology A entries of ontology B ontology B ontology A Policy 2 on Mapping To register a complete mapping from abstracted A to abstracted B in MFI Policy 1 on Mapping To register common semantics of a complete mapping from A to B Basic Policy of MFI A generic registry independent of languages that describe models Part3 Ontology registration registry Example： Part10 Basic mapping registry Part10 Basic mapping registry ・・・ ・・・ ・・・ Common semantics abstracted <Outside MFI> OWL ontology repository Common Logic ontology repository ・・・ Complete repository depending on a language OKABE, Masao

22. process model D process model C PSL process model repository MFI Part 10 Basic mapping as a essential subset of mappimgs Administered Item MFI Part10 Core model (formerly 2) Context Model Component MFI Part3,5, 8, etc Process Process Model MFI Part10 Basic mapping (formerly 4) Mapping Model Mapping Component full mapping from process model C to process model D Mapping repository specific from RM-ODP to PSL RM-ODP process model repository OKABE, Masao

23. Mapping (or Transformation ) for Interoperability • Currently, none of MFI Part3, Part5, Part7, Part8 has a metaclass related to mapping or transformation and that inherit MFI Part10 Basic Maping, except that MFI Part3 has a intentional relation “sameAS”. • What kind of mapping or transformation is necessaey for interoperability? OKABE, Masao

24. Simple Example for Discussion • Suppose that there are two conceptual domains. • One is gender code whose conceptual value domain is the abstracted one from {female, male, other}. • The other is sex classification whose conceptual domain is the abstracted one from {female, male, neutral, other}. • In gender code, {female, male, other} are not mutually exclusive, and bisexual is claasified to female and male at the same time. • In sex classification, {female, male, neutral, other} are mutually exclusive, and bisexual is classified to other. • In this case, what kind of mapping or transformation is required for interoperability. Note: This is not an example specific to MFI but a general example. OKABE, Masao

25. Sex classification • female • male • neutral • other • Gender code • female • male • other Simple Example • There are only three exaxt mapping; • From Sex classification:female to Gender code:female • From Sex classification:male to Gender code:male • From Sex classification:netutaral to Gender code:other • Then, what is next? Mapping or transformation although they are not the same? OKABE, Masao

26. Simple Example • From MFI Part3’s point of view, • Two Ontology Components • Definition of Gender Code • Definition of Sex Classification • Seven Ontology Atomic Constructs • Gender Code:female • Gender Code:male • Gender Code:other • Sex Classification :female • Sex Classification :male • Sex Classification :neutral • Sex Classification :other OKABE, Masao

27. Simpler example: Grade Code (?) • There are only two mapping with cardinality 1; • From Grade Code2:excellent to Evaluation classification 1:good • From Evaluation classification 2:very poor to Evaluation classification 1:poor • Then, what is next? • Mapping from A to B does not mean that A and B are not exactly the same. • Clear Objectives of Part10 is necessary. • See 20943 Part5 for strategy of mapping Mapping or transformation although they are not the same? • Grade Code 1 • good • (67-100) • fair • (36-67) • poor • (-35) • Grade Code 2 • Excellent • (75-100) • Good • (51-74) • Poor • (26-50) • very poor • (-25) OKABE, Masao

28. Simpler Example • From MFI Part3’s point of view, • Two Ontology Components • Definition of Grade Code 1 • Definition of Grade Code 1 • Seven Ontology Atomic Constructs • Grade Code 1: good • Grade Code 1: fair • Grade Code 1: poor • Grade Code 2: excellent • Grade Code 2: good • Grade Code 2: poor • Grade Code 2: very poor OKABE, Masao

29. Context and Mapping・・・・Part10 does not have Context • Context makes mappings sophisticated, which is better or worse. • rather than (a Context, a Model) (a Context, a Model) (a Context, a Model Component) (a Context, a Model Component) (a Context, an Atomic Construct) (a Context, an Atomic Construct) a Model a Model a Model Component a Model Component an Atomic Construct an Atomic Construct OKABE, Masao

30. MOF owl: individual ・・・ owl: Class type type instance instance ・・・ Person Tree Bruce Denise Note: OWL metamodel in ODM Note: Level-pair (or multi meta level) is not all mighty. M3 MOF (or UML for UML) M2 M1 M0 Association Class ・・・ type instance Person Tree ・・・ type instance Bruce Denise ・・・ OKABE, Masao

31. MOF (or UML for UML) Class Instance ・・・ Class type type type instance instance T (Top Class) ≡ Person Instance Person ・・・ type type should be instance instance Denise Bruce ・・・ Denise Bruce ・・・ instance Metalevel focusing on M1 and M0 Metalevel focusing on M2 Note: Level-pair (or multi meta level) is not all mighty. M3 MOF (or UML for UML) M2 M1 M0 OKABE, Masao