Editor’s 3rd Draftmetadata-standards.org/Document-library/Documents... · [Note:] the meaning of this term might vary according the context of the domain to be discussed. In the

ISO/IEC JTC 1/SC32 WG2 N1790

2013-05-28

ISO/IEC WD19763-1:ED2

ISO/IEC JTC 1/SC 32/WG 2

Secretariat:

Information Technology –Metamodel framework for interoperability

(MFI)—Part 1: Reference model, Second Edition

Editor’s 3rd Draft

Copyright notice

This ISO document is a Draft International Standard and is copyright-protected by ISO. Exceptas permitted under the applicable laws of the user's country, neither this ISO draft nor anyextract from it may be reproduced, stored in a retrieval system or transmitted in any form or byany means, electronic, photocopying, recording or otherwise, without prior written permissionbeing secured.

Requests for permission to reproduce should be addressed to either ISO at the address belowor ISO's member body in the country of the requester.

ISO copyright officeCase postale 56 CH-1211 Geneva 20Tel. + 41 22 749 01 11Fax + 41 22 749 09 47E-mail [email protected] www.iso.ch

Reproduction may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

Committee Draft ISO/IEC 19763 part 1 – Reference model 2nd edition

1

FOREWORD...................................................................................................... 3

INTRODUCTION................................................................................................ 4

1 SCOPE......................................................................................................... 6

2 NORMATIVE REFERENCES ...................................................................... 7

3 TERMS, DEFINITIONS AND ABBREVIATED TERMS ............................... 8

3.1 Terms and definitions ...................................................................................................83.1.1. concept ........................................................................................................................ 83.1.2. framework .................................................................................................................. 83.1.3. information model...................................................................................................... 83.1.4. interoperability .......................................................................................................... 83.1.5. metadata..................................................................................................................... 83.1.6. metamodel .................................................................................................................. 83.1.7. model .......................................................................................................................... 83.1.8. model element ............................................................................................................ 83.1.9. model construct .......................................................................................................... 93.1.10. model element ........................................................................................................ 93.1.11. modelling facility.................................................................................................... 93.1.12. modelling language ................................................................................................ 93.1.13. ontology................................................................................................................... 93.1.14. Open data................................................................................................................ 93.1.15. registration ............................................................................................................. 93.1.16. registry.................................................................................................................... 93.1.17. repository ................................................................................................................ 9

3.2 Abbreviations ................................................................................................................93.2.1 EDI: Electronic Data Interchange ............................................................................ 93.2.2 ebXML: Electronic business XML............................................................................. 93.2.3 LOD: Linked Open Data ......................................................................................... 103.2.4 MDR: Meta Data Registry(ISO/IEC 11179)........................................................... 103.2.5 MFI: Metamodel Framework for Interoperability .............................................. 103.2.6 RGPS : Role, Goal, Process and Service ................................................................. 103.2.7 ROR: Registry of Registries .................................................................................... 103.2.8 RS: Registry Summery ............................................................................................ 103.2.9 SDO: Standard Development Organization........................................................... 103.2.10 UML: Unified Modelling Language........................................................................ 103.2.9 XML: eXtensible Markup Language........................................................................ 10

4 CONCEPT AND ARCHITECTURE OF MFI............................................... 11

4.1 Purpose of the MFI standards ....................................................................................11

4.2 Strengthen interoperability and integration capability .............................................114.2.1 System interoperability.............................................................................................. 124.2.2 Semantic interoperability .......................................................................................... 144.2.3 Registry interoperability ......................................................................................... 144.2.1 On demand model selection .................................................................................... 15


2

5. CONCEPT OF MODEL REGISTRATION.................................................... 16

6. MFI AND MDR ARCHITECTURE ........................................................... 18

6.1 Overall structure of MDR/MFI ........................................................................................18

6.2 Modeling facility for MFI ............................................................................................18

6.3 Internal structure of MFI ................................................................................................19

6.4 common structure for MFI sub-parts ..............................................................................20

7 CONFORMANCE....................................................................................... 22

8 BIBLIOGRAPHY........................................................................................ 23

ANNEX A: ........................................................................................................ 24

A1. WHAT IS METAMODEL......................................................................... 25

A1.1 Model ..........................................................................................................................25

A1.2 Metamodel ..................................................................................................................25

A2. Typical MFI metamodel for registration ......................................................................28


3

ForewordISO (the International Organization for Standardization) and IEC (the InternationalElectrotechnical Commission) form the specialized system for worldwide standardization.National bodies that are members of ISO or IEC participate in the development of InternationalStandards through technical committees established by the respective organization to deal withparticular fields of technical activity.ISO and IEC technical committees collaborate in fields of mutual interest. Other internationalorganizations, governmental and non-governmental, in liaison with ISO and IEC, also take part inthe work.International Standards are drafted in accordance with the rules given in the ISO/IEC Directives,Part 3.In the field of information technology, ISO and IEC have established a joint technical committee,ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee arecirculated to national bodies for voting. Publication as an International Standard requiresapproval by at least 75 % of the national bodies casting a vote.Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 19763 maybe the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or allsuch patent rights.International Standard ISO/IEC19763 was prepared by Joint Technical Committee ISO/IEC JTC1, Information technology, Subcommittee SC 32, Data management services.ISO/IEC 19763 consists of the following parts, under the general title Information technology--Metamodel Framework for interoperability:_Part 1: Reference model, 2

ndedition [this document]

_Part 3: Metamodel for ontology registration, 2nd

edition_Part 5: Metamodel for process model registration_Part 6: Registry summery_Part 7: Metamodel for service registration_part 8: Metamodel role and goal registration_part 9: On demand model selection (Technical Report)_Part 10: Core model and basic mapping_Part 11: Structured registering (Technical Report)_Part-12: Metamodel for Information model Registration -


4

Introduction

Due to the proliferation of mobile devices, Social Network Systems and Cloud Computing overthe Internet, the more effective sharing of information and exchange of business transactionsacross countries and cultures has become easierIn the private sectors, the exchanging business transaction through EDI (Electronic Data

Interchange) was already recognized as a common way. At the same time, they have huge datain their database or the Cloud. It could be their urgent concerns to make use of those data forinducing the business intelligence.In the governmental sectors, many countries, territories or regions are working on the

establishing of new scheme that enable the interoperation and the collaboration among differentdepartments or agencies, materializing semantically interoperation of data across border orlanguage difference.

To cope with those current trends, it is required for governments to improve their services forcitizen and to make interoperation among different agencies more efficient through the internet.Especially, sharing of critical safety related information, such as earthquake, flood or some otherdisasters must be considered as the first.

It is assumed that the disclosing public sector information through the internet, so called “OpenData” could be an infrastructure to activate new innovation in the private sectors. One of issuesfor users is to access different governmental open data and mush up them to create a newinformation or knowledge.

Those trends had roused further needs for new standards that enable effective informationsharing in the both private and government sectors.One of key facilities for the easy sharing and the interoperation of information among different

communities could be the registry that enables the discovering and sharing of meta-informationsuch as metadata and models.

Background of the 2nd

edition of MFI part 1The first edition of the MFI part-1 standard was published 2007. At that time, the MFI family ofstandards was consisted of only four sub parts (part 1, part 2, part 3 and part 4).However, after publishing the first edition of part 1, many new projects were proposed. They aremostly intending to enhance the capability of MFI to cope with new trends of market, such asdiscovering process models and service models.Almost same time, a revising project of ISO/IEC11179 part-3 (The registry metamodel and

basic attribute: MDR) that is the core part of metadata registry standard was initiated.The MFI standards can be considered as extensions of the MDR core part by the sharing sameregistration mechanism and procedure. Then, a special study project for the harmonization ofMDR and MFI was formulated. As a result of the study, the common facilities were defined to beused in both MDR and MFI standards. It was expected that MDR and MFI could be more closelyrelated and integrated for the benefits of the users who need more effective sharing ofinformation and models or more sophisticated system interoperation.A design guideline to keep consistency on representing metamodel using UML was defined aswell, to be used in the developing MFI standardsThen, this new edition of this part was revised to provide a clear view to MFI and illustrate overallarchitecture of the MFI family of standards reflecting major changes mentioned above.


5

Information technology — Metamodel framework forInteroperability (MFI) — Part 1: Framework, edition 2


6

1 ScopeThis standard is a part of ISO/IEC19763 (Metamodel framework for interoperability: MFI) seriesof standards. As the first part of MFI (part 1), this document provides an overview and the scopeof MFI series of standards. Especially, the background, underline concept, overall architectureand requirements to the development of other parts of MFI standards.

The ISO/IEC19763 (Metamodel framework for interoperability: MFI) family of standards wereprepared to provide standard facilities to register any kind of models through the metamodel forregistration. However, MFI would not specify any repository structure where actual modelinstances were stored. Then, MFI metamodel provides the standard view when to be used theregistering models that were stored in repositories.


7

2 Normative ReferencesThe following referenced documents are indispensable for the application of this document. Fordated references, only the edition cited applies. For undated references, the latest edition of thereferenced document (including any amendments) applies.

ISO/IEC 11179-1, Information technology – Metadata registries (MDR) - Part 1 : FrameworkISO/IEC 11179-3, Information technology – Metadata registries (MDR) - Part3 :Ed3 MetamodelISO/IEC 19501:2005, Information technology - Open Distributed Processing- Unified ModellingLanguage (UML) Version 1.4.2ISO/IEC 19502:200X, Information technology - Open Distributed Processing- Unified ModellingLanguage (UML) Version 2.1.2

[NOTE;] Do we need MOF/XMI as normative?ISO/IEC 19502:2005, Information technology – Meta Object Facility (MOF)ISO/IEC 19503:2005, Information technology – MXL Metadata Interchange (XMI)


8

3 Terms, definitions and abbreviated terms

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 19505-2, ISO/IEC11179-3:2012, and the following apply.

3.1.1. concept

an unit of knowledge created by an unique combination of characteristics

[NOTE: ] concepts are not necessarily bound to particular languages. They are, however,influenced by the social or cultural background which often leads to different categorizations.See: ISO/IEC11179 part -3

3.1.2. framework

a basic structure underlying a system, concept, or text: the theoretical framework of politicalsociology

1

[Note:] the meaning of this term might vary according the context of the domain to be discussed.In the MFI, the framework is used for represent architectural view to a set of metamodels.

3.1.3. information model

graphical and textual representation of entities (4.2.12) and the relationships (4.2.28) betweenthem[NOTE:] May also be known as a data model, a conceptual data model, a logical data model, anentity relationship model, an object class diagram or a database definition

3.1.4. interoperability

the capability of communicate, execute programs, or transfer data among various functionalunits in a manner that requires the user to have little or knowledge of the unique characteristicsof those units. [see ISO/IEC 2382]

3.1.5. metadata

data which describes other data.See. ISO/IEC 11179-1 and ISO/IEC 19502

3.1.6. metamodel

a model which describes other models.See : ANNEX A and ISO/IEC 19503

3.1.7. model

A representation of concept in a domain of interest using a normative modelling facility andmodelling constructs.

3.1.8. model element

element or component in a model

[NOTE:]examples of model elements are an entity type in an information model, an event in a processmodel, a service operation in a service model, or an actor in a role and goal model.

1http://oxforddictionaries.com/definition/english/framework


9

3.1.9. model construct

a unit of notation for to represent a model.

[Note:] More generic term for modelling element. Sometimes the term is used to includemetadata, code and object patterns rather than the notations of a particular modelling facilitysuch as UML.

3.1.10. model element

element or component in a modelsee: ISO/IEC 19763 part 10

3.1.11. modelling facility

a set of rules and notations for use when modelling.Note: UML is a typical example.

3.1.12. modelling language

llanguage or notation that is used to model some aspect of a domain of interest.Note: UML is a typical modeliing language

3.1.13. ontology

description of concept.see more detailed definition of ISO/IEC19763-3 and ISO/IEC11179-3: 2012

3.1.14. Open data

TBD

3.1.15. registration

an official list or record of names or items:see: chapter 5.

3.1.16. registry

a place where registers or records are kept[ ]:2

in MFI and MDR, it mean a database to keep metadata or metamodel.see: chapter 5.

3.1.17. repository

a place where or receptacle in which things are or may be stored:3

in MFI and MDR, a repository is recognized as a database that stores actual instances toconform to a particular metadata or metamodel.[see: chapter 5 ]

3.2 Abbreviations

3.2.1 EDI: Electronic Data Interchange

3.2.2 ebXML: Electronic business XML

2http://oxforddictionaries.com/definition/english/registry

3http://oxforddictionaries.com/definition/english/repository


10

3.2.3 LOD: Linked Open Data

3.2.4 MDR: Meta Data Registry(ISO/IEC 11179)

3.2.5 MFI: Metamodel Framework for Interoperability

Note: This family of standards (ISO/IEC 19763)

3.2.6 RGPS : Role, Goal, Process and Service

3.2.7 ROR: Registry of Registries

3.2.8 RS: Registry Summery

3.2.9 SDO: Standard Development Organization

3.2.10 UML: Unified Modelling Language

3.2.9 XML: eXtensible Markup Language


11

4 Concept and Architecture of MFI

In this section, the background and basic concept that are underlining to all parts of ISO/IEC19763 (MFI: Metamodel Framework for Interoperability) and the overall structure of the MFIfamily of standards, should be explained.ISO/IEC 19763 (MFI) is a set of metamodel standards. Those metamodels are prepared for theregistering models to model registries, such as, ontologies, information models, process models,service models and roles & goal models, in order to materialize the interoperability amongsystems or persons.

4.1 Purpose of the MFI standards

To enable the discovering and the sharing of information on the heterogeneous networksocieties, some sort of specific information that describes data or models, must be needed.Sometime, those specific information are called metadata or metamodel to be disclosed to thesociety.The term “metadata” is defined as a data that describes other data. Also, the term “metamodel”

is defined as a model that describes other models. These definitions were accepted widely ascommon basic notions. However, more precise definitions should be provided in the ANNEX A.The term “Framework” generally means a skeleton or a structure to be applied to creation of an

article or a product. Usually, a framework has own dedicated objectives or purposes. Then, theframeworks would guide and regulate designing or productions to obtain the purpose keepingthe consistency among components.MFI is also a framework consisted by several normative metamodels. The common purpose of

those metamodels is the keeping consistency of the registration of information objects, such asinformation models, ontologies, service definitions or roles & goals, to a MFI registry.Each dedicated normative metamodel defined as an independent sub part of the MFI family ofstandards. The detail structure of the MFI will be shown at the clause 6 of this document.Through the applying dedicated MFI metamodels to each registration effort of those objects into

registries, it becomes easier to find or discover an appropriate target registry that keeps contentsto be used. The each MFI registry does not store any actual contents of the target registry orrepository. Only keeps the location and small administrative information of the target registry orrepository.The final goal of the MFI is focused on the facilitating the data integration that is discovering

objects(data, models, ontologies, service definitions, etc.) scattered over networks at differentsites or places and integrate them through exanimating the adequacy form the view point of theuse, and selecting appropriate mapping functions.

4.2 Strengthen interoperability and integration capability

The data or services integrations must be rely upon the strengthen of the capabilities of thediscovering and various types of interoperability. Such as; System interoperability Semantic interoperability Registry interoperability


12

Figure Purpose of MFI standards

4.2.1 System interoperability

To materialize the system interoperability, not only standardization of communication protocolsor more lower level physical connection, but, the standardization of message formats andrepresentation of data as metadata to be exchanged have to be needed.Today, SDO such as ISO, IEC, UN or some other standard consortia developed and enforced somany metadata standards or registry standards, following their own industry or domainrequirements. For instance, E-business, Healthcare, Electronic parts, Electronic documents,Library etc., those domains have own metadata standards.Then, it is still not easy to share information across deferent industries or domains without anyspecific mapping or translation tools between metadata among different registries. It must be oneof obstacles for materializing a global and dynamic supply chain that penetrate differentindustries across countries.For instance, in the electronics manufactures, they has own product database while retailer alsohas their own item database. Each database is constructed following particular metadatastandards that were specified by industry consortium or SDO. However, it is not easy to keep theinteroperation among those on the same products data. There must be some sort of mappingfunction to connect different data on a same product. [see. figure-1]

At the moment, instances of those metadata mapping have to be specified by human effortsdiscussing the difference between manufacturing product and sales item. They need to comparemetadata. At that time, they have to refer to information model to understand the nature of data.Then, the sharing of information model could be indispensable in the defining data as metadata,also, understanding metadata.


13

Fig-1 Current status of the cross industries interoperation

Not only for understanding of data, various types of information models were used widely today.In the software development area, the information models using UML or IDEF1X, etc., were usedas the software specifications. To capture the essential context of a target domain, normativerepresentation techniques were used to promote software design and development involvingdifferent peoples. In those environments, the model sharing must be necessary. Also, to involveengineers who are working in the different countries, so called “Offshoring”, they need the modelsharing supported by specific platform or infrastructure.MFI provides basis for the model sharing infrastructure, in term of the model registry.The model sharing could be accelerated by the registering models to a registry (Model registry)and make it easier to discover an appropriate model.The MFI is a set of normative metamodel to be used for the model registration, just like the MDRprovides normative metamodel for registering the metadata

Fig.2 Basic concept of the model sharing through the Model Registry


14

4.2.2 Semantic interoperability

MFI intends to enable the data and model sharing based on the semantics of data, facilitating theregistration of ontology. The ontology is a set of concept definitions. Today, a lot of terminologydictionaries are available on the Internet. Some of them are generic dictionaries while the othersare set of technical terminologies in a specific domain, such as Healthcare.MFI part3 (Metamodel for ontology registration) could be used to register those existing ontologyrepositories and make use of them for investigation of semantically sameness or understandingmodel components, terminologies or data elements.Those facilities must be needed for not only in understanding of the meaning of information butalso needed in the defining mapping rules among model components and data elements.

4.2.3 Registry interoperability

Another major purpose of the ISO/IEC 19763 (MFI) family of standards is to enable theinteroperability among registries. Currently, so many metadata registries or model registrieswere developed and enforced in various types of business domains in deferent countries orterritories. Most of them were developed conforming to international standards, such ase-business, healthcare, or library domains. However, those standards themselves wereincompatible each other and they were developed by the mostly requirements came from theirown domains. It means that a single company or user who belongs to a particular domain hasdifficulties on the accessing registries that were enforced in other different domains.

For the sake of the system interoperability, it could be an urgent issue to share metadata registryacross different domains. Then, the ISO/IEC 19763-6 standard (MFI-6) is intending to materializethe registry interoperation addressing to the problems mentioned above.This standard specifies a set of small XML artefacts called the Registry Summary to be attachedto each registry in the domains. These artefacts were represented by a metamodel using UML inthe MFI part 6.

The registry summary is a small set of metadata to be attached in the target registry as headerinformation of the registry. If every registry would follow and attach this registry summary to theirregistries, it could be possible to capture and know the nature of the registry and technicalinformation for accessing the registry.

Figure 3 illustrates a typical use case of RS (Registry Summary) and ROR (Registry ofregistries). Each registry prepared in a particular domain could be able to disclose RS at theirheader as entry information. Then, every user in different domains, such as Manufacturing orRetailing become able to prepare their own dedicated registry that is a collection of RS. It shouldbe called the Registry of Registries (ROR).

Currently, every domain of business is supported by some sort of registries or dictionaries. InISO or IEC, a lot of registry standards were developed and enforced. Then, for instance, tocomplete a particular supply chain that covers from manufacturer to consumers, they have torefer different registries or dictionaries, switching interface. Especially, to identify a vender orproduct, they have to spend a lot of time for negotiations to resolve those problems.Then, one of issues for MFI is to provide standard artifacts to construct their own Registry ofRegistries (ROR). That could resolve those problems by registering registries that they mightconcern. It will enable registry interoperability among current heterogeneous registryenvironment.


15

Fig 3 Registry interoperability by RS and ROR

4.2.1 On demand model selection

One of the urgent issues for the current system that rely upon the internet must be the preservingthe capability for smart and efficient discovering and integrating of information objects that werespeeded widely over the networks.Especially, the proliferation of the Cloud computing and the LOD(Linked Open Data)[XX ]aroused the necessity of the more sophisticated knowledge & service discovering features tointegrate those according to their needs.Those standards, such as, the MFI part 5(metamodel for process model registration), part7(metamodel for web services registration) and part 8(metamodel for RGPS registration) arespecializing to enable to register useful services and their processes keeping relations with theroles and goals that are also registered in the GRPS registry.Figure 4 illustrates the concept of the ODMS (On Demand Model Selection) based on RGPS(Role, Goal, Process and Service).

Figure 4 Discovering services and processes based on RGPS


16

5. Concept of model registration

MFI is a set of metamodels to be used in various types of model registration. The Major purposeof MFI metamodels is to make the model registration become easier and to enable theregistration consistency.Here, the term “Metamodel” is recognized as a model that describes a model. However, Moredetailed insight of the metamodel should be provided in the later potion of this document

Fig 5 shows the basic concept of model registration. The MFI metamodel provides to registrarnormalized view to registering. Also, the metamodel specifies the structure of registrationinformation to be stored into the registry.

Fig 5 Basic concept of MFI registration metamodel

A core metamodel for registering models is specified by MFI part 10. That is “the core model andbasic mapping”. According to the core model and basic mapping, other parts of MFI providesome specialized metamodel for the convenience of the registering specific modes as followed.

Ontology model (MFI part-3)Process model (MFI part-5)Service model (MFI part-7)Goals and Roles model (MFI part-8)Information model (MFI-12)Registry summery model (MFI-6)

MFI would not specify any implementation requirements for the registry or the repository, onlyspecifies metamodel for various types of models, in term of registration. That means how torepresent a model for the registration

Particularly, MFI-10 represents a registration mechanism as the core model to be used by otherparts of MFI. Also, another metamodel that represents registry itself as profile on a particularregistry is prepared to make the registry interoperation become possible.In the MFI, the model registry does not store any model instance into the data base, only model

information could be stored, while the model repository could accommodate instances of modelin the databases.Usually, the model repository used for storing a model into a database to be used for recallingand represent model exactly again by the modelling tools.


17

However, the model registry keeps only model administration information, such as location ofmodel, owner of model etc. Through the registry, it could be available to know the exact placewhere actual model is stored in a model repository.Generally, the registry is the place where records of some events or entities are put and kept forthe publicly disclose.Then, MFI registries store only information about those model and model components as follows.

Where the model exists, who is owner, when it is registered…What components are consist of the model and where does it existWhat are relationships among components

Then, MFI supposes that actual models to be shared are stored in a particular model repositoryoutside.In MFI, any representation style of model, such as UML, IDEF1X, ER, NIAM or BPMN can beregistered. Also, any kinds of domain models are available to be registered.

Fig 6 Registry entry and metamodel

The MFI and MDR, both share the same registration mechanism, such as, administered_itemand Identification_item.

In MFI, the registration record was inherited from the registration record that was standardizedISO/IEC 11179 (MDR).

The term “”Registration” means the recording of the things, such as some new events, oroccurrence of new entities, officially.Generally, these records are kept in the specific files called the registries, and they could not beupdated. Those records are referred and used by others, publicly. Then, the record in the registryshould be clearly defined and formatted, item to be registered must be standardized. Some time,record type and format might be the legal issues.A registration record should contain following items.1) The time to be recorded2) The ownership of the things3) Types of the things4) Name of registrar5) Name of registration authority6) Submission status


18

6. MFI and MDR ArchitectureThe metamodel framework for interoperability (MFI) family of standards consists of multiple partswhich are to be used in the sharing of information models, services, role & goal specification andontologies through the registration.

6.1 Overall structure of MDR/MFI

Each part of this family of standard specifies metamodel (by UML) that enables to register ofartefacts, such as information models, process models, services model, and ontologies.Through the registration of those various types of models (by any modelling language), it wouldmake possible to share those models and their constructs. It is also become easier tounderstand meaning and semantics of objects or attributes represented by metadata.Then, it is needed that all of parts of MFI are close related to ISO/IEC11179 (MDR: Metadataregistry). MFI considered as an extension of MDR. Especially, MFI-10 (Metamodel for modelregistration and basic mapping) provides common facilities to keep harmonization with MDR.Figure-7 illustrates the overall structure of both standards. A more precise view to internalstructure is shown on the Figure 8.

Figure 7. overall structure of the MFI and MDR standards

6.2 Modeling facility for MFI

All parts of MFI specify objects, such as model and model element to be registered in registryusing UML as metamodels. MFI could accommodate any modeling facility or model language bythe describing to be registered


19

Fifure 8. parts dependency in MFI

6.3 Internal structure of MFI

In the MFI family of standards, many parts were prepared according to the current industrial andpersonal requirements for finding and discovery of models, services, and ontologies.

Figure 9. parts relationship in the MFI family of standards

Administered_ItemIn order to keep consistency on the registration of objects, such as metadata or metamodel,

all parts of MFI are required to share the same administrative Information that is defined in thebasic package of ISO/IEC11179-3:2012. That enables to make use of metadata stored inmetadata registries.

Part 1 Reference modelThis part of the standard describes the concepts and an overall architecture of themetamodel framework standard to be applied in the development and the registration of thefollowing individual metamodel frameworks.

Part 10 Core model and basic mapping


20

This part of the standard describes the core model of the metamodel framework to be used inthe development of metamodel framework standards. The core model provides a mechanismfor metamodel description and normative constructs to be used in the development ofmetamodel framework standards.

Part 3 Metamodel for ontology registrationThis part of the standard describes a metamodel that provides a facility to registeradministrative information of ontologies.

Part 5 Metamodel for process model registrationThis part of standard specifies a metamodel that provides a facility to register any kind of

process model. The register following this standard become able to be RGPS registry.

Part-6 Registry summeryThis part of standard provides a metamodel of registry summery information that to be

installed on any kind of registry. By those summery information could be collected andconformed to a ROR (Registry of Registries).

Part 7 Metamodel for service registrationThis part of standard provides a metamodel for service registration. The services in this

standard are considered mostly the Web service. However, generic service that supported by aset of processes could be applied.

Part 8 Metamodel for RGPS registrationThis part of standard provides a metamodel for Role and Goal registration. A goal may be

decomposed into a couple of Roles.

Part 9 On demand model selection (TR)This part of standard provides an idea and a methodology to use model registry

contents ,such as Process model, Service model and Roles & Goals model from the view point ofODMS (On Demand Model Selection).

Part 11 Structured registering (TR)TBD

Part 12 Metamodel for registering information modelThis part of standard provide a super type of information models as a common view to

different modelling facilities such as, UML, ER, or IDEF1X,etc.

6.4 common structure for MFI sub-parts


21

Figure10. Common structure of MFI standards


22

7 ConformanceISO/IEC19763-1 specifies no conformance requirement. Other parts of this family of standards

specify their own conformance requirements as appropriate.


23

8 Bibliography[1] ISO/IEC TR 9007:1987, Information processing systems – Concepts and terminology forthe conceptual schema and the information base

TR 9007 provides information on conceptual modelling.

[2] ISO/IEC 10027:1990, Information technology – Information Resource Dictionary System(IRDS) FrameworkISO/IEC 10027 describes the concept of levels of modelling.

[3] ISO/IEC TR 15452:2000, Information technology – Specification of data value domainsTR 15452 describes the specification of value domains. It is expected to be replaced byISO/IEC TR 20943-3.

[4] ISO/IEC TR 20943-1:200n, Information technology – Achieving metadata registry contentconsistency – Part 1:Data elementsTR 20943-1, which is under development at the time of publication of ISO/IEC 11179-3, willprovide guidelines for recording data elements in a 11179-3 metadata registry.

[5] ISO/IEC TR 20943-3:200n, Information technology – Achieving metadata registry contentconsistency – Part 3:Value domainsTR 20943-3, which is under development at the time of publication of ISO/IEC 11179-3, willprovide guidelines for recording value domains in a 11179-3 metadata registry.

[6] [MDA] Policies and Procedures for MDA: OMG, 2001, pp/2001-09-01[7] [ebRIM] ebXML Registry Information Model. Version 0.56. Working Draft. 2/28/2001.ebXML Registry Project Team.[8] [ebRS] ebXML Registry Services. Version 0.85. Working Draft. 2/28/2001. ebXMLRegistry Project Team.


24

ANNEX A:

(Informative)

Basic concept of MFI metamodel


25

A1. What is MetamodelThis ANNEX provides the concept of the model and metamodel that are used in this standard.Before discussing metamodel, the concept of model to be discussed in this standard should bedefined.

A1.1 Model

Model is a representation of concept. The representation should be made following a particularnormative modeling facility such as UML and normative model elements such as vocabulary andvalues. However, result of the modeling could vary according to view points.

Figure11. Model and metamodel

A1.2 Metamodel

MFI is a set of metamodels that are prepared for the particular use, such as the registration ofmodels. Metamodel is also a model. Usually, same modelling language, such as UML is used torepresent both metamodel and model.Generally, the term metamodel is defined “a model which describes other models”. Anotheraspect of metamodel is that “a model which governs other model”. Then, the role of metamodelcan be classified as follows.

(1) Provide modelling constructs (i.e, diagram notations) with its semantics and syntax to themodel. Metamodel guides modelling under uniform representation manner.

Ex. UML metamodel (UML Superstructure)

Provide specific modelling concept for modelling with its constructs, such as “Object”, “Class”.”Relationship”, etc.


26

Figure 12 class diagram and simple metamodel at the N+1 layer

Figure 13 example of metamodel for “Object ” concept

(2) Here, the “modelling concept” means what kind of modelling concept should be used, such asObject modelling, NIAM modelling, IDEF1X modelling or others.

Ex. MOF (Meta Object Facility)

(3) Provide specialized modelling construct as template to view and capture the reality asconcept in a particular domain.

Ex. SPEM (Software Process Engineering Metamodel: OMG),

Usually, applying a metamodel to a modelling effort could be done by the inheriting modellingconstructs to the model to be defined.


27

Every metamodel in the MFI standards is considered to be 3) above mentioned, providingspecial dedicated modelling views in term of the model registration

Figure types of Metamodel and model


28

A2. Typical MFI metamodel for registration