Environmental Engineering Reference
In-Depth Information
Technological requirements:
-
The component software implementation must be made using technologies with
a widespread adoption.
There are several ways of matching the above requirements via software design and
implementation. In the next sections we list the major choices made for the design
and implementation of static and dynamic components developed for APES.
Ontology
A pre-condition of the successful integration and re-use of an existing component
is that the modeller understands the meaning of the data elaborated by the model.
Understanding means associating a variable with a shared concept, knowing its
spatio-temporal extent, its dimension and units and so on. In order to facilitate this,
the components must contain information, possibly extracted from a public ontology,
which describes the variables/parameters used, and allows checks on input-output
links and data quality tests at run time. Information consists of concepts (variables
in this case, which can be seen as instances of the concepts) and of attributes for each
variable, encapsulated using the VarInfo type implemented in a utility component.
VarInfo attributes are: Name, Description, Minimum/Maximum/Default value,
Units (Athanasiadis et al.
2006)
. The properties with respect to data flow are not
included among these attributes as they are not an intrinsic attribute of the variable.
In other words, a variable can be an input to one model, and an output from another.
This information from VarInfo is used in the domain classes described below.
The components also contain internal information about parameters and variables,
using the same VarInfo type. Such information is defined in the component and used
as described in the section on pre- and post-conditions. Collections of variables
that are associated with particular domains define the Domain Classes (Del Furia
et al.
1995)
. For instance, we could define
SoilStates
as the collection of all measure-
ments relevant to a specific goal chosen for soil modelling. Such collections can be
manually entered by a user or automatically created, using the built-in reasoning
features of the ontology. The definition of domain classes in the component
interface allows the dependency of the model to be abstracted from the data and the
extensibility of models fostered using design patterns (Mesketer
2004
; Bishop
2008)
.
The importance of domain classes goes beyond their meaning as software imple-
mentation items. In fact they provide a detailed description of the domain of interest.
Using domain classes, a modeller can exploit the knowledge structured in the ontology
in different modelling frameworks and programming languages. The adoption of an
ontology-driven approach for defining a model interface has clear advantages as it
enables the reusability of models in an easier way, while common problems related
to poor semantics of model interfaces can be effectively tackled.
The APES ontology is browsable on the web at a dedicated page (see Web
resources) in which each domain class and strategy is described using the VarInfo
values of their variables and parameters.
