Re-Curation
Re-curation means going back to published records to improve connectivity — adding ORCIDs, RORs, and related identifiers.
Learn more ↗
FAIR Principles
FAIR metadata is a continuum, not a checklist. The activity history here shows how repositories move along it over time.
Learn more ↗
Funder Metadata
Funder acronyms are not enough. Persistent identifiers like ROR make it possible to trace research outputs back to the agencies that funded them.
Learn more ↗
DataCite Provenance
Every DOI update since March 2019 is recorded by DataCite as a provenance event — this is what Re-Curation Watch visualizes.
Learn more ↗
MGC Mission
Better documentation leads to better data discovery, reuse, and research integrity.
Learn more ↗
Connectivity
Identifiers connect research. ORCIDs for people, RORs for organizations, DOIs for outputs — together they make the global research graph possible.
Learn more ↗
Completeness
Completeness here measures presence — the share of records that contain each concept — not whether the value is correct or rich.
Learn more ↗
FAIR use cases
The four FAIR use cases group concepts by purpose: Text for discovery, Identifiers, Connections, and Contacts.
Learn more ↗
Mandatory fields
DataCite requires a handful of fields (title, creator, publisher, type, year), so a few concepts sit near 100% by design — the interesting signal is everything else.
Learn more ↗
Total index
The FAIR Total is a concept-weighted average across the four FAIR use cases. Projects and Extras are scored separately and don’t affect it.
Learn more ↗
Sampling
For large repositories, a random sample of a few hundred records gives a representative completeness score in seconds.
Learn more ↗
Connectivity
Structured affiliations (ROR) and identifiers (ORCID, DOI) connect the research graph far better than plain names and titles.
Learn more ↗
Relations
relatedIdentifiers — Cites, IsPartOf, IsSupplementTo … — turn isolated records into a connected network. See the DataCite Relations use case.
Learn more ↗
In your browser
Every score is computed in your browser with the same jq queries Metadata Game Changers uses — nothing is uploaded or stored.
Learn more ↗
Retrieve ROR subset
To Retrieve records associated with an organization from a repository put quotes around the "ROR" in the query.
Learn more ↗
Connectivity
Connectivity measures whether the things in your metadata carry the identifiers that connect them — ORCIDs on people, RORs on organizations.
Learn more ↗
Distinct entities
The bars count distinct entities, not occurrences — a creator who appears in 50 records is one person to identify once.
Learn more ↗
Quick wins
Yellow segments are quick wins: an identifier already known for an entity that just needs to be copied to the records that are missing it — no lookup required.
Learn more ↗
ORCID
An ORCID on a creator or contributor links every one of their outputs across repositories — the single highest-leverage identifier to add.
Learn more ↗
ROR
ROR identifiers on affiliations disambiguate organizations far better than free-text names like “Univ. of Colorado”.
Learn more ↗
Duplicates
The same person or org shows up under many spellings. The potential-duplicates panel groups likely matches — even across creators and contributors.
Learn more ↗
Click a bar
Click any bar to list its distinct entities — quick wins first (a known identifier to copy to the records that are missing it), then the ones still missing an identifier.
Learn more ↗
In your browser
Everything is computed in your browser against live DataCite data — nothing is uploaded or stored.
Learn more ↗
Affiliation strategy
Each name is matched with ROR’s affiliation strategy — it tries substrings of your string against registered names and chooses a match only when it is confident.
Learn more ↗
Why the pace?
Each affiliation is a separate API request, paced to stay well inside ROR’s rate limit — results appear as they arrive, and you can Stop anytime and keep what’s done.
Learn more ↗
Colors
Green = chosen by the algorithm (trustworthy). Amber = a suggestion — best-score or keyword-search — verify by eye. Red = nothing usable.
Learn more ↗
QUERY fallback
Names the matcher can’t place are retried with ror.org’s keyword search; its top hit appears in amber with QUERY in the Match column.
Learn more ↗
“(Country)” names
Some registered names carry a suffix like “Metadata Game Changers (United States)” with no short alias — a ROR curation request fixes that for everyone.
Learn more ↗
Beyond affiliations
ROR absorbed the Open Funder Registry, so RORs identify funders and publishers too — not just author affiliations.
Learn more ↗
Candidates
Click an affiliation or its result count to see every candidate the API returned — scores, matching types, and which one was chosen.
Learn more ↗
In your browser
Matching runs in your browser against the public ROR API — nothing is uploaded or stored, and the CSV matches RORRetriever.py.
Learn more ↗
Curation Required
ROR searches do a great job in most cases, but sometimes manual curation is needed. Use the Valid checkboxes for results that are correct. They get saved as True in the csv datafile.
Learn more ↗
No Public Data?
Let your colleagues know — having an ORCID is wonderful, but making the data public is necessary to make it visible and findable.
Learn more ↗
The search
Each name is parsed into family and given names and searched in the public ORCID registry — the same search MGC’s getORCIDs.py uses.
Learn more ↗
Why the pace?
Every candidate iD is a separate record fetch (that’s where employment and journal come from), paced to respect ORCID’s public API — results appear as they arrive.
Learn more ↗
Pick one
Amber rows mean several people share the name — one row per candidate. Use the employment and journal columns to pick the right person.
Learn more ↗
Empty columns?
ORCID profile data appears only if the researcher made it public — an empty employment column doesn’t mean unemployed, just private or unfilled.
Learn more ↗
Common names
Max matches / name caps how many candidates are fetched — the Matches column still shows the true total, e.g. “first 5 of 137”.
Learn more ↗
Name forms
“First Last” and “Last, First” both work — suffixes (Jr, III) and nicknames are handled by the parser ported from getORCIDs.py.
Learn more ↗
Why ORCIDs?
An ORCID on a creator or contributor links every one of their outputs across repositories — the single highest-leverage identifier to add.
Learn more ↗
In your browser
Everything runs in your browser against the anonymous public ORCID API — no token, nothing uploaded or stored.
Learn more ↗
Curation Required
ORCID searches do a great job in most cases, but sometimes manual curation is needed. Use the Valid checkboxes for results that are correct. They get saved as True in the csv datafile.
Learn more ↗
Cohorts, not a time machine
Each year scores the records registered that year as they are today — a strong early year can mean good metadata then, or re-curation since. Compare with Re-Curation Watch to tell them apart.
Learn more ↗
Registered year
Registered is when DataCite first saw the DOI — assigned by the system, unlike publicationYear, which authors can backfill arbitrarily.
Learn more ↗
Thin years
Early years often have only a handful of records, so their percentages swing wildly — hollow points mark years with fewer than 10 records. Read trends from the solid ones.
Learn more ↗
Rising lines
A rising line means newer records are better documented — or older cohorts were never revisited. Falling lines are rarer and worth investigating: did a workflow change?
Learn more ↗
Focus with a query
The Query filter composes with each year — e.g. types.resourceTypeGeneral:Dataset tracks dataset metadata only, excluding text or software records.
Learn more ↗
In your browser
Every year is fetched from DataCite and scored in your browser with the same jq use-case queries as Metadata Completeness — nothing is uploaded or stored.
Learn more ↗
