Identifiers (DOI & ARK)¶
Every published item gets two permanent identifiers. This page explains how they're minted, kept in sync, and checked. For the reader-facing explanation, see DOIs & ARKs explained.
The strategy: DOI primary, ARK fallback¶
- The Crossref DOI is the primary, cited identifier for all content types (prefix
10.67178). - An ARK is always minted and always resolves as a durable fallback (NAAN
53360,ark:/53360/<suffix>, resolved by Amoud's own resolver via N2T). - An item's DOI and ARK share the same suffix.
When identifiers are minted¶
Identifiers are created at approval (a reviewer accepts the item) or at install (bulk import finalisation) — not when a depositor submits. So registration, browsing, and the submission form are all pause-free: nothing reaches Crossref until an item is published.
How minting works¶
DSpace 9 ships no Crossref connector, so AU-IR uses a custom XML pipeline (Crossref
schema 5.4.0) under scripts/:
- A cron job runs every 10 minutes and deposits DOIs for items that are archived, have an ARK, lack a DOI, and are in scope (guarded by a lock so runs don't overlap).
- A nightly verify (≈03:00) confirms every DOI still resolves at doi.org.
- A nightly resync (≈03:20) reconciles edited records with Crossref.
- A preflight report flags problems in the RIC review queue before they're approved.
Panel saves do not notify Crossref
Editing an item through the citation/export panel does not push the change to Crossref. The nightly resync is the bridge. If a correction must reach Crossref immediately, trigger/await the resync rather than waiting for a panel save.
Two rules that protect data integrity¶
Never mint a duplicate DOI
For work already published elsewhere, reuse the publisher's DOI — do not mint a second Crossref DOI. Store Amoud's identifier as the ARK instead. The pipeline's collision check matters here: because the DOI suffix equals the ARK suffix, a collision would cross-overwrite Crossref records.
DOIs are permanent — guard test items
A DOI registered with Crossref is meant to last forever. When capturing screenshots or running a dry run that would approve/import a test item, pause the cron first and delete the test item before re-enabling. The ARK is local; the DOI is the irreversible one.
Adding an item that already has a DOI (no new mint)¶
For a paper already published elsewhere, you want to keep its existing DOI and stop the
pipeline minting a second one. The minting cron only acts on items that are archived, have an
ARK, and have no dc.identifier.doi. So the rule is simple:
Record the publisher's DOI in the
dc.identifier.doifield before the item is approved (or before the next 10-minute poll after it's archived). The pipeline sees a DOI is already present and skips minting — the publisher's DOI stays as the item's cited identifier.
Where to put it, depending on how the item arrives:
| Route | How |
|---|---|
| At deposit (web form) | The depositor selects Identifiers → DOI and enters the value — this writes dc.identifier.doi. The reviewer just confirms it's present before approving. |
| Single item, in review | If the depositor didn't add it, the RIC/admin opens the item (or the workflow task) → Edit → Metadata → add dc.identifier.doi = the publisher DOI (e.g. 10.1109/XYZ.2024.12345), then approve. |
| Bulk import (SAF) | Include <dcvalue element="identifier" qualifier="doi">10.1109/…</dcvalue> in each item's dublin_core.xml. See Bulk import (SAF). |
| CSV metadata import | Fill the dc.identifier.doi column for those rows. |
Use dc.identifier.doi, not local.external.doi, to stop minting
There is also a local.external.doi field meant for recording an external DOI for
provenance — but the current pipeline only checks dc.identifier.doi when deciding
whether to mint. To actually suppress minting, the DOI must be in dc.identifier.doi.
(Populate local.external.doi as well if you want the provenance record.)
Check an item's identifiers¶
Open any published item — the DOI leads as the cited identifier, with the ARK shown as the fallback line.
