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.
The following is terminology used at DataCite that is relevant to the rest of this document.
Member : The entity that joins DataCite. This entity is responsible for paying membership fees and has voting representation in DataCite’s governance. A Member has at least one (but may have more than one) Repository.
Consortium : A special class of Member in which multiple entities join as a consortium. A Consortium Member is made up of multiple Consortium Organizations that each have at least one (but may have more than one) Repository.
Repository : The entity that creates DOIs. One Repository is one set of DOI-creating credentials. A Repository has at least one prefix.
Prefixes : The beginning numeric portion of a DOI string before the slash, leading with 10.xx. Multiple
Repositories (i.e. multiple sets of DOI-creating credentials) may not share prefixes. It is possible for a Repository to have more than one prefix, but DataCite generally recommends a one-to-one relationship between Repositories and prefixes.
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.
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.
DataCite Members can assign a DOI to multiple types of research outputs. The DataCite Metadata Schema must be suitable for describing these items.
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.
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.
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.
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:
- 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
- DOIs should resolve to a landing page containing metadata about the item.
- DOIs should not resolve directly to the content.
- The landing page should contain a full bibliographic citation.
- The DOI should be displayed on the landing page (so humans can read it).
- The DOI should be appropriately tagged (so that machines can read it).
- The landing page should provide a way to access the item.
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.
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).
A statement of unavailability should be included that details the circumstances that led to the item’s removal.
DataCite DOIs that describe removed content should be updated to the “Registered” state so that they remain resolvable without being publicly indexed.
The DOI must be updated to change its associated URL to the URL of the tombstone page.
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.
Updated 2 months ago
More detailed guides can be found in the Best Practices section of the support site.