Metadata Framework as the basis for Metadata-driven Architecture Heli Jaago Leading Methodologist Methodology Department

Topics Chart of Organization Interpretation of Metadata Integrated metadata Introduction of MMX Data Model Why Metadata Framework? Metadata Framework as the basis for Metadata-driven Architecture (I-Meta) Who describes metadata? Review of planned workflow Priority list 14/01/19

14/01/19

Interpretation of Metadata Metadata – data about data Concepts. Definitions.Data Processing Rules.References. Classifications (description of structure, versions) XML-based ontologies (XBRL, SDMX, HL7 etc) Workflow descriptions Data model specifications Informational system specification 14/01/19

Keywords of integrated metadata Modelling Relations References 14/01/19

MMX Data Model (1) Model corresponding to M3 level (metametamodel) in MOF (Meta Object Facility) terms housing both M2 (metamodel) and M1 (model) levels. MMX Data Model –knowledge model developed by Estonian software developer. MMX Data Model has been already implemented in an Estonian bank system. It`s working solution for vertical bank applications. MMX Data Model can be seen as a general-purpose storage mechanism for different knowledge models, eg. Frame system, Description Logic (RDF). Data models for these knowledge models are instantiated inside MMX Data Model by defining a set of classes (MD_OBJECT TYPE records) and relations (MD_RELATION_TYPE records) between them.  14/01/19

MMX Data Model (2) Several metadata models are predefined in MMX Data Model, eg: ontology (based on Frame System,  Declaration Logic etc.) classification (based on ISO:11179/Neuchâtel Model, http://www.unece.org/stats/cmf/) relational database (based on Eclipse SQLModel, http://www.eclipse.org/datatools/) role-based access control model (based on NIST RBAC, http://csrc.nist.gov/groups/SNS/rbac/) 14/01/19

MMX Data Model (3) Other possible application fields: Business process elements (business rules, mappings, transformations, computational methods) Data processing events (schedule, batch, task) Data acquisition and transformation processes (container, step, extract, transform, load) Data demographics, statistics and quality measures, etc. ….until the following conditions are fulfilled: Each and every class is part of a primary hierarchy, implemented through parent key; Every hierarchy has a root class denoting the data model; Hierarchies need not be balanced; Members of a hierarchy need not belong to the same class; There are 2 basic methods of implementing a hierarchy that can be mixed: a hierarchy of objects with different type: object type would infer an implicit name for a group (level); a hierarchy of objects of the same type: no implicit names for levels are provided; 14/01/19

Metadata Framework (1) Based on three concepts: meta-metadata model object-relational access layer generic data transformation support Metamodel. MMX Metamodel provides a storage mechanism for various knowledge models. The data model underlying the metadata framework is more abstract in nature than metadata models in general. The model consists of only a few abstract entities, most remarkably, OBJECT, RELATION, EXPRESSION and PROPERTY. The rest of the entities and relationships are 'hidden' inside these root objects and can be derived (inherited) by typifying those. Most of the structure of the data model normally exposed in ER diagram is therefore actually stored as data (meta-metadata). Access layer. As a large part of the structure of the meta-metadata is hidden from the relational model Structured Query Language (SQL) is not the best method for general data access as the queries in SQL would be too complicated and repetitive to write. Instead,  object oriented methods can be exploited using inheritance to derive the whole data access layer from a small set of primitives created in SQL. Modern automatic object environments (Persistency Layers, Object-Relational Mappers etc.) can be taken advantage of here. 3. Generic transformation. A large part of relationships between different objects in metadata model are too complex to be described through static relations. Instead, universal data transformation concept is put to use enabling definition of transformations, mappings and transitions of any complexity (exploiting recursion to flatten complex transformations). A limited set of transformation types ('templates') is defined on user-interface level to simplify creation and management of these transformations. 14/01/19

Metadata Framework (2) As basis for modelling and design of the whole spectrum of applications covering full life-cycle of metadata (concepts, definitions, references, administration, versioning, distribution) As basis for integrated metadata repository (database containing both business and technical metadata with relationships and associations between them) 14/01/19

Planned workflow 14/01/19

Metadata-driven architecture Potential Architectural view User Interface Layer (metadata administration and presentation) Application Components Layer (business and application logic) Knowledge Model Layer (metadata models and logical data access) Persistent Storage Layer (metadata repository and physical data access) 14/01/19

Priorities of metadata description Population Registry of Estonia Informational System of Estonian Tax and Customs Board Cadastral system Education register Constructions register The priority list is combined looking to upcoming Census on 2011. There are 2 other software development processes run together - Population and Dwellings statistical register and Fieldwork informational system. For preparation Census of Population and Dwellings we try to exploit administrative registers data as much as possible. I means that we have to precisly describe relations between administrative registers and statistical register. 14/01/19

heli.jaago@stat.ee 14/01/19