Making services discoverable in the EOSC Federation: registering catalogues with the EOSC EU Node
The document Registration of EOSC Service Catalogues in the EOSC EU Node’s Resource Catalogue, version 7.2 of 20 October 2026, describes how EOSC Nodes connect their service catalogues to the shared catalogue operated by the EOSC EU Node. Its practical significance lies in explaining how services from different providers become discoverable through a single entry point: the EOSC Resource Hub. A review of version v5.1 of this same document has already been published on the website. https://fair-center.bitp.kyiv.ua/resources/analytical-materials/registering-eosc-node-service/
The mechanism involves harvesting and indexing service metadata. The services themselves can remain on their providers’ infrastructure. The document therefore defines how resources are represented in a shared discovery environment and the technical and organisational conditions required. For institutions of the National Academy of Sciences of Ukraine, it helps translate the general intention to participate in EOSC into the preparation of a specific service portfolio.
The definition of a service is important. The document describes it as a digital service delivering capabilities through a web interface or API. Examples include repositories, computing platforms, data analysis environments, data management planning tools and training platforms. An information page about an organisation does not, by itself, constitute such a service. Similarly, software code and an operational service built on that code are different objects.
The document distinguishes three service tiers according to how services are provided and integrated with the EOSC EU Node. This classification describes their position within the infrastructure rather than ranking their scientific quality.
| Tier | Service ownership and origin | How services are presented |
|---|---|---|
| Tier 1 | Services owned by the European Commission and procured or provisioned for the EOSC EU Node. | Fully integrated into the EU Node’s service offering, including its User Space and credit system. |
| Tier 2 | Services owned by third-party providers and onboarded directly to the EOSC EU Node through a separate procedure. | Integration, access and ordering arrangements are determined during service onboarding. |
| Tier 3 | Services of other EOSC Nodes whose descriptions are harvested from those Nodes’ registered service catalogues. | Metadata are aggregated into the shared catalogue, while users access the service through an external link. |
Tier 3 is the focus of the document. Through its catalogue, a Node presents a selected set of services that it intends to share with the Federation. These may include both services owned by the Node operator and services provided by other organisations and onboarded to its portfolio. Not all local services necessarily need to be exposed through the shared catalogue.
One rule is particularly relevant: each Node can register one Service Catalogue. For prospective NASU Nodes, this means coordinating resource descriptions across participating institutions and identifying who is responsible for maintaining the catalogue, updating its content and communicating with the EOSC EU Node team. In the document’s model, the Node operator is a legal entity responsible for its governance.
The technical approach relies on a common exchange format. A local catalogue may use its own service information model, but must map its records to the Service Bundle schema for exchange. Records are made available through a REST API implementing GET /services. The response includes the total number of records, the result range and a list of service descriptions.
Mandatory service metadata include an identifier, name, webpage, description, scientific domains, service category, target users, available languages, technology readiness level and access or ordering modality. Several fields use controlled vocabularies. A locally unique identifier can be used for the primary identifier field: a DOI is not a universal requirement for every service.
It is also necessary to distinguish a service description from the catalogue registration profile. For example, helpdesk and security contacts are optional in the service metadata schema, whereas the catalogue registration wizard requires the corresponding email addresses. Preparation must therefore cover both the technical export of service records and organisational information about the catalogue provider.
Catalogue registration is linked to the Node enrolment workflow. The EOSC EU Node Onboarding Team creates an initial Node entry, after which an authorised representative completes the application through the Contributor Dashboard. The catalogue is registered as a Data Source, with Services Metadata as its type, Service Catalogue as its classification, and a REST API endpoint. Catalogue registration can begin while the Node enrolment application is still under review.
Following submission, the EU Node team validates the protocol implementation, metadata structure and semantics. Any incompatibilities are addressed through subsequent validation rounds. The document specifies monthly harvesting, so changes to the local catalogue do not imply an immediate update of the discovery portal.
| Stage | Required outcome |
|---|---|
| Define the portfolio. | Agree on the services to be included, their providers, intended users and access conditions. |
| Prepare service descriptions. | Complete mandatory metadata fields and apply the appropriate controlled vocabularies. |
| Ensure technical compatibility. | Expose Service Bundle records through a REST API that conforms to the specification. |
| Register and validate. | Submit the catalogue profile and resolve issues identified by the EOSC EU Node team. |
| Maintain the catalogue. | Keep descriptions current, maintain API availability and update responsible contacts. |
For NASU, another important distinction is between registering a repository as a service and providing metadata about its individual research outputs. Presenting DataverseUA in a service catalogue can help users discover the repository. However, this procedure does not, by itself, ensure that all its datasets are indexed. Similarly, a service’s appearance in the Resource Hub does not automatically demonstrate federated authentication, computing integration or full interoperability between research workflows.
The document accommodates different implementation options: developing catalogue software, deploying existing open-source software or using a catalogue-as-a-service solution. Appendix D identifies options involving the EOSC EU Node, SURF, CSC and D4Science. Building a new, complex portal is therefore not the only approach. The choice should reflect the number of services, community needs and the capacity to maintain the solution.
For the Competence Center, a practical role is to help institutions describe their services, identify users, prepare documentation and harmonise metadata. A training platform or digital research support service could be considered for inclusion in an appropriate Node’s portfolio, subject to its requirements. API implementation, registration and catalogue maintenance need to be agreed with the Node operator.
The document provides a concrete mechanism for making services discoverable across the EOSC Federation. Applying it requires an agreed portfolio, an accountable operator, a compatible catalogue and continuing maintenance of service descriptions. These are specific components that can be assessed during the preparation of NASU pilot Nodes.
Source: Registration of EOSC Service Catalogues in the EOSC EU Node’s Resource Catalogue, v7.2, 20 October 2026, pp. 3–11 and Appendices C–D. The implications for NASU and the Competence Center are analytical conclusions.