62
4 Semantic Technology for Simulations and Molecular Particle-Based Methods
the objects, not on what they represent: this is a convenient point of view from the
mathematical and numerical sides. Of course, to choose the appropriate Materials
Relation we still need to know what the object represents.
Moving on to interactions, we highlight the classes viso-am:potential,
viso-am:composite_potential and viso-am:non_conservative_force (cf. Fig. 4.2): the
first one refers to the mathematical expression (functional form) of a potential energy
and its elements are used as building blocks for elements of the second class; the second refers to a potential that is defined by more than just one single functional form
acting between a pair of species; the last one refers to forces, typically appearing in
coarse-grained models, that cannot be written in terms of a potential. Special cases
of composite potentials are what in computational chemistry are known as Force
Fields (called Interatomic Potentials in Physics): viso-am contains classes for some
of the most popular ones [32].
So far, we have given examples that pertain to the materials relation, i.e. subclasses
of viso-am:materials_relation_trait. Below viso-am:external_condition_trait, we find
concepts as the boundary conditions, external fields and potentials, and the thermodynamic ensembles (cf. Fig. 4.2).
The class hierarchy for the solver features is much simpler than that for the model
ones, being just a list of classes (including viso-am:integrator, viso-am:minimi-zation,
…), each populated by various individual algorithms.
6 We underline at this point
that the splitting into solver and model features is not always straightforward, since it
depends on how much relevance is given to an ingredient of the method: a prototypical
example is that of thermostats, which are typically considered as purely numerical
aspects, but have a central role for models such as Dissipative Particle Dynamics
(cf. the discussion in [31]). To circumvent this problem and allow for different
views while keeping solver and model features separated, we define in VISO the
relation viso:is_modelling_twin_of.
Within VISO, we intentionally don’t go beyond a certain level of detail in the
description of software; in particular, the variables entering the models and algorithms
are dealt with by the VOV ontology, presented in the next section.
4.4 Variables and Functions
The purpose of the Vimmp Ontology of Variables (VOV)
7 is to organize the variables
(in a broad sense, including constants) that appear in modelling and simulations, and
to connect them to models and algorithms in which they are involved and to model
objects (e.g. entities entering a simulation, such as sites, rigid bodies) which they
are attached to. VOV can be used in connection with VISO and OSMO to further
specify models, algorithms and workflows. The main concepts from VOV are:
6 We recall that individuals are not visible in the figures produced with OWLViz.
7 VOV: https://purl.vimmp.eu/semantics/vov/vov.ttl (non-resolvable IRI), mirrored at http://www.molmod.info/semantics/vov.ttl (resolvable URL).
4 Semantic Technology for Simulations and Molecular Particle-Based Methods
the objects, not on what they represent: this is a convenient point of view from the
mathematical and numerical sides. Of course, to choose the appropriate Materials
Relation we still need to know what the object represents.
Moving on to interactions, we highlight the classes viso-am:potential,
viso-am:composite_potential and viso-am:non_conservative_force (cf. Fig. 4.2): the
first one refers to the mathematical expression (functional form) of a potential energy
and its elements are used as building blocks for elements of the second class; the second refers to a potential that is defined by more than just one single functional form
acting between a pair of species; the last one refers to forces, typically appearing in
coarse-grained models, that cannot be written in terms of a potential. Special cases
of composite potentials are what in computational chemistry are known as Force
Fields (called Interatomic Potentials in Physics): viso-am contains classes for some
of the most popular ones [32].
So far, we have given examples that pertain to the materials relation, i.e. subclasses
of viso-am:materials_relation_trait. Below viso-am:external_condition_trait, we find
concepts as the boundary conditions, external fields and potentials, and the thermodynamic ensembles (cf. Fig. 4.2).
The class hierarchy for the solver features is much simpler than that for the model
ones, being just a list of classes (including viso-am:integrator, viso-am:minimi-zation,
…), each populated by various individual algorithms.
6 We underline at this point
that the splitting into solver and model features is not always straightforward, since it
depends on how much relevance is given to an ingredient of the method: a prototypical
example is that of thermostats, which are typically considered as purely numerical
aspects, but have a central role for models such as Dissipative Particle Dynamics
(cf. the discussion in [31]). To circumvent this problem and allow for different
views while keeping solver and model features separated, we define in VISO the
relation viso:is_modelling_twin_of.
Within VISO, we intentionally don’t go beyond a certain level of detail in the
description of software; in particular, the variables entering the models and algorithms
are dealt with by the VOV ontology, presented in the next section.
4.4 Variables and Functions
The purpose of the Vimmp Ontology of Variables (VOV)
7 is to organize the variables
(in a broad sense, including constants) that appear in modelling and simulations, and
to connect them to models and algorithms in which they are involved and to model
objects (e.g. entities entering a simulation, such as sites, rigid bodies) which they
are attached to. VOV can be used in connection with VISO and OSMO to further
specify models, algorithms and workflows. The main concepts from VOV are:
6 We recall that individuals are not visible in the figures produced with OWLViz.
7 VOV: https://purl.vimmp.eu/semantics/vov/vov.ttl (non-resolvable IRI), mirrored at http://www.molmod.info/semantics/vov.ttl (resolvable URL).