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' behind 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). 

MMX Metamodel 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 Metadata Model by defining a set of classes (MD_OBJECT TYPE records) and relations (MD_RELATION_TYPE records) between them. MMX Metamodel corresponds to M3 level (metametamodel) in MOF terms housing both M2 (metamodel) and M1 (model) levels. An arbitrary number of different data models can exist inside MMX Metadata Model simultaneously with relationships between them. Each of these data models constitutes a hierarchy of classes where the hierarchy might denote an instance relationship, a whole-part relationship or some other form of generic relationship between hierarchy members (see Construction of Controlled Vocabularies).  

Several metadata models are predefined in MMX Metamodel, eg:

However, any other type of data model can be described in MMX, eg.

  • 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;


External references to MD_OBJECT and MD_RELATION metaobjects are referenced with URI-s that have different meaning in context of different metamodels. For external well-defined Internet resources this reference takes the form of a URL. In RDF context these references might refer to RDF vocabularies defined elsewhere. In cases of technical metadata (eg. relational model, file system, etc.) where standard URI schemes are not available new unregistered URI-s have to be be used.

Model Architecture

MMX Data Model is based on principles and guidelines of EAV (Entity-Attribute-Value) or EAV/CR (Entity-Attribute-Value with Classes and Relationships) Modelling technique suitable for modelling highly heterogenous data with very dynamic nature. Unlike in traditional ER design, data element names in EAV are stored as data instead of column names and data can only be interpreted with the help of metadata. Therefore modifications to schema on 'data' level can easily be done without physical modifications by just modifiying corresponding metadata.