DAP Service Terminus

Overview

Currently DAP servers provide a number of dataset level responses (services). These include DAP services such as the DDS, DAS, and DDX, plus other services that have been added over time such as the RDF and ISO responses. There is currently no way for a user (or software agent) to discover which of these many services might be available for a particular dataset. While THREDDS catalogs do provide a mechanism for determining which services are associated with which datasets, they don't actually provide a mechanism for discovering the details of the various services URLs. A THREDDS catalog might identify a DAP service, but the URL that can be assembled from the THREDDS catalog for that service is limited to just the base dataset URL. Typically dereferencing this URL will provide one of two things - either the underlying data file (for example a netcdf file) or an HTTP 403 error if direct access to the underlying files has been disabled in the server configuration.

Example:

This URL points to a dataset on a DAP server:

http://test.opendap.org:8080/opendap/data/nc/fnoc1.nc

Dereferencing the link will not connect you to a DAP service or DAP response. It will only return the underlying netcdf file. The only way to know that DAP services exist for this is by reading the URL path and recognizing that it is likely an instance of a DAP server based on the position of the 'opendap' string in the URL.

There is no guarantee that dereferencing this URL will even yield the underlying file, as that behavior is a configuration option for the server. If that access is not allowed in the configuration, then dereferencing the URL will simply return an HTTP 403 (forbidden) error.

Proposal

I propose that base DAP URLs should return an XML document describing the DAP services available for the dataset.

At minimum this document should provide:

• The name of the service (DDX, DDS, etc.)
• The service suffix (.ddx, .dds, etc.)
• A brief description of the service
• A link to a complete description of the service response and it's semantics
• A reference to an XSLT that a browser would use to render the description into HTML for a presentation view.

Additionally this dataset services description document might contain:

• Descriptions and syntax of server side functions available for the dataset
• Please add things here that I have missed!

As the DAP servers evolve to support user authentication and sessions the content of the dataset services description document should become dynamic. By this I mean that some services and server functions might be available only to certain users. If an authenticated user asks for a particular dataset services description document they would see all the the services available to them, which might differ significantly from those available to a different user. As powerful server side functions such as re-gridding and re-projection become available we anticipate that data providers may not wish to allow just anyone to utilize them because of the potential burden they may place on the data center's computing resources.

Current Responses

Hyrax currently supports the following responses/services for datasets:

• Data (dataset_id + .dods)
• DDX (dataset_id +.ddx)
• DAS (dataset_id +.das)
• Information in HTML (dataset_id +.info)
• HTML Data Access Form (dataset_id +.html)
• RDF representation of the DDX (dataset_id +.rdf)
• NetCDF file out (dataset_id +.nc)
• ISO 19115 in XML (dataset_id +.iso)
• ISO Conformance rubric (dataset_id +.rubric)
• Server version information in XML (dataset_id +.ver)

Proposed Responses

• Raw file access (dataset_id +.file)
• Service (dataset_id)

Prototype Response Document

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="http://xml.opendap.org/xsl/DatasetServices.xsl"?>
<DatasetServices xml:base="http://test.opendap.org:8080/opendap/data/nc/fnoc1.nc" >
    <Service name="DAP2 Data Response" suffix=".dods">
        <Description xlink:href="http://www.opendap.org/dap/services/dap2.html">Blah blah blah</Description>
    </Service>
    <Service name="DDX" suffix=".ddx">
        <Description xlink:href="http://www.opendap.org/dap/services/ddx.html">Blah blah blah</Description>
    </Service>
    <Service name="DDS" suffix=".dds">
        <Description xlink:href="http://www.opendap.org/dap/services/dds.html">Blah blah blah</Description>
    </Service>
    <Service name="DAS" suffix=".das">
        <Description xlink:href="http://www.opendap.org/dap/services/das.html">Blah blah blah</Description>
    </Service>
    <Service name="INFO" suffix=".info">
        <Description xlink:href="http://www.opendap.org/dap/services/info.html">Blah blah blah</Description>
    </Service>
    <Service name="HTML" suffix=".html">
        <Description xlink:href="http://www.opendap.org/dap/services/html.html">Blah blah blah</Description>
    </Service>
    <Service name="RDF" suffix=".rdf">
        <Description xlink:href="http://www.opendap.org/dap/services/rdf.html">Blah blah blah</Description>
    </Service>
    <Service name="NetCDF File Out" suffix=".nc">
        <Description xlink:href="http://www.opendap.org/dap/services/nc.html">Blah blah blah</Description>
    </Service>
    <Service name="ISO" suffix=".iso">
        <Description xlink:href="http://www.opendap.org/dap/services/rdf.html">Blah blah blah</Description>
    </Service>
    <Service name="ISO Evaluative Rubric" suffix=".rubric">
        <Description xlink:href="http://www.opendap.org/dap/services/rdf.html">Blah blah blah</Description>
    </Service>
    <Service name="File Access" suffix=".file">
        <Description xlink:href="http://www.opendap.org/dap/services/rdf.html">Blah blah blah</Description>
    </Service>
    <Service name="Server Version Response" suffix=".ver">
        <Description xlink:href="http://www.opendap.org/dap/services/version.html">Blah blah blah</Description>
    </Service>
</DatasetServices>

Issues

• This a change in server behavior that will change the response content of file access URLs. These URLs are not part of the regular DAP URL pattern and their current behavior is a function of server configuration.
• How might we describe the way to elicit DAP3.x and DAP4 versions of the responses in this description given that we currently rely on the XDAP-Accept HTTP header to inform the server of the version being requested?
• I know we discussed additional issues, but I can't recall them. Please add them if you do!