Introduction (in OMG terminology)

OGML is a metalanguage like MOF. The goal of OGML is to tackle the difficulties of MOF: a linear modeling architecture, ambiguous constructs and incomprehensible/unclear architecture. OGML provides a nested modeling architecture with three fixed layers (models, languages and metalanguage), therefore it is clear how the different models conform to each other and can be handled. Constructs in OGML are chosen from the science of Ontology, making the distinction between properties / objects and classes / objects clear and less ambiguous. Last but not least, OGML provides an explicit notion of instantiation: model elements encode their types and languages define the semantics of instantiation. This extra information is needed in the relative modeling architecture to distinguish between structural and conceptual views on models, for example: we may want to view a UML model as an instance of the Object language and an instance of the Class model (Clabject). By providing this dual view on metamodel layer and on the language layer, OGML provides a very precise modeling architecture and an expressive way to deal with models.


Many researchers and engineers recognize the shortcomings of MOF. Metamodeling, the practice of specifying ones own language, is not directly supported by the MOF architecture. When introducing new metamodels, the whole architecture remains ignorant of their instantiation semantics. Interpretation of the models conforming to the new metamodels, is only indirectly supported by using reflection. Even thought this provides the needed functionality, it introduces allot of repetitive work for querying the model structure and relating it to the language structure again. Work that can all be automized.

OMG, the creator of MOF/UML, fails to come with a solution. This is clear by the fact that their solution for model querying and transformation (OCL and QVT) only supports the UML and MOF languages. Different other attempts have been taken to improve the situation:

Yet all the current solutions cannot support multi-level metamodeling: the OMG solution has to fall back on reflection and only supports UML and MOF. The other three approaches handle the instantiation semantics outside of the modeling framework (inside the processing engine: OCL/QVT), which renders the semantics of one modeling level ignorant of the higher levels which it actually depends on.

The OGML Approach

OGML integrates the instantiation semantics inside the metalanguage, thus integrating these semantics in the whole modeling architecture. It starts with the reflectively defined metalanguage itself. Using this language a common model structure is defined called OGMLeXtensional or OGMLX (this structure is basically a graph). Another section in the OGML definition defines how linguistic instances of OGML are represented (ontologically instantiated) onto OGMLX elements. Now, we can use the basic language elements of OGML to define another language, say UML. OGML "knows" how the metamodel of this language must be mapped onto OGMLX and the UML definition in turn provides a basic structure (Objects/properties) and instantiation semantics for its language constructs (Classes,Attributes). In the resulting architecture, each (meta)model carries all the information to query its direct and indirect instances. The querying of a model can thus be done using different views:

  1. A UML Object model representing a bunch of cars can be queried according to UML, in which case we can get the values of the attributes of class Car: the color "red" of MyCar, the number of cylinders in the engine of CarX.
  2. The same model can be queried using the OGML instantiation semantics. CarX and MyCar become a linguistic instance of "Object" in the UML language.
  3. Last but not least we have proven that the OGML semantics assures the (unique) representation of each model element in each model on an OGMLX element. When defining a model element in the architecture, this OGMLX element can be derived from the language definition and the OGML definition.
Normally case is hardcoded in tools by a parser (or an input specification of a parser generator). This way, OGML effectively shows that the linguistic and the ontological instantiation can be handled the same (with explicit instantiation semantics). shows the instanceOf relations between models in OGML as arrows. The explicit notion of instance of is thus realized by a description of the arrows semantics by the defining model (the model of which the arrow is an instance of). The self-reflective nature of OGML is not included in the figure, but becomes clear if OGML is also considered a specialization of Languages.


Model Driven Engineering (MDE) treats models as primary design artifacts. Models are expressed in a modeling language. In software development, often a general-purpose language like UML is chosen. We witness an increase in complexity of the problem domains. Often multiple overlapping domains are involved. In the design of large ERP systems, for example, where the domains accounting, legislation, production, stockpiling, etc come together. In such cases, domain specific languages (DSL) provide a more condensed way of modeling the problem domain. Orthogonal to the solution domain we find the different DSLs used in the engineering process: languages for programming the system, documenting the code, expressing patterns and architectures, configuration, traceability, etc.

In certain design artifacts, these languages overlap. For example, code and documentation can be specified on a per-function or per-class basis. Maintaining these artifacts as separate models causes dependencies amongst them that are hard to maintain and grow exponentially. Therefore, we envisage multi-intensional modeling: a modeling environment that supports different views over models. This allows the system designer to view and adapt a model according to a language of his choosing. A first step in this direction has been taken by the creation of Ontology Grounded MetaLanguage (OGML). OGML currently provides an API to query models from different perspectives.




Specification TODO




  1. Eclipse 3.4 Java or vanilla
  2. Install EMF plugins (help Install new software)
  3. Download TCS and put it in the plugin directory.
  4. Open the downloaded workspace.
  5. Pray.
  6. Use.


Currently and in the near future OGML does not support:


  1. Adapt checker to multi-intensional modeling feature.
  2. Implement both model import (physical) and referencing.
  3. Identity function for model elements (currently we use the name or location property).
  4. Value handling. Like in GModel, all values are serialized.
  5. Laws (constraints on model elements).
  6. Consider different parsers and loose eclipse dependency.