SimPhoNy is an ontology-based framework aimed at enabling interoperability between different simulation and data management tools, with a focus on materials science.
What can SimPhoNy be used for?¶
Fetch data from a database, run a simulation and immediately store the results¶
Ontology-based linked data is not only well suited for the interoperability of data, but also of software tools. In SimPhoNy, one can instantiate individuals from special ontology classes called wrappers. These wrappers are in fact a software interface between the core of SimPhoNy (ontology based) and external software tools, disguised to the user as an ontology class. We have already developed wrappers for a few database backends and popular simulation engines for materials science. You can have a look at the existing wrappers on our GitHub organization. If needed, you may even consider developing your own!
As a SimPhoNy user, you can see the data stored in the external software tools transparently as ontology individuals through the wrappers. In this way, moving data between different software tools becomes as simple as moving or copying it from one wrapper to another.
For example, linked data stored in a SQLite database can be used to run a simulation just by adding the ontology individuals contained in the SQLite wrapper to the Simulation Engine wrapper. Similarly, the ontology individuals representing the results can be simply added back into the database wrapper.
At this point, the results could be fetched again and for example, visualized with the help of a plotting library.
Couple simulation engines easily¶
Exactly in the same way that the data can be moved between a database and a simulation engine using their respective wrappers, it can also be moved between simulation engines.
This functionality facilitates the coupling and linking between such simulation engines. For example, in the domain of materials science, a certain engine might be useful for representing structures made up of atomistic particles (molecular dynamics), while another software tool could be focussed on representing bodies of fluids (fluid dynamics). As SimPhoNy can enable communication between the two tools, they could both be run and synced simultaneously to create more complex scenarios, such as a multi-scale simulation.
In order achieve that, it would be necessary to translate the input and output formats of both simulation engines. However, given that the necessary wrappers exist, and their ontologies are compatible, this task becomes relatively simple thanks to SimPhoNy! At the end of the coupling process, just add the results to a database wrapper to store them.
The name ‘SimPhoNy’ stems from the SimPhoNy EU-project in which it was originally developed (see more details here).
Here are some additional terms that are used throughout the documentation:
API: Application Programming Interface. A set of functions that allow the interaction with an application or system.
OSP: Open Simulation Platform. A set of common standards and related tools that form the basic environment on top of which compatible and compliant simulation workflows can be developed and run. An OSP does not contain any simulation tools itself, it is the common framework enabling to couple and link them.
backend: a third party application or service. Simulation engines and databases are examples of backends.
wrapper: a plugin for OSP-core that adds support to a new backend. It must allow the user to interact with the backend through the same API as OSP-core.
ontology: an explicit, formal specification of a shared conceptualization. In the context of ontology, other relevant terms are:
class: a concept. E.g., ‘City’, ‘Experiment’.
attribute: a property of a class that has a data type. E.g., ‘name’ of the type String which could be used as an attribute of ‘City’.
individual: an instance of a class. E.g., an instance of the class ‘City’ can be used to represent the city of Freiburg in which case it would have the attribute ‘name’ with the value ‘Freiburg’.
relationship: a type of a way in which one individual relates to another. E.g., ‘Has-A’ which could use to form the relationship ‘Freiburg (City) Has-A Dreisam (River)’.
entity: a general term that can refer to a class, a relationship, attribute, or an individual. E.g., ‘City’, ‘name’, ‘Has-A’, the Freiburg individual are all entities.
namespace: an ontology identifier. E.g., ‘city_ontology’ which could be used as a namespace for the ontology that consists of the entities ‘City’, ‘name’ and ‘Has-A’.
Each entity is uniquely identified by its name and the namespace it is contained in. We call <namespace name>.<entity name> the
qualified entity name.
CUDS: Common Universal Data Structure. A data structure that is used to uniformly represent ontology concepts in programming code.
CUDS exposes an API that provides CRUD (Create, Read, Update and Delete) functionalities.
CUDS is a recursive data structure in that a CUDS object may contain other CUDS objects.
CUDS is the fundamental data type of OSP-core, a framework that establishes interoperability between software systems that are built on top of ontologies.
CUDS class: represents an ontology class (a concept) and encodes its ontological information.
CUDS object: is an instance of a CUDS class and represents an ontology individual.