CASRAI Dictionary

Tag: RAiD

  • Project IDs in 2026: RAiD adoption update

    The Research Activity Identifier (RAiD) crossed several adoption thresholds in 2024-2025. ISO 23527:2022 standardisation completed; the Australian Research Data Commons reached operational scale; UKRI integrated RAiD into its funding workflow; the EU’s HORIZON identifier work began aligning with RAiD; the ARDC-led international RAiD Steering Group brought together national service providers from Australia, New Zealand, UK, Canada, and several EU member states. The May 2026 picture is meaningfully different from the May 2025 picture. This post is an adoption update.

    Where RAiD is now

    RAiD is operational at substantial scale in Australia, where the ARDC operates the national RAiD service and integration with the Australian Research Council and the National Health and Medical Research Council has matured. Every ARC and NHMRC grant from 2024 onward has a RAiD; the integration is a routine compliance item.

    RAiD is operational in New Zealand via a national service implementation aligned with the ARDC model.

    RAiD is operational in the UK via a UKRI-operated service, with integration into the Je-S successor (the UKRI Funding Service that launched in 2023). UKRI grants from 2024 onward have RAiDs; backfilling of historical grants is in progress.

    RAiD is in pilot in Canada via a CRDCN-led initiative, with the Tri-Agencies (CIHR, NSERC, SSHRC) participating in design.

    RAiD has affiliated national service providers in the Netherlands, Germany, and Finland; full EU integration is in development through the EOSC Federation work.

    RAiD is not yet operational at scale in the US. NIH’s evolving project-identifier work overlaps with but is not identical to RAiD; harmonisation discussions are ongoing.

    What RAiD actually carries

    A RAiD record carries: the project’s name and description; its participants with ORCID iDs; its institutional affiliations with ROR IDs; its funding sources with Funder Registry or ROR identifiers and grant identifiers; its outputs with DOIs and other PIDs; its temporal span; its status. The record is mutable: as the project evolves, the RAiD record is updated to reflect new participants, new outputs, new affiliations.

    The mutability is the design choice that distinguishes RAiD from a per-event identifier like a DOI. A project is a living entity for years; its identifier needs to grow with it. The RAiD service architecture supports this via versioning: each update produces a new version of the RAiD record, with the old versions preserved as historical states.

    The interlock with other PIDs

    RAiD’s value is largely in the interlock layer. A RAiD record references the ORCID iDs of its participants; ORCID 4.0 carries the RAiDs of its researcher’s projects. A RAiD references the DOIs of its outputs; Crossref and DataCite metadata reference the RAiD via the relationship blocks. A RAiD references the Funder Registry IDs of its funders and the grant DOIs (where they exist) of its grants; the Crossref Grant Linking System grants reference the RAiD via the contributes-to relationship.

    The result is a structured graph: from a RAiD, an integrator can traverse to participants (ORCID), institutions (ROR), funders (Funder Registry/ROR), grants (grant DOIs), and outputs (DOIs). The graph is queryable. The OpenAIRE Graph already operationalises this for European projects; the CASRAI persistent identifiers domain tracks the broader integration.

    What’s working well

    Three operational patterns deserve flagging.

    First, funder-issued RAiDs. The pattern of the funder issuing the RAiD on award and the awardee inheriting it has worked well. The funder has the structured grant data; the awardee has the operational knowledge of the project. The funder issues the RAiD with the structured data they have; the awardee updates it as the project evolves. This minimises the burden on researchers and ensures RAiD coverage is complete for funded work.

    Second, institutional-CRIS integration. CRIS systems that ingest RAiDs from their researchers’ projects and propagate them to outputs as a metadata field have closed the project-to-output linkage that previously required string-matching grant numbers. The integration is straightforward; the value compounds over time as the historical record accumulates.

    Third, cross-funder collaboration. A project with multiple funders (typical in large clinical trials and EU consortia) can have a single RAiD referencing all the funders’ grants. This addresses a longstanding accounting friction where multi-funder projects appeared as multiple disconnected projects in funder reporting systems.

    What’s not working yet

    Three issues remain open.

    First, retroactive RAiDs for historical projects. RAiD coverage is forward-looking from each jurisdiction’s start date. Historical projects (pre-2022 or so) do not have RAiDs; building the historical record is a substantial data-engineering effort that no jurisdiction has fully completed.

    Second, international coordination. Different jurisdictions have different RAiD service providers, different operational arrangements, and slightly different metadata profiles. The RAiD Steering Group is working on harmonisation but the work is incomplete. A project that crosses jurisdictions may have RAiDs from multiple providers, with the integration between them not yet seamless.

    Third, the unfunded-project case. RAiD was designed around funded projects, with the funder as the natural issuer. Unfunded research activity (self-funded, doctoral student projects without grants, community-research projects without traditional funders) does not have a clear RAiD-issuance path. The RAiD service architecture supports researcher-issued RAiDs; the institutional and funder workflows have not fully accommodated this case.

    What integrators should do

    For institutions running a CRIS, the priorities are: ingest RAiDs into the project record; propagate to outputs as metadata; reconcile with ORCID’s funding and contribution data; surface in research-administration reporting.

    For publishers, the priority is to accept RAiDs in submission systems as a funding-reference option alongside Funder Registry entries and grant DOIs, and to deposit RAiDs to Crossref via the relationships block. Several publishers have done this; broader adoption through 2026 would be welcome.

    For funders that have not yet issued RAiDs, the priority is to evaluate the operational integration. ARDC’s documentation and the UKRI implementation are useful reference points. The integration is non-trivial but not large; institutions that have done it report it pays back within 18 months in reduced cross-system reconciliation effort.

    The broader pattern

    RAiD adoption is the latest instance of the persistent-identifier pattern: a structured identifier for a class of research entities, with an operational service to mint and resolve them, with metadata that interlocks with other PIDs, with adoption that takes years to reach scale but compounds in value as it does. ORCID took a decade to reach saturation; ROR took five years to reach the equivalent in its space; RAiD is plausibly on a five-to-seven-year trajectory to comparable coverage.

    For the CASRAI community, the practical posture in 2026 is to incorporate RAiD into integration designs from the outset, to track adoption by jurisdiction, and to advocate for adoption where the operational case is strong. The PID quartet of ORCID-ROR-RAiD-DOI is increasingly the foundation on which research-information integration is built; the more complete that foundation, the more useful the integration layer becomes.

    Related dictionary entries

  • Persistent identifiers in 2026: ORCID + ROR + RAiD + DOI

    By 2026 the persistent-identifier (PID) layer of scholarly infrastructure has stabilised into a quartet: ORCID for people, ROR for organisations, RAiD for projects, and DOI for almost everything else (articles, datasets, software, instruments, samples, preregistrations). Each is operationally distinct, each has its own governance, and the seams between them are where most metadata loss still happens. This post is a tour of the state in early 2026, the integrations that work well, and the crosswalk gaps that institutions and publishers are still grinding through.

    ORCID at 2 million+ active iDs and counting

    The Open Researcher and Contributor iD is by some distance the most successful PID for people. As of 2026, ORCID reports over 21 million registered iDs with active use across publishing, funding, and institutional workflows. The 2024 integration of CRediT at the ORCID-record level was the missing piece that closed the loop: a contributor’s roles on a specific work can now be carried persistently on their ORCID record, not just in the publisher’s JATS.

    The CASRAI-stewarded contribution to ORCID’s data model also added affiliation history with PIDs (ROR for the organisation, RAiD for projects, DOI for grants), which means a complete ORCID record now resolves the four-way join. The ORCID federation page at CASRAI documents the per-country member organisations and the institutional integration patterns; the ORCID implementation page documents the technical integration via the public API and the member API.

    What’s still hard with ORCID in 2026

    Coverage is uneven by discipline. Life sciences and physics push close to saturation; humanities, education, and applied fields still have large populations who have not registered. Coverage is also uneven by career stage: PIs are nearly universal, postdocs and senior researchers have high coverage, graduate students and undergraduate contributors are sparse. The policy question of whether to require ORCID at submission, mandate it for funding eligibility, or leave it voluntary remains contested; the major medical journals (NEJM, JAMA, BMJ, Lancet) effectively require it for corresponding authors, the broader landscape does not.

    ROR: the organisational identifier that finally worked

    The Research Organization Registry launched in 2019 and crossed 100,000 active records around 2023. By 2026 ROR is the default organisational PID across Crossref, DataCite, ORCID, and most institutional CRIS systems. The decision to keep ROR governance light, the data open under CC0, and the IDs free at all volumes has been validated by adoption.

    ROR replaced a Babel of organisational identifiers (GRID, ISNI for orgs, ad-hoc Crossref Funder Registry entries, individual database keys at each tool). The integration pattern is clear: every author affiliation should resolve to a ROR ID, and that ID should travel through the metadata to Crossref, DataCite, ORCID, and the institutional repository. Most publishers now require or strongly prefer ROR at submission.

    ROR’s main 2025-2026 work has been on hierarchies: capturing the parent/child relationships between research institutions, hospitals, university systems, and consortia in a queryable way. A hospital with an academic affiliation needs both identifiers; a multi-campus university needs the campus-level resolution; an INSERM unit needs both the unit ROR and the parent INSERM ROR.

    RAiD: the project-level PID

    The Research Activity Identifier is the newest of the quartet and is filling a real gap. A project (a grant, a clinical trial, a multi-institution collaboration, a piece of fieldwork) was for years the orphan of the PID world: it had no canonical identifier, so its outputs (papers, datasets, software, training of students) could not be reliably linked back to it. RAiD, now an ISO standard (ISO 23527:2022) and operated as an open infrastructure with multiple national service providers, fills the gap.

    The RAiD model is straightforward: a RAiD record names the project, lists its participants (with ORCID iDs), its institutions (with ROR IDs), its outputs (with DOIs and other PIDs), its funders (with ROR or Funder Registry), its dates, and its status. A funder issues or registers a RAiD on award; the awardees update it as the project evolves; the outputs reference it.

    In 2026 RAiD adoption is strongest in Australia (where the ARDC operates a national RAiD service), New Zealand, the UK (where UKRI has integrated RAiD into its funding workflow), and parts of the EU. North American uptake has been slower; NIH’s evolving project-identifier approach overlaps with but is not identical to RAiD, and the harmonisation is still in negotiation.

    DOIs across artefact types

    The Digital Object Identifier is the workhorse. The interesting story in 2026 is not DOIs for journal articles (a settled problem) but DOIs for everything else.

    • Data. DataCite issues DOIs for datasets; coverage is high in well-funded disciplines (biology, astronomy, climate, social sciences via ICPSR), lower in others. The FAIR-data push has pulled coverage up.
    • Software. Software DOIs via Zenodo and via journal-specific archives (e.g., Software Impacts, JOSS) are now standard practice. Citation of software with DOIs is endorsed by the FAIR4RS principles.
    • Preprints. Every major preprint server issues DOIs; the Crossref preprint relationship metadata links the preprint DOI to the eventual journal-article DOI.
    • Preregistrations. OSF and AsPredicted issue preregistration DOIs.
    • Samples. IGSN (International Generic Sample Number) is a specialised PID for physical samples, increasingly issued as a DOI under the DataCite umbrella.
    • Instruments. The PIDINST initiative is rolling out DOIs for major research instruments, with full metadata about specifications and operators.

    The crosswalk layer

    The most underrated work in the PID ecosystem is the crosswalk layer: the mappings between identifier systems that make the quartet actually function as a graph. Crossref’s references and relations blocks link DOIs to other DOIs and to other PIDs. DataCite’s relatedIdentifier field plays the same role for datasets. ORCID’s work entries carry DOIs and increasingly RAiDs. ROR records carry relationships to other organisations and to Funder Registry entries.

    Where crosswalks fail is at the institutional repository boundary. A paper deposited in a university IR may have a DOI, but the IR record’s author affiliation may not resolve to a ROR ID; the project funding may be in a free-text field rather than a Funder Registry ID; the dataset associated with the paper may have a DOI but no relation to the paper’s DOI declared. The result is a graph with broken edges, which then degrades discovery downstream.

    The work to fix this in 2026 is mostly unglamorous metadata QA at the repository and CRIS layer. Several institutional CRIS vendors have shipped “PID completeness” dashboards that flag records with missing or unresolvable identifiers. The OpenAIRE Graph project rolls up the global picture and is the most useful external check.

    What we expect to settle by 2027

    Three threads are in motion. First, contributor-affiliation provenance: an ORCID record’s affiliation history with PIDs at both ends will become the canonical record, replacing the per-publisher author-affiliation strings that journals still maintain separately. Second, funder-PID standardisation: the Crossref Funder Registry and ROR are converging, with funders that are also research organisations getting unified records. Third, project-PID interop: RAiD, NIH project IDs, and the EU’s HORIZON identifiers are being mapped to allow a single project to be tracked across funder boundaries.

    For institutions setting strategy now, the practical priorities are: require ORCID at hire and on every publication; map every internal organisation to ROR; integrate RAiD into the funding-receipt workflow if you have it; and run quarterly QA against your CRIS for missing PIDs. The CRIS guidance at CASRAI walks through the integration patterns by vendor.

    Related dictionary entries

    References

    Meadows et al., Persistent Identifiers: The Building Blocks of the Research Information Infrastructure (Information Services and Use, 2019). Cousijn et al., A data citation roadmap for scholarly data repositories (Scientific Data, 2019). FAIR4RS Working Group, FAIR Principles for Research Software (RDA, 2022). ARDC documentation on RAiD operational service. ROR governance documentation and CC0 data dumps.

  • Crossref’s grant-linking initiative and CRediT: a 2025 status

    Crossref’s Grant Linking System (GLS), in development since 2019 and in steady production since 2022, has quietly become one of the most useful bits of plumbing in scholarly metadata. Its 2025 expansion — covering more funders, more grant metadata, and tighter integration with Crossref’s content-registration deposit schema — is worth a closer look, particularly for anyone integrating CRediT contributorship with funding attribution. This post walks through what GLS does, what changed in 2025, and how a CRediT integrator should consume the data.

    What GLS is, briefly

    A grant, as a thing in the world, has a funder (an organisation that paid), one or more awardees (people and institutions), a title, a project description, an amount, a duration, and a set of outputs (papers, datasets, software, other artefacts) that the grant produced. Pre-GLS, each piece sat somewhere different. The funder lived in the Funder Registry (a Crossref-maintained list of funder organisations). The grant number was a free-text string in publisher metadata. The outputs were registered with DOIs at Crossref but without structured links back to the grant. The result was that the graph from funder through grant to output existed only in fragments.

    GLS provides the missing middle layer. A funder registers grants with Crossref via a dedicated deposit schema; each grant gets a DOI; the grant DOI carries structured metadata about the funder, the project, the awardees (with ORCID iDs where available), and the institutions (with ROR IDs). Publishers and other depositors then reference the grant DOI from the output’s metadata, closing the loop.

    2025 expansion: more funders, more metadata

    The major story of 2025 was funder participation. Through 2024 the GLS depositors were a small set of early adopters (Wellcome, the Templeton Foundation, ANR, a handful of others). 2025 added the major UK research councils (UKRI’s component councils now register grants via GLS), several EU H2020 and Horizon Europe streams (via OpenAIRE-mediated deposit), the Australian Research Council, and — significant for the US ecosystem — initial NSF and NIH pilots. NIH’s pilot is small (a few thousand R01 grants), but it signals direction.

    The metadata expansion was equally important. GLS 2025 added structured fields for: project abstract (free text but indexed), discipline classification (using Crossref-curated CODE FOR codes and OECD FoS), expected outputs, ethics-board identifiers, and — the field most relevant to CRediT integrators — a participants structure that names each grant participant with an ORCID iD and a role from a controlled vocabulary (principal investigator, co-investigator, collaborator, named researcher, fellow, named staff). This is not CRediT, but it interlocks with CRediT cleanly.

    The CRediT-GLS interlock

    Here is the integration pattern that is now possible. A grant is registered with GLS, getting a DOI and a structured participant list. A paper acknowledges the grant by including the grant DOI in its Crossref deposit. The paper’s JATS carries a CRediT contributor statement, which is also deposited to Crossref via the relationships block. ORCID consumes both deposits via the public API and can now answer: this researcher contributed to this paper in these CRediT roles; the paper acknowledges this grant; this researcher is on the grant participant list in this grant role.

    The query is structured and unambiguous. Pre-2025, it required string matching grant numbers and best-effort author-name disambiguation. Post-2025, the entire chain runs on PIDs. The CRediT adoption ledger at CASRAI tracks which publishers deposit CRediT to Crossref in the form that makes this work, and which still drop the qualifiers at the deposit step.

    What integrators need to do

    For publishers depositing content with Crossref, the 2025 GLS recommendations are: include grant DOIs in the funding section of every deposit where a grant is acknowledged; resolve and validate the grant DOI before deposit; carry CRediT roles with the degree-of-contribution qualifier in the contributor section. Crossref’s submission schema 5.4 supports all of this; older schema versions do not, and a number of publishers are still on 4.x.

    For institutional CRIS systems, the recommendation is to ingest grant DOIs into the funding record alongside the internal grant number, and to use the grant DOI as the join key when reconciling CRIS funding records against ORCID’s funding entries and Crossref’s content metadata. The CASRAI CRIS integration guide has been updated with the GLS ingestion patterns by major CRIS vendor.

    For funders not yet depositing to GLS, the question is what to do about historical grants. Crossref’s recommendation is to deposit prospectively (new awards from a chosen start date) and backfill historical grants over time. The funders that have done well at GLS uptake budgeted a small data-engineering effort over 6-12 months to backfill 5-10 years of historical grants from internal records.

    The RAiD-Crossref-GLS triangle

    An open question for 2026 is the relationship between GLS and RAiD. Both can identify a research project; both can carry participant, institution, funding, and output metadata; both have ISO-standard or de-facto-standard status. The honest answer is that they overlap meaningfully but serve different communities and emphases.

    GLS is funder-centric: a grant is the unit; the funder registers it; outputs reference it. RAiD is project-centric: a project can span multiple grants, multiple funders, multiple institutions, with the project itself the persistent unit. For a single-funder, single-project grant they are functionally identical. For a multi-funder collaboration (typical in clinical trials, large astronomy or particle physics projects, EU consortia), RAiD captures the project shape; the individual grants funding it would each be GLS-registered and the RAiD would reference them.

    The Crossref-DataCite-ARDC working group has begun work on a formal crosswalk that lets a GLS grant DOI declare a RAiD that it contributes to, and vice versa. This will not collapse the two but will let consumers traverse the graph in either direction.

    Consuming the data

    The Crossref REST API exposes GLS grants under /works with a type filter of grant; the relationship from a paper to its grant is in the paper’s relation block with relationship type is-funded-by. For ORCID-aware consumers, the ORCID 4.0 funding resource now carries the grant DOI as a primary identifier, with the Funder Registry entry as the funder.

    OpenAIRE consumes GLS deposits and exposes the resulting graph in its OpenAIRE Graph, which is the easiest single endpoint to query for the full funder-grant-output structure. For institutional consumers without the bandwidth to consume Crossref directly, OpenAIRE Graph is the recommended starting point.

    What’s still rough

    Two known limitations. First, the GLS participants structure does not yet carry CRediT roles directly; it carries grant participation roles, which are a coarser categorisation. This is by design — grant participation is not authorship — but it means that the question “which CRediT role did this person play on this grant” can only be answered indirectly, by intersecting grant participation with CRediT roles on the grant’s outputs. We expect this to be cleaned up in a future GLS schema revision.

    Second, historical-coverage gaps remain. Pre-2020 grants are almost entirely absent from GLS; 2020-2023 coverage is partial; 2024 onward is increasingly complete. Tools building on the GLS graph need to handle the missing-grant case gracefully.

    Related reading

  • ORCID 4.0: the IDR roadmap and what it means for CASRAI integrations

    ORCID’s Integration and Data Roadmap (IDR) work, which culminated in late 2025 with the 4.0 release of the public and member APIs, is the most consequential PID infrastructure change of the year for anyone who cares about the contributor-affiliation-funding crosswalk. The headline is technical: a new contributions resource that supersedes the old works and employment pairing for representing what a researcher did, where, on whose money, and with whom. The implications reach into nearly every persistent-identifier integration CASRAI tracks.

    What 4.0 actually changes

    The pre-4.0 ORCID record was a federation of resource types: works (with DOIs), employment (with ROR organisation IDs), education, funding (with grant IDs and Funder Registry entries), peer reviews, and the like. Each was useful in isolation. None of them carried the relations between them in a structured form. If a researcher’s ORCID record listed a paper, an employment at the institution that hosted the work, and a grant that funded the work, those three facts sat in separate resources with no machine-readable link.

    4.0 introduces a top-level contribution entity that binds these. A contribution carries: a primary artefact (DOI, software identifier, dataset identifier, or RAiD), a set of CRediT roles with the degree-of-contribution qualifier, an affiliation in force at the time of the contribution (with ROR), funding in force at the time (with Funder Registry or ROR for the funder, plus the grant identifier and ideally a RAiD), and a temporal span. The relationships are explicit and queryable. A consuming system can ask: what did this researcher contribute, at this affiliation, under this grant, on this date? — and get an answer without inference.

    The CRediT-at-record-level integration matures

    The 2024 work to allow CRediT roles to live on an ORCID record (not just in publisher JATS) was the precursor to 4.0. The integration shipped, was widely adopted, and exposed two limitations that 4.0 closes. First, role assignments lived inside the work resource, making it awkward to express a Conceptualization role spanning several papers and datasets. Second, the qualifier was carried only at per-work granularity. 4.0 lets a CRediT role attach to a contribution that groups multiple artefacts, with the qualifier traveling with the contribution.

    Practical example: a researcher who is Lead for Conceptualization across a clinical trial’s primary paper, protocol paper, registered data, and statistical analysis plan should be representable that way. Pre-4.0, the assertion had to be repeated four times; post-4.0, it lives on the contribution entity. See the ORCID implementation guide for the API patterns.

    RAiD becomes a first-class citizen

    One of the unsung wins in 4.0 is the elevation of RAiD to a first-class identifier alongside DOI. Pre-4.0, RAiD could be carried in an ORCID funding resource as an external identifier, but the schema treated it as a second-tier metadata field. 4.0 adds RAiD to the primary identifier set for both contributions and funding, with the same validation and resolution support as DOI.

    This matters because RAiD is increasingly the canonical project-level identifier, and ORCID is increasingly the canonical person-level record. The interlock — researcher X contributed to project RAiD Y, which produced papers A, B, C — is now a structured query rather than a string-match exercise.

    Affiliation history with PIDs at both ends

    The 4.0 employment and affiliation model has been quietly tightened. Every affiliation now requires a ROR organisational ID at registration; legacy string-only affiliations are preserved but flagged. The optional department field accepts a ROR sub-organisation ID where one exists (the ROR hierarchy work has caught up to make this practical), or a free-text department name as a fallback. The result is that affiliation history on an ORCID record is now reliably machine-readable at the ROR ID level.

    For institutions running a CRIS, this closes a longstanding crosswalk gap. CRIS-to-ORCID deposit can now write structured affiliations that ORCID-to-CRIS retrieval can read back without ambiguity. The CASRAI CRIS integration guide has been updated with the 4.0 deposit patterns.

    What CASRAI integrations need to do

    Three things, in priority order.

    1. Update CRediT JATS round-trips. Publishers depositing structured CRediT to ORCID via the member API should switch to the contribution resource for new deposits. Legacy works-with-roles deposits will continue to be accepted through 2026 but will be migrated server-side in 2027. The CASRAI CRediT JATS integration patterns now include both the legacy and the 4.0 deposit forms; new integrators should implement only the 4.0 form.
    2. Validate ROR IDs at affiliation deposit. A CRIS or publisher pushing affiliation data to ORCID should resolve and validate the ROR ID before deposit. The 4.0 API will reject obviously bad ROR IDs at the schema layer but will accept ROR IDs that resolve to deprecated or merged records. A pre-deposit validation pass against the ROR public API catches the common error cases.
    3. Test the funding-to-contribution link. If your integration writes funding entries, link them explicitly to the contributions they funded via the new funded_by relation on the contribution resource. This is the integration point that was missing pre-4.0 and that downstream consumers (funder dashboards, institutional reporting) most want to query.

    Backwards compatibility and the migration window

    ORCID’s commitment is that the 3.x APIs remain available through end-of-2027, with the 4.0 API the recommended target from now. The data model migration is largely automatic for existing records: pre-existing works with associated employment and funding are projected into the contribution model server-side. Consumers reading via the 4.0 API will see contribution entities even for data that was deposited in the 3.x form.

    The one wrinkle is CRediT role assignments that were deposited in 3.x without explicit qualifiers. These project into the contribution model with no qualifier set — a valid state, but less informative than it could be. Publishers should re-deposit historical CRediT data with qualifiers where they have them during 2026.

    What this enables downstream

    The most interesting consequence of 4.0 is the ability to ask compound questions across the PID graph. Which researchers, affiliated with which institutions, contributed in which CRediT roles, to outputs funded by which funders, on which projects? — that query reduces to a structured traversal across ORCID, ROR, Crossref/DataCite, and the Funder Registry, with RAiD optionally tying the project layer together. The OpenAIRE Graph already operationalises a version of this; 4.0 makes it cleaner.

    For institutions, the practical implication is that reporting against funder mandates becomes substantially less manual. For publishers, the JATS-to-ORCID deposit becomes more valuable because it now persists in a queryable graph. For funders, the funder-PID-to-output traceability that ORCID has long promised starts to deliver at scale.

    What’s still missing

    4.0 does not solve everything. The contributor-affiliation-funding triple is now structured; the contributor-contributor relationship (collaboration graphs, mentorship) is not. A relationships resource is in development but not in 4.0. CARE-aligned identifiers for Indigenous researchers are also still in design.

    CASRAI’s integration tracking will follow 4.0 through 2026. The persistent-identifiers domain is being updated to reflect the contribution model; the ORCID federation page tracks member implementation.

    Related dictionary entries