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:
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:
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.