RDA DOI Use Cases

The RDA has created a set of use cases to facilitate structured DOI management for the archive. Considerations include data security/resiliance, dataset version control, dynamic dataset extension, and dataset depreciation.

On this page:

- Create a new DOI for a dataset
- Complete dataset replacement (new data from the provider)
- Routine DOI dataset extension in time
- Removal of DOI dataset
- Small scale data replacement within a dataset

Create a new DOI for a dataset

  • Requirement: All files must have one-to-one match on tape (offline) and online storage
  • Mint a new DOI through DataCite

Complete dataset replacement (new data from the provider)

  • Requirement: Update dataset metadata to describe changes on the existing dataset landing page.
  • Assign a new DOI for the updated dataset
  • Legacy version:
    • Maintain in tape archive and remove from online storage
    • Create a new landing page for legacy DOI informing user that data has been replaced by a new version, and that the legacy version of data can be retrieved from tape upon request
    • Update legacy DataCite metadata so DOI resolves to new landing page

Routine DOI dataset extension in time

  • Archive new files
  • New files inherit existing dataset DOI
  • Need to regularly update temporal coverage in DataCite metadata

Removal of DOI dataset

  • Create a new "depreciated" dataset landing page to explain dataset status and end user options
    • Dataset file set is preserved and files can be restaged for access
    • Dataset file set has been deleted from system, explanation provided
  • Update DataCite metadata so the dataset DOI now resolves to the special “depreciated” dataset landing page

Small scale data replacement within a dataset

  • Files to be replaced are removed from the online storage (disk hosted) dataset file set
  • Files to be replaced are moved to new names that designate version history on the decsdata directory, and set to status "V" -version controled. These files are no longer visibile to the general user community
  • IVC is the "internal version control" number and DTS is the "date/time stamp" are saved as history in database
  • Re-assign IVC across complete file set
  • Outcome:
    • Original files permanently preserved
    • Replacement files published for public access
    • Version history maintained for internal provenance tracking, and can be used to support end users if needed
    • DOI remains the same