The triptych of conceptual modeling

Perception and abstraction, i.e., “modeling,” and reasoning on models are basic human capabilities for coping with, understanding, and influencing the environment. Over time, many types of modeling have evolved: from completely intuitive to highly controlled ones that apply a specific set of terms forming the semantic instruments of a (modeling) language.

Natural language enables us to describe, communicate, or understand perceptions and thus supports a moderately controlled modeling: the language elements (words, phrases, texts, icons), their composition, and meaning are tacitly agreed upon by the users and, to a certain degree, are shared among them. The assignment of meaning to language elements, however, is sometimes ambiguous, and the syntactical rules are not strict throughout. Elements, syntax, and interpretation change over time.

In contrast to that, scientific disciplines, in particular mathematics, introduce strict formal languages and propose semantic interpretations to the lexical elements and their syntactic composition. An illustrative example of such a formal approach is the Petri Net Language as initially introduced by Petri [1]: a special type of bipartite directed graphs is provided together with some composition rules, and a family of functions (“marking” and “transition”). Applying standard Linear Algebra mechanisms to this leads to a powerful calculus. However, this calculus has no semantics at all! In order to make Petri Nets usable for modeling, we need to provide a “net interpretation,” i.e., to associate semantics to the language elements. Most popular is to interpret one type of nodes (the places) by Conditions and the other type by Events. The marking functions then describe possible situations by means of valid or invalid conditions; the transition function describes occurrence of events and their consequences.

In natural or technical sciences, this approach is reversed: initially, a conceptualization¹ of the domain of interest is established and subsequently one or more (textual and/or graphical) languages are defined for representing its elements and relationships. Think for instance of a conceptualization of electrical components that are represented using electrical circuit diagrams. The Unified Modeling Language UML comes with a conceptualization of abstract elements like class, attribute, relation, state, and activity for describing domains of interest. Similarly, the Business Process Model and Notation BPMN comes with a conceptualization of abstract elements like actors, activities, or decisions. A branch of Knowledge Engineering deals with so-called action languages that are based on the claim that “action theories always model—explicitly or implicitly—the general notions of time, change and causality” [2].

Often, such languages are called “conceptual modeling languages” and their use as “conceptual modeling”—although despite countless attempts, there is no generally used strict definition of what constitutes conceptual modeling and what does not.

One group of such definition attempts are variants of “Conceptual Modeling is Modeling with Concepts” [3, 4], and This way of defining “conceptual modeling,” however, does not provide hard criteria for differentiating it from other modeling methods in individual cases. For example, most conceptual modelers would say that programming or relational database design is not conceptual modeling (see, e.g., [7]). Nevertheless, programming languages or the SQL DDL work with conceptualizations, the latter for instance featuring elements like “Relation” or “Attribute” that have some basic semantics and therefore might be seen to be concepts in the above definition’s sense. From a practical point of view, this open question is not a real problem. However, the term “Conceptual Modeling” is widely used, and there has been an international conference with this name for 39 years. Therefore, it would be desirable to have a definition or at least a set of criteria at hand that would allow us to define more precisely what is and what is not a conceptual model. We will return to this question in Sect. 4.

Recent initiatives (e.g., [4, 8, 9]) try to compile and analyze systematically existing definitions and opinions in order to filter out a better understanding of the nature of conceptual modeling. Mylopoulos [7] offers “three complementary theses, answers to the question ‘What is a conceptual model?’.” These theses essentially state that conceptual models are (1) computational because they are stored in computers and are analyzed and justified by computers, (2) artifacts, so they should have requirements dictated by Engineering, and (3) social artifacts, because they must capture the common conceptualization of a group.

In fact, from the very beginning, conceptual modeling was propagated as a means to improve the design and implementation of whatsoever software system, especially with regard to a comprehensive and as clear as possible elicitation and analysis of system requirements. Until now, however, the practical use has mostly taken place at the level of mere drawings, which do not play a major role in the further development process and are rarely adapted to changes. Consequently, the developed software (nota bene: again a model) usually deviates considerably from what was originally modeled. The situation in Business Process Modeling is not much different, independent of the modeling method used (like BPMN, Adonis, Event Chains, etc.). This means that the potential of conceptual modeling is far from being exploited.

MDA/MDSD approaches [10] and models@runtime [11] are enforcedly more aligned with the system life cycle as they use the models for generating or driving the targeted software. Usually, they work with well-defined subsets or variants of known modeling methods [12‐14]. However, also these approaches do not have a breakthrough in practice.

Worse still, university graduates who highly motivated join a company often quickly lose their enthusiasm when they are told that modeling is too expensive in terms of effort and cost, not paid for by the customer, and has no impact on the quality of the software development process, since “agile developers” know what they are doing.

We assume that all this is mainly due to the fact that inventors and propagandists of conceptual modeling languages like ourselves have so far failed to make the anatomy of conceptual modeling and its benefits transparent to users. Instead, we invented hundreds of variants of “modeling languages” always believing that it should be a must for the targeted user to acknowledge and happily exploit the miracle we presented to her/him. Moreover, uncountable papers present what they call “ontologies” and expect the readers to internalize and share these without contradiction. Others implicitly equate conceptual modeling with “graphical modeling” [15] and thus not only add to the confusion but also distort the view of the essential.

We believe, therefore, that in order to make conceptual modeling more attractive for practitioners, we have (1) to provide a clear conception of what we are speaking about, (2) to make the anatomy of conceptual modeling transparent with its principles, paradigms, postulates, assumptions, particularities, specifics, potential, capacity and limitations, and (3) to allow the modelers to easily create and use their own domain and culture tailored modeling language and method instead of forcing them to learn and deal with ours.

With this paper, we would like to make a contribution to these To-do’s. We offer here our understanding of what modeling, in particular, conceptual modeling is about, and how we can clearly distinguish it from other modeling approaches. The perspective presented reflects four decades of dealing with conceptual modeling in research and practice, countless discussions with colleagues and practitioners, the rich body of knowledge published up to now, as well as long and intensive working meetings the authors had over the last two years. But we have neither the intention to improve the world nor to provide an n + 1st definition of what “conceptual modeling” is. Rather, we present a “signature” of conceptual modeling in the sense of a framework of characteristics by which conceptual modeling can be categorized. In other words, we will offer an explanatory framework that could help to better understand the nature of conceptual modeling.

The paper is structured as follows: Sect. 2 explores specifics of models and introduces six characteristics that can be observed for models. Section 3 refines these six characteristics in terms of a list of criteria that can be used to determine the nature of CM (conceptual modeling). In Sect. 4, we summarize the two previous sections and discuss the first conclusions that can be drawn from them. This will provide the basis for Sect. 5, where we present the core message of the paper: the triptych paradigm of conceptual modeling together with its dimensions and model/language hierarchies. The paper ends with a conclusion and an outlook on open research challenges in Sect. 6.

We will reference related work where appropriate but, intentionally, there will be no separate section on related work. Instead, we refer to the rather comprehensive overview given in Thalheim [4], to [23] and to attempts to define the term “model” [17].

Finally, we would like to point out that, for the sake of readability, we also adopt the usual homonymous use of the term “model” in this paper: from an epistemological point of view, a model is a mental object. In practice, however, the representation of a model introduced into the perceivable world is also referred to as a model, like, e.g., an Entity-Relationship diagram. We adopt this homonymy because the particular meaning will result from the respective context.

Across disciplines, the number of publications dealing with models, modeling, and abstraction is unmanageable. Even for the notion of “conceptual model” more than 60 different definitions can easily be found [4, 7, 23]. None of these, however, allows for a robust and unequivocal differentiation between conceptual and non-conceptual models. This is also true for an interesting definition that recently emerged in a side-piece discussion at ER 2017: “A conceptual model is a partial representation of a domain that can answer a question.” For, it only highlights one aspect.

We, therefore, try to elaborate the essence of conceptual modeling in the form of a taxonomy of characteristics that may help to better delimit the semantics of the term “conceptual model.”

Before we can do this, we first need to take a closer look at the terms “concept”, “notion”, and “term”. The reader will have noticed that we have avoided their use as much as possible so far. The reason for this is that the meanings of these terms in literature and in encyclopedias are not sharply delineated so that there are overlapping or synonymous definitions. For the purposes of this paper, however, we need a more precise distinction (which will be further specified in Sect. 5). We, therefore, assume the following meanings in the subsequent sections: Second, as conceptual models are models, we have to agree on the key characteristics of models before specializing and extending these to determine what the characteristics of conceptual models are. For this purpose, we adopt the main criteria provided by Mahr [27] that may be summarized by “A model is the synthesis of a conceptual idea, a form of expression and the assumption of a role through which it fulfils a function.”⁴

Model Characteristic 1: Models are related to (a collection) of “origins” or “originals”. A model is a model of something,⁵ i.e., it is a proxy of a natural, artificial, or mental original; in particular, the original of a model may be a model itself. As originals may change in time, the model/original relationship may change in time as well [28]. Models are results of cognitive processes (perception) [5]. The mission of a model is that of transporting a “cargo,” namely the perceived properties of the original that are considered to be relevant within the perception’s context. Mahr sees this function as the key criterion for a “model being a model” [29]. The transport occurs with the usage of the model; precision and transport warranties distinguish models and metaphors [30].

Model Characteristic 2: Concern and usage. We distinguish three different main concerns that are coupled to most kinds of modeling: (1) understanding, (2) communicating, and (3) agreeing as a process of consolidation, manifestation, and consensus. With the usage, a model unfolds its power: “We place models between ourselves as perceiving, recognizing, understanding, judging or acting subjects and the world as perceptible, observable, effective, to be judged or produced exterior. The impact of models results from the role that models play through their transport function in work processes, cognitive processes, business processes. The power of models is the result of their power to act”^6,7 [27]. In general, the usage of a model will be directed by its initial concern. However, this is not mandatory, because the using individual can do what she/he wants with a model.

Model Characteristic 3: Purpose and function. Given its concern and usage, a model serves a particular purpose: to understand/analyze/assess the origin, to plan/design a new original, to explain or predict properties of the original, to communicate about perceptions and ideas, and similar. The usage determines the function(s) of a model, for example to support explanation. It therefore makes sense to see a model’s function as that of an “instrument” [16, 18].

Model Characteristic 4: Domain and context. For the concerns of modeling, we distinguish the following three domains: The first domain is concerned with understanding and thinking. So is the second one which additionally is concerned with realization (in the sense of implementation). The third domain is concerned with communication.

A model is created, modified or refined in particular contexts: the personal context of the modeler, the environmental context in which the modeling process takes place, the social context, i.e., the particular community of practice, and the spatio-temporal context (time, duration, location, and movement, etc.) [31, 32].

Clearly, a model’s cargo as well as its interpretation depends on the given concern, purpose, domain and context.

Model Characteristic 5: Focus. A model reflects, for a given purpose, the “relevant” but not all aspects of its origin(al). In particular, “The objectual properties may recede behind the consideration of their rational-functional relationships” [33]. Note, that this is a more general view than that of [28], who emphasizes on reduction, i.e., differentiates between “modeled attributes” and “neglected attributes” of the origin(al).

Model Characteristic 6: Representation. For communication/transportation purposes, a model needs an associated “physical” representation; examples are an acoustic signal, a toy railroad, a diagram, a XML statement, an OWL file, a spoken/written natural language text, and so forth. These representations allow models to be recognized and understood by communication partners; in the case of a human partner, recognition is enhanced by “linguistic perception” [5]. The representations should be dependable, understandable by the involved actors (humans and/or systems), and thus be agreed within the community of practice. George A. Miller explained the relationship between a model and its representation as follows: “To have a model means to be able to produce or recognize a physical symbol carrier that represents a model, and to understand the meaning of the model” [34].

Clearly, this taxonomy is not complete, as the literature addresses many more characteristics. For example, see the “Kiel house of modeling” [17].⁸ However, it should not be a problem to classify most of them in relation to the characteristics presented.

Conceptual models are models, conceptual modeling is (a kind of) modeling. Consequently, the characteristics described in Sect. 2 also apply to conceptual models. So we need to identify what constitutes the specialization “conceptual.” To this end, we will now, wherever possible, specialize the above model characteristics and introduce two more that we believe are specific to conceptual models.

CM Characteristic 2: Concern and usage. In the discipline of Informatics the term “Conceptual Modeling” has been initially used for a database design method, later on for requirements modeling and since the 90s for business process modeling and software specification. In all cases, the mapping from conceptual models (represented using languages like the ERM, UML, BPMN, SysML, etc.) to an implemented system language (SQL DDL, programming languages, workflow languages, etc.) has been a key issue until today. Model Driven Software Development (MDSD) [35], Model Driven Architecture [10] as well as models@runtime [11] all start from conceptual models and aim at materializing and automating that mapping. Model Centered Architecture (MCA) [36] advocates, for any aspect of a system under development, the use of Domain Specific Modeling Languages (DSML), i.e., focuses on models (and their metamodels) in any design and development step up to the running system. In summary, conceptual modeling has a strong (although not mandatory) orientation to a subsequent implementation/realization of artifacts or products. It, therefore, is widely used as a means for requirements modeling and analysis. Consequently, we may add the concern (4) “specifying” to the list of concerns. Unlike [7], however, we do not claim that conceptual models are “computational”—and that they have only existed since computers have existed.

CM Characteristic 7: Concept Space. From its beginnings, conceptual modeling had a strong relation to semantics. Partly, “semantic modeling” using terms that are associated with concepts from a “concept space” is even used as a synonym [37] of conceptual modeling: A community of practice agrees on the terms and concepts, which it will consider, as well as on the association between these terms and concepts, and thus establishes an instrument for communication. The terms used for representing models thus have a meaning, the “a priori semantic” [6].

So we can consider conceptual models as models that are “enhanced” by concepts from a concept space. I.e., the decision to compile and accept a set of concepts and to use its elements for relating them to models opens the entrance into the world of conceptual modeling (we will discuss this in detail within the next chapters). This characteristic governs all others and reminds to the definition “Conceptual Modeling is modeling with concepts” cited in the introduction. Reflecting the considerations presented so far, a more apposite description could be “Conceptual Modeling is modeling with concepts from an associated concept space.”

Such association provides a semantical basis supporting understanding communicated models within a community of practice (see CM characteristic 2): as a prerequisite, this community agrees in advance on a set of concepts to be used for modeling, their meaning and representation (controlled vocabulary). Usually, this is done informally in natural language, i.e., relating an explaining natural language phrase to the given concept. As an example think of Peter Chen’s explanation of the concepts “entity” and “relation” [38]: “An entity is a ‘thing’ which can be distinctly identified. A specific person, company, or event is an example of an entity. A relationship is an association among entities. For instance, ‘father-son’ is a relationship between two ‘person’ entities.” I.e., the semantics of natural language—and thus its intrinsic a priori [39‐41] knowledge—are used to determine (the meaning of) concepts.

Therefore, the degree of a common understanding of the elements of a concept space by the members of a community of practice depends on the degree of equivalence of their understanding of the natural language used. As such equivalence cannot be formally derived or proven without a reference mechanism like an ontology or a set of axioms, the “a priori semantics” [5] of conceptual models provide a practically useful but formally inaccurate means for communication. Some people, therefore, call conceptual models “semiformal” as has been mentioned in the introduction.

CM Characteristic 8: Concept relationship. Concepts can be related to each other. Typical concept relationships are the “abstractions” [42] Mereology (Aggregation), Generalization, and Intension, each of them having an inverse: Disassembly (into components), Specialization (by additional concept attributes), Extension (denominating the elements characterized by their intension concept) [43, 44]. Other concept relationships are, e.g., synonymy, homonymy, troponymy, hyponymy; however, these only concern the level of assigning linguistic denoters to concepts. Therefore, such relationships can be found in thesauri and encyclopedias, since they occur at the linguistic level.

Note that a conceptual modeling language that offers explicit means for modeling the intension/extension relationship,⁹ supports “multi-level” modeling. For, models then are not mere extensions of a given metamodel but may consist themselves of intension/extension concept hierarchies. In the field of Domain Specific Modeling, this possibility is often neglected: Metametamodel abstraction relations are just used for relating metamodel concepts, but metamodels often do not explicitly provide such relations for allowing the same on the modeling level, i.e., the relationships are not introduced as part of the concept space in question.

Table 1 summarizes these considerations on model characteristics.

In this section, we use some examples to show how the previously introduced CM characteristics can be used to decide for a given model whether it is conceptual or not.

First, however, we note that models based on model hierarchy frameworks such as the Information Resource Dictionary IRDS [45]) or the MetaObject Facility MOF [46] are not conceptual per se, although the model hierarchies are induced by concept relationships according to CM characteristic 8. For, a metamodel (on a hierarchy level Hⁿ⁺², e.g., on MOF Level M2) specifies modeling elements (“modeling concepts” in [47]) and their relationships but neither automatically nor explicitly associates these with a concept space in the sense of CM Characteristic 7. This would also not change if we cast the whole thing in languages, i.e., create linguistic means of expression for the formulation/representation of models on level Hⁿ⁺¹ or model extensions on level Hⁿ by defining corresponding grammars.¹⁰

The Entity-Relationship Model (in the sense of a metamodel) thus only becomes “conceptual” when the meaning of the terms “entity set,” “relationship set,” “attribute,” etc. is at least colloquially explained (a priori semantics) in an associated concept space. The same applies to the metamodel of the UML. In other words, modeling with UML is conceptual if the a priori semantic explanation of what is meant by “class,” “relation,” etc. is associated with the models. Pure drawing of diagrams or “graphical modeling” is not conceptual.

But what about the question we raised in the introduction: “Is the Relational Data Model a conceptual one?” Traditionally, answering this question was avoided by introducing the notion of “logical” model, i.e., a representation that is based on a “logical” language and the semantics defined by usage (or implementation). Mylopoulos [7] makes a more specific statement on this: “Relational schemas are not conceptual as well, because they say nothing about the meaning of data in a database, only about its structure.” At first sight, one seems to be able to get along with this statement, but we do not want to accept it as a generally valid one. For, the situation is identical to the situation described above regarding UML: if there is (within the given community of practice) a common accepted view on the meaning of the terms “relation,” “column,” “row,” “attribute,” and so forth, the Relational Data Model (a metamodel) is a conceptual model, as its elements have an associated concept space. A relational schema represented in SQL DDL (on level H¹) and introducing common concepts (e.g., a table called “client”) then allows us to infer that client is an extension of the concept relation and has attributes (columns) describing clients’ properties, and rows describing particular clients.

If, at this stage, we chose the names of the columns from denominators that are well-known in our natural language NL (e.g., name, birthday …) then we can exploit the NL a priori knowledge in order to intuitively interpret the tables. This was already recognized in the year 1977 by John and Diane Smith [42]: “Since databases are usually designed to model the real world as we understand it, we can safely require that all object names in a relation definition be natural language nouns. These nouns then provide the bridge between our intuitive understanding of the real world and its intended reflection in the relation definition. If natural language nouns are not used, any discussion of the meaningfulness of a relation definition seems moot.” Formally, however, these H¹ level concepts become related to the respective Universe of Discourse only, if the respective denominators (“client,” “name,” etc.) and their a priori semantics are added to the concept space. This is often achieved by the use of a data dictionary or by establishing an ontology.

Another question that sometimes gives our students headaches is: “What is a balance sheet from a modeling perspective?” Of course, our students first would ask us to specify more precisely, what we mean by “balance sheet”: So far so good. But now we ask: Is a balancing scheme according to (2) a conceptual model? Again, this question can be answered with the help of the characteristics: Yes, it is a conceptual model, if the underlying metamodel associates with its elements the concept space of business administration with concepts like “assets”, “liabilities”, “cash on hand”, “equity capital”, “borrowed capital”, etc. and their relationships.

A somewhat easier to answer question than the previous one concerns the Petri nets already mentioned in the introduction: are they conceptual models? Again, for answering the question we have to specify more precisely, what we are concretely referring to by the term “Petri net.” So let us restrict ourselves to the classical “marked Petri Net.”¹¹ Given the definition in the footnote, we are dealing here with a purely formal structure with which no semantics are associated. However, if we associate, as Petri suggested, a “net interpretation,” i.e., a concept space, with (the elements of) the marked Petri Net it becomes a conceptual model. This, by the way, on hierarchy level Hⁿ, since a change of marking leads to a new extension. On Hⁿ⁺¹, one could, as an example, consider (P,T,I,O) together with the set of all possible mappings M as the intension of the Hⁿ model.

Comparable considerations can also be made about circuit diagrams in electrical engineering. It should be clear that such a diagram is not a pure drawing or formal graph structure but the graphical representation of a planned circuit or the description of a realized circuit. In the German term “Schaltplan” (literally translated as “circuit plan”) this model character is clearly expressed. The diagram for a concrete circuit is located on hierarchy level H⁰, but of course H¹ plans are also common as intensions, namely when they are generic, so that several concrete extensions can be derived from them (see Fig. 1). But are circuit diagrams also conceptual models? We can answer this question clearly with yes: The metamodel uses concepts exclusively from the concept space of electrical engineering (power source, resistor, line, switch, lamp, etc.), the (graph-)grammatical composition rules for the symbols of the model representation language correspond to the physical rules of concept space’s universe of discourse. Thus, the model in Fig. 1 represents a conceptual model for circuits in which a lamp and a switch are connected in series to a Battery as a power source.

Another example concerns a temple stele (Fig. 2) that is over 3000 years old, about which historians say the following: Basically, this is the “material manifestation” (a representation) of the contexts of a religious imagination. The stele represents a religious concept that was new at the time, namely a God who hears and answers to prayers (see the ears on the right side of the picture), with the king acting as “mediator.” In addition, social conditions are described: In the group of adorants, the stele founder comes first, then his wife, then their children, ranked by age (importance). Clearly, the stele represents a model of abstract and concrete originals (Char. 1). Its concern and usage is communicating the new religious concept to viewers (Char. 2) with the purpose (Char. 3) that these understand the concept. The focus (Char. 5) is on the idea of a listening God, the representation is graphical with some symbols referencing concepts. We interpret this stele as the representation of a hierarchy H¹ level model, as at least God and king may have various extensions. If this model is a conceptual one, cannot be said with a hundred per cent certainty. For there is no explicitly assigned concept space with corresponding concept relations handed down with. However, it is not impossible that artist and viewers were aware of such a concept space at the time.

To sum up, the existence of a concept space is a precondition for models being conceptual ones; the degree to which a component of a conceptual model has UoD related, interpretable semantics depends on its associated vocabulary elements. For comparison, consider the difference between WEB 1.0 and WEB 3.0 (“Semantic Web” [21]): In WEB 1.0 we can interpret website content based on the natural language terms used exploiting NL’s a priori knowledge. WEB 3.0 pages are intended to provide a vocabulary defining the semantics of the page content; consequently, WEB 3.0 pages are representations of conceptual models (mainly on hierarchy level H⁰), the concept space being defined, e.g., exploiting schema.org [48].

Our considerations as presented so far have inspired us to create a paradigm for conceptual modeling, namely the triptych¹²: For with this paradigm the transition from the linguistic description of phenomena to modeling and then to conceptual modeling can be described vividly through the successive opening of wings. In this section, we first explain the paradigm and then go into detail about the three dimensions that we attribute to conceptual modeling with this paradigm.

Modeling is as old as a human advanced civilization. The bible remembers models already in the Chronicles (1, 28, 11)¹⁹ or Torah/Genesis (2 Moses, 25, 9 or 1 Moses, 1, 27). Around the same time, Heraclitus developed the tenet of logos that consists of concepts.

Conceptual modeling is one of the kernel activities in information systems engineering. For instance, conceptual schemata are widely used since the advent of database technology and explicitly named as such with the introduction of the entity-relationship modeling language. The first model we know that might be called a conceptual one relates back to the myth of Ptah who builds the world according to his worldview and doctrine. As far as we know for sciences, simulation explicitly uses the term “conceptual model” since 1950 [53]. Other disciplines use the wording “conceptual model” with a quite different meaning, see for instance [54].

Today, the term “conceptual model” is widely used and needs proper systematization. We start this systematization with eight characteristics for a signature of the conceptual model. The first six characteristics (related to origins; concern and usage; purpose and function; domain and context; focus; representation) already belong to the signature of models. These characteristics are extended for conceptual models by two additional characteristics (concept space; concept relationship). The second and third characteristics are extended for conceptual models.

We differentiate between notions as general inclusive concepts, terms as representations referring to concepts, and concepts in the narrow sense as codified abstract ideas. In systems engineering, concepts are those in the narrow sense. The histories of notions, concepts, and terms are different. Notions have been used as reasoning instruments. Terms are bound to languages. Concepts have a history of at least 3–4000 years. The separation into notions, concepts, and terms can be used for a proper introduction of a paradigm of conceptual modeling: the triptych that consists of three wings which represent The outer two wings can be used without the third one. They form then a closed triptych, i.e., a diptych. The middle part of the triptych—the model dimension—is supported by the “encyclopaedic” dimension and is enabled by the linguistic dimension.

Modeling has been systematized by abstraction levels. The separation by abstraction is typical for artificial languages. The ground Hⁿ level represents things of interest. The Hⁿ⁺¹ level is used for models; the Hⁿ⁺² level for metamodels (i.e., essentially the structure of the modeling approach), and the Hⁿ⁺³ for metametamodels (i.e., essentially the framework of the modeling approach). This strict separation by abstraction is blurred in the linguistic dimension and almost not existing in the “encyclopedic” dimension. Conceptual modeling thus supports defining properly structured views on the encyclopedic dimension.

We did not plan to propose a new definition of the term “conceptual model,” especially as more than 60 such definitions exist to our knowledge. The introduced signature, however, together with the Triptych paradigm provides a means and explanation of the essence of conceptual modeling. We understand this as the first step toward a general theory of conceptual modeling. We encounter a good number of problems to be solved in forthcoming research. The list below is ordered according to our plans for the future; collaboration and contribution from the community are more than welcome: This list is far from being complete. It demonstrates, however, the potential of the signature approach by a systematic treatment of open issues in (conceptual) model research.