More than half of publicly funded research data in Europe remains difficult to access outside the institutions that created it. In many cases the issue is not the quality of the data, but the architecture of the platforms that store it.
INFRA-ART contained over 2,000 spectral records derived from paintings, archaeological artifacts, and cultural heritage objects. 
The data was valuable and well maintained, but the platform had been designed through a web application, with no interoperability with external research infrastructures.

The Data Was Good. The Architecture Was Not Designed to Share It.

Most research platforms are not built to fail. They are built to solve a specific problem, at a specific point in time. The data inside them is often excellent but the architecture around them, less.

INFRA-ART worked well enough: a Django backend, a solid PostgreSQL database, thousands of spectral records collected from paintings, archaeological artifacts, and cultural heritage objects.

The European Commission has measured this pattern: over 60% of publicly funded research data in the EU stays locked inside the team that created it. EOSC alignment and FAIR compliance are now conditions for qualifying for the next round of European funding, not recommendations.

What FAIR Compliance Actually Requires

The FAIR acronym: Findable, Accessible, Interoperable, Reusable, appears frequently in policy documents. It appears far less frequently in engineering specifications, which is part of why so many platforms claim compliance without achieving it.

In practical terms, FAIR compliance requires five things to be true simultaneously:

• Persistent identifiers assigned to every dataset, so records can be cited reliably across systems
• Structured metadata schemas aligned with EOSC or Dublin Core standards
• A public API with consistent, documented responses
• Standardised export formats: JSON, CSV, RDF
• Access policies that are documented and findable by external parties

Each of these is a concrete engineering requirement, not a policy aspiration.

A platform that satisfies four out of five is not FAIR compliant. It is close, which is a different thing entirely.

The Architecture: Separating What Should Not Be Mixed

When we reviewed the existing system, the data was not the problem. The data was the asset. The problem, rather, was that the architecture only supported access through the web application. No other systems could integrate with it programmatically.

No public API. Metadata in formats that external harvesters could not read. Infrastructure tied to institutional servers with an uncertain operational future. The data was there. The means to reach it were not.

Consequently, our starting point was to treat interoperability as a design constraint, not a post-launch improvement. That decision shapes everything that follows. It means the first weeks of a project move more deliberately, and the last weeks do not involve emergency retrofitting.

Separating the Data Layer from the Content Layer

Research records and editorial content have different requirements. A spectral database record needs to be fast, consistent, and machine-readable. A page describing the project, on the other hand, needs to be editable by a non-technical administrator without involving a developer.

The solution was to route them separately. Scientific data flows through direct PostgreSQL queries, bypassing the CMS entirely for performance-critical operations. Editorial content lives in Strapi, giving administrators independent control over pages and updates. Each layer has a clear responsibility and teams can maintain or update it without affecting the other.

Choosing Infrastructure That Meets Sovereignty Requirements

Beyond the application architecture, the hosting environment also required a deliberate decision. EU data sovereignty requirements mean research data must reside on EU-based infrastructure and comply with GDPR.

The Public API Is Not Optional

A point worth stating directly: without a public API, FAIR compliance remains an intention, not a capability.

External repositories cannot retrieve your data. Harvesting tools cannot index it. Partner institutions cannot integrate with it programmatically. Consequently, the quality of the underlying data is irrelevant if no stable, documented interface exists to access it.

We built the INFRA-ART API around consistent JSON responses across all endpoints, versioned documentation accessible to external developers, and rate limiting that protects against abuse without restricting legitimate access. Scientific data and editorial content serve different audiences with different performance requirements, so we routed them through separate API paths accordingly.

Results

In Summary

Research platforms do not usually fail because of bad data. They fail because the architecture was built for a different purpose and never updated to reflect what the data became worth.

INFRA-ART had that data. What it needed was an architecture capable of making it available to the people and systems that could use it.