Best Practices for Service Providers

Overview

A Service Provider is an organization that has integrated with one of the DataCite APIs to enable other organizations to register DataCite DOIs. DataCite Service Providers do not offer DOIs, but do offer DataCite Members and Consortium Organizations the ability to register DOIs through their platform. Members and Consortium Organizations register DOIs using their own Repository account credentials.

This document outlines a specific set of best practices that participants in the DataCite Registered Service Provider program should make best efforts to adhere to. Further best practices and guidance for all DataCite users can be found at our dynamically updated support site: https://support.datacite.org.

DataCite terminology

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. There are two types of membership that support DOI registration:

• Direct Member: In the DataCite membership model, a Direct Member supports DataCite's research sharing mission and is an organization that works with one or more repositories within their organization. A Direct Member account has permission to create new Repositories and update contact information.
• Consortium: In the DataCite membership model, a consortium is a group of organizations within one region or discipline that have come together to collectively participate in DataCite’s community and governance activities and use DataCite’s DOI services. A Consortium Lead account has permission to create and manage Consortium Organization accounts and new Repository accounts as well as contact information .

Consortium Organization: A Consortium Organization is part of a DataCite consortium. The Consortium Organization account has permission to create and manage new Repository accounts and update contact information.

Repository: Repositories play a key role in the DataCite membership model and are defined as a service operated by research organizations, where research materials are stored, managed and made accessible. A Repository is a single unit. A Repository account represents a store where all the DOIs for a group of resources are registered and will stay together. They have one unique prefix and are used exclusively for DOI registration. A Repository account may belong to a Direct Member or Consortium Organization.

Prefix: The beginning numeric portion of a DOI string before the slash. A DOI prefix always starts with '10.' and continues with a number (e.g., '10.1234' or '10.20865'). Each prefix may be associated with one and only one Repository. 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.

What can a DataCite DOI be assigned to?

DataCite Members and Consortium Organizations must follow the DOI Registration Policy. Service Providers should keep this policy in mind when designing integrations and working with customers who are DataCite Members or Consortium Organizations.

This policy specifies that:

1. An organization can only assign a DOI to content that their organization has responsibility for. DataCite expects all Members (and Consortium Organizations) 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. DOIs should not be assigned 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. DOIs can be assigned 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.

Guidelines for forming DOIs

A DOI consists of a numeric “prefix” followed by a “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.

More information: What characters should I use in the suffix of my DOI?

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

More information: DataCite DOI Display Guidelines

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.

More information: Best Practices for DOI Landing Pages

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.

More information: Best Practices for Tombstone Pages

Guidelines for 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.

Reserving DOIs

The DataCite APIs allow the creation of Draft DOIs, which are DOIs that are not resolvable. Draft DOIs are useful in cases where a user wants to “reserve” a DOI for later use. Draft state DOIs can be deleted. DOIs in Registered or Findable state cannot be deleted. If your implementation makes use of Draft DOIs via DataCite, the submitted metadata will be part of the DataCite Repository account. You are not required to make use of DataCite’s Draft DOI 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 DOI creation.

More information: DOI States