4. Metadata content

The following sections describe elements which are part of the MERIDIAN metadata profile. Some of these elements are collected during the MERIDIAN metadata submission process, which thus form a subset of the complete MERIDIAN metadata profile. The order of elements is important.

As in ISO 19139-2:2012, many elements have an expected value of another class, and some classes are reused multiple times. This results in a complex nesting of elements. As well, some codelists are very long, and can not be feasibly included alongside their elements without substantially disrupting the readability of their containing class. As such, hyperlinks have been included to facilitate digital navigation between relevant classes and codelists. Each section in this document describes a class, and a table within that section lists the elements it contains. That table also lists the values contained within those elements.

Because of the sheer number of elements, some descriptions and best practices may be reproduced from other sources without full attribution. Refer to the normative references for details regarding sources used.

Some elements may be used internally on the MERIDIAN metadata submission form, but not be changeable by a user. These have been left in this document should someone wish to manually craft their own metadata record.

Not all elements native to ISO 19139-2:2012 or Darwin Core have been included here. These omitted elements are technically permitted, but were deemed less important to acoustic oceanography.

4.1. gmi:MI_Metadata

Changes from ISO 19115:2003: New in ISO 19115-2:2009, an extension of gmd:MD_Metadata to add gmi:acquisitioninformation.

Description: This class contains elements which describe the metadata and the core components which describe the resource. The ‘top level’ class which encases all others. This is also the top-level element for an XML document based on ISO 19115-2:2009. It must also have attributes declaring each namespace used within the document. Refer to example XML documents for details on the unique reference identifier used for namespaces within the MERIDIAN portal.

Element name	Obligation	Value type	Description	Best practice
fileIdentifier	M-1	Free text	A (locally or universally) unique identifier which labels the metadata record.	Use a universally unique identifier (UUID). A version 1 UUID is generated by MERIDIAN via the submission form.
language	M-1	Free text	Language and regional dialect of the metadata record.	Combine an ISO 639-2 three letter language code and an ISO 3166-1 three letter country code, separated by a semicolon. This is currently hidden from the submission form, as the only form language is English.
characterSet	M-1	Codelist - MD_CharacterSetCode	Character encoding of the metadata record.	Most XML documents use UTF-8 encoding. This is currently hidden from the submission form, as the only form encoding is UTF-8.
parentIdentifier	O-1	Free text	The unique name (or fileIdentifier) of a record related to the current file but more general.	If a parent exists, identify it. If there is more than one parent, Aggregation Information (within MER:MD_DataIdentification) may be used instead.
hierarchyLevel	M-R	Codelist - MD_MetadataScopeCode	The type or scope of the resource to which the metadata applies.	Is this metadata about a specific dataset, a series of datasets…?
contact	M-R	Class - CI_ResponsibleParty	The person or people who can be contacted regarding this metadata content.	Person or organization responsible for providing the metadata. May be different from the data owner or creator. Repeat for each person or organization responsible. This information is used internally by MERIDIAN, and not displayed on our discovery portal.
dateStamp	M-1	ISO 8601 Date or DateTime	The date (and optionally time) the metadata was created. (not last updated)	A date is expressed as yyyy-mm-dd, while a DateTime is expressed as yyyy-mm-ddThh:mm:ss±cc:cc, where ±cc:cc is the offset from UTC (timezone). UTC-0 (GMT) is marked with Z instead of ±cc:cc.
metadataStandardName	M-1	Free text	The metadata standard or rule set followed when creating the record.	This document (the MERIDIAN profile) should be referenced. Hidden on the submission form.
metadataStandardVersion	M-1	Free text	The specific version of the standard or rule set used.	The version of this document (the MERIDIAN profile) which was used should be referenced. Hidden on the submission form.
distributionInfo	M-1	Class - MD_Distribution	Information about how to acquire the resource.	Contains descriptions of how to access the resource(s), whether via a link, or whether a particular person may be contacted to request access.
dataQualityInfo	M-R	Class - DQ_DataQuality	Data quality info for the described resource (not the metadata), within a specified scope.	May be repeated for each relevant scope of data quality which applies. For the submission form, we request this field at least once for all objects, to describe the overall data quality. For experimental datasets, we also require information on the collection session itself.
contentInfo	O-R	Class - MD_CoverageDescription (or others, not shown)	Characteristics of the resource coverage (among others).	Recommended that this class be used to contain details on modelled variables.
gmi:acquisitionInformation	O-R	Class - gmi:MI_AcquisitionInformation	Information about the platform, instruments, etc., which collected the data.	Strongly recommended to provide information here whenever describing experimental datasets

4.1.1. MD_CoverageDescription

Changes from ISO 19115:2003: The conditionality of the dimension element has been changed. We also recommend a specific choice of contentType.

Description: For describing the coverage within a resource.

Element name	Obligation	Value type	Description	Best practice
attributeDescription	M-1	RecordType (contains free text)	Description of the cell measurement.	We recommend this is used to briefly describe what has been modelled.
contentType	M-1	Codelist - MD_CoverageContentTypeCode	Information represented by the cell.	For model variables, we recommend only using thematicClassificiation.
dimension	M-R	Class - MD_Band	Information on the dimension of the cell measurement value.	Repeat for each variable you wish to describe. Alternate classes are possible, but MD_Band is the only one used on the submission form.

4.1.1.1. MD_Band

Changes from ISO 19115:2003: Extended to include non-EM wavelengths and general sensors.

Description: For describing the sensor data collected. Though the class was originally intended for electromagnetic wavelengths (e.g., light), the class is adaptable to include acoustic frequencies as well.

Element name	Obligation	Value type	Description	Best practice
sequenceIdentifier	M-1	gco:MemberName, which contains a gco:aName, which contains a gco:CharacterString	Sensor band wavelengths.	Recommend that the identifier be chosen from a controlled vocabulary, e.g., the Climate and Forecast standard name table.
descriptor	O-1	Free text	Description of cell value range.	Recommended to include free-text description of relevant sensor parameters here.
maxValue	O-1	Positive real number	Longest or largest value the sensor can collect in the designated band.	E.g., the highest acoustic frequency detectable. Not shown on the MERIDIAN submission form.
minValue	O-1	Positive real number	Shortest or smallest value the sensor can collect in the designated band.	E.g., the lowest acoustic frequency detectable. Not shown on the MERIDIAN submission form.
units	C-1	A gml-style unit (not described here).	The units of the sensor. Stored in BaseUnit, ConventionalUnit, or DerivedUnit elements, which are not described here.	Provide units if maxValue or minValue are reported. BaseUnits are for the core SI units (e.g., kilograms, metres, seconds…), DerivedUnits only involve multiplication or division of BaseUnits (e.g., velocity in metres per second), and ConventionalUnits are for everything else (e.g., degrees Fahrenheit).
peakResponse	O-1	Positive real number	The sensor response to the maxValue.	Helps determine conversion factors from the sensor units to real values.
bitsPerValue	O-1	Integer	Maximum number of significant bits in the uncompressed representation for the value in each band of each pixel.	Effectively determines the smallest changes the sensor can detect.
toneGradation	O-1	Integer	Number of discrete numerical values in the data.	Relates to the actual resolution of the sensor.
scaleFactor	O-1	Positive real number	The scaling factor which is applied to each cell value.	Helps determine conversion factors from the sensor units to real values.
offset	O-1	Real number	The physical value which corresponds to a cell value of zero (that is, when the sensor reads 0, what does that physically correspond to?).	Helps determine conversion factors from the sensor units to real values.

4.2. MER:MD_DataIdentification

Changes from ISO 19115:2003: Modified from gmd:MD_DataIdentification to add Darwin Core. Custom namespace used to incorporate these changes. Conditionality of language and characterSet changed to better match ISO 19115-1:2014.

Description: Information describing a resource (e.g., a dataset). It should uniquely identify the available resource.

Element name	Obligation	Value type	Description	Best practice
citation	M-1	Class - CI_Citation	Information on how the resource described within should be cited.	Include authors, title, and contact information for at least one author.
abstract	M-1	Free text	The abstract for the resource. A narrative summary explaining what the resource is about or contains.	Include information on content, features, time period… Model data, such as physics and forcing parameters, may also be included.
purpose	O-1	Free text	The reason the resource was created.	Recommended. Include details on the objectives of the resource as well - e.g., was the resource funded based on a specific intended outcome?
status	M-R	Codelist - MD_ProgressCode	Current status of the resource - e.g., is it in development, finished, etc.?	Note that certain statuses are mutually contradictory.
pointOfContact	M-R	Class - CI_ResponsibleParty	Identification and means to contact the people or organizations responsible for the resource.	Include at least one person (ideally the data owner or data curator) - but repeat as many times as appropriate. Must include contact information for at least one author.
resourceMaintenance	M-R	Class - MD_MaintenanceInformation	Details on the frequency and scope of updates, as well as the party responsible for updating the resource.	Note that this is not strictly the same as the pointOfContact, as it should include details on perpetual maintenance for ‘live’ resources.
descriptiveKeywords	M-R	Class - MD_Keywords	Commonly used words and phrases which describe the resource.	Include at least one keyword to aid in discovery. Use field-specific terminology whenever possible.
resourceConstraints	M-R	Class - One of MD_Constraints, MD_LegalConstraints, or MD_SecurityConstraints	Restrictions on access or use of the resource.	Include at least a free text description in MD_Constraints. Note that while MD_Constraints is provided by default, MD_LegalConstraints and MD_SecurityConstraints can be used in preference to MD_Constraints.
aggregationInfo	O-R	Class - MD_AggregateInformation	Linkage to the aggregate resource, and optionally details on the activity which produced the described resource.	Useful for resources which have a common origin project, or models which have a common source model.
language	C-R	Free text	The primary language and dialect of the resource.	Required when the resource contains textual content. Combine an ISO 639-2 three letter language code and an ISO 3166-1 three letter country code, separated by a semicolon. Although multiple entries are allowed, the submission form only collects a single entry.
characterSet	C-R	Codelist - MD_CharacterSetCode	The character encoding used in the resource.	Required when the resource contains textual content. Choose a value for each unique character encoding. However, we recommend that a resource only contain one type of encoding when possible, as it could complicate reuse.
topicCategory	M-R	Codelist - MD_TopicCategoryCode	A general topic which describes the theme of the resource. Required by ISO 19115 and INSPIRE.	Add a new topic category for each additional theme.
environmentDescription	O-1	Free text	Description of the processing environment of the resource.	Most relevant for datasets containing software, model data, or mixed raw and analyzed data. E.g., was this dataset only analyzed on a supercomputer cluster, or was it processed using a ten year old Windows 3.1 system? This helps other users know what to expect when using the data.
extent	C-R	Class - EX_Extent	The spatial and temporal coverage of the resource.	Required for datasets and series of datasets. Not required for model data, but recommended to identify the spatial and temporal extent of validity within the model.
supplementalInformation	O-1	Free text	Any additional information about the resource you wish to include.	Do not duplicate content from the Abstract or Purpose.
dwr:DarwinRecordSet	O-R	Refer to section dwr:DarwinRecordSet	Information on any species detected and other animal events which occur in the resource.	Strongly recommended for any acoustic recordings which have been processed to identify species, calls, etc.

4.2.1. MD_Keywords

Description: Commonly used words or phrases (within the expert community most closely connected to the resource) that describes the resource. A keyword type describing how the keyword relates to the resource may also be provided.

Additional comments: Additional keyword types and thesauri may be added by the user.

MERIDIAN has created two codelists, SeaVoX platform types and Acoustic experimental parameters, which are used to create a recommended keyword list on the MERIDIAN submission form. It is not necessary to strictly adhere to these codelists.

Element name	Obligation	Value type	Description	Best practice
keyword	M-R	Free text	The keywords proper.	Include at least one keyword for each of the default types and thesauri.
type	O-1	Codelist - MD_KeywordTypeCode	A term or type to group multiple keywords together.	Recommended to include a type for all new groups of keywords.

4.2.2. MD_AggregateInformation

Description: The type of an aggregate resource, a way to identify or locate said resource (e.g., name or identifier), and optionally the activity type which produced the described resource (not the aggregate resource).

Additional comments: Only link ‘up’ the chain - do not link from an aggregate resource to smaller resource subsets. If a resource is subdivided in multiple ways, this could cause confusion to readers. For example, consider an aggregate dataset comprised of multiple AIS receiver logs. In the scenario where ‘down’ chain linking occurs, an aggregate dataset would need to link to “north shore” AIS logs, “west shore” AIS logs, etc., which may overlap in definition or scope.

Changes from ISO 19115:2003: The obligation of fields has been changed compared to core ISO 19139-2:2012, to focus on the ones we deemed most useful for discovery.

Element name	Obligation	Value type	Description	Best practice
aggregateDataSetName	M-1	Class - CI_Citation	A citation to the aggregate resource.	Include sufficient detail to unambiguously locate the aggregate resource.
associationType	M-1	Codelist - DS_AssociationTypeCode	How the resource and the aggregate resource are related.	Select from the codelist as appropriate.

4.3. CI_Citation

Description: ISO 19115 format for citation details.

Element name	Obligation	Value type	Description	Best practice
title	M-1	Free text	Name of the (cited, or to-be cited) resource.	The exact name as written on the resource proper or as it should be written in a citation.
date	M-R	Class - CI_Date	An event and the date of the event in the life of the resource.	Repeat for each major event, such as publication, revision, retraction…
identifier	O-R	Class - MD_Identifier	Unique identifier for the cited document.	If an identifier exists for the resource or publication (such as a DOI), record the identifier here.
citedResponsibleParty	M-R	Class - CI_ResponsibleParty	Who created the resource. Repeat for each person or organization.	Provide at least one author for each cited document. If necessary, an author can be an organization.
otherCitationDetails	O-1	Free text	Other information which may be necessary to complete a citation.	E.g., “accessed on” for citations to digital documents.

4.3.1. CI_Date

Description: A class for describing specific dates, often related to a specific object, resource, or activity. E.g., creation, publication, revision, expiry.

Element name	Obligation	Value type	Description	Best practice
date	M-1	ISO 8601 Date or DateTime	The date (and time) of the chosen type of date	A date is expressed as yyyy-mm-dd, while a DateTime is expressed as yyyy-mm-ddThh:mm:ss±cc:cc, where ±cc:cc is the offset from UTC (timezone). UTC-0 (GMT) is marked with Z instead of ±cc:cc.
dateType	M-1	Codelist - CI_DateTypeCode	The type of date described (e.g., creation, revision).	Note that different date types require separate instances of CI_Date.

4.4. CI_ResponsibleParty

Changes from ISO 19115:2003: MERIDIAN has omitted the positionName element, as we did not believe it provided sufficient information to identify a party in the absence of other information. A CI_ResponsibleParty class containing solely a positionName and a role would not be accepted via the MERIDIAN service.

Description: A generic class which describes a party, person, group, organization, or specific personnel position.

Element name	Obligation	Value type	Description	Best practice
individualName	C-1	Free text	The name of the responsible person. Enter names in the order Last name, First Name. Initials can follow the first name and should be followed by a period.	One of these two elements must be present and filled in.
organisationName	C-1	Free text	The name of the responsible organization (e.g., Dalhousie University Libraries).
contactInfo	C-1	Class - CI_Contact	Contact information for the named party.	Mandatory at least once when CI_ResponsibleParty is used in the context of MI_Metadata/Contact, MD_DataIdentification/Citation/citedResponsibleParty and MD_DataIdentification/PointOfContact/
role	M-1	Codelist - CI_RoleCode	The function of the named party with respect to the contextual object.	When multiple roles apply, select the role which most closely matches the most significant output of the named party with respect to the contextual object.

4.4.1. CI_Contact

Changes from ISO 19115:2003: Previously, phone and address were considered equivalent and both were conditional. In the MERIDIAN profile, simply providing a phone number is no longer acceptable. The conditions regarding the address element were also changed.

Description: Details on how to contact named parties.

Element name	Obligation	Value type	Description	Best practice
phone	O-1	Class - CI_Telephone	Provides telephone or fax numbers to contact a named party.	A phone number is recommended in preference to a fax number. This can be used to replace an email address if strictly necessary.
address	C-1	Class - CI_Address	Provides physical and electronic mailing addresses	An email address (in this class) is required for at least one party in most contexts of CI_ResponsibleParty.
contactInstructions	O-1	Free text	Other instructions to facilitate contact with a named party.	E.g., “Working office hours are from…”

4.4.1.1. CI_Telephone

Changes from ISO 19115:2003: Fax numbers were previously equivalent to voice telephone numbers. MERIDIAN opted to focus on telephone numbers in preference to fax numbers, making fax numbers optional rather than conditional, and thus making telephone numbers mandatory.

Description: Telephone numbers for named parties.

Element name	Obligation	Value type	Description	Best practice
voice	M-R	Free text	Voice telephone number for a named party.	Provide at least one entry whenever CI_Telephone is used.

4.4.1.2. CI_Address

Changes from ISO 19115:2003: Physical address information is hidden as it was deemed not useful for an online discovery portal. Online resource (essentially a web page address) was made optional as opposed to conditional. This was done to reduce the need for metadata users to request external websites in order to obtain basic contact information. Electronic mailing address was made mandatory when CI_Address is called.

Description: Physical and electronic addresses for named parties.

Element name	Obligation	Value type	Description	Best practice
electronicMailAddress	M-R	Free text	Email address for a named party.	The first provided address should correspond with the most appropriate or frequently used address for the party. E.g., if the CI_ResponsibleParty is a specific professor, provide their email address rather than the email address of their department, or a general inquiries address for their university.

4.4.1.3. CI_OnlineResource

Changes from ISO 19115:2003 North American Profile: In the North American profile, protocol is a mandatory element. We make use of the protocol on our submission form, but it is not strictly necessary to do so - provided the linkage element contains the protocol within it.

Description: Details on web-based resources for citations or named parties.

Element name	Obligation	Value type	Description	Best practice
linkage	M-1	URL	The internet location of the online resource.	Do not include the protocol here.
protocol	C-1	Free text	How to connect to the online resource.	HTTPS, HTTP, FTP, are example values for this element. Required for NAP compliant metadata and when the protocol is not uniquely identified by the linkage.

4.5. Constraints

General constraints are divided into 3 related sub-classes. MD_Constraints is the simplest, top level, class, which is inherited by the two more specific classes.

For use on the MERIDIAN submission form, we have compiled a list of common data and software licenses, beginning with Common data licenses. These are inserted in a structured way into the useLimitation field alongside basic access terms of the resource and the cost of accessing the resource.

For example, open; free; GPL3 refers to software that is openly accessible, free to access/use, and licensed under GPL3.

To craft your own MERIDIAN compatible string, the first word should be one of open, closed, or restricted, the second word should be free or paid, and the third word should be the short form of the license. Separate each word by a semicolon. To provide additional details, add another semicolon and any other text.

4.5.1. MD_Constraints

Changes from ISO 19115:2003: The obligation of useLimitation was changed from M-R to M-1. As it is a free text field, we preferred to ensure all relevant information was in one field, rather than repeated, as this could lead to confusion.

Description: The most generic way to describe constraints, it is solely composed of the useLimitation element.

Element name	Obligation	Value type	Description	Best practice
useLimitation	M-1	Free text	Statement on the fitness of use or limitations on the use of the resource.	Provide a free-text description of any applicable constraints.

4.5.2. MD_LegalConstraints

Description: More specific constraints appropriate for intellectual property concerns, privacy concerns, etc.

Inherits from MD_Constraints.

Element name	Obligation	Value type	Description	Best practice
useLimitation (Inherited from MD_Constraints)	M-1	Free text	Statement on the fitness of use or limitations on the use of the resource.	Provide a free-text description whenever a constraint is described.
accessConstraints	O-R	Codelist - MD_RestrictionCode	Limitations on access to the resource.	Select the most applicable values from the codelist.
useConstraints	O-R	Codelist - MD_RestrictionCode	Limitations on using the resource	Select the most applicable values from the codelist.
otherConstraints	C-R	Free text	Other restrictions or prerequisites to using the resource	Required when an MD_RestrictionCode has a value of “otherRestrictions”.

4.5.3. MD_SecurityConstraints

Description: More specific constraints appropriate for national security concerns.

Inherits from MD_Constraints.

Element name	Obligation	Value type	Description	Best practice
useLimitation (Inherited from MD_Constraints)	M-1	Free text	Statement on the fitness of use or limitations on the use of the resource.	Provide a free-text description whenever a constraint is described.
classification	M-1	Codelist - MD_ClassificationCode	Level of the specific handling restrictions on the resource.	Select the most applicable value from the codelist.
userNote	O-1	Free text	An explanation of the classification level applied.	Why was the object assessed as requiring this classification?
classificationSystem	O-1	Free text	Name of the security classification system.	That is, under what rules or agency was classification assessed?
handlingDescription	O-1	Free text	Additional information regarding security restrictions when handing the resource.	E.g., Statistics Canada microdata can only be handled at specified locations.

4.6. DQ_DataQuality

Changes from ISO 19115:2003: Data quality reporting (gmd:report) and lineage were both conditional, with at least one of those required. Lineage was deemed more important, and so became mandatory.

Description: Information of the quality of the resource or contextual object specified by a scope.

The actual data quality reporting aspect of this class has been omitted from this document, as it was deemed overly complex for inclusion on the discovery portal.

Element name	Obligation	Value type	Description	Best practice
scope	M-1	Class - DQ_Scope	The extent of characteristics or data for which quality information is reported	Repeat the DQ_DataQuality element if there are multiple scopes for data quality.
lineage	M-1	Class - LI_Lineage	The information (or lack thereof) of events and source data used to construct the data within the specified scope.	I.e., the ‘history’ of the resource, in a narrative format.

4.6.1. DQ_Scope

Changes from ISO 19115:2003: The conditionality of levelDescription was changed from conditional to optional.

Description: A class designed to describe how much of the resource is covered by a particular data quality measure.

Element name	Obligation	Value type	Description	Best practice
level	M-1	Codelist - MD_ScopeCode	The level for which data quality is described.	Generally this should include the whole resource, but optionally sub-elements of the resource may have their own quality report.
extent	O-1	Class - EX_Extent	The physical or temporal for which data quality is described.	E.g., “because we stopped for the day at this location, the data quality report is only valid until that point”
levelDescription	O-1	Class - MD_ScopeDescription	Description of the level of the resource.	Recommended that a description is provided if the level is not the same as hierarchyLevel (with MD_MetadataScopeCode).

4.6.1.1. MD_ScopeDescription

Changes from ISO 19115:2003: Originally, MD_ScopeDescription allowed selecting one of 6 elements, as appropriate. MERIDIAN opted to focus on the singular ‘other’ element which allowed free text entry, which was deemed sufficiently flexible to describe any situation.

Description: Used to specify the precise amount or subset of data which is referenced.

Element name	Obligation	Value type	Description	Best practice
other	M-1	Free text	Text specification of the range and extent which is covered within the scope.	E.g., “Data within the bounding box with north-east coordinates [X, Y] and south-west coordinates [A, B]”

4.6.2. LI_Lineage

Changes from ISO 19115:2003: statement was made mandatory, which due to the original conditionality makes the other elements optional.

Description: The general history of the resource.

Element name	Obligation	Value type	Description	Best practice
statement	M-1	Free text	General explanation of the resource history and/or lineage.	That is, what has been done to the data?
source	O-R	Class - LI_Source	Information on the sources used in the development of the resource.	Use when describing models which make use of specific data sources.

4.6.2.1. LI_Source

Description: Details on the data source which was used to create or build a resource.

Element name	Obligation	Value type	Description	Best practice
description	M-1	Free text	Free text description of the source data.	Provide and fill at least one of description, citation, or extent.
sourceCitation	M-1	Class - CI_Citation	Citation for the sources in the resources.

4.7. MD_Identifier

Description: A generic identifier class which can be used for DOIs, URLs, etc.

Element name	Obligation	Value type	Description	Best practice
authority	O-1	Class - CI_Citation	Reference to the party responsible for the identifier.	E.g., if this is a DOI, include a citation to the DOI authority.
code	M-1	Free text	The specific alphanumeric value that identifies a reference.	Could be a UUID, a DOI, a URL, or a unique (local) name.

4.8. MD_MaintenanceInformation

Changes from ISO 19115:2003: Made ‘contact’ conditional instead of optional, to ensure it is captured when updates are planned.

Description: Details on maintenance and updates of a resource.

Element name	Obligation	Value type	Description	Best practice
maintenanceAndUpdateFrequency	M-1	Codelist - MD_MaintenanceFrequencyCode	How frequently are charges made to the resource?	Select the most appropriate value from the codelist.
dateOfNextUpdate	O-1	ISO 8601 Date or DateTime	The next scheduled revision.	If an update is planned, identify the expected date here. A date is expressed as yyyy-mm-dd, while a DateTime is expressed as yyyy-mm-ddThh:mm:ss±cc:cc, where ±cc:cc is the offset from UTC (timezone). UTC-0 (GMT) is marked with Z instead of ±cc:cc.
userDefinedMaintenanceFrequency	O-1	gts:TM_PeriodDuration	If maintenance period is not well-defined by the codelist, provide further details here.	Uses the ISO 8601 duration of a period format. E.g., P5DT4H30.7M represents a period of 5 days, 4 hours and 30.7 minutes - that is, an event recurring every 5 days, 4 hours, and 30.7 minutes.
contact	C-R	Class - CI_ResponsibleParty	Information on and contact details for the party responsible for maintenance.	If an update is planned, provide contact details for who is (currently) expected to perform the update. This may be different from the authors or metadata creators, e.g., in the case of a resource originally produced by a temporary staff member, uploaded by a technician, and currently maintained by a separate staff member.

4.9. MD_Distribution

Changes from ISO 19115:2003: Originally, either distributionFormat or distributor were required, with transferOptions being optional. To encourage data linkage and discoverability, MERIDIAN decided that the format was required, but insufficient for discovery purposes, and so the distribution and transferOptions elements were instead made conditional.

Description: Intended for describing the physical and electronic structure of a resource, how said resource is delivered to users, and by whom.

Element name	Obligation	Value type	Description	Best practice
distributionFormat	M-R	Class - MD_Format	The format of the resource during distribution.	Provide at least one format that the resource is available in.
distributor	C-R	Class - MD_Distributor	Information about the distributor.	Conditional: At least one of these two elements is required. Use transferOptions if the file is available via direct download link. Otherwise, use distributor.
transferOptions	C-R	Class - MD_DigitalTransferOptions	The means and media by which the resource is obtained from the distributor.

4.9.1. MD_Format

Description: Describes the electronic format of the resource. Generally a file type or file encoding scheme.

Element name	Obligation	Value type	Description	Best practice
name	M-1	Free text	The name of the format.	Recommended that MIME file types are used to provide a controlled vocabulary.
version	M-1	Free text	The version of the format.	If unknown, provide the version of the software which generated the above format.

4.9.2. MD_Distributor

Changes from ISO 19115:2003: Because distributionFormat in MD_Distribution is mandatory, distributorFormat here is optional instead of conditional.

Description: The party which delivers the resource to users and details on the delivery process itself.

Element name	Obligation	Value type	Description	Best practice
distributorContact	M-1	Class - CI_ResponsibleParty	Information on the distributor.	Since this is not repeatable, we recommend details on the organization are provided in preference to details on a specific individual. Must include contact information (usually email address).
distributionOrderProcess	M-R	Class - MD_StandardOrderProcess	How to obtain the resource being distributed.	Describe at least one order process.

4.9.2.1. MD_StandardOrderProcess

Changes from ISO 19115:2003: The other elements in MD_StandardOrderProcess were made optional, as opposed to conditional, and orderingInstructions was instead made mandatory, as it was deemed sufficiently general to handle the content of the other elements in a worst-case scenario.

Description: Describes how a user purchases or otherwise acquires a resource from the distributor.

Element name	Obligation	Value type	Description	Best practice
orderingInstructions	M-1	Free text	General instructions, terms, and services provided by the distributor.	This is where information such as “access provided upon request” may be recorded.

4.9.3. MD_DigitalTransferOptions

Description: Contains details regarding the transfer of electronic data, either online or off. Limited in MERIDIAN submission form to online.

Element name	Obligation	Value type	Description	Best practice
onLine	M-R	Class - CI_OnlineResource	Linkage to the online sources for the resource.	Include the link to download the resource here when digital transfer is available.

4.10. EX_Extent

Description: Used to describe the physical and temporal extent of a resource.

Provide at least one of the elements listed here when EX_Extent is used.

Element name	Obligation	Value type	Description	Best practice
description	O-1	Free text	Text description of the extent for the object which refers to EX_Extent.	Provide a description whenever the other elements are not present or may be imprecise.
geographicElement	M-R	Class - EX_BoundingPolygon or EX_GeographicBoundingBox	Series of classes for various ways to describing geographic areas. Choose the one which most accurately reflects the object which refers to EX_Extent.	We recommend the use of bounding boxes in general.
temporalElement	M-R	Class - EX_TemporalExtent	The time period(s) which are relevant for the object which refers to EX_Extent.	When called from MD_DataIdentification, always provide at least one temporalElement. The time period(s) should be those corresponding to data collection.

4.10.1. EX_BoundingPolygon

Description: For describing a polygon (arbitrary closed shape) which encompasses the physical extent.

Element name	Obligation	Value type	Description	Best practice
polygon	M-R	gml:Point or gml:Polygon (refer to ISO 19107:2003, clause 6.2.2)	A set of coordinates defining an area covered by a resource.	Polygons are preferred.

Additional comments: gml:Point can be created with a gml:pos class containing a coordinate tuple and with an attribute describing the spatial reference system. It also has an attribute containing an identifier for the specific point. E.g.,

<gml:Point gml:id="1">
        <gml:pos srsName="http://www.opengis.net/def/crs/EPSG/0/4326">45.67 88.56</gml:pos>
</gml:Point>

gml:Polygon has a mandatory exterior ring and optional interior rings which define the boundaries of the polygon. It also has an attribute describing the spatial reference system, and an attribute containing an identifier for the specific polygon. These rings are formed with gml:LinearRing classes, generally filled with a single gml:posList class containing a sequence of coordinate tuples.

E.g.,

<gml:Polygon gml:id="2" srsName="WGS84">
        <gml:interior>
                <gml:LinearRing>
                        <gml:coordinates decimal=" 156.86274,71.34815 -156.87389,71.33893 -156.88004,71.33883 -156.89144,71.33259 -156.89982,71.33182 156.86274,71.34815 "/>
                </gml:LinearRing>
        </gml:interior>
</gml:Polygon>

4.10.2. EX_GeographicBoundingBox

Description: Describes the physical extent of a resource using two latitudes and two longitudes, which appears as a square box in (non-transverse) cylindrical map projections, such as the Mercator projection.

Element name	Obligation	Value type	Description	Best practice
westBoundingLongitude	M-1	Decimal number in [-180, +180]	The westernmost coordinate of the extent	Ensure east value is greater than west value.
eastBoundingLongitude	M-1	Decimal number in [-180, +180]	The easternmost coordinate of the extent
southBoundingLatitude	M-1	Decimal number in [-90, +90]	The southernmost coordinate of the extent	Ensure north value is greater than south value.
northBoundingLatitude	M-1	Decimal number in [-90, +90]	The northernmost coordinate of the extent

4.10.3. EX_TemporalExtent

Description: Contains the time period during which the resource was active, collected, or prepared.

Element name	Obligation	Value type	Description	Best practice
extent	M-1	TM_Primitive (see ISO 19108:2003, clause 5.2.2)	The date and time, or period of time, which describes the content in the resource.	TM_Primitive is abstract and can be described with a single instant in time or a period of time. Strongly recommend that a period is used to represent data collection or the period over which a model is simulated.

Additional comments: TM_Primitive can represent one of 4 classes - TM_Instant, TM_Period, TM_Node, and TM_Edge. We only recommend using the first two, as the latter are topological measurements of time and thus are not absolute measures.

TM_Instant is a position in time. It has a single attribute - position, which is associated with a temporal reference system.

TM_Period is an extent in time. It has two attributes, TM_Period.begin and TM_Period.end, which are positions associated with a temporal reference system.

4.11. MI_AcquisitionInformation

Changes from ISO 19115:2003: New in ISO 19115-2:2009. Given that all elements here are optional, we require that whenever MI_AcqusitionInformation is called, at least one element is provided. For experimental datasets, we strongly recommend using this class.

Description: Contains details on the sensors, instruments, and platforms (bodies which hold sensors and instruments) which were used in the collection of the resource. Also contains information on overall acquisition ‘operations’, such as projects, cruises, or other distinct activities.

In terms of overall resource scope, Operation is more general than Platform, which is more general than Instrument. Choose the most general appropriate scope for your resource here, and use its associated class to contain information on more specific components.

Element name	Obligation	Value type	Description	Best practice
gmi:instrument	C-R	Class - MER:MI_Instrument	Details on the instrument, sensor, or device used to acquire data.	Choose one of these three elements. This should include information on specific sensors, converters, and signal processing equipment used. Do not use if instrument is contained in platform already.
gmi:operation	C-R	Class - gmi:MI_Operation	Details on the ‘operation’ which produced data.	Choose one of these three elements. A comprehensive research project would qualify as an operation.
gmi:platform	C-R	Class - gmi:MI_Platform	Details on the platform from which data were acquired.	Choose one of these three elements. This may include details on the gliders, ships, buoys, or satellites used in data collection. Do not use if you are describing a platform within an operation already.

4.11.1. MER:MI_Instrument

Changes from ISO 19115-2:2009: Specified a codelist for the ‘type’ element (mapped into a free text field) to boost internal consistency. Added the relatedEvents element from ISO 19115-2:2019’s equivalent MI_Instrument class (The original gmi:MI_Instrument can be used if MER:relatedEvents is not used).

Description: Extension of gmi:MI_Instrument. Intended to provide information about sensors and instruments used in data collection.

Element name	Obligation	Value type	Description	Best practice
gmi:citation	O-R	Class - CI_Citation	Reference to supporting instrument documentation.	For example, available open manuals, chip layouts, or papers which describe the functioning of an instrument.
gmi:identifier	M-1	Class - MD_Identifier	Unique identifier for the instrument.	E.g., an instrument’s serial number.
gmi:type	M-1	Codelist - OOI Instrument types	The general type of instrument	Choose an instrument type from the controlled vocabulary.
gmi:description	O-1	Free text	Description of the instrument.	Focused on the technical aspects, rather than the appearance or aesthetic aspects.
gmi:mountedOn	O-1	Class - gmi:MI_Platform	The platform on which the instrument is mounted.	Not recommended due to circular referencing. Only move from broader project scope to narrow (Operation > Platform > Instrument).
MER:history	O-1	Class - MER:MI_InstrumentationEventList	Record of an event which occurred related to the specific instrument.	E.g., time periods during which an instrument was under over-voltage conditions.

4.11.1.1. MER:MI_InstrumentationEventList

Changes from ISO 19115:2003: New in ISO 19115-2:2019. Also changed from ISO 19115-2:2019 is that at least one instrumentationEvent is required.

Description: Class which describes the list of events for a given instrument.

Element name	Obligation	Value type	Description	Best practice
MER:description	M-1	gco:CharacterString	Language and character set used to describe other events	Filled by the MERIDIAN submission form with ENG; CAN as the language and UTF-8 as the character set.
MER:instrumentationEvent	M-R	MER:MI_InstrumentEvent	Describe individual events in the life of the instrument.	Report any events which would impact the quality of the instrument’s data or otherwise aid in understanding the instrument.

4.11.1.1.1. MER:MI_InstrumentEvent

Changes from ISO 19115:2003: New in ISO 19115-2:2019.

Description: Class which describes a singular event for an instrument.

Element name	Obligation	Value type	Description	Best practice
MER:description	M-1	gco:CharacterString	Free text description of the event	Provide details such as time or duration of event with respect to the resource, the effect on the resource and instrument, and any other relevant details.
MER:type	M-1	codelist: MER:MI_EventTypeCode	Select the specific type of event which most closely matches the event being described.	If the event touches on multiple values, select the most relevant one and offer an explanation in the description.

4.11.2. MI_Operation

Description: Intended to contain details on a cruise, project, or other undertaking which generated data.

Note that MERIDIAN would prefer if events are described with their associated instruments, rather than within this element.

Element name	Obligation	Value type	Description	Best practice
gmi:description	O-1	Free text	Description and objectives of the operation.	A project overview from a planning document would be suitable.
gmi:citation	C-1	Class - CI_Citation	Reference to the operation specification and identification.	Provide whichever over the two most accurately identifies the specific operation being described, both if possible.
gmi:identifier	C-1	Class - MD_Identifier	A unique identifier for the operation.
gmi:type	O-1	Codelist - MI_OperationTypeCode	The general type of operation described.	Select the most appropriate value from the codelist.
gmi:status	M-1	Codelist - MD_ProgressCode	The status of data acquisition within the operation.	Select the most appropriate value from the codelist.
gmi:platform	O-R	Class - gmi:MI_Platform	Other platforms used in this operation.	For example, if you are describing a dataset collected by ship during a joint project, you might describe the other ships in the project here.
gmi:significantEvent	O-R	Class - gmi:MI_Event	Record of an event which occurred during the operation.	E.g., timestamps of significant sounds during acoustic data acquisition.

4.11.2.1. MI_Event

Description: Intended for containing the details of specific identifiable events which occurred during data collection.

Element name	Obligation	Value type	Description	Best practice
gmi:identifier	M-1	Class - MD_Identifier	A unique code or name for the event.	Provide sufficient details to uniquely identify the event within the context of the operation or instrument.
gmi:trigger	M-1	Codelist - MI_TriggerCode	How was this event identified?	E.g., automatic versus manual detection.
gmi:context	M-1	Codelist - MI_ContextCode	What is the context of the event?	More specifically, the experimental and geographic context of the event.
gmi:sequence	M-1	Codelist - MI_SequenceCode	Where within the context did the event occur?	Select the appropriate value from the codelist.
gmi:time	M-1	ISO 8601 DateTime	The date and time the event occurred.	A date is expressed as yyyy-mm-dd, while a DateTime is expressed as yyyy-mm-ddThh:mm:ss±cc:cc, where ±cc:cc is the offset from UTC (timezone). UTC-0 (GMT) is marked with Z instead of ±cc:cc.
gmi:relatedSensor	O-R	Class - MER:MI_Instrument	The instrument(s) which records changes due to the event.	That is, a CTD instrument may record a change due to a lightning strike, but it is unlikely to record a change due to a whale. Only recommended for use when called from MI_Operation, to avoid circular referencing.

4.11.3. MI_Platform

Description: Intended to contain details on the system on which sensors or instruments are deployed, or potentially deployed from.

Element name	Obligation	Value type	Description	Best practice
gmi:citation	O-1	Class - CI_Citation	Reference to information describing the platform.	E.g., a published manual or paper describing the platform.
gmi:identifier	M-1	Class - MD_Identifier	Unique identifier for the platform.	E.g., a serial number.
gmi:description	M-1	Free text	Narrative description of the platform.
gmi:sponsor	O-R	Class - CI_ResponsibleParty	The organization(s) which built, launched, operated, or otherwise participated in developing the platform.	Ideally, this would be groups of people, rather than individual people.
gmi:instrument	M-R	Class - gmi:MER:MI_Instrument	All instruments mounted on the platform.	NB: Do not use the “mountedOn” element on any instruments within this element, as it will result in circular referencing.

4.12. dwr:DarwinRecordSet

Description: Contains all Darwin Core elements.

Darwin Core follows a different structure as compared to ISO 19115, and so some elements of Darwin Core are less straightforward to implement or use when compared to the rest of this manual. However, as both have a well-defined XML implementation, it is possible to combine them together to some degree.

The following peculiarities should be noted. First, Darwin Core makes use of existing Dublin Core elements. Thus, the ‘namespace’ of elements may be either “dcterms”, referring to Dublin Core, or “dwc”, referring to Darwin Core. Refer to the section on namespaces for more details.

Second, Darwin Core specifies no mandatory or conditional elements, and allows unlimited repetition. Thus, by the convention so far, all Darwin Core elements have an obligation of O-R. However, to ensure consistent records, we have modified the obligations of many terms. In general, we recommend that each class contain no repeated elements, but classes themselves can be repeated. Thus, ‘top-level’ classes have a multiplicity of R, while elements themselves have a multiplicity of 1.

Third, metadata values do not have types. They are all, effectively, free text, and there is no need to call gco:CharacterString whenever the type is listed as ‘free text’. They can simply be entered as a value in XML. However, we mandate that some values are specific data types, e.g., ISO 8601 dates, to improve interoperability, but do not require the use of any gco namespaces such as gco:Date. We also recommend controlled vocabularies be used whenever possible to reduce possible divergence between records. E.g., taxon names could be taken from the World Register of Marine Species. We note recommended controlled vocabularies whenever possible.

MERIDIAN’s submission form imposes a logical structure on Darwin Core. The ‘root’ class is dwc:Occurrence. This is used to contain information about a specific annotation set. It also contains basisOfRecord, for noting whether it was a machine-generated or human-generated annotation set.

‘Within that’ - though in the underlying XML, it is merely connected via identifiers - is dwc:Event, which provides details on how the annotations were made. We strongly recommend including details on sampling protocols for the annotations here - e.g., how the large amount of audio was parsed into annotations.

Also ‘within that’ is information on the identification process(es) - dwc:Identification - which may have been applied to those annotations. This refers specifically to the process by which meaning was ascribed to specific sounds. We assume that this generally ascribes a biological meaning to the sounds, so it is then linked to dwc:Taxon. There may also be multiple identification processes, each reflecting a particular focus or specialization.

dwc:Taxon is then used to describe the species which were identified. This is repeated for each individual species which was identified within that specific identification session.

Finally, if specific animals were detected, they should be described within dwc:Organism and linked with their associated dwc:Taxon.

4.12.1. Classes in DarwinRecordSet

Class name	Obligation	Description	Best practice
dwc:Occurrence	M-R	A class for recording a specific manifestation, or evidence of existence, of an organism (see below) at a specific time and place.	E.g., a specific animal sighting or a specific animal call.
dwc:Organism	O-R	A class of terms for either a single organism, a specific group of organisms, or a taxonomically homogeneous group of organisms.	E.g.,if you are reporting on a specific school of whales, you would use this class.
dwc:Event	O-R	A class to describe any action localized in both space and time.	E.g., a specific sampling event or deployment.
dwc:Identification	O-R	A class describing a specific taxonomic determination and details on how it was performed.	Whenever a Darwin Core record is used, provide details on the observed species and how they were observed.
dwc:Taxon	O-R	A class containing data on the taxon of an organism.	Must be used when an Identification has been performed.

4.12.2. Record level elements

These are elements which may be used in any of the above classes. However, we limit the basisOfRecord to a single occurrence in the whole record, describing how organisms were observed.

Many record level elements are automatically populated using other elements and values from ISO 19115.

Element name	Obligation	Value type	Description	Best practice
dwc:basisOfRecord	M-1 per record	Codelist - dwc:dwc:BasisOfRecordList	Select the appropriate observation type from the Darwin Core classes.	That is, was it observed by machines or humans observations? Recommended inside dwc:Occurrence.
dwc:informationWithheld	O-1 per Class	Free text	Brief description of information may exist in the data, but is not being shared.	E.g., “no endangered species are identified in this record”.
dwc:occurrenceID	C-1 per Class	Free text	A unique identifier to the specific occurrence tied to this event. Used to cross-link elements in the Darwin Core record.	May be a UUID or a unique name within the context of the described resource. These are created automatically by the MERIDIAN submission form as UUIDs. The intent is to keep the various pieces of the record which are connected linked in a consistent manner. Refer to the description above for details on the structure of the Darwin Core elements.
dwc:organismID	C-1 per Class	Free text	A unique identifier for a specific organism in the record. Used to cross-link elements in the Darwin Core record.
dwc:eventID	C-1 per Class	Free text	A unique identifier for the specific event or observation of relevance. Used to cross-link elements in the Darwin Core record.
dwc:identificationID	C-1 per Class	Free text	A unique identifier for a specific identification. Used to cross-link elements in the Darwin Core record.
dwc:taxonID	C-1 per Class	Free text	A unique identifier for a specific taxon. Used to cross-link elements in the Darwin Core record.

4.12.3. dwc:Occurrence

Element name	Obligation	Value type	Description	Best practice
dwc:recordedBy	O-1	Free text	The person or persons who recorded or observed this specific occurrence.	Recommend that names be entered in a consistent Last name, First name (Affiliation) format.
dwc:organismQuantity	O-1	Positive real number	The quantity of organisms observed.	Must have an associated organismQuantityType.
dwc:organismQuantityType	C-1	Free text	The units of the organism quantity (kilograms, individuals, calls).	Required whenever organismQuantity is reported.
dwc:associatedReferences	O-1	Free text	List of literature (identified by URL, IDs, citations, etc.) associated with the occurrence. Separated by a semicolon (;)	Use a consistent citation or identification style throughout all references.
dwc:occurrenceRemarks	O-1	Free text	Other comments about the occurrence.	Include any details relevant to external understanding or re-use.

4.12.4. dwc:Organism

Element name	Obligation	Value type	Description	Best practice
dwc:organismName	M-1	Free text	The name assigned to the organism, if different from the organismID.	E.g., a nickname.
dwc:organismRemarks	O-1	Free text	Other comments about the organism.	May include notes recorded during a field session.

4.12.5. Events and observations

For dwc:Event, dwc:HumanObservation and dwc:MachineObservation

Element name	Obligation	Value type	Description	Best practice
dwc:samplingProtocol	O-1	Free text	Description or reference to methodology or protocol used during an event.	Strongly recommended. Citations or DOIs are acceptable.
dwc:samplingEffort	O-1	Free text	Amount of effort expended during an event.	E.g., number of person-hours, traps set, area travelled…

4.12.6. dwc:Identification

Element name	Obligation	Value type	Description	Best practice
dwc:identifiedBy	M-1	Free text	A list of people, groups, organizations, or software which contributed to the identification.	Provide at least one entry, so as to specify who was responsible for the taxon. Enter names in the order Last name, First Name. Initials can follow the first name and should be followed by a period.
dwc:identificationReferences	O-1	Free text	A list of any references which were used to complete the identification. List entries separated by a semicolon (;)	Use a consisted citation or identification style throughout all references.
dwc:identificationRemarks	O-1	Free text	Any other comments or notes about the identification.	May include notes recorded during the identification process itself.

4.12.7. dwc:Taxon

Element name	Obligation	Value type	Description	Best practice
dwc:scientificName	M-1	Free text	The full scientific name, with authorship and date information if known.	Strongly recommended if known.
dwc:vernacularName	M-1	Free text	The common or vernacular name for the taxon.	Multiple common names can be listed, separated by a semicolon (;)
dwc:taxonRemarks	O-1	Free text	Other comments about the taxon or name.	May include notes recorded during the identification process, so long as they are not repeated in dwc:Identification.