See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/284670222

The Conception of the Model

Conference Paper · June 2013

DOI: 10.1007/978-3-642-38366-3_10

CITATIONS READS

8 1,270

1 author:

Bernhard Thalheim
Christian-Albrechts-Universität zu Kiel
489 PUBLICATIONS   4,170 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Information system technology View project

web information systems engineering View project

All content following this page was uploaded by Bernhard Thalheim on 25 March 2016.

The user has requested enhancement of the downloaded file.

 The Conception of the Model

Bernhard Thalheim⋆

Christian-Albrechts-University Kiel, Computer Science Institute, 24098 Kiel, Germany

Abstract. Modelling is one of the central activities in Computer Science. Models

are used as intermediate artifacts for system construction, as reasoning tools, for
explanation, for description of reality, and for prediction of system behaviour.
In this paper we introduce a novel conception of model. The range of models
spans from elementary to matured models. Depending on the goal, purpose and
function of the model within a deployment story (‘Gebrauchsspiel’) we may use
the most appropriate model. If goals, purposes and functions are changing then
we need to change the model.

Keywords: model, models in science, model theory, conceptual model, conception of model.

1 Introduction

It is common misbelief (e.g. [2, 13] or more generally almost all Computer Science
textbooks) that there is no definition of the conception of the model. We consider this
claim as the big misunderstanding of the science and art of modelling.

1.1 A First Conception of the Model

As a starting point, a model can be simply considered to be a material or virtual artifact

(1) that is called a model within a community of practice (2) based on a judgement (3)
[8] of appropriateness for representation of other artifacts (things in reality, systems,
...) and serving a purpose (4) within this community. We distill in the sequel criteria
for artifacts to become a model. We can use two approaches: abstract properties and
criteria for artifacts. We observe however that most properties of models are hidden
or implicit and thus not given. The user must be a member of a community and base
his/her understanding on the background accepted in this community. This implicitness
is the main source of misunderstandings on models.
Additionally models are used in many different deployment scenarios and stories
(‘Gebrauchsspiel’ (deployment story), ‘Sprachspiel’ (language game)) [29]). They are
used for certain purposes and have a function within their deployment [9, 18, 30]. Often
they should not or cannot be used outside their purpose.
⋆
[email protected] http://www.is.informatik.uni-kiel.de/∼ thalheim
2 Bernhard Thalheim

1.2 The Manifold of Model Definitions

Computer Science uses more than 50 different kinds of models in all its sub-disciplines
[25]. Business informatics mainly uses four approaches to modelling [26]:
1. The general model definition by Stachowiak [17] uses the mapping, truncation and
pragmatic properties for origins and models
2. The axiomatic model definition [1] based on mathematical logics uses formal sys-
tems and formal theories which models represent a certain part of reality.
3. The mapping-based model definition [10] uses a direct homomorphic mapping be-
tween origin and model for description and prescription and another mapping be-
tween model and implemented system for realisation.
4. The construction-oriented model definition [3, 12, 19, 30] considers the model as a
result of a modelling process by some community of practice.
These differences explain the variety of model definitions used in literature ([26] se-
lected 35 of notions which are commonly used in business informatics.). As a very
short list we may consider the following statements:
[1]: A model is a mathematical description of a business problem.
[3]: A model is the result of a construction process for which the selected part of the
origin satisfies the purpose.
[4]: A model is the representation of an object system for the purpose of some subject.
It is the result of a construction process by the modeller who addresses a representation
of these objects for model user at a certain time and based on some language. A model
consists of this construction, the origin, the time and a language.
[8]: A model can be simply considered to be a material or virtual artifact which is
called model within a community of practice based on a judgement of appropriateness
for representation of other artifacts (things in reality, systems, ...) and serving a purpose
within this community.
[11]: The model prescribes concepts as a particular kind of relation relating a subject
and an entity.
[15]: A model is an object that has been developed and is used for solution of tasks
which cannot be directly solved for the origin by a subject because of its structural and
behavioural analogy to an origin.
[18]: Models are governed by the purpose, are mappings of an origin and reflect some
of the properties observed or envisioned for the origin. They use languages as carrier.

1.3 Brief Survey of the Paper

Concepts [28] are used for classification or are all the knowledge that the person has,
and associates with, the concept’s name. Conceptions [28] are however systems of ex-
planation. We target in this paper at the conception of the model in Computer and other
Sciences.

2 Models Defined Through Properties, Purposes and Functions

2.1 Stachowiak, Aristoteles, Galilei and Mahr Properties of Models
Models are often defined through abstract properties they must satisfy [22, 23].
 The Conception of the Model 3

(1) Mapping property: Each model has an origin and is based on a mapping from the
origin to the artifact.
(2) Truncation property: The model lacks some of the ascriptions made to the original
and thus functions as an Aristolean model by abstraction of irrelevant.
(3) Pragmatic property: The model use is only justified for particular model users, tools
of investigation, and period of time.
(4) Amplification property: Models use specific extensions which are not observed for
the original.
(5) Distortion property: Models are developed for improving the physical world or
for inclusion of visions of better reality, e.g. for construction via transformation or in
Galilean models.
(6) Idealisation property: Modelling abstracts from reality by scoping the model to the
ideal state of affairs.
(7) Carrier property: Models use languages and are thus restricted by the expressive
power of these languages.
(8) Added value property: Models provide a value or benefit based on their utility, ca-
pability and quality characteristics.
(9) Purpose property: Models and conceptual models are governed by the purpose. The
model preserves the purpose.
The first three properties have been introduced by Stachowiak [17]. The fourth and fifth
property have been introduced by Steinmüller [18]. The seventh property is discussed
by Mahr [10]. The sixth, eight and ninth properties [23] are however equally if not the
most important ones.

2.2 The Purpose of a Model

The purpose dimension is ruling and governing the model, the development process
and the application process because of the main reason for using a model is to provide
a solution to a problem. Therefore the purpose is characterised by the solution to the
problem provided by the model. We may distinguish a number of concerns such as
the impact of the model (“whereto”) for a solution to a problem,
the insight into the origin’s properties (“how”) by giving details how the world is struc-
tured or should be structured and how the functionality can be described,
restrictions on applicability and validity (“when”) of a model for some specific solu-
tions, for the validity interval, and the lifespan of a model,
providing reasons for model value (“why”) such as correctness, generality, usefulness,
comprehensibility, and novelty, and
the description of functioning of a model (“for which reason”) based on the model ca-
pacity.
Purpose is often defined via intention and mixed with function. Goal (or intention or
target or aim) is a ternary relation between a current state, envisioned states, and people
(community of practice). Typical - sometimes rather abstract - intentions are percep-
tion support, explanation and demonstration, preparation to an activity, optimisation,
hypothesis verification, construction, control, and substitution.
4 Bernhard Thalheim

2.3 The Function of a Model While Deploying it in Applications

The deployment function of a model relates the model purpose to a practice or appli-
cation cases or application ‘game’ similar to Wittgenstein’s language game (we call
it better deployment case and is characterised by answering the classical W-questions
(Hermagoras of Temnos1 rediscovered by J. Zachman): how, when, for which/what or
why, at what/which (business use case), etc. We add to purpose: application, conven-
tions, custom, exertion, habit, handling, deployment, service, usage, use, and way of
using. The model has a role and plays its behaviour within this application game. [24]:
Description-prescription function: models as images, figures, standard, opus, exposi-
tion, representation, composition, realisation;
Explanation function: models ‘gestalt’, pattern, guidance, type, family or species, orig-
inal, concept, principle, form, workout;
Optimisation-variation function: models as creation, ideal, achievement, probe, arti-
cle, plan, variant, substitute;
Verification-validation-testing function: models as sample, schema, specimen, pattern;
Reflection-optimisation function: models as creation, design, construction, type, deriva-
tive, master piece, product;
Explorative function: models as result, product, work, art piece, metaphor, paradigm,
first edition, style, realisation, artefact;
Hypothetical function: models as copy, release, original form, offshoot, simulation or
experiment product;
Documentation-visualisation function: models as presentation, figure, illustration, demon-
stration, explanation, adornment, plastic, structure.

3 The Conception of Model

3.1 Conceptions to be Given for a Model
Models are often only considered with their intext, i.e. their structures and behaviour.
Context is either neglected or taken for granted. We must however relate a model to the
context dimension if we want to understand, deploy or modify the model.
Models follow typically some modelling schemata or pattern [7]. They are based
on conceptions (concepts, theoretical statements (axioms, laws, theorems, definitions),
models, theories, and tools). Conceptual processes include procedures, conceptual (knowl-
edge) tools and associated norms and rules. Conceptions and conceptual processes are
based on paradigms which are corroborated.
Models support interaction, understanding, sharing, and collaboration among peo-
ple. They depend on existing knowledge, the actual (ontological) state of the reality, the
condition of the person’s senses and state of mind, and the state of employed instru-
ments. Therefore, models depend on the background concepts which are accepted in a
community.
We can summarise the considerations so far and develop a general model frame, i.e.
a model of the model itself. It consists of four main components
1
The rhetor Hermagoras of Temnos, as quoted in pseudo-Augustine’s De Rhetorica defined
seven “circumstances” as the loci of an issue: Quis, quid, quando, ubi, cur, quem ad modum,
quibus adminiculis(W7 : Who, what, when, where, why, in what way, by what means). See also
Cicero, Thomas Aquinas, and Qunitillian’s loci argumentorum as a frame without questioning.
 The Conception of the Model 5

Founding concepts: A model is based on paradigms, background theories, assump-

tions and guiding principles. It is composed of base conceptions/concepts with a
certain scope, expressions, concept space organisation, and some quantification/mea-
surement). Language-based models use a namespace or ontology as a carrier. This
namespace is based on definitions made, i.e. the cargo in the sense of [10].
Structure and behaviour: A model is often incrementally built. Models can be multi-
faceted (with a specific topology/geometry, with states, with interactions, with causal
associations) or monolithic.
Application domain context: A model corresponds to a part of the reality, i.e. the ap-
plication domain. The domain forms the empirical scope of the model. General or
application-specific correspondence rules guide the association between the origin
and the model. Each application domain is based on general laws one might have
to consider for the model as well.
Meta-model: Models are developed within a theory and have a status within it. These
theories provide the content of paradigms. Concepts are the most elementary build-
ing blocks. The construction process of a model is guided by the laws applicable to
such theory. We may use basic models, emergent models, and subsidiary models.
Reusing the theories of concepts, content and topics [20], we shape the general
concept frame. A concept is given by the scope, by at least one expression, by its asso-
ciation to other concepts and its media type [14] for the content. The application domain
and potential functions constitute the scope of a concept. A concept can be defined by
one or more partially synonymous expressions in a definition frame [22]. The concept
space must follow some internal organisation. Concepts are interdependent and asso-
ciated with each other. A concept must be underpinned and quantified by some data
which use a certain format. We assume that the formatting can be given by a media
type.

3.2 Model Fitness

[7] introduces model viability. We extend this approach and consider fitness of a model.
Fitness (or superior quality) of a model is given by
(a) usability of the model for its purpose, i.e. for resolving the questions, e.g. validity
of the model;
(b) potential of the model for the purpose, i.e. for the goals that are satisfied by the
model, e.g. reliability and degree of precision of the the model;
(c) efficiency of the model for the function of the model within the application, i.e. the
practice [29] of deployment of the model;
(d) generality of the model beside its direct intention of construction of the model, i.e.
for applying the model to other goals or purposes, within another function or with
some modification or extension, e.g. the extend of coverage in the real world.
These four criteria form main quality characterisations of a model. Viability is defined
through validity, reliability for the model purpose and function, extent of coverage in
dependence on context such as space and time, and efficiency of the model. Viability
thus can be used to evaluate how well the model represents the reality for a given scope
and how suitable or instrumental is the model for its purpose and function.
6 Bernhard Thalheim

The potential of a model is defined by its strengths, weaknesses, opportunities and

threats (SWOT). The potential can be assessed within a SWOT analysis. A model must
be empirically corroborated in dependence on the objective. The abstraction property
[17] determines the degree of corroboration. A model must be consistent with the con-
text and the background and coherent in its construction. Models are parsimonious re-
ductions of their origins. Due to this reduction models must be revisable for changes
in reality. At the same time models must be relatively stable and robust against minor
changes.

3.3 The Background of a Model

To summarise, the background of a model thus consists of

grounding G, i.e. concepts, foundations, language as carrier, and the cargo,
(meta-)basis B, i.e. basement, paradigms, theories; status in application; context; paradig-
matic evolution; abstraction, and scale,
deployment D, i.e. goal, purpose, function, and reason,
community of practice P, i.e. stakeholder with their roles and plays, with their inter-
ests, portfolio and profiles,
context C, i.e. time, space, and scope,
quality Q, i.e. correctness, generality, usefulness, comprehensibility, parsimony, ro-
bustness, novelty etc. and
viability V, i.e. corroboration, coherence, falsifiability, stability, and assurances (re-
strictions, modality, and confidence).
The grounding and the basis are metaphorically displayed as the cellar and the fun-
dament in Figure 1. The context and the community of practice are two of governing
directives for the model.

3.4 Properties of Artifacts Which Might Become Models

We can now classify artifacts:

Well-founded artifacts also explicitly define their grounding and basis.
Goal-oriented artifacts describe the goal state(s) and the initial state together with a
criterion in which case the goal has been achieved.
Purposeful artifacts are goal-oriented artifacts that provide methods for achieving the
purpose.
Deployable artifacts can be applied in deployment stories depending on the artifact
orientation (which application story, function).
Useful artifacts also consist of utilisation methods depending on the focus (what is
going to be represented, capacity), scope (what shall be solved by the model, pur-
pose) and orientation (which application story, function).
Adequate artifacts M∗ satisfy an invariance property for the origins M∗ , M1 , ..., Mk
depending on focus and scope.
Homomorphic artifacts are homomorphic to their origins based on some homomor-
phism.
 The Conception of the Model 7

Conceptual artifacts contain concepts which are used as the basis of semantics for
elements of the artifact.
Contextual artifacts explicitly describe their context, e.g. application domain, time,
space, discipline, and understanding within a school.
Manufacturable artifacts can be (re-)produced by application of creation methods.
Characterising artifacts describe certain properties of origins M∗ , M1 , ..., Mk .
Viable artifacts are corroborated, justified and established.
Evaluated artifacts are given with their quality properties.
Supported artifacts are explicitly supported by some community of practice.

3.5 An Artifact Which is a Model

Given a collection of artifacts M∗ , M1 , ..., Mk , a community of practice P (⊆ P),
a grounding G (⊆ G), viability V (⊆ V), bases B (⊆ B), context C (⊆ C), and
deployment D (⊆ D). The adequacy, fitness and usefulness can be expressed through
quality characteristics or measures: Qa ∪Qf ∪Qu for adequacy, fitness, and usefulness.
We call the quintuple (P, G, V, B, C, D) judgement frame J.
Based on J the artifact M∗ is called a model
• for M1 , ..., Mk by P,
• for D with V
• if it is appropriate with Qa ∪ Qf ∪ Qu and within C
• based on B using G , i.e.
• it is adequate (has potential for goals) [similar + regular + fruitful + simple]
according to the relation between M∗ and M1 , ..., Mk at level of Qa for D
with V within B and grounded by G,
• it is fit for D with Qf within C and compliant with G and B and
• it is useful for P within their D and at level of Qu .
We may also consider a model suite [6, 21] M∗1 , ..., M∗n instead of M∗ .
Therefore, artifacts such as metaphors, parable, similes, allegories, code or pro-
grams without additional artifacts for documentation, sets of examples, simple artifacts
without any utilisation method, artifacts without deployment, demonstration samples,
etc. are not considered to be models. Also, the so-called models in data mining are not
yet matured to become a pre-model.

3.6 Matured and Elementary Models

A matured model is an artifact that uses
a fundament with
• the grounding and
• the (meta-)basis,
four governing directives given by
• the artifacts to be represented by the model,
• the deployment or profile of the model such as goal, purpose or functions,
• the community of practice acting in different roles on certain rights through
some obligations, and
• the context of time, discipline, application and scientific school,
8 Bernhard Thalheim

two pillars which provide

• methods for development of the model and
• methods for utilisation of the model,
and finally
the model portfolio and function for the deployment of the model in the given appli-
cation.
An elementary model is an artifact that
• represent artifacts,
• has a deployment or profile of the model such as goal, purpose or functions,
• is supported by a (partial) community of practice, and
• has (some) methods for utilisation of the model.
A model is thus an artifact that consists of an elementary model and that may be ex-
tended to a matured model.

Solve/use/play/
‘Gebrauchsspiel’ (application story and scenarios)/functioning/
e.g. description ∨ explanation ∨ prescription ∨ prognosis ∨ ... /
define/construct/explore/communicate/understand/replace/
document/negotiate/replace/report/account

Deployment recount and model portfolio

Describe/characterise/ Community Use for solving/

picture/depict/represent/
Context
plan/construct/
relate/specify
time/space/ of practice skilled application
discipline/school/ role, right,
Create/produce/ application obligation, play
form/shape/design/ Prognose/simulate/


arrange/ estimate/


organise/model forecast/appreciate/
Development methods

treasure

Utilisation methods
Evolve/migrate/
redevelop
Develop, Usage Reason/

⇒ ⇒
construct, business cases understand/apprehend/
explore/conceive/
Corroboration/viability/
justify/support/
configure,
Model installation,
conclude/know

found/establish/ Explain/
orchestrate, consolidate
prove/argue/
choreography check/appraise/
substantiate/motivate/
constitute/show why experience


Integrate/


Evaluate/qualify/ harmonise/
argument/assess/ Goal/ faithful utilisation
internal quality/ Artifacts purpose/
external quality/ represented Explore/interprete/
function,
quality of use by model clarify/rationalise/
modality/confidence profile comprehend/clear up

Paradigms, Concepts, languages, cargo, routine, training, infrastructure, assumptions,

postulates,
culture, though community, thought style, pattern, methodology, guidelines, practice
restrictions,
background, Basis authorities,
foundations, conventions,
theories, commonsense
Grounding

Fig. 1. The matured model

The model house in Figure 1 displays these different facets of the model. It dis-
plays the matured or fully fledged model with grounding and basis as the fundament,
 The Conception of the Model 9

with four governing directives, with technical and technological pillars for develop-
ment and utilisation, and with the application roof The house consists of a cellar and
a fundament, two pillars, four driving or governing forces, and finally the deployment
roof. The grounding is typically implicitly assumed. It contains paradigms, the culture
in the given application area, the background, foundations and theories in the disci-
pline, postulates, (juristical and other) restrictions, conventions, and the commonsense.
The basis is the main part of the background. It is typically given for modelling. The
development uses a variety of methods for description, construction, evolution, corrob-
oration, and evaluation. The utilisation is based on methods for applying, prognosis,
reasoning, explanation, and exploration. We have used different verbs for classification
of the activities. The model can be used for completion of certain tasks. These tasks
may be combined into a model portfolio. The model is used for certain functions or
‘Gebrauchsspiel’ (application story or ‘game’). Finally, the model is governed by four
directives: artifacts, profile, community of practice, and context.
The nine properties of models can now naturally be represented:
The mapping property is one kind of model association.
The truncation property concentrates on abstraction as some kind of association.
The pragmatic property is given by the goal, community, and the context (time).
The extension property uses a specific partiality of mapping into instead of being
surjective.
The distortion property is a specific kind of mapping related to the goal.
The idealisation property is another specific kind of mapping.
The carrier property relates the model to its grounding and basis.
The added value property is one kind of combined quality.
The purpose property is a more explicit part of the pragmatic property.

3.7 Pre-Models
Pre-models are artifacts that do not contain an elementary model. In literature they
are often called “models”. They leave however out many essential parts and can thus
be misinterpreted, misunderstood, and misleading. The conclusions drawn with such
models are often doubtful or spurious.
Metaphors, similes and allegories are often considered to be models. They are how-
ever presented without a clear grounding, context or profile. The artifacts are often
incomplete. There development methods are left out. The community of practice is
only partially given. Furthermore, the basis is partially given. This situation can also be
observed in other disciplines.
Models might have a profile that consists only of goals. Methods for development
and utilisation are thus not necessary. The deployment is then vague. Illustrations are
typical models of the restricted applicability.

3.8 Elementary Models and Elementary Pre-Models

Computer Science models often do not discuss the basis or grounding. For instance, the
basis of Turing machines includes a number of implicit principles such as composition-
ality, functional or relational state transformations, step-wise computation, and context-
freeness. One of the guiding implicit postulates is the Von-Neumann-machine and its
10 Bernhard Thalheim

sequentiality. The purpose of the Turing machine model is a theory of computability

and complexity. Construction of real machines is beyond its purpose. Instead, the ab-
stract state machine approach explicitly uses the three guiding postulates for sequential
computation (postulates of sequential time, of abstract state, of bounded exploration
of the state space)[5]. These postulates may be extended to postulates for parallel and
concurrent computation, e.g. by extending the last postulate to the postulate of finite
exploration.
Mathematical models are often built around elementary models2 . The main interest
of these models is utilisation and partially deployment. A systematic and well-founded
development frame has been presented in [16]. [27] discusses an evaluation frame and
a guide to assessment of mathematical models. A similar observation can be made for
missing profiles, e.g. goals, purposes, or functioning.
Figure 2 depicts the relationship of pre-models and elementary (pre-)models to the
matured model3 . Some mathematical models might also be pre-models. Pre-models can
become mathematical models if at least the profile is given.

Deployment & portfolio Deployment & portfolio

Con- Con-
CoP CoP
text text
Development

Development
Utilisation

Utilisation
methods

methods

methods

methods
Model Model
M∗ M∗

M
...,1 , Pro- M
...,1 , Pro-
Mk file Mk file
Basis Basis
Grounding Grounding

Typical pre-models Some mathematical models

Fig. 2. Pre-models and elementary models compared to matured models in Figure 1

4 Conclusion
In this paper we introduced the conception of a model. This paper completes [22–24] by
an explicit definition of the conception of the model, by separation of concern within the
2
The classification of mathematical models seems to be very rigid. Development methods are
typically not a matter for mathematicians. The basis and the grounding are of very partial
interest. The classical scenario in mathematical modelling is: receive a model and application
problems; transform the model and one of the problems to a system of mathematical notions;
analyse, simulate and solve the selected problem; interpret the solutions within the received
model and problems.
3
We use the gray colour for explicit presentation of rudimentary elements of these models.
Missing parts are not shown at all.
 The Conception of the Model 11

‘model house’, and by explicit exclusion criteria for artifacts that can not be considered
to be models. This conception has been applied and tested in Computer Science, Phi-
losophy, Physics, and other sciences. So far we discovered that the notion is sufficient
and necessary and thus serves requirements for becoming a definition. It has been not
our aim to define a complete formal theory. Each term used in the paper needs however
such formal underpinning. The formal theory is however a straightforward application
of Discrete Mathematics and thus not a goal for a conference paper. The description
and the theory of methods used either for development of models or for utilisation of
models is a challenging research issue and cannot be handled yet.
We have been aiming at development of a formal notion of a model. Such formal
notion is necessary whenever we need a theory of modelling. It allows to exclude arti-
facts to become a model outside the judgement frame. It allows also to state when an
artifact is a model and what is necessary for an artifact to become a model.

References
1. D. Abts and W. Mülder. Grundkurs Wirtschaftsinformatik : Eine kompakte und praxisorien-
tierte Einführung. Vieweg, 2004.
2. J. Agassi. Why there is no theory of models. In I. Niiniluoto W.E. Herfel, W. Krajewsky and
R. Wojcicki, editors, Theories and Models in Scientific Processes, pages 17–26, Amsterdam-
Atlanta, 1995.
3. P. Alpar. Computergestützte interaktive Methodenauswahl. PhD thesis, Frankfurt Main
Univ., 1980.
4. J. Becker and R. Schütte. Handelsinformationssysteme : Domänenorientierte Einführung in
die Wirtschaftsinformatik. Moderne Industrie, 2004.
5. E. Börger and R. Stärk. Abstract state machines - A method for high-level system design and
analysis. Springer, Berlin, 2003.
6. A. Dahanayake and B. Thalheim. Co-evolution of (information) system models. In EMM-
SAD 2010, volume 50 of LNBIP, pages 314–326. Springer, 2010.
7. I.A. Halloun. Modeling Theory in Science Education. Springer, Berlin, 2006.
8. R. Kaschek. Konzeptionelle Modellierung. PhD thesis, University Klagenfurt, 2003.
Habilitationsschrift.
9. P. Loos, P. Fettke, B. E. Weißenberger, S. Zelewski, A. Heinzl, U. Frank, and J. Iivari. Welche
Rolle spielen eigentlich stilisierte Fakten in der Grundlagenforschung der Wirtschaftsinfor-
matik? Wirtschaftsinformatik, 53(2):109–121, 2011.
10. B. Mahr. Information science and the logic of models. Software and System Modeling,
8(3):365–383, 2009.
11. B. Mahr. Intentionality and modeling of conception. In Judgements and Propositions. Logi-
cal, Linguistic, and Cognitive Issues. Logos, 2010.
12. E. Ortner. Melchios - Methodenneutrale Konstruktionssprache für Informationssysteme.
Technical Report Bericht 60-94, Universität Konstanz, Informationswissenschaft, 1994.
13. T. Ritchey. Outline for a morphology of modelling methods -Contribution to a general theory
of modelling. Acta Morphologica Generalis, 1(1):1–20, 2012.
14. K.-D. Schewe and B. Thalheim. Usage-based storyboarding for web information systems.
Technical Report 2006-13, Christian Albrechts University Kiel, Institute of Computer Sci-
ence and Applied Mathematics, Kiel, 2006.
15. B. Scholz-Reiter. Konzeption eines rechnergestützten Werkzeugs zur Analyse und Model-
lierung integrierter Informations- und Kommunikationssysteme in Produktionsunternehmen.
PhD thesis, TU Berlin, Informatik, 1990.
 12 Bernhard Thalheim

16. B.Ja. Sovetov and S.A. Jakovlev. Systems Modelling. Vysschaja Schkola, 2005. In Russian.
17. H. Stachowiak. Modell. In Helmut Seiffert and Gerard Radnitzky, editors, Handlexikon
zur Wissenschaftstheorie, pages 219–222. Deutscher Taschenbuch Verlag GmbH & Co. KG,
München, 1992.
18. W. Steinmüller. Informationstechnologie und Gesellschaft: Einführung in die Angewandte
Informatik. Wissenschaftliche Buchgesellschaft, Darmstadt, 1993.
19. B. Thalheim. Entity-relationship modeling – Foundations of database technology. Springer,
Berlin, 2000.
20. B. Thalheim. The conceptual framework to user-oriented content management. Series Fron-
tiers in Arificial Intelligence, 154, Information Modelling and Knowledge Bases, XVII:30–
49, 2007.
21. B. Thalheim. Model suites for multi-layered database modelling. In Information Modelling
and Knowledge Bases XXI, volume 206 of Frontiers in Artificial Intelligence and Applica-
tions, pages 116–134. IOS Press, 2010.
22. B. Thalheim. Towards a theory of conceptual modelling. Jour-
nal of Universal Computer Science, 16(20):3102–3137, 2010.
http://www.jucs.org/jucs 16 20/towards a theory of.
23. B. Thalheim. The theory of conceptual models, the theory of conceptual modelling and
foundations of conceptual modelling. In The Handbook of Conceptual Modeling: Its Usage
and Its Challenges, chapter 17, pages 547–580. Springer, Berlin, 2011.
24. B. Thalheim. The science and art of conceptual modelling. In A. Hameurlain et al., editor,
TLDKS VI, number 7600 in LNCS, pages 76–105. Springer, Heidelberg, 2012.
25. M. Thomas. Modelle in der Fachsprache der Informatik. Untersuchung von Vor-
lesungsskripten aus der Kerninformatik. In DDI, volume 22 of LNI, pages 99–108. GI,
2002.
26. O. Thomas. Das Modellverständnis in der Wirtschaftsinformatik: Historie, Literaturanal-
yse und Begriffsexplikation. Technical Report Heft 184, Institut für Wirtschaftsinformatik,
DFKI, Saarbrücken, Mai 2005.
27. C. von Dresky, I. Gasser, C. P. Ortlieb, and S Günzel. Mathematische Modellierung: Eine
Einführung in zwölf Fallstudien. Vieweg, 2009.
28. R.T. White. Commentary: Conceptual and conceptional change. Learning and instruction,
4:117–121, 1994.
29. L. Wittgenstein. Philosophical Investigations. Basil Blackwell, Oxford, 1958.
30. S. Zelewski. Kann Wissenschaftstheorie behilflich für die Publikationspraxis sein?
In F. Lehner and S. Zelewski, editors, Wissenschaftstheoretische Fundierung und wis-
senschaftliche Orientierung der Wirtschaftsinformatik, pages 71–120. GTO, 2007.

Acknowledgment. We would like to thank the colleagues from the Christian-Albrechts University at Kiel for the
fruitful discussions on many facets of models in archeology, arts, biology, chemistry, computer science, economics, elec-
trotechnics, environmental sciences, farming, geosciences, historical sciences, languages, mathematics, medicine, ocean sci-
ences, pedagogical science, philosophy, physics, political sciences, sociology, and sports. We are thankful to the International
Institute of Theoretical Cardiology (IIfTC) for the evaluation of our approach. These discussions lasted in weekly ‘Tuesday’
open-end-evening seminars over the last three years from 2009 until now and in monthly seminars at the IIfTC. They resulted
in a general understanding of the notion of a model in most sciences, engineering and technology.

View publication stats