Traceability and Accountability

An important aspect of accountability and trust 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. Within the transaction object (also in the database) is the (list of) object(s) that were create by the transaction. Associated with each transaction is a list of prerequisite transactions that have to have been performed before the current transaction is performed. It is through the list of transactions that the data can be traced to its origin. 

Traceability

JThermodynamicsCloud was designed with the the notion that a database is not static. New data is continually being introduced and existing data objects may have to be modified. When data is used, for example in a calculation,it is important to the validation of its use to know the origins and history of the data. One of the major goals of JT.hermodynamicsCloud is to be able to trace a given piece of information back to its source and its modifications. For example, if a specific Benson rule is used in a calculation, the user can trace the source of this information back to the original input file that created it. If this value is an updated version of the Benson rule, then there would also be a connection to the value it replaced and this, in turn, would have a trace to its origins. These sources would also have a bibliographic reference to its origins, which not only puts a timestamp on the data, but also reflects the people and institutions that created the data.

The main tool that promotes traceability is the concept of transactions. A transaction is a class of tasks that perform modifications to the database. The database cannot be modified by any other means. Associated with each transaction are the set of prerequisite transactions, i.e. tasks, that are needed to perform the current transaction. Thus every modification of the database has a trace of transactions leading to the modifications. Each transaction produces a set of new output data objects that are stored in the database. Thus when a new transaction is to be performed, that data objects of the prerequisite transactions can be used as the basis for the new database objects. Thus, implicitly through the transactions, all data objects have traces to the data objects that were needed to create them. To perform a transaction task, there needs to be additional input information to steer how the prerequisite objects are to be transformed to the new data objects. This input information can also include other information, such as bibliographic references, abstract summary of the specific modification done. 

One of the purposes and goals of the use of transactions is to break down the creation of, for example, fundamental data into a series of simple generic tasks. The use of simple generic tasks promotes reusability of the algorithms. It also promotes a clear understanding of how the data in manipulated. One consequence of this is the creation of intermediate data being stored in the database. This intermediate data is used to create the fundamental data, but is not used as such.