Page History

Table of Contents

style	circle

Element Description

The Data Dates element is used to identify dates when the data or resource itself changed in some way. This element is made of two sub-elements, Type and Date. The Type describes what the date represents: a future review, when the resource was created, last updated, or planned for deletion. The Date describes when the resource had or will have the action performed on it as described by the Type element.

Best Practices

Each Data Date is accompanied by a Type. The Type must be selected from a controlled vocabulary list. There are four options available for Type:

CREATE: The date the resource was created. This should be the date the data set was published in the database/ entered into the data archive system.
UPDATE: The date the resource was last updated. This includes any changes made to the data itself, such as a change in processing or a change in the file naming convention.
REVIEW: The date of a planned future review of the resource.
DELETE: The date the resource will be deleted.

At least one Data Date must be provided. Multiple Data Dates are allowed, however, the same date type should not be repeated more than once in the same record (for example, a CREATE and an UPDATE time can be provided, but two CREATE times cannot be provided in the same record). All dates should comply with the ISO 8601 Standard.

Examples:

Type = CREATE Date: 2010-02-01

Type = UPDATE Date: 2018-02-01

Type = REVIEW Date: 2019-02-01

Element Specification

At least 1 Data Date must be provided. Multiple Data Dates may be provided, if necessary (Cardinality 1..*)

Model

Element

Type

Usable Valid Values

Constraints

Required?

Cardinality

Notes

UMM-C

DataDate/Type

Enumeration

CREATE

UPDATE

REVIEW

DELETE

n/a

Yes

1..*

The same Type should not be used more than once in the same record.

UMM-C

DataDate/Date

dateTime

n/a

Yes

1..*

The actual date that the event associated with the data occurred/ will occur.

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).

Lucidchart

rich-viewer	false

autofit	true
name	Copy of Wiki Page Metadata Evaluation Workflow-1939-51df84
width	1102
pages-to-display
id	98e5dc28-3252-4209-953f-66f1378e1cf4
align	Left
height	299

Please see the expandable sections below for flowchart details.

Expand

title	GCMD Metadata QA/QC

Manual Review
- Check that the date is accurate for the data set
Automated Review
- Check that the field has been populated
- Checks for correct format
- Check that the field length is not greater than 1000 characters

Expand

title	CMR Validation

<>

Expand

title	ARC Metadata QA/QC

ARC Priority Matrix

Priority Categorization	Justification
	This element is categorized as highest priority when: The DataDate/Type does not match one of the date type enumeration values (CREATE, UPDATE, REVIEW, DELETE) No DataDate is provided (at least 1 Data Date must be provided) The DataDate/Date provided does comply with the ISO 8601 Standard
	This element is categorized as medium priority when: A REVIEW or DELETE date is in the past The CREATE or UPDATE date is in the future A translation error between a native metadata format (ISO, DIF 10, ECHO 10) and UMM is present for the date and/or the date type
	This element is categorized as low priority when: n/a
	The element is provided, and follows all applicable criteria specified in the best practices section above.

ARC Automated Rules

If novalue is provided, return is "np"
Otherwise, return is "OK"

Dialect Mappings

Expand

title	DIF 9

DIF 9 ^{(Note: DIF-9 is being phased out and will no longer be supported after 2018)}

Expand

title	DIF 10

DIF 10

Specification	Path	Type	Usable Valid Values	Constraints	Required in DIF 10?	Cardinality	Notes
DIF 10	Metadata_Dates/Data_Creation	Date dateTime Enumeration	unknown present unbounded future Not provided	n/a	No	0..1	Dates provided in the Data_Creation field will be labeled with the DataDate/Type of 'CREATE' when translated to UMM. If any of the enumeration values are provided (unknown, present, unbounded, future, Not provided) the date will automatically default to 1970-01-01T00:00:00Z when being translated to UMM. This is because UMM does not currently support any enumeration values in date fields.
DIF 10	Metadata_Dates/Data_Last_Revision	Date dateTime Enumeration	unknown present unbounded future Not provided	n/a	No	0..1	Dates provided in the Data_Last_Revision field will be labeled with the DataDate/Type of 'UPDATE' when translated to UMM. If any of the enumeration values are provided (unknown, present, unbounded, future, Not provided) the date will automatically default to 1970-01-01T00:00:00Z when being translated to UMM. This is because UMM does not currently support any enumeration values in date fields.
DIF 10	Metadata_Dates/Data_Future_Review	Date dateTime Enumeration	unknown present unbounded future Not provided	n/a	No	0..1	Dates provided in the Data_Future_Review field will be labeled with the DataDate/Type of 'REVIEW' when translated to UMM. If any of the enumeration values are provided (unknown, present, unbounded, future, Not provided) the date will automatically default to 1970-01-01T00:00:00Z when being translated to UMM. This is because UMM does not currently support any enumeration values in date fields.
DIF 10	Metadata_Dates/Data_Delete	Date dateTime Enumeration	unknown present unbounded future Not provided	n/a	No	0..1	Dates provided in the Data_Delete field will be labeled with the DataDate/Type of 'DELETE' when translated to UMM. If any of the enumeration values are provided (unknown, present, unbounded, future, Not provided) the date will automatically default to 1970-01-01T00:00:00Z when being translated to UMM. This is because UMM does not currently support any enumeration values in date fields.

Value needed for translations:

Not provided - The value of 'Not provided' might appear in the Metadata_Dates/Data_Creation and/or the Metadata_Dates/Data_Last_Revision fields as a result of software used to convert older versions of DIF to DIF version 10.2. Required fields that are left empty in older versions a DIF record are automatically populated with 'Not provided' when being converted to a new version, and both Metadata_Dates/Data_Creation and Metadata_Dates/Data_Last_Revision are required in DIF version 10.2. Both Data_Creation and /Data_Last_Revision were changed from required to optional in DIF version 10.3. Therefore, no DIF 10.3 records should have 'Not provided' as a value in the Data_Creation or Data_Last_Revision fields. This value should not be used by metadata providers.

Example Mapping

Section

Column

width	50%

DIF 10

No Format
<Metadata_Dates> <Data_Creation>2012-12-12</Data_Creation> <Data_Last_Revision>2018-10-03</Data_Last_Revision> <Data_Future_Review>2100-01-01</Data_Future_Review> </Metadata_Dates>

Column

width	50%

UMM

No Format
DataDates: [ { Date: "2012-12-12T00:00:00.000Z", Type: "CREATE" }, { Date: "2018-10-03T00:00:00.000Z", Type: "UPDATE" }, { Date: "2100-01-01T00:00:00.000Z", Type: "REVIEW" }, ]

Expand

title	ECHO 10

ECHO 10

Specification

Path

Type

Constraints

Required in ECHO10?

Cardinality

Notes

ECHO 10

InsertTime

dateTime

n/a

Yes

1

The insert date/time the collection entered data provider's database.

The date provided in the InsertTime field will be labeled with the DataDate/Type of 'CREATE' when translated to UMM.

ECHO 10

LastUpdate

dateTime

n/a

Yes

1

The most recent update which occurred on the data provider's database.

The date provided in the LastUpdate field will be labeled with the DataDate/Type of 'UPDATE' when translated to UMM.

ECHO 10

DeleteTime

dateTime

n/a

No

0..1

The date the collection is planned to be deleted from the data provider's database.

The date provided in the DeleteTime field will be labeled with the DataDate/Type of 'DELETE' when translated to UMM.

Example Mapping

Section

Column

width	50%

ECHO 10

No Format
<InsertTime>2012-12-12T00:00:00.000Z</InsertTime> <LastUpdate>2018-10-03T00:00:00.000Z</LastUpdate>

Column

width	50%

UMM

No Format
DataDates: [ { Date: "2012-12-12T00:00:00.000Z", Type: "CREATE" }, { Date: "2018-10-03T00:00:00.000Z", Type: "UPDATE" } ]

Expand

title	ISO 19115-2 MENDS

ISO 19115-2 MENDS

At least 1 Data Date must be provided. Multiple Data Dates may be provided, if necessary.

Specification

Path

Type

Notes

ISO 19115-2 MENDS

/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:date/gco:DateTime

with

/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:dateType/ gmd:CI_DateTypeCode="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue=

dateTime

codelist

The actual date should be provided in the gco:DateTime field.

A codelist value (gmd:CI_DateTypeCode) should be provided with the date in order to identify the date Type. These fields can be repeated as many times as necessary - however, note that the same DateTypeCode should not be used more than once in the same record. If the same DateTypeCode is used more than once, only the first occurrence will be translated to UMM.

Enumeration/Code List Mapping

ISO MENDS	Translation Direction	UMM
creation	↔	CREATE
publication	↔
revision	↔	UPDATE

Example Mapping

Section

Column

width	50%

ISO 19115-2 MENDS

No Format

<gmi:MI_Metadata>
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      <gmd:citation>
        <gmd:CI_Citation>
          <gmd:date>
            <gmd:CI_Date>
              <gmd:date>
                <gco:DateTime>2012-12-12T00:00:00.000Z</gco:DateTime>
              </gmd:date>
              <gmd:dateType>
                <gmd:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="creation">creation</gmd:CI_DateTypeCode>
              </gmd:dateType>
              <gmd:date>
                <gco:DateTime>2018-10-03T00:00:00.000Z</gco:DateTime>
              </gmd:date>
              <gmd:dateType>
                <gmd:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode>
              </gmd:dateType>
            </gmd:CI_Date>
          </gmd:date>
        </gmd:CI_Citation>
      </gmd:citation>
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
</gmi:MI_Metadata>

Column

width	50%

UMM

No Format
DataDates: [ { Date: "2012-12-12T00:00:00.000Z", Type: "CREATE" }, { Date: "2018-10-03T00:00:00.000Z", Type: "UPDATE" } ]

Expand

title	ISO 19115-2 SMAP

ISO 19115-2 SMAP

At least 1 Data Date must be provided. Multiple Data Dates may be provided, if necessary.

Specification

Path

Type

Notes

ISO 19115-2 SMAP

/gmd:DS_Series/gmd:seriesMetadata/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:date/gco:DateTime

with

/gmd:DS_Series/gmd:seriesMetadata/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/ gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue=

dateTime

codelist

The actual date should be provided in the gco:DateTime field.

A codelist value (gmd:CI_DateTypeCode) should be provided with the date in order to identify the date Type. These fields can be repeated as many times as necessary - however, note that the same DateTypeCode should not be used more than once in the same record. If the same DateTypeCode is used more than once, only the first occurrence will be translated to UMM.

Enumeration/Code List Mapping

ISO MENDS	Translation Direction	UMM
creation	↔	CREATE
publication	↔
revision	↔	UPDATE

Example Mapping

Section

Column

width	50%

ISO 19115-2 SMAP

No Format

<gmd:DS_Series>
<gmd:seriesMetadata>
<gmi:MI_Metadata>
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      <gmd:citation>
        <gmd:CI_Citation>
          <gmd:date>
            <gmd:CI_Date>
              <gmd:date>
                <gco:DateTime>2012-12-12T00:00:00.000Z</gco:DateTime>
              </gmd:date>
              <gmd:dateType>
                <gmd:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="creation">creation</gmd:CI_DateTypeCode>
              </gmd:dateType>
              <gmd:date>
                <gco:DateTime>2018-10-03T00:00:00.000Z</gco:DateTime>
              </gmd:date>
              <gmd:dateType>
                <gmd:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode>
              </gmd:dateType>
            </gmd:CI_Date>
          </gmd:date>
        </gmd:CI_Citation>
      </gmd:citation>
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
</gmi:MI_Metadata>
</gmd:seriesMetadata>
</gmd:DS_Series>

Column

width	50%

UMM

No Format
DataDates: [ { Date: "2012-12-12T00:00:00.000Z", Type: "CREATE" }, { Date: "2018-10-03T00:00:00.000Z", Type: "UPDATE" } ]

UMM Migration

UMM Version 1.9.0	Translation Direction	UMM Version 1.10.0

Future Mappings

Expand

title	ISO 19115-1

ISO 19115-1

At least 1 Data Date must be provided. Multiple Data Dates may be provided, if necessary.

Specification

Path

Type

Notes

ISO 19115-1

/mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:date/cit:CI_Date/cit:date/gco:DateTime

with

/mdb:MD_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:citation/cit:CI_Citation/cit:date/cit:CI_Date/cit:dateType/cit:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue=

dateTime

codelist

The actual date should be provided in the gco:DateTime field.

A codelist value (gmd:CI_DateTypeCode) should be provided with the date in order to identify the date Type. These fields can be repeated as many times as necessary - however, note that the same DateTypeCode should not be used more than once in the same record. If the same DateTypeCode is used more than once, only the first occurrence will be translated to UMM.

Enumeration/Code List Mapping

ISO MENDS	Translation Direction	UMM
creation	↔	CREATE
publication	↔
revision	↔	UPDATE

Example Mapping

Section

Column

width	50%

ISO 19115-1

No Format

<mdb:MD_Metadata>
  <mdb:identificationInfo>
    <mri:MD_DataIdentification>
      <mri:citation>
        <cit:CI_Citation>
          <cit:date>
            <cit:CI_Date>
              <cit:date>
                <gco:DateTime>2012-12-12T00:00:00.000Z</gco:DateTime>
              </cit:date>
              <cit:dateType>
                <cit:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="creation">creation</gmd:CI_DateTypeCode>
              </cit:dateType>
              <cit:date>
                <gco:DateTime>2018-10-03T00:00:00.000Z</gco:DateTime>
              </cit:date>
              <cit:dateType>
                <cit:CI_DateTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="revision">revision</gmd:CI_DateTypeCode>
              </cit:dateType>
            </cit:CI_Date>
          </cit:date>
        </cit:CI_Citation>
      </mri:citation>
    </mri:MD_DataIdentification>
  </mdb:identificationInfo>
</mdb:MD_Metadata>

Column

width	50%

UMM

No Format
DataDates: [ { Date: "2012-12-12T00:00:00.000Z", Type: "CREATE" }, { Date: "2018-10-03T00:00:00.000Z", Type: "UPDATE" } ]

History

UMM Versioning

Version	Date	What Changed
1.10.0	5/2/2018	No changes were made for Data Dates during the transition from version 1.9.0 to 1.10.0
1.9.0

ARC Documentation

Version	Date	What Changed	Author
1.0	10/16/18	Recommendations/priority matrix transferred from internal ARC documentation to wiki space	Jeanne' le Roux

Page tree

Versions Compared

Old Version 18

New Version 19

Key

Element Description

Best Practices

Element Specification

Metadata Validation and QA/QC

UMM Migration

History

UMM Versioning

ARC Documentation