Best Practices for DOI Registration

Overview

A DataCite Member/Consortium/Consortium Organization is an organization that has joined to DataCite in order to register DataCite DOIs.

This document summarises some of the key best practices for DOI registration and management.

What can a DataCite DOI be assigned to?

1. DataCite Members can assign a DOI to content that their organization has responsibility for. DataCite expects all Members to be active stewards of the content they are assigning DOIs to. This means they need to be able to update the content and metadata. It is not permissible to provide or resell DOIs to third parties.

2. Do not assign a DOI to an identical version of the content if the same content is already published somewhere else with a DOI. You can assign a new DOI to an author-deposited manuscript, but this must not be the final published version. Please check copyright before assigning a DOI.

3. DataCite Members can assign a DOI to multiple types of research outputs. The DataCite Metadata Schema must be suitable for describing these items.

4. DOIs must resolve to a publicly available landing page. The underlying content does not need to be publicly available, but the metadata must be open.

What is the recommended way to handle versioning?

The DataCite Metadata Schema documentation recommends that a new DOI should be assigned when there is a new major version of the resource you are sharing. DataCite recommends adding a relatedIdentifier to each DOI with the relationType as follows:

HasVersion : The registered resource such as a software package or code repository has a versioned instance (indicates A has the instance B) e.g. it may be used to relate an un-versioned code repository to one of its specific software versions.

IsVersionOf : The registered resource is an instance of a target resource (indicates that A is an instance of B) e.g. it may be used to relate a specific version of a software package to its software code repository.

For minor versions, a new DOI may not be necessary. DOI metadata can be updated, which allows for correcting errors, adding additional files, or incrementing a minor version number.

Guidelines for forming DOIs

A DOI consists of a numeric “prefix” (beginning with 10.xx), followed by an alphanumeric “DOI name” or “suffix”. DataCite recommends using opaque suffixes that do not convey any semantic information. Our APIs allow the automatic creation of opaque suffixes using random strings.

Guidelines for displaying DOIs

DOIs should be displayed as a full clickable URL of the form: https://doi.org/10.7939/r3qz22k64

DataCite DOIs should be displayed as the full URL when bibliographic information about content is displayed. DataCite encourages all Members to display DataCite DOIs on their Repository landing pages. We also recommend that DataCite DOIs be displayed or distributed anywhere users are directed to a permanent, stable, or persistent link to the content including:

• abstracts
• tables of contents
• full-text HTML and PDF articles, and other scholarly documents
• citation downloads to reference management systems
• metadata feeds to third parties
• “How to Cite This” instructions
• social media links

Guidelines for landing pages

1. DOIs should resolve to a landing page containing metadata about the item.
2. DOIs should not resolve directly to the content.
3. The landing page should contain a full bibliographic citation.
4. The DOI should be displayed on the landing page (so humans can read it).
5. The DOI should be appropriately tagged (so that machines can read it).
6. The landing page should provide a way to access the item.

Guidelines for tombstone pages

A tombstone page should be created whenever the item a DOI describes is no longer available, for whatever reason. In general, however, it is better to avoid creating a situation in which a DOI's item is removed, if at all possible. This means being very careful not to accidentally create DOIs, or to put safeguards in place so that users of your service are not able to accidentally create DOIs.

1. In general, the guidelines for landing pages still apply, with the exception that it is not necessary for the user to be able to access the item from the landing page (since the item has been removed).

2. A statement of unavailability should be included that details the circumstances that led to the item’s removal.

3. DataCite DOIs that describe removed content should be updated to the “Registered” state so that they remain resolvable without being publicly indexed.

4. The DOI must be updated to change its associated URL to the URL of the tombstone page.

Draft State

The DataCite APIs can use Draft state, which saves the identifier string, but they are not resolvable and are unpublished. Draft state is useful in cases where a user wants to “reserve” the identifier for later use. Draft state metadata can be deleted. DOIs in Registered or Findable state cannot be deleted. If your implementation makes use of Draft state via DataCite, the submitted metadata will be part of the DataCite Member’s account, but it will not be accessible to anyone who does not possess that Member’s credentials. You are not required to make use of DataCite’s Draft state
(for example, if you have implemented a similar feature local to your own service), but it is highly recommended for both troubleshooting and for preventing accidental registration.