mmx metadata framework
...the DNA of your data
MMX metadata framework is a lightweight implementation of OMG Metadata Object Facility built on relational database technology. MMX framework
is based on three general concepts:
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... see more.
Access layer | Object oriented methods can be exploited using inheritance to derive the whole data access layer from a small set of primitives created in SQL. MMX Metadata Framework provides several diverse methods of data access to fulfill different requirements... see more.
Generic transformation | A large part of relationships between different objects in metadata model are too complex to be described through simple static relations. Instead, universal data transformation concept is put to use enabling definition of transformations, mappings and transitions of any complexity... see more.

Knowledge Management feat. Wiktionary

March 12, 2010 12:55 by marx

Wiktionary is about Knowledge Management.

Although the term itself has been around for ages, it would probably be hard to find two persons who would agree on what it stands for precisely. Knowledge management has come a long way, from huge hierarchical file systems full of text files of the 70's, to dedicated document management systems of the 80's, to enterprise portals, intranets and content management systems of the 90's. However, it's always been a balancing act between strengths and weaknesses in particular areas, to get the mix between collaborative, structural and navigational facets right.

Two burning issues building a knowledge management infrastructure as we see it are: How to define and access the knowledge we want to manage? and How to store the knowledge we have created/defined?

Regarding the first question, the keywords are collaborative effort in knowledge creation, and intuitive, effortless navigation during knowledge retrieval. In today's internet one of the most successful technologies of the Web 2.0 era is Wikipedia, or more generally - wiki. This is arguably the easiest to use, most widely recognised and probably the cheapest to build method to give a huge number of very different people located all over the world an efficient access to manage an unimaginably vast amount of complex and disparate information. So we found it to be good and put it to use.

One way to define knowledge management in a simple way is: it's about things (concepts, ideas, facts etc.) and relationships between them. In our today's internet-based world we have probably most (or at least a big share) of the data, facts and figures we ever need freely available for us, anytime, anywhere. So it's not about the existence or access of data, it's about navigation and finding it. The relationships are as important and sometimes even more important than the related items themselves. More than that, relationships tend to carry information with them, which might be even more significant than the information carried by the related items. 

Which brings us to the semantics (meaning) of the relationships. In Wikipedia (and in the Internet in general) the links carry only one universal meaning: we can navigate from here to there. A human being clicking on a link has to guess the meaning and significance of the link, and he/she does this by using a combination of intuition, experience and creativity. However, this is a pretty limited and inefficient way to associate things to each other. Adding semantics to relationships enables us to understand why and how various ideas, concepts, topics and terms are related. Some very obvious examples: 'synonym', 'antonym', 'part of', 'previous version', 'owner', 'creator'. The mindshift towards technologies with more semantically 'rich' relations is visible in the evolution from classifications to ontologies, from XML to RDF etc.

Finally, simply by enumerating things and relationships between them we have created a model, which forces us to think 'properly': we only define concepts and ideas that are meaningful in our domain of interest, and we only define relationships that are actually allowed and possible between those concepts and ideas. A model validates all our proceedings and forces us to 'do right things'. Wiktionary employs this approach as the cornerstone of it's technology; in fact, the metamodel acting as the base of Wiktionary houses a multitude of different models, enabling Wiktionary to support management of knowledge in disparate subject domains simultaneously and even have links between concepts belonging to different domains. So, regarding our second issue, metamodel defines a structured storage mechanism for our knowledge repository.

In data processing world, there has always been an ancient controversy between structured and unstructured data. Structured data is good for the computers, and can be managed and processed very efficiently. However, we, humans tend to think in an unstructured way, and most of us feel very uncomfortable while being forced to squeeze the way we do things into rigid and structured patterns. Wiktionary aims to bridge those two opposites by building on a well-defined underlying structure, at the same time providing a comfortable, unstructured user experience. We have two pretty controversial goals and the approach we have taken - Wiktionary - is arguably the cheapest route to solve both of them.

Access Layer

September 29, 2008 15:20 by marx
MMX Metadata Frameworks is built on relational database technology. However, 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.

MMX Metadata Framework provides several diverse methods of data access to fulfill different requirements:
  • Object-Relational Mapper: provides .NET and Web Service (SOA) interfaces (nHibernate). This would cover application programs, web applications and external clients;
  • RDF API: provides XML/HTTP interface for applications. Typically this would include various Semantic Web applications or services;
  • Database CRUD API: provides standard SQL interface for applications requiring database level functionality. This would typically include data transformation jobs, maintenance tasks, query tools etc.

MMX Knowledge Model

September 29, 2008 12:35 by marx

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.