Getting rid of Meta …

We’re currently doing a major cleanup and revision of the APIs of the DSL Tools.  An aspect of this is a systematic renaming so that the API is a better match to the concepts we are dealing with.  One thing we decided to do is get rid of the Meta… prefix altogether.

In my experience around UML and MOF, the Meta… prefix causes endless confusion, especially the concept of a “meta-instance”: M3 is an instance of M4, M2 is an instance of M3, and so on.  I became notorious for insisting that “M0 is a fiction”.

The issue here is the relationship between a model, and the stuff that it is a model of; and what this has to do with building a model of the concepts of a modelling language.

Sometimes people say “a metamodel is a model of a model”.  This is simply wrong.  If X is a model of Y, then X systematically represents Y for some purpose, leaving out unnecessary detail. That is not the relationship between a metamodel and a model.

Sometimes people say “a model is an instance of a metamodel”.  This begs the question of what it means to be an instance of a model.  If I have a model of a program, what is an instance of that model?  A copy of the source code? The DLL?  The DLL loaded into memory? An execution of the program? A stacktrace?  A mathematical model of the program’s semantics? It is an ill-defined concept.

So, to avoid all of this (which in any case reminds me of the issue of how many angels can dance on the head of a pin), we decided to call the models of the concepts in our DSLs Domain Models; which contain Domain Classes, Domain Relationships, Domain Properties, Domain Roles and so on.  These models are used to generate tools, and serialized in files.  We also have a model which we use to generate the tool and formats that we use to manipulate Domain Models – we call this the Domain Model Domain Model, or DMDM.

Comments (9)

  1. Martijn Iseger says:

    Likely you will now get confusion on what you mean with "domain" 🙂

  2. Andrey says:

    So, what in your view is the relationship between the metamodel and a model? Oh, BTW how different is the "metamodel of the metamodel" from the "metamodel of a model"?

  3. A metamodel specifies the concepts of the language in which the model is defined.

    — Steve

  4. Greg Nordstrom says:

    As someone who has taught and presented these concepts for several years now, I agree that "meta" is quite overloaded. But a name change won’t be enough–as Martijn notes–since there’s still a need to communicate the what belongs on each side of the dividing line between the model of a particular DS language (i.e. the model which defines the language’s syntax and semantics–both static and dynamic) and expressions of real-world systems created using that language.

    I see a familiar pattern here, where Microsoft feels the need to redefine things–sometimes to good effect (e.g. when the field contains loosely coupled and overloaded terms), but other times only for the sake of product branding. Let’s hope the VS2005 DSL project represents the former…

  5. David Robinson says:

    A modeler is a tool that makes models. A metamodeler is a tool that makes modelers.

  6. Jos Warmer says:

    Hi Steve, does this mean that a global replace of "meta" by "domain" will do the job? I agree that this will resolve some confusion, but I do agree with Martijn that "domain" will cause confusion. People are already cofusing business domains and technical domains and will now have "meta-(sorry to use the word)-domains" to worry about as well. Let’s hope the change in terminology helps.

  7. I had a conversation at breakfast today during which all of the following words were used: model, metamodel, domain model, metalanguage, and domain language. We do need to resolve some confusion. In response to Stefan Tilkov ( ): a domain model specifies the concepts of a domain-specific language.

  8. Jan Hendrik Hausmann says:


    some of the questions on meta-ness you raised can be attributed to the difference between type and token model as elaborated by Thomas Kühne (see I think these central issues ("what is an instance of what in which sense") need to be clarified, not obscured by yet another name change.

  9. Colin Chambers says:

    Another thing you might consider getting rid of is "model". A model is incomplete. However when you define something in a DSL you are not, in general, leaving anything out (assuming the syntax and semantics of the DSL are well-defined). For example if the domain of the DSL is user interfaces then a definition of something in the DSL is an executable definition of a user interface, not a model of a user interface. If the DSL is a mark-up language for documents then a definition in the DSL is a renderable definition of a document, not a model of a document. If the domain is DSLs then a representation in the [DSL]DSL is a complete definition of the syntax and semantics of a DSL, not a model of a DSL. There might be two different DSLs targetting the same domain. In that case you could have two different representations of the same domain thing (where a representation is an expression in a DSL). The representations are different from the thing. That does not make them models, though. The representations are complete, unlike models. A recipe in English for Aunt Jane’s muffins and a recipe in Spanish for Aunt Jane’s muffins are two representations of the same recipe, not two models of the same recipe.