Marcus Povey

There is a reasonable argument that the best way to design an interoperability standard for EOSC service catalogues is to look at what nodes are actually publishing before deciding what to mandate. This post does exactly that: it compares the two catalogue formats in active production use today, maps both against the DCAT-AP target that EOSC-A is moving towards, and draws some conclusions about what a workable minimal profile might actually look like.

The short version: the divergence between formats is real, it is already in production, and the empirical common core is smaller than either spec requires. Which is, somewhat inconveniently, the strongest possible argument for starting there.

The two formats

There are currently two formats in active use across EOSC nodes.

EEN (EOSC EU Node) format is defined in the EOSC EU Node Interoperability Guidelines (v7, February 2026). It specifies a ServiceBundle wrapper containing a nested Service object, with 12 required fields and a further 10 optional ones, all validated against controlled vocabularies published on GitHub. The API exposes a single /services endpoint returning paginated results in this nested structure.

EOSC Beyond format is derived from the madgeek-arc resource-catalogue, the same codebase that powered the original EOSC Portal service catalogue developed as part of the EOSC Future project. It places records flat in the results array with no nested wrapper. The schema shares much of EEN’s vocabulary (prefixed identifiers, shared category and domain terms) but extends it substantially with node provenance fields (nodePID, resourceOwner, serviceProviders), richer classification (scientificSubdomain, subcategory), and operational metadata (publishingDate, jurisdiction).

To be clear: these two formats are not the same thing. A harvester written for one will fail silently on the other without adaptation.

What the live data looks like

I pulled 239 service records from the EOSC Beyond sandbox API (providers.sandbox.eosc-beyond.eu/api/public/service/all) and compared them against the EEN specification and a draft EEN-to-DCAT field mapping being developed within the working group.

Here is what the three-way mapping looks like:

Fields that map cleanly across all three

Eight fields are present in both formats and have clean DCAT equivalents:

EEN field	EOSC Beyond field	DCAT mapping
serviceBundle.id / service.id	id	dcterms:identifier
name	name	dcterms:title
webpage	webpage	dcat:landingPage
description	description	dcterms:description
scientificDomains[].scientificDomain	scientificDomains[].scientificDomain	dcat:theme
categories[].category	categories[].category	dcterms:type
trl	trl	eosc:technologyReadinessLevel
orderType	orderType	eosc:orderType

Field names are identical across both formats for all eight. Vocabularies are identical. This is the empirical common core.

Fields that exist in both but with different names

Three pairs of fields share the same semantics but differ in naming. None of these is a meaningful technical challenge:

• accessModes[] (EEN) maps to accessTypes[] (EOSC Beyond). Same vocabulary values, same concept, different key name.
• alternativeIdentifiers[] (EEN) maps to alternativePIDs[] (EOSC Beyond). Same concept, slightly different sub-structure for the type/value pair.
• helpdeskEmail (EEN) maps to publicContacts[] (EOSC Beyond). EEN is a single email string; EOSC Beyond is an array.

These are one-line crosswalk rules. Both sides map to dcterms:accessRights, adms:identifier, and dcat:contactPoint respectively.

Required EEN fields with no EOSC Beyond equivalent

This is where things get interesting, EEN marks two fields as required that do not appear anywhere in the EOSC Beyond schema: targetUsers (mapping to dcterms:audience) and languageAvailabilities (mapping to dcterms:language). Across all 239 live records examined, neither field appears.

Including these two fields in any mandatory minimum profile would immediately disqualify every node currently running EOSC Beyond’s catalogue software. That seems like a poor starting point for a federation interoperability standard.

EOSC Beyond extensions with no EEN equivalent

EOSC Beyond also adds fields that EEN does not model at all but, several of these are useful and have reasonable DCAT equivalents:

EOSC Beyond field	Suggested DCAT mapping	Notes
nodePID	dcterms:isPartOf	Node provenance. Useful.
resourceOwner	dcterms:publisher	Organisation PID.
serviceProviders[]	dcterms:contributor	Often identical to resourceOwner in practice.
publishingDate	dcterms:issued	ISO 8601. Maps directly.
jurisdiction	dcterms:spatial	Controlled vocab (global, national, regional).
scientificDomains[].scientificSubdomain	dcat:theme (narrower concept)	Adds a second classification tier.
categories[].subcategory	dcterms:type (narrower)	Same approach.
order (URL)	dcat:accessService	Ordering endpoint. Frequently null.

The provenance fields in particular (nodePID, jurisdiction, resourceOwner) are not covered by the current EEN spec but are valuable for federation-level discovery, and they should be considered as recommended fields in any minimal profile.

The case for an empirical minimal profile

The argument for starting with a small mandatory profile rather than the full EEN specification has, up to now, rested on practical and political grounds: fewer fields means lower implementation burden, and lower implementation burden means more nodes actually participating.

This analysis adds an empirical leg to that argument. The eight fields in the clean-match table above are what nodes actually publish today. They are present in both formats, they have unambiguous DCAT mappings, and they use identical vocabulary values. No committee decision required.

The two EEN-required fields that fall outside this intersection (targetUsers and languageAvailabilities) are absent from every live EOSC Beyond record examined. If we are designing for the federation that exists rather than the one we would prefer to have, these belong in a recommended tier, not a required one.

What needs to happen next

Here are a few concrete things would move this forward…

Write up the minimal profile as a specification, not a recommendation. A versioned document with example JSON and field-level validation rules gives nodes something to implement. A discussion paper does not.

Extend the EEN-to-DCAT mapping document to include EOSC Beyond. The current mapping covers EEN fields only. The EOSC Beyond-specific fields (nodePID, jurisdiction, resourceOwner, publishingDate) need agreed DCAT predicate mappings and vocabulary URIs, which means engaging with EOSC-A and the EOSC Beyond teams.

Resolve the structural incompatibility between the two formats. The EEN ServiceBundle wrapper and the EOSC Beyond flat record structure are both in active production. A harvester needs to handle both, since both are being used with real EOSC nodes. The pragmatic option is format negotiation at the harvester rather than requiring nodes to maintain two API endpoints.

Surface the missing required fields with the working group. The fact that targetUsers and languageAvailabilities are required in EEN but absent from every EOSC Beyond record is not something the working group can quietly ignore. Either those fields get demoted to recommended in the EEN spec, or there needs to be a concrete plan for how EOSC Beyond nodes supply them. Either outcome is fine; the current ambiguity is not.

Set minimum data quality thresholds as a precondition for federation-level harvesting. At minimum: a real contact address, at least one tag, and a non-null access policy. A simple self-service validation endpoint that nodes can run against their own feed before registration would catch most of these issues before they become the federation’s problem.

The conclusion from all of this is that the path to EOSC service catalogue interoperability runs through the data that already exists, not through the data we would like to exist. Eight fields. Nodes actually publishing them, and that is the starting point.

---

The analysis in this post is based on the EEN Interoperability Guidelines v7 (February 2026) and the EOSC Beyond sandbox API as of July 2026. A draft EEN-to-DCAT field mapping is being developed within the EOSC working group on resource catalogue interoperability.