Versions

• Version 1.0.0, First Published Draft, August 2025
• Version 0.1.0, Original Draft Published for Public Review, January 2025
  • Public Comments on Version 0.1.0, Feedback Summary, August 2025

Background

Introduction

This document outlines recommendations for producing consistent data and metadata for Ocean Alkalinity Enhancement (OAE) field trial projects. Its first iteration was produced in partnership with the OAE community (see Acknowledgements), with the intention to remain a living document and continually improve to reflect best known scientific practice. Initially the document will be revised and updated in line with the latest OAE research approximately once per year, incorporating learnings and feedback from the OAE community and led by the Data Management Coordination Team. All major updates will undergo review and all previous versions will be maintained for transparency (see Deprecated Standards and Practices for a detailed description of versioning).

Objectives & Guiding Principles

The objective of the OAE Data Management Guidelines and this OAE Data Management Protocol document are to enable marine Carbon Dioxide Removal (mCDR)-OAE data collected from academia, government, non-profit, and industry to be documented in a consistent way, and make them findable and discoverable from shared data repositories to facilitate future data synthesis efforts. The guidelines here support FAIR data sharing principles, in effort to make data findable, accessible, interoperable, and reusable.

OAE introduces unique challenges and opportunities for data standardization. Traditional oceanographic data standards, while robust, require updates to address the specific needs of OAE projects.

The main updates and recommendations are driven by these Guiding Principles:

• Project Comparability: Developing guidelines that ensure data from different OAE projects are intercomparable, enabling meta-analyses and large-scale assessments of OAE effectiveness and environmental impact.
• Minimal Burden on Data Providers: Establishing streamlined protocols and tools that simplify data submission while ensuring high-quality, standardized outputs.
• Flexibility for Innovation: Allowing for innovation in project designs by creating standards that accommodate diverse methodologies and intervention scales without imposing restrictive requirements.
• Transparency and Accessibility: Promoting open and transparent data sharing, with appropriate metadata, to facilitate peer review, collaboration, and public trust in OAE efforts.

By building on existing standards and addressing these updates, the goal is to create a system that supports rigorous science while remaining practical and adaptable for data providers. This ensures that OAE projects contribute meaningfully to the collective understanding of marine carbon dioxide removal while fostering collaboration across the community.

Methodology

This protocol was developed by the OAE community in a multi-process method, starting with a workshop during OCEANS 2024 with participants representing academia, government, non-profit, and industry to gather initial feedback and input for sensor output, model output, and discrete carbonate and nutrient data. This feedback was developed into an outlined draft of recommendations, which were reviewed by attendees and developed into the first draft OAE Data Management Protocol 0.1.0. 

Working Groups were formed to capture input from biological sciences, sediment processes, and social science data, each hosting virtual meetings to gather community feedback, which further informed the initial draft. The recommended variable column header names and controlled vocabularies are made to mirror existing naming conventions, and long-standing recommendations by the Ocean Acidification Community. The draft was then provided to the Steering Committee members for internal review. The resulting draft was presented at a second workshop during AGU in December 2024 for additional mCDR-community feedback, followed by additional internal revisions to create the draft that was presented during an open public review period. This document represents the final conclusions developed by the OAE community to ensure projects will be standardized by data providers, and findable, openly accessible, and intercomparable by data end-users. 

This work was performed under a Cooperative Research and Development Agreement (CRADA) between NOAA and Carbon to Sea. However, the views expressed herein are not necessarily those of NOAA, the Department of Commerce or the U.S. Government.

We are grateful for the contributions of the workshop participants, working group members, the Steering Committee and those who provided comments during the open review period. For a list of contributors and contributing authors, please see the Acknowledgements section.

Intended Users

This protocol is designed to support data producers, granting agencies, institutions, registries, regulatory and verifying bodies working on OAE field projects that generate model output and/or field data from various sources, including commercially available sensors, discrete observations, social sciences, sediment processes, and biological processes. It provides a standardized approach for documenting datasets while offering guidance on selecting appropriate repositories, submission timelines, controlled vocabularies, and best practices to facilitate field data intercomparison. The level of detail provided to guide various fields of research and observing systems varies, as protocols and recommendations have been better defined in some areas than others by the general oceanographic community. Future work to develop these areas pertinent to the scope of this protocol are outlined in Emerging Standards. Data from field projects include any observations made by measuring the natural environment as well as its response to alkalinity addition, versus controlled laboratory experiments.

The protocol provides best practices around data management that may be adopted by any user to help develop their data management plan. Projects referencing compliance to this protocol must meet the minimum requirements outlined below, though additional recommendations provided here are strongly encouraged. While developed for OAE, these guidelines may also be relevant to other marine Carbon Dioxide Removal (mCDR) methods. Please reach out to data@carbontosea.org with any questions, comments, or suggestions regarding the protocol.

The protocol is organized into five chapters:

1. Metadata & Templates – Building on existing metadata guidelines that accompany each repository, this protocol requires mCDR-specific Metadata & Templates to provide essential context unique to OAE field trials. It also includes Model Metadata to introduce and define key fields for documenting model and model output data details.
2. Guidelines for Data Management – This chapter outlines how to set up, manage and submit data across a range of data types.
3. Column Header Names – Recommendations are provided for column header names for use in data files.
4. Controlled Vocabularies – Definitions are provided for controlled vocabularies, including OAE-specific fields.
5. Deprecated Standards and Practices – Versioning control for the Data Protocol is outlined here.

^ Return to tABLE OF CONTENTS ^

Definitions of Selected Terms

^ Return to tABLE OF CONTENTS ^

Project Metadata

Project-level metadata captures the overall context of a research effort, including its goals, timeline, participants, and funding. It links multiple experiments under a unified framework and ensures that experimental data can be traced back to the broader project—supporting transparency, coordination, and long-term synthesis. Project-level metadata should be re-used across all data submissions in a project.

Depending on your choice of repository (see When, Where, and How to Submit Data), there may be a structured metadata interface required with data submission that includes fields to describe the investigators, project site, etc. Below we have provided these general fields, with the addition of new fields specific to mCDR and OAE projects. 

Projects focused on mCDR, particularly OAE, involve the investigation of perturbations to study their effects. Given the diversity of approaches to raising alkalinity or reducing acidity, along with the site-specific nature of OAE field data, additional metadata fields are needed on top of existing metadata templates that are designed for ocean carbon and acidification studies. The mCDR Project Metadata leverages existing oceanographic core metadata from NOAA’s Ocean Carbon and Acidification Data System (OCADS) and provides the necessary context for the research community to effectively find, interpret, compare, and use OAE field data across different studies and methodologies.

^ Return to tABLE OF CONTENTS ^

Dataset Metadata

Dataset metadata are specific to the observed properties collected during an experiment. For example, these may include dataset files from a rosette sensor array, discrete samples collected on rosette casts, underway sampling, or a collection of sensor measurements sampled from unmanned vehicles. For a list of controlled vocabularies for mCDR data types see Controlled Vocabularies.

The Dataset metadata available for download here must be filled out for each mCDR Data Type. The observed properties metadata must also be completed for each dataset, which includes details on calibrations, sensor IDs, quality control methods, etc. The metadata fields for observed properties can be repeated for each measured or non-measured variable in a dataset within the same metadata file. For some observed properties, such as the carbonate parameters, specific metadata are required and included as separate tabs in the Dataset metadata file, which may be removed prior to submission if not applicable. These include: 

• Dissolved inorganic carbon metadata
• pCO₂/fCO₂ discrete metadata
• xCO₂/pCO₂/fCO₂ continuous or calculated metadata
• pH metadata
• Total alkalinity metadata
• Socioeconomic metadata
• Sediment metadata
• Physiological metadata
• ADCP metadata fields are provided by Ocean Networks Canada under the Matlab structure example for ‘config’ and ‘meta’.

^ Return to tABLE OF CONTENTS ^

Guidelines for Data Management

This section outlines the specific requirements and recommendations for submitting data associated with OAE research. It covers general guidelines for adjusted and raw data, in situ sensor data, model data, sediment processes, and derived variables. Additionally, it provides instructions for creating unique Project and Experiment IDs to facilitate cross-linking of datasets, particularly for research cruises and other projects, and timelines for archiving data. These standards ensure data consistency, reproducibility, and compatibility across studies while allowing for flexibility to include necessary details in the Metadata & Templates when repository fields are insufficient.

In this section, a ✦ indicates requirements in order to be considered compliant with this protocol. “Recommendations” (noted with a ﹢) are strongly suggested best practices to support quality data sharing, but may not always be possible.

^ Return to tABLE OF CONTENTS ^

General Guidelines for your Data

The following recommendations and requirements are general for both discrete and sensor data. 

Requirements:

✦ Include the OAE Data Management Protocol version number used in a ReadMe file.

✦ For data files with more than one variable measured under the same column header name (for example if two dissolved oxygen sensors were deployed on a single mooring), they can be differentiated by adding a numerical suffix. For the mooring example, this would result in a data file with column header names ‘doxy’ and doxy2’.

✦ The unique Experiment ID must be included in each data file. Use the column header name “exp_ID”.

✦ Required metadata fields must be included. If these are not integrated into the metadata system of your chosen repository, they may be uploaded as a separate file titled ‘mCDR metadata’.

✦ When providing date time information, either in metadata or data files, these must be in UTC and using ISO-8601 format (for example, using the format March 18, 2021 at 14:05:35 UTC would be 2021-03-18T14:05:35Z, where ‘T’ is used to separate the date (YYYY-MM-DD) from the time (HH:MM:SS), and appending with ‘Z’ denotes that the datetime is provided in UTC).

✦ Latitude and longitude must be provided in decimal degrees.

✦ When filling out your metadata, refer to the Controlled Vocabularies for inputs.

✦ Field data representing baseline conditions, control conditions, intervention conditions, or model experiments will be uploaded separately. The priority here is to ensure that intervention data are not easily mistaken for baseline oceanographic data by scientists. For this reason, and due to the fact that some intervention datasets may include long periods of no dosing where a ‘return to baseline occurs’, which would put a burden on the data provider to separate out these ‘baseline’ and ‘intervention’ data, it is left to the discretion of the data provider to decide whether to create a new experiment for each ‘return to baseline’ condition or leave it as a continuous time series in an intervention experiment. Once community agreement defining ‘return to baseline’ conditions has been reached, recommendations will be provided in this Protocol. This combination of data must only occur under an intervention experiment designation and never an experiment identified as ‘baseline’ or ‘control’. Given that intervention experimental data include information on dosing, it is recommended that data users apply dosing_rate or dosing_onoff data to interpret intervention data accurately. 

✦ Model experiments will always select the Experiment Type ‘model’.

✦ The unique project ID must be included in any data upload’s metadata in order to link e.g., the model output to other affiliated project data, baseline data to intervention data, etc.

✦ Raw data must be provided for nutrient and carbonate bottle data (indicated as <parameter_name>_raw).

✦ A unique sample identification number should be assigned to vector data (use column header name = ‘sample_ID’). These can simply be consecutive numbers.

✦ Missing values should be reported as ‘-999’.

✦ Associated quality flags for measured variables should be indicated as <parameter_name>_flag and follow the following flagging definitions (Jiang et al., 2022; Table 2), 

• 0 = interpolated or calculated data
• 1 = not evaluated/quality unknown 
• 2 = acceptable 
• 3 = questionable 
• 4 = known bad 
• 6 = median of replicates 
• 9 = missing value

Recommendations:

+ For transecting data moving between the outside and inside of an alkaline plume or tracer dye release, it is useful to include a qualitative information with the transect data time series using column header name ‘transect_location’ and options: ‘inside’ for inside the plume, ‘out’ for outside the plume waters, and ‘transit’ for data collected during periods of underway activity between stations or to and from port.

+ If processing software were used, include firmware version in the ReadMe file.

+ Providing meteorological data or data sources that provides context to the results of the project and interpretation of data is strongly encouraged. For example, rain accumulation (as it impacts salinity). 

+ Point by point uncertainty/precision values should be included with data (indicated as <parameter_name>_uncertainty or <parameter_name>_precision). For sensor data, if no uncertainty or precision analyses were performed during the project, these may be estimated using the manufacturers calibration sheets, for example, a factory calibrated sensor may have an accuracy specification of “+/-2 uM or 1.5% of measurement, whichever is greater.” This information can be converted into a point-by-point uncertainty value. Provide a brief description of how these values were estimated and types (e.g., instrumental, analytical, sampling) in the ReadMe file.

^ Return to tABLE OF CONTENTS ^

Model Data

Model output data plays a crucial role in interpreting and predicting the outcomes of mCDR interventions. Adhering to established data standards ensures that model configurations and outputs are consistent, interoperable, and easily integrated with observational data. This section outlines the requirements to maximize the usability and reproducibility of model output, as well as to facilitate meaningful comparisons across studies and datasets.

Requirements: 

✦ All model source code, including software versions (e.g., compiler information), model configuration code, experiment code, input/forcing data, and description of model output wherever possible must be shared publicly. Given data storage costs and limitations, it is not expected that large input datasets (e.g. atmospheric forcing data or boundary conditions) that are publicly available elsewhere be archived along with model code, but model code should link to public data repositories containing forcing and any methods and code used to process forcing data to produce actual model inputs (e.g. regridding) should be provided. If model forcing datasets are not already stored publicly, it is recommended that they be publicly archived and linked to the model code wherever possible or alternatively share the methods & code for generating the input/forcing data. See the Data Submission section for guidance on archiving model code. 

✦ Documentation outlining the model components, code versions, configuration, forcing, and parameterizations named ‘model_metadata’ if uploaded separately and provided in, xlsx, netCDF, or plain text format. An example template for this information is provided in the Model Description Template.

✦ Parameter names must refer to Model Output Variables for common naming conventions.

✦ The parameters modeled, spatial, and temporal frequency of model output data will vary substantially for specific model projects, and archiving large quantities of model output is impractical due to data storage limitations and costs. However, in cases where a biogeochemical model is used to quantify gross CDR (using a baseline and intervention experiment), we recommend publicly archiving the following parameters from models from both baseline and intervention model experiments at minimum:

• 2D Air-sea CO₂ flux (mol/m²/s or mmol/m²/day) time series
• 3D Dissolved Inorganic Carbon (μmol/kg) time series
• 3D Total Alkalinity (μmol/kg) time series
• 3D Temperature (°C) time series
• 3D Salinity time series

This minimum set of parameters includes essential parameters needed to calculate CDR from the difference between an intervention and baseline experiment (3D Dissolved Inorganic Carbon time series or 2D air-sea CO₂ flux time series), and the minimum parameter set needed to determine derived carbonate system parameters (Dissolved Inorganic Carbon, Total Alkalinity, Temperature, Salinity). To save space, derived variables do not need to be included, however the inputs needed to derive those variables (e.g. for CO₂SYS) should be included. Methods and equations used for derived variables should be described in a ReadMe file. See Derived Variables for further recommendations. It is recommended that model output is archived on the original model grid, all grid information is included (particularly grid cell area and volume needed to calculate spatially integrated DIC or air-sea CO₂ flux differences) and for models with a sigma, hybrid coordinate or terrain following coordinate system it is recommended either to re-grid to a depth coordinate or else to provide the data and functions needed to re-grid to a depth coordinate. The temporal frequency of the provided model output data is project dependent and left to the data provider to decide what to supply. See the Data Submission section for guidance on where to archive model output data. 

Recommendations:

+ The data from a counterfactual experiment and the intervention experiment may each be provided separately, as this can decrease the data storage needed in cases of multiple unique intervention experiments relative to a single counterfactual (for example for sensitivity experiments to assess parametric uncertainty). 

+ It is recommended that model outputs are provided in netCDF format, following recommended naming conventions (see Column Header Names for parameter naming conventions).

+ Additional recommended parameters to archive include:

• Physical transport vectors (u, v, w)
• Biological tracers (chlorophyll, phytoplankton, zooplankton, dissolved oxygen, NO₃^– and NH₄⁺, as available)
• Grid data to transform from model vertical coordinates to z coordinates

^ Return to tABLE OF CONTENTS ^

Sediment Processes Data

Requirements: 

✦ A description and/or reference to methods used for total carbon values must be included in a ReadMe file.

✦ Sediment sampling method should also be included in a ReadMe file.

Recommendations:

+ Local sediment type should be included in the Metadata under ‘Site description’.

+ Information on core length should be provided in the ReadMe file.

+ Sediment depth interval(s) should be provided.

^ Return to tABLE OF CONTENTS ^

Cross-linking Data Sets with Common Identifiers

Project ID

An ID that is unique based on the project’s key attributes may be created using the following fields, separated by an underscore character, however any method that creates a unique ID that will link all project data (e.g., a project’s baseline data to intervention data, and various data submissions within an experiment type) is acceptable.

• Lead organizer surname and first initial, or company name
• A unique date with the primary purpose to ensure a unique Project ID, as such the guidelines here are not strict. Please choose a date most reasonable to the data, for example, this may be the date that data were first collected for this project (likely the beginning of baseline sampling). Provide the date in Coordinated Universal Time (UTC) using ISO-8601 format 
• Location (descriptive)

Example 1: Carbon Dive is submitting project data beginning January 20, 2023 for their study site in San Francisco Bay where they collected baseline and intervention data, their resulting Project ID is carbondive_20230120_sanfranciscobay.

Experiment ID

An experiment ID is provided for each unique mCDR Experiment type as well as unique experiments within a single mCDR Experiment type. One option is to generate this by combining the following:

• Project ID (see above for how to generate)
• Experiment type (see Controlled Vocabularies)
• A numerical indicator starting at 01 to differentiate between experiments of the same type for a project.

In the example for Carbon Dive above, their Project ID is carbondive_20240120_sanfranciscobay. 

Carbon Dive collected baseline and intervention data during this project. 

For the baseline experiment, the Experiment ID is  carbondive_20240120_sanfranciscobay_baseline, and the Experiment ID for their intervention is carbondive_20240120_sanfransiscobay_intervention01. 

They also conducted an intervention experiment that was deemed reasonably distinct from the first (e.g., the Experiment metadata for carbondive_sanfransiscobay_intervention01 were not representative of this intervention experiment, however it was still considered to be under the same project), the resulting Experiment ID is carbondive_20240120_sanfransiscobay_intervention02.

Example 2: Dr. Jane Smith is providing model output from two global studies, one from a counterfactual model run and one from a baseline model run, their resulting Project ID is smith_20241004_global, and Experiment IDs are smith_20241004_global_model01 and smith_20241004_global_model02.

^ Return to tABLE OF CONTENTS ^

Column Header Names

A fundamental principle of data standardization is ensuring consistent naming across data submissions, projects, and repositories. If your chosen repository does not enforce a vocabulary, please refer to the references below for recommended naming conventions. Recommended units are also frequently provided for each variable, which significantly eases the process of synthesizing data across projects when standardization is maintained.

Column header names are the labels given to specific data types, variables, or measurements in a data set, commonly presented as abbreviated names in column headers. Standardizing column header names significantly eases syntheses projects and ensures that a user can find data of interest. 

Data file templates are provided for download here that include common recommended column header names and header information.

^ Return to tABLE OF CONTENTS ^

Sensor-observed Variables

Column header abbreviations, their preferred units and brief descriptions for continuous measurements of oceanographic variables using sensors (for example on autonomous or remotely operated platforms, e.g., time-series mooring, uncrewed surface vehicles, underwater gliders, and profiling floats). “N/A” is short for “not applicable”. 

See General and Chemical Oceanographic Variables for additional chemical variable header names that are applicable to both bottle and sensor data (e.g., DIC, TA, pH, and nutrient data).

For data resulting from pigment or optical measurements, see the standardized fields and units provided by NASA SeaBASS.

ADCP output variable name examples are provided by Ocean Networks Canada under the Matlab structure example ‘adcp’, with recommended units provided under ‘units’.

Further naming conventions of less-common and diagnostic variables are provided by Argo.

^ Return to tABLE OF CONTENTS ^

Model Output Variables

For model output variable names, please refer to the CF naming conventions.

^ Return to tABLE OF CONTENTS ^

mCDR Pathways

^ Return to tABLE OF CONTENTS ^

Alkalinity Feedstock Processing

^ Return to tABLE OF CONTENTS ^

Dosing Delivery Type

^ Return to tABLE OF CONTENTS ^

Platform Type

Controlled vocabularies for Platform Types are based on Jiang et al., 2023b with minor updates.

^ Return to tABLE OF CONTENTS ^

Deprecated Standards and Practices

Previous versions of this protocol can be found on the host site. 

The versioning format is defined as follows,

Update definitions:

MAJOR: Significant changes, such as new sections, substantial revisions, or breaking changes to existing recommendations.

MINOR: Additions or refinements to existing recommendations that are backward-compatible.

REVISION: Small edits like fixing typos, formatting, or minor clarifications without changing the meaning or scope.

Triggers for updates:

1. MAJOR Version (e.g., `2.0.0`):

• Introduced a new framework or restructured the document.
• Added entirely new priority levels or sections.
• Removed or deprecated previous recommendations in a way that could affect adoption.
• Example: Moving from draft to the first official release (`0.1` → `1.0`).

2. MINOR Version (e.g., `1.2.0`):

• Added new recommendations that complement existing ones.
• Updated examples, case studies, or appendices without altering the core content.
• Clarified ambiguities in key recommendations while maintaining backward compatibility.

3. REVISION (e.g., `1.1.3`):

• Corrected grammar, typos, or formatting.
• Reworded text for readability without changing intent.
• Fixed links or citations.

^ Return to tABLE OF CONTENTS ^

References

Caserini, S., Storni, N., Grosso, M. (2022). The availability of limestone and other raw materials for ocean alkalinity enhancement. Global Biogeochemical Cycles 36, 5. https://doi.org/10.1029/2021GB007246. 

Dickson, A. G. (1990). Standard potential of the reaction: AgCl(s) + 0.5 H2(g) = Ag(s) + HCl(aq), and the standard acidity constant of the ion HSO4− in synthetic sea water from 273.15 to 318.15 K. Journal of Chemical Thermodynamics 22, 113–127. doi:10.1016/0021-9614(90)90074-Z.

Frankignoulle, M., Canon, C., and Gattuso, J.-P. (1994). Marine calcification as a source of carbon dioxide: Positive feedback of increasing atmospheric CO₂. Limnology and Oceanography 39, 458–462. doi:10.4319/lo.1994.39.2.0458.

Gunning PJ, Hills CD, Carey PJ. (2010). Accelerated carbonation treatment of industrial wastes. Waste Management, (6):1081-90. doi:10.1016/j.wasman.2010.01.005

Jiang, L. Q., Kozyr, A., Relph, J.M. et al. The Ocean Carbon and Acidification Data System. Sci Data 10, 136 (2023). https://doi.org/10.1038/s41597-023-02042-0

Jiang, L. Q., Subhas, A., Basso, D., Fennel, K., and Gattuso, J.-P. (2023). Data reporting and sharing for ocean alkalinity enhancement research, in: Guide to Best Practices in Ocean Alkalinity Enhancement Research (OAE Guide 23), edited by: Oschlies, A., Stevenson, A., Bach, L., Fennel, K., Rickaby, R., Satterfield, T., Webb, R., and Gattuso, J.-P., Copernicus Publications, State Planet, https://doi.org/10.5194/sp-2-oae2023-13-2023.

Jiang, L. Q.,  Pierrot, D., Wanninkhof, R., et al., (2022). Best Practice Data Standards for Discrete Chemical Oceanographic Observations. Front. Mar. Sci, 8. https://doi.org/10.3389/fmars.2021.705638.

Jiang, L. Q., O’Connor, S. A., Arzayus, K. M., & Parsons, A. R. (2015). A metadata template for ocean acidification data, Earth Syst. Sci. Data, 7, 117–125.

Lee, K., Kim, T.-W., Byrne, R. H., Millero, F. J., Feely, R. A., and Liu, Y.-M. (2010). The universal ratio of boron to chlorinity for the North Pacific and North Atlantic oceans. Geochimica et Cosmochimica Acta 74, 1801–1811. doi:10.1016/j.gca.2009.12.027.

Lueker, T. J., Dickson, A. G., and Keeling, C. D. (2000). Ocean pCO₂ calculated from dissolved inorganic carbon, alkalinity, and equations for K1 and K2: validation based on laboratory measurements of CO₂ in gas and seawater at equilibrium. Marine Chemistry 70, 105–119. doi:10.1016/S0304-4203(00)00022-0.

Orr J. C., Epitalon J.-M. & Gattuso J.-P.. (2015). Comparison of ten packages that compute ocean carbonate chemistry. Biogeosciences 12, 1483–1510. https://doi.org/10.5194/bg-12-1483-2015. 

Renforth P., Henderson G. (2017). Assessing ocean alkalinity for carbon sequestration. Reviews of Geophysics 55 (3), 636-674. https://doi.org/10.1002/2016RG000533.

Waters, J., Millero, F. J., and Woosley, R. J. (2014). Corrigendum to “The free proton concentration scale for seawater pH”, [MARCHE: 149 (2013) 8–22]. Marine Chemistry 165, 66–67. doi:10.1016/j.marchem.2014.07.

^ Return to tABLE OF CONTENTS ^