TWiki> IVOA Web>IvoaTheorySimDAP (revision 1)EditAttach

Simulation Data Access Protocol (SimDAP) Draft

This page is for outlining the initial draft of the SimDAP Note. Once we've reached agreement on the outline, we will move content to an HTML version in the volute repository.

Please hold of on editing this, I'm still transferring some of my notes. I should be done later today.

-- RickWagner - 11 Nov 2008

1. Introduction

2. SimDAP Data Model

3. Interface Overview

3.1 Architecture

A SimDAP service provides access to initial or derived files from simulations.

3.2 Service Operations

A SimDAP service implements multiple service operations, each of which performs some well defined function when invoked by a client application. The service operations described here use HTTP GET and POST as the low level communications protocol. The functionality of each operation is defined independently of the low level communications protocol, and semantically equivalent operations could be implemented in the future via other protocols.

SimDAP defines the following standard service operations:

GetCapabilities
Return a standardized XML description of the capabilities of the service instance, describing what the service is capable of doing (VOSI compliant, registry cacheable and searchable).
GetAvailability
Return a standardized XML description of the runtime status of the service, describing the state and availability of the service (VOSI compliant).
ListExperiments
Return a list of the experiments served by this SimDAP instance.
ListSnapshots
For a given experiment, list the available snapshots.
QueryData
The QueryData operation requires only the basic EXPERIMENT_ID and SNAP_ID parameters to work. The FIELDS parameter may be used if the corresponding field selection service is available (otherwise it is discarded). No FIELDS specification or a blank FIELDS parameter, is interpeted as: download all available fields. If FIELDS requires unavailable quantities, the corresponding request is discarded.
Preview
The preview can be implemented in different ways, depending on the specific data we are dealing with. In all the cases, if the service is supported, a getPreview method MUST be implemented. The input of this method is the basic couple EXPERIMENT_ID and SNAP_ID. The FIELDS parameter may be used to specify which fields to preview (if supported, otherwise it is discarded). No FIELDS specification or a blank FIELDS parameter, is interpeted as: preview all available fields. If FIELDS requires unavailable quantities, the corresponding request is discarded. If the cutout service is available, the preview service MUST provide instruments to select the fields of interest and the cutout region. This will result in setting the parameters presented in Section 5.3.
Cutout
The goal of the cutout service is to select and extract a sub-volume of data from a given snapshot. Such operation refers to a single snapshot. Multiple sources cutouts, like for various time steps of the same simulation, are not supported by the protocol. Their implementation is up to the client, as, for example, sequences of requests with same subbox and fields but different datasets.
Custom
A service define custom operation.

3.3 Service Profile

The basic form of a SimDAP service is specified in detail in section ??. In the current section we merely summarize the elements of the basic service interface.

3.3.1 Request Format

A service may implement multiple service operations, such as download or preview; these define the service interface. Interfaces may change with time and hence are versioned. It is possible for a given service instance to simultaneously expose multiple interfaces or versions of interfaces.

The SimDAP interface described in this document is based upon a distributed computing platform (DCP) comprising Internet hosts that support the Hypertext Transfer Protocol (HTTP). Thus, the online representation of each operation supported by a service is composed as a HTTP Uniform Resource Locator (URL).

A request URL is formed by concatenating a baseURL with zero or more operation-defined request parameters. The baseURL defines the network address to which request messages are to be sent for a particular operation of a particular service instance on a particular server. Service operations generally share the same baseURL but this is not required.

3.4 Request Examples

4. SimDAP Service Operations

4.1 ListExperiments

4.1.1 Input Parameters

4.1.2 Query Response

4.2 ListSnapshots

4.2.1 Input Parameters

4.2.1.1 EXPERIMENT

4.2.2 Query Response


Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2008-11-11 - RickWagner
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback