arize the main dif- ferences: All entity symbols are domain specific. All relation symbols are domain specific, i.e., no user-defined relations are allowed. Therefore, the modeller need not add any text or code to explain what is meant with a particular relation. The excess of textual annotations that charac- terizes models in common-value languages is thereby avoided. The need for the general relation is_part_of is eliminated by graphically includ- ing entities that are part of another entity in the latter. The need for the general relation belongs_to_the_type/class is eliminated by using domain-specific graphical symbols for entities and relations. Obviously, an added-value modeling language will have to define more graphi- cal symbols than a common-value language, which could be an argument against it. For example, in the very early proposal for AMLn, the author did use an excess of network-specific symbols, in order to allow for models with high semantic preci- sion. This is counterproductive, however, since a well known fact is that humans have a short memory span that cannot cope with more than something in the range of 5-9 concepts (in this case: symbols) at the same time. For most system domains, this is a tough challenge to the language designer. For the case of AMLn, the author has solved this problem as follows: 1. Carefully analyse and select the minimum set of concepts and relations that are used in all network systems. 2. A specialization that cannot be included in the range of symbols can always be defined by attributes of an entity or a relation. 3. Define a set of model types ("views"), each set using only a small part of the complete set of symbols. 4. More important, most entity types are not defined by symbols of their own, but indirectly by the type of relation they have. Figure 1.4 gives some examples of this approach. Five entity types are used here, relying on only two entity sym- bols (AMLn defines only two entity symbols: a squared shape, denoting the general entity type node, and a roun