DCP-4

From Earth Science Information Partners (ESIP)

<< Back to the Discovery Change Proposals page


DCP-4: OPeNDAP Links in the Atom <link/> element

  • Progress (fill in the dates as the process moves forward)
  1. Submitted on: 14 Feb 2012
  2. Review period: 14 Feb 2012 to 14 March 2012
  3. Revision: N/A
  4. Vote: TBD
  5. Final review: TBD
  6. Ratified: TBD
  7. Rejected: TBD

Description

To include URLs that reference OPeNDAP servers and/pr response objects in Atom-based casts, use the XLink 1.1 protocol. The technique presented relies on only standard behavior for XLink 1.1 conformant software. It can be trivially extended to other web-based data access protocols (e.g., WCS).

Problem Addressed

We have a number of datacast feeds that are, or have the capability to, include links that can be used to access those cast datasets using OPeNDAP servers. However, few feed readers will understand how to process the responses from those servers. Furthermore, each 'OPeNDAP URL' really specifies a collection of potential responses, each accessed using a specific suffix appended to the pathname component of a/the URI/URL.

Proposed Solution

Include multiple <link href=.../> elements for each dataset to be cast. Different <link/> elements can be categorized as follows:

  1. A <link/> with only the Atom 1.1 href, title and rel attributes will be interpreted to reference the 'raw' dataset.
  2. A <link/> with the attributes xlink:type="simple" with the additional attributes xlink:role="<<dap schema URI>>" and title="<<some human readable title that mentions OPeNDAP>>" will be interpreted to reference a DAP service endpoint. The URL that can be dereferenced to access the endpoint will be the value of the href attribute and the rel attribute will be "enclosure"

<! -- # A <link/> with the attributes xlink:type="simple" with the additional attributes xlink:role="<<dap schema URI>>" and xlink:arcrole="<<DAP suffix>>" will be interpreted to reference a DAP response object using an endpoint. The arcrole will denote exactly which response will be returned when the URL that is the value ofthe href attribute is dereferenced. The rel attribute will be "enclosure". The title will contain some human readable text that mentions both OPeNDAP and the specific response. -->

  1. Stamp and Repeat for WCS, other protocols.

Examples

<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/>

<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" type="text/plain" xlink:role="http://xml.opendap.org/DAP2#" xlink:type="simple"/>

<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" type="text/xml" xlink:role="http://xml.opendap.org/DAP2#ddx" xlink:type="simple"/>

Notes:

  1. The xlink:type="simple" is not needed; if xlink:type is not present it defaults to simple

Rationale for the Solution

Xlink is the best way to include arbitrary metadata about a link in a link. Using it takes advantage of existing XML standards and so it is within the realm of reason to assume feed readers will not behave in a way that is toxic to users.

Discussions

The Atom 1.1 title attribute is used rather than xlink:title because feed readers are more likely to display it (caution: this is a WAG on my part - jimg).

The fact that xlink includes a namespace-qualified href attribute and the Atom 1.1 specification requires that href be present in <link/> elements is cumbersome. Note that xlink:href is not required for xlink:type="simple".

NB: It is not an error for a simple-type element to have no locator (href) attribute value. If a value is not provided, the link is simply untraversable. Such a link may still be useful, for example, to associate properties with the resource by means of XLink attributes. See: http://www.w3.org/TR/xlink11/ section 5.2.

Notes (Pedro)

xlink:role in atom:link

from the information in

http://www.w3.org/TR/xlink11/#att-method

it seems that is "legal" to add any of the xlink attribute (e.g. xlink:role) to an element JamesGallagher 16:32, 14 February 2012 (MST): Correct, but exactly which of the attributes are legal is a function of the value of xlink:type; it's a minor point because when xlink:type is simple all of the attributes we've been talking about using for both DCP-4 and DCP-5 are allowed. The table in section 4.1 shows the supported collections of attributes depending on the value of xlink:type.

MIME-TYPES

In your examples we are missing the type attribute that gives us the mime-type of the resource

JamesGallagher 16:24, 14 February 2012 (MST): I'll update the examples. NB: The MIME types for the OPeNDAP responses will be different from application/x-hdf5

So the examples would be:

<link rel="enclosure" href="http://data.gsfc.nasa.gov/data/file.hdf" title="HDF5 data showing controversial things" type="application/x-hdf5"/>

<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf" title="OPeNDAP acces to controversial data" xlink:role="http://xml.opendap.org/DAP2#" type="application/x-hdf5"/>

<link rel="enclosure" href="http://data.gsfc.nasa.gov/opendap/hyrax/data/file.hdf.ddx" title="OPeNDAP XML metadata response, for those weary of controversy" xlink:role="http://xml.opendap.org/DAP2#ddx" type="application/x-hdf5"/>

Consensus

Voting results.