This document reflects the current state of an ongoing conversation on interoperability and AI-readiness among OGC members and partners. It draws on work that OGC has carried out with its members across pilots and testbeds, and in EU-funded research projects, and on the wider debate about the future of spatial data infrastructures and geospatial ecosystems. It is offered as a proposal and a basis for discussion, a shared and evolving reference rather than a normative position or the view of any single organization.

OGC Document #: 26-050

Version 1.0, 12 August 2026

Cite as: Simonis, I., Atkinson, R., Zaborowski, P., Villar, A., Toscano, M., Noardo, F. (2026) Building Blocks for Interoperable, AI-Ready Geospatial Data: The Next Chapter of Spatial Data Infrastructures and Geospatial Ecosystems. OGC Document 26-050. Open Geospatial Consortium, doi: https://doi.org/10.62973/26-050

Acknowledgements

First and foremost, the research behind this document was made possible by funding from OGC strategic members and the European Commission¹. The framework presented here grew out of several EU-funded research projects as a collaborative effort between OGC and OGC member organizations, and was further explored and refined in OGC Pilot and Testbed activities. The EC-funded SeaDOTs project provides the worked examples used throughout this document, and SeaDOTs itself reused many of the building blocks resulting from other OGC standardization efforts as well as the ILIAD Digital Twin of the Ocean project. All these projects were carried out with many partners, and what is presented here reflects their combined work rather than any single contribution. Nevertheless, the content of this document reflects only the authors' view. It is not an official OGC standard or position.

A development of this kind cannot be produced by any one group working alone. It depends on continuous discussion and exchange among the many parties involved: the users who state what the data must answer, the researchers who define the concepts, the developers who build the tools, and the portal and platform operators who publish and serve the results. That sustained conversation across all of these perspectives is what turns a collection of standards into a working, shared framework like the one documented here.

Individual parts of the approach were advanced and tested through OGC Pilot and Testbed activities. In that context, OGC gratefully acknowledges Natural Resources Canada, the US National Oceanic and Atmospheric Administration, and the US National Geospatial-Intelligence Agency, the United Kingdom Hydrographic Office, and above all the European Space Agency (ESA) and the US National Aeronautics and Space Administration (NASA). Through their strong support for open-science research, ESA and NASA in particular have contributed substantially to the present understanding of what building blocks are, how they should be shaped, and what functions they can serve.

OGC also acknowledges the United States Geological Survey, which commissioned work on the future of spatial data infrastructures that has helped frame the questions this document addresses.

OGC also gratefully acknowledges the United States Geological Survey (USGS) and the General Authority for Survey and Geospatial Information of Saudi Arabia (GEOSA). Both have commissioned OGC to explore and help define the future of spatial data infrastructures, a future now increasingly described as the geospatial ecosystem and one of the central forces driving innovation across the field. OGC works closely with both organizations on this agenda, and their leadership in commissioning and guiding the work has been instrumental in advancing the shared understanding that this document builds on.

Finally, OGC thanks its members and sponsors, whose sustained engagement and support have carried this work forward and brought the community a good deal closer on the shared journey toward optimal interoperability and AI-readiness.

Executive summary

Across the geospatial community, more and more value depends on data being usable not only by the team that produced it, but by other people, other organizations, and increasingly by software and AI agents. Environmental observations, model outputs, statistics, and survey data arrive from different communities in different structures, described differently and named with different vocabularies. Left as they are, they cannot easily be combined, compared, or trusted, and a machine arriving at them has to guess what they mean. This document sets out a practical way to close that gap.

The central design choice is deliberate. Rather than forcing every dataset into one common schema, we need a framework that keeps each community's structure and connects those structures through shared discovery and provenance mechanisms. In our proposed framework, four mechanisms do the work. Data profiles describe how data is structured. Catalog profiles describe how data is found and linked. Controlled vocabularies describe what terms mean. OGC building blocks package all of this into reusable, testable components. The building block is the piece that ties the others together, and much of this document explains what it is and why it makes data interoperable, verifiable, and ready for automated use.

To keep our suggested framework concrete rather than abstract, it is illustrated throughout with a running example: SeaDOTs. SeaDOTs, short for Social-Ecological Ocean Management Applications with Digital Ocean Twins, builds digital twins of the ocean that bring physical, ecological, and socio-economic information together to support marine spatial planning, adaptive management, and policy decisions. It works through three demonstrators in the Norwegian North Sea, the southern North Sea, and the Baltic Sea. Each one studies an offshore wind farm and its effects on nature, communities, and local economies, and each publishes its results through the European Digital Twin Ocean.

The challenge. A digital twin of the ocean must combine data from very different communities. Ocean physics, biology, fisheries statistics, social surveys, and model outputs are each structured differently, described with different metadata, and named with different vocabularies. Left as they are, they cannot easily be combined, compared, or trusted, and the record of how a model result was produced is rarely captured in a way that a later user, or a machine, can follow. Making these inputs, outputs, and their lineage interoperable and reusable is the problem this framework addresses.

The SeaDOTs examples show how the framework handles data that goes into a Digital Twin, the products that come out of it, and the record of how those products were made. The framework itself is general, and nothing in it is specific to the ocean domain. We used a Digital Twin example, because Digital Twins as well as Data Spaces are two settings where the need is especially visible, but the same approach works for any data integration challenge and serves any organization that wants its data to be found, understood, trusted, and reused beyond its own walls.

A word on how this document should be read is important, because it goes to the heart of why it was written. This is a proposal and a basis for discussion, not a normative OGC position or a specification that anyone is required to follow. Nothing in it is new or independent research surfacing for the first time. Its purpose is the opposite. It draws together the many initiatives, pilots, testbeds, and community conversations of recent years and brings the current state of that shared discussion to a single, coherent point. It is offered to be read, challenged, and improved by the community it draws on, and it is expected to evolve as that conversation does.

The framework is also honest about its limits. It shows how building blocks apply to the inputs, outputs, and lineage around a workflows. It does not yet address the running, coupled system in full. That boundary, and the work still open, are set out in the status section, so that the reader knows exactly what is proposed, what is already demonstrated, and what remains to be worked out together.

Figure 1 brings the whole argument into a single view. Across the top it moves from the problem to the solution to the outcome. On the left is the fragmentation just described, where data from different communities cannot be held by any single common schema. In the middle is the response, an OGC building block that binds structure, discovery, and meaning into one versioned, testable package. On the right is the result, an ecosystem in which every product carries its full provenance and describes itself well enough for people and software agents to use without guessing. Beneath these three panels runs the governed check-in workflow, the path by which data enters the framework, is matched against existing blocks, is reviewed, transformed, strictly validated, and finally published and registered. The two panels at the foot of the figure show why the approach is powerful. On the left, two sources with different structures are tied to one meaning through a shared vocabulary block, so a consumer can use either in place of the other. On the right, two unrelated datasets share a single structural block while keeping their own meaning, so fixing that block once corrects both files. The sections that follow open up each of these parts in turn.

1 Introduction

1.1 What this document is and what it does

Across the geospatial community, the same problem keeps returning in new forms. Environmental observations, numerical model outputs, biodiversity information, socio-economic statistics, indicator models and digital twin workflows come from different scientific communities. They use different data structures, different metadata conventions and different vocabularies. Left as they are, they cannot easily be combined, compared or reused, and increasingly they cannot be consumed reliably by automated and AI-driven tools either.

This document sets out a practical framework for making such data interoperable and machine-actionable without forcing every dataset into a single grand schema. Its purpose is to define a small set of shared, reusable interoperability contracts, and to explain how any dataset can meet the contract that fits it. Our suggested approach is built on OGC building blocks (and profiles and registers), and it applies as much to a single dataset that someone wants to publish as to a large collection that has to be integrated across organizations.

Seen this way, the document is best read as a practical roadmap for anyone who wants to make data genuinely usable by others, and increasingly by software and AI agents, rather than only by its original producer. Digital twins are one prominent setting for this, because they consume and produce many kinds of data and depend on clear provenance. Data spaces are another, because they exist precisely to let independent participants share and reuse data under common rules and within trusted environments. The need, however, is far more general. Any organization that wants its data to be found, understood, trusted, and acted upon by parties and systems it does not control faces the same problem, and the building-block approach set out here is a way to solve it once and reuse the solution wherever the data has to travel.

The suggested approach is not the work of one project or one author. It reflects the current state of an ongoing conversation among OGC members and partners, developed over many years across pilots, testbeds and collaborative innovation initiatives, and in a series of research and innovation actions. The wider debate on the state and future of spatial data infrastructures and geospatial ecosystems has fed directly into it. What is written here is best read as a shared, evolving reference that many organizations have helped to shape.

This document is the practical member of a set of three. It shows how interoperable, AI-ready data is built in practice. The background article "Declared Meaning: Why AI-Readiness Is a Data Architecture Problem" makes the case for why this is a matter of data architecture rather than of any single standard, and the OGC paper on a machine-interpretable standards ecosystem, document 26-021, sets out the conceptual framework that both draw on; it is explicitly a proposal for discussion rather than a specification. The chapters that follow are best understood as one worked instantiation of that architecture, made concrete with a public example.

To keep the framework concrete rather than abstract, it is illustrated throughout with a running example: SeaDOTs, a research project building digital twins of the ocean. SeaDOTs is a useful setting because it has to combine exactly the kinds of data described above, and because its work is public. Its three demonstrators, in Germany, Norway and Sweden, and its target platforms, the European Digital Twin Ocean known as EDITO and, optionally, the European Open Science Cloud known as EOSC, supply the worked examples used in later chapters. The framework itself, however, is general, and nothing in it is specific to the ocean domain. SeaDOTs integrates environmental observations, numerical model outputs, biodiversity information, socio-economic statistics, indicator models and digital twin workflows. These assets come from different scientific communities. They use different data structures, different metadata conventions and different vocabularies. Left as they are, they cannot easily be combined, compared or reused.

This document uses the interoperability framework developed for the project to explain how data of different types and natures, with different origins and governance regimes, can be integrated into a digital twin and made AI-ready. The purpose of the framework is not to invent a single grand schema that everything must fit. Its purpose is to define a small set of shared, reusable interoperability contracts, and to explain how each dataset can meet the contract that fits it.

All three demonstrators study offshore wind farms. The Norwegian case assesses the impact of an offshore wind farm on the community and environment of Utsira Island. The Swedish case explores how an offshore wind farm affects the fishing community and economy on the Baltic coast north of Gotland. The German case looks at a multi-use offshore wind farm that also hosts low-trophic aquaculture.

1.2 Who should read this, and what you will get from it

This document is written for two kinds of readers at once, and it is arranged so that each can take from it what they need.

The first is the strategic reader: the policy lead, the agency director, the program manager, or the planner who is shaping how an organization, a nation, or a community will share and use data in the years ahead. Readers who are charting the future of spatial data infrastructures and the emerging geospatial ecosystem will find here a clear account of where interoperability is heading and why, expressed in plain language and without requiring any prior familiarity with the underlying standards. For this reader, the opening chapters are the heart of the document. They explain the problem that makes data hard to combine, the idea of the building block as the unit that solves it, and, through two concrete worked examples, why separating structure, meaning, and provenance is the design choice that pays off. A strategic reader can stop there and still come away with a firm grasp of the approach and what it implies for the future of spatial data infrastructures.

The second is the practitioner: the data manager, the architect, the standards specialist, or the developer who has to put the approach into practice. For this reader, the later chapters and the appendices carry the detail: the canonical formats, the controlled vocabularies, the catalog and provenance model, the governed check-in workflow, and a full worked walk-through of a real building block, backed by the standards stack, the building-block index, and the vocabulary, namespace, and tool registries.

No prior knowledge of building blocks, of any particular domain, or of the example project used throughout is assumed. A reader who works through the document should come away understanding what a building block is, what problem it solves, how the pieces fit together, and how to begin applying the approach to their own data. The examples happen to come from digital twins of the ocean, because that setting has to combine unusually diverse data and because its work is public, but nothing in the approach is specific to that domain.

The audience is therefore deliberately wide. If you produce, steward, or publish data of any kind, and you want it to be found, understood, trusted, and reused by people, systems, and AI agents beyond your own team, this document is written for you. You do not need to work on digital twins or data spaces to benefit from it. Those are simply two settings where the need is especially visible, and the same building-block approach applies equally to a national mapping agency, a statistical office, a research group, or a single team publishing one dataset well.

1.3 Scope of this version

This version shows how building blocks apply to three things. First, the inputs to a digital twin, meaning the observations, forcing data, parameters, and reference datasets a simulation model that is part of the digital twin consumes. Second, the outputs, meaning the products a model run generates. Third, the lineage, meaning the record that connects an output back to the model, the parameters, and the input data that produced it.

This version does not yet demonstrate building blocks for the twin as a living system. A digital twin, in its fullest sense, is a running, coupled set of models that stays connected to the real system it represents and feeds information back and forth. The framework does not standardize how the models run, how they are coupled, or how they exchange state at runtime. What it standardizes is the data and provenance envelope around each model run.

This boundary is deliberate and appropriate for the current stage of discussion. Getting the inputs, outputs, and lineage right is the foundation on which the running twin can later be described. The framework is a living document. A future version is expected to apply the same building block approach to the running twin itself, and Section 12 records this as a planned direction.

1.4 What the framework is, and what it is not

The framework captures the principles and workflows that make data reusable. It covers data inputs and outputs, the processes and workflows that matter for reuse, the vocabularies of model properties and indicators, and the relationships between indicators.

The framework defines interfaces, not operational pipelines. It says how data should be shaped and described so that systems can exchange it, but it does not itself run the connections between those systems. For example, Norwegian biodiversity observations are already published into the global OBIS² system. If a scenario needs richer detail than OBIS carries, the framework defines the contract for acquiring and transforming that richer source, and it captures the acquisition and harmonization steps as reusable tools.

2 The problem: why data is hard to combine

The same difficulty appears in almost every field. Suppose you are building a decision-support tool that has to bring together several datasets produced independently by different groups. Consider, for example, a tool for planning an offshore wind farm. It might need ocean temperature and salinity from a numerical model, catch statistics from a fisheries agency, seabed biodiversity from a national survey, employment figures from a statistics office, and the results of a simulation that ties these together. Whatever the domain, each of these arrives in its own form.

The model output is a multidimensional grid with dimensions, variables, and a coordinate system. The biodiversity data needs taxonomic identifiers to say which species were observed. The statistics come with aggregation dimensions and code lists. The social survey follows a complex internal data model with its own vocabulary. The simulation carries provenance describing how it was run. Each of these is reasonable on its own, and each reflects how its own community actually works.

The tempting solution is to define one common schema that everything is converted into. In practice, this fails in one of two ways. Either the single schema forces each dataset into a shape it does not naturally have, which loses information the source community depends on, or the schema grows into a giant superset in which most fields are meaningless for any given dataset, which no one can validate in a meaningful way. Section 5 shows both failure modes with concrete examples.

This framework takes the other path. It keeps multiple data profiles, one family per kind of asset, and it maintains interoperability through shared discovery and provenance mechanisms rather than through a single schema. The rest of this document explains the pieces of that approach.

3 The core idea: building blocks and four mechanisms

3.1 What a building block is

An OGC building block is a small, reusable, self-contained package that captures one interoperability contract³ completely. A single building block can contain a schema that defines the JSON structure of some data, a context that maps each field to a precise meaning on the web of linked data, a set of example records, validation rules that check whether a dataset actually complies, and, where relevant, transformation rules for converting a source into the required shape. It also carries human-readable documentation.

The value of packaging all of this together is reuse. A building block can be published once and then referenced by many datasets and by other building blocks. When one part of the design changes, only the relevant building block changes, and everything that depends on it can be revalidated automatically. A building block is versioned, so improvements can be made without silently breaking the datasets that rely on earlier behavior. In short, a building block turns an interoperability agreement into a testable software artifact rather than a paragraph in a specification that everyone interprets slightly differently.

A project rarely needs to invent all of its building blocks from scratch. Many are already published by OGC, by other initiatives such as the ILIAD digital twin of the ocean project, and by the OGC Open Science work, and a project defines its own only where a genuine gap exists. Blocks are not only reused but composed. A block can aggregate others, refine or extend one to cover a case it was not written for, or substitute one for another, and these are the same formal operations used across the wider building-block ecosystem.

3.2 Four mechanisms, four questions

The framework achieves interoperability through four complementary mechanisms. Each answers a different question, and keeping them separate is what makes the whole approach flexible.

Data profiles define how information is structured. They answer the question: how is this data shaped and in what format is it exchanged? Catalog profiles define how an asset is described, found, linked, and reused. They answer the question: how is this asset discovered? Controlled vocabularies define what the terms in the data and metadata actually mean. They answer the question: how is this information interpreted consistently by different people and systems? Building blocks provide the reusable implementation artifacts, including the schemas, examples, validation rules, and transformations, that put the other three into practice. They answer the question: how is interoperability implemented and validated?

A single dataset can take part in all four at once. It can conform to a data profile, be described through a catalog profile, reuse terms from several vocabularies, and be implemented using one or more building blocks. Because the four are separate, a change in storage format, in metadata model, or in vocabulary can be handled on its own without disturbing the others.

3.3 The interoperability layers

The same idea can be seen as a set of layers, from the business question at the top to the technical protocols at the bottom. Each layer has its own concern and its own mechanism, here explained using digital twin of the ocean example SeaDOTs provides.

The framework does not try to standardize all project data into one schema. It defines reusable interoperability contracts suited to specific classes of assets. Data profiles describe structure, vocabularies describe meaning, catalog profiles describe discovery, and building blocks bind them together and can also describe implementation patterns such as transformations. Together they provide interoperability across very different assets.

4 How data flows through the framework

Before looking at the mechanisms in detail, it helps to see the whole path a piece of data takes. Raw data enters the framework, is profiled and harmonized, is described in the catalog, is validated against the relevant building blocks, and is finally published to a target platform where it can be discovered and reused. The sections that follow make this concrete with the example of a digital twin run, but the same path applies to any data that has to be prepared for sharing and reuse.

4.1 What a digital twin execution produces

In our SeaDOTs example, each demonstrator runs a different kind of model. Though all demonstrators show the evaluation of offshore wind farms, the data and applied models vary to address the different needs and motivations. The German case couples a numerical ocean model with aquaculture yield in a multi-use scenario. The Swedish case uses agent-based models of fisheries on the Swedish coast. The Norwegian case maps fuzzy-cognitive relationships for wind-farm investment decisions. Despite the differences, every run can be understood in the same simple way. A simulator takes a set of input data and a set of control parameters, and it produces a set of output variables.

The outputs, such as a predicted yield time series, local employment, tons of fish caught, or a biodiversity measure, are the variables that feed the project’s indicators. From many runs, the project derives generalized or equilibrium relationships that support decision-making. This document focuses on the interpretable data at the level of a single run, meaning its inputs, its outputs, and the way they are linked.

4.2 Linking inputs, outputs and the model

The connection between an input, an output, and the model that ties them together is the execution record. One execution is one run of one workflow. It records which model was used, which inputs and control parameters went in, and which products came out. This record is what makes a result reproducible and auditable, because a reader can trace any product back to the exact run and inputs that produced it.

5 Two worked examples: why separate mechanisms beat one schema

The separation of vocabulary, schema, and building block is not just tidy in theory. Two real examples show concretely why collapsing them into a single artifact would fail. These two examples are the heart of the framework, and a reader who understands them understands the whole approach.

5.1 Example one: the same real-world quantity, two structures, one meaning

The Norwegian reef-effect calculation needs a value for benthic biomass⁴ density for each affected species. Two independent monitoring programs can supply this value, MAREANO and IMR, but they cannot share a single structure.

The MAREANO program reports values per species inline, as an array over a mapped area and a sampling period, because that is how a MAREANO survey record is built. The IMR program reports a single density value with an explicit uncertainty and an ICES⁵ area annotation, because that is how the IMR regional baseline series works. A single shared schema would either force one program’s data into a shape it does not have, or become a bloated superset in which most fields are meaningless for any given record. This is exactly the failure mode described in Section 2.

What makes the two sources interchangeable as inputs to the reef-effect calculation is not a shared structure. It is the vocabulary layer. Both programs are bound to one abstract concept, baseline benthic biomass density, defined once. Each program provides a narrower, more specific version of that same concept. Because each program’s fields are mapped to the same abstract meaning, the reef-effect calculation can consume either source without needing to know which program supplied the number.

Three separate building blocks make this arrangement reusable and independently maintainable. One is a vocabulary building block that defines the shared abstract concept, baseline benthic biomass density, together with its two narrower bindings; i.e., the MAREANO concept and the IMR concept are both narrower kinds of that abstract concept. The other two are schema building blocks, one for MAREANO and one for IMR. Each carries its program's data structure, the shape of a MAREANO survey record or an IMR baseline record, together with a small mapping, called the context, that says which concept each field corresponds to. This field-to-concept mapping lives inside the schema building block itself, not in the vocabulary building block.

This division is exactly what buys the independence. MAREANO's schema block can change its survey fields without touching IMR's, because IMR's fields are described entirely inside IMR's own block. A new monitoring program simply adds one more schema building block, which carries that program's field mapping, and one more narrower binding in the vocabulary block, and none of the existing blocks change. The reef-effect calculation, which only ever refers to the shared abstract concept, does not change either. That independence would be impossible if benthic biomass density were locked into one hard-coded schema. The two schemas do share a common envelope, the general observation shape, but their detailed payloads cannot be merged without either dropping IMR's mandatory uncertainty or inventing an empty field on IMR records that was never captured.

5.2 Example two: one structure, two unrelated meanings

Example 1 showed two data sources that were built differently but meant the same thing. Example 2 shows the mirror image. Here, two datasets are built the same way, yet they mean completely different things. Reading the two examples side by side is the quickest way to see why structure and meaning have to be handled as separate concerns.

The two datasets come from different demonstrators and different scientific worlds. One is the output of the Swedish digital twin, a simulation of the herring and sprat fishery. The other is a German harvest scenario, a time series of modeled harvest values. In terms of content, they have nothing to do with each other.

What they do have in common is how their files are physically laid out. Both are stored as GeoParquet, and both describe that layout in the same way, through a single shared building block called the GeoParquet header envelope. This envelope is purely structural. It records things like the file name, where the data came from, the list of columns and their data types, and how the geometry and its coordinate reference system are declared. It says nothing about what any particular column actually means. Because both datasets point to this one shared building block instead of each defining its own layout, any standard GeoParquet tool can open either file without special handling.

The meaning of the two datasets lives somewhere else entirely, inside each dataset's own vocabulary. The Swedish output uses the SeaDOTs fishery indicator terms. The German scenario uses its own harvest terms. A column in one dataset has no equivalent in the other, and nothing in the shared envelope pretends otherwise. In short, the structure is shared while the meaning is kept apart.

This separation is not just tidy; it pays off in practice. At one point, the shared envelope had a defect in the way it recorded the coordinate reference system, which could make a file unreadable by real tools. Because the rule that guards against this lives in the shared building block, fixing it once corrected both datasets at the same time. Neither dataset's own vocabulary had to change, and the repair for one did not disturb the other.

Taken together, the two examples show that structure and meaning are independent of each other. Two datasets can share a meaning without sharing a structure, as in Example 1, and they can share a structure without sharing a meaning, as here. This is exactly why the framework keeps schemas, vocabularies, and building blocks as separate, reusable pieces. A single common schema would fuse structure and meaning into one, and it would break the moment a new dataset needed one of them but not the other.

5.3 The general pattern

The two examples point to a single lesson, which can be summarized as follows.

The two questions are independent. Whether two datasets share a file structure and whether they share a meaning can be answered separately, which gives four combinations. Example 1 sits in the top-left, where the meaning is shared but the structure differs. Example 2 sits in the bottom-right, where the structure is shared but the meaning differs. Building blocks let a project reuse whichever axis is shared: a vocabulary building block for meaning and a schema building block for structure, which a single common schema could not do.

5.4 The payoff: full provenance and easy reuse

Keeping schemas, vocabularies and building blocks as separate, reusable pieces takes more care up front than writing a single schema. As a close to this chapter, it is worth stating plainly why that care pays off. The benefits are easiest to see from two perspectives: what building blocks give you when you describe data with them, and what they give you when a new dataset needs to reuse them.

The first perspective is description and provenance. When a dataset is described through building blocks and registered in the way this chapter and the check-in workflow in Section 9 set out, the result is a complete provenance profile, not just a file. The record captures which source the data came from, which building blocks governed its description, which transformation turned the source into its compliant form, which fields were mapped to which vocabulary terms, and what was finally produced. Because all of this is written down against the building blocks that governed it, anyone can later trace exactly what was done at each step, how it was done, and on what basis. A building block is therefore more than a schema. Together with the catalog and provenance records, it makes the whole description auditable and reproducible.

The second perspective is reuse when a new dataset arrives. If the building blocks that other groups have already built are public, they serve as worked examples that show how to describe your own data, and the two examples in this chapter map onto the two situations you are most likely to meet.

In the first situation, your dataset measures the same real-world quantity as an existing one. You can then declare that your data also maps to the shared abstract concept, and you can take the existing building blocks as a template. Seeing how others mapped their fields to that concept is the quickest way to work out how to map your own data to it, rather than modeling it from scratch.

In the second situation, your dataset shares a structure rather than a meaning. If it is another GeoParquet output, you reuse the same GeoParquet header building block, which already describes the complete form of your file. You then look at how other groups described their content in their own blocks, and you define an analogous block for your content, reusing their approach as a pattern.

In both situations, the two perspectives come together. The moment your new building block is used, the provenance benefit from the first perspective applies to your data as well, so that everyone who later encounters it can again trace exactly what was done, when, and how. Reuse lowers the effort of describing a new dataset, and it does so without giving up any of the transparency. That combination is what a single common schema cannot offer, and it is the reason the framework is built from building blocks in the first place.

6 Data profiles and canonical formats

SeaDOTs data falls into a few broad categories. Each has a preferred storage format for efficiency and a canonical exchange format for interoperability. For every category, the project registers a catalog record, based on the OGC API Records model and profiled for STAC for data and for DCAT-AP for open-science discovery.

Because the categories are genuinely different in structure, a single profile would either lose detail or become unworkable. Multidimensional model outputs need dimensions, variables, and coordinate systems. Biodiversity observations need taxonomic information. Statistical datasets need aggregation dimensions and code lists. Social survey data follows complex internal models. Workflows need provenance and execution metadata. The project therefore uses several profile families while keeping common discovery mechanisms through STAC, OGC API Records and DCAT.

6.1 Multidimensional spatio-temporal data

This category covers gridded and array data such as model outputs and reanalysis, where variable values are mapped onto a predefined spatial and temporal scheme. NetCDF with the Climate and Forecast conventions is the common legacy and source format, and it is well understood. The preferred cloud-native storage format on EDITO is GeoZarr, which is chunked for efficient access and stores its metadata as JSON, which makes extensions easier.

Typical examples include Baltic Sea physics from Copernicus Marine, Utsira wind measurements (see Utsira Nord Offshore Wind Area and Utsira Nord Metocean and Wind Dataset), and DWD reanalysis. The catalog profile for this category is named catalog-data-multidim.

6.2 Tabular and statistical data

Tabular data usually arrives as CSV or plain text, sometimes following a column convention such as SeaDataNet. SeaDOTs prefers semantically rich formats in which the meaning of each column is explicit and linkable, such as GeoParquet, GeoJSON, and CSV on the Web. EDITO supports GeoParquet and CSV, so these are the preferred targets.

Typical examples include Eurostat fishery and tourism statistics, ICES catch data, HELCOM marine protected areas, Utsira observation tables and social survey data. The catalog profile for this category is named catalog-data-tabular. Dataset-specific GeoParquet profiles should reference the shared GeoParquet header building block rather than redefining the envelope, as explained in Section 5.2.

A note of practical caution is worth recording. The coordinate reference system (CRS) stored in a GeoParquet file should be encoded as a valid and complete PROJJSON object, as defined by the GeoParquet and PROJ specifications, rather than as a shorthand representation that merely resembles JSON. Using incomplete CRS definitions can lead to interoperability issues and inconsistent coordinate interpretation across software environments. The shared header building block previously discussed now constrains this, and the conversion tools emit correct values, but a produced file should always be sanity-checked by opening it with a real reader before it is trusted.

6.3 Graph and knowledge data

Some artifacts, such as the fuzzy-cognitive models that express relationships between variables and indicators, are naturally graph data. When they arrive as plain text or CSV, their rich version is converted into canonical RDF.

Typical examples include the Ostrom social-ecological system model for offshore wind governance, composite indicators and Norwegian relationship matrices. The catalog profile for this category is named catalog-data-graph.

6.4 Workflows and applications

In an open-science setting, data is linked to the workflow that generated it and to the input data and control parameters that fed it. The connecting point is the experiment, meaning one execution. SeaDOTs represents these relationships at the catalog level. The project does not standardize how models are executed, although some run on EDITO and comply with its requirements.

From an interoperability and reuse point of view, two aspects matter for a workflow. First, its metadata, which describes data requirements, owner, license, and provenance. Second, its technology stack, which determines whether the application can run on EDITO or only elsewhere. These assets are represented at the catalog level with references to the code base and to any published papers.

6.5 From Standards to Building Blocks

This chapter makes the scale of the problem visible. Running a digital twin means agreeing on storage formats, exchange formats, metadata models and controlled vocabularies, and doing so separately for gridded data, tabular data, graph data and workflows. On their own, these standards are only a menu of possibilities. Each one can be read, interpreted and combined in more than one way, and two teams working from the same list can still end up with data that does not fit together.

This is where building blocks earn their place. For each category, a building block fixes one specific, tested combination of these standards and writes it down as a concrete artifact. It records, for instance, that multidimensional data is stored as GeoZarr, described with the STAC datacube extension and CF attributes, and named with CF standard names from the NERC server, and it captures that decision as a schema, a set of examples and validation rules rather than as prose that each reader interprets anew.

In this way building blocks turn the long list of standards in this chapter from something every project has to reassemble by hand into something that can be referenced, validated, reused and versioned. They are the layer that makes the standards operational, so that the many agreements a digital twin depends on are applied the same way every time and can be checked automatically rather than taken on trust.

7 Controlled vocabularies

7.1 Reusing authoritative vocabularies

Profiles ensure that data is structured consistently. Vocabularies ensure that the terms in the data mean the same thing to everyone. Because SeaDOTs combines environmental, ecological, social and economic data, several domain vocabularies are needed. In each case, the project reuses an authoritative external vocabulary wherever one exists.

Environmental variables such as temperature, salinity, wave height, and wind speed are described with the CF standard names, published through the NERC Vocabulary Server, and harmonized with SeaDataNet vocabularies. Biodiversity and ecosystem data uses Darwin Core for observation terms, WoRMS⁶ for taxonomic identifiers, and OBIS⁷ for exchange. Statistical and socio-economic data uses SDMX for statistical structures, Eurostat code lists for regional and economic classifications, and ICES code lists for fisheries reporting. Provenance and workflow metadata uses PROV-O, DCAT and the OGC Open Science building blocks.

Some social-ecological concepts that SeaDOTs needs are not covered by any existing vocabulary. Examples include social acceptance indicators, fisheries displacement indicators and socio-ecological relationship models. These are maintained in project-specific vocabularies and indicator registries, with mappings to external standards kept wherever possible, so that the project does not create isolated terms with no connection to the wider web of data.

7.2 How building blocks attach meaning to the data

As with formats, vocabularies deliver their value only once they are attached to real data, and that is the function building blocks perform here. A vocabulary on its own is a shared list of agreed terms. It says what temperature, a taxon identifier or a statistical region means, but it does not by itself say which field of which dataset carries that meaning. The building block is where the connection is made. Inside each building block a small mapping, the JSON-LD context introduced in Section 5.1, binds the dataset's own fields to the authoritative terms described in this chapter, so that a column named in a project's private way is tied unambiguously to a CF standard name, a Darwin Core term or an SDMX code. Because this mapping lives inside a building block alongside examples and validation rules, the meaning is not merely asserted in prose but can be reused by the next dataset, checked automatically, and read back as linked data once the dataset is published. The same building block also carries the honest exceptions. Where SeaDOTs needs a concept that no external vocabulary yet covers, the building block records it as a candidate definition with links to the closest existing terms, rather than inventing an isolated label. In short, the vocabularies in this chapter supply the meaning, and the building blocks are what fasten that meaning to the data in a form that can be reused and verified.

One further point completes the picture, and it matters as much as the mappings themselves. Attaching meaning is not only about declaring that two fields mean the same thing. It is sometimes about declaring, explicitly, that two things which look alike are not the same and must not be combined. A building block can therefore record a declared non-correspondence, for example that a surface skin temperature and an air temperature two meters above the ground are different quantities despite sharing a label, so that a consumer, and an automated agent in particular, is told to keep them apart rather than left to average them by accident. A stated incompatibility is worth as much as a clean mapping, because a machine can act safely on it, whereas an unstated one is exactly the trap that produces confident, wrong answers. The companion article "Declared Meaning" develops this point in full.

8 Catalog profiles and provenance

This chapter builds up in four steps, from the shape of the catalog to a concrete specification. Section 8.1 shows how the catalog is organized, by demonstrator and by the role each record plays. Section 8.2 introduces the basic elements of a single run and how they relate, in plain terms. Section 8.3 shows how those elements are encoded in real standards, what each link means, and where the activity fits. Section 8.4 is the level below that, the concrete profile for each record type, namely which standard it is built on, which fields a compliant record must carry, and how it is published for EOSC. Taken together, the earlier sections explain the model and the later ones turn it into the checklist that the check-in workflow in Section 9 enforces, with the DCAT and GeoDCAT-AP serialization as the bridge that makes SeaDOTs records discoverable across the wider open-science landscape.

8.1 Catalog hierarchy

Data profiles describe the content of an asset. Catalog profiles describe the asset itself, so that it can be discovered, its provenance tracked, and its records exchanged between EDITO, EOSC, and external catalogs. The catalog is STAC-first for data, because that is what EDITO expects, and it is aligned to OGC API Records for applications, following the structure of the OGC Open Science building blocks. For EOSC, these records are linked to the DCAT and GeoDCAT vocabularies.

Catalog records can represent data, an application or workflow, and an execution. Within the SeaDOTs catalog, these are organized per demonstrator.

/Catalogs/SeaDOTs/
├── germany/
│   ├── workflows/{workflow_id}      OGC Records item
│   ├── experiments/{experiment_id}  STAC item
│   ├── inputs/{input_id}            STAC item, per type
│   └── products/{output_id}         STAC item, per type
├── norway/
│   └── ...
└── sweden/
    └── ...

The tree is read from the top down. The catalog is divided first by demonstrator, with a branch for Germany, Norway, and Sweden, and then by the role each record plays inside that branch. The same four roles appear everywhere. Workflows describe the reusable models and processing steps and are registered as OGC API Records items. Experiments record the individual runs of those workflows. Inputs and products hold the concrete datasets that a run consumed and produced, and both are registered as STAC items so that EDITO and other spatial catalogs can index them directly.

The choice of standard follows the kind of thing being described: a workflow is in effect a piece of software, which OGC API Records captures well, whereas an input or a product is a spatial dataset, which STAC is built for. Because the same roles recur in the same order under every demonstrator, a reader or a tool can move through the catalog predictably, from a country to a particular run, and from that run outward to the data it used and the data it produced.

8.2 The catalog metadata model

The catalog represents each digital twin run as a small set of linked records rather than as one large document. Before looking at the technical detail, it helps to see the basic shape, which the simplified diagram below captures.

There are four elements. A workflow is the reusable model, transformer, or processing service. An execution is one concrete run of that workflow. An input is a dataset, parameter file or configuration that the run consumes, and an output is a product that the run produces.

They relate in only a few ways. An execution is an instance of a workflow, so the workflow acts as the plan that the run follows. When the run happens, it uses its inputs and generates its outputs, and each output is linked back to the inputs it was derived from. That handful of elements and links is the entire model. The next section shows how these same records and links are written down in real standards, and it introduces one further element, the activity, that belongs to that more detailed level.

8.3 The provenance model

Section 8.2 introduced the elements and how they relate. This section shows how each element is expressed in a concrete standard, what each record actually carries, and how the whole pattern travels between platforms. The diagram below is the same model as before, now drawn in full detail that includes the new element Activity.