Interoperation

The goal of Interoperation is that data can flow between computational units regardless of the programming language each unit uses or the infrastructure it runs on. Units meet only at their boundaries, and if those boundaries use language-agnostic formats and standard protocols, no unit ever needs to know what its neighbour is written in.

This pillar is where the approach touches the FAIR principles most directly: interoperability of data is realised here through concrete format and protocol choices at unit boundaries. Four questions identify the right strategy for your study.

What is the nature of the data being exchanged? Tabular, hierarchical, or multi-dimensional arrays? And is it numerically heavy? The format choice follows from the answer, and Int1 walks through it.

Do all units run locally, or does the study span compute locations? As long as units share a filesystem, exchange through files and nothing more. When the study spans a laptop and a cloud instance, or two clusters with no shared mount, you need remote storage. Int2 covers both and when to switch.

What is the pattern of data exchange? One handover per unit, or repeated exchanges while units run? High-frequency exchange, the defining trait of Pattern C, is a different problem from bulk handover and is handled in Int3.

How might the interoperation needs grow? More data volume pushes you toward binary formats and chunked access (Int1, Int3); more heterogeneous units make the language-agnostic boundary rule of Int1 non-negotiable from day one.

The paper's rule of thumb orders the whole pillar: start with CSV or JSON exchanged through the filesystem. Move to binary formats (HDF5, Zarr, Parquet) as the data becomes primarily floating-point. Switch to remote storage when the study spans separate infrastructures. Adopt an HTTP client-server setup only when units need to exchange data at high frequency during execution. Each step adds capability and complexity, so take a step only when the study actually needs it.