4.4 Variables and Functions
65
that it will not automatically transfer to the new variable all the properties of the
prototype one, for example, its physical dimensions; however, this transfer can be
taken care of when creating the data storage.
Coming to the class vov:function, which concerns relations between variables,
in the case of classical particle-based models such a concept is mostly needed
in the processing of data:
8 in Fig. 4.3, one can see classes such as vov:trajectory,
vov:pair_distribution_function and vov:autocorrelation_function. The class
vov:field, that has a more central role in continuum models, is however relevant
also for particle-based ones: think, for example, of external spatially varying fields
or of the density and velocity fields that are obtained processing the raw results.
To clarify how the two VIMMP ontologies we are discussing in this chapter
are linked to each other, in Fig. 4.5, we highlight some classes from VISO and
VOV, together with the main relations between them. In Fig. 4.6, we illustrate the
same concepts with a more concrete example including individuals: the example
is about a Molecular Dynamics (MD) software tool (we imagine it to be called
“A_MD_TOOL”) which has certain features (e.g. a velocity-Verlet integrator and a
potential energy called “A_POTENTIAL”) that in turn relate to variables (e.g. the
simulation time step or the mass and velocity of an interaction site). These variables
can extend to the whole system or be limited in scope to a model object. Considering
the variable usage, the time step is a vov:solver_variable, whereas the site mass is a
vov:model_variable. The idea behind the classification shown in Fig. 4.4 is to help to
identify the variables that affect the physics of the system from those that do not,
9
or should not, and to recognize which part of the governing equations they enter. So,
as soon as a variable is involved in some feature, we can infer which class it belongs
to; however, since the classes are not disjoint, we cannot exclude it belongs to the
sibling class too.
We note at this point the general and somewhat obvious, but practically relevant,
fact that there is a delicate trade-off between the looseness of concept definitions and
the ability to make informative inferences; and that is even more so given the assumptions under which ontologies by construction work
10 [34]. That is, to be able to make
stringent inferences, we need to make explicit statements about class disjointness,
individuals being different and so on. Otherwise, we can still extract information, but
8 Following RoMM nomenclature, “processing” comprises any manipulation of the raw data obtaining solving the governing equations [30].
9 In this respect, we note that even what looks like the most harmless of all concepts, the number
of particles entering a simulation, poses already a classification problem: while for some finite
systems the number of simulated particles has indeed a physical relevance and therefore should
belong to the model; in other cases, as for infinite systems, it is more appropriately seen as a solver
parameter, not different from the number of grid points used to solve differential equations. Within
VOV, this and similar variables belong to the class vov:system_composition_variable and are
not automatically classified as model/solver ones.
10 In frameworks like the Semantic Web, where information is expected to be distributed across
multiple and heterogeneous resources, two assumptions are typically made: one assumes that there
could be more information out there, beyond the currently accessible one (Open World Assumption) and that individuals may be named differently in different contexts (Non-Unique Naming
Assumption) [34].
65
that it will not automatically transfer to the new variable all the properties of the
prototype one, for example, its physical dimensions; however, this transfer can be
taken care of when creating the data storage.
Coming to the class vov:function, which concerns relations between variables,
in the case of classical particle-based models such a concept is mostly needed
in the processing of data:
8 in Fig. 4.3, one can see classes such as vov:trajectory,
vov:pair_distribution_function and vov:autocorrelation_function. The class
vov:field, that has a more central role in continuum models, is however relevant
also for particle-based ones: think, for example, of external spatially varying fields
or of the density and velocity fields that are obtained processing the raw results.
To clarify how the two VIMMP ontologies we are discussing in this chapter
are linked to each other, in Fig. 4.5, we highlight some classes from VISO and
VOV, together with the main relations between them. In Fig. 4.6, we illustrate the
same concepts with a more concrete example including individuals: the example
is about a Molecular Dynamics (MD) software tool (we imagine it to be called
“A_MD_TOOL”) which has certain features (e.g. a velocity-Verlet integrator and a
potential energy called “A_POTENTIAL”) that in turn relate to variables (e.g. the
simulation time step or the mass and velocity of an interaction site). These variables
can extend to the whole system or be limited in scope to a model object. Considering
the variable usage, the time step is a vov:solver_variable, whereas the site mass is a
vov:model_variable. The idea behind the classification shown in Fig. 4.4 is to help to
identify the variables that affect the physics of the system from those that do not,
9
or should not, and to recognize which part of the governing equations they enter. So,
as soon as a variable is involved in some feature, we can infer which class it belongs
to; however, since the classes are not disjoint, we cannot exclude it belongs to the
sibling class too.
We note at this point the general and somewhat obvious, but practically relevant,
fact that there is a delicate trade-off between the looseness of concept definitions and
the ability to make informative inferences; and that is even more so given the assumptions under which ontologies by construction work
10 [34]. That is, to be able to make
stringent inferences, we need to make explicit statements about class disjointness,
individuals being different and so on. Otherwise, we can still extract information, but
8 Following RoMM nomenclature, “processing” comprises any manipulation of the raw data obtaining solving the governing equations [30].
9 In this respect, we note that even what looks like the most harmless of all concepts, the number
of particles entering a simulation, poses already a classification problem: while for some finite
systems the number of simulated particles has indeed a physical relevance and therefore should
belong to the model; in other cases, as for infinite systems, it is more appropriately seen as a solver
parameter, not different from the number of grid points used to solve differential equations. Within
VOV, this and similar variables belong to the class vov:system_composition_variable and are
not automatically classified as model/solver ones.
10 In frameworks like the Semantic Web, where information is expected to be distributed across
multiple and heterogeneous resources, two assumptions are typically made: one assumes that there
could be more information out there, beyond the currently accessible one (Open World Assumption) and that individuals may be named differently in different contexts (Non-Unique Naming
Assumption) [34].