Status: The DOI structure described on this page is final. Created March 2010 by Ryan Scherle Discussed Spring 2010 with various stakeholders
This page describes how Dryad assigns DOIs. For information about how to cite data in Dryad, see Citing Data. Recommendations for depositors and users about DOI presentation and placement are included in the Curator's messages to authors and journals, and can be found on the Depositing Data and Using Data pages of the repository website.
Dryad assigns DOIs for its data packages and data files. DOIs provide persistent links and can be used to cite Dryad content.
For information about the software system in Dryad that manages DOIs, see DOI Services Technology.
Dryad's DOI prefix is 10.5061
Identifiers in Dryad need to contain the following information:
- The (DOI or Handle) prefix
- The string "dryad", for branding purposes
- An accession number for the data package
- A version number for the data package
- (for data files) An accession number for the data file
- (for data files) A version number for the data file
- Data package 1234 version 2
- By default, if the version number is omitted, the most current version is returned
- The 3rd file of data package 1234 version 2 (first version of this file)
- Data files also allow use of a "default" version. There is only one default identifier per file, which is not affected by the versions of the data package:
- The majority of human use will be at the level of data packages, which have relatively short identifiers.
- a version number can be omitted to signify "the most recent version of this object", which is desirable in many situations (e.g., the Dryad search interface, OAI-PMH provider)
- DOIs are defined to be case-insensitive.
- CrossRef's guidelines discourage keeping version information in the DOI, but the guidelines are being revised.
Levels of Persistence:
- The most commonly used formats are registered as DOIs. We may call them "object identifiers". They are permanent and citable.
Number of DOIs required:
- assume an average of 2 data files per package
- assume 2 versions per data file (base file, possible migration)
- For each package.... 1 default package DOI, 2 versioned package DOIs, 2 default file DOIs, 4 versioned file DOIs
- We have a minimum of 6 DOIs per "typical" data package, and we can expect 9-12 total identifiers per "typical" data package that undergoes some version changes.
- Should the DOI for a data file be syntactically related to the DOI for a data package? Yes.
- Reasons to relate them:
- This is consistent with the Web architecture.
- People who use Dryad identifiers can perform some simple manipulation on the DOI to get useful results. ("hackable identifiers")
- It is more obvious when people are citing a file versus a package.
- The journal representatives think it is important.
- Reasons NOT to relate them:
- The more semantics added to an identifier, the more brittle it becomes, and the more likely that problems will ensue. (But it this isn't too bad as long as we are clear to users that the identification is permanent, and the hackability may change.)
- This structure in the identifiers complicates the use of version numbers in the identifiers (see below).
- Reasons to relate them:
- Should we reserve a DOI for "all available versions of this object"? No. This can be treated as a REST command. It will be available in human-readable form from the item display pages. There is no established standard for this, so it is not worth registering a DOI to reserve this functionality.
- Should migration to a new version (the most common operation that "changes" an item in DSpace) create a new DOI? No. 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.
- Does modification of a file force version changes of the other files, or can the other files continue to use a DOI based on the original package?
- The other files can retain their original ID. This lessens hackability, but isn't terrible. We don't expect items to be versioned regularly. For systems that want to ensure they always have the latest version of an item, they can parse the metadata for the package object and download the latest versions. (Or they can just use the abstract DOI, which will always point to the latest version.)
- Greg Janee's manifesto on identifiers and versioning
- The DOI foundation is working on alternate resolution strategies
Dryad uses the EZID service from California Digital Library to assign DOIs.