Page tree

 

 

 

 

Revision 1.0.0

Earth Science Data and Information Systems (ESDIS) Project, Code 423

 

 

Unified Metadata Model Services (UMM-S)

 


 

 

 

Signature/Approval Page

 

 

 

Prepared by:

 

 

 

 

 

 

 

Name

 

Date

Title/Role

 

 

Organization

 

 

 

 

 

Reviewed by:

 

 

 

 

 

 

 

Name

 

Date

Title/Role

 

 

Organization

 

 

 

 

 

Approved by:

 

 

 

 

 

 

 

Name

 

Date

Title/Role

 

 

Organization

 

 

 

 

 

Concurred by:

 

 

 

 

 

 

 

Name

 

Date

Title/Role

 

 

Organization

 

 

 

[Electronic] Signatures available in B32 Room E148

online at: / https://ops1-cm.ems.eosdis.nasa.gov/cm2/


Preface

This document is under ESDIS Project configuration control. Once this document is approved, ESDIS approved changes are handled in accordance with Class I and Class II change control requirements described in the ESDIS Configuration Management Procedures, and changes to this document shall be made by change bars or by complete revision.

 

Any questions should be addressed to: esdis-esmo-cmo@lists.nasa.gov

ESDIS Configuration Management Office (CMO)
NASA/GSFC

Code 423

Greenbelt, Md. 20771

 

 

 

 

 


Abstract

This document describes the Unified Metadata Model for Services (UMM-S) to be used by the NASA Earth Science community and addresses the need for describing services available on data, which is managed by repositories contributing their metadata to CMR. This community needs services that transform structured data into a structure that is convenient to the end user. Developers, engineers and architects should reference this document and the UMM as a guide when implementing CMR components, CMR clients or services that make use of the CMR or CMR clients.

 

This version of the service model describes the Minimal Viable Product (MVP). Hence, we focus on what is the minimum service metadata needed to support the User Interface/User Experience (UI/UX). In general, the Unified Metadata Model (UMM) covers both data and services. While the UMM-C (Collection), UMM-G (Granule) and UMM-Var (Variables) consider data, the UMM-S (Service) cover only services.

 

 

Keywords: UMM-S, UMM-Common, UMM-C, UMM-G, UMM-Var, Services, NASA Earthdata Search, Tools, EOSDIS, ESDIS, CMR, GCMD, SERF

Change History Log

 

Revision

Effective Date

Description of Changes

(Reference the CCR & CCB Approval Date)

V0.1.0

February 2015

Provisional Release.

V0.1.1

February 2015

Added ISO 19115-1

V0.1.2

May 2015

Added Normalize to Publication Reference

V0.1.3

July 2015

Updated from June 2015 Earth Science Data and Information System (ESDIS) Standards Office (ESO) review comments.

Changed the Parameter Search tag to Search API.

Removed Metadata Standard

Changed Metadata Dates to Metadata Date

Removed Lineage

Removed Data Dates

V0.1.4

September 2017

Revised for End-to-End Services

Design

V1.0.0

December 2017

Revised for addition of SERF fields

 

 


Table of Contents

1 Introduction

1.1 Purpose

1.2 Scope

1.3 Impact

1.4 Copyright Notice

1.5 Feedback

1.6 Document Conventions

1.7 Related Documentation

1.7.1 Applicable Documents

1.7.2 Reference Documents

2 Services Metadata Conceptual Model

2.1 Services Context Diagram

2.2 Use Case

2.2.1 a. Collection Search

2.3 UMM-S Metadata Model

2.3.1 Service

2.3.1.1 Name [R]

2.3.1.2 LongName [R]

2.3.1.3 Type [R]

2.3.1.4 Version [R]

2.3.1.5 Description [R]

2.3.1.6 RelatedURL [R]

2.3.1.7 ScienceKeywords [O]

2.3.1.8 ServiceKeywords [R]

2.3.1.9 ServiceOrganization [R]

2.3.1.10 ServiceContact [R]

2.3.1.10.1 ContactPerson [O]

2.3.1.10.2 ContactGroup [O]

2.3.1.11 Platform [O]

2.3.1.12 Instrument [O]

2.3.1.13 ServiceQuality [O]

2.3.1.14 AccessConstraints [O]

2.3.1.15 UseConstraints [O]

2.3.1.16 AncillaryKeywords [O]

2.3.2 Options

2.3.2.1 SubsetType [O]

2.3.2.2 SupportedProjections [O]

2.3.2.3 InterpolationType [O]

2.3.2.4 SupportedFormats [O]

2.3.3 Coverage [O]

2.3.3.1 Name [O]

2.3.3.2 Type [R]

2.3.3.3 SpatialExtent [R]

2.3.3.4 SpatialResolution [R]

2.3.3.5 SpatialResolutionUnits [R]

2.3.3.6 TemporalExtent [R]

2.3.3.7 TemporalResolution [R]

2.3.3.8 TemporalResolutionUnits [R]

2.3.3.9 RelativePath [O]

Appendix A: Deprecated Elements

Appendix B: Tags Glossary

Appendix C: Abbreviations and Acronyms

List of Figures

Figure 1: UMM Relationships showing key associations

Figure 2: Use Case – Collection Search

Figure 3: Sequence Diagram – Collection Search

Figure 4: Overall Service Model

List of Tables

Table 1: Cardinality

Table 2: Applicable Documents

Table 3: Reference Documents

 

 


1            Introduction

EOSDIS generates, archives, and distributes massive amounts of Earth Science data, which in turn are made available to the science community and the public at large. To aid in the search and discovery process, these data must be organized and cataloged, which makes accurate, complete, and consistent metadata a requirement for efficient accessibility.   To improve the quality and consistency among its metadata holdings, EOSDIS has developed a model describing metadata that it archives and maintains. The model represents CMR metadata elements that are useful for discovery​ and maps them to various metadata standards. This unified model, aptly named the Unified Metadata Model (UMM), has been developed as part of the EOSDIS Metadata Architecture Studies (MAS I and II) conducted between 2012 and 2013. The UMM will be used by the Common Metadata Repository (CMR) and will drive search and retrieval of metadata cataloged within that system.

 

This document describes a UMM reference profile referred to as the UMM-S, where 'S' stands for services. The updated UMM-S provides metadata to support the UI/UX-driven approach to End-to-End Services. Specifically, when a user wants to know what services are available for a particular collection, the user makes selections via the UI, e.g. subsetting, data transformations and the desired output file format. The UMM-S enables the population of the various options which are surfaced in the UI to support these selections. Each service record contains the identification of the service, i.e. name, type, version, description, service options for subsetting, available data transformations, and formatting. An important consideration of how the capabilities of the service are captured in UMM-S is to ensure that it can be accessed by both humans, via the UI, and by machines, via the API.

 

Since UMM-S is part of the UMM, there are common elements that are shared across the different UMM models and have already been documented in the UMM-Common document.   When this is the case, this document will provide a description of where the element is located in the UMM-Common.

 

1.1          Purpose

The motivation for UMM-S is to devise a services model applicable to CMR that (1) stores service metadata to support the End-to-End Service model, and (2) permits user selection of service options for data transformations which are available from the service (or services) for any given collection. In addition, the CMR services model is related to the other CMR metadata models, e.g. UMM-Var, which supports the specification of variables which may have associated services. We expect that these two models will mature together as more use cases are developed.

 

Note: the previous service design addressed the Service Entry Resource Format (SERF) standard. The SERF version of the service design included tools, software and instances of services, including web services, US and international web portals. This has been gradually growing over the last twenty years, and warrants revision. More recently, NASA’s Earth Observing System Data and Information System (EOSDIS) is evolving to expose data and services using standards based protocols in order to keep pace with evolving standards in Web Services, i.e. Open-source Project for a Network Data Access Protocol (OPeNDAP), Web Coverage Services (WCS), Web Mapping Services (WMS). In recent work [1] ) the EED2 team sought to understand how data were being accessed and for what purpose, and how this could be more simply achieved via services. To achieve this, the team has developed a UI/UX driven approach to services. We have called this model: "End-to-End Services". Here, the user experience guides what selections and choices a user makes at the UI for typical data transformations, e.g. spatial subsetting, reprojection, reformatting, etc. In this model, the user is exclusively concerned about what choices are available for a specific data set and the back-end services take care of any needed processing. An enterprise solution to how services are represented in the UMM, and the implementation of these services is required.

 

This document provides information to the National Aeronautics and Space Administration (NASA) Earth Science community. Distribution is unlimited.

1.2          Scope

This document describes the UMM Service   (UMM-S) model.

1.3          Impact

This document outlines a profile intended to be backward compatible with existing NASA Earth Science metadata implementations. It will impact providers from NASA Distributed Active Archive Centers (DAAC[s]) including service providers, Common Metadata Repository (CMR) client developers, metadata catalog developers, and users.

1.4          Copyright Notice

The contents of this document are not protected by copyright in the United States and may be used without obtaining permission from NASA.

1.5          Feedback

Questions, comments and recommendations on the contents of this document should be directed to support@earthdata.nasa.gov

1.6          Document Conventions

Each section of this document describes an element of the model and includes the following components:

 

  • Element Name: Specifies the element name.
  • Element Specification: Provides the sub elements, cardinality of the sub elements, and any other major factors that make up the element.
  • Description: Provides background information on the purpose of the element and its intended use. Furthermore, any information about the element's current usage, recommendations for usage, or unresolved issues is also documented here.
  • Cardinality: Indicates the expectation of counts for this element, summarized in Table 1.

 

 

  • Tags: Provides related keywords associated with each element. Tags have specific valid values, which are listed and defined in Appendix B: Tags Glossary.
  • Analysis: Provides information pertaining to legacy systems and if data is controlled within those systems.
  • Mapping: Gives an XPath mapping for this element in SERF and ISO 19115-2 XML representations. This can be considered as the "crosswalk" for this element.
  • Examples: XML snippets from cross-walked data formats documenting sample values for the element. Whenever possible, a URL to the specific service used for the metadata snippet is provided. ISO 19115-2 snippets were manually generated using the SERF data and the ISO 19115-2 schema.   A couple of examples were taken from collections that would have the same ISO 19115-2 representation.   The representations were developed using version 1.27 of the file ECHOtoISO.xsl. Current versions of this transformation can be found at https://cdn.earthdata.nasa.gov/iso/resources/transforms/
  • Recommendations: Provides any future recommendations for the element.

  Table 1 : Cardinality

Value

Description

1

Exactly one of this element is required

0..N

Optionally, up to and including N numberof this element may be present

0..*

Optionally, any number of this element may be present

1..*

At least one of this element is required, any number may be present

 

Unified Modeling Language (UML) class diagrams and element lists are provided for each subcomponent of the model. The [R] after an element name indicates that the element is required.


Some elements are tagged as 'Required (with Option)'. These elements are similar to the xml scheme <choice> element: one of the options is required, but there is a choice as to which option is utilized. For more information about the various tags used throughout this document, refer to Appendix B: Tags Glossary.

 

As described in the Introduction, there is a UMM-Common document that contains elements and their details common to multiple UMM profiles.   While this document will refer to those elements and its details, this document takes precedence.   Any elements and their details described in this document override the details found in the UMM-Common document.   Examples include, but are not limited to a sub element cardinality difference - usually starting from either a 0 or 1, additional sub elements, sub elements that should be excluded, additional analysis or recommendations, etc.

1.7          Related Documentation

There is a document that fully describes   metadata elements that are used in multiple models. This document, the UMM-Common (https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents) is documented separately. The Service model makes several references to the UMM-Common throughout.

 

The latest versions of all documents below should be used. The latest ESDIS Project documents can be obtained from URL: https://ops1-cm.ems.eosdis.nasa.gov .   ESDIS documents have a document number starting with either 423 or 505. Other documents are available for reference in the ESDIS project library website at: http://esdisfmp01.gsfc.nasa.gov/esdis_lib/default.php unless indicated otherwise.

1.7.1         Applicable Documents

The following documents are referenced within or are directly applicable, or contain policies or other directive matters that are binding upon the content of this document.

Table 2 : Applicable Documents

CMR Life Cycle

https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents

UMM-Common

https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents

SERF

https://gcmd.nasa.gov/Aboutus/xml/serf/serf.xsd

https://gcmd.nasa.gov/add/serfguide/index.html  

CMR End To End Services Study

https://rms.earthdata.nasa.gov/perspective.req - _ftnref1 CMR End-To-End Services Study (Task 25) EED2-TP-025: https://drive.google.com/open?id=0BzJ0Mge7A2GEQ0NlZ0tnQktlbnM

 

1.7.2         Reference Documents

The following documents are not binding on the content but referenced herein and, amplify or clarify the information presented in this document.

  Table 3 : Reference Documents

Tags

http://en.wikipedia.org/wiki/Tag_%28metadata%29

Translators

Translators to ISO can be found at https://cdn.earthdata.nasa.gov/iso/resources/transforms/

XPath

XPath is a language for addressing parts of an XML document, designed for use with XSLT.

XLinks

http://en.wikipedia.org/wiki/XLink

 

2            Services Metadata Conceptual Model

 

2.1          Services Context Diagram

Any service metadata described by the UMM-S may be associated with other metadata, such as collection (UMM-C) metadata, granule (UMM-G) metadata, and variables (UMM-Var).   In addition, as shown in Figure 1, each service may have associated variables and may be searched for via a collection. Furthermore, each service has a single instance of an OnlineResource, which contains a web services linkage (universal resource locator). This will enable data to be requested, accessed, subsetted and downloaded or streamed via the corresponding service.   Finally, all UMM models and the CMR Lifecycle are documented separately.   The CMR Lifecycle represents how metadata is managed over time, and will govern this model, all related documentation and facilitate change.   These documents are located at: https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents .

 

Figure 1 shows the UMM-S metadata class at a high-level and specifically depicts the relationship of UMM-S to the other models in the context of the Unified Metadata Model by mapping its   relationships with the other key entities: Collection, Granule,   and Variable.

 

Note: These entities are represented in abbreviated forms.

https://documents.lucidchart.com/documents/78d0d453-a719-47c9-a1a4-5c95fc46c474/pages/-kxETCOecEnU?a=1532&x=-172&y=-252&w=1502&h=760&store=1&accept=image%2F*&auth=LCA%20372aab754c8977fd482b81f7473c9d889b37c974-ts%3D1507730240 data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D

Figure 1 : UMM Relationships showing key associations  

2.2          Use Case

This section provides a use case and sequence diagram identified for the UMM-S. A sequence diagram is presented after the use case.

 

2.2.1         a. Collection Search

As a user of the Earthdata Search Client (EDSC), I can perform a Collection Search and discover the available variables and service options in the CMR.  

Scenario [a]:   As a user of the Earthdata Search Client (EDSC), I can get a list of Collections from the CMR. For each collection, I can make a request to determine whether the following local operators are "true": "has_variables", "has_transforms" or "has_formats".

Scenario [b]:   As a user of the Earthdata Search Client (EDSC), I have a collection and I can make a request to return all the variables and service options from the CMR. The Service options include details of the available data transformations, and format conversions that can be requested.

Scenario [c]:   As a user of the Earthdata Search Client (EDSC), I can select collection(s) and I can make a request to return all the variables and service options from the CMR for the selected collections.

 

Outcomes:   As an EDSC user, with no knowledge of the Service capabilities captured in the CMR, I can perform a Collection search and subsequently discover the variables, the associated services, and available service options. These enable the EDSC user to determine whether the collections have variables, transforms, and formats; as well as to gather the details of these and make selections in the UI modals - which are captured in the user's project. These selections can be subsequently used to make a data transformation request.

 

Definitions:

 

Variable: A variable is typically used to store a science value within a data file, e.g. radiances, brightness temperatures, or sea surface temperatures.   However, it but can also be used to store geolocation information, e.g. latitude, longitude, or ancillary information, e.g. engineering values from an instrument. Typically, variables can be represented within a granule metadata structure, and are defined uniquely on a collection by collection basis. Variables are grouped into sets of variables, and are organized according to the order found within the metadata granule header. Within the UMM, the word "variable" is used in place of the word "parameter".

 

Service: A service has various abilities to transform variables. The service can be remotely accessed via a universal resource locator, e.g. a web service.

 

Data Transformation (or transform): A data transformation is a specific capability available from a service, e.g. spatial subsetting or reprojection. It is an umbrella term that represents a method for transforming data from one form to another. For example: spatial subsetting might be used on data that exists with a global extent, to subset it to a regional extent. The list of data transformations available is service provider dependent e.g. at Goddard Earth Sciences Data and Information Services Center (GES DISC), a typical OPeNDAP service provides: spatial subsetting, variable subsetting, and data format conversion. This list of data transformations available is dependent on the service provider.

 

Format: The file format used to store the data on the file system. The data can be transformed to a different format through the use of a service, e.g HDF4 -> GeoTIFF. The native file format and the list of available output file formats will be available from the UMM-S.

 

Note: Within the EDSC UI, there are three modals when we arrive to the point of selections of service options in the workflow: the first to list the Variables (which have services), a second for Data Transformations, and a third for formats. In the model, we don't need to separate the formats out into its own class, provided the model can support the UI, in terms of what metadata it needs to "surface."

 

Use Case:   see use case diagram below

 

https://rms.earthdata.nasa.gov/attachment/5872/Use%20Cases%20-%20UMM-S%20-%20Revised%20Collection%20Search.png data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D

Figure 2 : Use Case – Collection Search

 

Workflow:   see sequence diagram below

 

Figure 3 : Sequence Diagram – Collection Search  

 

2.3          UMM-S Metadata Model

The service metadata conceptual profile shown in Figure 4 is a high-level profile that has been broken down into three main classes for Services: Service, Options, and Coverage with each class describing a different aspect of the service. The Collection and Variables classes are represented here to highlight these important relationships with the Service class. Each aspect is described in more detail in the subsequent sections of this ​document.

https://rms.earthdata.nasa.gov/attachment/5914/UMM-S%20UML%20Diagram%20-%20UMM-S%20Simplified%20w_SERF%20%281_2_216PM%29.png data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D

 

Figure 4 : Overall Service Model  

The function of the Service class is to enable the service to be specified by its unique service metadata. Each service will be identified in terms of its name, type, version and description. A universal resource locator is used to capture the RESTful service endpoint for the service. The OnlineResource class has attributes used to describe the universal resource locator.   Within this class, the Linkage attribute is used to specify the service endpoint.

 

The function of the Options class is to capture the various data transformations and formats available from the service.

 

The function of the Layer class is to capture specific information about the layer (or identifier). If the service has layers, then the name and the path relative to the service endpoint may be specified, for each layer.

 

Note: Typically, OPeNDAP service layers are mapped 1:1 with the variables represented in UMM-Var. By contrast, typical WMS or WCS identifiers can be mapped 1:1 with the variables represented in UMM-Var, but the name of the layers sometimes differs from the variable names. This is dependent on choices in naming layers made by each service provider.

 

2.3.1         Service

The Service class contains basic information about the service itself, its identifying information, and its uniform resource locator. It contains the five elements described below.

 

Service [1..N]

Service /Name [R]

Service /LongName [R]

Service /Type [R]

Service /Version [R]

Service /Description [R]

Service /RelatedURL [R]

Service /SciencKeywords [O]

Service /ServiceKeywords [R]

Service /ServiceOrganization [R]

Service /ServiceContact [R]

Service /Platform [O]

Service /Instrument [O]

Service /ServiceQuality [R]

Service /AccessConstraints [O]

Service /UseConstraints [O]

Service /AncillaryKeywords [O]

2.3.1.1        Name [R]

Element Specification

Service/Name (1)

 

Description

The name of the service, software, or tool.

 

Sample Values (service example): " SERVIR ".

 

Sample Values (software example): " BYU_slice_response ".

 

Sample Values (tool example): " USGS_TOOLS_LATLONG ".

 

Tags

Required

 

2.3.1.2        LongName [R]

Element Specification

Service/LongName (1)

 

Description

The long name of the service, software, or tool.

 

Sample Value (service example: " Mesoamerican Visualization and Monitoring System (SERVIR) ".)

 

Sample Value (software example: " SeaWinds 3D Slice Response Software ".)

 

Sample Value (tool example: " WRS-2 Path/Row to Latitude/Longitude Converter ".)

 

Tags

Required

 

2.3.1.3        Type [R]

Element Specification

Service/Type (1) <ESI, OPeNDAP, WMS, WCS>

 

Description

The type of the service, software, or tool.

 

Please note that Type values will come from KMS which is a controlled list.

 

Also: The service type not only needs to support REST-based APIs that are WCS or OPeNDAP, but those that are not.  

 

Sample Value: WCS

 

Tags

Required ,   Controlled Vocabulary

 

2.3.1.4        Version [R]

Element Specification

Service/Version (1)

 

Description

The edition or version of the service, software, or tool.

 

Sample Value: 1.1.1

 

Tags

Required

 

2.3.1.5        Description [R]

Element Specification

Service/Description (1)

 

Description

A brief description of the service, software, or tool.

 

Sample Value (service 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.

 

Sample Value (software example):   " Imaging applications of SeaWinds on QuikSCAT and ADEOS II are facilitated by applying reconstruction and resolution enhancement algorithms to produce high resolution images of the surface normalized radar cross section (sigma-0). Such algorithms require a description of the spatial response functions of the measurements. The pencil-beam design of Seawinds, coupled with the onboard processing. "

 

Sample Value (tool example): " The USGS WRS-2 Path/Row to Latitude/Longitude Converter allows users to enter any Landsat path and row to get the nearest scene center latitude and longitude coordinates. You can also enter coordinates in the second section to discover the closest Landsat path and row - daytime (descending) or nighttime (ascending). "

 

Tags

Required

 

 

2.3.1.6        RelatedURL [R]

Element Specification

Service/RelatedURL (1)

 

Description

This element contains important information about the universal resource locator (URL) for the service. These include the following required elements: Name, Description and URL. The details are located in the UMM-Common document.

 

RelatedURL (0..*)

RelatedURL/URL (1)

RelatedURL/Description (0..1)

RelatedURL/URLContentType (1)     <CollectionURL, PublicationURL, DataCenterURL, DistributionURL, DataContactURL, VisualizationURL>

RelatedURL/Type (1)                                             {Valid values shown below}

RelatedURL/Subtype (0..1)                         {Valid values shown below}

 

Set Type:   select from the following list:

 

  • GET DATA
  • GET SERVICE

 

Set Subtype: select from the following list:

 

  • ACCESS MAP VIEWER
  • ACCESS MOBILE APP
  • ACCESS WEB SERVICE
  • DIF
  • MAP SERVICE
  • NOMADS
  • OPENDAP DATA
  • OPENDAP DATA (DODS)
  • OPENDAP DIRECTORY (DODS)
  • OpenSearch
  • SERF
  • SOFTWARE PACKAGE
  • SSW
  • SUBSETTER
  • THREDDS CATALOG
  • THREDDS DATA
  • THREDDS DIRECTORY
  • TOOL
  • WEB COVERAGE SERVICE (WCS)
  • WEB FEATURE SERVICE (WFS)
  • WEB MAP FOR TIME SERIES
  • WEB MAP SERVICE (WMS)
  • WORKFLOW (SERVICE CHAIN)

 

Please note:   these keywords will be in KMS following the 8.6 keyword release in March 2018.

 

The following examples show how the above fields should be completed for service, software package and tools examples.

 

Sample Value (service example):

RelatedURL/URL: " https://www.servirglobal.net/default.aspx "

RelatedURL/Description: "SERVIR-Mesoamerica is regional service that provides a suite of analysis and visualization tools that integrate satellite and other geospatial data"

 

For services, select URLContentType:   DistributionURL

 

Set Type: GET SERVICE

 

Set Subtype:   ACCESS WEB SERVICE

 

Sample Values (software package example): "SeaWinds 3D Slice Response Software"

RelatedURL/URL: "http://www.scp.byu.edu/software/slice_response/Xshape_temp.html"

RelatedURL/Description: "Access the SeaWinds 3D Slice Response software."

 

For software package, select URLContentType:   DistributionURL

 

Set Type:   GET SERVICE

 

Set Subtype: SOFTWARE PACKAGE

 

Sample Values (tool example): " USGS_TOOLS_LATLONG "

RelatedURL/URL: "https://landsat.usgs.gov/wrs-2-pathrow-latitudelongitude-converter"

RelatedURL/Description: "Access the WRS-2 Path/Row to Latitude/Longitude Converter."

 

For tools, select URLContentType:   DistributionURL

 

Set Type:   GET SERVICE

 

Set Subtype:   TOOL

 

The following   example   shows how the above fields should be completed for an   OPeNDAP service   example.

 

If the service type is OPeNDAP, the RelatedURL/URL field may be populated with the root URL to the OPeNDAP service.

 

Sample Value   (OPeNDAP service example):

 

RelatedURL/URL: "https://acdisc.gesdisc.eosdis.nasa.gov/opendap/Aqua_AIRS_Level3/AIRX3STD.006/"

RelatedURL/Description: "OPeNDAP Service for AIRX3STD.006"

 

For OPeNDAP services, select URLContentType:   DistributionURL

 

Set Type:   GET SERVICE

 

Set Subtype: OPENDAP DATA

 

Tags

Required

 

Note: we are reviewing the list of fields which apply to the URL. We are looking at ways to expand the use of RelatedURL for services, or service API specification. New fields under consideration, include one to set configurable granule order limits, when ordering data via a service. This could be used for display on the UI as an exceedance warning, when a user places a request which will consume resources unduly.  

 

2.3.1.7        ScienceKeywords [O]

Element Specification

Service/ScienceKeywords (1)

Service/ScienceKeywords/Category     (1)
Service/ScienceKeywords/Topic     (1)
Service/ScienceKeywords/Term     (1)
Service/ScienceKeywords/VariableLevel1     (0..1)
Service/ScienceKeywords/VariableLevel2     (0..1)
Service/ScienceKeywords/VariableLevel3     (0..1)
Service/ScienceKeywords/DetailedVariable     (0..1)

 

Description

Allows for the specification of Earth Science keywords that are representative of the service, software, or tool being described. The controlled vocabulary for Science Keywords is maintained in the Keyword Management System (KMS).

 

Sample Value: "EARTH SCIENCE > SOLID EARTH > TECTONICS > EARTHQUAKES > EARTHQUAKE OCCURRENCES"

 

Tags

Optional

 

 

 

2.3.1.8        ServiceKeywords [R]

Element Specification

Service/ServiceKeywords (1)

Service/ServiceKeywords/ServiceCategory (1)
Service/ServiceKeywords/ServiceTopic (1)
Service/ServiceKeywords/ServiceTerm (1)
Service/ServiceKeywords/ServiceSpecificName (0..1)

 

Description

Allows for the specification of Earth Science Service keywords that are representative of the service, software, or tool being described. The controlled vocabulary for Service Keywords is maintained in the Keyword Management System (KMS).

 

Sample Value: "ServiceCategory: Earth Science Services,   ServiceTopic: Data Management/Data Handling,   ServiceTerm: Data Search and Retrieval".

 

Tags

Required

 

2.3.1.9        ServiceOrganization [R]

Element Specification

Service/ServiceOrganization (1..*)

Service/ServiceOrganization/Roles (1..*)     <SERVICE PROVIDER, DEVELOPER, PUBLISHER, AUTHOR, ORIGINATOR>

Service/ServiceOrganization/ShortName (1)

Service/ServiceOrganization/LongName (0..1)

Service/ServiceOrganization/Uuid (0..1)

Service/ServiceOrganization/ContactInformation (0..1)

Service/ServiceOrganization/ContactInformation/RelatedURL (0..*)

Service/ServiceOrganizationContactInformation/ServiceHours (0..1)

Service/ServiceOrganizationContactInformation/ContactInstructions (0..1)

Service/ServiceOrganization/ContactInformation/ContactMechanism (0..*)

Service/ServiceOrganization/ContactInformation/ContactMechanism/Type (1)   <Direct Line, Email, Facebook, Fax, Mobile, Modem, Primary, TDD/TTY Phone, Telephone, Twitter, U.S. toll free, Other>

Service/ServiceOrganization/ContactInformation/ContactMechanism/Value (1)

Service/ServiceOrganization/ContactInformation/Address (0..*)

Service/ServiceOrganization/ContactInformation/Address/StreetAddresses (0..*)

Service/ServiceOrganization/ContactInformation/Address/City (0..1)

Service/ServiceOrganization/ContactInformation/Address/StateProvince (0..1)

Service/ServiceOrganization/ContactInformation/Address/PostalCode (0..1)

Service/ServiceOrganization/ContactInformation/Address/Country (0..1)

 

CHOICE OF:

 

Service/ServiceOrganization/ContactPerson (0..*)

Service/ServiceOrganization/ContactPerson/Roles (1..*) <SERVICE PROVIDER CONTACT,, TECHNICAL CONTACT, SCIENCE CONTACT, INVESTIGATOR, SOFTWARE AUTHOR, TOOL AUTHOR, USER SERVICES, SCIENCE SOFTWARE DEVELOPMENT>

Service/ServiceOrganization/ContactPerson/NonServiceOrganizationAffiliation (0..1)

Service/ServiceOrganization/ContactPerson/FirstName (0..1)

Service/ServiceOrganization/ContactPerson/MiddleName (0..1)

Service/ServiceOrganization/ContactPerson/LastName (1)

Service/ServiceOrganization/ContactPerson/Uuid (0..1)

Service/ServiceOrganization/ContactPerson/ContactInformation (0..1)

Service/ServiceOrganization/ContactPerson/ContactInformation/RelatedURL (0..*)

Service/ServiceOrganization/ContactPerson/ContactInformation/ServiceHours (0..1)

Service/ServiceOrganization/ContactPerson/ContactInformation/ContactInstructions (0..1)

Service/ServiceOrganization/ContactPerson/ContactInformation/ContactMechanism (0..*)

Service/ServiceOrganization/ContactPerson/ContactInformation/ContactMechanism/Type (1) <Direct Line, Email, Facebook, Fax, Mobile, Modem, Primary, TDD/TTY Phone, Telephone, Twitter, U.S. toll free, Other>

Service/ServiceOrganization/ContactPerson/ContactInformation/ContactMechanism/Value (1)

Service/ServiceOrganization/ContactPerson/ContactInformation/Address (0..*)

Service/ServiceOrganization/ContactPerson/ContactInformation/Address/StreetAddresses (0..*)

Service/ServiceOrganization/ContactPerson/ContactInformation/Address/City (0..1)

Service/ServiceOrganization/ContactPerson/ContactInformation/Address/StateProvince (0..1)

Service/DataCenter/ContactPerson/ContactInformation/Address/PostalCode (0..1)

Service/DataCenter/ContactPerson/ContactInformation/Address/Country (0..1)

 

OR

 

Service/ServiceOrganizationContactGroup (0..*)

Service/ServiceOrganization/ContactGroup/Roles (1..*) <SERVICE PROVIDER CONTACT, TECHNICAL CONTACT, SCIENCE CONTACT, INVESTIGATOR, SOFTWARE AUTHOR, TOOL AUTHOR, USER SERVICES, SCIENCE SOFTWARE DEVELOPMENT>

Service/ServiceOrganizationContactGroup/NonServiceOrganizationAffiliation (0..1)

Service/ServiceOrganization/ContactGroup/GroupName (1)

Service/ServiceOrganization/ContactGroup/Uuid (0..1)

Service/ServiceOrganizationContactGroup/ContactInformation (0..1)

Service/ServiceOrganization/ContactGroup/ContactInformation/RelatedURL (0..*)

Service/ServiceOrganization/ContactGroup/ContactInformation/ServiceHours (0..1)

Service/ServiceOrganization/ContactGroup/ContactInformation/ContactInstructions (0..1)

Service/ServiceOrganization/ContactGroup/ContactInformation/ContactMechanism (0..*)

Service/ServiceOrganization/ContactGroup/ContactInformation/ContactMechanism/Type (1) <Direct Line, Email, Facebook, Fax, Mobile, Modem, Primary, TDD/TTY Phone, Telephone, Twitter, U.S. toll free, Other>

Service/ServiceOrganization/ContactGroup/ContactInformation/ContactMechanism/Value (1)

Service/ServiceOrganization/ContactGroup/ContactInformation/Address (0..*)

Service/ServiceOrganization/ContactGroup/ContactInformation/Address/StreetAddresses (0..*)

Service/ServiceOrganization/ContactGroup/ContactInformation/Address/City (0..1)

Service/ServiceOrganization/ContactGroup/ContactInformation/Address/StateProvince (0..1)

Service/ServiceOrganizationContactGroup/ContactInformation/Address/PostalCode (0..1)

Service/ServiceOrganization/ContactGroup/ContactInformation/Address/Country (0..1)

 

Description

The service provider, or organization, or institution responsible for developing, archiving, and/or distributing the service, software, or tool.

 

Please note   that ShortName and LongName values come from KMS which is a controlled list.

 

Sample Value: "Role: SERVICE PROVIDER, ShortName: SEDAC, LongName: Socioeconomic Data and Applications Center".

 

Tags

Required, Controlled Vocabulary

 

2.3.1.10    ServiceContact [R]

Element Specification

Service/ServiceContact (1)

 

Description

The ServiceContact is the point of contact for more information about the service, software, or tool.

 

ServiceContact is a parent element to the ContactPerson and   the ContactGroup elements. Its purpose is to hold shared elements that its children will use. The ServiceContact element must exist with at least 1 of its children; it cannot exist on its own.

 

The ContactPerson and the ContactGroup elements are described in detail in their respective sub-sections.  

 

Sample Value:

ContactGroup/Roles: TECHNICAL CONTACT

ContactGroup/GroupName: SEDAC USER SERVICES

ContactGroup/ContactInformation/ContactMechanism/Type: Email

ContactGroup/ContactInformation/ContactMechanism/Value: ciesin.info@ciesin.columbia.edu

ContactGroup/ContactInformation/ContactMechanism/Type: DirectLine

ContactGroup/ContactInformation/ContactMechanism/Value: +1 845-365-8920

ContactGroup/ContactInformation/ContactMechanism/Type: Fax

ContactGroup/ContactInformation/ContactMechanism/Value: +1 845-365-8922

ContactGroup/ContactInformation/Address/StreetAddresses: 61 Route 9W. P.O. Box 1000 Palisades

ContactGroup/ContactInformation/ContactMechanism/Address/StateProvince: NY

ContactGroup/ContactInformation/ContactMechanism/Address/PostalCode:10964

ContactGroup/ContactInformation/ContactMechanism/Address/Country: USA

 

Tags

Required

 

2.3.1.10.1   ContactPerson [O]

Element Specification:

ContactPerson (0..*)

ContactPerson/Roles (1..*) <Service Provider Contact, Technical Contact, Science Contact, Investigator, Metadata Author>

ContactPerson/NonDataCenterAffiliation (0..1)

ContactPerson/FirstName (0..1)

ContactPerson/MiddleName (0..1)

ContactPerson/LastName (1)

ContactPerson/Uuid (0..1)

ContactPerson/ContactInformation (0..1)

ContactPerson/ContactInformation/RelatedURL (0..*)

ContactPerson/ContactInformation/ServiceHours (0..1)

ContactPerson/ContactInformation/ContactInstructions (0..1)

ContactPerson/ContactInformation/ContactMechanism (0..*)

ContactPerson/ContactInformation/ContactMechanism/Type (1) <Direct Line, Email, Facebook, Fax, Mobile, Modem, Primary, TDD/TTY Phone, Telephone, Twitter, U.S. toll free, Other>

ContactPerson/ContactInformation/ContactMechanism/Value (1)

ContactPerson/ContactInformation/Address (0..*)

ContactPerson/ContactInformation/Address/StreetAddresses (0..*)

ContactPerson/ContactInformation/Address/City (0..1)

ContactPerson/ContactInformation/Address/StateProvince (0..1)

ContactPerson/ContactInformation/Address/PostalCode (0..1)

ContactPerson/ContactInformation/Address/Country (0..1)

 

Description:

This element includes metadata telling a service user whom they may contact to get information about that service, and how they may contact that person. There may be zero to many contact persons. There may be both a contact person or persons   and a contact group or groups for a given service.

 

Tags

Recommended

 

2.3.1.10.2   ContactGroup [O]

Element Specification:

ContactGroup (0..*)

ContactGroup/Roles (1..*) <TECHNICAL CONTACT, User Services, Science Software Development>

ContactGroup/NonDataCenterAffiliation (0..1)

ContactGroup/GroupName (1)

ContactGroup/Uuid (0..1)

ContactGroup/ContactInformation (0..1)

ContactGroup/ContactInformation/RelatedURL (0..*)

ContactGroup/ContactInformation/ServiceHours (0..1)

ContactGroup/ContactInformation/ContactInstructions (0..1)

ContactGroup/ContactInformation/ContactMechanism (0..*)

ContactGroup/ContactInformation/ContactMechanism/Type (1) <Direct Line, Email, Facebook, Fax, Mobile, Modem, Primary, TDD/TTY Phone, Telephone, Twitter, U.S. toll free, Other>

ContactGroup/ContactInformation/ContactMechanism/Value (1)

ContactGroup/ContactInformation/Address (0..*)

ContactGroup/ContactInformation/Address/StreetAddresses (0..*)

ContactGroup/ContactInformation/Address/City (0..1)

ContactGroup/ContactInformation/Address/StateProvince (0..1)

ContactGroup/ContactInformation/Address/PostalCode (0..1)

ContactGroup/ContactInformation/Address/Country (0..1)

 

Description:

This element includes metadata telling a service user which group   they may contact to get information about that service, including how they may contact that group.     There may be zero to many contact groups.

There may be both a contact person or persons and a contact group or groups for a given service.

 

Tags

Recommended

 

2.3.1.11    Platform [O]

Element Specification

Service/Platform (0..*)
Service/Platform/Type     (0..1)
Service/Platform/ShortName     (1)
Service/Platform/LongName     (0..1)
Service/Platform/Characteristics     (0..*)
Service/Platform/Characteristics/Name     (1)
Service/Platform/Characteristics/Description     (1)
Service/Platform/Characteristics/DataType     (1)
Service/Platform/Characteristics/Unit     (1)
Service/Platform/Characteristics/Value     (1)
Service/Platform/Instrument     (1..*)     {See Instrument for full specification}

 

Description

Associates the satellite/platform that is supported by the service, software, or tool.

 

Please note that ShortName and LongName values come from KMS which is a controlled list.

 

Sample Value:

 

ShortName: AQUA

LongName: Earth Observing System, AQUA

 

Tags

Optional, Controlled Vocabulary

 

2.3.1.12    Instrument [O]

Element Specification

Service/Platform/Instrument (0..*)
Service/Platform/Instrument/ShortName     (1)
Service/Platform/Instrument/LongName     (0..1)
Service/Platform/Instrument/Technique     (0..1)
Service/Platform/Instrument/Characteristics     (0..*)
Service/Platform/Instrument/Characteristics/Name     (1)
Service/Platform/Instrument/Characteristics/Description     (1)
Service/Platform/Instrument/Characteristics/DataType     (1)
Service/Platform/Instrument/Characteristics/Unit     (1)
Service/Platform/Instrument/Characteristics/Value     (1)
Service/Platform/Instrument/OperationalMode     (0..*)

Service/Platform/Instrument/NumberOfInstruments     (0..1)

Service/Platform/Instrument/ComposedOf/Instrument   (0..*)

 

Description

Associates the instrument/sensor that is supported by the service, software, or tool.

 

Please note that ShortName and LongName values come from KMS which is a controlled list.

 

Sample Value:

 

ShortName: MODIS

LongName: Moderate-Resolution Imaging Spectroradiometer

 

Tags

Optional, Controlled Vocabulary

 

2.3.1.13    ServiceQuality [O]

Element Specification

Service/ServiceQuality (0..1)

 

Description

Information about the quality of the service, software, or tool, or any quality assurance procedures followed in development.

 

Sample Value: "The software has been reviewed for quality and errors have been found".

 

Tags

Optional

 

2.3.1.14    AccessConstraints [O]

Element Specification

Service/AccessConstraints (0..1)

 

Description

Information about any constraints for accessing the service, software, or tool.

 

Sample Value: "Registration is required to access this service".

 

Tags

Optional

 

2.3.1.15    UseConstraints [O]

Element Specification

Service/UseConstraints (0..1)

 

Description

Information on how the item (service, software, or tool) may or may not be used after access is granted. This includes any special restrictions, legal prerequisites, terms and conditions, and/or limitations on using the item. Providers may request acknowledgement of the item from users and claim no responsibility for quality and completeness.

 

Sample Value: "Please credit U.S. Geological Survey as the Service Provider".

 

Tags

Optional

 

Note: Use Constraints describes how the item may be used once access has been granted, and is distinct from Access Constraints, which refers to any constraints in accessing the item.

 

2.3.1.16    AncillaryKeywords [O]

Element Specification

Service/AncillaryKeywords (0..1)

 

Description

Words or phrases to further describe the service, software, or tool.

 

Sample Value: "Hierarchical Data Format, Document Type Definition, Web Map Service".

 

Tags

Optional

 

2.3.2         Options

The Options class contains information about the service options available.   It contains the four elements described below.

 

Options/   [0..N]

Options /SubsetType [O]

Options /SupportedProjections [O]

Options /InterpolationType [O]

Options /SupportedFormats [O]

 

2.3.2.1        SubsetType [O]

Element Specification

Options/SubsetType (0..*) <Spatial, Temporal, Variable>

 

Description

This element is used to identify the list of supported subsetting requests.

 

Sample Value: "Spatial, Variable"

 

Tags

Optional

 

2.3.2.2        SupportedProjections [O]

Element Specification

Options/SupportedProjections (0..*) <"Geographic", "Universal Transverse Mercator", "State Plane Coordinates", "Albers Equal-Area Conic",   "Lambert Conic Conformal",   "Mercator", "Polar Stereographic", "Transverse Mercator", "Lambert Azimuthal Equal Area", "Sinusoidal", "Cylindrical Equal Area", "UTM Northern Hemisphere", "UTM Southern Hemisphere", "Cylindrical", "EASE-Grid 2.0", "CEA(EASE-2.0)", "UTM(Transverse-Mercator)", "Native(No-Reprojection)">

 

Description

This element is used to identify the list of supported projection types.

 

Sample Value: "Geographic, Sinusoidal"

 

Tags

Optional

 

2.3.2.3        InterpolationType [O]

Element Specification

Options/InterpolationType (0..*) <Nearest Neighbor, Cubic Convolution, Distance-weighted average resampling, Bilinear Interpolation>

 

Description

This element is used to identify the list of supported interpolation types.

 

Sample Value: "Bilinear Interpolation, Nearest Neighbor, Cubic Convolution"

 

Tags

Optional

 

2.3.2.4        SupportedFormats [O]

Element Specification

Options/SupportedFormats (0..*) <HDF4, HDF5, HDF-EOS4, HDF-EOS5, netCDF-3, netCDF-4, Binary, ASCII, PNG, JPEG, GIF, TIFF, GeoTIFF, GeoTIFFInt16, GeoTIFFFloat32>

 

Description

The project element describes the list of format names supported by the service.

 

Sample Value: "HDF-EOS5, netCDF-4, GeoTIFF"

 

Tags

Optional

 

2.3.3         Coverage [O]

The Coverage class describes the layers or coverages available from the service. It contains the elements described below.

 

Coverage/ [0..N]

Coverage/Name [O]

Coverage/Type [R]

Coverage/SpatialExtent [R]

Coverage/SpatialExtent/Type [R] <SPATIAL POINT, SPATIAL LINE STRING, BOUNDING BOX, SPATIAL POLYGON>

Coverage/SpatialExtent/Uuid [R]

Coverage/SpatialResolution [R]

Coverage/SpatialResolutionUnits [R]

Coverage/TemporalExtent [R]

Coverage/TemporalExtent/TimePoints [R]

Coverage/TemporalExtent/TimePoints/Time [R]

Coverage/TemporalExtent/TimePoints/Value [R]

Coverage/TemporalExtent/TimePoints/Description [O]

Coverage/TemporalResolution [R]

Coverage/TemporalResolutionUnits [R]

Coverage/RelativePath [O]

 

CHOICE OF:

 

Coverage/SpatialExtent/SpatialPoint [O]

Coverage/SpatialExtent/SpatialPoint/Coordinates [O]

 

OR

 

Coverage/SpatialExtent/SpatialLineString [O]

Coverage/SpatialExtent/SpatialLineString/Coordinates [O]

 

OR

 

 

Coverage/SpatialExtent/SpatialBoundingBox

Coverage/SpatialExtent/SpatialBoundingBox/BBox [O]

 

OR

 

Coverage/SpatialExtent/SpatialPolygon [O]

Coverage/SpatialExtent/SpatialPolygon/Coordinates [O]

 

2.3.3.1        Name [O]

Element Specification

Coverage/Name (0..*)

 

Description

The name of the layer or coverage available from the service.

 

Sample Values: "cell_antenna_scan_angle_aft", or "sea_ice_concentration_01", or "seasonal_snow_classification", or "snow_extent_01" or "antarctic_bedrock_elevation" or "CH4_VMR_A", or "power_601_daily_t10m_lst".

 

Tags

Optional

 

2.3.3.2        Type [R]

Element Specification

Coverage/Type (1..*)

 

Description

The type of the layer or coverage available from the service.

 

Sample Values: "raster".

 

Tags

Required

 

2.3.3.3        SpatialExtent [R]

Element Specification

Coverage/SpatialExtent(1)

Coverage/Uuid (1)

 

Description

The spatial extent of the layer or coverage available from the service. These are coordinate pairs which describe either the point, line string, boundingbox, or polygon representing the spatial extent.

 

Sample Values (SpatialPoint example):

 

Coverage/SpatialExtent/SpatialPoint

Coverage/SpatialExtent/SpatialPoint/Coordinates: ("34.32", "-167.63")

 

OR (SpatialLineString example)

 

Coverage/SpatialExtent/SpatialLineString

Coverage/SpatialExtent/SpatialLineString/Coordinates: ("23.04", "78.32"), (26.75", "78.12")

 

OR (SpatialBoundingBox example)

 

Coverage/SpatialExtent/SpatialBoundingBox

Coverage/SpatialExtent/SpatialBoundingBox/BBox: -180.0, -90.0, 180.0, 90.0

 

 

OR (SpatialPolygon example)

 

Coverage/SpatialExtent/SpatialPolygon

Coverage/SpatialExtent/SpatialPolygon/Coordinates: ("36.92", "-120.72"), ("37.74", "-121.84"), ("41.84", "-123.84"), ("35.83", "-120.92")

 

Tags

Required

 

2.3.3.4        SpatialResolution [R]

Element Specification

Coverage/SpatialResolution(1)

 

Description

The spatial resolution of the layer or coverage available from the service.

 

Sample Values: "10".

 

Tags

Required

 

2.3.3.5        SpatialResolutionUnits [R]

Element Specification

Coverage/SpatialResolution(1)

 

Description

The units of the spatial resolution of the layer or coverage available from the service.

 

Sample Values: "KM".

 

Tags

Required

 

2.3.3.6        TemporalExtent [R]

Element Specification

Coverage/TemporalExtent(1)

 

Description

The temporal extent of the layer or coverage available from the service.

 

Sample Values:

 

Coverage/TemporalExtent/TimePoints

Coverage/TemporalExtent/TimePoints/Time: "%H:%M:%S"

Coverage/TemporalExtent/TimePoints/Value "12:20:01"

Coverage/TemporalExtent/TimePoints/Description "Time stamp of the layer"

 

Tags

Required

 

2.3.3.7        TemporalResolution [R]

Element Specification

Coverage/TemporalResolution(1)

 

Description

The temporal resolution of the layer or coverage available from the service.

 

Sample Values: "1".

 

Tags

Required

 

2.3.3.8        TemporalResolutionUnits [R]

Element Specification

Coverage/TemporalResolutionUnits(1) <DAY, WEEK, MONTH, YEAR>

Description

The units of the temporal resolution of the layer or coverage available from the service.

 

Sample Values: "DAY".

 

Tags

Required

 

2.3.3.9        RelativePath [O]

Element Specification

Coverage/RelativePath (0..*)

 

Description

Path relative to the root universal resource locator for the layer.

 

Note: Some layers are specified as a path relative to the root service endpoint. This field serves to capture this information. The client would simply join the two strings contained in the RelatedURL/URLand Coverage/RelativePath fields to get the fully qualified path to the layer.

 

Format: "%year%/%month%/%day%"

 

Sample Values: "2002/01/01"

 

Tags

Optional


 

Appendix A: Deprecated Elements

With the revisions needed for the End-to-End Services, UI/UX driven approach to services, the following elements were removed:

 

Metadata Language

Metadata Standard

Metadata Dates

Lineage

Entry ID

Entry Title

Abstract

Purpose

Service Language

Data Dates

Responsibility

Party

Related URL

Service Citation

Quality

Use Constraints

Access Constraints

Metadata Association

ISO Topic Category

Science Keywords

Service Keywords

Ancillary Keywords

Additional Attributes

Distribution

Platform

Instrument

Project

 

These deprecated elements apply to the UMM-S model only. Elements which have these names have not been removed from the UMM-C model. We have an ongoing reconciliation task to determine how best to represent the SERF entities within the UMM model.

 


 

Appendix B: Tags Glossary

 

Tag Name

Description

Required

This element is required.

Required (with option)

This element is required but can be implemented in several ways. For example, a Responsibility is required, but may be represented by either an organization or a person.

Controlled Vocabulary

This element will have a controlled vocabulary, which will be used to validate the value.

Keyword Search

This element will be indexed by the CMR as part of the free text keyword search.

Parameter Search

This element will be indexed by the CMR and will be exposed via the CMR API as a specific parameter. For example, the CMR will expose a "platform" search parameter, so the "Platform" element will have this tag. This is not to be confused with parameters (or variables) that are part of a collection's science data.

Faceted

This element should be exposed by the CMR catalog via a faceted search response.

Normalize

Existing metadata for these fields are uncontrolled, but should be brought under a controlled vocabulary or simple enumeration via a normalization process. For example, the product level is uncontrolled, so a Level 1 product may be identified as "Level 1", "L1" or simply "1". This is a good candidate for normalization.

Link

This element contains a URL that is used to link to external resources

Validated

This element gets validated to make sure associations exist or keywords match controlled vocabulary

Markdown Support

This element supports markdown-formatted text. Additional information on markdown can be found at
http://en.wikipedia.org/wiki/Markdown

 

 


 

Appendix C: Abbreviations and Acronyms

Name

Description

ACL

Access Control List

API

Application Programming Interface

CMR

Common Metadata Repository

DAAC

Distributed Active Archive Center

DOI

Digital Object Identifier

ECHO

Earth Observing System (EOS) Clearing House

EOS

Earth Observing System

EOSDIS

Earth Observing System Data and Information System

ESDIS

Earth Science Data and Information System

ESO

Earth Science Office

ISO

International Organization for Standardization

KMS

Keyword Management System

MAS

Metadata Architecture Studies

MVP

Minimum Viable Product

NASA

National Aeronautics and Space Administration

NOAA

National Oceanic and Atmospheric Administration

OPeNDAP

Open Source Data Access Protocol

SERF

Service Entry Resource Format

UI

User Interface

UML

Unified Modeling Language

UMM

Unified Metadata Model

UMM-C

Unified Metadata Model - Collections

UMM-Common

Unified Metadata Model - Common Elements

UMM-G

Unified Metadata Model - Granules

UMM-M

Unified Metadata Model - Metadata

UMM-S

Unified Metadata Model - Services

UMM-Var

Unified Metadata Model - Variables

UMM-Vis

Unified Metadata Model - Visualization

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

URS

User Registration System

UX

User Experience

WCS

Open Geospatial Consortium Web Coverage Service

WMS

Open Geospatial Consortium Web Mapping Service

XML

Extensible Markup Language

XPath

XML Path Language