Discussed the need for multiple visual notations at the metamodeling level. Currently, metamodeling tools support multiple visual formalisms at the modeling level through metamodeling. However, at the metamodeling level, only a single formalism (and the associated visual-notation) are supported : e.g: ER for Atom3 and Class Diagrams for GME. In order to support true end-user programmability, the modeling environment needs to support the use of multiple visual formalisms at the metamodeling level as well. How can these be assigned a meaningful semantics?? Is there a point in doing this? Why is this useful? These innocent questions led (as usual) to some wicked questions ...

How the Activity of Modeling differs from Traditional Programming
The problem seemed apparently clearer with traditional programming languages. Why? The simplicity is due to the fact that all programs (models of traditional programming languages) are assigned only an operational semantics by immediately mapping on to a model of computation. The "meaning" of a program is never discussed, it is only assigned meaning in so far as specifying "how to run it". "what happens when you run it" is anybody's guess.

The need for Prototypes
Thus, we are given a running system, which is, by virtue of the fact that it is running, is a model of computation, and we use this to simulate new systems that offer a different interface to this same system. In this manner, all traditional languages are implicitly prototype based, in that all programs are a specialization of the prototypical computational process that is always in execution. What the process is doing is beyond the scope of the programming language. It only specifies how the process being modeled by the program can be constructed by specializing the prototypical computational process.

Parallels to Constructivism
This is also the essence of a constructivist model of the universe. What constructivists say, is that since we know that "what something is" cannot be formally specified in a complete and consistent way for all things (a la Godel), we instead content ourselves with specifying "how something can be constructed" as a reasonable approximation for "what something is".

Fundamental Axiom of Modeling?
As modelers, however, we would like (preferably without trespassing any theoretical limits) for the "meaning" of a model to be formally specified. And what is the meaning of this? This means we try and establish an equivalence between the model and another model for which the meaning is agreed upoun by a majority of us (a denotational semantics), possibly practioners of some common art (domain experts). Thus, we are not saying that the meaning of a model is specified, but that the equivalence of meaning with respect to another model is specified.

Domain Specificity and the Fundamental Axiom of Modeling?
The usefulness of a denotational semantics is thus incumbent upoun the existence of a core set of models whose meaning is well defined, to the extent that it is agreed upoun by a large number of people.

The Fundamental Axiom of Metamodeling?
This brings us, naturally to the next question. Assuming that this core set exists for each domain, how do we represent the models in the core set themselves? We have postponed the question of assigning meaning to the models so far, and we cannot postpone it any further. At this point, we resort to the prototypical computation and specialize it to create the core set models. We must remember, however, that using the prototypical computation to create the core set models doesn't give them meaning. It does not specify what they "are". This meaning exists only in the mind of the modelers. What the system facilitates, is merely the mechanism to create objects whose behaviour simulates the objects in the mind of the modelers. Thus the fundamental axiom of metamodeling can be simply stated thus: The problem of representing the core set using a formal axiomatic system is, at best, intractable, and at worst, undecidable. However, systems can be created to make it easier for outside observers of the system to deduce the intended meaning of the core set and to use this information to make design decisions

Implications for the Requirements Engineering of a Metamodeling Tool.
It can thus be argued that the core activity of modeling is to create systems with which the "common core" models can be created, transformed, specialized, composed/reused and most importantly, reasoned about. The features that support the ability to reason about the system are most valuable because of the fundamental axiom of metamodeling: the meaning of the core set is unspecifiable. Thus, there is always a possibility of discovering new properties of the represented system using the representation. The virtue of the modeling system lies in the operations it supports to enable the modeler to discover these features, and to create representations of the new features discovered, and so on and so forth, ad infinitum.

The Case for Domain Specific Visual Metamodeling.
What are the operations a tool needs to support to make it easier to reason about representations? The answer is obvious: it depends on the domain. Take the case of audio signal processing - one of the class-objects in the core-set is the hierarchical signal flow graph class. This class-object (call it TSignalFlow) represents a very large set of objects. The core activity of an audio signal processing expert is to identify subsets of this class that are useful for particular signal processing tasks. E.g: low pass filters, high pass filters, band pass filters. Even more interesting are custom filters designed, for example to boost a particular frequency range for some give room.
How do audio signal processing experts arrive at these filter graphs?

Generalizing the syntax of the Metamodeling Formalism.
Given that the fundamental activity of metamodeling involves reasoning about large, complex sets, and creating new large, complex, subsets of the sets being reasoned about, can we arrive at a common core of "operations on types" that are tailored for the specific purpose of facilitating "thought experiments" on the type? This is consistent with the larger of goals of modeling and simulation in general, which is of complementing thought experiments and reasoning with simulation.
This is also consistent with the freedom that traditional programming languages gave us by allowing us to make up for our disability to say "what something is" precisely, with our ability to construct an object, and generalizes this notion to the realm of types, where we can make up for our disability to define a sub-type in it's entirety by using a computer augmented deductive system to construct the sub-type (sub set) incrementally so as to satisfy all the properties that we would like it to posses.

Interaction with Sets
A first take on the operations that a visual metamodeling environment needs to support to ease the creation of subsets is to define how the modeler can interact with a class-object (set). The details of the visual interaction with the set is left as part of the metamodel of the domain, but they must support the basic operations.