Minting Identifiers for a Legacy Repository Before the Domain Dies
A university repository with 22,000 records is migrating from a home-grown system to DSpace 7. Of these, 6,400 have no persistent identifier. DOIs were previously minted ad hoc by subject librarians through a Crossref member account held by the library, but 1,200 of those DOIs resolve to landing pages on the old domain, which will be decommissioned in nine months. Another 300 records are duplicates - the same paper entered twice with different metadata - and 900 are conference posters and research datasets. The institution plans to join DataCite. ORCID is not integrated and author names are inconsistent ("J. Smith", "Jane Smith", "Smith, J.A."). The national aggregator harvests via OAI-PMH and rejects any record without a DOI. The library has 1.5 FTE for the project and a nine-month deadline.
1. Set out the identifier plan: which records get DOIs, through which registration agency, and what happens to the 1,200 legacy DOIs on the retiring domain.
Read the worked answer
Legacy DOIs are the emergency, not the backlog. A DOI is a promise of persistence; letting 1,200 resolve to a dead domain is the most damaging outcome available. Do not mint replacements - that creates duplicate identifiers for the same object. Instead update the URL in each DOI's metadata at Crossref (or via a batch update), point to the new landing pages, and keep a permanent redirect from the old domain to the new one after decommissioning. Do this first, with a full resolution test before the switch.
Agency split. Use Crossref for text outputs that have a DOI-worthy version of record: journal articles, conference papers, book chapters. Use DataCite for datasets, software and other non-text research outputs. Do not dual-mint. Posters are a judgement call: mint only if the repository will keep the file and landing page permanently and the item is citable; otherwise give a local handle.
The 6,400 without identifiers. Do not mint wholesale. Mint where the item is stable, in scope, and likely to be cited: theses, reports, datasets. Use local handles for ephemeral or low-value items. Prioritise records the national aggregator will harvest, since aggregator inclusion is a concrete benefit and the DOI is a hard gate.
Sequencing with 1.5 FTE in nine months: legacy DOI repair and redirect; duplicate resolution; DataCite membership and a metadata profile; then batch minting by collection, starting with theses and datasets. Automate validation; reserve human review for exceptions.
2. How should the 300 duplicates and the 900 posters and datasets be handled before any identifier is minted?
Read the worked answer
Duplicates first - a DOI is effectively permanent. Minting an identifier onto a duplicate creates two citable objects for one work, splits citation counts, and is painful to unpick later. Run deterministic matching on normalised title, year, and first author, then fuzzy matching on abstract similarity, and cluster candidates. Expect the automated pass to be noisy; a person must confirm every merge. Merge by keeping one canonical record, transferring files and metadata, and leaving a tombstone record that redirects rather than silently deleting, so existing links still resolve. Where a duplicate already carries a DOI, keep that DOI on the canonical record and retire the other's landing page with a redirect. Log every decision with a reason, because authors will challenge them.
The 900 posters and datasets. These are not one category. Separate them by format and by intended persistence. Datasets with a landing page, documentation and a stable file should go to DataCite with rich metadata (creator ORCIDs, affiliation ROR, licence, related publication). Posters and conference ephemera should generally receive local handles unless the repository commits to permanent stewardship; a DOI implies a commitment the library may not want to make for a file it might withdraw.
Rule to apply: mint only where the object is stable, described well enough to be found, and will remain accessible. Apply this rule before the aggregator deadline rather than letting the harvest requirement dictate identifier policy for the whole repository.
3. Design the author-identity approach: ORCID integration, name reconciliation, and affiliation metadata, given the inconsistent names and no current integration.
Read the worked answer
ORCID is consent-based; do not auto-assign. Auto-matching names to ORCID iDs produces confident errors that are hard to detect later. Instead:
- Add ORCID capture to the deposit and thesis submission forms, with an OAuth authentication step so the iD is verified rather than typed.
- Run a bulk enrichment pass only on high-confidence matches (exact name plus affiliation plus publication overlap), and route everything else to a review queue or to an author email campaign.
- For legacy records where no iD can be verified, store the name variants in a structured field rather than forcing a single string, and mark the record as unlinked.
Name reconciliation. Build a local authority file of author entities with all observed variants, and link records to the authority record, not to a text string. This makes future merging tractable and is reversible.
Affiliations. Record institutional affiliation using ROR identifiers rather than free text; this disambiguates the university from similarly named institutions and supports the aggregator's metadata requirements. Store affiliation as it was at the time of publication, not the author's current affiliation.
Resourcing. With 1.5 FTE, do not attempt to clean 22,000 records. Fix the workflow so new deposits are correct, enrich a targeted subset (theses, highly cited authors, records feeding the aggregator), and publish a short guidance page for authors explaining why the iD matters and how to claim records.