Discovery Change Proposal-2

From Earth Science Information Partners (ESIP)

<< Back to the Discovery Change Proposals page

DCP-2: Canonicalizing Granule-level OPeNDAP Links

  • Progress (fill in the dates as the process moves forward)
  1. Submitted on: 15 June 2011
  2. Review period: 15 June 2011 - 7 July 2011
  3. Withdrawn due to lack of consensus: or when rejected.
  • Authors: Christopher Lynnes, NASA/GSFC; Matt Cechini, Raytheon; James Gallagher,


The Discovery Response Format (v1.1) includes the following values for the "rel" attribute on the <link> element.

Link type Description Default data link. Data Casting Granules. OpenSearch Granules response. Appropriate for smaller browse images. See following for alternate browse links. Default documentation. See following for alternate documentation links. Data, collection, and service metadata. Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead. Service Casting. Micro-articles of natural phenomenon. Feed of various feeds. Enables hierarchy of feeds.

In addition to the "rel" attribute specifying what a URL addresses, there is also a "type" attribute. The values for the "type" attribute are recommended to be mime-type values, but this is not enforced.

In light of this, it may be possible that data providers will have multiple URLs that point to downloadable data. In each of these cases, the "rel" attribute value would be "". A specific use case would be a granule that has a direct download link to the HDF file and also a download link to an OPeNDAP service. With only a single "rel" attribute value, clients and/or users are unable to distinguish between download link types.

The scope of this DCP is constrained to resolving this issue for OPeNDAP URLs. Other data download link types should be included in separate DCPs.

Problem Addressed

This allows clients to unambiguously distinguish OPeNDAP URLs from simple download URLs, without relying on parsing the path of the URL pattern for telltale strings like "dodsC". (These paths can vary with implementation and with deployment site and are thus unreliable). The restriction of the Root OPeNDAP URL allows the client to distinguish between, say, an HDF file that is downloaded in a netCDF response, vs. a NetCDF file that is served by the OPeNDAP. The former case, the URL in the Atom response will end in HDF (with possible suffixes for compression), e.g.,, while the latter case will end in .nc.

Proposed Solution

  1. The rel attribute for link elements in the Atom or RSS response should unambiguously identify OPeNDAP end points for the individual granule at a granule level. The rel attribute value to indicate this shall be to indicate compliance with version 3.3 of the DAP specification. Servers compatible with other versions of DAP should substitute the appropriate version in the URL. (Note, these URIs are not necessarily dereferencible.)
  2. OPeNDAP URLs shall be construed to point to the "root" URL, i.e., without any specific response suffix (.html, .asc, .nc, .dds, .das, .ddx, etc.).
  3. OPeNDAP URL links are optional in either an Atom or RSS response, depending on whether the provider supports them and wants to expose them.

Note that granule-level OPeNDAP URLs are essentially data, offered through a particular service. This proposal is not meant to apply to advertisement of the overall service itself, which in OPeNDAP would typically be along the lines of

Rationale for the Solution

This solution follows the pattern already used in ESIP Federated search to use a rel attribute with an unambiguous namespace URI to identify a specific kind of link.





Through August 31.