Description

Element Description

A brief explanation of the service. 

Best Practices

The description should contain information about the service, the purpose of the service, the parameters (or variables) being invoked, and what are the sources of the data for the service.

The following information should be included (when applicable):

• Similarities and differences of the service to other related services.
• The purpose and/or intended use of the service.
• Any other pertinent information a user might find helpful.
• Utilize a standard mixed case capitalization scheme.
• All acronyms should be defined.
• Use complete sentences and proper grammar.

Examples:

• OPeNDAP example: OPeNDAP, the Open-source Project for a Network Data Access Protocol, is a NASA community standard DAP that provides a simple way for researchers to access and work with data over the internet. OPeNDAP's client/server software allows users to subset and reformat data using an internet browser, command line interface, or custom user interface such as a C NetCDF or Java NetCDF-compliant data analysis program.
• SEDAC Hazards mapper example: The SEDAC Hazards Mapper enables users to visualize data and map layers related to Socioeconomic, Infrastructure, Natural Disasters, and Environment and analyze potential impacts and exposure. The web app mashups layers from various sources including SEDAC, NASA LANCE, NASA GIBS, USGS, NOAA, ESRI, and others.
• Web service example: MODAPS Web Services provides an Application Programming Interface (API) to access the data products provided by the Level 1 and Atmosphere Archive and Distribution System (LAADS). The mission of MODAPS Web Services is to provide programmatic and/or scriptable access to MODIS level 1 and atmosphere data products. Capabilities include parameter sub-setting, geographic sub-setting, day/night granule search, metadata search, masking, channel sub-setting, tile re-projection, order tracking, granule re-projection, GeoTIFF re-formatting and mosaicking.

Element Specification

Metadata Validation

All records undergo CMR schema and business rule validation before entering the system. 

• This element is required.
• Must contain at least 1 character and be no longer than 1024 characters in length.

History

UMM Versioning