The research presented in this article demonstrates initial parts of a specification mechanism for visual representation of conceptual model content that aims to provide a higher-level declaration mechanism for concrete model syntax. The presentation focuses on an example application, that demonstrates parts of the language without offering a complete description of all language features. The remainder of Section I introduces selected language features of the approach, which are subsequently applied in Section II to an example that specifies a visual representation for a given conceptual model about the bicycle product domain. Other scientific work which is related to the presented considerations is considered in Sect. III, and a conclusion in Sect. IV summarizes the discussed ideas.

The Topology Type Language (TTL) is being developed to serve the purpose of specifying visualizations of diverse kinds for models. It is intended to describe model representations of various visual forms, such as diagrams or graphical user interfaces, together with corresponding human interactions. Especially, the TTL is being developed as an advanced specification formalism for concrete syntaxes of domain-specific modeling languages. Among others, it offers three central characteristics which go beyond the state-of-the-art of conventional concrete syntax specification mechanisms:

1) The description of a visualization happens entirely independent from a model, i. e., the visualization can be defined without restrictions imposed by the meta-model of the visualized language.

2) The specification mechanism can refer to meta-models with multiple type levels. It describes a notion of instantiating topology types in multiple refinement steps which can be mapped to the conceptual type-level hierarchy of a multi-level meta-model. 3) The approach provides a visual formalism to describe topologies. Although the description of topologies is an abstraction over a visualization and does not describe the visualization itself, the use of a visual language to specify topologies appears appropriate as it promises a higher level of cognitive efficiency and advanced easeof-use than a textual formalism.

The term "topology" has been chosen as part of the name to indicate a level of conceptual abstraction, which on the one hand uses visual constructs that express meaning with spatial patterns and locations, and on the other hand does not denote the resulting visualization itself, but a reflective abstraction about it. Figure 1 shows an example TTL model which will further be introduced in the use case demonstration in Section II. Fig. 1: Example visualization specification for a bike product type Some central considerations that have guided the development of the TTL are briefly described in the following.

1) Decoupling Visualization Description from Conceptual Description: It is a major shortcoming of existing approaches such as the Eclipse Graphical Modeling Framework (GMF) [8], that the use of different types of conceptual elements can pre-determine the visual structure and composition of the graphical syntax. Some line connectors, or nesting elements inside each other, can only be used in combination with fixed meta-model concepts. For example, a visual nesting, in which elements are placed inside an outer element, requires the meta-model to contain a composition relationship between the nested concepts. To the contrary, the use of lineconnectors demands for non-containment associations between the classes of the connected elements in the meta-model. Such connectors thus cannot be used to visualize associations that are considered to be compositions from a conceptual point of view -although the decision whether to model a relationship as an association or as a composition may be contingent in the modeled domain, and should not influence the shape of possible visualizations that can be specified as concrete syntax.

As a consequence, it turns out to be necessary for a specification mechanism for model visualizations, to introduce a layer with intermediary specification concepts, which serves to decouple the structure of the described visualizations from the structure of the meta-model that is underlying to the (domain-specific) conceptual language the concepts of which are visualized. The approach provided with the TTL does so by abstracting visualizations to topologies, which can initially be described without any references to a modeling language and its instances, and only at a later stage during the specification of the visualization are bound to concrete model instances. This binding happens by specifying conceptual relations that query content from model instances and may feed back modified content into the model. A default way to specify conceptual relations can be realized by incorporating an existing expression language into the TTL specification approach.

2) Instantiation by Copy-and-Complete Semantics: The specification language supports a notion of Abstract Areas versus Concrete Areas, and in addition allows to specify a sequence of Completion Steps that constrain how an Abstract Area is supposed to be transformed to a Concrete Area, in order to make it visually renderable. Among other linkages to multi-layer or multi-step application contexts, these constructs in combination allow to reflect a notion of topology types which over multiple levels of abstractions get instantiated to a concrete topology. As this procedure is applied to a visual formalism, it makes sense to describe the differences between types and instances in terms of missing versus provided elements, which is why an operational copy-and-complete semantics seems appropriate to describe a visual type system.

Following such a copy-and-complete procedure, the transformation from abstract to concrete topology type descriptions happens in an n-step transformation process, in which underspecified parts of the topology type description are completed step by step, until no more underspecified parts exist. Figures 1 and 7-9 show the example copy-and-complete procedure that is applied to create the topology type description for the example domain model.

Those language elements of the TTL that are used in the example in Section II are briefly explained in the following.

1) Area: The Area concept is the central model element to specify topologies. It provides the fundamental structure element to describe visualizations. Areas are assumed to have a spatial extension and can be nested into each other. Every area has a location that may be relative to other areas, and to its parent area (if it exists). Areas are notated by slightly rounded squares with a dashed line border (see Fig. 2).

Areas provide templates for renderers. Areas do not define their visual appearances by themselves, but they provide space for renderers to work in. Renderers use the topology type description and bound values from the domain model as input to actually display visualizations on top of a concrete graphics rendering technology. From a conceptual point of view, renderers can be implemented using any arbitrary technology, e. g., they can be created directly as program code. Different renderers may be responsible for displaying the same topology type description via different document formats, or on different devices. The wide range of realization options for renderers is not in the main focus of this paper and will further be discussed elsewhere.

An area can be associated with a type. Visually, types are distinguished by different colors of the dashed area borders. The definition of available types is indicated by small squares in the top section of the parent area.

Figure 2 shows Area notation elements nested inside each other, with the parent area defining two distinct types, that are applied to the nested areas. Further details on the specification of Areas are out of the scope of this paper and will also be discussed elsewhere.

2) Locator: A Locator serves the purpose to formally describe spatial relationships between Areas. The visual presence of a Locator, that connects two or more areas with each other, semantically only means that there is an explicit statement on how the respective areas are related to each other. The actual kind of spatial relationship is non-visually specified via the properties-sheet of the Locator. There are multiple options to actually implement a formal description scheme for spatial relations. One possibility is to recur to a 2D spatial version Allen's interval algebra, as it is elaborated in [22], which list all possible kinds of spatial relations that bodies can have on a diagram plane, e. g., overlapping, touching containing, etc.

The spatial placement of a Locator inside an area and in relation to its connected areas, as it appears in a TTL diagram, is a pure visual hint for the topology modeler that may or may not visually resemble the actual placement the Locator is expressing.

For the purposes of the example presented in Section II, a simple notion of locators that specify an absolute distance and direction between two connected areas is sufficient.

The visual notation of a Locator is exemplified in Fig. 3.

3) Abstract Areas versus Concrete Areas: In order to provide a notion of instantiability of abstract topology types to concrete ones, the notion of regarding an incomplete specifica-Fig. 3: Notation of a Locator element (middle circle) with Locator Links to two areas (dashed lines) tion of a topology as abstract, and a fully specified topology as concrete which can serve as input to a renderer, can be broken down to individual Areas. An Area which is not yet fully specified to serve as input to a renderer is considered abstract, while an Area which provides all necessary information to be rendered is concrete.

There are three ways to make sure an Area can be rendered, i. e., to concretize an Abstract Area to a Concrete Area:

• Children Areas are added (every Area that contains at least one child Area is considered to be concrete, because a default renderer can be applied that hands over the rendering of the nested areas to their respective renderers) • Conceptual Relation Specifications are added to all Conceptual Relation placeholders that an Area contains (Conceptual Relation Specifications bind elements from the data population of an area to parameters of renderers) • An Area Reference to a Concrete Area is added, which has the effect that the referenced Area is used to replace the referencing one The first two options can be combined, given that the configured renderer both processes children Areas and Conceptual Relations. In the special case that a Renderer which has no parameters at all is assigned (e. g., a visual decorator), an Area is also considered to be concrete.

The notation of Conceptual Relations and Conceptual Relation Specifications is shown in Fig. 4.

Step: Abstract Areas can be assigned with Completion Step tags, that allow to specify a minimum and / or maximum number of concretization steps, until the Abstract Area either has be made concrete, or optionally is removed. In general, Completion Step tags allow to specify any finite sequence of modes that subsequent concretization steps have to conform to.

The three distinguishable modes of how to perform a single completion step on an Abstract Area are:

• Preserve: the Abstract Area is not completed and remains abstract in the current completion step

• Optional: the Abstract Area may be completed, remain, or be deleted in the current completion step • Complete: the Abstract Area must be completed with a concrete topology description, either by assigning a renderer to the area, describe a sub-topology in the area, or by referencing another area which is concrete Figure 5 shows the notation of Completion Step tags as a sequence of differently drawn small circles in the upper right top part of an area symbol, together with a brief legend explaining the three different modes of appearances of the circles. The ability to impose constraints on anticipated future concretization steps provides a mechanism which stands in analogy to the specification of intrinsic features in a multilevel modeling language [10]. This means, the sequence of concretization steps can be defined along the instantiation levels of entities from a multi-level conceptual domain model. Using Completion Step tags, the demand for when to fill in Conceptual Relation specifications can be delayed in a controlled way. A topology type definition can make use of this to define Conceptual Relations on the basis of intrinsic attributes on higher levels of conceptual abstractions in the domain model, for which the concrete values will later be derived from slot values of entities on lower levels. This makes the TTL a visualization specification approach that integrates the description of visualizations for conceptual entities on different levels of conceptual abstractions into one unified specification mechanism for model visualizations. It allows for an efficient declaration of concrete syntaxes for domainspecific type models, together with concrete syntaxes for their instance models across multiple type levels.

The example domain model that conceptually describes the bicycle product domain is displayed in Fig. 6. It has been created with the multi-level modeling language FMML x [10], originally as a contribution to the MULTI 2017 Challenge [4].

The model is composed of four type levels. The topmost level, indicated by entities with red header backgrounds, models the general idea of a bicycle, by defining the basic components a bicycle is made of. These are BikeFrame, BikeFork, BikeHandlebar, and BikeWheel. The fact that an entire bicycle is composed of these parts is expressed by the use of a composite pattern, which provides the abstract class Component from which the individual part entities inherit, and the abstract class CompositeComponent, which is a parent class of Bike.

The second upper level, which consists of entities with a blue header background, introduces a type level which distinguishes between different kinds of bicycles, such as MountainBike, CityBike, or RacingBike in the example. It also provides some entity types that describe a refined notion of general bicycle parts, such as RacingFrame and RacingFork, which are particularly intended to be used for RacingBikes.

On the third level, a refined notion of bicycle kinds from the above level is intended to be modeled. The example demonstrates this by introducing the bicycle kinds ProRaceBike and ProRaceFrame on this level.

Finally, the lowest level shown in the example model contains bicycle product types as they could appear in the catalog of a bicycle vendor. The example model contains the product types ChallengerA2XL, which is a ProRaceBike, and the RocketA1XL bicycle frame as an instance of ProRace-Frame. From these product type, concrete instances of physical bicycle entities can be instantiated, which would resemble the notion of concrete bicycles such as "Peter's yellow racing bike". Instances of this kind are considered to be created during runtime use of the model, and are not included in the example.

The model in the TTL shown in Fig. 1 is the result of a multi-step transformation from a more general TTL model to a concrete visualization description for "Pro Racing Bikes". The procedure of the transformation is described in the following, starting with the initial TTL model shown in Fig. 7 that generally describes the notion of any bike visualization without a connection to concrete data to be rendered.

The TTL model in Fig. 7 provides a general description of what a visualization of a bike product could be composed of. The description is independent from any binding to model content yet, but by specifying several empty Conceptual Relationship elements in its area elements, it already suggests what domain characteristics should influence a resulting rendered visualization.

The Completion Step elements in the upper-right corners of each area part suggest how to further complete this topology type description in the next concretization step. The outer "Bike" area specifies a single further Completion Step, which demands to concretize this area specification in the next subsequent step. The other areas each define three subsequent

As a consequence, in the next step the outer "Bike" area is made concrete by filling in the previously empty Conceptual Relation element "background" with a binding that provides input data from the visualized model as input for the renderer that is configured for the "Bike" area. In case of the example at hand, this could mean that either based on the class name of a bike entity to be displayed, or as a result of combining the suitedForToughTerrains and suitedForRaces slot values, a suitable name for a background image is calculated. E. g., a renderer could be configured which displays a background image of a mountain scenery for mountain bikes, a street scenery for city bikes, and a racing track for racing bikes. There are diverse options for realizing such a binding on the implementation level, further details are not discussed here.

Figure 8 shows the topology model after the first concretion step has been performed.

If at this point also renderers are attached to the other areas, which could render a generic visualization of the respective elements they are to display even without concrete input values (e. g., by using pre-defined default values as long as the Conceptual Relations for the respective area are not fully specified), then the visualization description could already be used for rendering a generic, product-independent, visualization of a bike.

To provide a further refinement of the visualization specification, the next concretization step reuses the topology type Fig. 8: Example visualization specification distinguishing the notion of general types of bikes (racing/mountain/city), as modeled on the second-highest abstraction level in the domain model description in Fig. 8 and enhances it in order to visualize specific characteristics of racing bikes described in the domain model. To do so, additional Conceptual Relations are added to the "Frame" area which represent the domain fact that the frames of racing bikes are described by three lengths values. Adding further Conceptual Relations is possible, because the Conretization Step specifications for the current step allows optional modification to the area. The resulting topology type description after this step is displayed in Fig. 9.

The remaining Concretization Step elements in the model in Fig. 9 all demand for a completion of the yet underspecified areas. As a consequence, the final modifications to the model in the third concretization step consist of filling in the empty Conceptual Relation placeholders with bindings to concrete input value that can be derived from domain model entities on abstraction level 1. According to the declarations of intrinsic attributes in the domain model, this is the level where the information is present that distinguishes visual characteristics of different bike products.

Figure 1 shows the resulting concrete renderable topology type description for "Pro Racing Bikes", as described in the domain model.

Specifying concrete syntaxes for visual diagram languages is pivotal to the design of domain-specific languages (DSLs). As a consequence, most of the DSL creation approaches and tools available offer means for defining concrete diagram syntaxes. Three well known representatives of the category Fig. 9: Example visualization specification incorporating characteristics of "Pro Racing Bikes", as modeled on level 2 in the domain model of meta-modeling environments which offer support in visual language creation are METAEDIT+ [16], the ECLIPSE GRAPHICAL MODELING FRAMEWORK (GMF) [8], and SIR-IUS [7]. These tooling environments offer mechanisms to specify conceptual features of a domain, e. g., with a metamodel, together with functionality to define visual representations for the domain concepts. METAEDIT+ includes a simple graphical icon editor that allows to paint graphical symbols to represent domain concepts. GMF also supports the definition of graphical symbols composed out of drawing primitives, however, the specification of the symbols happens non-visually in a tree-view editor. SIRIUS also uses a treeview configuration editor for all parameters of its diagram definitions, with the significant difference to GMF that the concrete syntax definition is interpreted at run-time without the need for code generation. Any changes that are made to a SIRIUS diagram definition become immediately visible in a corresponding editor.

The general approach in these tools is to enhance the conceptual description in the meta-model with additional information about the visualization that gets attached to the metamodel elements. This happens either by directly attaching information about how to visualize a concept in the metamodel (e. g., by the use of annotations), or by employing a mapping model that externally attaches additional information to meta-model elements. In both cases, one has to be aware that a direct annotation of meta-model elements limits the range of possible visualizations to describe, as the meta-model structure pre-forms the possible structure of visualizations [14], [15]. None of the approaches embedded in existing tools has been developed from the very beginning based on theoretical considerations about the demands towards an optimal visualization specification mechanism. The TTL aims to overcome these limitations.

The specific task of defining visual representations for multi-level conceptual models has been addressed by a few contributions. The multi-level modeling environment OMME [28] combines conceptual multi-level modeling capabilities with the ability to visually specify a graph-based diagram language. This allows to define visual domain specific languages for multi-level models, however, the specification mechanism for the visual syntax does not specifically adhere to conceptual multi-level features, and thus does not provide reusability and extensibility of visual language specifications across multiple type levels in the underlying conceptual models.

The DPF workbench [18] also offers an integrated approach for multi-level modeling together with the specification of visual diagram representation of models. DPF's specification mechanism for visualizations offers a formalism that incorporates the notion of graph homomorphisms and type homomorphisms to check the conformance of a visualizations across multiple type levels. However, the expressiveness of the visualizations themselves is fairly limited, and the specification formalism is restricted to graph-based diagrams only, like many of contemporary concrete syntax specification mechanisms.

In XMODELER [5], [6], conceptual multi-level modeling capabilities are combined with a non-visual specification mechanism for model representation and interaction called XTOOLS. While this approach gives flexibility over specifying model representations of various types, which are not necessarily restricted to graph diagrams, the current version of XTOOLS does not specifically take into account multi-level capabilities of the underlying conceptual models.

The MELANEE [1] domain-specific language workbench is a representative of a multi-level modeling environment, which incorporates a visual language design approach that allows to take into account multiple type levels. The approach makes use of an aspect-oriented declaration mechanism, by which parts of a visualization specification can be equipped with join-points for elements that are to be specified or modified later in a refined version of the visualization [12]. This way, basic characteristics of reusability and refinement of existing visualizations for more specific type levels are made available. The visual paradigm of the diagrams languages that can be defined, however, remains limited to a be represented by a set of graph-nodes and corresponding line connectors.

Despite the prominent role of diagram languages in Information Systems, theoretic research about concrete syntax specification is just about to be established as a relevant perspective on the core objectives of the discipline. Considerations about the "Physics of Notation" [21] provide one source in Information Systems science that summarizes fundamental principles of designing visual diagram languages. Diverse points of critique have been brought forward against the narrow perspective taken in by [21]. Especially the potential for leveraging the capabilities of the human visual perception apparatus, which allows for fast, parallel, and scalable cogni-tive processing of visual pattern structures, is not sufficiently taken into account [26], [27].

Beyond the Information Systems discipline, a wider range of scientific contributions about information visualization can be found. Classical work about diagrams from before the age of computers has been contributed by [2], [24], [25]. More recent work about the effectiveness of interactive visualizations originates from fields such as interaction design and journalism [3], [17], [19], [23], or information dashboard design [9]. The research demand for incorporating the perspective on cognitive efficiency into Information Systems research has been pointed out as well [14], [15].

The example developed in this paper has given an impression of how a visual formalism for specifying visualization types that can represent model content on multiple levels of abstraction can work. Core elements of the visual Topology Type Language (TTL) have been introduced, without, however, going too much into details to keep the example description appropriately compact.

The TTL integrates the description of visualizations for conceptual entities on different levels of conceptual abstractions into one unified specification. This allows for an efficient reuse of existing concrete syntaxes, and makes it possible to specify visual languages for domain-specific type models as well as their instance models across multiple levels in the same place.

Other aspects of the TTL with respect to its applicability to presentation and interaction schemes beyond mere diagram visualizations, toward describing entire applications' user interface presentation and interactions, will be part of future work. The TTL might as well be suited for use in selfreferential enterprise system scenarios [11], where dynamically configurable views on instance models serve both as tools for control and analysis. The TTL could play a role in such a setting by providing a visual specification mechanism which allows to define instance visualizations at run-time based on existing reusable specifications of type-level visualizations.