This post is an overview of the different ways and levels an ontology can be used on a domain level.
Some of the pictures are taken from slide presentations (for the most part KEOD conferences) of the CHEMCONNECT and JThermodynamicsCloud projects. And some are taken from documents in the field of nuclear reactors.
- Software Technical Level
- Data structure specification
- Service/Process Specification
- Transactions
- RDF generation
- Domain Specific Information
- Glossary of Terms (extracted from domain dictionaries/glossaries/ISO documents
- Ontology Model of System: Systems Description of the plant/device including interconnections and data input and output.
- Terminology and Definitions
- Structured Documents
Software Technical Level
Data object representation
- Data Specification: where the data is represented. This is particularly advantageous when the software system is made up of different modules, each of which could be in different language. The ontology provides a central specification of the data structures.
- Semantic enhancement: Through the class hierarchy and the annotations to each data object, additional information about the data structure can be given. Once again centralized, and it doesn’t have to be documented in each individual module.
Process/Function/Subroutine/Service Specification
Complimenting the data structure specification, the services available in the system can be documented:
- Input Specification
- Output Specification
- Description of the process
- Dependence on other operations (Prerequisites)
Transactions
One level higher than service definitions is that of transactions. An entire process is defined as a series of transactions (goal oriented programming in a sense).
A transaction (as defined in CHEMCONNECT) has the following elements:
- Prerequisite Transactions (dcterms:requires)
- Additional information to perform transaction (dcterms:source)
- Output object: (dcat:Catalog)
Automatic RDF Generation
If data structures are considered the source, for example, reading in of data or tables, then the information can be ‘connected’ to other information through RDFs
object -> predicate -> subject
The individual components of the data structure can be (automatically) translated to a graphical representation of the data for easy (easier) searching and manipulation.
Domain Specific Information
Glossary Terms
These are the domain vocabulary. For example, in the illustration, this can be taken directly (almost automatically) from documents.
For example the neo.ttl excerpt above defines the ‘fission product’ class. The definition is taken directly from the text. The reference is also given.
If the glossary (as in the document ISO 12749-5:2018(en) Nuclear energy, nuclear technologies, and radiological protection — Vocabulary — Part 5: Nuclear reactors) has 
some structure, then that could be reflected in the ontology hierarchy. The information for each term can be inserted as annotations.
Systems Analysis
This document, and similar specification documents, is an example how to start creating a systems model of a nuclear power plant, including many general characteristics which distinguish power plants from one another (see Annex I below).
This document defines a set of attributes describing a generic nuclear power plant as subsystems and attributes characterizing the subsystems (elements of the PRIS database).
Systems Example from CHEMCONNECT
Heat Flux Burner
Here the ontology holds a description of the burner from a systems point of view. Meaning that the burner consists of several subsystems (for example, Fuel preparation, Thermal conditioning and burner) and each of these, in turn, consist of further subsystems creating a hierarchy of subsystems.
Within the subsystem description itself, there are a set of attributes that describe its characteristics. A typical ‘generic’ subsystem would have a list of characteristics. The instantiation of the subsystem would assign specific values to these attributes.
In the generic description, there is also a set of ‘observations’, inputs from connected subsystems and outputs produced by this subsystem. This gives a reference to the data collected from this subsystem.
Structured Documents
In structured documents, the ontology can provide a vocabulary and the general structure of the elements of the document.
It can be a question, whether how the elements are filled in are in an ontology or in the knowledge base (RDF structures in a graphical database).
For example, the “Standard Technical Specifications – Operating and New Reactors” provide specification of reactors in a very structured way. First they provide, for example, the vocabulary used in the document (there is a document for different reactors — but the vocabulary seems consistent over all documents). This vocabulary can be translated one-to-one to an ontology to make it actionable.
Another part of the document is a very structured specification of conditions and the actions that should be taken under the conditions. Interpreting this can use the vocabulary and definitions read into an ontology.
One question that arises is whether the set of conditions and actions are put in an ontology structure or a graphical knowledge base (which in once sense can be viewed as a simplified ontology). If the actions are generic in nature, where instantiation can differentiate the actions for specific cases (here meaning reactors), then these actions should be in a ontology describing the schema of the action.
Vocabulary and definitions
Condition and Actions on Conditions
English