- Background and Terms of reference
- 1. Purpose of this document
- 2. Implementation of metadata convention
- 3. Global attributes
- 4. Summary of metadata categories
- 5. Description of metadata category table headers
- 6. Definition of attributes for active acoustic metadata
- 6.1. Category: Metadata record
- 6.2. Category: Mission attributes
- 6.3. Category: Cruise attributes
- 6.4. Category: Ship attributes
- 6.5. Category: Platform attributes
- 6.6. Category: Transect attributes
- 6.7. Category: Instrument attributes
- 6.8. Category: Ancillary instrumentation
- 6.9. Category: Calibration attributes
- 6.10. Category: Data acquisition attributes
- 6.11. Category: Data processing attributes
- 6.12. Category: Dataset attributes
- 6.13. Category: Data attributes
- 7. Revision history
- 8. Acknowledgements
- 9. References
- Appendix A: Standard lists of controlled vocabulary
- Appendix B: Metadata authorities
- Appendix C: Transducer orientation conventions
- Appendix D: Beam geometry
International Council for the Exploration of the Sea
Conseil International pour l’Exploration de la Mer
H. C. Andersens Boulevard 44-46
DK-1553 Copenhagen V
Denmark
Telephone (+45) 33 38 67 00
Telefax (+45) 33 93 42 15
www.ices.dk
[email protected]
Recommended format for purposes of citation:
ICES. 2020. A metadata convention for processed acoustic data from active acoustic systems. Series of ICES Survey Protocols SISP 4-TG-AcMeta. 48 pp.
Series Editor: Emory D. Anderson
The material in this report may be reused for non-commercial purposes using the recommended citation. ICES may only grant usage rights of information, data, images, graphs, etc. of which it has ownership. For other third-party material cited in this report, you must contact the original copyright holder for permission. For citation of datasets or use of data to be included in other databases, please refer to the latest ICES data policy on ICES website. All extracts must be acknowledged. For other reproduction requests please contact the General Secretary.
This document is the product of an Expert Group under the auspices of the International Council for the Exploration of the Sea and does not necessarily represent the view of the Council.
ISBN 978-87-7482-191-5
ISSN 2304-6252
© 2020 International Council for the Exploration of the Sea
The ICES Working Group on Fisheries Acoustics, Science and Technology (WGFAST) meeting in 2010, San Diego USA recommended the formation of a Topic Group that will bring together a group of expert acousticians to develop standardised metadata protocols for active acoustic systems. Through annual meetings in 2011-2013 and email correspondence the Topic Group on Acoustic Metadata (TG-AcMeta) developed a metadata convention for active acoustic data which is presented in this document.
The terms of reference for TG-AcMeta were “To develop standardised metadata protocols to suit requirements for data acquisition, processing, quality control and data dissemination of calibrated integrated active acoustic backscatter data. This includes data from a range of platforms such as Ships of Opportunity including research, merchant and commercial fishing vessels, moorings, AUV’s and acoustic instruments such as calibrated single- and multi-beam acoustic systems.”
Metadata is data describing data, and should allow potential users to determine the fitness for their purposes of that data from the metadata alone, without having to access the actual data. A metadata convention is a systematic set of metadata attributes that have been developed to describe a particular genre or type of data. This document describes a metadata convention that details the attribute fields necessary to describe water column backscatter data obtained from active acoustic systems.
This convention is not intended to conform to general metadata standards, such as Federal Geographic Data Committee (FGDC), International Organization for Standardization (ISO):19115/19139, etc., nor to describe a metadata profile consistent with such standards. Essentially it describes a set of attributes to be included with the acoustic data itself to make a fully self-documenting data set. In addition to these, it also defines best practice for storing and managing fisheries acoustic data by providing a standard approach. That said, the metadata elements described here include all those necessary to populate any aggregated (or even global) metadata catalogue describing the available bioacoustic datasets managed in multiple institutional repositories.
It is recommended that processed acoustic data is stored in SI units of linear sv (m-1). Depending on the purpose, acoustic backscattering data is sometimes stored in a number of other forms including Sv, volume backscatter in logarithmic form (dB re 1 m-1), area backscattering coefficient sa (m2 m-2), or scaled to nautical area scattering coefficient, sA (aka NASC, m2 nmi-2) cite:[maclennan2002,demer2015calibration]. The actual form of the backscattering data needs to be specified as part of the data attributes and the dimensions of the echo-integration cell also specified.
This convention was developed for processed acoustic data, but has relevance for archiving raw acoustic data. Processed acoustic backscatter data are generated by applying procedures to the instrument acquired acoustic data (i.e., raw data) that address data quality, calibration and, in many cases, resampling to a lower resolution than the acquired data. Unless stated otherwise in the metadata, appropriate calibration parameters and time varied gain (TVG) corrections will have been applied. Metadata attribute fields are provided that will allow description of processing procedures specific to the data set.
In many cases the cost of collecting acoustic data is significant and adhering to this metadata convention will facilitate the discovery, reuse, and exchange of processed acoustic data while ensuring its longevity.
This document describes a metadata convention for processed acoustic data. It is assumed that appropriate data and metadata management of unprocessed acoustic data files will be in place, discussion of which is beyond the scope of this document.
Processed acoustic data and metadata may be held in a variety of formats including, but not limited to, relational databases, Extensible Markup Language (XML), JavaScript Object Notation (JSON), Network Common Data Format (NetCDF) and Hierarchical Data Format (HDF). Storage of the data and associated metadata is a question of implementation and is not mandated or defined by this document. When choosing a data format some key considerations are ease of data exchange, visibility of data and metadata, and potential for automated harvesting of metadata. It is recommended that guidance and assistance from metadata experts are sought when realizing this metadata convention in a specific implementation format.
The metadata attribute fields in this document build on existing conventions and are presented following the NetCDF cite:[rew1990,unidata2017] format of global attributes. The global attributes describe the overall contents of the file and allow for data discovery. Global attributes can be thought of as conveying five kinds of information:
-
What: What are the data in the dataset?
-
Where: The spatial coverage of the data.
-
When: The temporal coverage of the data.
-
Who: Who produced the data?
-
How: How were the data produced and how are they being made available?
All fields should be human-readable and can be of either ‘character’ or ‘numeric’ type. Where applicable, metadata attribute definitions will state that controlled vocabulary should be used. Use of controlled vocabulary aids consistency, accuracy, interoperability, and data discovery. Standard lists for controlled vocabulary developed specifically for this metadata convention are given in Appendix A. If the appropriate words are not present in the standard list users should provide their own terminology. The standard lists can be extended according to user feedback to accommodate new terminologies in future versions of this metadata convention.
Wherever possible, the global attributes are based on established authorities. In some instances the metadata attribute may cite other authorities, while other metadata attributes may be unique to this metadata convention. Where they exist, the relevant authority is cited for each of the attribute fields. A table of the various metadata authorities is given in Appendix B.
The metadata attributes are grouped according to logical categories (Figure 1). This is done to help both author and reader navigate the metadata record, but it is important to note that this does not describe a formal hierarchical structure. The metadata record of this convention is effectively a continuous list. Thus each global attribute must have a unique name for it to be unambiguously identified. Attribute names that are sourced from existing authorities are by necessity identical to that used by the authority in order to facilitate automatic harvesting of metadata. To ensure uniqueness, non-authoritative attributes are prefixed with the category name of this metadata convention. White spaces or blank characters are not allowed in attribute names as these are not supported by some of the established authorities (e.g. CF, the NetCDF Climate and Forecast Metadata Convention) and the underscore ‘_’ character is used instead. Following the form of existing conventions, specific category of platform attributes has been developed to support development of metadata attribute fields for other acoustic systems (e.g. autonomous underwater vehicles, gliders, towed bodies, acoustic lenses, and parametric arrays).
There is no constraint on the addition of extra metadata attributes to fully describe a dataset. Such extra attributes would be a super-set of the attributes of this convention and might be specific to a particular institution but their presence would not violate this convention.
This section briefly outlines the grouping and hierarchical structure of metadata attributes used in this document.
- Metadata record
-
Uniform resource identifier (URI) that uniquely identifies the metadata record.
- Mission metadata
-
Metadata that gives a high-level description of the overarching initiative (e.g. mission, project, and ocean observing system) under which the acoustic data were collected.
- Cruise metadata
-
Attributes that describe the cruise from which the acoustic data were acquired. Metadata should provide information that readily enables the cruise to be identified and be aware of cruise objectives, other instrumentation, and data acquired.
- Ship metadata
-
Attributes that describe the ship from which acoustic data were collected. Metadata should provide information that uniquely identifies the ship and its basic specifications to enable an understanding of the type of ship and its purpose.
- Platform metadata
-
Attributes that describe the platform from which acoustic data were collected.
- Transect metadata
-
Attributes that describe transect data. Transect metadata would normally apply to acoustic data from a moving platform.
- Instrument metadata
-
Attributes that describe the acoustic instrument that recorded the raw data from which the processed data were derived.
- Ancillary instruments
-
Attributes that provide the opportunity to list ancillary instruments that may be of relevance to the acoustic data set.
- Calibration metadata
-
Attributes that describe calibration procedures with calibration accuracy and precision.
- Data acquisition metadata
-
Attributes that describe the data acquisition process.
- Data processing metadata
-
Attributes that describe the data processing procedures. Data processing procedures may be complex and difficult to capture in a simple list of attributes. Therefore links to documents that give more comprehensive descriptions of processing procedures should be given if appropriate.
- Dataset metadata
-
Attributes that describe the set of data. Some attributes will vary with each data file and may be automatically generated from the data file. When possible, automatic generation of dataset attribute metadata is preferred to reduce effort and the possibility of human error. Other attributes will need to be manually generated. In many cases attributes may be unchanged between datasets; hence the use of a metadata template which includes stable attributes may be beneficial.
- Data metadata
-
Attributes that describe the data in a dataset, including the type of scattering quantity that is stored and the data horizontal and vertical dimensions.
- Attribute name
-
Unique name for the attribute. When possible, names will conform to existing standards. Non-authoritative attributes are prefixed with the category name to ensure that they are unique. For example the 'name' attribute for cruise and ship categories are prefixed to be cruise_name and ship_name respectively. White space or blank characters are not allowed and the underscore ´_´ character is used instead. For this metadata convention all attribute fields are lowercase.
- Definition
-
Description of attribute.
- Data type
-
S for string, N for numeric.
- Units
-
If applicable, the units to be used for numeric attributes, using the SI standard.
- Authority
-
Where they exist, the relevant authority is cited for each of the attribute fields. The field is left blank if no authority exists.
- Obligation
-
Following Dublin Core documentation cite:[dublincore2004], Obligation ‘indicates whether the element is required always or sometimes be present. In this application profile, the obligation can be: mandatory (M), mandatory if applicable (MA), strongly recommended (R) or optional (O). Mandatory ensures that some of the elements are always supported and mandatory if applicable means that this element must be supported if the information is available. An element with a mandatory obligation must have a value. The strongly recommended and the optional elements should be filled with a value if the information is appropriate to the given resource but if not, they may be omitted.’ An example of an MA field would be attributes in the transect category that are only populated if the data relates to a mobile platform in some way.
- Maximum occurrences
-
Specifies the maximum number of instances of the attribute. Single occurrences are shown by ‘1’. Multiple, but specified number of occurrences, are indicated by ‘N’. A fixed number of occurrences are allowed (e.g., ‘2’, ‘3’, etc). For example, if the data comes from a cruise then the attribute field cruise_name is mandatory and applicable and has a maximum occurrence of 1.
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
convention_name |
Name of this convention. “A metadata convention for processed acoustic data from active acoustic systems”. |
S |
M |
1 |
||
convention_author |
“ICES WGFAST Topic Group, TG-AcMeta”. |
S |
M |
1 |
||
convention_year |
Publication year of metadata convention document (e.g. 2020). |
N |
M |
1 |
||
convention_organisation |
International Council for the Exploration of the Sea (ICES). |
S |
M |
1 |
||
convention_publisher |
The Series of ICES Survey Protocols (SISP). |
S |
M |
1 |
||
convention_version |
A label that states the convention version that the metadata conforms to. Must be of the form major.minor where major and minor are non-negative integers separated by a full stop, aka period (.). E.g. Version 1.10 would be the 10th revision of the version 1 series. Note for metadata versions prior to V1.10 the leading zeros in minor should be ignored (e.g. V1.05 is the 5th revision of the version 1 series). |
S |
M |
1 |
||
convention_reference |
Record the reference for this convention. Note that while the convention version label is included in the convention reference as per the example full entry below, the authoritative version label is given in the convention version attribute. Example of a full entry for this version is: “ICES. 2020. A metadata convention for processed acoustic data from active acoustic systems, TG-AcMeta Version 2.0, ICES WGFAST Topic Group, TG-AcMeta. 47 pp.”. |
S |
M |
1 |
||
uniform_resource_identifier |
Uniform resource identifier (URI) that uniquely identifies the name and location of the metadata record. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
mission_name |
Name of mission. |
S |
M |
1 |
||
mission_abstract |
Free text description of the mission, its purpose, scientific objectives and area of operation. Other instruments and experiments within the mission which may or may not relate directly to the acoustic data can be included. |
S |
M |
1 |
||
mission_start_date |
Start date of mission in ISO 8601 format including local time zone. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
M |
1 |
||
mission_end_date |
As per mission_start_date. |
S |
MA |
1 |
||
principal_investigator |
Name of the principal investigator in charge of the mission. |
S |
IMOS |
M |
1 |
|
principal_investigator_email |
Principal investigator e-mail address. |
S |
IMOS |
M |
N |
|
institution |
Name of the institute, facility, or company where the original data were produced. |
S |
CF |
M |
N |
|
data_centre |
Data centre in charge of the data management or party who distributed the resource. |
S |
IMOS |
M |
N |
|
data_centre_email |
Data centre contact e-mail address. |
S |
IMOS |
M |
N |
|
mission_id |
ID code of mission. |
S |
M |
1 |
||
mission_platform |
Platform type (see ICES controlled vocabulary here). For example, define 'Research vessel' if your mission platform is a research vessel. |
S |
M |
N |
||
creator |
An entity primarily responsible for making the resource. |
S |
Dublin core |
M |
N |
|
contributor |
An entity responsible for making contributions to the resource. |
S |
Dublin core |
M |
N |
|
mission_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
cruise_name |
Formal name of cruise as recorded by cruise documentation or institutional data centre. |
S |
MA |
1 |
||
cruise_description |
Free text field to describe the cruise. May include list of objectives of the cruise. For example scientific survey, commercial fishing, resupply, or combinations of these. |
S |
MA |
1 |
||
cruise_summary_report |
Published or web-based references that link to the cruise report. SeaDataNet - Pan-European Infrastructure for Ocean and Marine Data Management has a well developed Cruise Summary Report (CSR) system that is in wide use and follows ISO standards. Adoption of this format is recommended and may be obligatory for nations that participate in the SeaDataNet endeavour. See CSR for more information. Alternatively, institutional cruise reports should be referenced. If available, Digital Object Identifiers (DOI’s) should be given. |
S |
ICES/SeaDataNet |
MA |
1 |
|
cruise_area_description |
List main areas of operation (e.g. Southern Pacific Ocean, Chatham Rise Region, and Indian Ocean High Seas). |
S |
MA |
N |
||
cruise_start_date |
Start date of cruise in ISO 8601 format. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
MA |
|||
cruise_end_date |
see cruise_start_date. |
S |
IMOS |
MA |
1 |
|
cruise_id |
Cruise id where one exists. |
S |
IMOS |
O |
1 |
|
cruise_northlimit |
The constant coordinate for the northernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
cruise_eastlimit |
The constant coordinate for the easternmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
cruise_southlimit |
The constant coordinate for the southernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
cruise_westlimit |
The constant coordinate for the westernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
cruise_uplimit |
The constant coordinate for the uppermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
cruise_downlimit |
The constant coordinate for the lowermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
cruise_units |
The units of unlabelled numeric values of cruise_northlimit, cruise_eastlimit, cruise_southlimit, cruise_westlimit. Units specified as appropriate to the projection. E.g. geographic coordinates specify 'signed decimal degrees', UTM specify 'm'. |
S |
Dublin core* |
MA |
1 |
|
cruise_zunits |
The units applying to unlabelled numeric values of cruise_uplimit, cruise_downlimit. SI units are 'm'. |
S |
Dublin core* |
MA |
1 |
|
cruise_projection |
The name of the projection used with any parameters required, such as ellipsoid parameters, datum, standard parallels and meridians, zone, etc. |
S |
Dublin core* |
MA |
1 |
|
cruise_start_port |
Commonly used name for the port where cruise started. |
S |
O |
1 |
||
cruise_end_port |
Commonly used name for the port where cruise ended. |
S |
O |
1 |
||
cruise_start_BODC_code |
Name of port from where cruise starts. Recommend use of British Oceanographic Data Centre (BODC) port gazetteer. |
S |
BODC ports gazetteer |
O |
1 |
|
cruise_end_BODC_code |
see cruise_start_BODC_code. |
S |
BODC ports gazetteer |
O |
1 |
|
cruise_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
* Dublin core DCMI Bounding Box Encoding Scheme.
Attribute name | Definition | Data type | Units | Authority | Obligation | Occurrences |
---|---|---|---|---|---|---|
ship_name |
Name of the ship. |
S |
MA |
1 |
||
ship_type |
Describe type of ship that is hosting the acoustic instrumentation (see ICES controlled vocabulary here). For example, define 'Research vessel' if it is a research vessel. |
S |
MA |
1 |
||
ship_code |
For example, in-house code associated with ship, e.g. SS = Southern Surveyor or ship national identifier. |
S |
O |
1 |
||
ship_platform_code |
SeaDataNet Ship and Platform Codes at ICES (see here). Requests can be made to add new vessels to the database by contacting [email protected]. For example, define '33OA' for the ship 'Oscar Dyson'. |
S |
ICES/SeaDataNet |
MA |
1 |
|
ship_platform_class |
ICES controlled vocabulary for platform class (see here). For example, define '31' for 'Research vessel'. |
S |
ICES/SeaDataNet |
MA |
1 |
|
ship_callsign |
Ship call sign. |
S |
MA |
1 |
||
ship_alt_callsign |
Alternative call sign if the ship has more than one. |
S |
O |
1 |
||
ship_IMO |
Ship’s International Maritime Organisation ship identification number. |
S |
O |
1 |
||
ship_operator |
Name of organisation or company which operates the ship. |
S |
MA |
1 |
||
ship_home_port |
Home port of the ship. |
S |
MA |
1 |
||
ship_length |
Overall length of the ship. |
N |
m |
MA |
1 |
|
ship_breadth |
The width of the ship at its widest point. |
N |
m |
R |
1 |
|
ship_tonnage |
Gross tonnage of the ship. |
N |
t |
R |
1 |
|
ship_engine_power |
The total power available for ship propulsion. |
N |
kW |
R |
1 |
|
ship_noise_design |
For example, ICES 209 compliant cite:[mitson1995]. Otherwise description of noise performance of the ship. |
S |
R |
1 |
||
ship_acknowledgement |
Free text field to acknowledge the ship and ship operator. |
S |
R |
1 |
||
ship_comments |
Free text field for relevant information that might not be captured by the defined ship attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
platform_name |
Name of the platform. |
S |
MA |
1 |
||
platform_mobility |
Active acoustic systems are always associated with a platform. Controlled vocabulary for defining mobility of a platform is 'Mobile' or 'Fixed'. |
S |
M |
1 |
||
platform_type |
Type of platform hosting the acoustic instrumentation (see ICES controlled vocabulary here). For example, 'Autonomous underwater vehicle'. |
S |
MA |
1 |
||
platform_code |
In-house code associated with the platform. For example, define 'SD1007' for a Saildrone with vehicle number '1007'. |
S |
O |
1 |
||
platform_class |
ICES controlled vocabulary for platform class (see here). For example, define '25' for 'Autonomous underwater vehicle'. |
S |
MA |
1 |
||
platform_length |
Overall length of the platform. |
N |
m |
R |
1 |
|
platform_breadth |
The width of the platform at its widest point. |
N |
m |
R |
1 |
|
platform_description |
Free text field to describe the platform. This may include a description of the platform, its objectives, details about the cruise (if applicable) and other information relevant to the data being collected. |
S |
MA |
1 |
||
platform_site_name |
For example name of location where platform is deployed. |
S |
O |
1 |
||
platform_depth |
Seafloor depth at platform site. |
N |
m |
MA |
1 |
|
platform_northlimit |
The constant coordinate for the northernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
platform_eastlimit |
The constant coordinate for the easternmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
platform_southlimit |
The constant coordinate for the southernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
platform_westlimit |
The constant coordinate for the westernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
platform_uplimit |
The constant coordinate for the uppermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
platform_downlimit |
The constant coordinate for the lowermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
platform_units |
The units unlabelled numeric values of platform_northlimit, platform_eastlimit, platform_southlimit, platform_westlimit. Units specified as appropriate to the projection. E.g. geographic coordinates specify 'signed decimal degrees', UTM specify 'm'. |
S |
Dublin core* |
MA |
1 |
|
platform_zunits |
The units of unlabelled numeric values of platform_uplimit, platform_downlimit. SI units are 'm'. |
S |
Dublin core* |
MA |
1 |
|
platform_projection |
The name of the projection used with any parameters required, such as ellipsoid parameters, datum, standard parallels and meridians, zone, etc. |
S |
Dublin core* |
MA |
1 |
|
platform_deployment_date |
Start time of platform deployment in ISO 8601 format. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
MA |
1 |
||
platform_retrieval_date |
See platform_deployment_date. |
S |
MA |
1 |
||
platform_operator |
Name of organisation or company that operates the platform. |
S |
MA |
N |
||
platform_acknowledgement |
Free text field to acknowledge the platform and platform operator. |
S |
R |
1 |
||
platform_comments |
Free text field for relevant information that might not be captured by the defined platform attributes. |
S |
O |
1 |
* Dublin core DCMI Bounding Box Encoding Scheme.
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
transect_name |
Name of the transect. |
S |
O |
1 |
||
transect_id |
Identifier for the transect. |
S |
O |
1 |
||
transect_description |
Description of the transect, its purpose, and main activity. |
S |
MA |
1 |
||
transect_related_activity |
Describe related activities that may occur on the transit. |
S |
O |
1 |
||
transect_start_time |
Start time of the transect in ISO 8601 format. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
MA |
1 |
||
transect_end_time |
see transect_start_time. |
S |
MA |
1 |
||
transect_northlimit |
The constant coordinate for the northernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
transect_eastlimit |
The constant coordinate for the easternmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
transect_southlimit |
The constant coordinate for the southernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
transect_westlimit |
The constant coordinate for the westernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
transect_uplimit |
The constant coordinate for the uppermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
transect_downlimit |
The constant coordinate for the lowermost face or edge in the vertical, z, dimension. |
N |
Dublin core* |
MA |
1 |
|
transect_units |
The units of unlabelled numeric values of transect_northlimit, transect_eastlimit, transect_southlimit, transect_westlimit. Units specified as appropriate to the projection. E.g. geographic coordinates specify 'signed decimal degrees', UTM specify 'm'. |
S |
Dublin core* |
MA |
1 |
|
transect_zunits |
The units of unlabelled numeric values of transect_uplimit, transect_downlimit. SI units are 'm'. |
S |
Dublin core* |
MA |
1 |
|
transect_projection |
The name of the projection used with any parameters required, such as ellipsoid parameters, datum, standard parallels and meridians, zone, etc. |
S |
Dublin core* |
MA |
1 |
|
transect_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
* Dublin core DCMI Bounding Box Encoding Scheme.
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
instrument_frequency |
Frequency of the transceiver/transducer combination in kHz. Some systems such as broadband and multi-beam will have a range of frequencies. If so, specify the minimum, maximum and centre frequency. |
S |
kHz |
M |
1 |
|
instrument_transducer_location |
Location of installed transducer. Refer to Section A.1 for a list of standard transducer locations. |
S |
M |
1 |
||
instrument_transducer_manufacturer |
Transducer manufacturer. |
S |
M |
1 |
||
instrument_transducer_model |
Transducer model. |
S |
M |
1 |
||
instrument_transducer_beam_type |
For example 'single-beam, split-aperture'. See controlled vocabulary table for transducer types in Section A.2. |
S |
M |
1 |
||
instrument_transducer_serial |
Transducer serial number. |
S |
R |
N |
||
instrument_transducer_depth |
Mean depth of transducer face beneath the water surface. |
N |
m |
O |
1 |
|
instrument_transducer_orientation |
Direction perpendicular to the face of the transducer. A simple description for a ship mounted sounder would be 'downward looking', a mooring could be 'upward looking'. If required Appendix C provides a comprehensive description of transducer orientation conventions. |
S |
M |
1 |
||
instrument_transducer_psi |
Manufacturer specified transducer equivalent beam angle, expressed as \(10 \log_{10}(\psi)\), where \(\psi\) has units of steradians. Note this value is not necessarily used for processing. Check data processing attributes. |
N |
dB |
R |
1 |
|
instrument_transducer_beam_angle_major |
Major beam opening, also referred to athwartship angle. See Appendix D for description of beam geometry conventions. |
N |
degrees |
R |
1 |
|
instrument_transducer_beam_angle_minor |
Minor beam opening, also referred to alongship angle. See Appendix D for description of beam geometry conventions. |
N |
degrees |
R |
1 |
|
instrument_transceiver_manufacturer |
Transceiver manufacturer. |
S |
M |
1 |
||
instrument_transceiver_model |
Transceiver model. |
S |
M |
1 |
||
instrument_transceiver_serial |
Transceiver serial number. |
S |
R |
1 |
||
instrument_transceiver_firmware |
Transceiver firmware version. |
S |
R |
1 |
||
instrument_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
ancillary_instrumentation |
List suite of instruments and other equipment (e.g. net systems, CTD, ADCP) potentially relevant to the acoustic data set. |
S |
O |
N |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
calibration |
Attribute to define processed acoustic data is calibrated or not. Controlled vocabulary is ‘Yes’ if data is calibrated and ‘No’ if not. |
S |
M |
1 |
||
calibration_date |
Date of calibration in ISO 8601 format including local time zone. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
MA |
1 |
||
calibration_acquisition_method |
Describe the method used to acquire calibration data (see Section A.3, Standard lists). |
S |
MA |
1 |
||
calibration_processing_method |
Describe method of processing that was used to generate calibration parameters (e.g. Section ‘4.1.2.3 On-axis calibration’ from Demer, D., Berger, L., Bernasconi, M., Bethke, E., Boswell, K., Chu, D., Domokos, R., et al. 2015. Calibration of acoustic instruments. ICES Cooperative Research Report No. 326. 133 pp.). |
S |
MA |
1 |
||
calibration_accuracy_estimate |
Estimate of calibration accuracy. Include a description and units so that it is clear what this estimate means (e.g. estimate might be expressed in dB or as a percentage). |
S |
MA |
1 |
||
calibration_report |
URL or references to external documents which give a full account of calibration processing and results may be appropriate. |
S |
MA |
1 |
||
calibration_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
data_acquisition_software_name |
Name of software that controls echosounder and its data logging. |
S |
R |
1 |
||
data_acquisition_software_version |
Version of software that controls echosounder and its data logging. |
S |
R |
1 |
||
data_acquisition_stored_data_format |
Name of the format in which data is stored. For example Simrad raw format, HydroACoustics (HAC) format. |
S |
M |
1 |
||
data_acquisition_ping_duty_cycle |
Free text field to describe ping duty cycle. For a ship system this may be continuous pinging at a certain rate. For a mooring this may describe the duty cycle. For example 10 minutes pinging at 1 ping per second, followed by 50 minute sleep mode. |
S |
M |
1 |
||
data_acquisition_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
data_processing_software_name |
Name of software that was used to process raw acoustic data. |
S |
M |
N |
||
data_processing_software_version |
Version of software that was used to process raw acoustic data. |
S |
M |
N |
||
data_processing_triwave_correction |
Applies to Simrad ES60 and ES70 echosounders only. The raw data from Simrad ES60/ES70 echosounders are modulated with a triangle wave error sequence with a 1 dB peak-to-peak amplitude and a 2720 ping period. Controlled vocabulary is ‘Yes’ if error has been corrected, ‘No’ if not corrected, and 'Not applicable' for echosounders other than Simrad ES60/ES70. See also pages 63-64 of Demer, D. A., Berger, L., Bernasconi, M., Bethke, E., Boswell, K., Chu, D., and Domokos, R. et al. 2015. Calibration of acoustic instruments. ICES Cooperative Research Report No.326: 133 pp. |
S |
MA |
1 |
||
data_processing_channel_id |
Unique identifier for each data channel. |
S |
R |
1 |
||
data_processing_bandwidth |
Bandwidth associated with processed data. |
N |
kHz |
R |
1 |
|
data_processing_frequency |
Transmit frequency associated with processed data. |
N |
kHz |
M |
1 |
|
data_processing_transceiver_power |
Nominal transceiver power. |
N |
W |
M |
N |
|
data_processing_transmit_pulse_length |
Transmit pulse length. |
N |
ms |
M |
N |
|
data_processing_on_axis_gain |
Total system gain value when calibration sphere is on-axis. This term accounts for whole of system calibration including the power source, the transducer directivity multiplied by its efficiency, and any other gains or losses through the echosounder system including the transducer cable. It is commonly denoted as Go in the sonar equation. Echoview software refers to it as the Transducer Peak Gain and EK60 systems refer to it as 'Ek60TransducerGain'. Simrad refers to this as Transducer Gain with symbol 'G' in their EK60 manual. Note: manufacturers of other echosounders may express calibration in different terms and users are encouraged to propose new attributes be added to this metadata convention that will meet their specific needs. In the meantime additional or different calibration parameters can be described in the data_processing_comments field as appropriate. Alternatively a superset of discrete calibration parameters specific to the particular system can be added to the metadata record. |
N |
M |
N |
||
data_processing_on_axis_gain_units |
Units for the data_processing_on_axis_gain attribute. Units may be in dB for some systems (e.g. Simrad) but on other instruments may be dimensionless numeric values. |
S |
M |
1 |
||
data_processing_Sacorrection |
Area backscattering coefficient sa (m2 m-2) correction factor (Simrad transceivers). |
N |
dB |
MA |
1 |
|
data_processing_absorption |
Nominal absorption coefficient value used for data processing. If absorption profile was used, give appropriate description in the data_processing_absorption_description field. |
N |
dB m-1 |
MA |
1 |
|
data_processing_absorption_description |
Describe (i) equation used to calculate absorption, (ii) source of input data into absorption calculation (e.g. model, XBT, CTD), (iii) arithmetic or geometric mean of depth-absorption profile or nominal value applied to entire data set. e.g. (i) Equation: Francois and Garrison 1982, (ii) WOCE98 model, (iii) nominal value for entire data set. |
S |
R |
1 |
||
data_processing_soundspeed |
Nominal sound speed value used used for data processing. If sound speed profile was used, give appropriate description in the data_process_soundspeed_description field. |
N |
m s-1 |
MA |
1 |
|
data_processing_soundspeed_description |
Describe (i) equation used to calculate sound speed, (ii) source of input data into sound speed calculation (e.g. model, XBT, CTD), (iii) arithmetic or geometric mean of depth-absorption profile or nominal value applied to entire data set. e.g. (i) Equation: Mackenzie 1981, (ii) WOCE98 model, (iii) nominal value for entire data set. |
S |
R |
1 |
||
data_processing_transducer_psi |
Transducer equivalent two-way beam angle used for data processing, expressed as \(10 \log_{10}(\psi)\), where \(\psi\) has units of steradians. |
N |
dB |
M |
1 |
|
data_processing_transducer_beam_angle_major |
Major beam opening used for data processing, also referred to athwartship angle. See Appendix D for description of beam geometry conventions. |
N |
degrees |
MA |
1 |
|
data_processing_transducer_beam_angle_minor |
Minor beam opening used for data processing, also referred to alongship angle. See Appendix D for description of beam geometry conventions. |
N |
degrees |
MA |
1 |
|
data_processing_motion_correction |
Attribute to define transducer motion correction is applied or not. Controlled vocabulary is ‘Yes’ if correction has been applied and ‘No’ if not. |
S |
MA |
1 |
||
data_processing_motion_correction_description |
A reference for commonly used transducer motion correction if applied is (e.g. Dunford, A. J. 2005. Correcting echo-integration data for transducer motion. The Journal of the Acoustical Society of America, 118: 2121-2123). |
S |
MA |
1 |
||
data_processing_amplifier_linearity_correction |
Attribute to define whether correction has been made for amplifier non linearity. Controlled vocabulary is ‘Yes’ if correction has been applied, ‘No’ if not and 'Not applicable' if it is not applicable. |
S |
MA |
1 |
||
data_processing_amplifier_linearity_correction_description |
The reference for this correction, if applied, is De Robertis, A. et al. 2019. Amplifier linearity accounts for discrepancies in echo-integration measurements from two widely used echosounders. ICES Journal of Marine Science, 76 :1882–1892. See Figure 8a. Please provide extra comments as required to describe the actual correction method. |
S |
MA |
1 |
||
data_processing_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
project |
The scientific project that produced the data. |
S |
NACDD |
M |
1 |
|
title |
Short description of the dataset. |
S |
NUG |
M |
1 |
|
abstract |
A paragraph describing the dataset: type of data contained in the dataset, how the data was created, the creator of the dataset, the mission for which the data was created, the geospatial coverage of the data, the temporal coverage of the data. Manually generated attribute. |
S |
IMOS |
M |
1 |
|
history |
Provides an audit trail for modifications to the original data. It should contain a separate line for each modification, with each line beginning with a timestamp and including user name, modification name and modification arguments. Manually generated attribute. |
S |
NUG |
R |
N |
|
comment |
Miscellaneous information about the data or methods used to produce it. Any free-format text is appropriate. Manually generated attribute. |
S |
CF |
O |
N |
|
keywords |
A comma separated list of key words and phrases. Keywords are an important tool in data discovery and the use of words or phrases from 'standard' vocabularies is encouraged to maximise the discoverability of the data by others. The use of keywords from the Global Change Master Directory (GCMD) vocabulary is recommended. The GCMD keywords list can be downloaded from here. Non-GCMD keywords may be used at your discretion, but consideration should be given to using keywords from other standard catalogues (e.g. BODC) if there are no applicable GCMD keywords. |
S |
NACDD |
M |
N |
|
references |
Published or web-based references that describe the data or the methods used to produce the data. If available, Digital Object Identifiers (DOI’s) should be given. |
S |
CF |
M |
N |
|
doi |
Digital Object Identifier (DOI) for project documentation. |
S |
IDF |
O |
N |
|
citation |
The citation to be used in publications using the dataset should follow the format: "ProjectName. [year-of-data-download], [Title], [Data access URL], accessed [date-of-access]". Manually generated attribute. |
S |
IMOS |
M |
N |
|
license |
Describe the restrictions to data access and distribution. For example visit Australian National Data Service website which incorporates Creative Commons licences. |
S |
NACDD |
M |
1 |
|
author_email |
Email address of the person responsible for the creation of the dataset. |
S |
IMOS |
M |
N |
|
author |
Name of the person responsible for the creation of the dataset. |
S |
IMOS |
M |
N |
|
distribution_statement |
Statement describing data distribution policy, e.g., re-packagers of this data should include a statement that information about data quality and lineage is available from the metadata record and a statement that data, products and services from are provided "as is" without any warranty as to fitness for a particular purpose. |
S |
IMOS |
M |
1 |
|
date_created |
The date on which the data was created in ISO 8601 format. Will vary with each data file, possibly automatically generated. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). |
S |
NACDD |
M |
N |
|
northlimit |
The constant coordinate for the northernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
eastlimit |
The constant coordinate for the easternmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
southlimit |
The constant coordinate for the southernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
westlimit |
The constant coordinate for the westernmost face or edge. |
N |
Dublin core* |
MA |
1 |
|
uplimit |
The constant coordinate for the uppermost face or edge in the vertical, z, dimension. Reference edge for this attribute is the water surface. |
N |
Dublin core* |
MA |
1 |
|
downlimit |
The constant coordinate for the lowermost face or edge in the vertical, z, dimension. Reference edge for this attribute is the water surface. |
N |
Dublin core* |
MA |
1 |
|
units |
The units of unlabelled numeric values of northlimit, eastlimit, southlimit, westlimit. Units specified as appropriate to the projection. E.g. geographic coordinates specify 'signed decimal degrees', UTM specify 'm'. |
N |
Dublin core* |
MA |
1 |
|
zunits |
The units of unlabelled numeric values of uplimit, downlimit. SI units are 'm'. |
N |
Dublin core* |
MA |
1 |
|
projection |
The name of the projection used with any parameters required, such as ellipsoid parameters, datum, standard parallels and meridians, zone, etc. |
S |
Dublin core* |
MA |
1 |
|
dataset_linestring |
OGC:SFS/WKT compliant LINESTRING geometry representing each transect. A LineString consists of a sequence of two or more vertices, along with all points along the linearly-interpolated curves (line segments) between each pair of consecutive vertices. |
S |
O |
N |
||
time_coverage_start |
Start date of the data in UTC Date format is ISO 8601. For example, a local time of 18:00 on the 24th of October 2008 would be represented as 2008-10-24T08:00:00Z +10 (local). Will vary with each data file, possibly automatically generated. |
S |
NACDD |
M |
1 |
|
time_coverage_end |
see time_coverage_start. |
S |
NACDD |
M |
1 |
|
dataset_comments |
Free text field for relevant information that might not be captured by the defined attributes. |
S |
O |
1 |
It is usual and recommended for the cell dimensions (ping-axis interval and range-axis interval) to be stored for each data value to be stored with the data. These cell dimensions should also be defined in the metadata if possible. If cell dimensions do vary within the dataset then they cannot be specified in the metadata record and it will be essential that they are stored with the data. Similarly it is expected that time and position (if appropriate) of each data value will be stored with the data.
Attribute name | Definition | Data type | Units | Authority | Obligation | Maximum occurrences |
---|---|---|---|---|---|---|
data_acoustic_datatype |
In what form is the acoustic data stored? Controlled vocabulary options include :
see also citenp:[maclennan2002]. |
S |
M |
|||
data_ping_axis_interval_type |
Ping-axis interval by which data have been binned. Controlled vocabulary includes:
User-defined interval types can be used if not on controlled vocabulary list. |
S |
M |
1 |
||
data_ping_axis_interval_origin |
Location of ping axis interval value in the ping axis interval. Controlled vocabulary includes: Start Middle End |
S |
M |
1 |
||
data_ping_axis_interval_value |
Numeric value for data ping axis interval according to its specified type Examples: (1) data_ping_axis_interval_type: Time (seconds) data_ping_axis_interval_value: 600 (2) data_ping_axis_interval_type: Distance (metres) data_ping_axis_interval_value: 1000 (3) data_ping_axis_interval_type: Number of pings data_ping_axis_interval_value: 300 Notes: If ping axis interval values vary within each dataset they cannot be specified as a single number in this metadata record. Leave this record blank if this is the case. Note that it would be usual for the ping axis interval information to be stored at the same level as the data itself. |
N |
MA |
1 |
||
data_range_axis_interval_type |
Range-axis interval by which data has been binned. Controlled vocabulary includes: Range (metres) Time (seconds) User-defined interval type can be used if not on controlled vocabulary list. |
S |
M |
1 |
||
data_range_axis_interval_origin |
Location of ping axis range value in the range axis interval. Controlled vocabulary includes: Start Middle End |
S |
m |
M |
1 |
|
data_range_axis_interval_value |
Numeric value for data range axis interval according to its specified type, e.g. data_range_axis_interval_type: Range (metres) data_range_axis_interval_value: 10 SI units are 'm' Notes: If range axis interval values vary within each dataset they cannot be specified as a single number in this metadata record. Leave this record blank if this is the case. Note that it would be usual for the range axis interval information to be stored at the same level as the data itself. |
N |
MA |
1 |
Version | Date | Changes |
---|---|---|
1.04 |
21 August 2014 |
Altered obligations on attributes from Mandatory (M) or Mandatory if Applicable (MA) to recommended (R) for ship_breadth, ship_tonnage, ship_engine_power, ship_noise_design and ship_acknowledgements.
|
1.10 |
10 May 2016 |
The ICES Data Centre (Hjalte Parner, Nils Olav Handegard) is constructing an Acoustic Trawl Survey database with the intention of implementing the ICES Acoustic Metadata Standard. Through this process a number of new and existing attribute fields were discussed. This revision documents the consequent changes that were made as described below.
Revised convention version. Previous versions were using a decimal number series - e.g. version 1.01, 1.02 etc. limiting the minor number series to 99 revisions. This revision alters the convention to follow the more common convention in the computer world where the version number is described by two integers separated by a full stop. Thus following this convention our previous version 1.05 would now be version 1.5, that is the 5th revision in version 1 series. This version 1.10 is the 10th revision of the version 1 series. |
2.0 |
17 Feburary 2020 |
Moved to ICES Publications GitHub page for user input.
|
Present and past members of ICES WGFAST Topic Group on Acoustic Metadata (TG-AcMeta) are acknowledged for facilitating metadata standards and developing this convention document.
Some temporary citations cite:[simmonds2005,foote1987] because of a bug in asciidoctor, whereby citations inside tables are not seen (asciidoctor/asciidoctor-bibtex#39).
bibliography::[]
Hull, keel |
Hull, drop keel |
Hull, blister |
Hull, gondola |
Towed, shallow |
Towed, deep |
Towed, deep, trawl net attached |
Ship, pole |
Type | Comments |
---|---|
Single-beam |
Single beam. |
Single-beam, split-aperture |
Single beam transducer with elements divided into groups to provide information on the direction of arrival of echoes. Typically four equal sectors but other groupings are possible. |
Multi-beam |
Multiple single beams. |
Multi-beam, split-aperture |
Multiple single beams with elements divided into groups to provide information on the direction of arrival of echoes. Typically four equal sectors per beam but other groupings are possible. |
Method | Comments |
---|---|
Standard sphere, in-situ |
As per citenp:[foote1987,demer2015calibration,simmonds2005]. |
Standard sphere, tank |
|
Standard sphere, other |
|
Reciprocity |
|
Hydrophone |
|
Seafloor reflection |
|
Nominal |
For example, As per manufacturer’s nominal specification. |
Intership |
For example, comparison between echo integration from two ships in the same regions either as a relative difference, or comparing results from an uncalibrated ship to those from a calibrated ship. |
NetCDF |
|
NUG |
|
COARDS |
|
CF |
|
NACDD |
|
Dublin Core |
|
IMOS |
|
BASOOP |
|
OceanSITES |
|
UDUNITS |
|
ISO8601 |
|
MMI |
|
IDF |
|
SeaDataNet |
Pan-European infrastructure for ocean and marine data management |