Theory Home > On Models and Model Transformations
On Models And Model Transformations

On Models And Model Transformations

This text is an excerpt from the PhD thesis by S. Kozlovičs (

Models and Abstraction

In his article in the ``Software and Systems Modeling'' journal Jochen Ludewig pointed that although we, humans, use models all the time, it is difficult to define what a model is. ``Endless discussions have proven that there is no consistent common understanding of models'', — he writes [86]. For the purpose of this thesis models must have one essential property, namely, the ability to be automatically processed by a computer. Thus, I will use the following definition of a model found in the book by A. Kleppe et al. [78]. The definition consists of the two parts:
A model
is a description of (part of) a system written in a well-defined language.
A well-defined language
is a language with well-defined form (syntax) and meaning (semantics), which is suitable for automated interpretation by a computer.
For other possible definitions the reader can refer to the thesis by Elīna Kalniņa, where she has done extensive work on investigating various sources, while seeking for a model definition [75].
Another important notion related to models is the notion of abstraction. Although it is a general term, in Computer Science it has a quite concrete sense. A Dictionary of Computing by Oxford University Press gives the following definition:
[is] the principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate solely on those that are. The application of this principle is essential in the development and understanding of all forms of computer system [58].
Thus, abstraction removes irrelevant details. The number of details is related to the notion of abstraction level. The following definitions can be found in the book by A. Kleppe et al. [78]:
Abstraction Level
[is] the inverse of the (relative) amount of details that are in a model.
High Abstraction Level
[means] a (relative) low amount of details.
Low Abstraction Level
[means] a (relative) high amount of details.
In this thesis, ``higher level of abstraction'' will usually mean ``closer to human mind'', while ``lower level of abstraction'' will mean ``closer to computer hardware''.
Although mainly I will use the definition of abstraction from above, there is another (general) meaning of that term, which is also used in Computer Science, and which is particularly important, when we speak about models. The Encyclopædia Britannica describes it as follows:
[is] the cognitive process of isolating, or “abstracting,” a common feature or relationship observed in a number of things, or the product of such a process [39].
Abstraction in this sense appears, for instance, in object-oriented programming (OOP): a class defines common features for its objects and a superclass factors out common features of its subclasses.
A model and abstraction are the two main notions used in this thesis.

1.1 Models, Metamodels, and Meta-Metamodels

In the definition of a model from above a well-defined language is a language for describing models. That language can be considered a model by its own. Thus, it is a model for describing other models, or a metamodel. Saying that a metamodel MM describes a model M is the same as saying that M conforms to MM.
Example A. The Java grammar can be considered a metamodel for describing models in the form of Java programs. Every syntactically correct Java program conforms to the Java grammar.
A metamodel is also a model, thus, it is also written in some well-defined language. We can think of that language as of a metamodel for describing metamodels, or a meta-metamodel.
Example B. Extended Backus-Naur Form (EBNF), a notation for context-free grammars, can be considered a meta-metamodel for grammars [20]. Grammars themselves can be considered metamodels (as in Example A) that conform to EBNF.
Although we can continue to add other meta-s, in many cases a meta-metamodel is able to describe itself. This observation is called the three-level conjecture, where the three meta-levels are the model level (M1), the metamodel level (M2), and the meta-metamodel level (M3); the fourth level is not needed, since it equals to M3. These levels are sometimes called layers [52].
Example C. A Java program lies at Level M1, the Java grammar lies at M2, and EBNF lies at M3. EBNF can be described in EBNF.

1.2 Technical Spaces

In 2002 I. Kurtev, J. Bézivin and M. Aksit have made an observation that the three-level conjecture can be applied to numerous technologies. The concept of technical space was introduced to identify such technologies [81, 52]. In a technical space, usually a fixed meta-metamodel at Level M3 provides a basis for defining metamodels at Level M2, which, in their turn, define models at Level M1. This chain can be extended by saying that models at Level M1 define objects at Level M0, which are real-world objects or runtime objects of a system being modelled. For instance, UML (Unified Modeling Language) Infrastructure is based on such Four-level Metamodel Hierarchy [#bib_uml_infrastructure, Sections 7.9--7.12]. At the same time, the border between M1 and M0 is where modelling either finishes (when M1 elements describe real objects), or changes its form (when, for example, M1 elements describe data in a database representing real world objects). In accordance with J. Bézivin and I. Kurtev, I will consider Level M0 lying outside the concept of technical space [52].
Having three meta-levels, a technical space must also define the ``conforms to'' relation between them. This relation is defined differently in different technical spaces, but usually there are tools to check this relation. For instance, in the EBNF technical space (from Example B above), the ``conforms to'' relation between M1 and M2 is checked by language parsers.
Technical spaces are not just three meta-levels and the ``conforms to'' relation. J. Bézivin and I. Kurtev say:
The motivation to investigate different technical spaces (TS's) and to support them is driven by the following considerations:
Technical spaces need to store models somewhere. The term model repository (or simply: repository) will denote a store, where models can be saved. It can be a specific data store, a simple text file, or an XML-file. Different types of repositories (even within one TS) have to be accessed differently. In some cases a repository is accessed by means of a specific parser, while in other cases — via certain API (Application Programming Interface).
Table 1 summarizes my research on technical spaces and their repositories.

Table 1: Technical spaces (TS's) and their repositories.
Models are graphs with attributed nodes and labelled edges. Inspired by CDIF [61] and IRDS [21], the MOF standard [66] by OMG is central in this TS. MOF consists of the two main variants: Essential MOF (EMOF) and Complete MOF (CMOF). OMG is working also on Semantic MOF (SMOF), which will contain features not available in MOF TS, but available in the RDF/OWL TS (see below) [67].
EMF/Ecore [15, 98]; Enhanced Model Repository [16]; NetBeans MDR [88]; MOF 2 for Java [12]; MetaMart Metadata Repository [32]; CDO [6]; JR [94]
XML-file [19] XML schema [35, 36] XML meta-schema (XSD.xsd)
Sesame [3]; Virtuoso [11]; OWLIM [26]; OWL API [9]; Apache Jena [2]; JR [94]; AllegroGraph [1]
JGraLab [7] and others

1.3 Linguistic vs. Ontological Metamodelling

While the ``conforms to'' relation holds between a model and its metamodel, there is another relation called ``instance of'', which holds between model elements (objects) and the corresponding metamodel elements (types, or classes). The ``conforms to'' and ``instance of'' relations go between two adjacent meta-levels.
With a help of the ``instance of'' relation it is quite easy to demonstrate, how the need for more than three meta-levels (offered by technical spaces) arises. Douglas Hofstadter in his famous book ``Gödel, Escher, Bach'' (1979) mentions the following example [70]:
  1. (Level n+5 ) a publication
    1. (Level n+4 ) a newspaper
      1. (Level n+3 ) The San Francisco Chronicle
        1. (Level n+2 ) the May 18 edition of the The San Francisco Chronicle
          1. (Level n+1 ) my copy of the May 18 edition of the The San Francisco Chronicle
            1. (Level n ) my copy of the May 18 edition of the The San Francisco Chronicle as it was when I first picked it up (as contrasted with my copy as it was a few days later: in my fireplace, burning)
In this example, an element at Level n+i is instance of the element at Level n+i+1 , i [ 0,1,2,3,4 ] . The question arises how such multiple meta-levels can be put within the three-level conjecture?
Atkinson and Kühne [46, 83, 82] noticed that actually there are two variants of the ``instance of'' relation: ``linguistic instance of'' and ``ontological instance of''. Thus, meta-levels can also be linguistic and ontological. To see the difference between these two types of meta-levels, refer to Figure 1.3. Figure 1.3(a) is an example of UML Four-level Metamodel Hierarchy [#bib_uml_infrastructure]. Although Level M0 (a level of real world objects) lies outside MOF TS, it is depicted for informative purposes. ECore is a possible meta-metamodel for Level M3 (only a small part of it is depicted in Figure 1.3(a)). Level M2 contains a UML-like metamodel described in ECore. For this example it is essential that the M2 Level metamodel is able to describe both classes and objects, see classes Class and Object. Level M1 contains a sample model, which conforms to the UML-like metamodel from Level M2.
All the three levels (M1-M3) are linguistic meta-levels, since the meta-metamodel from Level M3 can be considered a language for specifying metamodels at Level M2, and each metamodel from M2 can be considered a language for specifying models at M1. However, if we look at Level M1 more narrowly, we can see that it can be split into two levels, where UML-style objects occupy one level, and UML-style classes occupy another level (Figure 1.3(b)). The borderline is defined by the ``type'' relation from Level M2. These new levels are called ontological meta-levels. They are denoted O j and O j+1 in Figure 1.3(b), while linguistic meta-levels (M1-M3) have been renamed to L i , L i+1 , and L i+2 . The pivot indices i and j have been introduced here to be independent on any particular absolute numbering. For the purposes of this thesis, only relative arrangement of (both linguistic and ontological) meta-levels will matter.
Figure 1.3(c) adds one more ontological meta-level O j+1 by introducing the MetaClass concept at L i+1 . However, in order to express the six-meta-level example by D. Hofstadter, we must add at least three more meta-classes at L i+1 (in order the total number of ontological meta-levels become six). Figure 1.3(d) shows that instead of introducing meta-class(es), multiple ontological levels can be described by means of the ``type'' relation from Class to Class at L i+1 . This relation can be used as many times as needed, thus, creating a chain of ontological meta-levels as in the example by D. Hofstadter (the ``lowest'' meta-level can be linked to the chain by the ``type'' relation between Object and Class).
In Figure 1.3(d), Class can also be made a subclass of Object at L i+1 (Atkinson and [45] introduce the term ``clabjects'' [from class+object] for such classes). In this case, the ``type'' relation between Object and Class is not needed any more, since its role is played by the ``type'' relation from Class to Class.
In some cases ontological meta-levels can be mixed. In Figure 1.3, a class Person has been added. A person can be linked to a dog by means of the ``owner'' relation defined at Level O j+1 . A person can also be linked to a breed by means of the ``favourite breed'' relation, which crosses levels O j+1 and O j+2 . Having a particular person Peter at O j , we can see that the ``owner'' link lies in the same O j level, while the ``favourite breed'' link crosses two levels O j and O j+1 .
The theory behind the ``instance of'' relation goes even further. , Kaviani, and Hatala show that the (ontological) ``instance of'' relation can be inferred from the two other relations. They suggest to treat each class as consisting of two parts: intentional and extensional [62]. Intentional part specifies common features of objects (e.g., ``has long hair'') and is used for building abstractions; the relation between elements and the intentional part is called ``conformant to''. Extensional part represents a class as a set, to which certain elements (objects) belong; the relation between elements and the extensional part is called ``element of''. For the purposes of this thesis I do not need the ``conformant to'' and ``element of'' relations. Still, I will need both variants (linguistic and ontological) of the ``instance of'' relation.
On the one hand, multiple ontological meta-levels and (usually) the three linguistic meta-levels give power to describe and organize models. On the other hand, it appears that it is difficult for a human to concentrate at more than two meta-levels at a time. While working on a generator for higher order model transformations, where multiple meta-levels are involved, A. Šostaks came to the following conclusion (I call it Šostaks' conjecture):
One of the arguments in favour of this conjecture is as follows. Students learning Java can work with classes and objects easily (two meta-levels are used). Java is an object-oriented language, and it has the Object class, which is a common superclass for all other classes — an easy-to-understand OOP construction. At the same time, Java has the reflection mechanism, which permits considering Java classes as objects. The class named Class has been introduced for that. Actually, it is a meta-class (i.e., it brings an additional meta-level to Java), but represented as an ordinary Java class. At this point students encounter difficulties, since three meta-levels are involved.
Certain RDF/OWL meta-levels can be considered either linguistic, or ontological. In Table 1, RDF can be considered as spanning three linguistic meta-levels: the RDFS level (M3), the RDF vocabulary level (M2), and the RDF individuals level (M1). Still, RDFS permits breaking this level hierarchy, since classes may be individuals at the same time. RDFS also allows meta-levels to be mixed (as in Figure 1.3). The same refers to OWL Full and OWL 2 with RDFS semantics. Thus, we can think of RDF/OWL TS as occupying only two linguistic meta-levels: L 2 containing RDFS/OWL Full definition, and L 1 containing the pool of ontological classes and instances ( L 1 conforms to L 2 ). In this case, L 1 consists of two or more ontological meta-levels, which can be mixed. To deal with different interpretations of meta-levels (whether the given level is linguistic or ontological),

1.4 Organizing Meta-Levels into Quasi-Meta-Levels

Models are usually organized in multiple meta-levels. To deal with numerous meta-levels in a common way, we organize meta-levels into two groups. The first group will contain the fixed (and, thus, read-only) linguistic meta-metamodel (at Level M3) of some technical space. The second group will contain all other meta-levels that are possible in that technical space. The meta-levels from the second group are not fixed.
Example. In the Grammarware technical space, there is a fixed meta-metamodel at M3 called EBNF [20]. EBNF is able to describe grammars at M2 (variable w.r.t. M3), and grammars at M2 are able to describe char sequences at M1 (variable w.r.t. M2). Thus, EBNF belongs to the first group, while grammars (Level M2) and the corresponding char sequences (Level M1) belong to the second group.
I call these two groups the quasi-linguistic meta-level M3 and the quasi-linguistic meta-level M, respectively. The quasi-linguistic level M3 is fixed. In most cases, it will contain the linguistic meta-metamodel of some technical space (hence, the name ``M3''). The level M will contain all other meta-levels that are variable w.r.t. to M3 (either directly, or via other meta-levels). I call these variable levels quasi-ontological meta-levels (in reality, they may be either linguistic, or ontological meta-levels; see below). Figure 1.4 illustrates the organization of quasi-meta-levels. Figure 1.4 is similar to meta-levels depicted in Figures 1.3(c) and (d) on page elsewhere. The difference is that now we have exactly two quasi-linguistic meta-levels.
Such an organization of quasi-meta-levels has the following benefits:

Model Transformations

The concept of model transformation is closely related to the concept of model. A transformation takes some source artefact and transforms it to some target artefact. In a model transformation, at least one of these artefacts is a model.

2.1 Different Types of Model Transformations

A transformation that transforms a model to a model is called a model-to-model transformation (Figure 2.1). Usually, the distinction is being made between the transformation definition (a set of rules that describe how to transform a source model into a target model [78]) and the transformation execution (a process of applying the rules at runtime). While transformation definition lies at Level M2 and is described in terms of the source and target metamodels, transformation execution is performed on models (conforming to those metamodels) at Level M1.
Traditionally, it is considered that some transformation tool is needed to execute a transformation definition [78]. However, it depends on a language, in which the given transformation definition is written. For some languages, transformation definitions can be deployed as precompiled binaries. In this case an additional supporting tool is not required. Here we can see an analogy between a program and its execution, where the program can be executed either by its own, or by a supporting virtual machine or an interpreter. For short, I will use the term transformation to refer to a transformation definition. In this sense, a transformation is like a program, while the source and target metamodels are like source and target data formats.
If the result of a transformation has to be put into the source model (that is, the target model coincides with the source model), then such transformation is an in-place transformation. In-place transformations can be applied, for example, to perform incremental changes (updates) on models.
Generally speaking, transformations can take multiple models as inputs and produce multiple models as outputs. Moreover, these models can lie in different technical spaces.
Besides model-to-model transformations, there are also ``something-to-model'' and ``model-to-something'' transformations. Here, ``something'' can be:
Noteworthily, repositories from Table 1 perform such ``something-to-model'' and ``model-to-something'' transformations, when loading and saving models. These transformations are tailored for storing models and are not applicable for a general case.
In the context of TDA, we can talk also about ``something-to-model'' and ``model-to-something'' transformations, where ``something'' is a graphical presentation or a service.
This subsection presented only basic classification of model transformations. For a more detailed taxonomy of model transformations, refer to works by Czarnecki, Helsen, Mens, and Van Gorp [57, 90, 91].

2.2 Transformation Languages

When OMG introduced MDA in 2001, there were no specific model transformation languages in MOF TS [93, 78]. That is why in 2002 OMG issued a request-for-proposal called MOF QVT (Query/View/Transformation) to seek for MOF-compatible transformation languages [63]. The first version of the MOF QVT standard appeared only in 2008 [64]; the current version is 1.1 (appeared in 2011) [65]. Having the standard, tools that support it are also needed. Currently, MOF QVT is supported by such tools as Eclipse M2M [8] (implementing the QVT Operational and QVT Declarative languages), SmartQVT [10] (QVT Operational), and medini QVT [40] (QVT Relational).
When the MOF QVT standard was in the development stage, many independent transformation languages appeared, and they continue to appear even now. There is a wide variety of transformation languages: textual and graphical, operational and declarative, unidirectional and bidirectional. As a rule of thumb, supporting tools for the given language are developed by the institution that developed the language. Some examples are: ATL [42, 74, 13], the Epsilon family consisting of several languages for different needs [79, 18], MOLA [76, 104], the Lx family [47, 103], lQuery [85], IBM Model Transformation Framework [59], GReAT [41, 72], GreTL [71], Tefkat [84, 29], VIATRA2 [101, 33], PTL [87], BOTL[50, 30], RubyTL [56, 5], etc. Some transformation languages such as COPE [69] and Epsilon Flock [95] are tailored for the model migration task.
It can be noted that ATL, Epsilon and MOLA have certain abstraction layers that allow them to be independent on the underlying model repository. Still, these abstraction layers are different, since they come from different projects.
It is interesting that even before the MOF QVT request-for-proposal, model transformation languages already existed in non-MOF technical spaces. In 1990-ties and in the very beginning of the XX century, the Typed Attributed Graph technical space already had graph transformation languages such as AGG [99, 4], PROGRES [97], TGG/FUJABA [96, 60, 105], and VIATRA [55, 33]. In 1999, XML TS got the standard for the XSLT 1.0 language (Extensible Stylesheet Language Transformations) intended to transform XML documents (the current version is XSLT 3.0, a working draft) [37, 38]. Even stored procedures in the Relational Database technical space can be used to describe transformations on data from database tables. In this thesis by ``transformation languages'' I mean all such transformation languages from all technical spaces (not just from MOF).
Mapping languages can be considered as an abstraction of transformation languages. They can be viewed as specialized (``domain-specific'') languages for specifying model transformations. Instead of directly specifying the instructions how to transform a source model to a target model, a mapping specifies relations between these models, usually, at a higher level of abstraction than transformation definitions do. For instance, with MALA4MDSD, a graphical mapping language developed at IMCS-UL with major contribution by E. Kalniņa [75], a mapping between two UML models can be specified easily. Languages such as D2RQ [49, 14], RDB2OWL [27], R2RML [27], and D2R MAP [48] are mapping languages between two TS's — RDB TS and RDF/OWL TS.
Mappings can be interpreted directly or translated into a lower-level transformation language for execution as ordinary transformations. The latter use-case is related to high-order transformations (HOT's), which are model transformations that perform certain actions on other model transformations. For instance, a HOT can be used for transformation synthesis from mappings (see the paper by M. Tisi et al. for applications of HOT's [100]). HOT's treat model transformations they work with as models conforming to some metamodel representing some transformation language. To provide better support for HOT's, existing transformation languages can be extended, or new languages can be invented. For example, in Template MOLA, a language for defining HOT's, the constructs for what to generate and the constructs for how to generate are expressed graphically in a MOLA-like syntax. There is no need to think about MOLA metamodel and its numerous technical details in order to specify what to generate (that would be necessary, if the ordinary MOLA was used).
In this thesis I assume that the term ``transformation language'' encompasses also mapping languages and languages for defining HOT's.

2.3 Other Languages

In many cases a language that describes a path from one model element to other element(s) is useful. Such languages are called model navigation languages. A well-known navigation language in XML TS is XPath [34]. Microsoft DSL Tools use a similar language [53].
A navigation language can be a part of another language. For instance, the OCL language (Object Constraint Language) from MOF TS has constructs to express navigation between model elements [68]. OCL itself is a constraint language, i.e., a language for expressing constraints on model elements. OCL constraints are being used in Atlas Transformation Language (ATL) [74]. Epsilon Validation Language (EVL) uses constraints that are ``quite similar to OCL constraints'' [17].

2.4 Semantic Reasoners as Model Transformations

Semantic Web is a broadening research area, which is parallel to MDE, but tightly related to it. OWL ontologies and RDF graphs can be considered as models (see RDF/OWL TS in Table 1). Besides, OWL has semantic reasoners — programs that can infer certain data from ontologies. These reasoners can be considered as specialized model transformations that are executed on models from RDF/OWL TS.
Classical types of tasks performed by reasoners are [54]:
Reasoners are based on impressible Math such as description logic. There are various OWL variations, and there is a trade-off between what can be inferred and how fast that can be done (if that can be done at all). For instance, a reasoner for OWL Lite terminates in polynomial time, a reasoner for OWL DL terminates in exponential time, reasoners for certain OWL 2 variations terminate in double-exponential time, while OWL full is undecidable [24]. Examples of commercial reasoners are OntoBroker, and RacerPro. Examples of free reasoners are Pellet (with an option to obtain a commercial license), Fact++, and Hoolet.
Semantic reasoners infer data according to the open world assumption (in contrast to the closed world assumption used, for example, in Prolog). Stefano Mazzocchi explains the difference between both assumption in one sentence [89]:
``[The closed] world assumption implies that everything we don’t know is false, while the open world assumption states that everything we don’t know is undefined.''
The closed world is based on the ``negation as failure'' principle, while the open world is based on the ``negation as contradiction'' principle [102]. An OWL ontology can be processed by a semantic reasoner according to the closed world assumption by adding some additional OWL statements that ``close'' the world of the ontology.
In this thesis, semantic reasoners will be considered as in-place transformations that append existing models with inferred data. The main difference from ordinary model transformations is that a reasoner implements a set of predefined model transformations (like from the list above). Reasoners are usually written in third generation programming languages (3GLs) and are deployed in a binary form. The reasoning process can be ruled only in a declarative way by means of data stored in an ontology. Thus, no specific transformation language is needed in this case.


1"AllegroGraph RDFStore Web 3.0's Database".
2"Apache Jena".
3"Sesame home page".
4"The Attributed Graph Grammar System: A Development Environment for Attributed Graph Transformation Systems".
5"The Agile Generative Environment (AGE) project".
6"The CDO Model Repository".
7"The Java Graph Laboratory (JGraLab) project".
8"The Model To Model (M2M) project, a subproject of Eclipse Modeling Project".
9"The OWL API".
10"The SmartQVT project".
11"Virtuoso Open-Source Edition".
12"A Meta-Modelling Technology for CMOF-based Models".
13"ATL --- a model transformation technology, an Eclipse Model-to-Model Transformation project".
14"D2RQ: Accessing Relational Databases as Virtual RDF Graphs".
15"Eclipse Modeling Framework (EMF, Eclipse Modeling subproject)".
16"Enhanced Model Repository".
17"Epsilon Validation Language".
18"Epsilon, an Eclipse Model-to-Model Transformation project".
19"Extensible Markup Language (XML) 1.1 (Second Edition)".
20"Information technology - Syntactic metalanguage - Extended BNF".
21"Information technology -- Information Resource Dictionary System (IRDS) Services Interface (ISO/IEC 10728:1993 standard)".
22"LINQ (Language-Integrated Query)".
23"OWL 2 Web Ontology Language Document Overview (Second Edition)".
24"OWL 2 Web Ontology Language Profiles (Second Edition)".
25"OWL Web Ontology Language Reference".
26"OWLIM Semantic Repository".
27"R2RML: RDB to RDF Mapping Language".
28"Resource Description Framework".
29"Tefkat: The EMF Transformation Engine".
30"The BOTL (Bidirectional Object-oriented Transformation Language) project".
31"The GrGen.NET project".
32"The InfoLibrarian Universal MetaMart Metadata Repository".
33"VIATRA2 (VIsual Automated model TRAnsformations) framework, an Eclipse project".
34"XML Path Language (XPath), Version 1.0".
35"XML Schema Definition Language (XSD) 1.1 Part 1: Structures".
36"XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes".
37"XSL Transformations (XSLT), Version 1.0".
38"XSL Transformations (XSLT), Version 3.0 (a working draft)".
39"Encyclopædia Britannica. Encyclopædia Britannica Online Academic Edition.", Encyclopædia Britannica Inc. (2012).
40IKV++ Technologies AG, "The medini QVT project".
41Aditya Agrawal and Gabor Karsai and Feng Shi, "Graph Transformations on Domain-Specific Models", Institute for Software Integrated Systems, Vanderbilt University (2003).
42F. Allilaire and T. Idrissi, "ADT: Eclipse Development Tools for ATL", in Proceedings of Second European Workshop on Model Driven Architecture (, 2004).
43Scott Ambler, "Mapping Objects to Relational Databases: O/R Mapping In Detail".
44K. Anuja, Object Relational Mapping (Cochin University of Science and Technology, 2007).
45Colin Atkinson and Thomas Kühne, "Meta-level Independent Modelling", in International Workshop on Model Engineering at 14th European Conference on Object-Oriented Programming (, 2000).
46Atkinson, Colin and Kühne, Thomas, "Model-Driven Development: A Metamodeling Foundation", IEEE Software 20, 5 (2003), pp. 36--41.
47Barzdins, Janis and Kalnins, Audris and Rencis, Edgars and Rikacovs, Sergejs, "Model transformation languages and their implementation by bootstrapping method", in Avron, Arnon and Dershowitz, Nachum and Rabinovich, Alexander, ed., Pillars of computer science (Berlin, Heidelberg: Springer-Verlag, 2008), pp. 130--145.
48Christian Bizer, "D2R MAP - Database to RDF Mapping Language and Processor".
49Christian Bizer and Andy Seaborne, "D2RQ -- Treating Non-RDF Databases as Virtual RDF Graphs", in Proceedings of the 3rd International Semantic Web Conference (ISWC 2004) (, 2004).
50Peter Braun and Frank Marschall, "BOTL: The Bidirectional Object Oriented Transformation Language", Institut für Informatik der Technischen Universität Munchen (2003).
51Jean Bézivin, "About model transformations" (2010).
52Jean Bézivin and Ivan Kurtev, "Model-based Technology Integration with the Technical Space Concept" (2005).
53S. Cook and G. Jones and S. Kent and A. C. Wills, Domain-Specific Development with Visual Studio DSL Tools (Addison-Wesley, 2007).
54Fulvio Corno and Laura Farinetti, "Logic and Reasoning in the Semantic Web (part II -- OWL)" (2012).
55Csertán, György and Huszerl, Gábor and Majzik, István and Pap, Zsigmond and Pataricza, András and Varró, Dániel, "VIATRA: Visual Automated Transformations for Formal Verification and Validation of UML Models", in Proceedings of the 17th IEEE international conference on Automated software engineering (Washington, DC, USA: IEEE Computer Society, 2002), pp. 267--.
56Cuadrado, Jesús and Molina, Jesús and Tortosa, Marcos, "RubyTL: A Practical, Extensible Transformation Language", in Rensink, Arend and Warmer, Jos, ed., Model Driven Architecture -- Foundations and Applications vol. 4066, (Springer Berlin / Heidelberg, 2006), pp. 158-172.
57Czarnecki, K. and Helsen, S., "Classification of model transformation approaches", in Proceeding of OOPSLA03 Workshop on Generative Techniques in the Context of Model-Driven Architecture (, 2003).
58John Daintith and Edmund Wright, ed., A Dictionary of Computing (Oxford University Press, USA, 2010).
59Sebastien Demathieu and Catherine Griffin and Shane Sendall, "Model Transformation with the IBM Model Transformation Framework" (2005).
60Fischer, Thorsten and Niere, Jörg and Torunski, Lars and Zündorf, Albert, "Story Diagrams: A New Graph Rewrite Language Based on the Unified Modeling Language and Java", in Selected papers from the 6th International Workshop on Theory and Application of Graph Transformations (London, UK, UK: Springer-Verlag, 2000), pp. 296--309.
61Rony G. Flatscher, "An Overview of the Architecture of EIA's CASE Data Interchange Format (CDIF)".
62Gašević, Dragan and Kaviani, Nima and Hatala, Marek, "On Metamodeling in Megamodels", in Engels, Gregor and Opdyke, Bill and Schmidt, Douglas and Weil, Frank, ed., Model Driven Engineering Languages and Systems vol. 4735, (Springer Berlin / Heidelberg, 2007), pp. 91-105.
63Object Management Group, "MOF 2.0 Query / Views / Transformations RFP" (2002).
64Object Management Group, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, Version 1.0" (2008).
65Object Management Group, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, Version 1.1" (2011).
66Object Management Group, "OMG Meta Object Facility (MOF) Core Specification Version 2.4.1" (2011).
67Object Management Group, "MOF Support For Semantic Structures (SMOF)" (2012).
68Object Management Group, "Object Constraint Language (OCL), Version 2.3.1" (2012).
69Herrmannsdoerfer, Markus and Benz, Sebastian and Juergens, Elmar, "COPE -- Automating Coupled Evolution of Metamodels and Models", in Proceedings of the 23rd European Conference on ECOOP 2009 --- Object-Oriented Programming (Berlin, Heidelberg: Springer-Verlag, 2009), pp. 52--76.
70Hofstadter, D.R., Gödel, Escher, Bach: an eternal golden braid (Harvester Press Ltd., 1979).
71Horn, Tassilo and Ebert, Jürgen, "The GReTL transformation language", in Proceedings of the 4th international conference on Theory and practice of model transformations (Berlin, Heidelberg: Springer-Verlag, 2011), pp. 183--197.
72Institute for Software Integrated Systems, Vanderbilt University, "The Graph Rewrite And Transformation (GReAT) tool suite".
73Edgar Jakumeit and Sebastian Buchwald and Moritz Kroll, "GrGen.NET", International Journal on Software Tools for Technology Transfer (STTT) 12, 3 (2010), pp. 263--271.
74Jouault, Frédéric and Kurtev, Ivan, "Transforming models with ATL", in Proceedings of the 2005 international conference on Satellite Events at the MoDELS (Berlin, Heidelberg: Springer-Verlag, 2006), pp. 128--138.
75Elina Kalnina, Model Transformation Development Using MOLA Mappings And Template MOLA (University of Latvia, 2011).
76Kalnins, Audris and Barzdins, Janis and Celms, Edgars, "Model Transformation Language MOLA", in Model Driven Architecture vol. 3599, (Springer Berlin Heidelberg, 2005), pp. 62--76.
77Steven Kelly, "The Model Repository: More than just XML under version control" (2008).
78Kleppe, Anneke G. and Warmer, Jos and Bast, Wim, MDA Explained: The Model Driven Architecture: Practice and Promise (Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003).
79Dimitrios Kolovos and Louis Rose and Richard Paige, "The Epsilon Book".
80Kozlovics, Sergejs, "The Orchestra of Multiple Model Repositories", in SOFSEM 2013: Theory and Practice of Computer Science vol. 7741, (Springer Berlin Heidelberg, 2013), pp. 503-514.
81I. Kurtev and J. Bézivin and M. Aksit, "Technological Spaces: An Initial Appraisal" (2002).
82Kühne, Thomas, "Clarifying matters of (meta-) modeling: an author's reply", Software and Systems Modeling 5 (2006), pp. 395-401.
83Kühne, Thomas, "Matters of (Meta-) Modeling", Software and Systems Modeling 5 (2006), pp. 369-385.
84Lawley, Michael and Steel, Jim, "Practical declarative model transformation with Tefkat", in Proceedings of the 2005 international conference on Satellite Events at the MoDELS (Berlin, Heidelberg: Springer-Verlag, 2006), pp. 139--150.
85Liepiņš, Renārs, "Library for model querying: IQuery", in Proceedings of the 12th Workshop on OCL and Textual Modelling (New York, NY, USA: ACM, 2012), pp. 31--36.
86Ludewig, Jochen, "Models in software engineering -- an introduction", Software and Systems Modeling 2 (2003), pp. 5-14.
87M. Almendros-Jiménez, Jesús and Iribarne, Luis, "A Model Transformation Language Based on Logic Programming", in Emde Boas, Peter and Groen, FransC.A. and Italiano, GiuseppeF. and Nawrocki, Jerzy and Sack, Harald, ed., SOFSEM 2013: Theory and Practice of Computer Science vol. 7741, (Springer Berlin Heidelberg, 2013), pp. 382-394.
88Martin Matula, "NetBeans Metadata Repository".
89Stefano Mazzocchi, "Closed World vs. Open World: the First Semantic Web Battle" (2005).
90Mens, Tom and Van Gorp, Pieter, "A Taxonomy of Model Transformation", Electron. Notes Theor. Comput. Sci. 152 (2006), pp. 125--142.
91Tom Mens and Krzysztof Czarnecki and Pieter Van Gorp, "A Taxonomy of Model Transformations", in Proc. Dagstuhl Seminar on "Language Engineering for Model-Driven Software Development". Internationales Begegnungs- und Forschu… (Electronic, 2005).
92MetaEdit+, "".
93Miller, J. and Mukerji, J., "MDA Guide, Version 1.0.1" (2003).
94M. Opmanis and K. Čerāns, "Multilevel Data Repository for Ontological and Meta-modeling" (2011).
95Rose, Louis M. and Kolovos, Dimitrios S. and Paige, Richard F. and Polack, Fiona A. C., "Model migration with Epsilon Flock", in Proceedings of the Third international conference on Theory and practice of model transformations (Berlin, Heidelberg: Springer-Verlag, 2010), pp. 184--198.
96Andy Schürr, "Specification of Graph Translators with Triple Graph Grammars", in Ernst W. Mayr and Gunther Schmidt and Gottfried Tinhofer, ed., WG vol. 903, (Springer, 1994), pp. 151-163.
97Schürr, A. and Winter, A. J. and Zündorf, A., "The PROGRES approach: language and environment", in Ehrig, H. and Engels, G. and Kreowski, H.-J. and Rozenberg, G., ed., Handbook of graph grammars and computing by graph transformation (River Edge, NJ, USA: World Scientific Publishing Co., Inc., 1999), pp. 487--550.
98D. Steinberg and F. Budinsky and M. Paternostro and E. Merks, EMF: Eclipse Modeling Framework, 2nd Edition (Addison-Wesley, 2008).
99Taentzer, Gabriele, "AGG: A Tool Environment for Algebraic Graph Transformation", in Proceedings of the International Workshop on Applications of Graph Transformations with Industrial Relevance (London, UK, UK: Springer-Verlag, 2000), pp. 481--488.
100Tisi, Massimo and Jouault, Frédéric and Fraternali, Piero and Ceri, Stefano and Bézivin, Jean, "On the Use of Higher-Order Model Transformations", in Paige, Richard and Hartman, Alan and Rensink, Arend, ed., Model Driven Architecture -- Foundations and Applications vol. 5562, (Springer Berlin / Heidelberg, 2009), pp. 18-33.
101Varró, Dániel and Balogh, András, "The model transformation language of the VIATRA2 framework", Sci. Comput. Program. 68, 3 (2007), pp. 187--207.
102Michael Zakharyaschev, "Reasoning with OWL. Open vs closed worlds. Constructors.".
103Institute of Mathematics and Computer Science, University of Latvia, "The Lx transformation language set home page".
104Research Laboratory of Modeling and Software Technologies of Institute of Mathematics and Computer Science, University of Latv…, "The MOLA project".
105Fujaba Development Group - University of Paderborn, "Incremental Model Transformation and Synchronization with Triple Graph Grammars" (2006).