Track Version Changes

From Dryad wiki
(Redirected from Versioning)
Jump to: navigation, search

This page describes the versioning system, which enables depositors of data to add an updated version of a data file, usually to correct an error in the original file, or to provide the data in a different format.

Overview

The Dryad submission system allows depositors to add a new version of a data file. A major focus of Dryad is archival preservation of the scientific record, so the repository always will retain the original data file(s) as submitted, but in some cases authors may wish to correct errors in the archived data. The versioning system allows this.

If a file has multiple versions, the most current one will always be displayed by default. Earlier file versions will be listed on the data package page.

Instructions

Dryad depositors who wish to add a new file to their data package, to correct or clarify their data, can do so by contacting the Dryad curator, who will handle adding the file to the data package.

Soon we wish to enable authors to add new versions of their files themselves. At this time we recommend that authors contact the curator, who will handle the versioning.

Technical Documentation

Documentation on atmire wiki:

Design History

Versioning was developed in late 2011 and early 2012, and released to users in March 2012.

Goal: The history of an item should be available, and it should be possible to cite a particular version of the item.

Requirements:

  1. Data packages and data files have a relationship between their identifiers. Each version of a file/package is represented by a separate DOI. The "base" DOI points to the most recent version of the file/package, but a version number can be added to the base DOI to access previous versions. See the DOI Usage page for more details about the DOI format.
  2. When a new version of data file is deposited, a new identifier will be created for the data file item, as well as the containing data package item.
  3. Adding or changing README files or metadata will not result in creation of a new identifier.
  4. All metadata changes are logged by writing a metadata snapshot to the filesystem -- this allows us to retain a record of the changes, even though they are not available as explicit versions (and not viewable in the UI). Each item's metadata should record the time of last modification.
  5. If all we are doing is adding a new bitstream without changing the existing bitstreams, there is no need to force a version number change.
  6. When a new identifier is created for a data file, a new identifier is automatically created for the corresponding data package.
  7. Each version of the item includes metadata about who created the version and the date/time. (it is essentially a full copy of the item, with modifications)
  8. Only the most recent version of an item is available via the search interface.
  9. On the item page, there is a link to view previous/subsequent versions.
  10. By examining the metadata, it is possible to determine whether an item is the most recent version, the original version, or an intermediate version. This information is machine-readable.
  11. Previous versions of bitstreams are retained. If something was once retrievable, it is always retrievable.
  12. Creation of a new version is initiated by the submitter. On the "submissions" page, users should see all of their archived submissions. Each archived submission should have a button to submit a new version of a data file.