pdf: 600KB - Potsdam Institute for Climate Impact Research

37
Figure 7.1 is a partial view of the ontology underlying Simile's model-representation language.
This is presented in the form of a screen dump from Protegé, one of a number of software
packages specifically developed for ontology design. It shows, on the left, the taxonomy of
model-building elements: for example, it shows that compartment is a type of node. On the
right, we see more information for the selected class, including its 'slots' (attributes) and some
free-form text. We see that compartment has the attributes label, complete, ID, position and
size. label and ID are string (character) attributes. complete (denoting whether the element has
the required mathematical information associated with it) is a Boolean (true/false) attribute.
position and size are defined by another class, which in turn represent the fact that each has two
numeric values. Each slot is required to have a single value.
We can evaluate Simile against the design criteria. Its model-representation language is very
expressive: a wide range of ecological and environmental simulation models can be represented in
it (Muetzelfeldt 2003). It is parsimonious, having a language based on only some 12 symbols.
And it is pretty intuitive, using the widely-used System Dynamics notation plus a clear symbolism
for representing objects.
7.4 Designing the model-representation language: syntax
The ontology defines what we might consider to be the abstract language: the set of concepts that
our language is capable of representing. In order for models to be actually represented on a
computer, we require a syntax for statements in the language. This might be in binary form -
written and read only by a computer program - or it could be in text form, so that it can be
processed both by computers and also by humans (entered using a word processor, and printed
out).
A few years ago, a group of people designing a new language might very well have come up with
a new syntax, without regard to the syntax of languages designed for other purposes. For
example, the statement
compartment: name=biomass, initial=100
might represent the fact that the model contains a compartment 'biomass' with an initial value of
100.
Over the last few years, however, there has been a huge increase in the use of XML (the
eXtensible Markup Language) as a metalanguage within which other languages can be
expressed. Section 6.7 introduces XML notation for representing model structure, and Appendix
A2 provides some more detail. I simply reiterate here that XML is the obvious metalanguage to
use for representing simulation models. Not only does it give access to the technologies
developed around it, but it also means that some parts of the notation exist already, such as the use
of MathML [see URLs] for representing equations.
There is not, however, a one-to-one correspondence between the ontology for a language and its
syntax, even given a commitment to the XML metalanguage. There are still many choices to be
made about representation, which will affect the readability of model description files (if that is
desired), the size of the files, and the ease of processing by software tools.
XML supports the concept of namespaces. In this context, this enables all the language elements
that relate to a particular modelling paradigm - such as System Dynamics - to be grouped together.
This means that groups developing software tools do not have to commit themselves to dealing
with all concepts that the full language supports: rather, one tool might restrict itself to (for
example) the System Dynamics namespace.