Ontology for the Semantic Enhancement, Database Definition and Management and Revision Control
Download as PPTX, PDF0 likes11 views
The document discusses the ontology used for semantic enhancement, database management, and revision control in a web application called ChemConnect, which operates in the chemical and scientific instrumentation domain. It details how the ontology drives the interaction between the Java application and the Firestore database, enabling process specifications, transaction management, and automatic generation of RDF structures for catalog objects. The goal is to generalize coding processes, minimize modifications to Java code when defining new processes, and enhance traceability through transactions.
Ontology for the Semantic Enhancement, Database Definition and Management and Revision Control
- 1. Ontology for the Semantic Enhancement, Database Definition and Management and Revision Control Edward S. Blurock (edward.Blurock@gmail.com) Blurock Consulting AB, Lund, Sweden Case Study: CHEMCONNECT: Web application in the chemical and scientific instrumentation domain using Google Cloud Firebase (Firestore NoSQL database and blob storage) The ontology has several roles within CHEMCONNECT. The ontology drives the interaction between the JAVA program, the interface and the database The catalog objects, the data objects within the database, are specified by the ontology. This specification is translated into JSON objects. These JSON data objects are manipulated within the JAVA program and are the objects which are stored within the Google Firestore database. Semantic Enhancement, Documentation and Object Specification The ontology provides semantic enhancement and documentation through, for example, the objects placement in the hierarchy of objects and annotations within the objects. Documentation of processes are provided by having an associated ontology object with the JAVA process. The ontology provides process specifications through templates. RESTFUL Services are defined with corresponding ontology object specification under the prov:SoftwareAgent (1). The specification (2), which has a corresponding JAVA process (3), provides the input (dcterms:hasPart) and the output (hasOutput). The RESTFUL service input specifies the service (service) (4). This specification routes the process to the core process code (3), within a JAVA enum ( with the name of the set of processes defined, in this case ServiceCollectionQueryOntology (1). The output of the process is a JSON object specified by the output definition (5) Ontology: Core of data driven software, process specification and execution There are several ‘generic’ processes that are steered by the ontology specification. The goal is minimize and generalize the coding of processes and shift as much of the process specific information to the ontology. This is particularly important for domain specific operations. The goal is to be able define new processes without having to modify the JAVA code. The Transaction is the key to data traceability, accountability and revision control. 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. 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. The 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). Only the ‘Transaction Process’ is specific to the transaction. The rest is generated and steered by the ontology specification. Generic code for all transactions. For each catalog object, a set of corresponding database RDFs are generated. The RDFs of the ontology are static. The database RDF set increases as more catalog objects are added to the database. The database RDFs are used to facilitate searching for catalog objects within the database. Given a catalog object, the RDF generation is totally automated by the catalog specification. Within the ontology catalog object definition, a skos:mappingRelation set is defined (1). These point to data objects (subclasses of RDFMappingDefinition, under skos:Concept) defining the subject (2a), predicate (2b) and the object (2c) of the generated RDF (3b). The predicate is the definition name (2b). The subject (3a) and object (3b) are automatically found within the total catalog object. Note that these elements do not have to be in the record or catalog object where they are defined. In the example, the CatalogObjectKey is actually found in the top catalog object. Additional Information about techniques described in this poster: https://sites.google.com/view/chemconnecttechniques/about Blurock Consulting AB: https://sites.google.com/view/blurock-consulting-ab/home CHEMCONNECT project: https://sites.google.com/view/chemconnect/chemconnect