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. It also reports a technote that declares no date_updated, since such a technote is cited without a date — and the registered record is where the missing date already is, so the finding quotes it back.

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 technote.toml: the registered title is 'The technote', but technote.toml declares '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 technote.toml: 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 technote.toml: 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.

A technote that declares no date_updated is told what date to declare, in the words the registered record supports. A record that states a full date quotes the line to write:

[TN105] The metadata registered for DOI 10.5281/zenodo.51968 differs from the technote: the registered record gives an issue date of 2016-05-24, but technote.toml declares no date_updated, so the technote is cited undated; set 'date_updated = 2016-05-24' to date the citation. Compare with the registered metadata at https://api.datacite.org/dois/10.5281/zenodo.51968.

A record that states only a year — which is every Rubin-minted record — names the year to look within instead:

[TN105] The metadata registered for DOI 10.71929/rubin/2570308 differs from the technote: the registered record gives a publication year of 2026, but technote.toml declares no date_updated, so the technote is cited undated; set date_updated to the date the technote was published in 2026 to date the citation. Compare with the registered metadata at https://api.datacite.org/dois/10.71929/rubin/2570308.

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. Declare one, using the date the finding quotes, and regenerate CITATION.cff (TN106) if the repository has one. This is the one part of the finding that is always yours to fix, and always worth fixing: an undated citation is wrong everywhere it is rendered.
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 date the rule also reports on is not a comparison at all; see 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 date the technote is cited by#

A technote’s citation is dated by [technote] date_updated, and only by it. A technote that declares none is cited undated — in its own rendered citation, in the CITATION.cff the repository generates, and in the metadata every harvester reads. That is a gap a technote author can always close, and the registered DOI record is exactly where the missing date already is, so TN105 reports it and quotes the date back.

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, and a full date is a value you can write straight into technote.toml, so the finding quotes it as the line to write. 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 names the year to look within instead, rather than inviting 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, so reading them would date a citation by an event in Rubin’s minting pipeline.

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.