Versions Compared

Old Version 3

changes.mady.by.user user-b4abf

Saved on

compared with

New Version 4

changes.mady.by.user Dana Shum

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Author(s): <user-b4abf>

 

Section
bordertrue
Column
width50%

Description of Problem

The Version field has traditionally been a free text format field that gave data providers flexibility in defining a Version that reflected their data product and so we see a wide variety in the information stored in the Version field.  Unfortunately,  this makes it difficult to use the Version field for its original purpose which was disambiguating between different collections of the same data. ECSE-155 attempts to standardize the format of the Version field in a way that clarifies the field contents and enables collection disambiguation.

Column

JIRA Linkage

Jira
serverEarthdata Ticketing System
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId9a2ac141-7181-31f1-a247-ccbc66e20158
keyECSE-155
<Ctrl+Shift+J allows you to link to your ECSE JIRA ticket easily.

  Replace the ticket above with your ticket>

 

 

Background:

Origin of Version --  In the early days of EOSDIS, the priority was on defining systems to support large flagship missions such as Aqua and Terra.  Since the data produced by these flagship missions was expected to be collected and supported for decades, it was recognized that the data products would be periodically reprocessed using new algorithms that incorporated the latest scientific understanding.  The resultant data products could be significantly different from the previously created data products.  To distinguish between the data produced by different processing algorithms,  the ECS data model incorporated a Version that was meant to represent a specific version of the algorithms that were used to produce a new “version”  of a Collection.   

...

Version should be presented as   Major.MInor, such as 3.0,  or 6.4

Changes to CMR

<Describe any changes that CMR would need to make here.  Would additional fields need to be indexed?  Additional validation rules?  etc>

What should the MMT forms look like

<Describe changes to MMT> 

How should the values in these fields be presented to the user on the EDSC

<Describe changes to EDSC in terms of facet changes, data display changes or functionality changes>