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 |
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 |
---|---|---|---|
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. |
|
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. |
|
O-R |
A class to describe any action localized in both space and time. |
E.g., a specific sampling event or deployment. |
|
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. |
|
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. |