Element Description

The Version element indicates the version of the dataset. 

Best Practices

The version should be consistent throughout the metadata record. The version in the metadata should be identical to the version specified on the dataset landing page and in dataset documentation. For example, if the dataset landing page specifies the dataset as version 1.1, then the version number in the metadata should also be 1.1 (e.g. not 1.10). If the version in the title is specified as 3.4.2004 then the version in the metadata should also be 3.4.2004 (e.g. not 03.04.2004).     

The Data Product Development Guide for Data Producers offers the following information about versioning:

"The global attribute product_version is used to distinguish between versions of a given data
product (e.g., produced using different processing algorithms or updates to calibration parameters).
It is particularly important for users to know if they will acquire the latest version of a data product.

It is highly recommended to represent the data product version with an ordinal identifier (e.g., 1, 2,
3, etc.) that expresses its position in a series of data product publications. The data product version
can be represented with both a major and minor version identifier (e.g., 2.1, 2.2, etc.). A minor
version is used to identify selected files associated with a limited reprocessing of data (e.g., changes
around a data anomaly that did not affect the rest of the data product). A change that affects the
whole data product (e.g., complete reprocessing) would be considered a major version change.
Guidance for setting version numbers should be sought from the DAAC hosting the data. Some
guidance by the DIWG regarding version numbers can be found in [26] (Rec. 3.10). Whatever
versioning scheme is used, it is understood that all files in a given data product were produced in a
consistent manner.

Periodic reprocessing of data products can produce new versions with a distinct data product
identifier. In general, data that are sufficiently different should be organized into separate data
products. When data are reprocessed, the data producer must distinguish between major and minor
version changes. Also, the nature of changes and the records to which they apply should be
described for every version. In practice, a DAAC may choose to combine different minor versions of
data into a single major version of a data product in the archive and only advance to the next major
version upon reprocessing of the entire data product.
If possible, it is useful to use the same version for the data product as for the algorithm software
used to generate the product (e.g., PGEVersion), to avoid confusing the data product users."

Examples:

"2.0"

"1"

"007"

Note: The short name and version combination must be unique across the CMR.

Metadata Validation and QA/QC

All metadata entering the CMR goes through the below process to ensure metadata quality requirements are met. All records undergo CMR validation before entering the system. The process of QA/QC is slightly different for NASA and non-NASA data providers. Non-NASA providers include interagency and international data providers and are referred to as the International Directory Network (IDN).

Please see the expandable sections below for flowchart details.

Dialect Mappings

UMM Migration

None

Future Mappings

<mdb:MD_Metadata>
  ...
  <mdb:identificationInfo>
    <mri:MD_DataIdentification>
      <mri:citation>
        <cit:CI_Citation>  
          ... 
          <cit:edition>
            <gco:CharacterString>2.0</gco:CharacterString>
          </cit:edition>
          ...
        </cit:CI_Citation>
      </mri:citation>
      ...
    </mri:MD_DataIdentification>
  </mdb:identificationInfo>
  ...
</mdb:MD_Metadata>

"Version" : "2.0",

History

UMM Versioning

ARC Documentation