The ARDC DOI service offers options for automated machine-to-machine minting of DOIs as well as a manual minting service. Processes to monitor service calls should also be implemented to manage any error or update messages returned from  the DOI service.

Yes, the manual minting service is likely to be of interest to those institutions (not individuals) that expect to mint only a small number of DOIs, or as an interim measure while the machine-to-machine service is established.

The DOI Participant Agreement needs to be completed for both the manual minting and machine-to-machine options.

CSIRO has provided their workflow. Minting workflows will vary widely from data owner to data owner. Larger institutions will probably prefer a fully automated system that integrates well with other systems and provides management, reporting  and auditing. Simpler workflows may be suitable for small institutions or data holders.

• Mediated access - Yes the metadata record is public but access to the dataset is through a contact person.
• Restricted access - Yes the metadata record is public but access to the dataset is only under certain conditions or available to certain people.

 No where both the metadata record and the data are private a DOI should not be minted as this data will not be part of the scholarly record and potentially cited. Another persistent identifier (Handle) may be more appropriate. The ARDC Handle service provides a way to automatically assign globally unique citable identifiers, based on Handle technology, to an individual's datasets, collections, papers and so on.

DOIs are appropriate when:

• The data will be exposed to the outside world, possibly through mediated access.
• The data will be citable and part of the scholarly record.
• The data will be persistently available.
• The data will have the minimum citation metadata required by DataCite.

 If you are producing a derived product from the data which results in a new, or substantially altered, dataset then a new DOI should be minted and the original dataset noted in the metadata for the new DOI.

The decision to apply DOIs at collection, subset or item level needs to reflect the needs of the communities involved, what they need to cite and how they will use the data. It's a bit like citing a book versus pages in a book. Consider: 

1. Data users: would they expect to use (and thus cite) the data at collection or item level (e.g. archaeological specimens, tissue samples)?
2. An institution might consider citing at multiple levels: 
   
   • parent collection DOI example
   • data item DOIs.
     Collections are intrinsically more citable than items, and collections can impose indexing on items to retrieve them.
3. Specific subsets and queries against large databases: it is probably best to have a DOI that binds to a temporal/spatial query against the database. The DOI should resolve to the result of this query and not to a "live" query so that the DOI resolves to the same dataset on each access.

ARDC requires that each DOI minted through the ARDC DOI service is associated with a resolvable URL which points to a landing page for the data being identified by the DOI. This should be a metadata record you manage in an institutional or domain-specific repository or metadata store.

A landing page generally contextualises objects and provides at least the following information:

• preferred citation
• descriptive metadata
• license information for reuse of the data
• a link to any accompanying paper(s)
• how to access the data
• and perhaps: links to subsets, persistent queries, versions of the same dataset.

If there is no landing page as described above, the idea of a resolvable "landing page" for data access can also cover:

• a human-readable web landing page with links to the data
• a human-readable web page with instructions for accessing mediated-access datasets
• a machine-to-machine oriented web service that uses content negotiation between data client and server to customize data formats and access patterns
• a well known data service end-point (e.g. for an OPeNDAP service) that requires a customized service client.

Where no other option exists, and subject to specific criteria, a DOI may resolve to a collection record in Research Data Australia.

In April 2016, the scope of the DOI Service was expanded to include grey literature.

Examples of grey literature that may be assigned a DOI using the ARDC service include theses, reports, unpublished conference papers, newsletters, creative works, pre print journal articles, technical standards and specifications for which the institutional repository is the primary publication point.

Published peer reviewed journal articles, ephemera, teaching and learning materials and book chapters are out of scope for the ARDC DOI service.If you wish to assign DOIs to these materials, other DOI Registration Agencies such as CrossRef should be consulted. Contact [email protected] if you wish to use DOI service to assign DOIs to grey literature.

The ARDC DOI service mints DOIs for data and associated workflows, software and models, provided the citable item has the minimum metadata requirements and is part of the scholarly record.

Many datasets will change in version, scope and content over the life cycle so it's important to have a strategy for dealing with change. As a general rule, if the change is substantial and / or it is necessary to identify both the original and the changed material, assign a new DOI (doi.org FAQ).

• Moved data: if the data storage location changes, update the URL using the DOI Query Tool in the RDA Registry. If the new URL domain is not registered against the institution's  DOI account, contact [email protected] to have the new domain added. Do not mint a new DOI.
• Minor changes (clarifications, minor errors, etc): issue a set of changes to the original data and link this to the original DOI.
• Regular changes (large evolving datasets that are changing regularly): mint new DOIs for each regular update or snapshot.
• Significant changes: mint a new DOI and ensure the DataCite metadata element 'RelatedIdentifier' (and other metadata as needed) is used to refer to the previous versions of the dataset.
• Software updates: new DOIs should be minted for changed versions of software or software services.

 Usually whoever is managing the data coming from a research collaboration should mint the DOI. Deciding who will mint the DOI should be part of the data management practices for the collaboration. Institutions should not mint a DOI for data from a third party (e.g. multi-partner and consortia  projects).

To ensure that only one DOI per item/collection is minted it is best to have agreement between the collaborating institutions about who will be responsible for minting the DOI.

Do not mint DOIs for the sake of getting a different landing page. This violates the point of persistent identifiers, which are meant to be at FRBR (Functional Requirements for Bibliographic Records) Manifestation rather than FRBR Item level. Instead, look closely at Open URL, which is how the publishing industry already addresses resolution of DOIs to multiple locations. Data owners could also use the optional metadata to build references to other DOIs forming part of a collection or dataset changing in time.

There are ways to list the DOIs minted by the Consortium Organisations:

• The DataCite Fabrica interface allows you to view a listing of all the DOIs you have minted , including those previously minted through the legacy ARDC DOI interface and/or API. For more information on accessing the user interface, please refer to the technical documentation.
• Data owners can also query the DataCite Metadata Store web services directly.
• Users and data owners can also go to the publicly accessible DataCite Search interface to search and/or list the DOIs minted for the organisation. A listing of all Repositories in DataCite can be directly accessed here.

Displaying the DOI encourages citation using the DOI rather than the URI and is part of already well developed scholarly practices for citation for example.

DOIs should be stored in both the data repository and / or metadata store, for different reasons:

• The metadata store becomes a system of record for referencing data from the outside world.

• The data repository is where the fragile URL is linked to the persistent identifier.

Storing locally is a decision data owners will need to make based on local factors but the DOI needs to be integrated into your data management, otherwise you will keep using fragile URLs to refer to it instead. DOIs are also stored in Research Data Australia, and in the global DataCite and DOI infrastructure.

If it is still within the scope of DataCite it is possible that one of the other DataCite Registration Agents would be able to help you. For example you might like to inquire about minting DOIs from the California Digital Library using EZID or from figshare.

ARDC DOIs are only opaque and random (e.g. 10.4225/02/4E9F5DE549B8D). These are considered best practice because they are the most persistent and sustainable with minimal maintenance. Substantial effort may be required to maintain DOIs that incorporate organisational (e.g. doi.pangaea.de/10.1594/PANGAEA.762817) or sequence branding (e.g. http://dx.doi.org/10.5255/UKDA-SN-4093-1) - particularly if the organisation name changes. However, please contact [email protected] if your organisation has a strong case for customised DOIs.

DOI strings do not have meaning. DOI.org reminds users that DOIs are case insensitive and that "A DOI name and its referent are unaffected by changes in the rights associated with the referent, or changes in the management responsibility of the referent" (2.3.6 Persistence).

"In use, the DOI name is an 'opaque string' or 'dumb number' — nothing at all can or should be inferred from the number in respect of its use in the DOI system. The only secure way of knowing anything about the entity that a particular DOI name identifies is by looking at the metadata that  the Registrant of the DOI name declares at the time of registration. This means, for example, that even when the ownership of a particular item changes, its identifier remains the same - in perpetuity. This is why the DOI name is called a 'persistent identifier'." (2.2 Syntax of a DOI Name).

As it is now, your repository accountID and password is shared among all the users within the organisation’s repository members therefore, we strongly recommend that  you only distribute the credentials to anyone who has valid business requirements for access.

DataCite is currently planning to move towards individual authentication in Fabrica. Once individual authentication is rolled out, every valid user will have their own login account and logging in through the repository account ID will no longer be available.  DataCite and ARDC will announce when this functionality becomes available.

The way the DataCite Fabrica system currently works is that there is no way to edit or update the organisation name or repository ID once it’s created. If there is a valid business need to change the organisation member ID and/or repository ID, the only way to do this is by creating a new repository under a new consortium organisation. DataCite would then transfer the DOIs and prefix from the old repository to the newly created account. 

You, however, can change your repository name when you are logged in to Fabrica.

You have 24 hours to reset your repository account password using the link sent to your system email address when a repository has been setup. If you missed this window, you can always generate a new password reset link by going to https://doi.datacite.org/reset and entering your repository ID (e.g. ARDCX.ARDC) as account ID.

• 'A web page is slowing down your browser' error in Firefox.  
  • Option 1:Disable Shockwave Flash plugin/extension in the browser settings. 
    • Go to Firefox > Preferences
    • Click on 'Extensions & Themes' 
    • Disable Shockwave Flash by un-ticking 'Block dangerous and intrusive Flash content' 
  • Option 2: Clear cookies and cache
    • Navigate to https://doi.datacite.org/
    • Click the padlock icon then click "Clear cookies and site data". Select any of the sites (all should end with datacite.org) then click Remove. Repeat for every site listed (the site doi.datacite.org may not vanish from the list).
    • Refresh the page.
    • Click the Accept button at the bottom right (to accept cookies).
    • Click the Sign In button and log into DataCite Fabrica.
• In Chrome, Fabrica page just would not load.  No error messages displayed on the screen.
  • Disable (or remove) XML viewer extension. If this extension does not exist, users are encouraged to disable or remove the plugins or extensions one at a time.
    • Go to Chrome > Preferences
    • Click on 'Extensions'
    • Disable XML Viewer (or other extensions if this did not work)

• • Option 2: Clear cookies and cache
    • Navigate to https://doi.datacite.org/
    • Click the padlock icon then click "Cookies". Select any of the sites (all should end with datacite.org) then click Remove. Repeat for every site listed.
    • Refresh the page.
    • Click the Accept button at the bottom right (to accept cookies).
    • Click the Sign In button and log into DataCite Fabrica.