ARDC DataCite DOI Service Policy Statement
1 Purpose
This statement describes the core policies underpinning the ARDC DataCite DOI service . Most of these policies arise as a consequence of the design and architecture of the global DOI and DataCite infrastructure which supports this service.
2 Background
ARDC collaborates with a range of partners to establish underpinning infrastructure that enables Australian researchers to gain competitive advantage through data. Persistent identifiers (PIDs) are a core component of this national infrastructure and key to world class, global research infrastructure. ARDC’s commitment to PIDs and our strategy in offering PID services are outlined in the ARDC Persistent Identifiers Policy .
As part of its PID strategy, ARDC has entered into a Consortium agreement with DataCite that allows users of the ARDC DataCite DOI service to create (“mint”) and maintain DOIs as part of national infrastructure to support excellent and impactful research in Australia.
3 Policies
3.1 Service functionality
The ARDC DataCite DOI service allows Australian research organisations to assign and manage DOIs for research datasets, collections or grey literature. DataCite is an international DOI service infrastructure. ARDC has a consortium membership with DataCite that allows Australian members to access this international service.
3.2 Service scope
To ensure that data relevant to research can be allocated a DOI, the ARDC DataCite DOI Service is designed for use by Australian research organisations or data centres relevant to Australian research, such as those run by Government agencies and universities. Participation in a DataCite national consortium is restricted to non-profit organisations.
In-scope:
Research datasets and collections, associated workflows, software and models
Grey literature such as theses, reports, unpublished conference papers, newsletters, creative works, preprint journal articles, technical standards and specifications for which the institutional repository is the primary publication point
Other resource types that are in scope for DataCite
Out of scope:
Published peer reviewed journal articles, ephemera, teaching and learning materials and book chapters
Digital objects that are not relevant to research
3.3 Service access
Clients are required to register with ARDC before access to the DataCite services are granted. Once registered with ARDC, clients can access the DataCite Fabrica Service to register and manage DOIs and metadata either programmatically via the Datacite API or by using the manual interface.
3.4 Data availability
The ARDC DataCite DOI Service is intended to identify datasets and other in-scope objects being made available to the national and international research community. Objects to which DOIs will be assigned should:
Be accessible. Note this can include both open access ( example ) and mediated access ( example ).
Be part of the scholarly record.
Be persistently available.
Have the metadata required by the DOI Service.
ARDC assumes no responsibility for the selection of datasets and other in-scope objects which are to be assigned DOIs. This remains the responsibility of the institution which has ownership of the objects.
3.5 Service style
The ARDC DataCite DOI Service encourages users of the service to maintain information in their own systems about the digital objects to which the DOIs are assigned. This is important to maintain the resolvability of DOIs when local URL’s change. We also encourage the integration of DOI minting into automated workflows to enable comprehensive coverage of datasets. For both these reasons, use of the API interface to the DataCite DOI service is encouraged.
3.6 DOI structure
The structure of the DOI will be in accordance with DataCite requirements.
Best practice for persistent identification would suggest not putting semantic strings into the DOI (i.e. not the name of the current repository) since that kind of information can go out of date or even be misleading in the future. This kind of contextual information is best put into the DataCite metadata. A simple alpha-numeric string is usually the best default starting point.
3.7 DOI metadata
Minting a DOI through the ARDC DataCite DOI service requires metadata. DataCite has a metadata schema that defines the valid format for submissions to its DOI registration system. The metadata will be publicly visible through the DataCite Metadata Search . ARDC encourages users of the DOI service to provide rich metadata, in particular the inclusion of other identifiers to related objects such as grants or publications.
3.8 Management of DOIs
ARDC assumes no responsibility for the management of DOIs minted using the ARDC DataCite DOI service. It is the responsibility of the client who minted a DOI to ensure it is kept resolvable and the metadata associated with a DOI is current.
3.9 Landing Page
Users of the ARDC DataCite DOI service are expected to adhere to DataCite requirements for landing pages. DataCite requires that the DOI continuously resolves to a response page (a "Landing Page") containing, at a minimum, (i) complete bibliographic information about the corresponding Content (including the Identifier), visible on the initial page, with reasonably sufficient information detailing how the Content can be cited and accessed, and/or (ii) a hyperlink leading to the Content itself, in each case in accordance with the Display Guidelines. Some examples of failures to meet this requirement include: publishing or communicating Identifiers without registering them with DataCite, withdrawing content without posting a notification (“Tombstone Page ”) and not updating the record's URL/metadata with DataCite. It is recommended that users of the ARDC DataCite DOI service follow DataCite’s best practice guidelines for landing pages .
3.10 Service availability and support
As Consortium lead, ARDC will provide Tier 1 service availability and support for users of the ARDC DataCite DOI service. Although ARDC and DataCite aim to ensure maximum availability of the DOI service, planned and unexpected outages will occur. Notice of all planned outages will be distributed via email prior to the event. Users of the service should ensure that software being integrated with this service is designed to cope with occasional service unavailability and that contact details are kept up to date.