JThermodynamicsCloud is software service for the chemical, or more specifically, the combustion research domain. JThermodynamicsCloud service can be said to be an model driven application, where the ontology is a platform independent model of the data and operational structures. The ontology, as used by the service, has three distinct purposes: documentation, data structure definition and operational definitions. One goal of the ontology is to place as much of the design and domain specific structures in the ontology rather than in the application code. The application code interprets the ontology in the backend. The primary purpose of the JThermodynamicsCloud is to perform thermdynamic calculations and manage the data needed to make those calculations. The calculation itself is highly dependent on the varied types of molecular data found in the database The complete service is a system with three interacting components, a user interface using Angular, a (RESTful) backend written in JAVA (with the JENA API interpreting the ontology) and the Google Firestore noSQL document database and Firebase storage. The service uses these three components to make calculations for thermodynamic quantities based on molecular species structure. These different platforms are united through the ontology.

1. JThermodynamicsCloud: Case Study in an Ontology-Driven NoSQL Cloud Based
Database Application in Chemical Domain
Edward S. Blurock. (edward.Blurock@gmail.com) Blurock Consulting AB, Lund, Sweden
All data manipulations are the results of
transactions. In the hierarchy of
TransactionEvents (dcterms:Event)
(1a), a transaction is specified (1b). A
transaction can have some specific
information guiding the transaction (2),
specified by an object, dcterms:source.
The output of the transaction is a catalog
object to be written to the database (3). The
transaction can also be dependent on a set of
prerequisite catalog objects which were
created by previous transactions (4).
Associated with each catalog object is a
transaction. Associated with each
transaction is a task that modifies the
database. Thus, the history of the
creation and manipulation of the catalog
object can be traced through the
transactions. This includes changes to the
catalog object. How a catalog object is
derived and modified can be traced
through the catalog data objects pointed
to by chain of transactions.
The Execution of a Transaction Process
The user supplied input information of the transaction is accessed through the
user interface (1a) and a JSON object created (2c). In addition, using the
prerequisite transactions specification (1b), the database is searched (2a) for
appropriate transactions objects. Through the user interface, the specific
transactions are chosen (2b). The transaction process (corresponding JAVA code)
takes as input (3a) the user input (2c) and the selected prerequisite transactions
(2b). The template for the output catalog object (3b) is used by the process to
create the output object. The catalog object is written to the database (4). The
catalog object determines where in the database hierarchy the object is stored
(5). In addition, the catalog object is used to automatically generate the database
RDFs (6).
There is a one-to-one correspondence between the hierarchy of the noSQL
document based database and the Database Hierarchy Specification in the
Ontology. The ontology is used to generate the document address.
A given catalog object class has a unique position not only in the database
hierarchy but also in the in the ontology hierarchy. The leaf class in the
specification ontology hierarchy specifies, through the skos:member
property, which class of catalog object is to be stored in the database.
Google Firestore noSQL database: document oriented data-model
SaaS for thermodynamic calculations and data management
JThermodynamicsCloud is software service in the combustion research domain
to perform thermodynamic calculations from differents sets of fundamental
chemical data and manage the data needed to make those calculations.
Model Driven Application
The JThermodynamicsCloud service can be said to be a model driven
application, where the ontology is a platform independent model of the data
and operational structures. All the ontology concepts outlined here, from the
ontology definition to the utilization of this definition in the application, have
been implemented: https://github.com/blurock/Angular/releases
Different data formats are united through the ontology
ThermodynamicsCloud is comprised of three different platforms with three
different data formats to represent JSON-like data. The user interface uses
Angular typescript, the (RESTful) backend is written in JAVA uses GSON and
the Google Firestore noSQL document database has a map-based data
format. Every piece of JSON-like data within all three systems of the service
are united with a single corresponding ontology class. This means that
communication between systems has the same ontology reference.
Management of Fundamental Data
The multiple sets of fundamental data used to perform the calculations are not
static and are constantly being updated. A primary task of
JThermodynamicCloud is to manage the data stored in a Database of Catalog
Objects. Ontologies play an important role in the modelling of this data.
The path from ontology root, CatalogHierarchyThermodynamicDatasets. to
the ontology catalog class has a one-to-one correspondence with the address
path of the stored catalog object in the database. Each class in this path specifies
how the address label at that level should be generated. The
rdfs:isDefinedBy annotation specifies the method that generates the
label. The source string address label can be the ontology class, the object
ontology class or the stored object itself. The set of methods to create these
labels are defined in the ontology under the GenerateStringLabel class
(this is an example of an implementation of operations by type).
The structure is an alternating hierarchy of collections and documents.
Database address generated by the ontology
data traceability, accountability
and revision control
Transaction Definition in the ontology