from http://www.metamodel.com/staticpages/index.php?page=20021010231056977
Introduction
About ten years ago, it was fairly clear what metamodeling was. The community of practitioners was small, everyone knew everyone, and while this community — like many metamodelers — seemed to like to follow the principle "it is best to disagree", they agreed at least what metamodeling was.
As with many efforts, as this new technology of metamodeling found wider adoption, this consensus weakened. In more recent years, with the rise of the internet, and the rise of some intensely marketed "meta" products of various sorts, that consensus has weakened somewhat. Further, some communities of practice that used to be entirely separate, and working in very different industries (from ship building over electronics to software, for example) discovered that what they were doing in their domains were really the same activity. Some of them called that metamodeling. Others called it other things, such as semantic modeling, simply schema creation, or even domain standardization. This cross-pollination of terms and concepts has further muddled the waters.
Unfortunately, even the word at the very core of metamodeling, the term "meta" has never quite found a generally accepted meaning.
We are trying to give you some background information who and where and why so you can find your way through this maze of different mindsets and terms. Why? Because it's becoming important, more and more so. Read on as we explore these issues on this and other pages on this site.
Disclaimer: there may be differences in opinion here, this one is ours. But you are welcome to use the facilities on this site to comment and express your own view.
Attempt at a Definition of the Term "metamodel"
A metamodel is a precise definition of the constructs and rules needed for creating semantic models.
(See also the Q&A section of this site).
What is metamodeling, and what is a metamodel good for?
Let's start with the obvious first: metamodeling is an activity. This activity produces, among other things, metamodels.
Metamodeling is a close relative to modeling, such as object-oriented modeling, or even climate modeling in that it produces models — well, metamodels — which are an attempt at describing the world around us for a particular purpose.
The two key phrases in the preceding sentence are "an attempt at describing the world" and "for a particular purpose".
Why are these phrases important? Because just like there is never, ever, going to be the definitive climate model that describes the climate perfectly so you know whether it is going to be sunny on Thursday afternoon five years from now, there is never going to be a perfect metamodel. Climate models are successive approximations, as are metamodels. Which raises an important issue of metamodel maintenance and migration, but more about that later.
It's also important to understand that metamodels are always made for a particular purpose. Do not ever attempt to use a metamodel without understanding the particular goal that the authors had in mind when they created the metamodel. Again the analogy with the climate model can help: just like there are different climate models for long-term climate change (e.g. to predict the effect of greenhouse gases over the next 100 years), and for the prediction of the Thursday afternoon weather on your porch, metamodels of the same subject are very likely going to be different if they have been created for different purposes. If someone claims they aren't, ask them to explain why there must be different climate models, but not metamodels, in their view (and then post the answer you get on this site — maybe we can all learn something, good or bad).
So what are those metamodels good for? Well, this depends on the purpose for which any given metamodel was developed for in the first place. Common purposes for metamodels are:
As a "schema" for semantic data that needs to be exchanged. This is where much of metamodeling has its roots: CDIF, for the interchange of CASE tool data (and UML/XMI later), STEP, for the exchange of industrial design data, and even XML Schema.
Closely related is the use of Metamodels as a schema for semantic data that needs to be stored, in a repository, for example.
As a language that supports a particular methodology or process, which was the original purpose of the UML metamodel. (Note that later, it also became used for the purposes of data exchange and storage, which lead to various problems in the metamodel that needed to be fixed, illustrating the point of "particular purpose" made earlier).
In this case, a metamodel allows a language designer or methodologist to better capture, analyze and understand what they are actually writing about in all those methodology books.
As a language to express additional semantics of existing information. One example is to make information on the web more computable. This is a big focus area of the emergine "Semantic Web".
Semantics
Now I said it, the dreaded word. "Semantics". The notion of semantics is very important to metamodels. Its use often gets people rolling their eyes, although the term "meta", in particular in a phrase like "metameta" tends to accomplish this much more safely. Nevertheless:
The term "semantic" reflects the need to not only model something in the real world, but to model the meaning that this something has for the purpose of the metamodel. Ah! That meaning is of course somewhat in the eye of the beholder, and it clearly depends on the purpose of the metamodel (which is one of the reasons we were talking about the purpose of a meta-model up front).
A simple drawing tool like is a good example to illustrate this. If you draw a box in such a tool, the tool understands that this is a box. Well, it has to, otherwise it wouldn't know whether it was supposed to draw a box or a circle. So from the perspective of the drawing tool, the semantics are "box on screen" (with such-and-such coordinates, color, etc.). But if you are using this drawing tool as a tool to document a company workflow, for example, as many people do, then "box on screen" is not the meaning you have in mind when you look at the diagram. You think: the meaning of what you just drew was "front-office process".
So the drawing tool and you look at the exact same information, and come up with very different opinions as to the meaning of what is on the screen. And that means that the metamodel you have in mind is a very different one than the drawing tool would have in mind, if it had a mind (well, it's hard-coded into the software). Now imagine two metamodelers who do not agree on the purpose of a certain metamodel comparing notes. There will be hardly overlap. The "drawing tool metamodel" will say: Box, Line, Circle, Diagram, etc. etc., while the "workflow metamodel" will say: Process, Transition, Participant, etc.
So in this roundabout way, we have actually introduced the notion of a metamodel: A metamodel is the collection of "concepts" (aka things, terms, ...) that are the vocabulary with which you are talking about a certain domain. Such as Box, Line, Circle, Diagram, or Process, Transition etc.
Because it is all about precising meanings, so understanding can be created, it's important that we are precise when we try to define those meanings. That's why metamodels typically are — and always should be — built according to a strict ruleset, which in most cases is derived from a version entity-relationship-attribute or object-oriented modeling.
Here are some traditional types of users for meta-models
1. CASE tool vendor / modeling tool vendor
For example, as a modeling tool vendor you may face this customer requirement to not only support Classes as you did in your object analysis and design tool, but also Interfaces as distinct concepts. Your chief architect will carefully examine this requirement by looking at how this new concept relates to other concepts that are already supported by your tool, and how the data structures of the tool need to be changed to be able to capture information about interfaces.
In essence, what the chief architect does is extending the metamodel, whether or not he calls it that way, or has even heard the word. The data structures in the tool are the physical representation of the metamodel.
2. Repository vendor
For example, you may sell a repository (or database, or directory, ...) to customers who want to store software/systems development information in it. They may call it "metadata". In order to store any software/systems engineering artifacts in a repository, you need to have a schema (just like a database needs to have a schema). Metamodels are often used as the conceptual schema for repositories.
Most metamodels tend to be on a conceptual level, rather than a logical or physical level (or anything else), because good metamodels tend to stay away from considerations of implementation technology. So expect having to go through a conceptual-to-physical datamodeling mapping exercise, but that is typically a straightforward process. Metamodel vendors can usually not do this for you, because your physical schema tends obviously depends on the type of repository that you are using (relational, object-relational, object-oriented, XML, etc.)
3. Systems integrator
Systems integrators are often hired, well, to integrate systems. One the first activities in such a project often is to understand the meaning of the data in all the systems that need to be integrated: which data has the same meaning, which data is complementary, and how everything relates. Performing this analysis yields a semantic model for the types of data to be integrated, in other words, a metamodel. Often, such analysis can be dramatically shortened and improved by working from available metamodels for the domain under consideration.
Ask your systems integrator about what role metamodeling will play in the project that they are proposing.
4. End user
As an end user, how do you evaluate software? If you have multiple packages that you could buy, how do you determine which one is the most powerful? Functionality is one aspect ("this one has a nice shiny button over here"), but the supported metamodel is even more important. After all, the metamodel determines what you can express with the software — and all the shiny buttons in the world don't help you if you cannot distinguish between as many customer categories as you need, for example.
If you have the time, metamodeling comes in handy to help with a thourough analysis. This is similar to asking to see the database scheme of the product, but on a conceptual rather than physical, optimized and maybe denormalized level.