Element Description
A service is a resource which can be used to transform data before downloading it (e.g. subset, reformat, re-project, etc.). Examples of services which are commonly used in the Earthdata community include OPeNDAP and Web Map Services (WMS). The Related URLs element, when accompanied by the 'use service api' sub-elements, can be used to link directly to these types of services.
If a service is available for a dataset, it is strongly encouraged that a link to the service be provided in the collection level metadata. It is also encouraged that a service metadata record be created for the service. Service metadata records provide additional capabilities and opportunities for users to search and access data in the Earthdata Search Client:
UMM-Service (UMM-S) Records
If a service is available for a dataset, it is strongly encouraged that a UMM-Service (UMM-S) metadata record be created for that service. This service record can then be associated with the collection level metadata record.
UMM-S version 1.2 was released in July 2018, and UMM-S records can now be managed (i.e. created/populated/changed) via the Metadata Management Tool (MMT). Please see this link to the MMT User's Guide for details on how to manage UMM-S records in the MMT.
There is also information available on how to ingest and search UMM-S records via the CMR API.
In the case that the creation of a UMM-S record is not feasible, it is still recommended that a link to the service be provided in the collection level metadata. Note that simply providing a link to a service in the collection level metadata does not provide the same capabilities offered by implementing a service metadata record.
The best practices that follow are for providing a link to a service in collection level metadata.
Best Practices
The Related URLs element, accompanied by 'Use Service API' sub-elements, is used to link to resources which can be used to subset and/or transform data and obtain it. This is different from a GET DATA URL, which relates to direct data access. For details concerning GET DATA URLs, please see the Related URLs (GET DATA) wiki page.
For general Related URL guidance (not specific to service links), please refer to the Related URLs wiki page.
For Non-NASA collections, the USE SERVICE API may be used to expose OpenSearch Description Document (OSDD) links to enable a collection's granules to be searched and discovered through the International Directory Network (IDN) search portal. For more information about how CMR utilizes OpenSearch, please refer to the CMR OpenSearch Documentation.
The USE SERVICE API Related URL metadata element allows for the linkage of a metadata record to a service. As mentioned on the Related URLs wiki page, there are several sub-elements which are used to identify the purpose of the URL. For USE SERVICE API links specifically, best practices for these elements include:
URL Content Type: The URL Content Type is a keyword which, at a high level, describes the content of a link. This is a controlled vocabulary field maintained as an enumeration list within the UMM-Common schema. For USE SERVICE API URLs, the URL Content Type should always be "DistributionURL."
URL Type: The URL Type is a keyword which specifies the content of a link. URL Type keywords are maintained in the Keyword Management System (KMS). For USE SERVICE API URLs, the URL Type should always be "USE SERVICE API."
URL Subtype: The URL Subtype is a keyword which further specifies the content of a link. Together, the URL Type and Subtype keywords create a keyword hierarchy which is used to identify the URL. Providing a Subtype for USE SERVICE API URLs is optional, but should be used when applicable. Valid Subtype keywords can be found here under the "Subtype" column. Specifically, any subtypes listed after the USE SERVICE API type keyword can be used to label service links. Definitions for these Subtypes can be found in the KMS.
Description: While not required, it is highly recommended that a description be provided for each URL provided in the metadata. The description should be kept brief and explain to the user what type of service they are being linked to. The descriptions should be unique to the link. While descriptions can be repeated for the same type of URL across different metadata records, it is generally advised that the same description not be repeated within the same metadata record. I.e. the description should be used to further differentiate two USE SERVICE API URLs with the same URL Type and Subtype.
There are several sub-elements specifically designated for USE SERVICE API URLs. The following provides definitions and best practices for each of the sub-elements:
RelatedUrls/GetService/Format: The format of the data provided via the associated URL. Providing the format is required??. Format is a controlled vocabulary field and should be chosen from the <insert GCMD data format keyword list>. If data is provided in a compressed file format, recommend listing the format of the data once it is uncompressed.
RelatedUrls/GetService/MimeType: MIME stands for "Multipurpose Internet Mail Extensions". Mime types are used to identify the nature and format of files provided on the Internet, and are typically used by internet browsers in order to determine how to properly process or display a document or file. Providing the Mime Type element in the metadata helps ensure that the URL contents will be properly displayed on the Web. Providing a Mime Types is required for USE SERVICE API URLs. Mime Type is a controlled vocabulary field and should be chosen from the GCMD Mime Type keyword list.
RelatedUrls/GetService/Protocol: The protocol is used to identify mechanisms/conventions for communication between different network devices. The Protocol element is a controlled vocabulary field maintained as an enumeration list within the UMM-Common schema.
RelatedUrls/GetService/FullName: Do we still need this field?
RelatedUrls/GetService/DataID: Do we still need this field?
RelatedUrls/GetService/DataType: Do we still need this field?
RelatedUrls/GetService/URI: Do we still need this field?
Examples:
URL: https://acdisc.gesdisc.eosdis.nasa.gov/opendap/Aqua_AIRS_Level3/AIRH3QPM.006/contents.html
URL Content Type: DistributionURL
URL Type: USE SERVICE API
URL Subtype: OPENDAP DATA
Description: Use the link to access data via the OPeNDAP protocol.
Format: HDF-EOS
Mime Type: text/html
Protocol: HTTPS
Full Name: Do we still need this field?
Data ID: Do we still need this field?
Data Type: Do we still need this field?
URI: Do we still need this field?
URL: https://disc1.gsfc.nasa.gov/daac-bin/wms_omi?service=WMS&version=1.1.1&request=GetCapabilities
URL Content Type: DistributionURL
URL Type: USE SERVICE API
URL Subtype: WEB MAP SERVICE (WMS)
Description: WEB MAP SERVICE (WMS) GetCapabilities request.
Mime Type: text/xml
Protocol: HTTPS
Full Name: Do we still need this field?
Data ID: Do we still need this field?
Data Type: Do we still need this field?
URI: Do we still need this field?
URL Content Type: DistributionURL
URL Type: USE SERVICE API
URL Subtype: OpenSearch
Description: tag_key: opensearch.granule.osdd
Mime Type: application/opensearchdescription+xml
Element Specification
An unlimited amount of Related URLs may be listed (Cardinality: 0..*)
Model | Element | Type | Usable Valid Values | Constraints | Required? | Cardinality | Notes |
---|---|---|---|---|---|---|---|
UMM-Common | RelatedUrls/URL | String | n/a | 1 - 1024 characters | Yes | 1 | The USE SERVICE API URL should point the user to a location where data can be subset or transformed before downloading. |
UMM-Common | RelatedUrls/Description | String | n/a | 1 - 4000 characters | No | 0..1 | It is strongly recommended that a description be provided for each URL. |
UMM-Common | RelatedUrls/URLContentType | Enumeration | DistributionURL | n/a | Yes | 1 | "DistributionURL" is the only valid option for service links. |
UMM-Common | RelatedUrls/Type | String | USE SERVICE API | KMS controlled | Yes | 1 | "USE SERVICE API" should be provided as the Type. |
UMM-Common | RelatedUrls/Subtype | String | GCMD URL Content Type 'Subtype' Keywords | KMS controlled | No | 0..1 | The Type and Subtype are part of a keyword hierarchy specified in the KMS. Any Subtype listed get after USE SERVICE API in the keyword list is a valid option. If none of the available Subtypes are appropriate for the URL, then it is okay to leave the Subtype field blank. |
UMM-Common | RelatedUrls/GetService/Format | String | KMS controlled | No | 0..1 | ||
UMM-Common | RelatedUrls/GetService/MimeType | String | GCMD Mime Type Keywords | KMS controlled | Yes, if applicable | 1 | |
UMM-Common | RelatedUrls/GetService/Protocol | Enumeration | HTTP HTTPS FTP FTPS Not Provided | n/a | Yes, if applicable | 1 | It is recommended that use of FTP and FTPS be phased out if possible. |
UMM-Common | RelatedUrls/GetService/FullName | String | n/a | 1 - 80 characters | Yes, if applicable | 1 | Are we keeping the full name field? |
UMM-Common | RelatedUrls/GetService/DataID | String | n/a | 1 - 80 characters | Yes, if applicable | 1 | Are we keeping the data ID field? "The data identifier of the data provided by the service." Typically, this is a file name. ← Providing a file name would only make sense for direct download |
UMM-Common | RelatedUrls/GetService/DataType | String | n/a | 1 - 80 characters | Yes, if applicable | 1 | |
UMM-Common | RelatedUrls/GetService/URI | Array Composed of at least 1 String | n/a | 1 - 1024 characters (per string) | No | 0..* |
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.
Dialect Mappings
UMM Migration
None
History
UMM Versioning
Version | Date | What Changed |
---|---|---|
1.15.5 | 12/3/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.15.4 to 1.15.5 |
1.15.4 | 9/18/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.15.3 to 1.15.4 |
1.15.3 | 7/1/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.15.2 to 1.15.3 |
1.15.2 | 5/20/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.15.1 to 1.15.2 |
1.15.1 | 3/25/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.15.0 to 1.15.1 |
1.15.0 | 2/26/2020 | No changes were made for Related URLs-Use Service during the transition from version 1.14.0 to 1.15.0 |
1.14.0 | 10/21/2019 | No changes were made for Related URLs-Use Service during the transition from version 1.13.0 to 1.14.0 |
1.13.0 | 04/11/2019 | No changes were made for Related URLs-Use Service during the transition from version 1.12.0 to 1.13.0. |
1.12.0 | 01/22/2019 | No changes were made for Related URLs-Use Service during the transition from version 1.11.0 to 1.12.0. |
1.11.0 | 11/28/2018 | No changes were made for Related URLs-Use Service during the transition from version 1.10.0 to 1.11.0. |
1.10.0 | 05/02/2018 | During the transition from version 1.9.0 to 1.0.0, the sub element 'Format' was added, which provides the format of the data accessed via the associated URL. |
1.9.0 |
ARC Documentation
Version | Date | What Changed | Author |
---|---|---|---|
1.0 | 07/26/2018 | Recommendations/priority matrix transferred from internal ARC documentation to wiki space | Jeanne' le Roux |