An important aspect of accountability and traceability is being able to trace any piece of data to its original source. Traceability is accomplished through the concept of transactions. Every modification of the database is done through a transaction. Every data object within the database is created through a transaction. This includes modifications. The transaction defines: the method used to modify the database, the information needed, including prerequisite objects from the database, to perform the method and, finally, the objects created or modified by the method. It is through the list of prerequisite transactions that the data can be traced to its origin.
As with all data objects in JThermodynamicsCloud, the transaction object has an ontology template. The ontology template for a given transaction has class information for the performance of the transaction:
Transaction name: The name of the transaction action corresponds to the name of the transaction to be performed. This name is used in the RESTful call of the transaction. Essentially this defines the method in the backend.
Prerequisites: A given transaction is often dependent on transactions performed previously. The ontology definition defines which transactions are needed by specifying their ontology class name. In the performance of the transaction, the set of prerequisite transaction classes is used to find the specific instantiation of that class. Often the transaction class and an additional label, such as dataset:CatalogObjectUniqueGenericLabel for preliminary data (see Section Source to Fundamental Data), is enough to isolate directly the prerequisite information.
Parameters: In addition to the preliminary data, often extra information is needed to steer the transaction method. When using the GUI interface, this information is filled in by the user.
Output: This is the type of catalog database object that is created. When the transactIon is executed, an array of these catalog objects are created.
The transaction catalog object that is stored in the database has the following information:
ID: A unique ID associated with the transaction (this is created automatically by the backend)
Access: Since the transaction object is a catalog database object, all the information about ownership and access is specified.
Parameters: The specific parameters that were used to perform the transaction
Output addresses: The array of addresses of the catalog objects, of the type specified in the ontology, that are created by the transaction.
To perform a transaction a RESTful transaction service is called. The input is the name of the transaction, the extra parameters needed to perform the transaction and the prerequisite transaction objects. The set of prerequisite transaction objects are used by the backend to retrieve the prerequisite catalog objects needed to perform the transaction method. As a result of the transaction, both the transaction object and the set of new catalog objects are stored in the database.
For example, to read a set of data fundamental data objects, such as Benson rules, from a input file, there are a set of three transactions. The first transaction is the reading of the file, as a whole, into the file repository. Addition information within this transaction is the bibliographic reference to the source of the input file (tracing the data to the original source). The second transaction, which has the first as a prerequisite parses the file into the individual text blocks defining a benson rule. This single transaction has the list of generated text blocks (each of which is an individual database object). The third transaction is the interpretation of these text blocks and the generated objects are the fundamental database objects for the calculational database. Each Benson rule object also has a link to the text block it was derived from.