(r1) IvoaTheorySimDAP < IVOA

IVOA Web>IvoaTheorySimDAP (revision 1) (raw view)~~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.

-- IVOA.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





<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r1 - 2008-11-11 - RickWagner
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema