Page History

Element Description

The Entry Title element describes states the title of the dataset. It is a required element in UMM-C. 

Best Practices

The Entry Title should be a descriptive, formal title of the dataset. The Entry Title should not be the same as the Short Name element. It is recommended that the Entry Title follow a mixed case capitalization scheme and that the use of special characters (such as underscores) and acronyms be kept to a minimum, if possible. In order to make titles descriptive, important elements about the data may be included, such as: parameters measured, geographic location, instrument, project, temporal coverage, etc. 

The Data Product Development Guide for Data Producers offers the following guidance for naming a data product. The term "long name" in the excerpt below is synonymous with the "Entry Title" metadata element:

"The name of a data product is critical to its discovery in Earthdata Search and tools developed by
DAACs. DAACs have rules for naming data products, so selection of long and short names should be
a joint effort between producer and DAAC. DAAC involvement in naming also helps in making the
data products discoverable and EOSDIS-unique. Data products must be assigned both a long name,
which is meant to be human readable (and comprehensible), and a short name, which aids precise
searching by keyword. The data product long name and short name are considered global attributes
in that they are not associated with any particular variable but are related to the data product as a
whole.

Data producers should seek a name that will be understandable to the target user community but
also unique within EOSDIS. A reasonable data product name may already be in use (e.g., beginning
with “MODIS/Aqua” or MODIS/Terra”), and care should be taken to avoid naming conflicts by
consultation with the relevant data producers. Also consider interoperability when choosing names
[26].

There is no universal file-naming convention for NASA Earth Science data products, apart from the
DIWG recommendations regarding the components of file names provided in [26] (Rec. 3.8-3.11).
However, filenames should be unique and human-readable and contain information that is
descriptive of the contents.

The data product long name (not to be confused with the CF long_name attribute for individual
variables) is a scientific definition of the product. It should be as brief (but as complete) as possible,
as it expands on the sometimes-cryptic corresponding short name. Specifically, the long name
should be a character string from 45-90 characters to prevent wrapping and enhance readability
and scannability in interfaces (such as Earthdata Search) [49]. The attribute LongName is
synonymous with the attribute title used in netCDF documentation (see Appendix D.1).

The product long name should be included in the file as the global attribute LongName.

The recommended naming convention for data products includes the following information:

• The data source, usually the acronym/abbreviation for the project responsible for producing
the data, but can also be the instrument (e.g., HIRDLS, the High Resolution Dynamics Limb
Sounder), satellite (e.g., TRMM, the Tropical Rainfall Measuring Mission), or program (e.g.,
MEaSUREs, Making Earth System Data Records for Use in Research Environments); include
both the instrument and satellite names to eliminate ambiguity (e.g., MODIS/Aqua).

• Science content (e.g., Aerosol, Precipitation).

• The general spatial distribution of the data (e.g., gridded, swath, orbit, in situ).

• For gridded data, the temporal resolution (e.g., daily, monthly).

• Processing level (e.g., L2 or Level 2).

• Spatial resolution (e.g., 3 km; if there are multiple resolutions in the product, then the
highest resolution is stated)."

Examples:

"The San Joaquin Valley Air Quality Study (SJVAQS) Atmospheric Signatures, Predictions, and Experiments (AUSPEX) Database"

"Aquarius Official Release Level 3 Sea Surface Salinity Smoothed Standard Mapped Image Monthly Data V4.0"

"The Next Generation Weather Radar (NEXRAD) Level II, III, and IV Data Products"

Value needed for translations:

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.

Not applicable

Dialect Mappings

String

Enumeration Mapping

N/A

<Entry_Title>Aquarius Official Release Level 3 Sea Surface Salinity Smoothed Standard Mapped Image Monthly Data V4.0</Entry_Title>

"EntryTitle" : "Aquarius Official Release Level 3 Sea Surface Salinity Smoothed Standard Mapped Image Monthly Data V4.0",

Example Mapping

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