Skip to main content
Erschienen in:
Buchtitelbild

Open Access 2021 | OriginalPaper | Buchkapitel

4. Semantic Technology for Simulations and Molecular Particle-Based Methods

verfasst von : Martin Thomas Horsch, Silvia Chiacchiera, Welchy Leite Cavalcanti, Björn Schembera

Erschienen in: Data Technology in Materials Modelling

Verlag: Springer International Publishing

Aktivieren Sie unsere intelligente Suche um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Abstract

In this Chapter we discuss the role of ontologies for simulations, in the context of materials modelling in general and of molecular particle-based methods in particular. After a brief overview of the literature and possible applications, we present the VIMMP ontologies that allow to describe software capabilities and to further specify the various algorithms via the involved variables: the VImmp Ontology of Software (VISO) and the Vimmp Ontology of Variables (VOV).

4.1 Brief Overview of Ontologies for Modelling and Simulation

Since the appearance of ontologies in computer science in the 90s [1], there have been proposals and endeavours to use them to describe modelling and simulation, with the aim to support the exchange of information both between people (communication) and between software (interoperability) [24].
As with any topic, clearly also in this case many different points of view can be adopted. Browsing the literature on the subject, we identify two major perspectives: taking a more philosophical approach, some authors focus on the process of modelling itself, as a cognitive process, and its relation to the physical world, see, e.g. [3]; on the other side, with a more application-oriented view, other authors focus on the structuring of models and simulations, giving for granted their connection to reality [2, 4].
The first perspective might seem surprising, but, in fact, there are various intellectual steps that are undertaken each time we use a numerical simulation to make predictions about a certain real problem: typically these involve abstraction and simplification, to arrive to a model (in the MODA sense) and then its conversion into a numerical implementation (see, for example, [57], where the steps of the first part, what Robinson calls conceptual modelling for simulation, are described). It is therefore relevant to be able to formally describe these steps explicitly, for example, to compare models involving different levels of abstraction, and to address model verification and validation.
Coming to the ontologies presented or referred to in this book, EMMO and VIVO are close in spirit to the first perspective, whereas the ontologies we will describe in this chapter, the VImmp Ontology of Software (VISO) and the Vimmp Ontology of Variables (VOV), are closer in spirit to the second one. Before describing them (in Sects. 4.3 and 4.4), we highlight in the following some existing ontologies and assets that have a similar purpose or scope.
In the area of physics and engineering, we would like to point out two ontologies: the pioneering PhysSys [2], which already gave a central role to theories such as mereology and topology and recognized the need for different viewpoints on a given problem, and the very recent Physics-based Simulation Ontology (PSO) [4], which uses the Basic Formal Ontology (BFO) [8] as an upper ontology and is split into two parts addressing the physical phenomena (PSO-Phys) and the simulation aspects (PSO-Sim). Both ontologies focus on what in the EMMC vocabulary are called continuum models.
Looking at solutions to characterize software in other domains, we find that, in logistics and manufacturing, discrete-event simulations are the object of the DeMO Ontology [9]; recent work capturing the point of view of a scientist end user has led to the Software Ontology (SWO) [10] for life sciences and to OntoSoft [11] for geosciences.
Moving to variables, we would like to recall the catalogue for Quantities, Units, Dimensions and Data Types Ontologies (QUDT) [12], which addresses among others dimensional analysis and a classification of units, and the Scientific Variables Ontology (SVO) [13, 14]. The latter originated analysing thousands of variables in the area of natural sciences, but provides a framework that can be, in principle, adapted to other fields.
With a focus on the software engineering aspects, we highlight instead the Software Engineering Ontology Network (SEON) [15], an ontology network based on the Unified Foundational Ontology (UFO) [16, 17]. Connected to SEON, a Reference Ontology on Object-Oriented Code (OOC-O) was recently proposed [18].
We note that the relation of some of these ontologies to our work is very concrete: in fact, concepts from SWO and QUDT are currently imported in VISO, VOV and other VIMMP ontologies (cf. Sects. 4.3 and 4.4).

4.1.1 Examples of Applications

As already explained in Chap. 1, ontologies are an explicit and formal way to represent knowledge in a certain domain. But how are they actually used in the context of simulations and modelling?
This question connects to the purpose the ontology is designed for and to technical aspects, such as the availability and choice of tools (for example, to connect ontologies to programming languages1). And it also poses the question whether we expect the end users to be (mainly) humans or machines.
Also, the use could be more or less direct: thinking, for example, of a database, a triplestore would make an immediate use of the ontology, whereas a less direct approach would be to take into account aspects of the ontology when designing the database.
We can get some insight on the possibilities by looking at the examples given above: OntoSoft [11] was used to design a platform to find and compare software [20]; the Simulation Intent Ontology [21] is used in connection with the CoGui tool [22] to automatize some steps in the simulation setup; finally, one of the perspective uses of SVO and the connected tools [13, 14] is to generate suitably formed variables starting from free-form text.
From the point of view of the source code, a perspective use of OOC-O is to support polyglot programming [18], i.e. the simultaneous use of multiple object-oriented programming languages.

4.2 Other Relevant Assets and Approaches

In the previous section, we limited the scope to ontologies; however, as discussed in Chap. 1, the semantic spectrum is wide, and along with them there are other relevant assets, which are technically different but similar in spirit, such as data schemas (cf. Chap. 2).
Also, we should recall different branches of a field that is sometimes referred to as conceptual modelling. Historically, in the ’60s–’70s, novel ideas setting the basis of this field appeared in different areas of computer science, namely, artificial intelligence, programming languages, databases, software engineering [23]: these ideas lead, among others, to the development of knowledge-representation languages, object-oriented programming and entity-relationship (ER) models (see [23] for a discussion of the pioneering ideas in each area and a brief history of the topic).
Even if the connections between these approaches are not always direct, the thinking behind their development is similar: so, for example, when building an ontology for a domain, it is definitely instructive to look also into object-oriented programs and schemas for such domain, and vice versa.
As an illustration of schemas for our area, we recall the Chemical Markup Language (CML) [24] and the ThermoML schema [25, 26], a IUPAC standard primarily developed at NIST. In the direction of object-oriented programs, a popular tool is the Atomic Simulation Environment (ASE) [27] which allows to set up, control, visualize and analyse simulations at the atomic and electronic level.
Another relevant topic is that of visual programming: a visual scheme is used to represent a model (in the general sense), but also to generate the source code (model-driven simulation). This operation can sometimes work also in the opposite direction, extracting the model from the source code, a form of reverse engineering.
Finally, in the area of software design and business modelling, it is important to recall the role of the Object Management Group (OMG) [28] that was formed 30 years ago; in particular, its activities lead to the development of the Unified Modeling Language (UML) [29] and an ecosystem of specifications based on it.
In a nutshell, UML allows to describe a system2 structure and behaviour via different types of diagrams. It was motivated as a unifying object-oriented language, and one of its main aims is to “advance the state of the industry by enabling object visual modeling tool interoperability” [29]. The visual aspect of the diagrams can be used to share ideas; however, these diagrams can also be given “life”, in the sense of visual programming.
The OMG standards are widely adopted and there are many (commercial and not) tools based on UML that allow, for example, to generate executable code, check the model and generate test suites.
Of course, “modeling” in the case of UML has a more general meaning (as abstraction) than as we intend it in the EMMC sense (as applied to materials and based on physics and mathematics). From the literature, we note that UML does not appear to be strongly connected to science applications, but it is probably used internally by professional software tools, including those commonly used in engineering.
Finally, an important contribution bridging between UML and ontologies is OntoUML, which is ontologically well-founded version of UML (more specifically, of the UML 2.0 fragment of class diagrams) [16, 17].

4.3 Software Capabilities

The aim of the VImmp Ontology of Software (VISO)3 is to characterize software tools in the area of materials modelling, especially their features (i.e. capabilities), intended both at the model and solver level, but also their technical requirements, compatibility with other tools and licensing aspects. The concepts defined within this ontology will, first, guide the ingest of information on the VIMMP platform, and, later, allow the users to retrieve and compare tools. Below an upper level (viso-general, cf. Fig. 4.1) that addresses aspects common to all software, we split VISO into three branches focusing on classes of models: electronic (EL, viso-el), atomistic and mesoscopic (AM, viso-am), and continuum (CO, viso-co) models.4 These branches depend on viso-general, but can be loaded independently of the other two siblings. We underline that both VISO and VOV (presented in the next section) are designed to address models from the four granularity levels of RoMM [30]. However, in this book, we especially focus on its AM branch, which deals with molecular models and particle-based methods; for more details on the other branches, we refer the reader to [31] and to a recent VIMMP ontology release [32, 33].
Accordingly, selected major concepts from viso-general are:
  • viso:software: a computer program. Its direct (mutually disjoint) subclasses are: viso:software_tool, viso:compiler, viso:operating_system.
  • viso:programming_language: a language that can be used to write software.
  • viso:software_tool_feature \(\equiv \) (viso:model_feature \(\sqcup \) viso:solver_feature): a capability of a software tool, intended as either a model aspect that can be addressed (viso:model_feature) or as a numerical algorithm which is implemented (viso:solver_feature). Following the approach from RoMM [30], these two classes are disjoint.
  • viso:model_type: a classification of the model, intended as in RoMM [30].
  • viso:model_object: the type of object entering the model and carrying degrees of freedom. Its subclasses in the AM branch (cf.  Fig. 4.2) include viso-am:interaction_ site, viso-am:interaction_surface, viso-am:connected_object.
  • viso:software_update: it describes (as text) the changes between versions of a software. In particular, its subclass viso:software_tool_update allows to describe the addition/removal of features from a tool.
  • viso:software_interface: an interface between a software and a user or a client (i.e. a program or device). Some subclasses of this class are taken from the SWO software interface class (swo:SWO_9000050) [10].
  • viso:license: a regulation of the right to use, modify and distribute something, in this case software. It is declared to be equivalent to the Software Licence class from SWO (swo:SWO_0000002), cf.  Malone et al. [10].
  • viso:license_clause: it is equivalent to the Licence clause class from SWO (swo:SWO_9000005), cf.  Malone et al. [10].
Selected relations (object properties) from VISO are:
  • viso:has_feature points to a (model or solver) feature of a tool. Domain: viso: software_tool; range: viso:software_tool_feature.
  • viso:is_compatible_with relates two tools that are able to exchange information directly, with no need to interface. Domain and range: viso:software_tool.
  • viso:involves, i.e. (X involves Y) means that there is a mathematical expression or an algorithmic formulation of X that contains Y. Domain: viso:software_tool_ feature \(\sqcup \) viso:modeling_related_entity; range: vov:variable \(\sqcup \) vov:function \(\sqcup \) viso: model_object.
  • viso:is_tool_for_model associates tools with models. Domain: viso:software_tool; range: viso:model_type.
  • viso:requires relates a tool to libraries and/or operating systems. Domain: viso:software_tool; range: viso:software.
  • viso:is_modelling_twin_of relates two objects that (despite being possibly distinct individuals) are equivalent from the modelling point of view.
The upper part of VISO also contains a number of datatype properties, mostly Boolean ones (e.g. viso:is_free, viso:has_a_gpu_version), but not only (e.g. viso:has_main_name, viso:has_version_identifier) to characterize the software [32].
Below viso:general, the EL, AM and CO branches of VISO expand on the categories viso:model_feature, viso:solver_feature and viso:model_type (cf.  Fig. 4.2 for the AM one). These classes are the richest ones of VISO, and they contain most of the concepts that are peculiar to our domain. The three branches have a common structure, in that the subclasses of viso:model_feature are further classified into (non-disjoint) classes of viso:materials_relation_trait, viso:physical_equation_trait and viso:external_condition_trait. For clarity, we systematically use trait here, and not aspect, since the latter keyword has a different and well-defined role within OSMO and MODA.
In the last part of this section, we look into more detail at the viso-am branch, which was designed considering Molecular Dynamics, Molecular Mechanics, Dissipative Particle Dynamics and Monte Carlo methods. First of all, our choice to treat together the atomistic and mesoscopic models is motivated by the fact that in many cases they rely on the same numerical methods and a given software tool can address both. Also, the meaning of “mesoscopic” within RoMM is different from the usual acceptation: as soon as two or more atoms are grouped into an entity, this is considered a mesoscopic model; since united-atom models already fall into this class, treating these two granularity levels jointly seems well justified.
It is important to underline that the RoMM [30] classification principle is based on what a modelling entity represents, a criterion that is indeed well suited to multi-scale modelling. A complementary and quite natural classification could be based on the mathematical nature of the modelling entity: for example, the classical models could be distinguished in particle-based and field-based ones. While as a rule of thumb AM models are particle-based and CO models are field-based, typically there are also fields in AM models, discrete particles in CO and classical particles in EL ones. Above all, it is important to realize that the two classifications are fundamentally different: to give an extreme example, we could have a particle-based model of the solar system, where each particle represents a planet!
In this direction, an important concept in VISO is that of viso:model_object5 (cf.  Fig. 4.2) which is the type of object entering the model and carrying degrees of freedom. To be able to encompass different chemical objects, we need to adopt a neutral vocabulary; in the AM branch, we choose to use viso-am:interaction_site to indicate a point which is involved in (experiences) some interaction; it can represent the centre of a physical particle (an atom, a coarse-grained bead), but also be a fictitious particle. Similarly, a viso-am:connected_object, where connectedness is via bonds of some type, could be a molecule (in the chemical sense) or an aggregate. Finally, we have viso-am:interaction_surface, which is a surface affecting the interactions and is treated as continuum, not as a collection of sites; for example, it could be a wall. It is clear that our approach focuses on the mathematical nature of 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:minimization, ...), 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:
  • vov:variable: a variable in the mathematical sense, i.e. a symbol that stands for a quantity in a mathematical expression.
  • vov:function: a relation between two or more variables (e.g. the radial distribution function, the energy density of states); it can be defined via a mathematical equation or via tabulated values. Its subclasses (cf.  Fig. 4.3) include vov:field.
Variables in VOV can be classified according to three main criteria: by their scope (vov:object_variable, vov:pair_variable, vov:system_variable, vov:universal_variable), their rank (vov:scalar_variable, vov:vector_variable, vov:tensor_variable) or their basilar kind (vov:mass, vov:energy, ...), for which qudt:QuantityKind is used [12]. In Fig. 4.3, we show the splitting of vov:variable according to scope and the subclasses of vov:function. A different classification, also present in VOV and shown in Fig. 4.4, distinguishes variables based on the nature of the features they are involved in, as that is stated in VISO. Since a variable can be involved in multiple features of different nature, clearly the two main classes (vov:model_variable and vov:solver_variable) are not disjoint. Also, the vov:model_variable class is further split, mirroring in this way the hierarchy of model features in VISO.
Selected relations (object properties) from VOV are:
  • vov:has_attached_variable points to a variable that is carried by/attached to an object. Its subproperties include vov:has_mass, vov:has_position and vov:has_ velocity. Domain: viso:model_object; range: vov:object_variable.
  • vov:has_attached_function points to a function that is carried by/attached to an object. Its subproperties include vov:has_velocity_field and vov:has_wavefunction. Domain: viso:model_object; range: vov:function.
  • vov:shares_value_with indicates that two variables have the same numerical value. Domain and range: vov:variable.
  • vov:shares_role_with indicates that two variables have the same role in the model or solver. This property can be used to instantiate variables that are already defined in VOV as individuals and to connect them to those. Domain and range: vov:variable.
Note that both relations specify viso:involves, i.e. vov:has_attached_variable \(\sqsubseteq \) viso:involves and
vov:has_attached_function \(\sqsubseteq \) viso:involves.
For properties such as the particle species (in a broad sense, chemical species in atomistic models, particle/object type in general), label and index, we use datatype properties (vov:has_species, vov:has_label, vov:has_index).
While for some typical variables it makes sense to define in the ontology named individuals, in other cases it is necessary to allow the user the freedom to define new ones. Accordingly, VOV provides different mechanisms to define the needed variables: one can directly use variables that are present in VOV as individuals (e.g. vov:TARGET_TEMPERATURE) or introduce customized ones populating VOV classes (e.g. defining elements of vov:object_mass). A third approach is to characterize the value and role of new variables using the relations vov:shares_value_with and vov:shares_role_with. The last method, while very convenient, has the drawback 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 work10 [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 with the limitations just described. So far for inferences; nevertheless, of course, there is always the possibility to make explicit negative statements about variables and other concepts (using owl:complementOf, or owl:NegativePropertyAssertion, available in OWL2).

4.4.1 Simulation Variables vs Physical Properties

We open here a parenthesis to discuss the relation between the variables entering a simulation and the physical properties of real-world objects; this naturally leads to a comparison of simulations and experiments.
Let’s consider, for example, a certain material (say, liquid water) and focus on its electric permittivity \(\epsilon \). The latter is a quantity that appears in electrostatic and electrodynamic laws (e.g. Coulomb’s law), and can be measured experimentally based on them.
When designing a model for such material that, in particular, captures its electric permittivity, different approaches are possible: (a) we might take \(\epsilon \) as fixed (a model parameter, a constant needed as an input), or (b) we could design a model containing dynamic degrees of freedom that carry electric dipoles, so that \(\epsilon \) is an emergent property, and the input of the model is instead the properties of the degrees of freedom, possibly fictitious particles. In both cases, \(\epsilon \) will be matched to the experimental value: in one case directly, and in the other by tuning the parameters associated with the simulated entities.
In the case (b), the value of \(\epsilon \) can be estimated using liquid-state theory and computed from simulations using linear response theory: both procedures are quite far from what is done experimentally. However, a way to test that the model actually behaves as it should is to compute the reduction in the force between two fixed ions due to the presence of the medium; the same test can be done in the case (a), as a basic check of the numerical implementation of electrostatics, for example.
Now, is this so different from an experiment done on the material? Simulations, especially those involving some stochastic element, are in many ways similar to experiments, for example, they also require several repetitions and their results are affected by statistical errors.
In our view, the concept of observation (which includes measurement) in the EMMO could be generalized to accommodate also calculations (analytical and numerical ones), and the variables entering the models (both as input and output) that are numerical counterparts of physical properties could be recognized as such.

4.5 EngMeta and VIMMP Ontologies

The EngMeta scheme described in Chap. 2 and the VIMMP ontologies presented in this and in the previous chapter have a relevant overlap in scope, with similar keywords appearing in both assets. From Fig. 2.​2, one can see that EngMeta includes concepts that on VIMMP side are addressed by different ontologies, in particular, OTRAS (e.g. author, publication, citation), VISO (e.g. software, force-field), VOV (e.g. variable), MMTO (e.g. project), OSMO (e.g. system component/material) and VICO (e.g. persons and organizations). The technical metadata (e.g. file size, checksum), instead, are mostly tackled by the Zontal storage itself [35, 36].
At the syntactic level, we are comparing an XSD schema and OWL DL ontologies: what are entities (say, “Software”) and attributes (say, “license” and “softwareVersion”) within EngMeta, typically correspond to classes within VIMMP ontologies (in this case, viso:software_tool) and to the objects or data a relation points to (in this case, a viso:license, pointed to by viso:has_license and a xs:string, pointed to by viso:has_version_identifier).
In general, to match or integrate two assets that, like here, differ syntactically and (even if slightly) semantically, one can think of performing the operation in two steps: a syntactic conversion first, then a semantic matching or integration (cf. Sect. 5.​3).

4.6 Closing Thoughts

Clearly, there are many concepts involved here: formalization, standardization and automation. One could argue that for the domain we are interested in, i.e. simulations of materials, physics and mathematics are already universal languages: why, where and what kind of further formalization and standardization are needed?
For example, imagine we are given a set of equations that models the mixing of two fluids in an industrial device. Even if the mathematical formulation will be accessible to everybody with a scientific background, this does not capture the context the model is embedded in (in fact, the simulation intent, the assumptions and approximations made are normally expressed in natural language in an accompanying paper), and understanding it will require delving into a jungle of details. Also, importantly, the tacit assumptions and the technical jargon can vary a lot across communities (with the same algorithm having a different name and so on). Classifications and standardization can therefore help inter-community communication and collaboration and facilitate intra-community reuse of models. Coming to automation, of course, the possibility to generate source code from a pseudocode is very appealing, both for non-experts and for experts.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://​creativecommons.​org/​licenses/​by/​4.​0/​), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Fußnoten
1
For example, Owlready 2 [19] is a Python module that allows to import and manipulate OWL 2.0 ontologies and do ontology-oriented programming in Python.
 
2
A “system” is intended here in a very general sense, as something made of components.
 
3
VISO: https://purl.vimmp.eu/semantics/viso/viso-general.ttlhttps://purl.vimmp.eu/semantics/viso/viso-electronic.ttl, https://purl.vimmp.eu/semantics/viso/viso-atomistic-mesoscopic.ttl, https://purl.vimmp.eu/semantics/viso/viso-continuum.ttl (all of which are non-resolvable IRI); the concatenation of the four files is mirrored at http://www.molmod.info/semantics/viso-all-branches.ttl (resolvable URL).
 
4
To avoid name clashes between the branches, prefixes are used as indicated. In the protégé editor, one can choose different options for the rendering (view tab), including rendering by short name and rendering by prefixed name.
 
5
Not to be confused with the “Object model” concept of Chap. 2.
 
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).
 
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].
 
Literatur
1.
Zurück zum Zitat T.R. Gruber, Toward principles for the design of ontologies used for knowledge sharing? Int. J. Human-Comput. Stud. 43(5), 907–928 (1995)CrossRef T.R. Gruber, Toward principles for the design of ontologies used for knowledge sharing? Int. J. Human-Comput. Stud. 43(5), 907–928 (1995)CrossRef
2.
Zurück zum Zitat P. Borst, H. Akkermans, J. Top, Engineering ontologies. Int. J. Human-Comput. Stud. 46(2–3), 365–406 (1997)CrossRef P. Borst, H. Akkermans, J. Top, Engineering ontologies. Int. J. Human-Comput. Stud. 46(2–3), 365–406 (1997)CrossRef
3.
Zurück zum Zitat C. Turnitsa, J.J. Padilla, A. Tolk, Ontology for modeling and simulation, in Proceedings of WSC, ed. by B. Johansson, S. Jain, J. Montoya Torres (IEEE, Piscataway, New Jersey, USA, 2010), pp. 643–651 C. Turnitsa, J.J. Padilla, A. Tolk, Ontology for modeling and simulation, in Proceedings of WSC, ed. by B. Johansson, S. Jain, J. Montoya Torres (IEEE, Piscataway, New Jersey, USA, 2010), pp. 643–651
4.
Zurück zum Zitat H. Cheong, A. Butscher, Physics-based simulation ontology: an ontology to support modelling and reuse of data for physics-based simulation. J. Eng. Des. 30(10–12, SI):655–687 (2019) H. Cheong, A. Butscher, Physics-based simulation ontology: an ontology to support modelling and reuse of data for physics-based simulation. J. Eng. Des. 30(10–12, SI):655–687 (2019)
5.
Zurück zum Zitat S. Robinson, Conceptual modelling for simulation Part I: definition and requirements. J. Oper. Res. Soc. 59(3), 278–290 (2008)CrossRef S. Robinson, Conceptual modelling for simulation Part I: definition and requirements. J. Oper. Res. Soc. 59(3), 278–290 (2008)CrossRef
6.
Zurück zum Zitat S. Robinson, A tutorial on simulation conceptual modeling, in Proceedings of WSC, ed. by W.K.V. Chan, A. D’Ambrogio, G. Zacharewicz, N. Mustafee, G. Wainer, E. Page (IEEE, Piscataway, New Jersey, USA, 2017), pp. 565–579 S. Robinson, A tutorial on simulation conceptual modeling, in Proceedings of WSC, ed. by W.K.V. Chan, A. D’Ambrogio, G. Zacharewicz, N. Mustafee, G. Wainer, E. Page (IEEE, Piscataway, New Jersey, USA, 2017), pp. 565–579
7.
Zurück zum Zitat S. Robinson, Conceptual modelling for simulation part II: a framework for conceptual modelling. J. Operat. Res. Soc. 59(3), 291–304 (2008) S. Robinson, Conceptual modelling for simulation part II: a framework for conceptual modelling. J. Operat. Res. Soc. 59(3), 291–304 (2008)
8.
Zurück zum Zitat R. Arp, B. Smith, A.D. Spear, Building Ontologies with Basic Formal Ontology (MIT Press, Cambridge, Massachusetts, 2015)CrossRef R. Arp, B. Smith, A.D. Spear, Building Ontologies with Basic Formal Ontology (MIT Press, Cambridge, Massachusetts, 2015)CrossRef
9.
Zurück zum Zitat G.A. Silver, J.A. Miller, M. Hybinette, G. Baramidze, W.S. York, DeMO: an ontology for discrete-event modeling and simulation. Simulation 87(9), 747–773 (2011)CrossRef G.A. Silver, J.A. Miller, M. Hybinette, G. Baramidze, W.S. York, DeMO: an ontology for discrete-event modeling and simulation. Simulation 87(9), 747–773 (2011)CrossRef
10.
Zurück zum Zitat J. Malone, A. Brown, A.L. Lister, J. Ison, D. Hull, H. Parkinson, R. Stevens, The software ontology (SWO): a resource for reproducibility in biomedical data analysis, curation and digital preservation. J. Biomed. Semant. 5, 25 (2014)CrossRef J. Malone, A. Brown, A.L. Lister, J. Ison, D. Hull, H. Parkinson, R. Stevens, The software ontology (SWO): a resource for reproducibility in biomedical data analysis, curation and digital preservation. J. Biomed. Semant. 5, 25 (2014)CrossRef
11.
Zurück zum Zitat Y. Gil, V. Ratnaka, D. Garijo, OntoSoft: capturing scientific software metadata, in Proceedings of K-CAP 2015, ed. by K. Barker, J.M. Gómez Pérez (ACM, New York, USA, 2015), p. 32 Y. Gil, V. Ratnaka, D. Garijo, OntoSoft: capturing scientific software metadata, in Proceedings of K-CAP 2015, ed. by K. Barker, J.M. Gómez Pérez (ACM, New York, USA, 2015), p. 32
12.
Zurück zum Zitat X. Zhang, K. Li, C. Zhao, D. Pan, A survey on units ontologies: architecture, comparison and reuse. Prog. Electron Lib. 51(2), 193–213 (2017) X. Zhang, K. Li, C. Zhao, D. Pan, A survey on units ontologies: architecture, comparison and reuse. Prog. Electron Lib. 51(2), 193–213 (2017)
14.
Zurück zum Zitat M. Stoica, S. Peckham, Incorporating new concepts into the scientific variables ontology, in Proceedings of eScience, ed. by N. Williams (IEEE, Piscataway, New Jersey, USA, 2019), pp. 539–540 M. Stoica, S. Peckham, Incorporating new concepts into the scientific variables ontology, in Proceedings of eScience, ed. by N. Williams (IEEE, Piscataway, New Jersey, USA, 2019), pp. 539–540
15.
Zurück zum Zitat F. Borges Ruy, R. de Almeida Falbo, M. Perini Barcellos, S. Dornelas Costa, G. Guizzardi, SEON: a software engineering ontology networ, in Proceedings of EKAW 2016, ed. by E. Blomqvist, P. Ciancarini, F. Poggi, F. Vitali, LNCS, vol. 10024 (Springer, Cham, Switzerland, 2016), pp. 527–542 F. Borges Ruy, R. de Almeida Falbo, M. Perini Barcellos, S. Dornelas Costa, G. Guizzardi, SEON: a software engineering ontology networ, in Proceedings of EKAW 2016, ed. by E. Blomqvist, P. Ciancarini, F. Poggi, F. Vitali, LNCS, vol. 10024 (Springer, Cham, Switzerland, 2016), pp. 527–542
16.
Zurück zum Zitat G. Guizzardi, Ontological foundations for structural conceptual models. Ph.D. thesis, University of Twente (2005) G. Guizzardi, Ontological foundations for structural conceptual models. Ph.D. thesis, University of Twente (2005)
17.
Zurück zum Zitat G. Guizzardi, G. Wagner, J.P. Andrade Almeida, R.S.S. Guizzardi, Towards ontological foundations for conceptual modeling: The unified foundational ontology (UFO) story. Appl. Ontol. 10(3–4), 259–271 (2015) G. Guizzardi, G. Wagner, J.P. Andrade Almeida, R.S.S. Guizzardi, Towards ontological foundations for conceptual modeling: The unified foundational ontology (UFO) story. Appl. Ontol. 10(3–4), 259–271 (2015)
18.
Zurück zum Zitat C.Z. de Aguiar, Rd.A. Falbo, V.E. Silva Souza, OOC-O: a reference ontology on object-oriented code, in Proceedings of ER 2019, ed. by A.H.F. Laender, B. Pernici, E.P. Lim, M. Palazzo, J. de Oliveira (Conceptual Modeling) LNCS, vol. 11788 (Springer, Cham, Switzerland), pp. 13–27 C.Z. de Aguiar, Rd.A. Falbo, V.E. Silva Souza, OOC-O: a reference ontology on object-oriented code, in Proceedings of ER 2019, ed. by A.H.F. Laender, B. Pernici, E.P. Lim, M. Palazzo, J. de Oliveira (Conceptual Modeling) LNCS, vol. 11788 (Springer, Cham, Switzerland), pp. 13–27
19.
Zurück zum Zitat J.B. Lamy, Python et les Ontologies (ENI, Saint-Herblain, France, 2019) J.B. Lamy, Python et les Ontologies (ENI, Saint-Herblain, France, 2019)
21.
Zurück zum Zitat F. Boussuge, C.M. Tierney, H. Vilmart, T.T. Robinson, C.G. Armstrong, D.C. Nolan, J.C. Leon, F. Ulliana, Capturing simulation intent in an ontology: CAD and CAE integration application. J. Eng. Des. 30(10–12, SI), 688–725 (2019) F. Boussuge, C.M. Tierney, H. Vilmart, T.T. Robinson, C.G. Armstrong, D.C. Nolan, J.C. Leon, F. Ulliana, Capturing simulation intent in an ontology: CAD and CAE integration application. J. Eng. Des. 30(10–12, SI), 688–725 (2019)
23.
Zurück zum Zitat J. Mylopoulos, Information modeling in the time of the revolution. Inf. Syst. 23(3–4), 127–155 (1998)CrossRef J. Mylopoulos, Information modeling in the time of the revolution. Inf. Syst. 23(3–4), 127–155 (1998)CrossRef
24.
Zurück zum Zitat P. Murray-Rust, H.S. Rzepa, M. Wright, Development of chemical markup language (CML) as a system for handling complex chemical content. New J. Chem. 25(4), 618–634 (2001)CrossRef P. Murray-Rust, H.S. Rzepa, M. Wright, Development of chemical markup language (CML) as a system for handling complex chemical content. New J. Chem. 25(4), 618–634 (2001)CrossRef
25.
Zurück zum Zitat M. Frenkel, R.D. Chirico, V. Diky, Q. Dong, K.N. Marsh, J.H. Dymond, W.A. Wakeham, S.E. Stein, E. Königsberger, A.R.H. Goodwin, XML-based IUPAC standard for experimental, predicted, and critically evaluated thermodynamic property data storage and capture (ThermoML). Pure Appl. Chem. 78(3), 541–612 (2006)CrossRef M. Frenkel, R.D. Chirico, V. Diky, Q. Dong, K.N. Marsh, J.H. Dymond, W.A. Wakeham, S.E. Stein, E. Königsberger, A.R.H. Goodwin, XML-based IUPAC standard for experimental, predicted, and critically evaluated thermodynamic property data storage and capture (ThermoML). Pure Appl. Chem. 78(3), 541–612 (2006)CrossRef
26.
Zurück zum Zitat M. Frenkel, R.D. Chirico, V. Diky, P.L. Brown, J.H. Dymond, R.N. Goldberg, A.R.H. Goodwin, H. Heerklotz, E. Königsberger, J.E. Ladbury, K.N. Marsh, D.P. Remeta, S.E. Stein, W.A. Wakeham, P.A. Williams, Extension of ThermoML: the IUPAC standard for thermodynamic data communications (IUPAC recommendations 2011). Pure Appl. Chem. 83(10), 1935–1967 (2011) M. Frenkel, R.D. Chirico, V. Diky, P.L. Brown, J.H. Dymond, R.N. Goldberg, A.R.H. Goodwin, H. Heerklotz, E. Königsberger, J.E. Ladbury, K.N. Marsh, D.P. Remeta, S.E. Stein, W.A. Wakeham, P.A. Williams, Extension of ThermoML: the IUPAC standard for thermodynamic data communications (IUPAC recommendations 2011). Pure Appl. Chem. 83(10), 1935–1967 (2011)
27.
Zurück zum Zitat A.H. Larsen, J.J. Mortensen, J. Blomqvist, I.E. Castelli, R. Christensen, M. Dułak, J. Friis, M.N. Groves, B. Hammer, C. Hargus, E.D. Hermes, P.C. Jennings, P.B. Jensen, J. Kermode, J.R. Kitchin, E.L. Kolsbjerg, J. Kubal, K. Kaasbjerg, S. Lysgaard, J. Bergmann Maronsson, T. Maxson, T. Olsen, L. Pastewka, A. Peterson, C. Rostgaard, J. Schiøtz, O. Schütt, M. Strange, K.S. Thygesen, T. Vegge, L. Vilhelmsen, M. Walter, Z. Zeng, K.W. Jacobsen, The atomic simulation environment: a Python library for working with atoms. J. Phys. Cond. Math. 29, 273002 (2017) A.H. Larsen, J.J. Mortensen, J. Blomqvist, I.E. Castelli, R. Christensen, M. Dułak, J. Friis, M.N. Groves, B. Hammer, C. Hargus, E.D. Hermes, P.C. Jennings, P.B. Jensen, J. Kermode, J.R. Kitchin, E.L. Kolsbjerg, J. Kubal, K. Kaasbjerg, S. Lysgaard, J. Bergmann Maronsson, T. Maxson, T. Olsen, L. Pastewka, A. Peterson, C. Rostgaard, J. Schiøtz, O. Schütt, M. Strange, K.S. Thygesen, T. Vegge, L. Vilhelmsen, M. Walter, Z. Zeng, K.W. Jacobsen, The atomic simulation environment: a Python library for working with atoms. J. Phys. Cond. Math. 29, 273002 (2017)
30.
Zurück zum Zitat A.F. de Baas (ed.), What Makes a Material Function? (EU Publications Office, Luxembourg, Let me compute the ways, 2017) A.F. de Baas (ed.), What Makes a Material Function? (EU Publications Office, Luxembourg, Let me compute the ways, 2017)
31.
Zurück zum Zitat M.T. Horsch, C. Niethammer, G. Boccardo, P. Carbone, S. Chiacchiera, M. Chiricotto, J.D. Elliott, V. Lobaskin, P. Neumann, P. Schiffels, M.A. Seaton, I.T. Todorov, J. Vrabec, W.L. Cavalcanti, Semantic interoperability and characterization of data provenance in computational molecular engineering. J. Chem. Eng. Data 65(3), 1313–1329 (2020)CrossRef M.T. Horsch, C. Niethammer, G. Boccardo, P. Carbone, S. Chiacchiera, M. Chiricotto, J.D. Elliott, V. Lobaskin, P. Neumann, P. Schiffels, M.A. Seaton, I.T. Todorov, J. Vrabec, W.L. Cavalcanti, Semantic interoperability and characterization of data provenance in computational molecular engineering. J. Chem. Eng. Data 65(3), 1313–1329 (2020)CrossRef
34.
Zurück zum Zitat D. Allemang, J. Hendler, Semantic Web for the Working Ontologist, 2nd edn. (Morgan Kaufmann, Waltham, Massachusetts, 2011) D. Allemang, J. Hendler, Semantic Web for the Working Ontologist, 2nd edn. (Morgan Kaufmann, Waltham, Massachusetts, 2011)
36.
Zurück zum Zitat M.T. Horsch, S. Chiacchiera, M.A. Seaton, I.T. Todorov, K. Šindelka, M. Lísal, B. Andreon, E.B. Kaiser, G. Mogni, G. Goldbeck, R. Kunze, G. Summer, A. Fiseni, H. Brüning, P. Schiffels, W.L. Cavalcanti, Ontologies for the Virtual Materials Marketplace. Künstl. Intell. (2020). https://doi.org/10.1007/s13218-020-00648-9 M.T. Horsch, S. Chiacchiera, M.A. Seaton, I.T. Todorov, K. Šindelka, M. Lísal, B. Andreon, E.B. Kaiser, G. Mogni, G. Goldbeck, R. Kunze, G. Summer, A. Fiseni, H. Brüning, P. Schiffels, W.L. Cavalcanti, Ontologies for the Virtual Materials Marketplace. Künstl. Intell. (2020). https://​doi.​org/​10.​1007/​s13218-020-00648-9
Metadaten
Titel
Semantic Technology for Simulations and Molecular Particle-Based Methods
verfasst von
Martin Thomas Horsch
Silvia Chiacchiera
Welchy Leite Cavalcanti
Björn Schembera
Copyright-Jahr
2021
DOI
https://doi.org/10.1007/978-3-030-68597-3_4

    Marktübersichten

    Die im Laufe eines Jahres in der „adhäsion“ veröffentlichten Marktübersichten helfen Anwendern verschiedenster Branchen, sich einen gezielten Überblick über Lieferantenangebote zu verschaffen.