You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »


Element Description

The Temporal Extent element describes when data were acquired or collected. 


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 temporal extent representations 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.  

RangeDateTime for the collection:RangeDateTime for the first granule in the collection:

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. 

RangeDateTime for the collection:RangeDateTime for the first granule in the collection:RangeDateTime for the last granule in the collection:

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 (yyyy-mm-dd). Please see the Paleo Temporal Coverage wiki page for details. 

Element Specification

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonTemporalExtent/PrecisionOfSecondsIntegern/aNo0..1The precision (position in number of places to right of decimal point) of seconds used in measurement.
UMM-CommonTemporalExtent/EndsAtPresentFlagBooleann/aNo0..1Setting the Ends At Present Flag to 'True' indicates that a data collection currently ends at the present date. Setting the Ends at Present flag to 'True' eliminates the need to continuously update the Range Ending Time for collections where granules are continuously being added to the collection inventory.

Choice of:

(1) SingleDateTime

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

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonTemporalExtent/SingleDateTimedateTimen/aYes, if applicable1Dates must comply with the ISO 8601 Standard.

(2)  RangeDateTime

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

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonTemporalExtent/RangeDateTime/BeginningDateTimedateTimen/aYes, if applicable1Dates must comply with the ISO 8601 Standard.
UMM-CommonTemporalExtent/RangeDateTime/EndingDateTimedateTimen/aNo0..1An EndingDateTime must be provided at the collection level if the collection is complete.

(3) PeriodicDateTime

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

ModelElementTypeUsable Valid ValuesConstraintsRequired?CardinalityNotes
UMM-CommonTemporalExtent/PeriodicDateTime/NameString

n/a

1 - 30 charactersYes, if applicable1
UMM-CommonTemporalExtent/PeriodicDateTime/StartDatedateTimen/an/aYes, if applicable1Dates must comply with the ISO 8601 Standard.
UMM-CommonTemporalExtent/PeriodicDateTime/EndDatedateTimen/an/aYes, if applicable1Dates must comply with the ISO 8601 Standard.
UMM-CommonTemporalExtent/PeriodicDateTime/DurationUnitEnumeration

DAY

MONTH

YEAR

n/aYes, if applicable1
UMM-CommonTemporalExtent/PeriodicDateTime/DurationValueIntegern/an/aYes, if applicable1
UMM-CommonTemporalExtent/PeriodicDateTime/PeriodCycleDurationUnitEnumeration

DAY

MONTH

YEAR

n/aYes, if applicable1
UMM-CommonTemporalExtent/PeriodicDateTime/PeriodCycleDurationValue   Integern/an/aYes, if applicable1


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

Priority CategorizationJustification

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 date provided does not comply with the ISO 8601 Standard
  • 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).

The element is provided, a correct valid value is used, and the valid value matches the status of the data set.

ARC Automated Checks

  • If all three fields (SingleDateTime, BeginningDateTime, EndingDateTime) are provided, return is: "According to the UMM schema, the <Single_DateTime> field cannot be populated while the <Beginning_Date_Time>/<Ending_Date_Time> fields are populated."
  • If the provided value is not formatted correctly, return is: "The provided date, <provided value> , does not adhere to one of the ISO 8601 standard formats (https://www.w3.org/TR/NOTE-datetime)"
  • If the proved value is in the future, return is: "The provided date, <provided value>, is in the future. If this error is for the 'Ending Date Time' field, recommend removing the ending date time from the metadata record and setting the EndsAtPresentFlag to True. If this error is in the 'Future Review' or 'Delete Time' fields, it is 'OK. Otherwise, recommend providing a valid date for this field"
  • If the provided value's 'day' is not valid, return is: "The provided date, <provided value>, contains a day that is > 31 or < 1. Recommend providing a valid date."
  • If the provided value's 'month' is not valid, return is: "The provided date, <provided value> contains a month that is > 12 or < 1. Recommend providing a valid date."
  • If the provided value's 'time' is not valid, return is: "The provided date, <provided value>, is in the future. If this error is for the 'Ending Date Time' field, recommend removing the ending date time from the metadata record and setting the EndsAtPresentFlag to True. If this error is in the 'Future Review' or 'Delete Time' fields, it is 'OK'. Otherwise, recommend providing a valid date for this field"


Dialect Mappings

DIF 9

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


DIF 10

SpecificationPathTypeConstraintsRequired in DIF 10?CardinalityNotes
DIF 10/DIF/Temporal_Coverage/Time_TypeString
No0..1


DIF 10/DIF/Temporal_Coverage/Date_TypeString
No0..1
DIF 10/DIF/Temporal_Coverage/Temporal_Range_TypeString
No0..1
DIF 10/DIF/Temporal_Coverage/Precision_Of_SecondsInteger
No0..1The precision (position in number of places to right of decimal point) of seconds used in measurement.
DIF 10/DIF/Temporal_Coverage/Ends_At_Present_FlagBoolean
No0..1Recommend providing a value of "true" for active data sets.

Choice of:

(1) Single_DateTime

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

ModelElementTypeUsable Valid ValuesRequired?CardinalityNotes
DIF 10/DIF/Temporal_Coverage/Single_DateTime

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

Yes, if applicable1

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

ModelElementTypeUsable Valid ValuesRequired?CardinalityNotes
DIF 10/DIF/Temporal_Coverage/Range_DateTime/Beginning_Date_Time

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

Yes, if applicable1

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.

DIF 10/DIF/Temporal_Coverage/Range_DateTime/Ending_Date_Time

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided

No0..1

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

ModelElementTypeUsable Valid ValuesConstraintsRequired?CardinalityNotes
DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/NameStringn/a
Yes, if applicable1Dates must comply with the ISO 8601 Standard.
DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/Start_Date

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided


Yes, if applicable1

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.

DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/End_Date

Date

dateTime

Enumeration

unknown

present

unbounded

future

Not provided


Yes, if applicable1

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.

DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/Duration_UnitEnumeration

DAY

MONTH

YEAR


Yes, if applicable1
DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/Duration_ValueIntegern/a
Yes, if applicable1
DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/Period_Cycle_Duration_UnitEnumeration

DAY

MONTH

YEAR


Yes, if applicable1
DIF 10/DIF/Temporal_Coverage/Periodic_DateTime/Period_Cycle_Duration_ValueIntegern/a
Yes, if applicable1

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

DIF 10

Translation

Direction

UMM
DAY↔DAY
MONTH↔MONTH
YEAR↔YEAR
unknown→
present

unbounded

future

Not provided

Example Mapping

DIF 10

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

UMM

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

SpecificationPathTypeConstraintsRequired in ECHO10?CardinalityNotes
ECHO 10/Collection/Temporal/TimeTypeString1 - 80 charactersNo0..1

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

ECHO 10/Collection/Temporal/DateTypeString1 - 80 charactersNo0..1

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

ECHO 10/Collection/Temporal/TemporalRangeTypeString1 - 80 charactersNo0..1

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

ECHO 10/Collection/Temporal/PrecisionOfSecondsIntegern/aNo0..1

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

ECHO 10/Collection/Temporal/EndsAtPresentFlagBooleann/aNo0..1It is recommended that a value of "true" be provided for active data sets.

Choice of:

(1) SingleDateTime

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

SpecificationPathTypeConstraintsRequired in ECHO10?CardinalityNotes
ECHO 10/Collection/Temporal/SingleDateTimedateTimen/aYes, if applicable0..1

(2) RangeDateTime

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

SpecificationPathTypeConstraintsRequired in ECHO10?CardinalityNotes
ECHO 10/Collection/Temporal/RangeDateTime/BeginningDateTimedateTimen/aYes, if applicable1
ECHO 10/Collection/Temporal/RangeDateTime/EndingDateTimedateTimen/aNo0..1An EndingDateTime must be provided if the collection is complete. No EndingDateTime is necessary if the collection is active.

(3) PeriodicDateTime

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

SpecificationPathTypeUsable Valid ValuesConstraintsRequired in ECHO10?CardinalityNotes
ECHO 10/Collection/Temporal/PeriodicDateTime/NameStringn/a1 - 30 charactersYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/StartDatedateTimen/an/aYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/EndDatedateTimen/an/aYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/DurationUnitEnumeration

DAY

MONTH

YEAR

n/aYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/DurationValueIntegern/an/aYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/PeriodCycleDurationUnitEnumeration

DAY

MONTH

YEAR

n/aYes, if applicable1
ECHO 10/Collection/Temporal/PeriodicDateTime/PeriodCycleDurationValueIntegern/an/aYes, if applicable1

Enumeration Mapping

ECHO 10

Translation

Direction

UMM
DAY↔DAY
MONTH↔MONTH
YEAR↔YEAR

Example Mapping

ECHO 10

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

UMM

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

SpecificationPathTypeNotes
ISO 19115-2 MENDS/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:status/gmd:MD_ProgressCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode" codeListValue=StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.

Enumeration/Code List Mapping

ISO MENDS

Translation

Direction

UMM
planned↔PLANNED
underDevelopment→PLANNED
onGoing↔ACTIVE
completed↔COMPLETE
historicalArchive→COMPLETE
obsolete→COMPLETE

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

↔NOT APPLICABLE
Blank or doesn’t exist→NOT PROVIDED
Any other value→NOT PROVIDED
Don’t translate←NOT PROVIDED

Example Mapping

ISO 19115-2 MENDS

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

UMM

"CollectionProgress" : "COMPLETE",



ISO 19115-2 SMAP

SpecificationPathTypeNotes
ISO 19115-2 SMAP/gmd:DS_Series/gmd:seriesMetadata/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:status/gmd:MD_ProgressCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode" codeListValue=StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.

Enumeration/Code List Mapping

ISO SMAP

Translation

Direction

UMM
planned↔PLANNED
underDevelopment→PLANNED
onGoing↔ACTIVE
completed↔COMPLETE
historicalArchive→COMPLETE
obsolete→COMPLETE

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

↔NOT APPLICABLE
Blank or doesn’t exist→NOT PROVIDED
Any other value→NOT PROVIDED
Don’t translate←NOT PROVIDED

Example Mapping

ISO 19115-2 SMAP

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

UMM

"CollectionProgress" : "COMPLETE",



UMM Migration


UMM Version 1.9.0

Translation

Direction

UMM Version 1.10.0
PLANNED↔PLANNED
IN WORK↔ACTIVE
COMPLETE↔COMPLETE
NOT APPLICABLE↔NOT APPLICABLE
NOT PROVIDED↔NOT PROVIDED
Any other value→NOT PROVIDED

Future Mappings

ISO 19115-1

SpecificationPathTypeNotes
ISO 19115-1

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

with codeList and codeListValue attributes

StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.

ISO 19115-1

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

UMM

"CollectionProgress" : "ACTIVE",


History

UMM Versioning

VersionDateWhat Changed
1.10.0
Changes would be tracked here
1.9.0

ARC Documentation

VersionDateWhat ChangedAuthor
1.08/17/18Recommendations/priority matrix transferred from internal ARC documentation to wiki space
Kaylin Bugbee



  • No labels