Page History

Element Description

The Temporal Extent element describes when data were captured or collectedProject element describes the scientific endeavor(s) with which the collection is associated. Scientific endeavors include field campaigns, flight campaigns, projects, interdisciplinary science investigations, missions, scientific programs, etc. This element may also cover a long term project that continuously creates new datasets. 

Best Practices

Dates provided in CMR metadata should comply with the ISO 8601 Standard, which is an International Standard for the representation of dates and times. 

There are three options in the UMM for describing the temporal extent of data: Single Date Time, Range Date Time and Periodic Date Time.  

Using different types of temporal extent between collection and granule level metadata are allowed, as long as it makes logical sense. For example, Single Date Time could be used to describe temporal coverage at the granule level, whereas a Range Date Time may be used to describe temporal coverage at the collection level. It is important that the temporal extent at the collection level be in sync with the temporal extent provided in associated granule level metadata files. 

Single Date Time

The Single Date Time element should be used if data were captured instantaneously (i.e. a single time stamp sufficiently describes the temporal extent of the data). For example, if a data file contains an image that was taken by a camera, the time stamp associated with the time the image was taken would be listed as the Single Date Time in the granule level metadata. Single Date Time may also be used in the collection level metadata if appropriate. If the exact time of data capture is known, it is strongly recommended that the time be included in the Single Date Time. If the exact time of data collection is unknown, it is okay to just provide a date. Multiple Single Date Times may be provided if necessary (cardinality 0..*).

Examples:

SingleDateTime: 2018-11-11T14:53:32Z

SingleDateTime: 2017-04-14T05:26:22Z

Range Date Time

The Range Date Time element should be used when a continuous time range is appropriate to describe the temporal extent of data. Range Date Time is composed of two sub-elements: Beginning Date Time and Ending Date Time, which describe the start and end time of a data file or a collection. 

For completed data sets:

• It is required that an Ending Date Time be provided. The 'EndingDateTime' element should specify the ending date and time of the last available granule in the collection. In addition:
  • The ‘Ends at Present Flag' element should be set to “false”. Setting the ‘Ends at Present Flag’ element to “false” tells the CMR that the ending time for the collection is in the past. Note: Ends at Present Flag is an optional element. 
  • The Collection Progress element should be set to “COMPLETE”

If data collection is ongoing,

• An Ending Date Time does not need to be provided. In addition: 
  • The ‘Ends at Present Flag’ element should be set to “true.” Setting the ‘Ends at Present Flag’ element to “true” tells the CMR that the ending time for the collection is present day, and thus eliminates the need to specify the Ending Date Time of the collection. This also eliminates the need to update the Ending Date Time in the metadata each time new data gets added to the collection.
  • The Collection Progress element should be set to “ACTIVE”

Multiple RangeDateTimes may be provided if necessary (cardinality 0..*). It is recommended that multiple RangeDateTimes be used if there is a significant temporal gap present in the data.

Examples:

A satellite collected data from May 1, 2004 to February 10, 2008. A data product derived from this satellite provides monthly global averages of surface temperature. A monthly global average for February 2008 was not included in the data set since only 10 days of data were available in February.  

BeginningDateTime: 2004-05-01T00:00:00Z

EndingDateTime: 2008-01-31T23:59:59Z

BeginningDateTime: 2004-05-01T00:00:00Z

EndingDateTime: 2004-05-31T23:59:59Z

Radar measurements were taken from a plane. One flight occurred each day from August 20, 2018 to August 31, 2018. 

BeginningDateTime: 2018-08-20T12:34:00Z

EndingDateTime: 2018-08-31T10:01:02Z

BeginningDateTime: 2018-08-20T12:34:00Z

EndingDateTime: 2018-08-20T16:50:52Z

BeginningDateTime: 2018-08-31T06:18:21Z

EndingDateTime: 2018-08-31T10:01:02Z

Periodic Date Time 

For data that is collected in regular reoccurring intervals, the temporal extent can be described as a Periodic Date Time. Periodic Date Time is described via the below sub-elements. If Periodic Date Time is provided, all sub-elements are required:

Name: The name given to the recurring time period.

StartDate: The date (day and time) of the first occurrence of this regularly occurring period. This is when data collections begins for the entire collection. This also identifies the day of the month and time of the day when data collection starts for each reoccurring cycle. 

EndDate: The date (day and time) of the last occurrence of this regularly occurring period. This is when data collection ends for the entire collection.

DurationUnit: The unit for the regularly reoccurring data collection period. In combination with DurationValue, this describes the length of time that data gets collected. This value must be selected from a controlled vocabulary list maintained in the UMM-Common schema. Options include: DAY, MONTH, YEAR

DurationValue: The number of DurationUnits comprising the regularly reoccurring data collection period. Together, DurationValue and DurationUnit describe the length of time that data gets collected. 

PeriodCycleDurationUnit: The duration unit of one full cycle. The full cycle includes both the active data collection period as well as an inactive period. This value must be selected from a controlled vocabulary list maintained in the UMM-Common schema. Options include: DAY, MONTH, YEAR

PeriodCycleDurationValue: The number of CycleDurationUnits comprising one full cycle. Together, CycleDurationValue and CycleDurationUnit describe the length of a full cycle which includes both the active data collection period as well as an inactive period. 

Examples:

Data for a field campaign are collected in December, January and February of each year. Data collection started in December 2013 and ended in February 2017.

Name: Winter_FieldCampaign

StartDate: 2013-12-01T00:00:00Z  

EndDate: 2017-02-28T23:59:59Z

DurationUnit: MONTH

DurationValue: 3

PeriodCycleDurationUnit: YEAR

PeriodCycleDurationValue: 1

A sensor collected data every morning from 5 AM to 6 AM UTC.

Name: AM_Sensor_Daily

StartDate: 2000-04-01T05:00:00Z  

EndDate: 2010-09-04T06:00:00Z

DurationUnit: DAY

DurationValue: 0.0417

PeriodCycleDurationUnit: DAY

PeriodCycleDurationValue: 1

For paleoclimate or geologic data, temporal coverage can be described via the Paleo Temporal Coverage elements. Paleo Temporal Coverage should be used to describe time frames earlier than 0001-01-01 (yyy-mm-dd). Please see the Paleo Temporal Coverage wiki page for details. 

Choice of:

(1) SingleDateTime

If SingleDateTime is selected, the cardinality is 1..*

(2)  RangeDateTime

If RangeDateTime is selected, the cardinality is 1..*

(3) PeriodicDateTime

If PeriodicDateTime is selected, the cardinality is 1..*

n/a

DAY

MONTH

YEAR

DAY

MONTH

YEAR

Value needed for translations:

N/A

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.

ARC Priority Matrix

This element is categorized as highest priority when:

• Temporal Extent is not provided at all
• A Temporal Extent element is included but no dates are provided. Either a SingleDateTime, RangeDateTime, or PeriodicDateTime must be provided in the metadata.
• The valid value in the element appears to be out of sync with data collection. Examples include:
  • Data collection has ended but no ending date has been provided.
  • An ending date has been provided for data that is still being actively collected.
  • Dates and/or times do not align with time stamps provided in the actual data.
  • The 'Ends at Present Flag' element is set to 'True' when data collection has ended.
  • The 'Ends at Present Flag' element is set to 'False' (i.e. data collection has ended) but no ending date has been provided.
• The beginning and/or ending date time provided in the collection level metadata is out of sync with the dates provided in the granule level metadata.
  
  • This is flagged as red if the discrepancy is greater than 1 day. (E.g. The EndingDateTime of the last granule in a collection is 2003-03-03T06:33:00Z but the EndingDateTime of the collection level metadata is 2003-03-01T06:33:00Z, two days before the last granule was collected).

This element is categorized as medium priority when:

• The beginning and/or ending date time provided in the collection level metadata is out of sync with the dates provided in the granule level metadata.
  • This is flagged as yellow if the collection level temporal extent does not include the full extent of the granules, and if the discrepancy is less than 1 day. (E.g. The EndingDateTime of the last granule in a collection is 2003-03-03T06:33:00Z but the EndingDateTime provided in the collection level metadata is 2003-03-03T00:00:00Z. 6 hours and 33 minutes of data in the last granule of the collection is not represented in the collection level temporal extent).
• The 'Ends at Present Flag' element is not provided for an ongoing data set. For ongoing or active data sets, the Ends at Present Flag should be provided with a value of 'True'
• There are significant temporal gaps in the data, but only one RangeDateTime is provided in the collection level metadata. Significant gaps can be more accurately represented by providing multiple RangeDateTimes.

This element is categorized as low priority when:

• The beginning and/or ending date time provided in the collection level metadata is out of sync with the dates provided in the granule level metadata.
  • This is flagged as blue if the collection level temporal extent includes the full extent of the granules, but there is a discrepancy between the times that amount to less than 1 day. (E.g. The EndingDateTime of the last granule in a collection is 2003-03-03T06:33:00Z but the EndingDateTime provided in the collection level metadata is 2003-03-03T23:59:59Z. The collection level metadata includes the full extent of the granule but there is a discrepancy in the ending time provided on 2003-03-03 between the granule and the collection metadata).

ARC Automated Checks

Project names are important for data search and discovery. In order to provide a consistent search experience, Project names are controlled by GCMD vocabulary maintained in the Keyword Management System (KMS). This is especially important for faceted searches by Project name in the Earthdata Search Client. A list of valid Project keywords can be found here: https://gcmd.earthdata.nasa.gov/kms/concepts/concept_scheme/projects?format=csv

Providing a Project is optional, however, it is highly recommended that a Project be provided in the metadata if possible. If a dataset is associated with more than one Project, then multiple Projects may be listed. Project also includes the 'Campaign' sub-element in order to support multiple sub-campaigns under the same Project. The following sub-elements are used to describe Project:

ShortName: If the Project element is provided, then the Short Name field is required. The Project Short Name must be selected from the 'Short_Name' column in the GCMD Project Keyword list. Project names are controlled to ensure ensure consistency when searching for data using keywords or via the Project faceted search.

LongName: Providing a Project Long Name is optional, however, it is encouraged that a long name be provided if one exists in the GCMD Project Keyword list. Providing a Project Long Name is encouraged because the associated Project Short Name may be comprised of acronyms. Project Long Names should be selected from the Long_Name column in the keyword list.  

Campaign: The Campaign sub-element can be used to list the names of smaller projects/campaigns which fall within the scope of the Project listed. If necessary, multiple Campaigns may be associated with a single Project. 

StartDate: The Start Date should indicate the date that the Project began. Providing the Start Date is optional. 

EndDate: The End Date should indicate the date that the Project ended/will end. For Projects that are still underway, the End Date may be in the future. Providing the End Date for the Project is optional.

Examples:

ShortName: ISLSCP II

LongName: International Satellite Land Surface Climatology Project II

StartDate: 1986-01-01

EndDate: 1995-12-31

ShortName: MEaSUREs

LongName: Making Earth System Data Records for Use in Research Environments

Campaign: NVAP-M 

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

History

UMM Versioning

Dialect Mappings

DIF 9

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

DIF 10

Choice of:

(1) Single_DateTime

If Single_DateTime is selected, the cardinality is 1..*

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

DateTime fields must be in date (YYY-MM-DD) or Date-Time (YYYY-MM-DDTHH:MM:SS) format. It is preferred that a date or dateTime be provided if known, rather than one of the enumeration values. For definitions of the enumeration values, please see the DIF schema.

The enumeration "Not provided" should not be used by metadata providers. This value is used by translation software (to DIF 10) for required fields.

(2) Range_DateTime

If Range_DateTime is selected, the cardinality is 1..*

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

DateTime fields must be in date (YYY-MM-DD) or Date-Time (YYYY-MM-DDTHH:MM:SS) format. It is preferred that a date or dateTime be provided if known, rather than one of the enumeration values. For definitions of the enumeration values, please see the DIF schema.

The enumeration "Not provided" should not be used by metadata providers. This value is used by translation software (to DIF 10) for required fields.

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

DateTime fields must be in date (YYY-MM-DD) or Date-Time (YYYY-MM-DDTHH:MM:SS) format. It is preferred that a date or dateTime be provided if known, rather than one of the enumeration values. For definitions of the enumeration values, please see the DIF schema.

The enumeration "Not provided" should not be used by metadata providers. This value is used by translation software (to DIF 10) for required fields.

(3) Periodic_DateTime

If Periodic_DateTime is selected, the cardinality is 1..*

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

DateTime fields must be in date (YYY-MM-DD) or Date-Time (YYYY-MM-DDTHH:MM:SS) format. It is preferred that a date or dateTime be provided if known, rather than one of the enumeration values. For definitions of the enumeration values, please see the DIF schema.

The enumeration "Not provided" should not be used by metadata providers. This value is used by translation software (to DIF 10) for required fields.

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

DateTime fields must be in date (YYY-MM-DD) or Date-Time (YYYY-MM-DDTHH:MM:SS) format. It is preferred that a date or dateTime be provided if known, rather than one of the enumeration values. For definitions of the enumeration values, please see the DIF schema.

The enumeration "Not provided" should not be used by metadata providers. This value is used by translation software (to DIF 10) for required fields.

DAY

MONTH

YEAR

DAY

MONTH

YEAR

Value needed for translations:

The following value is used to translate older versions of DIF (e.g. DIF 9, DIF 10.1) to the most current version of DIF (DIF10.3) if no valid value is provided in the older version of the record.

Not provided - This value is auto-populated to any DateTime fields if no valid value is provided in the DateTime field at time of conversion to DIF 10.3. This value should not be used by metadata providers.

Enumeration Mapping

Translation

Direction

Example Mapping

<Temporal_Coverage>
  <Single_DateTime>2018-08-20T14:13:22Z</Single_DateTime>
</Temporal_Coverage>


<Temporal_Coverage>
  <Ends_At_Present_Flag>true</Ends_At_Present_Flag>
  <Range_DateTime>
    <Beginning_Date_Time>1980-01-01</Beginning_Date_Time>
  </Range_DateTime>
</Temporal_Coverage>


<Temporal_Coverage>
  <Range_DateTime>
    <Beginning_Date_Time>1980-01-01T00:00:00Z</Beginning_Date_Time>
    <Ending_Date_Time>2010-12-31T23:59:59Z</Ending_Date_Time>
  </Range_DateTime>
</Temporal_Coverage>


<Temporal_Coverage>
  <Periodic_DateTime>
    <Name>Winter_FieldCampaign</Name>
    <Start_Date>2013-12-01T00:00:00Z</Start_Date>
    <End_Date>2017-02-28T23:59:59Z</End_Date>
    <Duration_Unit>MONTH</Duration_Unit>
    <Duration_Value>3</Duration_Value>
    <Period_Cycle_Duration_Unit>YEAR</Period_Cycle_Duration_Unit>
    <Period_Cycle_Duration_Value>1</Period_Cycle_Duration_Value>
  </Periodic_DateTime>
</Temporal_Coverage>

TemporalExtents: [
  {
    SingleDateTimes: [
      {
        SingleDateTime: "2018-08-20T14:13:22Z"
      }
    ]
  }
]


TemporalExtents: [
  {
    EndsAtPresentFlag: true,
    RangeDateTimes: [
      {
        BeginningDateTime: "1980-01-01",
      }
    ]
  }
]


TemporalExtents: [
  {
    RangeDateTimes: [
      {
        BeginningDateTime: "1980-01-01T00:00:00Z",
        EndingDateTime: "2010-12-31T23:59:59Z"
      }
    ]
  }
]


TemporalExtents: [
  {
    PeriodicDateTimes: [
      {
        Name: "Winter_FieldCampaign",
        StartDate: "2013-12-01T00:00:00Z",
        EndDate: "2017-02-28T23:59:59Z",
        DurationUnit: "MONTH",
        DurationValue: "3",
        PeriodCycleDurationUnit: "YEAR",
        PeriodCycleDurationValue: "1"
      }
    ]
  }
]

ECHO 10

The time system which the values found in temporal subclasses. For example:

The type of date represented by the value in the date attributes of the temporal subclasses. For example:

Tells the system how temporal coverage is
specified for the collection. For example: SingleDateTime, RangeDateTime, PeriodicDateTime

The precision (position in number of
places to right of decimal point) of seconds used in measurement.

Choice of:

(1) SingleDateTime

If SingleDateTime is selected, the cardinality is 1..*

(2) RangeDateTime

If RangeDateTime is selected, the cardinality is 1..*

(3) PeriodicDateTime

If PeriodicDateTime is selected, the cardinality is 1..*

DAY

MONTH

YEAR

DAY

MONTH

YEAR

Enumeration Mapping

Translation

Direction

Example Mapping

<Temporal>
  <SingleDateTime>2018-08-20T14:13:22Z</SingleDateTime>
</Temporal>


<Temporal>
  <EndsAtPresentFlag>true</EndsAtPresentFlag>
  <RangeDateTime>
    <BeginningDateTime>1980-01-01</BeginningDateTime>
  </RangeDateTime>
</Temporal>


<Temporal>
  <RangeDateTime>
    <BeginningDateTime>1980-01-01T00:00:00Z</BeginningDateTime>
    <EndingDateTime>2010-12-31T23:59:59Z</EndingDateTime>
  </RangeDateTime>>
</Temporal>


<Temporal>
  <PeriodicDateTime>
    <Name>Winter_FieldCampaign</Name>
    <StartDate>2013-12-01T00:00:00Z</StartDate>
    <EndDate>2017-02-28T23:59:59Z</EndDate>
    <DurationUnit>MONTH</DurationUnit>
    <DurationValue>3</DurationValue>
    <PeriodCycleDurationUnit>YEAR</PeriodCycleDurationUnit>
    <PeriodCycleDurationValue>1</PeriodCycleDurationValue>
  </PeriodicDateTime>
</Temporal>

TemporalExtents: [
  {
    SingleDateTimes: [
      {
        SingleDateTime: "2018-08-20T14:13:22Z"
      }
    ]
  }
]


TemporalExtents: [
  {
    EndsAtPresentFlag: true,
    RangeDateTimes: [
      {
        BeginningDateTime: "1980-01-01",
      }
    ]
  }
]


TemporalExtents: [
  {
    RangeDateTimes: [
      {
        BeginningDateTime: "1980-01-01T00:00:00Z",
        EndingDateTime: "2010-12-31T23:59:59Z"
      }
    ]
  }
]


TemporalExtents: [
  {
    PeriodicDateTimes: [
      {
        Name: "Winter_FieldCampaign",
        StartDate: "2013-12-01T00:00:00Z",
        EndDate: "2017-02-28T23:59:59Z",
        DurationUnit: "MONTH",
        DurationValue: "3",
        PeriodCycleDurationUnit: "YEAR",
        PeriodCycleDurationValue: "1"
      }
    ]
  }
]

ISO 19115-2 MENDS

Enumeration/Code List Mapping

Translation

Direction

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

Example Mapping

<gmd:status>
    <gmd:MD_ProgressCode codeList=
        "https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode"
        codeListValue="completed">completed</gmd:MD_ProgressCode>
</gmd:status>

"CollectionProgress" : "COMPLETE",

ISO 19115-2 SMAP

Enumeration/Code List Mapping

Translation

Direction

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

Example Mapping

<gmd:status>
    <gmd:MD_ProgressCode codeList=
         "https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode"
         codeListValue="completed">completed</gmd:MD_ProgressCode>
</gmd:status>

"CollectionProgress" : "COMPLETE",

UMM Migration

Translation

Direction

Future Mappings

ISO 19115-1

/mdb:MI_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:status/mri:MD_ProgressCode

with codeList and codeListValue attributes

<mri:MD_DataIdentification>
  <mri:citation>
    ...
    <mri:status>
      <mri:MD_ProgressCode codeList="{codeListLocation}#MD_ProgressCode"
        codeListValue="onGoing">onGoing</mri:MD_ProgressCode>
    </mri:status>
    ...
  </mri:citation>
</mri:MD_DataIdentification>

"CollectionProgress" : "ACTIVE",

History

UMM Versioning

ARC Documentation