Transactions are the one of the more important features promoting the traceability of data as it is created and transformed within the database. A single transaction event performs a single task. However, this task could be dependent on other prerequisite transaction tasks. In other words, the prerequisite transactions set up the necessary data for the current task. Thus inherent in the definition of a transaction is the list of prerequisite transactions that are needed. The transaction event can be thought of as a node in the tree of manipulations that data undergoes. The transaction also is a tool to isolate single tasks making the organization of data manipulation more transparent.
The ontology's role in this design is to give the specification to the input to the transaction, this includes the list of transactions that are needed to perform the current transaction. Due the structure of the database and the organization of transactions, often just knowing the type of transaction needed is enough to isolate the particular prerequisite transaction needed. If the exact prerequisite transaction cannot be isolated, the choices for the user are fewer.
The ontology provides the complete specification of each transaction, i.e. the form of the expected input and output information. Each transaction is described with an ontology class which is in the subclass hierarchy under dataset:TransactionEvent, a subclass of Dublin Core class dcmitype:Event. The specification in the form of an ontology class has several properties:
dcat:catalog: This is the class of the catalog object that the transaction creates. This is the class of the object that is in the array of the response under dataset:simpcatobj.
dcterms:source: This is the class of the dataset:ActivityInformationRecord JSON input information object that is needed to derive the output catalog objects. The ontology class specifies the supplementary data needed to perform transaction. This input object is pointed to by the dataset:activityinfo in the RESTful service call.
dcterms:type: This is the class of transaction that is produced. This class is a subclass of dataset:ChemConnectTransactionEvent (which ultimately is a subclass of dataset:SimpleCatalogObject which is a subclass of dcat:Catalog). The database transaction catalog object is not the same class as the transaction class specification. Different transaction class specifications can produce a database transaction object of the same class.
dcterms:requires: These are the classes of the transaction specifications, i.e. subclass of dataset:TransactionEvent, that are required before this transaction can be performed. Through these transaction specifications the database transaction object class that was produced by the transaction is specified. This class information is used to retrieve the specific database transaction
The example we will use the the dataset:PartiionSetWithinRepositoryFile transaction. The input information specified by the dcterms:source field is the class dataset:ActivityRepositoryPartitionToCatalog. Within this information is the record, dataset:DatasetTransactionSpecificationForCollection. This class has two fields specifying the dataset:DatasetName, such as StandardData, which specifies the database dataset that is ultimately going to the formed, and the field which specifies the dataset:CatalogObjectUniqueGenericLabel. such as tableA1CarbonBensonRules, which is a unique name specifying the particular chain of transactions which interprets a file of Rules used in the database. With these two labels, the collections that is ultimately pointed to is:
hierthermodynamicdataset -> UOqk0KtFtaXma5TGsi8Seh9RMbx1 -> StandardData -> tableA1CarbonBensonRules
At this point in the collection hierarchy each sub-hiearchy represents a particular transaction, including the previous transactions that have been performed to interpret the file. are all the transactions having to do with interpreting the tableA1CarbonBensonRules rules for the database. But since all the transactions for this manipulations