Marcus Povey

Most research infrastructure data has a short memory. You get access, you run your experiment, you take your data home, and, from the infrastructure’s point of view, that’s more or less the end of the relationship. The proposal exists in one system, the raw data sits on a facility’s storage (if you’re lucky), and the two rarely speak to each other again. Ask someone six months later which access project a given dataset came from and you’ll get a shrug, or an email chain.

That’s not a criticism of anyone in particular, it’s just what happens when data and metadata are captured as an afterthought rather than as part of the workflow. It’s a real problem if you’re trying to do anything more ambitious with that data than store it, like, say, use it to train an AI model.

What Fragment-Screen is actually doing

Fragment-Screen is a Horizon Europe project bringing together research infrastructures, plus a clutch of industry partners, to modernise fragment-based drug discovery (FBDD). The short version: instead of screening drugs as fully-formed molecules, you screen small chemical fragments against a target, find the ones that bind (weakly), and then grow or link them into something more potent. It’s faster and cheaper than traditional screening, and it leans heavily on structural biology to work.

Instruct coordinates the project, which fits, since ‘integrated structural biology’ is Instruct’s whole reason for existing, and Fragment-Screen is a good demonstration of why that integration matters. X-ray, NMR, cryo-EM, and mass spectrometry all get used across the project, often on the same targets, and the value only really shows up when you can link results across techniques rather than treating each as its own silo.

Where I come in

My piece of this is Work Package 4 (data management) and specifically making ARIA, Instruct’s access management system, “data-aware.” Which sounds obvious until you notice it currently isn’t. Research infrastructure access projects generate a lot of data at acquisition time, at various facilities, and until now there’s been no link between that data and the project record in ARIA. The data exists. The connection doesn’t.

We’re extending ARIA to capture data and acquisition-related metadata during access, and tying it back to the original proposal, cradle to grave, in theory: proposal, raw data, metadata, outputs, all linked to the same thread. In practice this means a new tool, FandanGO, sitting alongside ARIA and talking to facility storage, plus a new project output page (data.aria.services) where you can browse your own data (or anyone’s, once an embargo period lifts) by title or by mined content identifiers, visualise it, and download it.

The part I actually find interesting

The metadata linking on its own is useful but not thrilling. What I think is genuinely worth talking about is the cross-referencing: once you’ve got metadata attached to data attached to a project, you can start mining and graphing the connections between projects, and enriching records with identifiers that weren’t in the original sample at all. A compound logged with a SMILES string, for instance, can get an InChI cross-reference added automatically, opening it up to a different set of databases and tools without anyone having to do that mapping by hand.

That’s the bit that starts to look less like record-keeping and more like infrastructure for AI. Fragment screening is exactly the kind of domain where the training data that matters most isn’t the headline result, it’s the chemicals used, the machine settings, the things nobody thinks to write down because they’re “obvious” at the time and completely lost six months later. Curated, linked, well-described data is the actual bottleneck for AI-assisted drug discovery, more than the models themselves.

What’s still in progress

Some of this is running, some is in build. The end-to-end demonstration, capture at an NMR facility, storage linked to the proposal, download of visit information, execution in a model, is planned as future work as we had to build the infrastructure first. The wider repository wiring into BMRB and PDB is next.

There’s also a natural next step that I’ve been circling in parallel: some of the semantic interoperability and catalogue federation work I’ve been doing in EOSC overlaps with exactly this problem, i.e. how you make data findable and federated across infrastructures without everyone reinventing the same plumbing. Fragment-Screen’s open catalogue is one instance of a pattern that’s going to keep recurring across European research infrastructure, and it’s a big part of why I think this space is worth more attention than it gets.