ResData is a UNSW Library service for managing UNSW research data. The service, currently based on Fedora 3.7, has two main components:
- Research Data Management Plan (RDMP) - allows UNSW researchers and Higher Degree Research (HDR) Candidates to record metadata about research projects and associated research data. Completion of an RDMP is a requirement for allocation of storage in the UNSW Data Archive.
- A catalogue of UNSW datasets and collections of research materials
There are four main types of objects or records that are ingested, queried and updated in ResData: Dataset, Party, Activity and RDMP, where a Dataset or an RDMP must have 1 Activity and 1 or more Party associated it. Therefore, every ingest or update via ResData UI triggers a transaction that affects 1 Dataset or RDMP, 1 Activity and at least 1 Party object.
ResData transactions are required to be ACID as below:
- Atomicity is needed to ensure that for each failed ingestion of a Party or an Activity or a Dataset or an RDMP, all previously ingested records within the same transaction are rolled back. For example, a researcher creates a Dataset A that is linked to Party A and Activity A. During ingest, Party A and Activity A are ingested successfully but Dataset A fails. ResData must be able to remove Party A and Activity A from Fedora and inform the researcher accordingly. In Fedora 3, this gets extremely complicated when versioning of records is enabled.
- Consistency is required to ensure that a successfully ingested Dataset or an RDMP has only 1 Activity and at least 1 Party associated with it. This is currently done at client level with relative ease.
- Isolation ensures that each ingest or update transaction in ResData is executed sequentially. In ResData, it is possible to have an RDMP and a Dataset link to the same Activity - this could lead to data integrity issue with the Activity, if both the RDMP and Dataset are ingested concurrently . This is currently handled at client level by placing a lock on a record that is being modified.
- Durability is needed to permanently store all committed changes to Fedora and guarantee recovery to original state in the case of errors, crashes or power failure.
