Data Harmonisation and Interoperability

After completing this Circular, practitioners will be able to harmonise and integrate ocean accounting data from diverse sources, formats, and domains, applying interoperability standards that address the technical and methodological challenges of multi-source data integration. Data harmonisation underpins three decision contexts for ocean accounting: cross-agency data sharing within national statistical systems, international comparability of ocean accounts across jurisdictions, and dissemination of ocean accounting data to external users through standardised exchange platforms.

Cross-agency data sharing: Ocean accounts draw upon data from national statistical offices (economic statistics), environmental agencies (ecosystem monitoring), hydrographic organisations (bathymetry), fisheries management authorities (catch and effort data), and maritime administrations (vessel tracking). Without harmonised classifications, coordinate reference systems, and exchange formats, each bilateral data transfer requires bespoke transformation procedures. The standards described in this Circular enable agencies to establish common data integration protocols that reduce transaction costs and improve data quality through systematic quality checks.

International comparability: Countries implementing ocean accounts require comparable indicators for benchmarking, knowledge exchange, and coordination of regional ocean governance. The SDMX framework provides the international standard for exchanging statistical data, enabling ocean accounting indicators to be disseminated through the same infrastructure as national accounts, environmental-economic accounts, and SDG indicators. Alignment with geospatial standards from the Open Geospatial Consortium and International Hydrographic Organization ensures that spatial data components of ocean accounts can similarly be exchanged across jurisdictions.

This Circular covers the principal international standards for statistical data exchange, including (1) the Statistical Data and Metadata Exchange (SDMX) framework, (2) geospatial interoperability standards from the Open Geospatial Consortium (OGC) and International Hydrographic Organization (IHO), and (3) classification concordance mechanisms that enable mapping between different classification systems. By applying the principles and protocols described here, compilers can establish data integration workflows that raise data quality and reduce manual processing.

Essential prerequisites:

• TG-0.1 General Introduction to Ocean Accounts: conceptual framework and key components of Ocean Accounts.

Helpful background:

• TG-0.7 Quality Assurance Principles: quality dimensions and assessment frameworks, particularly coherence and comparability.

Ocean accounts draw upon a diverse range of sources: fisheries catch statistics from national statistical offices, bathymetric surveys from hydrographic agencies, satellite observations from earth observation programmes, ecosystem condition assessments from environmental monitoring networks, and economic statistics from national accounts. Each of these data streams has evolved within its own institutional context, employing different standards, classifications, formats, and temporal and spatial reference systems. Ocean accounting must harmonise these disparate data streams into a coherent accounting framework whilst preserving data quality and provenance. For guidance on spatial delineation of accounting units, see TG-2.12 Spatial Data Frameworks Sections 3.2 and 3.3. For temporal considerations, see TG-2.12 Spatial Data Frameworks Section 3.4.

This section examines four interrelated dimensions of data harmonisation and interoperability: data standards that define common structures and semantics, exchange formats that enable machine-readable data transmission, interoperability protocols that support automated data discovery and retrieval, and classification concordances that enable translation between different coding systems. Together, these elements form the technical infrastructure for integrated ocean accounting.

Figure 4.6.1 shows how economic data (SDMX), geospatial and marine data (OGC/IHO S-100), and classification concordances feed an integration layer that produces coherent ocean accounts.

The Statistical Data and Metadata Exchange (SDMX) initiative provides the international standard for exchanging statistical data and metadata. Developed by the seven sponsor organisations (BIS, ECB, Eurostat, IMF, OECD, United Nations, and World Bank), SDMX has been designated as an ISO International Standard (ISO 17369). The SDMX 3.1 version, released in May 2025, introduces enhanced support for geospatial data, microdata, and improved data structure definitions.

SDMX is built around an information model that defines the structural metadata needed to describe statistical data. At its core is the Data Structure Definition (DSD), which specifies the dimensions, attributes, and measures that characterise a particular data collection. For ocean accounting, DSDs would define the structure of fisheries statistics, marine economic activity data, and environmental flow accounts. The structure of physical flow accounts is described in TG-2.6 Ocean Economy Investment.

The SDMX framework supports three process patterns for data exchange:

1. Bilateral exchange — counterparties agree on specific formats and processes
2. Gateway exchange — multiple organisations agree on a common exchange format
3. Data-sharing exchange — open standards enable any organisation to access and use data

For ocean accounting, the data-sharing model is particularly relevant as it enables national statistical offices, environmental agencies, and research institutions to publish data in standard formats that can be automatically discovered and integrated.

SDMX provides three transmission formats (SDMX-ML, SDMX-JSON, SDMX-CSV), detailed in Section 3.2 below. The CSV format is particularly accessible to non-specialist users whilst remaining losslessly convertible to the other formats. SDMX registry services provide “visibility into the data and metadata existing within the community, and support the access and use of this data and metadata by providing a set of triggers for automated processing”. A registry-based architecture enables ocean accounting compilers to discover available data sources, retrieve structural metadata, and automate data collection workflows.

The Global Statistical Geospatial Framework (GSGF), version 2.0 released by UN-GGIM and the Statistical Commission in 2025, provides the overarching framework for integrating statistical and geospatial information. The GSGF defines five principles, of which Principle 4 on “Statistical and geospatial interoperability” is directly relevant to ocean accounting data integration.

Data interoperability, as defined in the GSGF, refers to “the ability of different systems, organizations, and applications to exchange, interpret, and use data in a coordinated manner”. The framework identifies four interoperability dimensions derived from the European Interoperability Framework (EIF). Table 3.1.1 below summarises these dimensions.

Two additional ISO standards are essential for geospatial metadata management. ISO 19115 (Geographic information — Metadata) provides the standard schema for describing geographic datasets and services, defining the metadata elements needed for data discovery, evaluation, and use. Its XML implementation, ISO/TS 19139, specifies the encoding format in which ISO 19115 metadata should be stored and exchanged, enabling machine-readable metadata interchange between systems. Together, these standards ensure that geospatial data used in ocean accounts carry sufficient provenance and quality information for informed integration.

The International Hydrographic Organization (IHO) S-100 standard provides the Universal Hydrographic Data Model for marine geospatial data. S-100 Edition 5.2.0, adopted in June 2024, builds upon the earlier Edition 5.1.0 (October 2023) and establishes “a contemporary hydrographic geospatial data standard that can support a wide variety of hydrographic-related digital data sources, and is fully aligned with mainstream international geospatial standards, in particular the ISO 19100 series”. In December 2024, IHO Member States approved operational editions of key S-100-based Product Specifications, including S-101 (Electronic Navigational Charts), S-102 (Bathymetric Surface), S-104 (Water Level Information), and S-111 (Surface Currents).

S-100 is designed to support applications “that go beyond the scope of traditional hydrography — for example, high-density bathymetry, seafloor classification, marine GIS”. The standard comprises multiple parts covering conceptual schema, feature catalogues, spatial schemas, metadata, portrayal, and encoding formats including ISO 8211, GML, and HDF5.

Part 16 of S-100 specifically addresses the Interoperability Catalogue Model, which “enables interoperability between disparate technologies through the use of common interfaces”. For ocean accounts that integrate hydrographic data (bathymetry, tides, currents) with ecosystem and economic data, S-100 provides the interoperability framework for the marine domain component.

• SDMX-ML (XML-based) provides the most complete expression of the SDMX information model. The Structure Specific Data format is “the sole XML format for data exchange” following the deprecation of legacy formats in SDMX 3.0. Appropriate for formal data exchanges where complete metadata preservation is required.
• SDMX-JSON is “well-suited to web-based applications and modern programming environments” and is increasingly preferred for API-based data access.
• SDMX-CSV provides a “simple columnar format” that offers accessibility for practitioners without specialised tools whilst still enabling conversion to other SDMX formats “without loss”. CSV may serve as a practical intermediate format for data validation and review.

For geospatial ocean accounting data, several format standards are relevant:

GeoJSON and JSON-FG (OGC Features and Geometries JSON) provide JSON-based formats for geographic features that are “well-suited to web mapping applications”. These formats are appropriate for ecosystem extent boundaries, marine protected area polygons, and other vector features.

GML (Geography Markup Language) provides the full XML encoding for geographic information conforming to ISO 19136. GML is required for formal data exchange in contexts where complete geometry representation and coordinate reference system information must be preserved.

HDF5 (Hierarchical Data Format version 5) is adopted by IHO S-100 for gridded and imagery data. HDF5 is appropriate for bathymetric grids, ocean temperature fields, and other multi-dimensional environmental data.

GeoPackage provides an SQLite-based container format that can store both vector and raster data. GeoPackage is increasingly used for distributing compiled geospatial datasets.

Interoperability protocols define how systems communicate to discover, query, and retrieve data. Effective protocols enable automation of data collection workflows. Automation reduces manual processing and improves timeliness.

SDMX RESTful Web Services

SDMX defines a RESTful web services API for querying data and structural metadata. The API enables:

• Structure queries — retrieving Data Structure Definitions, codelists, concept schemes
• Data queries — retrieving data observations filtered by dimension values
• Availability queries — discovering what data exists for given parameters

The RESTful API design means queries are expressed through URL patterns, enabling integration with standard web tools. For example, a query for fisheries catch data might specify the dataflow, reference area, time period, and species codes through URL parameters.

The SDMX registry architecture supports “automated processing” through subscription and notification services. Compilers can subscribe to data updates and receive notifications when new data becomes available, enabling near-real-time data integration workflows.

The OGC web services introduced in Section 3.1 (Table 3.1.2) function as interoperability protocols: WFS supports spatial and attribute filtering for retrieval of ecosystem assets within specified bounds, whilst WMS supports rendered map visualisation of spatial context. The Sensor Observation Service (SOS) complements these by providing access to sensor data and observations, relevant for integrating ocean monitoring data (water quality, temperature, wave height) into ocean accounts.

The GSGF emphasises that technical infrastructure should support “standard interfaces, services, and data formats, including metadata standards”. Implementation of OGC services enables ocean accounting systems to integrate with national spatial data infrastructures.

The FAIR Principles (Findability, Accessibility, Interoperability, Reusability) provide guiding principles for scientific data management that are increasingly applied to statistical data. The GSGF explicitly incorporates FAIR principles, noting that the Interoperability principle “emphasises metadata” and that “(meta)data should be ready to be exchanged, interpreted and combined in a (semi)automated way”.

For ocean accounting, FAIR principles translate to practical requirements summarised in Table 3.3.1 below.

The FAIR principles align with quality dimensions in TG-0.7 Quality Assurance Principles and should guide the design of ocean accounting data management systems.

Classification concordances (also called crosswalks or mapping tables) enable translation between different classification systems. For ocean accounting, concordances are essential for:

The relationship between ISIC (activity classification) and CPC (product classification) is fundamental to economic statistics. As the CPC documentation explains, “each subclass of the CPC consists of goods or services that are generally produced in a specific class or classes of the ISIC”. The CPC documentation includes explicit correspondences to ISIC, enabling ocean accounting compilers to link product flows with producing industries.

The CPC serves as a “central” classification providing “a framework for international comparison and promotes harmonization of various types of statistics related to goods and services”. The classification was “developed primarily to enhance harmonization among various fields of economic and related statistics and to strengthen the role of national accounts as an instrument for the coordination of economic statistics”.

With the endorsement of ISIC Rev.5 and CPC Ver.3.0 by the UN Statistical Commission in March 2024, compilers should note that the division-level structure for ocean-relevant activities has been maintained, though with increased detail at lower classification levels. For ocean accounting, key concordance relationships include:

• ISIC Division 03 (Fishing and Aquaculture) corresponds to CPC Division 04 (Fish and Other Fishing Products)
• ISIC Division 50 (Water Transport) corresponds to relevant groups within CPC Divisions 64-67 (Transport and Supporting Services), with specific correspondence at the group and class level documented in official UNSD concordance tables

The UNSD has developed official correspondence tables for the ISIC Rev.4-to-Rev.5 and CPC Ver.2.1-to-Ver.3.0 transitions. These tables should be used when bridging data compiled under different classification versions. Compilers working with historical data collected under ISIC Rev.4 and CPC Ver.2.1 should apply these official correspondence tables rather than constructing ad hoc mappings, to ensure consistency and comparability across time.

Detailed guidance on ocean-relevant economic classifications is provided in TG-0.2 Overview of Relevant Statistical Standards.

The IUCN Global Ecosystem Typology (GET) provides the reference classification for ecosystem types in SEEA Ecosystem Accounting. However, “countries may have their own national classification system of ecosystems (or ecological areas) that could be used for the extent accounts. In such cases, developing a bridge or concordance (often called a schema crosswalk in GIS) of this national classification system with the GET reference classification may facilitate comparability across countries”.

For marine ecosystems specifically, concordances may be required between:

• National marine habitat classifications and GET Marine Realm types
• EUNIS habitat classification and GET Ecosystem Functional Groups
• National land cover classifications and GET transitional realm types (for coastal areas)

The SEEA Biophysical Modelling Guidelines note that the GET “represents a global typological framework that applies a process-based approach to ecosystem classification across the whole planet”. The hierarchical structure (Realms, Biomes, Ecosystem Functional Groups) provides natural aggregation levels for concordance development.

Guidance on ecosystem classification for ocean accounts is provided in TG-4.1 Remote Sensing and Geospatial Data Section 3.2.4 and TG-3.1 Asset Accounts.

Developing classification concordances involves:

1. Structural comparison — examining the hierarchical structure and level of detail in each classification
2. Conceptual alignment — identifying where definitions align or diverge
3. Mapping relationships — defining one-to-one, one-to-many, or many-to-many relationships
4. Documentation — recording mapping rationale and any approximations
5. Validation — testing concordances with actual data

The UNFC (United Nations Framework Classification for Resources) provides an example of formalised concordance development: “mapping schemes have been developed showing the link between the UNFC2009 and the SPE and CRIRSCO classifications” for mineral and petroleum resources.

Classification systems evolve over time through revision processes. ISIC has progressed through Revisions 3, 3.1, 4, and now 5. The CPC has progressed through Versions 1.0, 1.1, 2.0, 2.1, and now 3.0. The UN Statistics Division maintains official correspondence tables between versions to enable time series compilation across classification changes.

For ocean accounting, temporal concordances are required when:

• Compiling time series that span classification revisions
• Integrating historical data collected under previous classifications
• Comparing international data collected under different version implementations

The ISIC documentation emphasises that “continuity, i.e., comparability between the revised and preceding versions of ISIC, has always been a major concern expressed by the Commission”. The official ISIC Rev.4-to-Rev.5 correspondence table, developed between March and October 2024 following the endorsement of ISIC Rev.5 explanatory notes, should be consulted when compiling time series that bridge these classification versions. Similarly, the CPC Ver.2.1-to-Ver.3.0 correspondence table is available through the UNSD classifications portal.

3.5 Data Harmonisation Workflow

Implementing data harmonisation for ocean accounts requires a systematic workflow that transforms heterogeneous source data into consistent, integrated accounting tables. This section describes the compilation procedure and provides a worked example.

The data harmonisation workflow consists of four sequential phases:

Phase 1: Classify — Assign source data to standardised classifications. For ocean accounting, this involves:

• Mapping economic activity data to ISIC Rev.5 divisions and groups
• Mapping product flows to CPC Ver.3.0 categories
• Mapping ecosystem types to IUCN GET Ecosystem Functional Groups
• Mapping spatial units to the national spatial framework and coordinate reference system

Classification mappings should be documented in concordance tables that record the source classification, target classification, mapping type (1:1, 1:many, many:1, many:many), and any assumptions or approximations.

Phase 2: Map — Transform source data values to common units and temporal reference periods. This includes:

• Converting spatial coordinates to the accounting area’s coordinate reference system (typically WGS84 for horizontal coordinates)
• Aligning temporal references to accounting period start/end dates (calendar year, fiscal year)
• Converting physical units to standard measurement units (e.g., tonnes for biomass, hectares for extent, cubic metres for water volumes)
• Converting monetary values to constant prices using deflators where time series require comparability

Mapping transformations should preserve source values in metadata to enable quality checks and re-transformation if specifications change.

Phase 3: Validate — Check integrated data for consistency, completeness, and plausibility. Validation includes:

• Range checks: values fall within plausible bounds (e.g., catch cannot exceed vessel capacity)
• Balance checks: supply equals use in flow accounts
• Spatial checks: geometries are valid, no gaps or overlaps in exhaustive spatial frameworks
• Temporal checks: time series are continuous, no unexplained breaks
• Cross-source confrontation: data from multiple sources describing the same phenomena are reconciled

Validation should generate exception reports that flag issues for resolution. The quality assurance framework in TG-0.7 Quality Assurance Principles provides detailed validation procedures.

Phase 4: Integrate — Compile validated data into accounting tables. Integration produces:

• Asset accounts combining physical extent, condition indicators, and monetary valuations
• Flow accounts recording extractions, emissions, and ecosystem service flows
• Supply-use tables linking ocean economy production and consumption
• Combined presentations integrating environmental, economic, and social dimensions (see TG-3.8 Combined Presentations)

Table 3.5.1: Data harmonisation workflow phases

Worked Example: Harmonising Fisheries Data Using SDMX

This synthetic example demonstrates the data harmonisation workflow for integrating fisheries catch data from multiple agencies into ocean accounts. The scenario: a national statistical office is compiling fisheries accounts and must integrate data from three sources with different reporting frameworks:

• Source A: National fisheries agency — species-level catch data by fishing zone, reported quarterly in tonnes live weight
• Source B: Port authority — landing declarations by vessel and port, reported monthly in various product forms (whole fish, fillets, processed)
• Source C: Customs administration — seafood export data using national tariff codes, reported monthly in kilograms and monetary value (FOB)

Phase 1: Classify

The compiler establishes an SDMX Data Structure Definition (DSD) for fisheries flow accounts with the following dimensions:

• Source A reports species using national codes, and a concordance table maps these to FAO ASFIS codes (mostly 1:1)
• Source B records product forms, and a concordance table maps these to CPC Ver.3.0 with conversion factors to derive live weight equivalent (1:many mapping: one product code may correspond to multiple CPC classes depending on processing level)
• Source C uses HS 2022 tariff codes, and the official UNSD concordance table maps these to CPC Ver.3.0 (many:many mapping requiring allocation based on supplementary information)

Phase 2: Map

Unit conversions and temporal alignment:

• Source A data are already in tonnes live weight, and temporal alignment aggregates quarterly data to annual totals for stock accounts whilst preserving quarterly detail for seasonal analysis
• Source B landing weights require conversion to live weight equivalent using species-specific factors (e.g., fillets to whole fish factor 2.5 for snapper, 2.8 for tuna). Conversion factors documented in metadata
• Source C export data in kilograms converted to tonnes product weight, and to live weight equivalent using the same species- and product-form factors as Source B, with monetary values (FOB) converted to national currency constant prices using fish price deflator

Spatial mapping:

• Source A fishing zones map to ocean accounting spatial framework using GIS overlay of zone boundaries
• Source B port locations geocoded using national address gazetteer, with landings attributed to fishing zones using vessel logbook data on fishing grounds (where available) or pro-rata allocation based on Source A zone proportions for species
• Source C export port locations geocoded, with spatial attribution to production zones inferred from Source A and B integration

Phase 3: Validate

Validation checks applied:

• Source A reports 15,200 tonnes tuna catch in EEZ, whilst Source B records 14,100 tonnes landings. The difference is attributed to unreported landings (estimated 600 tonnes based on observer coverage) and at-sea discards (estimated 500 tonnes, 3.3% discard rate consistent with observer data)
• Source C reports 8,200 tonnes tuna exports in product weight, or 9,100 tonnes live weight equivalent (the 900-tonne difference is weight removed in processing), which reconcile with Source B after accounting for 4,800 tonnes domestic consumption and 200 tonnes cold storage stock increase

Validation produces exception report documenting assumptions and highlighting areas requiring further investigation (unreported catch estimation method).

Phase 4: Integrate

Validated data compiled into SDMX-compliant fisheries flow account table with dimensions:

The DSD includes attributes documenting data sources, estimation methods, and quality flags. The compiled data structure enables:

• Dissemination through SDMX registry for automated retrieval by analysts
• Integration with economic accounts using ISIC and CPC concordances
• Comparison with international fisheries statistics using FAO ASFIS species codes
• Spatial analysis of catches by zone for marine spatial planning

The worked example demonstrates how SDMX Data Structure Definitions provide a standardised framework for harmonising heterogeneous source data. That framework supports systematic quality checks and produces interoperable outputs for ocean accounting.

3.6 Modular Data Architecture Patterns

The technical infrastructure supporting ocean account data harmonisation must accommodate diverse data sources, multiple processing workflows, and varied dissemination requirements. This section describes modular architecture patterns that enable national statistical offices and ocean accounting programmes to build scalable, maintainable data systems. The guidance draws on established practices in statistical data management and modern data engineering, adapted to the specific requirements of environmental-economic accounting.

Data lake versus data warehouse

Two architectural paradigms are relevant for ocean accounting data infrastructure: data lakes and data warehouses. Each serves a distinct purpose, and many implementations will employ both in combination.

A data lake stores data in its original format (raw satellite imagery, CSV files from monitoring stations, spreadsheets from fisheries agencies, GIS shapefiles) without imposing a predefined schema. The data lake preserves full provenance and enables re-processing when methodologies change. For ocean accounting, a data lake is appropriate for ingesting heterogeneous source data from the diverse agencies described in Section 3.1, including remote sensing products (TG-4.1 Remote Sensing and Geospatial Data), survey microdata (TG-4.2 Survey Methods for Ocean Economic Activity), administrative records (TG-4.3 Administrative Data Sources), and citizen science observations (TG-4.4 Citizen Science).

A data warehouse stores data in a structured, schema-enforced format optimised for analytical queries and reporting. The warehouse contains harmonised data that has passed through the classify-map-validate-integrate workflow described in Section 3.5. For ocean accounting, the data warehouse holds the compiled account tables in SDMX-compliant structures, ready for dissemination and analysis. The data warehouse enforces the classification concordances (Section 3.4) and accounting identities that ensure internal consistency.

APIs should provide three access tiers: a discovery tier (what data are available, covering which areas and periods), a metadata tier (data structure definitions, classification codelists, quality reports), and a data tier (observation values with full dimensional context). This mirrors the SDMX architecture of structure queries, availability queries, and data queries. Each tier should support standard HTTP methods and return responses in both SDMX-JSON and SDMX-CSV formats to accommodate different client capabilities.

Versioning is essential for APIs serving official statistics. Each API version should be maintained for a minimum of two years after a successor version is released, enabling downstream systems to migrate without disruption. Version identifiers should appear in the URL path (e.g., /api/v2/data/ocean-accounts/...) following REST conventions.

Authentication and access control should follow the data governance policies established by the national statistical office. Public-use indicators may be served without authentication, whilst microdata or geographically detailed data may require registration and licence acceptance, consistent with the FAIR principles described in Section 3.3.

Complete metadata is essential for data discovery, evaluation, and reuse. Ocean accounting data should carry metadata conforming to two complementary standards:

Geospatial metadata follows ISO 19115 / ISO 19139 (introduced in Section 3.1). All geospatial data products used in ocean accounts (ecosystem extent maps, bathymetric grids, spatial unit boundaries) should carry ISO 19115-compliant metadata encoded in ISO 19139 XML, documenting the coordinate reference system, spatial resolution, temporal coverage, processing history, and quality assessment results.

Statistical metadata follows the SDMX information model (Section 3.1). All compiled ocean account tables should be accompanied by SDMX structural metadata defining the dimensions, attributes, and measures of each dataset. Reference metadata (quality reports, methodological descriptions) should follow the SDMX metadata structure definition format.

Where ocean accounting data combines geospatial and statistical components (as is typical), both metadata standards should be applied. The GSGF (Section 3.1) provides guidance on achieving interoperability between ISO 19115 and SDMX metadata, recommending that organisations maintain metadata catalogues that link geospatial and statistical metadata for the same underlying datasets.

National statistical offices and ocean accounting programmes with constrained budgets can implement the lakehouse architecture using open-source software. The following stack has been demonstrated in environmental-economic accounting contexts and aligns with the standards described in this Circular:

Table 3.6.2: Open-source technology stack for ocean accounting data infrastructure

The SDMX community maintains the .Stat Suite, an open-source platform for SDMX data dissemination that is already used by several national statistical offices and international organisations. For geospatial data, GeoServer provides OGC-compliant web services. These tools can be deployed on standard server infrastructure or cloud platforms, with costs scaling according to data volume and user load.

3.7 Science-to-Accounts Translation Protocols

Ocean accounts depend on data from scientific research programmes (oceanographic surveys, ecological monitoring, biodiversity assessments, and fisheries stock assessments) that are produced for scientific purposes and must be translated into the structured formats required by accounting frameworks. This section provides protocols for converting research datasets into account-ready inputs, managing uncertainty, and establishing quality tiers that reflect the maturity and reliability of different data sources.

Scientific datasets differ from administrative and statistical data in several respects that affect their suitability for ocean accounts. Research data may cover irregular spatial domains (transects, sampling stations) rather than exhaustive spatial frameworks, may use non-standard temporal reference periods (field seasons, project durations) rather than accounting years, and may employ bespoke classification schemes in place of international standard classifications. The conversion protocol addresses each of these differences systematically.

Spatial harmonisation: Research data collected at point locations (monitoring stations, sampling sites) must be interpolated or modelled to produce estimates for the exhaustive spatial units used in ocean accounts. The biophysical modelling guidance in TG-2.1 Aggregate Biophysical Indicators of Environmental State describes interpolation and modelling techniques. Compilers should document the interpolation method, the spatial support (area over which each estimate applies), and the estimation uncertainty. Remote sensing data (TG-4.1 Remote Sensing and Geospatial Data) can provide spatially complete coverage to supplement point-based research data.

Temporal alignment: Research datasets with non-standard temporal coverage must be adjusted to accounting periods. Where research data cover a different period (e.g., a biological survey conducted from March to November), compilers should assess whether temporal adjustment is needed (for stocks that change slowly, the survey period may be a reasonable proxy for the annual average) or whether correction factors should be applied (for seasonally variable quantities such as biomass or water quality). The temporal alignment should be documented in metadata, including any assumptions about seasonal patterns.

Classification mapping: Research datasets often use scientific taxonomic or habitat classification schemes that differ from the standard classifications used in ocean accounts. Compilers should develop and maintain concordance tables mapping research classifications to accounting classifications (IUCN GET for ecosystem types, FAO ASFIS for species, ISIC/CPC for economic activities). The concordance development process described in Section 3.4 applies. Where research classifications provide finer detail than accounting classifications, the mapping is straightforward (aggregation). Where research classifications are coarser or use different conceptual categories, expert judgement is required and should be documented.

Table 3.7.1: Science-to-accounts conversion steps

Scientific data carry measurement uncertainty that must be propagated through the accounting framework. Ocean accounts should report uncertainty for key aggregates, enabling users to assess the confidence they can place in derived indicators. Three levels of uncertainty reporting are recommended, in order of increasing sophistication:

Level 1 — Qualitative assessment: Each data input is assigned a qualitative uncertainty rating (low, medium, high) based on expert judgement of the data source, collection method, and processing steps. This minimum level is feasible for all ocean accounting programmes and should be documented in metadata for every compiled account.

Level 2 — Confidence intervals: Key aggregates (total ecosystem extent, total fish stock biomass, ocean economy GVA) are reported with confidence intervals derived from the uncertainty of input data. Where input uncertainties are characterised as standard errors or confidence intervals, propagation follows standard statistical methods (error propagation for sums, products, and ratios). This level requires quantitative uncertainty estimates for the major input datasets.

Level 3 — Monte Carlo simulation: For accounts involving complex non-linear transformations (such as ecosystem service valuation using benefit transfer, or carbon stock estimation using allometric equations), Monte Carlo simulation provides the most rigorous uncertainty propagation. Input distributions are sampled repeatedly, the accounting calculations are performed for each sample, and the resulting distribution of outputs characterises the aggregate uncertainty. This level requires specification of probability distributions for all major inputs and is appropriate for high-priority accounts where uncertainty is a policy concern.

Table 3.7.2: Uncertainty reporting levels

Tier 1 — Official statistics: Data produced by national statistical offices or designated official statistics producers, compiled according to the UN Fundamental Principles of Official Statistics. Tier 1 data have been through established quality assurance processes and carry the authority of the national statistical system. Examples include national accounts aggregates, population census data, and fisheries catch statistics compiled by the national statistical office. The quality assurance framework in TG-0.7 Quality Assurance Principles describes the quality dimensions applicable to official statistics.

Tier 2 — Provisional and administrative data: Data from government agencies (environmental ministries, fisheries authorities, port authorities) that follow documented collection and processing procedures but have not been formally designated as official statistics. Tier 2 data may be subject to revision and may not meet all quality dimensions of official statistics. Examples include environmental monitoring data, vessel tracking records, and protected area registries. Administrative data guidance is provided in TG-4.3 Administrative Data Sources.

Tier 3 — Experimental and research data: Data from research programmes, citizen science initiatives, remote sensing products, and modelled estimates that have been peer-reviewed or validated but are not part of the official statistical system. Tier 3 data are often the only source available for ecosystem condition indicators, ecosystem service estimates, and blue carbon stocks. Research data guidance is provided in TG-4.5 Research Data, and citizen science guidance in TG-4.4 Citizen Science.

Research data entering the ocean accounts should undergo peer review appropriate to the quality tier. For Tier 3 data, the minimum requirement is that the underlying research has been published in a peer-reviewed journal or technical report, or has been reviewed by a technical advisory committee with relevant domain expertise. For Tier 2 data, the data collection methodology should be documented and reviewed by the national statistical office or an equivalent quality assurance body. For Tier 1 data, the full quality assurance framework of the national statistical system applies.

Where ocean accounting programmes commission new research or monitoring to fill data gaps, the research design should be reviewed before data collection begins (to ensure the outputs will be compatible with accounting requirements) and the results should be reviewed before incorporation into accounts. The review should assess fitness for purpose (does the data measure what the account requires?), methodological rigour (is the collection and processing method sound?), and reproducibility (could another team replicate the results?).

3.8 Time-Series Data Investment Guidance

For each indicator, the gap analysis should record: the current data source (if any), the quality tier (Section 3.7), the spatial and temporal coverage, the update frequency, the time lag between reference period and data availability, and the estimated cost of producing the indicator. Gaps should be classified into three categories:

Complete gaps: No data source exists for the indicator. Complete gaps are the most serious, as they prevent compilation of entire account components. Common complete gaps in ocean accounting include ecosystem condition indices for deep-sea ecosystems, monetary valuation of regulating services, and governance effectiveness indicators.

Partial gaps: Data exist but with insufficient spatial coverage (e.g., monitoring stations cover only a fraction of the coastline), temporal coverage (e.g., surveys conducted once rather than annually), or thematic detail (e.g., employment data available for the ocean economy as a whole but not disaggregated by industry). Partial gaps can often be addressed through statistical estimation or modelling, but sustained monitoring investment is needed for reliable time-series compilation.

Quality gaps: Data exist with adequate coverage but at an insufficient quality tier (e.g., Tier 3 experimental estimates where Tier 1 official statistics are needed for policy credibility). Quality gaps require investment in data collection methodology, quality assurance processes, or institutional capacity rather than new monitoring infrastructure.

Table 3.8.1: Gap analysis template

Cost-benefit of sustained monitoring

Investment in sustained ocean monitoring should be evaluated against the analytical value it generates for ocean accounts and the policy decisions it enables. The cost-benefit assessment should consider both the direct costs of data collection (equipment, personnel, survey operations, data processing) and the indirect benefits (improved policy decisions, avoided environmental damage, international reporting compliance).

The third is substitutability: some data can only be collected through direct observation (e.g., deep-sea biodiversity surveys), whilst others can be estimated from proxies or models (e.g., wave energy potential from reanalysis products). Investment priority should favour non-substitutable observations.

Table 3.8.2: Monitoring investment priority matrix

Based on the gap analysis and cost-benefit assessment, ocean accounting programmes should develop a prioritised data investment plan. The investment plan should be aligned with the national statistics development strategy and the broader ocean governance priorities. Priority investments for most countries implementing ocean accounts will typically include:

Establishing annual ecosystem extent monitoring using satellite remote sensing, which provides the foundational spatial data for extent accounts, condition assessments, and ecosystem service estimation. The relatively low marginal cost of processing freely available satellite imagery (Sentinel-2, Landsat) makes this a high-value investment. Guidance on remote sensing methods is provided in TG-4.1 Remote Sensing and Geospatial Data.

Strengthening coastal water quality monitoring networks to provide consistent, spatially representative measurements of nutrients, sediments, and pollutants. Water quality data serve the residual flow accounts (TG-3.4), ecosystem condition accounts, and the water-marine quality integration protocol described in TG-3.8 Combined Presentations, Section 3.8.

Developing ocean economy satellite accounts within the national accounts framework, enabling consistent measurement of ocean economy GVA, employment, and trade. This requires collaboration between the national statistical office and sectoral ministries to agree on the scope of ocean-related industries and compile thematic accounts following TG-3.3 Economic Activity Relevant to the Ocean.

Investing in sub-national data disaggregation to support provincial and municipal ocean accounting, as described in TG-3.8 Combined Presentations, Section 3.9. Many national datasets can be disaggregated to sub-national level at relatively low additional cost if the disaggregation requirement is built into data collection design from the outset.

The data investment priorities identified in this section should be integrated into the broader capacity development strategy described in TG-4.7 National Data Coordination Architectures. Sustained monitoring requires institutional capacity as well as financial investment: trained personnel, maintained equipment, quality assurance systems, and data management infrastructure. The capacity development Circular provides guidance on building and maintaining these institutional foundations, including workforce planning, training programmes, and partnerships with research institutions and international organisations. Data investment plans should be reviewed and updated alongside the capacity development strategy to ensure that monitoring ambitions are matched by implementation capacity.

Implementation of these standards requires institutional investment in technical infrastructure, staff capacity building, and sustained collaboration across organisational boundaries. The GSGF notes that “both the statistical and geospatial communities operate their own general data models, metadata capabilities, architectures, and data infrastructures” and that bridging these requires “greater incorporation of geospatial processes, standards, and best practices in the statistical business processes and data management systems”.

For ocean accounting practitioners, a pragmatic approach involves:

1. Adopting SDMX-CSV as an accessible intermediate format whilst building toward full SDMX-ML/JSON implementation
2. Ensuring geospatial data conforms to OGC standards and carries ISO 19115-compliant metadata to enable integration with national spatial data infrastructures
3. Documenting all classification concordances used, including rationale and limitations, and using official UNSD correspondence tables for transitions between ISIC and CPC versions
4. Implementing FAIR principles progressively, prioritising persistent identifiers and standardised metadata
5. Establishing data harmonisation workflows with systematic quality checks at each phase

All ocean accounts benefit from harmonised data infrastructure. Asset accounts (TG-3.1 Asset Accounts) integrate physical and monetary data from diverse sources, requiring consistent classifications and units. Ocean economy investment accounts (TG-2.6 Ocean Economy Investment) depend on concordances between economic activity and product classifications. Combined presentations (TG-3.8 Combined Presentations) integrate environmental, economic, and social data, relying on interoperable formats and metadata standards. Data harmonisation and interoperability are therefore foundational to the ocean accounting framework.

Guidance on specific data integration challenges for individual account types is provided in the relevant thematic Circulars: TG-4.1 Remote Sensing and Geospatial Data, TG-4.2 Survey Methods for Ocean Economic Activity, TG-4.3 Administrative Data Sources, TG-4.4 Citizen Science, and TG-4.5 Research Data.

For minimum institutional capacity, data infrastructure, and human skills requirements for implementing these data methods, see TG-0.8 Implementation Readiness Assessment.

Authors: [To be confirmed]

Reviewers: [To be confirmed]