Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
Edward S. Blurock
Blurock Consulting AB, Lund, Sweden
Keywords: Ontology Use Case, Database System, Chemical Kinetics, Experimental Data, Chemical Modelling.
Abstract: CHEMCONNECT is an ontology cloud-based repository of experimental, theoretical and computational data
for the experimental sciences domain that support the FAIR data principle, namely that data is findable,
accessible, interoperable and re-usable. The design also promotes the good scientific practices of
accountability, traceability and reproducibility. The key to meeting these design goals is the use of ontologies.
The primary goals of using ontologies include not only capturing a domain specific knowledge base (with
support of domain experts), but also to create a data/ontology driven software system for the data objects, data
entry, the database and the graphical interface. The impetus within (combustion research) domain, which is
the initial focus of CHEMCONNECT, of the knowledge base is formation and documentation of standard
data reporting practices. The ontology is a software technical implementation of practices within the
community. Storing and querying of specific instantiations of object data is done using a NOSQL database
(Google datastore). This initial design of CHEMCONNECT is modelled for the chemical kinetics and
combustion domain. Within this domain, the ontology defines templates of typical experimental devices
producing data, algorithms and protocols manipulating data and the data forms that are encountered in this
pipeline. These templates are then instantiated, with the aid of ontology driven cloud-based interface, to
specific objects within the database. The knowledge base is key to uniting data input in various forms
(including diverse labelling) to a common base for ease of search and comparison. The structure is not limited
to this domain and will be expanded in future collaborative work. CHEMCONNECT is currently implemented
with the Google App Engine at
CHEMCONNECT is a cloud-based database and
repository of experimental and modelling data
primarily in the area of chemical kinetics. Currently,
the emphasis is on combustion data, but a more
general structure is maintained to allow expansion
into other scientific domains.
As the name implies, the purpose and design of
the software system CHEMCONNECT recognizes
that individual data points are not isolated but are
interconnected with a multitude of other data
representing its history, origin and dependencies and
how points are used and related to other data points.
The impetus for this philosophy is to promote the
good scientific practices of accountability,
traceability and reproducibility. In addition, the
database is designed to promote FAIR(GO FAIR
2016; Hagstrom 2014; Wilkinson et al. 2016)
principles, meaning that the data is Findable,
Accessible, Interoperable and Re-usable. The goal of
CHEMCONNECT is to provide a platform that
encourages these practices in a semi-automated way
so as to not to incur an increased work-load for the
researcher. The goal is to provide a natural workflow
of data entry for the researcher.
This work has been spurred by the movement,
especially within the combustion community which
is the initial emphasis of CHEMCONNECT, of
standardizing data reporting. CHEMCONNECT
implements these standardizations through its
knowledge base ontology.
1.1 Interconnectivity of Data and
Knowledge Base
CHEMCONNECT recognizes that all data is not
isolated and has a complex interconnection with data
of different forms and purposes. This is the central
Blurock, E.
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT.
DOI: 10.5220/0008069502400247
In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 240-247
ISBN: 978-989-758-382-7
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
concept in promoting good scientific principles of
accountability, who and what devices generated the
data, traceability, the origins of all data, including
external data sources, and reproducibility, all the
information and algorithms of the entire process is
We start with a single data point. Most likely this
point has been included from a data files within a
repository with its associated information of who
entered the data, data of entry, data of data
production, origin of data, etc. The data point itself
represents some knowledge as to its context. This
context lies within a network of interconnected
concepts. The database ontological knowledge within
CHEMCONNECT provides this context.
If the data point is a ‘direct’ measurement, there is
a connection with all the associated information with
the device. First, there is the specific device found at
a specific place (institute, department, etc.), within a
specific organization (university, research center,
etc.), performed by a specific researcher (including
collaboration, supervisor, position, and other
information about the researcher). The device itself
has a description and can be viewed as a collection of
subsystems each of which has a purpose and its role
in producing the data point. Within the device there
could be the actual component which produced the
data with its specific properties, including accuracy,
reliability and dependence on other components in the
device. Part of the CHEMCONNECT database is a
device description. The specific device used to
produce the point is, of course, related to similar
devices with similar properties. The
CHEMCONNECT ontology knowledge base
provides templates of device descriptions and the
device’s relation and composition in relation to other
similar devices. In addition to the meta-data about the
device (parameterized description, abstract
description, references to publications, institutes,
researchers, etc., the device is viewed as a set of
interconnected subsystems and components.
Templates of these descriptions are found in the
database which also gives their role and purpose
within a larger scientific context.
Final data point results reported in publication are
seldom direct measurements. Usually, there is a flow
of data manipulations from the ‘raw’ data
measurement from the device to the final result
reported in a table in the publication. It is becoming
more critical within the scientific community,
especially for the chemical kinetics community, that
this data trace is included, particularly in error
analysis, for traceability, accountability and
reproducibility. For example, the computation of
propagation of errors can be done a variety of ways
and can range from the simple, which is usually done
by the primary data producer, to complex, which can
be done by researchers with data expertise.
The chain of data manipulations from ‘raw’
results to final published results is represented by a
protocol. The interconnectivity of data is further
promoted by each component in this chain. A
protocol essentially consists of the entire set of
algorithms, procedures, devices and intermediate data
produced from those algorithms. Within these
components are further connections to specific
organizations, researchers, publications, and other
external references. Within the CHEMCONNECT
knowledge base, templates for protocols are given,
meaning typical experimental procedures leading to
final results. Instantiation of a protocol into the
database is done by providing the specific
information regarding the specific experiment. This
instantiation supplements the general context
knowledge, within the broader knowledge base of
experimental procedures and devices.
Within the knowledge base of CHEMCONNECT,
templates for algorithms and their specific
implementation can be given to the database.
Algorithms can be range from simple algorithmic
calculation, to computer software. Within the
algorithm description would be further references
giving a broader context to the algorithm. An
‘algorithm’ can also be a specific experimental
procedure describing (with references) how the data
was produced. The ontological knowledge base
algorithms provide information about the role and
purpose of the algorithm within the large context of
data manipulation.
1.2 Structure of CHEMCONNECT
The general structure of CHEMCONNECT consists
of the interaction between these entities:
Knowledge Base: This is the heart of the
CHEMCONNECT system. It is an ontology
describing the data structures and domain
structures and concepts.
Repository: This is the data in the original
form of the researchers. These are the files that
are parsed and interpreted using the knowledge
base and stored in the database.
Database: This is the primary persistent
storage of individual pieces of interconnected
data. The database not only holds the data
itself, but also the data specifications and
templates used to input and interpret data.
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
Cloud-based Interface: From a browser
interface, the data can be inputted, visualized,
compared and searched. The driving force of
the interface is the knowledge-base providing
for effective input, visualization and
comparison of data.
It is important to note that the role of the ontology
is to store ‘generic’ knowledge about structures
within CHEMCONNECT and the role of the database
is to store specific persistent instantiations of domain
data. Queries about specific domain objects is done
through the database. Queries using the ontology are
about the character and make-up of the entities used
The general workflow of using
CHEMCONNECT is in two stages. First, an initial
‘one-time’ setup phase setting up the organization,
researcher, device and protocols. During the
measurement phase, these references and protocols to
interpret the data are re-used. The philosophy is that
after the initial setup, the introduction of
measurements, including all their interpretations and
interconnections, is semi-automatic. In principle, the
data file is put into the repository and then parsed and
interpreted into the database.
A typical lab most likely has a limited number of
devices with a static configuration and a ‘fixed’
structure of the experimental data. This means that the
device description and the experimental protocols on
how to interpret the data are done once and then re-
used during the experimental phase.
The setting up of a protocol and data
specifications involves starting with a template within
the knowledge-base and making an instantiation
within the database. This instantiation, an entity
within the database, provides the exact interpretation
of data coming from the original raw input.
A primary design philosophy of CHEMCONNECT is
that the software system is knowledge-base driven.
The software components are fairly (emphasis on
‘fairly’) general and how they are pieced together is
determined by the knowledge base captured by an
ontology representation. The ontology knowledge
base is geared towards a particular focus group,
namely experimental and modelling researchers in
the field of chemical kinetics and combustion
research. However, in the design of
CHEMCONNECT a certain degree of generality is
maintained to expand out of this focus group, for
example, experimental research in general.
The ontology used in CHEMCONNECT is used in
several capacities:
Data Structures: These ‘general’ structures
have a one-to-one correspondence with data,
interface and persistent database structures.
Templates: These are generalized information
used to fill in domain information into the
general ‘data-structures’.
Concepts: This is the hierarchy of domain
specific concepts and classifications. The
concepts are also used to fill in domain
information in the templates.
Part of the design concept is to base
CHEMCONNECT ontology objects as much on
existing ontologies, both general and domain specific,
as possible.
2.1 Data Structures
The set of data structures is general enough to
accommodate the domain specific templates and
concepts. There are basically three levels of data
Catalog Structures: These are based on the
DCAT Catalog structure (Maali and Erickson
2014). These are the structures representing the
main data objects to represent the domain.
Record Structures: Base on the dcat:record
from the DCAT ontology, these are the records
of the catalog. Each record structure contains
several pieces of 'primitive' information.
Primitives: These are basically a single (string)
word primitives that make up the record.
For the current domain, the following types of catalog
objects were deemed sufficient:
Catalog Hierarchy: This is essentially a
directory structure virtually categorizing the
data. Sets of data within the same hierarchy
position are considered related.
Contact Data: It is important for
accountability to have a trace to individual
researchers and the organizations producing
the data.
Device and Component Data: Each device
and component is represented by a catalog
object. The device descriptions are a hierarchy
of subsystems and components.
Interpretation Data: These catalog objects
provide instructions on how to interpret data
object. For example, given a csv, spreadsheet
(in various formats), XML, yaml, etc. file with
a block (matrix) of data information. This
isolates and interprets the block as a matrix
KEOD 2019 - 11th International Conference on Knowledge Engineering and Ontology Development
Observation/Protocol Specifications: These
catalog objects represent specifications of how
the data is to be interpreted relative to the
domain knowledge base.
Observations: This is the set of catalog objects
produced as a result of the observation
specifications with a protocol. Simply said, an
individual observation is a matrix of results,
where the columns are interpreted by the
observation specification (including which
knowledge base object is involved and the units
used) and each row is a set of actual
2.1.1 Catalog Objects
The top data objects are the catalog objects
(dcat:catalog). Each catalog object consists a set of
records (dcat:record). Each catalog object has a set
standard records and a set of concept specific records.
In the ontology, a particular record can be one
instance of the record (restriction type of cardinality
of one) or there can be multiple instances of the same
record (restriction type some).
The other concept specific records contain the
defining information for that object. The standard
record information is (See structure part
ChemConnectDataStructure in Figure 1):
Catalog Hierarchy (DataCatalogID): The
position within the catalog hierarchy.
Description (DescriptionDataData): Title,
descriptions, ownership and concept
References (DataSetReference): Publication
Data Links (DataObjectLink): Links to other
data objects with a corresponding link concept.
External Links (ContactHasSite): Links to
external sites with corresponding link concept.
2.2 Templates
Templates are more complex specifications, often
made of other specifications and concepts. Each
specification gives domain specific information on
how to fill in a particular catalog object (See Figure 1
for an example of a heat flux burner as a subsystem):
Parameter Specification (Attribute): The
template defining a parameter’s the essential
information, such as unit class (the actual class
is defined on instantiation), purpose, keyword,
standardized name, etc. A critical component
of the parameter ontology is the use of the
Quantities, Units, Dimensions and Data Types
Ontologies (QUDT 2018).
Observation Specification (hasOutput):
This is a template of a specific observation set
made up of a set of parameters. This
specification can be thought of defining which
parameter specifications define the columns of
a matrix of data. Based on the data cube
ontology (Cyganiak and Reynolds 2014).
Device Specification (hasSubSystem): This
defines a template for an experimental device.
The device is viewed as a hierarchy of
subsystems and components. Based on the SSN
(Haller et al. 2017) and the SOSA (Cox 2017).
Protocol Specification: A protocol is
essentially the specification that is needed to
define an experimental regime. An essential
part of the specification is used to interpret the
set of data input files making up the
experimental regime.
Within the interface, the template is used to generate
the interface in which the specific information for the
instantiation of the entity can be filled in. For
example, for a parameter, the template gives the
default information. In the interface, the actual units
used can be chosen. The template gives the unit class
(and maybe a suggestion for default units). There are
two levels of parameter specifications. For defining a
specific parameter, the value of the units and the
actual parameter value are given. But if the template
is used in, for example, defining the column of a
matrix, the value is no given.
Figure 1: The ontology describes the structure of all the data
objects. In this example, the structure describes a general
device (subsystem) structure. Within the ontology there is a
description of a typical device, such as a heat flux burner.
The template describes how the class structure should be
filled in for the device.
2.3 Concepts
Within CHEMCONNECT, keywords are arranged in
a hierarchy of Concepts (under the skos:Concept
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
ontological object). Most of the domain information
is stored as a concept. Within the hierarchy of
concepts there are several types. Those concepts
representing single word concepts, essentially a set of
standardized keywords are:
Keywords: These are concepts within a
hierarchy of concepts, with the hierarchy
giving them context and meaning.
Purpose: A standardized purpose keyword,
within a hierarchy.
Classifications: A concept keyword
representing a set of types of classes of objects.
The sub-classes of the classification are the
specific choices. Classifications are used, for
example, in the interface to produce a pull-
down list of choices.
Links: This is the concept that links two
entities, such as catalog objects. This concept
can have an extra property limiting the
structures it links to. This information, for
example, is used by the interface to produce a
list of choices from the database.
An important entity within a data repository is a
parameter. A parameter is simple representation that
condenses complex reality into a single value. One of
the challenges is data repository information is the
representing the ‘meaning’ and context of a particular
parameter. In scientific collaboration, unless there is
a conscience standardization, often there is a degree
of ambiguity data parameters, particularly in naming
the parameter (and the use of adjectives and
abbreviations) and in the actual units involved.
CHEMCONNECT’s knowledge base attempts,
through the use of ontologies, is to formalize these
concepts and reduce the ambiguity and increase the
comparability of parameters coming different
A parameter is used and defined on several levels
depending on how they are needed within the
A parameter specification defines the basic
information about a parameter, particularly the unit
type (unit class), uncertainty value type, a purpose, a
concept and whether it is an input (dimension) or an
output (measure). A specification does not involve
the actual value or even the specific units. This is
what is defined with a parameter template within the
A value specification starts with the parameter
specification, but then the particular units from the
unit class are specified. An important aspect of the
parameter specification is the standardization of the
name that can be linked to from, for example, a
parameter name within a particular data file of a
researcher. A parameter specification can be thought
of as defining a column in a data matrix. Here, the
units of the values are specified and, if the matrix is
within a data file, a correspondence between the
parameter name in the file and the standardized name
in the ontology.
Within the description of a catalog object, there
can often be a parameterized description, a set of
attributes, of the object. Here, the parameter
specification is used and the units and the value of the
attribute is specified.
Similar to the attribute is the parameter value.
The only distinction here is that instead of the
parameter being a single attribute-value pair, it
represents a set of values, such as a column in the
The CHEMCONNECT interface facilitates the
reading of a data file produced by a researcher so that
the data can be put on a standardized platform. The
key step is setting a correspondence between a
column of data, the set of data values, and a value
specification. The utility of this lies in the comparison
of data. The link to the standardized name within the
ontology links the two data sources for that
parameter. Knowing the particular units and the
conversion of units (primarily from the QUDT
ontology) allows direct numerical comparison. It
should be noted that the ‘extra’ work in setting up this
correspondence is done once for the particular format
of the researcher. For the most part, a given research
lab has a given device and a given data format that
they have used for years at a time.
The CHEMCONNECT systems consists of the
interplay between software entities of different types
defining the structure, its persistence, its knowledge
content (templates and instantiations), how it can be
visualized and its textual form (XML, yaml, etc.). A
single entity of CHEMCONNECT has several forms
serving different purposes. The purpose of this
section is to give a brief overview of the software
interactions with examples and key elements.
4.1 Ontology Object
One purpose of the CHEMCONNECT ontology is to
define data structures through the catalog, record and
KEOD 2019 - 11th International Conference on Knowledge Engineering and Ontology Development
primitive objects. This definition steers the
management of objects and information within the
JAVA software.
For example, the catalog object,
has (in addition to the
standard information for all catalog objects listed
previously) the following:
(multiple): Parameterized
(attribute-value pairs) description of the
(multiple): A
specification of the observations that are made
from the subsystem.
(multiple): The
subsystems of this subsystem (a device is
viewed as a hierarchy of subsystems).
In the ontology these are specified as a subclass
restriction with a
, if
multiple, or
if a singlet, which points
to the respective ontology record or catalog object. To
find the list of sub-objects of a catalog class a
SPARQL query is done. Within the JAVA software,
the SPARQL commands to access the ontology are
embedded in functions.
Figure 2: The ontology, shown on the left (from Prodigy)
gives the template for an observation. CHEMCONNECT
can use this template to create the interface to fill in values
for the observation elements.
4.2 Hierarchy of JAVA Classes
Corresponding to each catalog and record object
(primitives are usually just String classes) is a JAVA
class and there is a one-to-one correspondence to the
elements of the ontology definition. Each element in
the JAVA class is a string with the identifier of the
sub-object. If the object is a singlet, then the string is
the identifier of sub-object. If the object is multiple,
then the identifier points to a single
object having a
reference to the multiple entities.
Each JAVA class corresponding to an ontology
catalog or record object is also persistent database
objects. CHEMCONNECT uses Google App Engine
(GAE) datastore objects (using Objectify API). This
is expressed with the
annotations in the class definition.
A complete catalog object is actually a hierarchy
of JAVA catalog and record objects and is
represented in a tree of
objects. This
class holds the current object instantiation and the list
having the
sub-objects. When reading an object from persistent
storage (GAE datastore), the top object is read, put
into the top of the hierarchy and then using the
ontology description of the class and the identifiers
within the object, the sub-objects in the hierarchy are
filled in.
The hierarchy is made from individual classes as
java and the corresponding persistent objects in the
database. Associated with each object in the ontology
(corresponding to JAVA class) is an identifier. A
class is translated to a map using these identifiers. A
single class is translated to a map with the ontology
identifier pointing String object that is either an object
identifier if it another class or the class element value
if it is class information. The class hierarchy is a
hierarchy of these class maps. This mapping structure
facilitates the automated manipulation of the
hierarchy of class information and translation, for
example, to a text form such as YAML.
4.3 Domain Specific Information
The descriptions of the software objects in this
section up to now are general and the only connection
to domain information is what ‘general’ entities are
needed to describe the domain, which is this case is
experimental and modelling chemical information.
For example, the
entity is
general enough to describe a large class of devices
and components. But there is no specific information
about the structure of a specific device. The primary
reason for this is to simplify the ‘hard-coded’
software and leave the ability to dynamically update
domain information as it is expanded in concert with
domain researchers. The domain researcher
concentrates on the ontology description of the
domain and the not the software technical details.
Under the
hierarchy are
templates of typical domain instantiations of the
general catalog and record entities. For example, the
template needed for a
entity fills in the four basis elements. The
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
subSystemType is the name of the subsystem
concept, for example dataset:HeatFluxBurner
(a device within the combustion chemical kinetics
domain). The particular device’s position in the
ontology skos:Concept hierarchy gives addition
context information about the device. For example,
the heat flux burner is in the hierarchy:
For analytical purposes, for example to
statistically compare the results of similar devices, it
is often useful to parameterize a description of the
device (or any catalog object for that matter). The
domain researchers, in analysing their particular
devices, often deduce a set of significant parameters
(range of operation, configuration, etc.) that should be
in the device description. These are presented as data
cube:attribute sub-class restriction
on a parameter within the ontology of
parameter specifications.
The device itself is viewed as a system of
subsystems. The top level being the overall device
description and the sub-levels describe important sub-
systems making up the device. The hierarchy can be
arbitrarily deep. Within the device ontology template
specification, is the set of subsystems making up the
device. Each subsystem is itself represents a template
instantiation of a
SubSystemDescription. This
is done through through a subclass restriction
owl:related and the ssn:hasSubSystem
In a similar fashion, the set of observations, i.e.
the data that the subsystem can produce, is listed.
4.4 User Interface
Also associated with each catalog and record entity is
a user interface object which steers the look and feel
of the object presentation. The ontology and
particularly the templates defined object within the
ontology play an important part in the user interface.
The ontology plays a particularly important role
for the presentation of choices. For the specific choice
of a specific choice, the hierarchy of concepts found
below the top concept are presented as a pull-down
list (for example, for a classification) or a tree of
choices. For example, for the creation of a new
device, the concept hierarchy under the
dataset:DataTypeDevice is presented as a tree
menu. The nodes of the tree represent the device
templates to be presented. An end node is selected
and a new device is created using the device template
as an initial pattern.
Just as the objects themselves, the presentation
objects are set up as a hierarchy. For the most part,
the presentation object has a header object which
visualizes the direct information of the object. Under
this header is a tree of sub-objects as defined by the
particular object. If the object has elements that can
be changed, then those elements are presented as a
CHEMCONNECT is cloud based as a Google
App Engine. The interface is built using Google Web
Tool Kit(Google GWT 2017) with GWT Material
Design(Google 2018) for the look and feel of the
Part of the design philosophy of the
CHEMCONNECT ontology was to build upon
available accepted ontologies from the W3C
community. The basic ontologies which have had a
particular influence are:
Dublin Core Terms(Dublin Core 2012): This
is the source of the basic terminology and the
basis of the other ontologies.
Simple Knowledge Organization System
(Miles and Bechhofer 2008): This is the basic
ontology for the concept terms and their inter-
Two ontologies serve as the basis for the contact
Friend of a friend(Brickly and Miller 2014):
This is basic information about individuals.
Organization(Reynolds 2014): Organization
contact structure.
The ontology dealing with data structures are:
Data Catalog Vocabulary, DCAT (Maali
and Erickson 2014): This is the basic for the
category and record entities. This serves as the
basis for the basic data types and database
objects used within CHEMCONNECT.
Data Cube Vocabulary, cube (Cyganiak and
Reynolds 2014):
Several ontologies which contain domain knowledge:
Semantic Sensor Network, SSN (Haller et al.
Sensor Organization Sampling Actuator,
SOSA (Cox 2017):
Quantities, Units, Dimensions and Data
Types Ontologies, QUDT (QUDT 2018):
KEOD 2019 - 11th International Conference on Knowledge Engineering and Ontology Development
What has been described in this paper is the extensive
use of ontologies at several levels within the
CHEMCONNECT repository. The primary goal of
using ontologies is to decouple domain knowledge
from the software engine to produce a data/ontology
driven repository for experimental and modelling
information. The current version of
CHEMCONNECT is modelled on the domain
knowledge within the chemical kinetics and
combustion communities. An implementation of the
repository can be found at:
and implemented on the Google Cloud Platform.
The templates for devices, protocols, algorithms, etc.
within CHEMCONNECT are derived in
collaboration of experts within the field. The
templates are implementations of best practice of data
reporting within the domain as established by domain
experts. CHEMCONNECT knowledge base is a
result of collaborations from the SMARTCATS
COST Action CM1303, Chemistry of Smart Energies
Carriers and Technologies.
The author would like to acknowledge the
cooperation of domain experts within the combustion
community that has been made possible through the
SMARTCATS COST Action CM1303, Chemistry of
Smart Energies Carriers and Technologies. In
particular, the members of the working task group
within the action for Standard definition for data
collection and mining toward a virtual chemistry of
Smart Energy Carriers, of which the author is the
group leader.
Brickly, Dan, and Libby Miller. 2014. “FOAF Vocabulary
Specification.” January 14, 2014.
Cox, Simon. 2017. “SOSA Ontology - Spatial Data on the
Web Working Group.” April 18, 2017. https://www.
Cyganiak, Richard, and Dave Reynolds. 2014. “The RDF
Data Cube Vocabulary.” January 16, 2014.
Dublin Core. 2012. “Dublin Core Metadata Initiative.”
Dublin Core Metadata Initiative. June 12, 2012.
GO FAIR. 2016. “FAIR Principles - GO FAIR.” 2016.
Google. 2018. GWT Material Design (version 2.1.1).
Google GWT. 2017. Google Web Toolkit (GWT).
Hagstrom, Stephanie. 2014. “The FAIR Data Principles.”
FORCE11. September 3, 2014. https://www.
Haller, Armin, Krysztof Janowicz, Simon Cox, Danh Le
Phuoc, Kerry Taylor, and Maxime Lefrancois. 2017.
“Semantic Sensor Network Ontology.” December 8,
Maali, Fadi, and John Erickson. 2014. “Data Catalog
Vocabulary (DCAT).” January 16, 2014.
Miles, Alisair, and Sean Bechhofer. 2008. “SKOS Simple
Knowledge Organization System Namespace
Document 30 July 2008 ‘Last Call’ Edition.” August
20, 2008.
QUDT. 2018. “Quantities, Units, Dimensions and Data
Types Ontologies.” Quantities, Units, Dimensions and
Data Types Ontologies. December 16, 2018.
Reynolds, Dave. 2014. “The Organization Ontology.”
January 16, 2014.
Wilkinson, Mark D., Michel Dumontier, IJsbrand Jan
Aalbersberg, Gabrielle Appleton, Myles Axton, Arie
Baak, Niklas Blomberg, et al. 2016. “The FAIR
Guiding Principles for Scientific Data Management and
Stewardship.” Scientific Data 3 (March): 160018.
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT