MOF
Autor: Bernhard Haslhofer, Universität Wien, bernhard.haslhofer@univie.ac.at
Abstract
Die Verwendung unterschiedlicher Datenmodelle und Schema-Definitionssprachen führt bei institutionellen Metadaten-Systemen zu Inkompatibilität mit anderen Systemen. Die Meta Object Facility (MOF), ein Standard der ursprünglich der Domäne des Model Driven Engineerings entstammt und deshalb hauptsächlich mit der Unified Modeling Language (UML) in Verbindung gebracht wird, bietet einen Weg, diese Inkompatibilitäten zu überbrücken. Dieser Beitrag bietet eine kurze Einführung in die MOF-Grundkonzepte und analysiert, wie und in welchem Ausmaß MOF Interoperabilität zwischen Systemen herstellen kann.
The Meta Object Facility (MOF)1 is a standardized metadata management framework to enable the interoperability of model and metadata driven systems. It originates from the domain of Model Driven Engineering and is widely known as the modeling language in which the Unified Modeling Language (UML)2 has been specified. However, in the course of time it has become an Object Management Group (OMG) standard that can be used to establish a certain degree of interoperability among any metadata systems such as metadata repositories or digital library applications.
The MOF Architecture
The central concept in the MOF architecture is the notion of a “model”3. A model is designed for a certain application domain and describes its entities and their relations among each other. Each metadata model has a semantics, which is defined through the meaning of its elements in a certain context, and a (concrete) syntax, which can be symbolic, textual, or graphical. The abstract syntax of a model describes its structure. Regarding metadata systems from a technical perspective, we can identify three types of models:
First, metadata schemes4 such as Dublin Core (DC) or Learning Object Metadata (LOM) defining the metadata elements (e.g. Creator, Subject, Work). They can be regarded as constituents of a “metadata model” describing a certain application domain. Second, there are schema definition languages in which the previously mentioned metadata models are defined. Many are defined in XML Schema, some in Semantic Web Languages such as RDF/S or OWL, and if we also consider proprietary schemes, a large part is simply defined by SQL-DDL statements describing the tables and columns in a relational database. From a technical perspective, languages used for building metadata models are models themselves. They provide a set of language primitives (e.g. ComplexType, Class, Property, Table, etc.) with a precise semantic definition and a syntactical notation. Since there is a strict correspondence between the elements of a metadata model and the language primitives, a schema definition language can be conceived as a meta-model of a metadata model and can therefore be denoted as “metadata meta-model”. Third, there are universal modeling languages in which the schema definition languages themselves — hence the metadata meta-models — are defined. This is where MOF becomes an issue: the specification defines a model — which is actually a metadata meta-meta model — for such a universal modeling language. This type of model can also be denoted as “metadata meta-meta model”.
The MOF specification offers a definition for the previously mentioned three model types and arranges them on three levels: M1 is the level that holds the model elements for a particular application; metadata schemes (e.g. definition of element ‘Creator’) are therefore M1 metadata models. Schema definition languages reside on layer M2 — a metadata meta-model can be considered as “model of a particular modeling system”. On the top-most level, at M3, we can find universal modeling languages (e.g. core constructs, primitive types) in which modeling systems are specified. For metadata instances that describe real word (information) objects, for instance a metadata record holding descriptive metadata (e.g. “Creator = Leonardo DaVinci”), MOF introduces the M0 level. Except from the M3 level where the model is defined reflexively, there are instance-of relationships between the elements of a model on one level and the elements of the model on the level above: a metadata instance (M0) is an instance of a metadata model (M1), which is an instance of a metadata meta-model (M2), which is an instance of a metadata meta-model. Figure 1 illustrates these three MOF layers and the correspondences between the models on each layer.
Figure 1: MOF Meta-Levels Hierarchy
MOF defines an M3 model and therefore provides a language for defining the models (abstract syntax) of schema definition languages. There are two variants of this model: EMOF (Essential MOF) and CMOF (Complete MOF). The primary goal of EMOF is to allow simple meta-models to be defined using simple concepts. CMOF is required for more sophisticated modeling.
MOF and other Metadata Systems
Any model that is hooked into the MOF architecture can make use of the supporting XML Metadata Interchange (XMI)5 standard, which is an XML based format that allows the exchange of models and metadata across system boundaries. In that way, metadata becomes platform independent. In practice, a multitude of metadata and metadata models are not MOF-based. They are expressed using XML Schema, RDF/S, OWL, SQL-DDL etc., which are schema definition languages that are largely independent from each other. To overcome this issue, MOF on one hand relies on mappings to these languages. Mappings to XML Schema and XML-DTD, for instance, are part of the XMI specification. On the other hand, it defines a common MOF-based meta-model for languages like RDF/S, OWL, Common Logics, and Topic Maps. This model is part of the Ontology Definition Metamodel (ODM)6 Specification.
How and to what extend can MOF provide interoperability?
The main contribution of MOF for metadata interoperability is its ability to build a bridge between distinct metadata meta-models, the main constituents of schema definition languages. Due to the abstraction hierarchy among the various models in the MOF architecture, models and instances can be expressed in terms of a higher-level model. If we consider, for instance, two distinct metadata instances, both corresponding to distinct metadata models (metadata schemes) which in turn are defined using two distinct metadata meta-models (schema definition languages), these instances are incompatible and must be processed differently by machines. However, if the metadata meta-models are instances of a common MOF model, the gap between the languages is bridged and the metadata could reside in the same metadata system. For achieving interoperability among existing metadata systems, MOF in combination with the Ontology Definition Metamodel provides a valuable means to bridge the gap between common schema definition languages such as XML Schema, RDF/S, OWL, Topic Maps, and also conceptual models such as UML and ER. Whenever a new schema definition language (metadata meta-models) is defined, using MOF for specifying its abstract syntax promises a large degree of interoperability not only with other languages but also with existing industry-standard environments such as modeling tools or metadata repositories.
References
- ↑ Meta Object Facility (MOF) Core Specification, Version 2.0, http://www.omg.org/technology/documents/formal/MOF_Core.htm
- ↑ Unified Modeling Language (UML), Version 2.1.2, http://www.omg.org/technology/documents/formal/uml.htm
- ↑ Seidewitz, E.: What Models Mean. IEEE Software 20 (5) (2003)
- ↑ Different domains use different terms such as ‘schema’, ‘ontology’, or ‘vocabulary’ to denote models representing real-world entities. In this paper we use these notions interchangeably.
- ↑ MOF 2.0 / XMI Mapping Specification, Version 2.1.1, http://www.omg.org/technology/documents/formal/xmi.htm
- ↑ Ontology Definition Metamodel, http://www.omg.org/cgi-bin/doc?ad/06-05-01.pdf
|
Follow comments |
 |
Tags: Data model