DOI tombstone

DOI tombstoning is the recommended pattern when a publisher or repository must remove the underlying content but cannot ethically delete the citation history. DataCite supports an explicit ‘withdrawn’ state; Crossref relies on publisher tombstone landing pages plus the ‘is-retracted-by’ relationship in metadata. The DOI itself stays resolvable: a citation that was correct at the time of publication remains a resolvable reference, with the tombstone explaining the change of state.

Retraction vs. withdrawal

The two are related but distinct states a tombstone can describe. Retraction applies mainly to published literature and follows publisher/COPE retraction-notice conventions — the article record stays, marked as retracted, with a linked retraction notice explaining why. Withdrawal is the broader DataCite term, more commonly used for datasets and software, covering cases from legal takedown to a mistaken duplicate deposit, without necessarily implying the same editorial-integrity process a journal retraction does.

What a well-formed tombstone page typically shows

A properly built tombstone preserves the original bibliographic metadata (title, creators, original publication/deposit date) so the record remains citable and identifiable, states clearly and prominently that the resource has been withdrawn or retracted, gives a reason where one can be disclosed, and links to any replacement or successor version and to the retraction/withdrawal notice itself if one was separately issued.

What this is not

A DOI tombstone is not the same as a dataset landing page in its normal state — it is what that landing page becomes after withdrawal — and it is not full removal of the identifier from the resolution system, which both DataCite and Crossref guidance actively discourage because it breaks the persistence guarantee that makes the identifier trustworthy to cite in the first place.

References

• DataCite, ‘Best Practice — Update Metadata for Withdrawn DOIs’ (support.datacite.org).

Who is responsible for updating the record

For a published article, the retraction notice and the tombstone landing page are the publisher’s responsibility — the publisher issues the retraction notice per COPE guidance and updates its own metadata feed to Crossref, which then propagates the ‘is-retracted-by’ relationship. For a dataset or software deposit, the responsibility sits with whichever organization actually registered the DOI: the depositing repository, acting through its own DataCite registration agent account. A researcher or a sponsored-programs office cannot update DataCite metadata directly for a repository they don’t administer — the request has to go to the repository’s own data curator or DOI administrator, who is the only party with write access to that specific DOI’s metadata record.

What a research-administration or library office should check

Before relying on a tombstoned record in a progress report, a data management plan compliance check, or a citation audit, confirm three things: that the tombstone state is the correct one for the situation (retraction for published literature following an editorial-integrity process, versus withdrawal for a dataset or software issue that may not involve misconduct at all), that the original bibliographic metadata is still intact so the record remains identifiable and citable, and that any successor or replacement version is actually linked from the tombstone page rather than existing only in a separate announcement. An institution citing its own withdrawn dataset in a funder report should point to the tombstone’s stated reason, not describe the withdrawal in different terms than the tombstone itself uses.

Checking this against the current guidance

Whether a tombstone page has to state a reason, and in how much detail, depends on which registration agency’s policy and which underlying legal or ethical basis triggered the withdrawal. The answer depends on which registration agency and withdrawal basis you are working to, and the page above states the general rule.

Ask CASRAI: If our repository has to withdraw a dataset because it was deposited using someone else’s identifiable data without consent, does DataCite’s ‘withdrawn’ tombstone state require us to publicly disclose the reason, or can the tombstone page state only that the record was withdrawn?

It searches CASRAI’s indexed corpus of research-administration guidance and cites the passage behind each claim, so you can open the source and check it rather than take its word — and it says so when the corpus does not cover something instead of guessing. Two questions a day are free while you are signed out, no account and no card. Everything CASRAI publishes stays free to read.

Frequently asked questions

Can a DOI be deleted once it’s been tombstoned?

No. Both DataCite and Crossref guidance actively discourage deleting a DOI outright, because doing so breaks the persistence guarantee that makes any DOI trustworthy to cite. A tombstone — a landing page explaining the withdrawal while the identifier keeps resolving — is the standard alternative to deletion, not a step toward it.

Who updates a DOI’s metadata to reflect a retraction or withdrawal?

The organization that registered the DOI in the first place: the publisher for a journal article’s Crossref record, or the depositing repository’s own DOI administrator for a DataCite-registered dataset or software record. Neither a researcher nor an outside institution can push that update directly.

Does a tombstoned DOI still resolve to a working page?

Yes. That is the point of tombstoning rather than deleting — the DOI continues to resolve, but to a page that discloses the withdrawn or retracted status instead of the original content, so a citation made before the change remains a traceable, resolvable reference.

Is withdrawing a dataset the same process as retracting a journal article?

They’re related but not identical. Retraction follows publisher and COPE conventions built around editorial integrity in published literature. Withdrawal is DataCite’s broader term, more commonly used for datasets and software, and can cover situations — a legal takedown, a mistaken duplicate deposit — that don’t necessarily involve the same editorial-integrity process a journal retraction implies.