Skip to main content
Skip table of contents


Most asked

Is there an overview of how to get started with minting DOIs?

 Yes - this checklist for the ARDC DOI minting service is a good place to start.

How can we be sure Australian DOIs will continue?

All institutions who mint Digital Object Identifiers (DOIs) with ARDC are automatically registered with DataCite as member of the consortium. In the unlikely event that ARDC is no longer a Registration Agency with DataCite:

  • The DataCite organisation will continue to run its infrastructure and thus the status/availability/accessibility of existing DOIs will continue.
  • Previously minted DOIs and the metadata associated with those DOIs will persist through DataCite; your ability to manage and mint new DOIs will also persist.
  • ARDC will develop a transition plan and provide advice or recommendations about alternative arrangements to create new DOIs.
  • It is the institution's responsibility to continue to manage your existing DOIs and to manage any changes or moves of data location to ensure the DOI resolver continues to work.
What is the cost of minting and maintaining a DOI?

Minting costs: there is no cost to mint DOIs through the ARDC DOI service for publicly funded Australian research organisations, or Government agencies.

Maintenance costs: while there is no direct fee or charge associated with maintaining a DOI at this stage, there are other costs associated with ensuring persistence as part of routine data management. It is the responsibility of the institution to maintain the persistence of the DOI. If the URI  changes, it is the responsibility of the data manager to update the URI either manually using the Fabrica interface or though the DataCite API.

How can we get DOIs for our data collections and related scholarly outputs?

 Check out the ARDC DOI Service to find out how to mint DOIs using the simple machine-to-machine workflow or via a user interface.

Who should mint and manage DOIs within an institution?

Whoever is taking responsibility for controlling access to, and preservation of, the resource usually has responsibilities for both minting and the ongoing management for DOIs.

It is possible for an institution to have:

    • multiple data publishers (e.g. institutional repositories, discipline based repositories etc.) all using a single DOI minting service - this is the ARDC preferred state
    • multiple DOI minting services in the same institution registered with ARDC - the institution will need to determine policy around ensuring multiple DOIs are not minted for the same data.
    Do we need rules for our DOIs?

    Institutions should develop business rules or procedures to underpin DOI minting and management. Consider for example:

    • Which datasets will be assigned a DOI (e.g. all datasets made public, or only those datasets associated with a peer reviewed publication)?
    • At what level of granularity will they be assigned (e.g. at the data file level, or collection level? Consider how the data may be reused and cited).
    • How will changes to metadata or data (updates, versions) be dealt with?
    • Who is responsible for maintaining persistence of DOIs ? (i.e. resources, roles & responsibilities).

    These examples are a good starting point, although each institution is likely to have local factors to consider:

    Please get in touch with the organisation for the most recent version of their guidelines.

    ARDC DOI Service

    Is the DOI service completely automated, or would human mediation be advisable?

    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.

    Can I request a single DOI through a manual process?

    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.

    Is there an example DOI minting workflow?

    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.

    Applying DOIs

    Should DOIs be applied to "mediated access"and / or "restricted access" data?
    • 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.
    Should DOIs be applied to "private" data?

    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.

    When are DOIs appropriate?

    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.
    What about DOIs for derived datasets?

    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.

    Do we apply DOIs at the collection, subset or item level?

    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.
    Does the DOI point to the metadata (description) record or directly to the data?

    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.

    Can we get DOIs for other digital objects in our repository e.g. theses, reports

    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 if you wish to use DOI service to assign DOIs to grey literature.

    What about DOIs for software, workflows, computational models and grey lit?

    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.

    Minting, maintaining and storing DOIs

    What happens with DOIs if object is moved/updated/expanded/snapshot/new version?

    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 ( 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 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.
    Can we mint a DOI for data produced through multiple-institution collaborations?

    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).

    How can we avoid minting multiple DOIs for an object?

    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.

    Is there a way of finding how many DOIs we have and getting a list of these?

    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.
    How many DOIs can / should we mint?
    DOIs for Australian research institutions are free to mint through the ARDC DOI service and are effectively infinite. The number to mint will depend on the ability of the institution to keep all datasets with a DOI persistently available, and whether the data meets the criteria for DOIs. The ARDC Identifier Decision Tree can further help you decide which datasets should have a DOI.
    How should we display and store our DOIs?

    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.

    Can I get a DOI if my data doesn’t come from a publicly funded AU research org?
    If your data is NOT generated through publicly funded Australian research organisations or Government agencies you cannot get a DOI from ARDC.

    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.

    Can DOI strings include our institutional name?

    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. or sequence branding (e.g. - particularly if the organisation name changes. However, please contact if your organisation has a strong case for customised DOIs.

    DOI strings do not have meaning. 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).

    Fabrica Usage

    Can we request individual Fabrica accounts?

    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.

    Can we change our organisation name and/or our repository name in Fabrica?

    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.

    Our repository password reset link expired. How can we get the password reset link again?

    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 and entering your repository ID (e.g. ARDCX.ARDC) as account ID.

    We are getting errors when trying to login to DataCite Fabrica test or production system
    • '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
        • Click the padlock icon then click "Clear cookies and site data". Select any of the sites (all should end with then click Remove. Repeat for every site listed (the site 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
        • Click the padlock icon then click "Cookies". Select any of the sites (all should end with 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.

    Known Issues

    Affected areaIssue DescriptionWorkaround (if available)

    Fabrica login/authentication

    Individual authentication is currently not supported by DataCite Fabrica

    None. It is strongly advised that organisations distribute the Fabrica credentials ONLY to anyone who has valid business requirements for access and that these individuals understand the risk of using shared account.

    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.

    Fabrica manual entry formUnable to add user-defined Creator's affiliation that are not in the Research Organization Registry (ROR)'s database

    There are two ways to add an affiliation that is not yet listed in ROR to the metadata of a DOI.
    1. You can create a DOI using the form. Then download the XML file, edit the XML file (pasting the organisation name) and upload the XML file.
    2. If there is no ROR ID for the organisation you are looking for, you could send a request to ROR and they will create one. At the moment ROR only indexes organisations at the highest level which you could use in the meantime until ROR has found a way how to address curation on a granular level.

    Fabrica manual entry form

    Unable to update a DOI minted via API or XML when using the Fabrica manual interface. User is getting error "To save this DOI, first resolve the errors with these properties: <element name>" even if the <element> has not been changed since minting the DOI.

    For instance, a date with value 2016-001-01 to 20120-02-01 will have to be changed to 2016-01-01/2020-01-01 (as per schema documentation, date should be in an ISO8601 format).


    DOIs minted via APIs or XML upload are always accepted by Fabrica even if the value of the elements do not comply with the schema documentation requirements. This is because the XSD validator checkes the values entered via the manual entry form while DOIs minted via XML upload or via the APIs do not.

    DOI creation or update (either via MDS API or manual entry form)

    Unable to add alternateIdentifier to a DOI using a MDS API or the Fabrica manual entry form.

    The altenateIdentifier element is being dropped when a DOI is updated or minted with in Findable state. Users are able to add this element in Draft but it is dropped when changing state to Findable.


    This is a reported bug. Users are encouraged to add comments and examples in DataCite's GitHub bug register

    JavaScript errors detected

    Please note, these errors can depend on your browser setup.

    If this problem persists, please contact our support.