datacite-metadata-current (TN105)#

Group	Default severity
Metadata	Warning

When a technote is released, a DOI is minted for it and the technote’s metadata is registered with DataCite. That registered record is what the rest of the scholarly world reads: it is what a reference manager imports, what an indexer harvests, and what https://doi.org/doi ultimately describes. technote.toml can go on changing after that — a title is reworded, an author joins — and the registered record does not follow by itself.

This rule reads the metadata registered for the technote’s [technote] doi from DataCite’s public API and reports when the registered title or author list no longer matches technote.toml, or when the two sides register the same author under conflicting ORCIDs. A finding raised for one of those reasons also says when the registered record was issued, if the technote declares no date_updated — not as a problem, but because that is the field which pins the citation to a fixed date, and the author is already reading the record.

Note

TN105 uses the network, and so do the author checks (R101–R103), but only TN105 degrades to silence. An author database that cannot be reached is reported as R103; a DataCite that cannot be reached is reported as nothing at all. See When DataCite is not reachable for every situation this rule stays quiet in.

Example of a failing technote#

The technote is renamed in technote.toml after its DOI was registered:

technote.toml#

[technote]
id = "SQR-000"
title = "The technote, revised"
doi = "10.71929/rubin/2570308"

[TN105] The metadata registered for DOI 10.71929/rubin/2570308 differs from the technote: the registered title is 'The technote', but the technote is titled 'The technote, revised'. Compare with the registered metadata at https://api.datacite.org/dois/10.71929/rubin/2570308.

An author who joined the technote after its DOI was registered reads much the same way, naming the people the two sides do not agree on:

[TN105] The metadata registered for DOI 10.71929/rubin/2570308 differs from the technote: technote.toml declares authors the record does not register ('AlSayyad, Yusra'). Compare with the registered metadata at https://api.datacite.org/dois/10.71929/rubin/2570308.

An author registered under somebody else’s ORCID reads as the conflict it is, naming both identifiers:

[TN105] The metadata registered for DOI 10.71929/rubin/2570308 differs from the technote: the ORCID registered for 'Sick, Jonathan' is https://orcid.org/0000-0002-1793-3689, but technote.toml declares https://orcid.org/0000-0003-3001-676X. Compare with the registered metadata at https://api.datacite.org/dois/10.71929/rubin/2570308.

Where the technote declares no date_updated, any of those findings closes with a sentence about the registered date. A record that registers a full date says the day:

[TN105] The metadata registered for DOI 10.5281/zenodo.51968 differs from the technote: the registered title is 'Smtn-005 V1.0 Cloud Statistics Via All-Sky Camera', but the technote is titled 'Cloud Statistics via All-Sky Camera For Rubin Observatory'; the record registers authors technote.toml does not declare ('Sick, Jonathan'). The registered record was issued on 2016-05-24. technote.toml declares no date_updated, so the technote is dated by its publishing commit; declare date_updated to pin the citation to a fixed date instead. Compare with the registered metadata at https://api.datacite.org/dois/10.5281/zenodo.51968.

A record that registers only a year — which is every Rubin-minted record — says the year:

[TN105] The metadata registered for DOI 10.71929/rubin/2570308 differs from the technote: technote.toml declares authors the record does not register ('AlSayyad, Yusra'). The registered record was issued in 2026. technote.toml declares no date_updated, so the technote is dated by its publishing commit; declare date_updated to pin the citation to a fixed date instead. Compare with the registered metadata at https://api.datacite.org/dois/10.71929/rubin/2570308.

The sentence is never a finding on its own: a technote that matches its registered record and declares no date_updated reports nothing at all.

The message names each field that differs and links to the record it compared against, so you can read exactly what is registered:

curl https://api.datacite.org/dois/10.71929/rubin/2570308

How to fix it#

Decide which side is right — the finding does not assume technote.toml is.

The technote changed. Release the technote again so that its DOI’s metadata is updated from the current technote.toml. Rubin’s technote CI registers metadata as part of a release, so publishing a new version brings the record back in step.
The registered record is right and :file:`technote.toml` drifted — a title that was edited in the wrong place, an author who was removed by accident, or a mistyped orcid. Correct technote.toml, and regenerate CITATION.cff (TN106) if the repository has one.
The technote declares no date_updated. Nothing is broken — the citation is dated by the commit the technote is published from. Declaring date_updated, using the date the finding reports, pins the citation to that day instead, so that a later typo fix does not re-date the work; regenerate CITATION.cff (TN106) if the repository has one, since that file is written only from a declared date.
The registered record is wrong and a release will not fix it. Ask in the #square-help Slack channel for the DataCite record to be corrected; DOI metadata is registered by Rubin’s services rather than from your working copy.
Nobody at Rubin can change the registered record. See When the registered record cannot be changed below.

This rule is a warning: it does not fail a lint run unless you pass --strict. That is deliberate — the registered metadata is not something a technote author can always change on their own, so the finding informs rather than blocks.

What is compared#

Only two fields are compared — the title and the authors — and tolerantly wherever tolerance can be afforded. A false positive here is worse than a miss: the rule warns about metadata you may not control directly, and a warning nobody can act on trains people to ignore the linter. The one exact comparison is between two ORCIDs, for the reason given below. The registered date the rule also reports is not a comparison at all; see The registered date, and the date the technote is cited by below.

Title: Compared ignoring case and whitespace, so The Technote and the technote agree.
Authors: Each author in technote.toml is paired with a creator registered for the DOI, and the authors left unpaired are reported — an author the record does not register, or a creator technote.toml does not declare. A pair the two sides make under conflicting ORCIDs is reported too. The order the two sides list people in is not compared, since a legitimate reordering is not drift.

The pairing goes in two passes.

ORCID first. Where both sides carry an ORCID — an author’s orcid in technote.toml, and an ORCID under the creator’s nameIdentifiers in the registered record — a matching ORCID pairs them and settles it. An ORCID is the stronger claim about who an author is than any spelling of their name, so a pair it settles is not compared on name at all: an author who has since changed how their name is written is not reported. Both sides are normalized first, so a bare 0000-0003-3001-676X and an https://orcid.org/0000-0003-3001-676X URL are the same identifier.

Then by name. Whoever is left over — an author with no ORCID, or one whose ORCID the record does not register — is paired by name:

Family names are compared after folding case, accents, and punctuation, so Ibáñez and Ibanez are the same family name.
Given names are compared tolerantly of initials, so a registered James F. matches a declared James and a registered R. Lynne matches a declared Lynne. A different name — John where technote.toml declares James — does not match.
A creator that registers no given name is compared on its one name alone. That covers an Organizational creator, and the Personal creator with only a familyName that Rubin’s minter registers a committee as. An absent given name is not drift.

A pair made by name where both sides carry an ORCID is a conflict. The ORCID pass has already searched every registered creator, so an author that reaches the name pass still carrying an ORCID has established that no creator registers that identifier — and the creator its name then matches necessarily registers a different one. The two sides agree about who the author is and disagree about which ORCID is theirs, which means one of the two identifiers belongs to somebody else. This is the one thing the rule compares exactly rather than tolerantly, precisely because the tolerance that keeps a reworded name quiet would hide it.

The comparison reads a creator’s decomposed givenName and familyName in preference to the formatted name the record also carries, because the formatted name is not always trustworthy: Rubin’s minter writes a literal null into it for a creator with no given name, as in "Rubin's Survey Cadence Optimization Committee, null". Comparing the decomposed parts also means a transposed given and family name is seen as drift rather than silently accepted.

A field only one side declares is skipped rather than reported. A technote.toml with no title, or a registered record that lists no creators, simply is not compared on that field.

Other metadata a DOI record carries — the publisher, the landing-page URL, affiliations — is not compared. Those fields are set by the minting service at release time and legitimately differ from what technote.toml says, so comparing them would produce findings nobody should act on. The registered date is read, but it is not compared either; the next section says why.

The registered date, and the date the technote is cited by#

A technote that declares [technote] date_updated is cited by that date. A technote that declares none is cited by the commit it is published from, by that commit’s UTC calendar day — its citation is dated either way; see Where the date comes from. So the registered date is not a gap to be closed, and TN105 never raises a finding about it. What it does is mention the registered date at the end of a finding that already exists, for the technote that declares no date_updated: the author is reading the record anyway, and date_updated is the field that pins the citation to one day rather than letting it follow the latest commit.

Which field the date comes from. The year comes from DataCite’s publicationYear. DataCite’s metadata schema makes it mandatory and defines it as the year the resource “was or will be made publicly available”, directing a registrant with no standard publication year to “use the date that would be preferred from a citation perspective” — it is the citation year, by definition. It is also the only date a Rubin-minted record carries.

A record may additionally list an entry in dates typed Issued, which DataCite defines as “the date that the resource is published or distributed”. That states the same publication to the day, so the sentence reports the day where one is registered. A DOI minted years ago by the Zenodo–GitHub release integration is the common case: such a record carries both a publicationYear of 2016 and an Issued date of 2016-05-24. A record that registers no full date says the year instead, rather than implying a January 1st nobody published on.

The DOI’s own registration date is deliberately not consulted. A DataCite record also carries created, registered, and updated attributes. Those are timestamps of the DOI record — when the DOI was minted and last touched — and say nothing about when the technote was published.

A date the technote does declare is never compared against the record. The rule says nothing about the date at all once one is declared, whether it falls before or after the registered date. Both directions are legitimate: a technote edited after its DOI was minted has a date_updated that postdates the record, and a DOI minted some time after the last edit has a registered date that postdates date_updated. Comparing them would produce a finding in both cases and be right in neither.

When the registered record cannot be changed#

Some technotes carry a DOI that Rubin did not mint and cannot re-register. A DOI created years ago by the Zenodo–GitHub release integration is the common case: Zenodo registered the metadata it derived from the GitHub release, which is why such a record often carries a machine-made title (Smtn-005 V1.0 Cloud Statistics Via All-Sky Camera) and a creator who was a repository contributor rather than an author of the document.

TN105 reports that drift correctly, and none of the fixes above reach it. A Rubin release only re-registers 10.71929/rubin DOIs, so publishing again changes nothing; editing technote.toml to match the registered record would make the technote itself wrong; and only the owner of the Zenodo deposit can edit that record. The warning is permanent, and it keeps --strict out of reach for the whole repository.

Switch the rule off for that technote, and say why:

technote.toml#

[technote.lint]
# Zenodo DOI minted in 2016; a Rubin release cannot update its metadata.
ignore = ["TN105"]

The rule then makes no DataCite request at all for this technote, and the lint summary names it as ignored rather than passing. See Ignoring a rule for the full behavior of the ignore list.

Ignore TN105 only when the registered record is genuinely beyond reach. A record that a release would fix, or one #square-help can correct, should be fixed: the rule exists because a stale DOI record is what the rest of the scholarly world reads.

When DataCite is not reachable#

The check is silent — no finding, and no complaint about the attempt — in every situation where it cannot reach a confident conclusion:

The technote declares no DOI. Most technotes have no DOI for most of their lives; there is nothing to cross-check.
The declared DOI is not a DOI. A value that is not a DOI is rejected when technote.toml is parsed, so it is TN001’s finding, and TN105 asks DataCite nothing.
DataCite answers 404. A DOI that has been reserved but not yet made findable looks exactly like this, and it is not a problem to report.
DataCite cannot be reached at all — no network, a DNS failure, a timeout, an outage, or a response that is not a DOI record.

So a technote author working offline, and a CI job running while DataCite is down, both get the same clean lint run they would get with the network up. The request uses a short timeout for the same reason: a DataCite that is not answering must not stall a lint run that is going to stay silent about it either way.