2004
Ser-
'uses
step
uire-
F this
] ab-
Xter-
> and
is for
perly
rele-
e one
ction
asily
n the
? Ser-
ion to
arin,
ssing
ichi-
itions
> spe-
e the
model
arvice
nodel
nt, in
d ser-
level-
of all
to be
ive to
iy be
neri
ene TIC
specific
hd ser-
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
EY]
metamodel
GSP node (a) =)
Te y
|
|
|
| |
GSP node(b) | «---------------- > |
born eid
model |
repository |
x i
| GSP node (...) 4&7
L
Figure 5: Role of the metamodel in the GSI architecture
achieved if the models are based on the same metamodel.
Such metamodel should therefore provide a rigourous ab-
stract syntax for defining models. Figure 5 shows the role
of the metamodel in the GSI architecture. The metamodel
enables the implementation of a repository where com-
pliant models of GSI services can be stored. Hence, the
repository becomes the central component in a GSI system.
The repository supports the exchange of models between
different service providers, thereby facilitating the use of
these models in combinations to form more complex ser-
vice models that address specialised sets of requirements.
A metamodel defines the set of design concepts and their
relationships, which one can use to produce models of some
system according to a specific objective. A design con-
cept, also called modelling concept, is a building block that
can be used in the construction of a model. A design con-
cept represents one or more related properties of a system
or system part that are considered relevant in the design
of a system. The complete collection of design concepts
should allow one to model all relevant system properties.
Relationships between design concepts define the possible
ways in which a model can be constructed from of these
concepts.
Which metamodel should be used depends on the mod-
elling needs of every particular project. For the purpose of
designing GSI systems, we require design concepts suit-
able for specifying the system’s functionality and its en-
vironment, the system’s internal structure in terms of its
composing parts or subsystems and their relationships, and
the contribution of each part to the system's overall func-
tionality. This translates into the following modelling needs:
e to represent the system, its logical or physical parts
and any external thing that interacts with the system,
which could be a person, another system, etc., as sin-
gle entities capable of exhibiting behaviour;
e to represent the locations where interactions between
different entities occur;
e to represent behaviour according to different related
abstraction levels;
1231
e to be able to discriminate between the behaviour and
the entity that carries the behaviour, such that an en-
tity could potentially exhibit multiple behaviours.
e to be able to structure behaviour into units behaviour
and their relationships;
e to represent anything that is used or produced in a be-
haviour.
Additionally, the selection of an appropriate set of design
concepts should adhere to the following quality principles
(van Sinderen, 1995):
e consistency, which requires that concepts should be
consistent in their representation of the aspects in the
real world;
e orthogonality, which requires that distinct concepts
should be used to represent different aspects;
e propriety, which requires that concepts should be proper
to the modelling needs;
e generality, which requires that concepts should be of
general purpose in a given domain and the complete
set of concepts be sufficient to cover the needs of the
domain.
S5 METAMODEL FOR GSI
The types of service provided by a GSI system spread along
the whole geo-information value chain. This value chain
starts with identification of information sources that are
used in different geo-processing tasks to create value added
geo-information products. These products are subsequently
used in various types of analysis with the purpose of deriv-
ing new information that is not directly obtainable from
the sources. In most of the cases diverse combinations of
tasks and information sources are required to solve specific
problems and help user communities to make sense of the
geographical world that surrounds them.
The structural organisation of this work is consequently
formed by arrangements of independent functions and data
sources organised in such way that large geo-processing
tasks can be accomplished. Any of these arrangements
defines a specific behaviour. This behaviour is accom-
plished through the creation, manipulation or transforma-
tion of some items or artefacts, and must be carried out by
entities within the system.
According to these criteria and to the modelling needs men-
tioned in the previous section, we need a metamodel to be
able to build repositories where our models can be prop-
erly, structurally and consistently stored and retrieved. We
introduce a metamodel to be used in the creation of repos-
itories to store our models (see Figure 6). This metamodel
is a specialisation of the ISDL metamodel (Quartel, 2003).
The metamodel is organised in a number of classes, where
each class addresses a group of related design concepts.
