pdf: 600KB - Potsdam Institute for Climate Impact Research

33
7. Architecture for a declarative modelling approach
The key to realising the vision for environmental modelling is this: to think of a model as a design
to be represented and processed rather than as a program to be run. This is the essence of the
declarative modelling approach.
Realising the vision thus depends on having two types of object: models; and modelling tools.
The model will be represented in some language; the tools need to be capable of reading,
processing and/or writing models represented in that language.
It is important to reiterate that, by its very nature, a declarative modelling approach has no
software core, no software package that users must install if they are to work with the approach.
If a community of ecosystem modellers commit to such an approach, the only thing that they are
committing to is a specification of the model-representation language. In effect, they are
committing to a standard, expressed in a standards document. They can then obtain and use
tools that adhere to this standard, but no individual tool is fundamentally required. There may be
a variety of tools available for building models; a variety for generating runnable versions of the
model and running simulations. In the near future, these tools will be available over the web, as
web services, so they won't even need to be installed on one's own computer. It is a highly
distributed and robust approach.
Section 7.1 considers the specification of requirements for a declarative model-representation
language. Sections 7.2 to 7.4 consider the development of an appropriate language: what
elements should the language be built upon? In Section 7.5 we consider the development of tools
for handling models represented in this language, while in Section 7.6 we consider one particular
type of tool - tools for simulating the behaviour of the declaratively-represented model. Finally,
Sections 7.7 and 7.8 are concerned with assembling a variety of tools together in a modelling
environment, and with publishing models on the web.
7.1 Requirements specification for a model-representation language
We need to define the scope of the language - what range of models should the language be able
to represent? At one extreme, we could restrict the language to sets of differential-algebraic
equations (DAE's). At the other, we could aim to include every type of model that has ever been
used in ecosystems research. Clearly, the more restricted the scope is, the easier it is to devise a
suitable language - but the less use it will be.
The Table 7.1 lists part of the requirements specification for the Simile visual modelling
environment (see Section 8). Some parts of the specification are expressed in the sort of terms
that modellers use to describe their models (e.g. "age-class model"). There is some overlap
between these terms, and equally well there are some other terms that modellers would use that
are not mentioned here. This does not matter too much, provided that the eventual design is
capable of handling the range of requirements. Other parts (such as modularity) refer to more
abstract features of the modelling language.
Note that, as we shall see in the next subsection, there is no obligation on us to have an element in
the language for each entry in the requirements specification. The point of the requirements
specification is to define what the language must be capable of representing, not how it represents
it. That comes next, when we define the ontology of the language.