Framework for Metamodel Interoperability (MMF) ISO/IEC19763-1,2,3,4

1. Framework for Metamodel Interoperability（MMF）ISO/IEC19763-1,2,3,4 （Draft CD/WD ）for discussion ISO/IEC/JTC1/SC32/WG2 meeting Washington DC 2004.11.09 Masaharu Obayashi

2. Changes at 2nd (draft) CD • CD reviewed and revised based on 1st CD comments and resolutions, also discussion with experts • Change inheritance from MDR and MOF • Administered Item from MDR • Avoid direct inheritance from MOF • Change package structure • Divide normative and informative • Harmonize metamodel with Ontology (part 3) and Mapping (part 4) • Specification reviewed and redefined for affect of above changes

3. Scope • This part of ISO/IEC 19763 applies to activities including: • A business object is an object that is identified in building a reusable model of business or a reusable software component that should support interoperability within an enterprise or in the trade between enterprises. • To identify and define a concrete object, firstly concepts in the modeling target domain must be put in order, and secondly the meaning of business objects that are picked up from those concepts should be defined exactly with the relationships among the business objects.

4. Scope (objectives) • inter-enterprise connection • Using standardized business objects, inter-enterprise connection among customers, trading partners and business partners would be available. In addition, if a compliant model that is created based on common business objects were adopted, the interoperability among the subsystems of each section of an enterprise would be maintained in the ease way. • standardization for core models • As a standard model among enterprises or in an industry, if business objects and core models were defined independent of any particular platform, the development of components and tools conforming standard functions or interoperability would be enabled. Then, the solution business by vendors would be promoted. • stability and reusability of a standard model • In some cases, the lifecycle of a business application may be longer than one of hardware or platform. If a business application were built based on a business object model that was independent of any particular platform, remaking the same application on a new hardware or a particular platform would be easy and flexible by generating the code of its application from the model. Much of the maintenance cost of the lifecycle could be reduced.

5. Messages • Developing sharable model is best promoted through accumulation of Metamodels and Ontologies • Metadata about target could be also registered as a Metamodel including metaclasses and attributes • Registry must be defined with separated from target • MMF works to manage Granularity, Scale, and Context • Using ‘Components’ to express Context • Define Concepts with Components from different scales and methodologies • ‘Signs’ must be separated from Concepts • ‘Concepts governs Instances’ (e.g. “is-kind-of” = “governs” ) • “Employee is a kind of person” means“The model of all employees governs the model of persons” • Bridging scales and context with Ontologies and Mappings • Linking Ontologies to integrate or to map Metamodel and model

6. Framework of Registering (1) • Sign-Concept-Referents • Sign • a symbol designating a named element in a namespace. • Namespace is a collection of signs • Concept • specify meaning of sign. • generally expressed with sign. • Referents • a set of instance of the Concept designated by a sign. • Selection • a result of selecting a set of model instance from referents designated by a sign.

8. Framework of Registering (2) • Model Concept-Model Domain-Model Instance • Model Concept (Sign) • designate a named element in a namespace. • Namespace is a collection of signs defined by a submitted organization • Signs should be unique within the particular Namespace • Model Domain (Concept) • specify meaning of the sign. • Model Classifier of Model Domain is generally expressed with the sign. • A sign is corresponding to a Model classifier • The meaning of Model Domain is provided by Model Profile • Model Instances (Referents) • a set of instance of the Concept designated by the sign. • governed by Model Domain • should satisfy the constraints concerning the Model Domain. • Model Selection • Model Selection is a result of selecting a set of model instances from Model Instances designated by a sign.

9. Model Specification Namespace Model Profile (Upper Model) within specified by Model Components has defines sign concept Model Concept Model Domain Model Classifier Named Element Model Selection Model Instance governs referent Basic Scheme of Target Objects Model Components (Lower Model)

10. Target Objects World • Structure of Registered Target Objects • Multi-forest • There are many SDOs and organizations that will register a Model profile • There will be many kinds of Model profile developed by SDOs • A set of Model profiles may be registered as a family • Multi-layer • A Model classifier in a Model profile governs a Model instances • A Model componentin Model instances may be also registered as another Model classifier in the same Model profile or the other one. • Multi-component • A Model classifier may consist of elements including external objects that are selected from in another registered Model instances

11. Target Objects (Simple) Model Profile (Upper Model) Employee Model Domain Person Address Model Classifier governing Addresses at A-district Office Persons at J-Company Manager Model Instance Staff Home Addresses at B-district Persons at K-company Model Components (Lower Model)

12. Target Objects (Composed) Model Profile (Upper Model) Employee Model Classifier Model Domain Person Address governing Employees at J-Company Office Manager Model Instance Staff Home Employees at K-company Model Components (Lower Model)

13. Registered Target Objects (Simple) Model Profile (Upper Model) Model Classifier Model Concept Model Domain governing Model Instance Model Components (Lower Model)

14. Registered Target Objects (Composed) Model Profile (Upper Model) Model Classifier Model Concept Model Domain governing Model Instance Model Components (Lower Model)

15. Using Registered Target Objects Home Staff Model Selection Jones Washington Home Staff DB (Hospital B) DB (Hospital A)

16. Model Specification Model Profile (Upper Model) Model Components Namespace has defines Model Classifier Named Element Model Classifier Named Element Model Classifier Named Element Model Classifier Named Element Model Classifier Named Element Model Concept Model Domain governs Model Selection Model Instance Model Components (Lower Model) Target Objects for a Model Profile Model Components (Lower Model) Model Components (Lower Model) Model Components (Lower Model) Model Components (Lower Model)

17. connected with Model Selection Composed Target Objects connected with Model Selection

18. Register again Lower model as Upper model with name Layered Target Objects name model model name

19. Overview of Target Objects World (1) • Structure of Registered Target Objects • Multi-forest • Multi-layer • Multi-component

20. Overview of Target Objects World (2) NameSpace Model Component Model Domain(concept) Model Concept (sign) ModelInsatances(referents) Model Selection NamedElement

21. Overview of Target Objects World (3) Skeleton (overview) Skeleton (detail)

22. What is “Governing”? • Metamodel and Model • Metamodel (upper) • Define the abstract syntax for expressing the lower governing model • Described using MOF, the other notation may be allowed as informative • Model (lower) • Described using UML, the other notation may be allowed as informative • Should be expressed according to concrete syntax governed by upper metamodel • Model and Model • Model (upper) • Described using UML, the other notation may be allowed as informative • Has role as a source model for derived lower models • Model (lower) • Described using UML, the other notation may be allowed as informative • Should be derived from based on governed upper model • Model and Element • Model (upper) • Described using UML, the other notation may be allowed as informative • Has role as a source model for corresponding value sets • Element (lower) • Described using UML, the other notation may be allowed as informative • Should be enumerated for upper model governing values

23. Framework of Registering (3) Upper Model (metamodel) Model Profile Model Classifier ＋ Namespace Model Selection Model Component (with Model Selection) Model Classifier (Lower Model) governing … Model Instances Model Component (with Model Selection) Skeleton (detail)

24. Onto Source Relationship between Core and Onto Onto Profile ＋ … Onto Expression Onto Instances Onto Rule

25. … Onto Onto Rule Relationship between Onto and Onto

26. MMF Mapping

27. … Relationship between Onto and Mapping Model Transformation

28. Model Mapping World Mapping of Composite Elements Mapping for Model Instance

29. CodedValue Model Profile (Upper Model) Notation for explanation Namespace Model Classifier Ont Profile Ont Domain Model Concept Model Domain Named Element Ont Classifier Ont Instance Model Selection Model Instance Set of Model Instances Ont Components Model Components (Lower Model) Model Type Upper is Governing Lower HL7V3 Ont Observation ActCode ObservationActCode Defining Semantics between Upper and Lower Lab Observation Selected Element Ont Observation ActCode Instance SNOMED LOINC

30. ModelClassifier • The category of Model Classifier • Pattern • Communication • Message • Component • Framework • Stereotype • Tag Value • Vocabulary • Term • Coded Value • Data type • Product • Website • Methodology

31. examples from ebXML UpperModel (overview) CC/BIE Library Data Type BCC/ACC BBIE/ABIE BIEs UBL

32. UpperModel (detail) and ModelClassifiers Instance of ModelClassifier CC BIE ABIE ACC BBIE BCC CC/BIE Metamodel (ebXML)

33. ModelComponent (1) ACC <<ACC>> Person (論理ﾋﾞｭｰ から) Name : Text Birth Date : Date Office Address Residence <<ACC>> Address (論理ﾋﾞｭｰ から) Street;Text ZIP_Post Code : Text Town : Text Address Country <<ACC>> Country (論理ﾋﾞｭｰ から) Country Name; Identifier Population : Numeric CC/BIE Instances Instance of ModelClassifier BCC Insatnce of ModelClassifier Pointing instanfce of ModelSelection

34. ModelComponent (2) CC/BIE Instances ABIE BCC Pointing instance of ModelSelection BCC

35. ModelComponent (3) Component CC/BIE Instances ABIE ACC ModelSelection BCC ACC-Person ModelClassifier (ACCPerson) ModelInstance (ABIE for Person)

36. ModelInstances (BIE message)

37. CC/BIE Metamodel PROFILE ( ebXML ) Registry Class (論理ﾋﾞｭｰ から) Business UniqueIdentifier Context CC Dictionaly EntryName (論理ﾋﾞｭｰ から) Definition BIE CC/BIE Library Data Type Business Informaiton Core BCC/ACC Entity(BIE) +basis Component (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) BusinessTerm CCTerm 0..n 0..n Aggreate Business Aggregate Core Information Entity(ABIE) Compnent(ACC) +basis (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) QualifierTerm ABIE ObjectClassTerm 0..n 0..n Cardinality ACC CC Property BIE Property +basis (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) PropertyTerm QualifierTerm Carndinality 0..n 0..n 0..n 0..n 0..n 0..n BBIE/ABIE Association CC Association BIE +basis Property Property (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) 0..n 0..n Basic BIE Basic CC +basis Property Property (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) BBIE BCC Data Type (論理ﾋﾞｭｰ から) QualifierTerm Basic Core Basic Business Information +basis Component(BCC) Entity(BBIE) (論理ﾋﾞｭｰ から) (論理ﾋﾞｭｰ から) 0..n 0..n BIEs UBL

38. Metamodel of MMF Core • Target • Registry • Relationship • Administered Item (MDR2.0) • MOF Model (from MOF1.4) • ModelClassifier (informative) • Level Pair (informative)

39. Registration Basic Framework

40. RegisteredTarget Structure

41. Registration Example

42. Model Relationship

43. Category of Registered Target (informative)

44. Level Pair (informative)

45. MMF Ontology

46. MMF Core, Ontology and Mapping

47. Registration Form for MMF Core and Onto

49. Example : MMF Application

50. Ontology based Data Mapping in CWM An Application of Ontology and Model Mapping