Technical interoperability in the EOSC

The document “Technical Interoperability in the EOSC Federation and Initial Gap Analysis” was prepared as part of the work of the EOSC Association Interoperability Task Force (Technical & Semantic Interoperability). It addresses a practical question: which technical conditions are still missing for the EOSC Federation to function for researchers as a truly “single” infrastructure, rather than as a set of disconnected services and repositories.

The annotation emphasises that the vision of the EOSC Federation depends on a high level of technical interoperability between Nodes, and that the current baseline capabilities — AAI and catalogues — are necessary but not sufficient for modern interdisciplinary scenarios.

Context: How the Document Defines the EOSC Federation and Its “Building Blocks”

In the “Background and Context” section, the EOSC Federation is described as a “system of systems”: a system that brings together different research infrastructures through EOSC Nodes and enables the secure sharing of FAIR data and services across institutions and countries.

At a high level, the architecture consists of three components:

1. EOSC Nodes;
2. Federating Capabilities, which are enabled through cooperation between Nodes;
3. Interfaces, including APIs and metadata schemas, which connect Node services with federating capabilities and must be aligned with the requirements of the EOSC Interoperability Framework (EOSC IF).

Figure 2.1 — High-level EOSC Federation Architecture

The document also details the architecture of a Node. Each Node has Core Capabilities, including AAI, helpdesk, monitoring and resource catalogues, as well as Node Resources. These resources are divided into generic resources, domain-specific research resources and a subset called Node Exchange — the resources that a Node shares with the federation.

The document also identifies the initial set of federating capabilities that, during the build-up phase, are provided mainly through the EOSC EU Node. The mandatory capabilities are the federated resource catalogue and federated AAI. The recommended capabilities include workflow orchestration, monitoring, accounting, helpdesk integration and management systems.

In this context, the EOSC IF is interpreted as a set of Interoperability Guidelines, an Interoperability Registry and governance mechanisms that ensure the coordinated operation of the federation’s components.

Method: What the Gap Analysis Is Based On

The key value of the document is that the gaps are identified not “from the architecture”, but from user needs. The authors analyse what is currently possible and what is needed so that Nodes can cooperate in real scientific scenarios.

The evidence base includes 82 use cases and 70 user stories. The document notes that these cases are not statistically representative of the entire future EOSC audience, but they make it possible to reliably identify recurring needs.

Requirements were collected through three campaigns:

1. from Pilot Nodes within EOSC Beyond;
2. from a wider audience during the EOSC Winter School 2025;
3. from technical experts and representatives of large scientific communities within the Task Force.

To make the problem more concrete, the document presents illustrative domain-specific scenarios.

In the Life Sciences, the focus is on large data volumes — terabytes per day from a single microscope — the need to combine public and private data in a single computational environment, and barriers to accessing sensitive biomedical data in trusted environments.

For Photon and Neutron facilities, the document describes the problem of multi-source tera- and petabyte-scale datasets, complex formats and metadata, the lack of a platform for processing, and publication delays caused by manual integration operations.

In Astronomy and Astrophysics, the document presents a “reference” example of standardisation through IVOA and the requirement to minimise data movement, following the principle of “bring the code to the data”, including containerisation and workflow orchestration in a distributed environment.

Identified Gaps: What Is Not Yet “Stitched Together” in the Federation

The consolidated list of gaps covers:

• metadata and discovery;
• data harmonisation and integration;
• service discovery and API compatibility;
• federated AAI;
• data lifecycle management and preservation, including PIDs;
• resource and allocation management;
• support and training;
• governance and policies, including sensitive data and regulatory compliance.

Proposal: Which New Federating Capabilities Are Needed

Based on the gap analysis, the document proposes a priority set of new federating capabilities:

1. data and metadata interoperability through radical transparency;
2. federated resource discovery;
3. federated access to and reuse of services;
4. federated compute and storage for data analysis;
5. file/data sync and share;
6. large-scale data transfers;
7. AI tools to support interoperability.

The most conceptually important proposal is radical transparency. The authors explicitly state that transparency does not replace interoperability, but is its prerequisite. It makes it possible to move from opinion-based discussions to managed improvement based on measurable differences.

A minimal normative layer is proposed: web-based descriptions of digital assets and the recording of their technical conformity, together with tools for validating and monitoring such declarations.

In relation to SRIA/MAR, examples of “minimum rules” for transparency are provided: the use of PIDs, controlled vocabularies, open formats, provenance metadata and similar elements.

For federated discovery, the document proposes an evolution from centralised search in the EOSC Resource Catalogue towards a federation of catalogues that can work with different metadata schemas and disciplinary specificities. In this context, the document also proposes a Common Data Model (CDM): a small “core” of shared fields plus extensions for domain metadata and controlled vocabularies. This should make it possible to combine compatibility with rich disciplinary descriptions.

For the reuse of services, the document proposes developing a Shared Access Policies Model and strengthening the EOSC IF so that it supports machine-composability of services and datasets through configurations of interoperability guidelines.

For compute and storage, the document recommends common architectural blueprints, further development of “bring code to data” approaches, container orchestration and intelligent resource brokering. It also explicitly identifies the need for a federated Credit & Order Management system to support fair allocation and monitoring of resource consumption across Nodes.

For collaboration, the document proposes recommending EFSS services — file synchronisation and sharing services — as a baseline federating service for Nodes. For large-scale movement of data, it proposes Bulk Data Transfer, which should be able to translate PIDs into real access endpoints and integrate with the federated catalogue.

A separate section is devoted to AI/LLM as tools for strengthening interoperability. The proposed uses include automated documentation generation, schema crosswalks, creation and linking of controlled vocabularies, and multilingual search. At the same time, the document stresses the need for benchmarks, traceability of FAIR data sources in models, and the integration of AI-based approaches into registries and catalogues.

Towards a Roadmap: Links to SRIA and “What to Do Next”

The document synchronises its recommendations with the SRIA, which identifies seven technical challenges:

1. identifiers;
2. metadata and ontologies;
3. FAIR metrics and certification;
4. AAI;
5. user environments;
6. provider environments;
7. the EOSC IF.

It proposes that corresponding actions be included in the next cycle of the Multi-Annual Roadmap (MAR).

In the “Conclusions and Next Steps” section, the document proposes a four-step plan:

1. validation with stakeholders;
2. specification and prototyping;
3. alignment with the Federation Handbook, the EOSC IF, the Build-up Group and the development of the EOSC EU Node, including a proposed revision of the EOSC IF;
4. testing on candidate Node use cases, followed by scaling.