Research projects generate outputs — datasets, protocols, publications — that end up scattered across repositories, registries, and institutional systems. Keeping those connected to the project they belong to has always required manual effort, and manual effort is where adoption dies.

That's exactly the problem RAiD was designed to solve. The Research Activity Identifier is a persistent identifier (PID) for research projects. Think of it as an ORCID for your project: just as an ORCID aggregates a researcher's personal outputs and contributions, a RAiD record aggregates everything associated with a project — its contributors, funding, related publications, and datasets — into a single, resolvable, machine-readable record. Funders and research organisations increasingly recognise RAiD as essential infrastructure. But for RAiD to realise its value, researchers need to actually report to it. And that means meeting them where they work.

In close collaboration and with support from Matthias Liffers and the RAiD team at ARDC and the US RAiD Pilot, we've done exactly that and integrated RAiD support into the latest release of RSpace.

Integrating PIDs into research workflows

We've been on a deliberate journey to embed persistent identifiers in research workflows throughout RSpace. Users are identified by their ORCID. Institutional affiliations carry ROR identifiers. Physical samples are registered with IGSN. And now, research projects connect to RAiD.

Each of these isn't just a checkbox. The PIDs are carried forward in research data workflows facilitated by RSpace to automatically make research outputs findable, attributable, and reusable at scale.

We recently walked through this integration in more detail with the US RAiD Pilot community — the slides are available on Zenodo.

What the RAiD integration does

The RAiD integration in RSpace is built around a simple idea: when a researcher exports data to a repository, RSpace should handle the RAiD reporting automatically. No separate login to a RAiD portal. No copy-pasting identifiers. No extra steps.

Here's what happens in practice:

1. Connect. An RSpace administrator configures the RAiD service point for your institution. Researchers activate the RAiD integration and connect to the service point with a single authentication step.

2. Associate a project group to a RAiD. In any RSpace Project Group — a shared workspace where teams collaborate on research notebooks, protocols, and data — researchers can link a RAiD identifier. They search by title or RAiD ID and select the relevant record. From that point on, RSpace knows this project has a RAiD.

3. Export, and let RSpace do the rest. When researchers export data to a repository like Dataverse or Zenodo, they'll see a new option in the export dialog: "Report to RAiD record." If activtivated RSpace will:

• Embed the RAiD in the RO-Crate and manifest of the export package, so the connection travels with the data
• Deposit the data to the repository as usual
• Add the RAiD identifier to the repository metadata
• Report the resulting DOI back to the RAiD record as a research activity

The result: the RAiD record that stays current without the researchers having to maintain it manually.

Let us know what you think!

The RAiD integration released in RSpace 1.120 covers a core workflow: project association, data export, and automatic reporting. But we're already thinking about further workflows we could build into RSpace around RAiD.

A few questions we're genuinely curious about:

• What other workflows matter to you? Are there research activities, project types, or reporting scenarios we should prioritize?
• Should RSpace play a more active role in RAiD creation and curation? For example, creating a new RAiD record directly from within RSpace when a project group is set up — rather than requiring a RAiD to exist already.
• What would make RAiD adoption realistic for your institution or community?

We're actively developing this integration further, and the roadmap is shaped by conversations like these. If you have thoughts, we'd love to hear them — reach out at opensource@researchspace.com or join our next open-source office hour.

Up next

We're already looking at the next piece of the PID ecosystem: a persistent identifier for scientific instruments (PIDINST). More on that soon, but feel free to reach out to us if you have any thoughts or suggestions around instrument identifiers.

‍