Marcus Povey

One of the slightly unglamorous things I have been thinking about recently has been identifiers.

I realise this is not the sort of sentence that gets people rushing to click, but identifiers are one of those bits of infrastructure that only look boring until they are missing. Once you start trying to join research data across proposals, facility visits, raw data, processed outputs, public repositories, and future AI workflows, you very quickly discover that the humble question “what is this thing called?” is not humble at all.

In ARIA, we already have a lot of the contextual information around a piece of science. We know about the access proposal, the facility visit, the access route, the site, and, increasingly through the data management work we have been doing for Fragment-Screen, the data and metadata generated during the experiment. What we have not had, at least not in a clean public way, is a canonical way of referring to those ARIA entities outside ARIA itself.

So, shamelessly riffing on the idea of identifiers.org, we put together identifiers.aria.services.

The problem with local IDs

Inside ARIA, a proposal ID or visit ID is meaningful. Proposal 12345 means something to the system, and a visit attached to that proposal means something to the facility and the researcher. However, outside ARIA, 12345 is just a number.

If I put proposal 12345 into a PDB deposition, a project catalogue, a molecular dynamics database record, or a JSON metadata file, I have not really created a durable reference, I have created a clue. Someone who already knows about ARIA might be able to work out what I meant, but the identifier itself does not carry enough context to survive on its own.

Most systems have IDs, the problem is that local IDs do not travel well. What we need is something more like:

https://identifiers.aria.services/proposal:12345
https://identifiers.aria.services/visit:12345

Now the identifier says a few useful things at once:

• this is an ARIA identifier
• it refers to a proposal or visit
• it has a namespace and accession
• it can be resolved
• it can be embedded in other metadata without losing its meaning

That last point is the important one, this is not just about prettier URLs, it’s about giving ARIA entities stable names that can be used elsewhere and carry the relevant context with it.

PID-like, deliberately modest

I am being quite deliberate in saying PID-like here.

This is not, by itself, a full persistent identifier infrastructure. It does not replace DOIs, ARC IDs or anything else that already exists and works well in its own domain, it is also not an argument against registering ARIA namespaces with identifiers.org in the future. What identifiers.aria.services gives us is a first controlled step, a place under ARIA control, where ARIA entities can have canonical, resolvable references.

This matters because the ARIA data model is evolving. Historically, ARIA was primarily about access management: proposals, review, approval, visits, reporting. Increasingly, as I have written about before, we are linking proposals to experimental metadata, raw data locations, outputs and depositions. This necessitates stable hooks to hang things on.

Fragment-Screen as the first real use case

Fragment-Screen is a good example of why this matters. A fragment screening campaign is not a single data object, it is a chain of related activity. There is a proposal and one or more facility visits. There are samples, targets, fragments, machine settings, experimental conditions, raw data, processed outputs, and eventually public depositions or publications.

The scientific value is not just in any one of these things. it is in the connections between them. So, if a dataset captured through FandanGO can point back to:

https://identifiers.aria.services/visit:12345

Then that dataset has a durable link to the visit context that produced it, so that, if it is found on a disk some time in the future, the provenance can be preserved.

If a public output can point back to:

https://identifiers.aria.services/proposal:12345

Then that output is no longer floating free of the access record, it has a link back to the proposal, the infrastructure, and, where policy allows, the broader chain of experimental context.

Depositions need provenance hooks

The same issue appears when we think about public repositories.

The Protein Data Bank is already a rich, structured archive for macromolecular structures, with PDBx/mmCIF providing a detailed metadata framework for representing structural data and associated information. MDDB, similarly, is concerned with molecular dynamics data, metadata, provenance, and reuse. However, from ARIA’s point of view, the question is: how do we connect those final research outputs back to the access and facility context that produced them?

If a PDB deposition can carry a reference to an ARIA proposal or visit, then the structure is no longer just an isolated output from the perspective of the research infrastructure. It becomes part of a traceable chain:

proposal -> visit -> experiment -> raw data -> processed output -> deposition

That is useful for researchers, because it makes it easier to understand where data came from, and it is useful for facilities, because it helps demonstrate impact and track downstream outputs. Frankly, it is also useful for sanity, as six months after an experiment, nobody should have to hunt through email chains to work out which visit produced which data.

From resolver to machine-readable context

The first version is deliberately incredibly simplistic, you can as for:

https://identifiers.aria.services/proposal:12345

Which will redirect you to the appropriate ARIA or data.aria.services page.

Later, we can do more interesting things; a browser request can resolve to a human-readable page, while a request asking for JSON can return structured metadata. A future deposition workflow could include the ARIA proposal or visit identifier and downstream systems could follow that reference to discover more context.

This is where the PID-like behaviour starts to become more than just resolution and becomes a way of exposing ARIA entities as part of a wider machine-readable research graph, which fits with some of the knowledge graph work we’ve been experimenting with. In that world, identifiers are the entry points into a network of relationships; a proposal links to visits, visits link to data, data links to outputs, outputs link to public repositories, public repositories link to proteins, ligands, publications, authors, organisations, and projects.

So, identifiers.aria.services is not a big flashy feature, it is a small resolver for ARIA proposal and visit identifiers. But this is exactly the sort of small infrastructure step that makes larger things possible. It gives us a controlled way to refer to ARIA entities outside ARIA, and gives us a way to stop treating ARIA IDs as local implementation details and start treating them as part of the research data landscape.

Visit the project on Gitlab...