Horizon Europe · HORIZON-INFRA-2025-01-DEV-03 · M1–M36

Everything the Navigator says out loud, we modelled first.

AI4Access turns the Euro-BioImaging catalogue into a machine-actionable knowledge base — an ontology-driven graph of services, methods, workflows and providers, linked by persistent identifiers. That graph is the project. This is a working reference to it, read from the seat that builds it — unfamiliar terms are in the glossary.

39
Nodes to harmonise
295
Facilities described
1,100+
Past projects as evidence
120+
Technologies to model

Where we sit

Not the manager's view. the knowledge modeller's.

We define meaning

Entities, relations, controlled vocabularies, PID strategy. What counts as a service, how a facility relates to a technology, which term is authoritative. Decided in T2.1, inherited by everything after it.

We fill it with truth

39 Nodes, a website full of prose, and 1,100+ past projects — collected, enriched with AI assistance, reviewed by humans, and kept fresh by an update protocol that outlives the grant.

We are everyone's upstream

KTH's backend, the MCP SDK, the pilots, the provenance framework, the explanations shown to users — all read from what we build. When the schema slips, seventeen tasks slip with it.

12 of 33 tasks led or co-led here

The work owned from this seat

WP2T2.1M1–M12

Ontology-aligned, AI-enhanced data model for Node services

The foundation stone. Define the minimum viable semantic model for services, technologies, facilities and workflows; pick and align controlled vocabularies; set the PID strategy (ORCID / ROR / DOI / PIDINST) that every later record hangs off.

D2.1 (M12)
WP2T2.2M6–M24

Engagement with Nodes and data collection

Where the model meets 39 Nodes and 295 facilities. Templates go out, messy reality comes back. AI-assisted enrichment plus human review loops turn heterogeneous Node descriptions into the first harmonised dataset.

D2.2 (M18)
WP2T2.3M6–M24

Continuous integration of Euro-BioImaging website content

The public website and Access Portal already hold years of curated knowledge in prose. Map it, tag it semantically, parse it with AI assistance, and turn it into machine-actionable content the Navigator can cite.

D2.3 (M24)
WP2T2.4M18–M36

Update protocol and long-term Node engagement

A knowledge base that is not maintained is a knowledge base that lies. Design the update cycle, self-service editing, AI-assisted quality checks and the governance that keeps it alive after M36.

D2.4 (M24)
WP2T2.5M12–M36

Integration with user access support in INFRA-SERVs

Cross-RI semantic mapping. INFRA-SERV catalogue vocabularies (canSERV, ISIDORe, AgroSERV) will not match ours; this task owns the crosswalks and proves that a query can route across infrastructure boundaries without losing meaning.

D2.5.1 (M18)D2.5.2 (M36)
WP3T3.1M6–M18

Landscape analysis of image analysis tools and integration

Survey the analysis-tool landscape and score integration maturity and FAIRness. BIII is the obvious anchor: reuse its tool/workflow records rather than re-cataloguing from scratch.

D3.1 (M12)
WP3T3.2M1–M36

AI-ready service catalogues

The longest-running task led here — M1 to M36. Maintain the machine-actionable image-data service catalogue and drive EDAM / EDAM-Bioimaging updates back to the upstream community, not just into this project's own store.

D3.2 (M24)MS2 (M24)
WP4T4.2M12–M30

Continuous learning and system updates

Provenance, versioning and rollback are data-architecture problems wearing an engineering hat. The T2.4 update protocol and this pipeline must be the same mechanism, not two competing ones.

D4.2 (M36)
WP5T5.1M1–M36

Integration with Nodes and national platforms

Five pilots test whether the model survives contact with real national information systems. Database integration here is a mapping exercise against local schemas this function does not control.

D5.1 (M36)MS3 (M12)
WP5T5.2M12–M36

Pilot with individual facility processes

Facility management systems (booking, LIMS) hold the operational truth. Mapping them defines the data-sharing boundary between what the Navigator may know and what stays local.

D5.2 (M18)MS4 (M19)
WP5T5.3M18–M36

Training Node staff on the Research Navigator and its implementation

The update protocol (T2.4) and the SDK/MCP adapters (T4.4) are only as good as whether a Node coordinator can actually operate them. This task turns both into workshops, checklists and an adoption playbook.

D5.3 (M36)MS5 (M18)
WP6T6.2M12–M36

Transparent explanations and ethical traceability

"Why did the Navigator recommend this?" is answerable only if the evidence objects and their links were modelled from day one. Model/data cards and audit logs draw straight from the provenance graph built here.

D6.2 (M30)

The spine

The chain everything downstream inherits from

  1. M1–M12
    1. T2.1 — the semantic model
    Ontology alignment, PID strategy, validation rules. D2.1 at M12.
  2. ~M12
    2. Schema v1.0 freeze
    Not in the register. Needs agreeing with KTH, or D4.1 is built on sand.
  3. M6–M24
    3. T2.2 / T2.3 — fill it
    Node submissions and website content become one harmonised dataset. D2.2 at M18.
  4. M18
    4. T4.1 — KTH's backend goes live on our data
    First hard proof that the model answers real questions.
  5. M18–M36
    5. T2.4 / T3.2 — keep it alive
    Update protocol and the maintained AI-ready catalogue. MS2 at M24.
  6. M36
    6. A knowledge base that outlives the grant
    Reusable by other ERICs through the white-label toolkit.

7 open items, 2 critical

What's still undecided

No Node data collection dashboard exists

critical

T2.2 asks 39 Nodes to submit structured service descriptions. Without a real intake surface — templates, validation on entry, per-Node status, review queue — collection degrades into spreadsheets by email, and the harmonisation cost lands here at exactly the moment D2.2 (M18) is due.

AskAgree by ~M4 whether this is built in-house, extended from the Access Portal, or bought. It has to exist before the model is finalised, because the intake form is the model made visible.

Ontology base is undecided

critical

T2.1 must pick between extending EDAM-Bioimaging, formalising the 2022 harmonised services ontology, adopting foundingGIDE recommendations, or a hybrid. Every downstream annotation, crosswalk and adapter schema inherits this choice, and reversing it after M12 is expensive.

AskA time-boxed decision workshop before M6, with a written rationale. Recommendation: OLS-resolved terms, EDAM-Bioimaging for analysis, a small Euro-BioImaging services extension for access concepts.

Schema freeze date not agreed with KTH

high

T4.1 delivers the backend and hybrid knowledge base at M18 and depends on T2.1–T2.4. If the model is still moving at M15, KTH builds against a shifting target and both sides absorb rework.

AskAgree a v1.0 schema freeze at M12 with a versioned change process afterwards — additive changes only until M18.

Unfilled posts across dependent tasks

high

The register lists 'new hire' on T1.1–T1.4 and 'Aman till new hire' on WP4 tasks. Inputs from this function land on people who are not yet in post, and the WP1 persona work that shapes the data model is among them.

AskConfirm start dates so it's known whether the T1.2 intent taxonomy will really be usable before the T2.1 freeze.

Authority rules for conflicting sources

high

Node submissions (T2.2), website content (T2.3) and facility systems (T5.2) will disagree about the same service. Without a precedence rule and a sign-off owner, the knowledge base contains contradictions the Navigator will confidently repeat.

AskDefine a source precedence order and a named authority per record type, inside the T2.4 update protocol.

10 sources we build on

We are not starting from zero

Euro-BioImaging ERIC

Euro-BioImaging Access Portal

Proposal form fields → target schema for the agentic pre-population in T4.3

Euro-BioImaging-coordinated Horizon CSA

foundingGIDE — Ontology & Metadata / GIDE Stack

Metadata exchange schema patterns — do not reinvent the interoperability layer

EMBL-EBI

EMBL-EBI OLS4

Term resolution service — resolve and validate every vocabulary term at ingest, no local copies of ontologies

EDAM community, hosted at BioPortal & OLS

EDAM / EDAM-Bioimaging

Operations and topics vocabulary for describing analysis services

Bioimaging community / Image Data Resource (IDR)

REMBI — Recommended Metadata for Biological Images

The eight-module structure as a template for what a Node service record needs to carry

NEUBIAS community / BIII.eu

BIII — BioImage Informatics Index

Tool and workflow records as ready-made seed content for T3.1 and T3.2

AI4Life Horizon Europe project / AICell Lab

Hypha / BioEngine (AI4Life project)

Precedent architecture for WP4's AI Agent: orchestrating heterogeneous tools and data behind one agent interface

Euro-BioImaging + Node experts (2022 restructuring)

Harmonised imaging services ontology work

The service-oriented portfolio structure as the skeleton of the T2.1 model

Global PID infrastructure

PID backbone: ORCID, ROR, DOI, PIDINST

ROR for Nodes, facilities and partner organisations

European platforms and data spaces

EOSC LSR, EUCAIM, UNCAN

Their catalogue schemas as crosswalk targets, defined once and maintained

Four organisations

Who we work through

ERIC
Euro-BioImaging ERIC
Finland

Coordinator; Access Portal, personas, regulatory, INFRA-SERV, dissemination.

Bio-Hub
European Molecular Biology Laboratory
Germany

Home of the WP2 data model, WP3 catalogues, Node engagement.

Med-Hub
Consiglio Nazionale delle Ricerche
Italy

Co-lead on WP2/WP3/WP5; medical imaging perspective on the model.

KTH
KTH Royal Institute of Technology
Sweden

GenAI backend, hybrid knowledge base, RAG/CAG, provenance, evaluation.

The end goal

A researcher describes a problem in plain language, and the answer names a real technology, a real facility, and a real analysis route — with citations.

Every part of that sentence is a data-architecture commitment. "Real technology" means a maintained, ontology-aligned catalogue. "Real facility" means PID-linked Node records that are still true today. "With citations" means provenance modelled into every assertion from M1. If the graph is right, the Navigator is useful. If it is not, no amount of model quality rescues it.

8 deliverables in the register carry our name. The rest of the project reads from what they produce.