Persistent identifier for the IDS Project Tracking pilot

[wpotrzebowski]

What do you need help with?

Is RAiD a feasible persistent identifier for the IDS Project Tracking pilot?
Follow-up question: How should we fulfill the requirements that are not covered by RAiD?

Context

This decision is needed to unblock the pilot’s backbone and integrations with identifiers called for in the Project Tracking charter and follow‑up deck.

The Project Tracking initiative will deliver a web‑based, minimal‑but‑extensible pilot for 2–4 units, with clear IDs, logging/audit, notifications, and role‑based access, and it explicitly plans to integrate with sample & project identifiers (examples mentioned include BioSamples for samples and RAiD for projects/activities).

The initial mock-ups (still work in progress) for researchers and users are shown below:

What you've considered (optional)

Based on early requirement review, RAiD will not satisfy 100% of use cases (e.g., internal or sensitive workflows not suited to public activity registries, or operational tasks that are not “research activities”). We therefore need an approach that does not block the pilot when RAiD cannot be applied, while still allowing us to determine whether RAiD provides enough integrative value to justify operating it at scale. (This constraint is consistent with the charters’ emphasis on MVP scope, privacy‑by‑design, and avoiding lock‑in.)

Timeline

The project is planned to start beginning of next year (2026). It would be good to have at least initial feedback in Jan 2026.

Additional Information

RAID_OrderPortalMapping.pdf

[alneberg]

Hi @wpotrzebowski, thank you for your request! I especially appreciate the mapping you supplied in the RAID_OrderPortalMapping.pdf. I think modifying the order portal forms slightly to fit with the RAID schema is the way to go and I think most suggestions look fine. However I fear that the embargo time is too short for a lot of our projects at the genomics platform. In (very) rare cases we might deliver the data back to the researcher 18 months or more after the order has been submitted. I'm not sure if its fair to publish the project metadata before the user has had any chance at looking at the data?

Is there perhaps a way to prolong the embargo time once it has been set?

Additionally, its important for the genomics platform that the order portal form does not become complicated to fill in. It has to be as easy as possible for the users.

As you already mention, we have some projects with industry which are confidential and never aim to be public, I guess they will not fit with RAID. So they would have to have some other identifier, probably generated by the system?

Also, I am under the impression that the European RAID minting service is not yet up and running, so maybe that would be problematic for the timeline of the project?

Will you keep a one to one mapping between projects in the order portal and in the project tracking page? What constitutes a project is very different for an individual researcher than a platform. At the genomics platform for example, we frequently split up projects into smaller projects to simplify administration, routines and throughput.

[jhagberg]

Architecture Board guidance: Internal-first identifiers

Thanks for the thorough analysis, @wpotrzebowski, and for the concrete OP↔RAiD mapping. Also +1 to @alneberg's and @viklund concerns.

Recommendation

I strongly recommend we do not make Project Tracking depend on an external minting service as its primary key.

Instead:

• Internal ProjectTracking ID = primary key (always exists; stable; used by all integrations)
• External PIDs (RAiD, DOI, local CRIS IDs, etc.) = optional identifiers, stored in a mapping layer (similar to the alternateIdentifier pattern in the mapping document)

This keeps the pilot unblocked and avoids lock-in, while still letting us test whether RAiD provides enough integrative value to justify broader adoption.

How this addresses stakeholder concerns

Concern	How internal-first helps
18-month embargo too short for some genomics projects	Internal ID exists from day 1; RAiD minted later when publication-ready
Industry/confidential projects can never be public	Internal-only ID – RAiD simply not minted
European RAiD service onboarding risk	System fully functional without external dependency
Platform vs researcher "project" definitions differ	Internal IDs model operational reality; RAiD reserved for research-facing identity
Future flexibility	Same pattern extends to DOI, institutional CRIS IDs, ORCID linkages

Alignment with the mapping document

The OP↔RAiD mapping notes that "OP does not enforce schema constraints by default" and suggests using alternateIdentifier to capture local CRIS/ERP IDs. This internal-first approach follows the same logic – RAiD becomes one of potentially several external identifiers, not the foundation.

Proposed decision

Project Tracking SHALL use internally-generated identifiers as primary keys. External persistent identifiers (RAiD, DOI, etc.) SHALL be stored as optional mappings and SHALL NOT be required for project creation or core system functionality.

I'll follow up with separate comments on RAiD feasibility details, domain modelling, and legal framework implications.

[jhagberg]

Comment 2: RAiD feasibility assessment

When RAiD fits – and when it doesn't

Building on Comment 1, here's a more detailed assessment of RAiD's fit for Project Tracking.

RAiD is a good candidate for:

Research activities where public discoverability is intended – linking researchers, outputs, funding, and datasets in open science workflows.

Constraints we must design around:

1. Embargo limit is a hard constraint

RAiD's access model is essentially open or embargoed, and the schema constrains embargoExpiry to ≤18 months from registration.

Reference: RAiD Metadata Schema v1.6

• https://metadata.raid.org/en/v1.6/core/access.html

For projects that may deliver results 18+ months after order submission, the practical workaround is delay RAiD minting until within an acceptable publication window – while tracking internally from day 1.

2. Permanently confidential projects don't fit (by design)

Industry collaborations and other permanently sensitive work should remain internal-only.

RAiD’s access vocabulary does not support permanently restricted access (i.e., it is designed for activities that are open now or become open after an embargo). For projects that will never become publicly discoverable, minting RAiD either compromises confidentiality or creates workarounds that defeat the purpose.

3. European service availability is a delivery risk

RAiD states Europe is served via SURF as Registration Agency, and FAIRCORE4EOSC describes RAiD as in production. However, practical onboarding, support maturity, and operational readiness should be treated as a delivery risk rather than assumed availability.

The pilot should be fully functional without RAiD while we validate the integration path and service readiness.

Suggested approach for the pilot

1. All projects get internal IDs from creation
2. RAiD integration as opt-in enrichment – test with suitable projects (open research, clear publication timeline)
3. Evaluate value before committing to broader rollout
4. Document the integration pattern so it can extend to other PIDs (DOI for datasets, ORCID for contributors, etc.)

Embargo update (important for implementation)

RAiD identifiers are persistent, but metadata can be updated over time. Even so, the 18-month-from-registration embargo constraint still applies, so “mint early with long embargo” only works for short pipelines.

Practical default: Mint RAiD when ≤18 months from expected publication, not at project creation.

[jhagberg]

Comment 3: Domain model considerations

Avoiding 1:1 assumptions between Order Portal and Project Tracking

@alneberg raised an important point: platforms may split or merge work for throughput/admin reasons, while researchers view "project" differently.

Recommendation: Don't bake 1:1 into the data model

The mapping document implicitly assumes one OP order ↔ one RAiD. But operationally:

• A researcher's "project" might span multiple platform orders
• A platform might split one order into multiple operational units
• RAiD is meant to identify a research activity, which may not align with either

Suggested approach

Design internal entities that reflect operational reality:

• ServiceRequest / Order – what comes from Order Portal
• OperationalProject – how platforms organise work internally
• ResearchActivity – the RAiD-worthy unit (optional, researcher-facing)

Allow N:M mappings between these. RAiD's schema supports relationships (relatedObject, relatedRaid) precisely because real research activities don't map 1:1 to administrative units.

This flexibility also helps with the "who owns this record" question – an OperationalProject clearly belongs to a platform/unit, while a ResearchActivity might span multiple.

For the pilot

Start simple, but don't foreclose flexibility. If the initial implementation assumes 1:1, make sure the data model can evolve to N:M without major rework.

[wpotrzebowski]

Thank you for comments/recomendations @jhagberg and @alneberg! They give a good basis for devising a future solution. I don't know answers to the questions posed e.g. regarding extending embargo in RaID but may learn them as we go.