CAOM and ObsTAP Query Management

The STScI CAOM and ObsTAP service provides an interface into observational data at Space Telescope, in the Common Archive Observation model, including summary information in the Observation Core data model. This page contains simple web forms that can manage synchronous and asynchronous ADQL queries to that TAP service, which will return the results of a basic table query in a VOTable. The main URL for programmatic access to the TAP service is: http://vao.stsci.edu/CAOMTAP/tapservice.aspx.

More information can be found via the service metadata description at the STScI Registry.

This page contains simple web forms that can manage synchronous and asynchronous ADQL queries to that TAP service, which will return the results of a basic table query in a VOTable.

VOSI Queries - Availability, Capabilities, and Schema

VOSI gives us the ability to query metadata about the service itself. Any of the following buttons will issue a VOSI query about the service which can be used to determine whether the underlying service and its database are available, and to plan your query itself.


DALI Examples

DALI examples give us the ability to see sample queries for the service. This is especially useful for services with a non-standard data model that allow geometric queries.


Synchronous Query

Synchronous queries are run immediately on the server. There is not yet any hard maximum limit on the amount of data returned, and there is a great deal of data to be pontentially returned. It is suggested that you use "top n" in the select statement of your ADQL query itself. When submitting your query, you will be redirected to your VOTable-encoded result set or error page.

Enter Synchronous ADQL Query:

Asynchronous Query (using the Universal Worker Service)

Asynchronous queries are managed using the UWS protocol, which allows queries with much larger result sets to be efficiently managed by the service. In short, they are set up by the client, potentially negotiated with regards to the amount of time they are allowed to run or be stored on the server, then run by the client. The client then polls the server to discover when the query has run and where potential error or completed result sets are stored.

This is all managed via a 'job ID'. To run a UWS query, first enter your ADQL - based query. Given the RESTful nature of UWS as implemented, you will be forwarded to a status page with a job number. Copy down this job number - you will use it for the rest of the lifetime of your query. You can also query the UWS engine for a list of currently existent jobs.

Enter Asynchronous ADQL Query:

Asynchronous Query Management

Once you have a job number, you can come back to this page with the browser 'back' button' after any step of the UWS query process. Here, you can enter your job number in the form below to renegotiate the deletion time of your results (if you expect it to take a long time to run, or will be personally unable to check up on your results before they would be automatically deleted), to trigger the job to be run, to poll your job for another status page giving the URL of its result set or error documentation, and to delete your job when it is finished. Job deletion will bring you back to the job summary page.

Enter job number to run:

Enter job number to poll:

Enter job number to delay destruction:
Enter New Destruction DateTime (format GMT, yyyy-mm-ddThh:mm:ss):

Enter job number to view results or errors (if they exist):

Enter job number to delete:

References

The following links may help to explain the basic query language and systems at work.

  • TAP - Table Access Protocol. This is the underlying standard behind ObsTAP, or Observation Data Model / TAP, services. All queries built using the forms on this page are formatted for TAP. The standard provides a basic query mechanism, a mechanism for schema-related configuration queries, and VOSI support.
  • ObsTAP - Observation Data Model / Tap services. This is a type of service using the TAP protocol to expose a database table using the Observation Data Model (in progress). This defines the columns available, whether they are returned by default, and whether they are mandatory.
  • VOSI - Virtual Observatory Standard Interface. This defines a protocol for discovering basic uptime, capability, descriptive, and schema-related information about a service. We have implemented the REST version as explained in the VOSI 1.0 documentation.
  • ADQL - Astronomical Data Query Language. This can be used for SQL-like string queries to the service
  • UWS - Universal Worker Service for asynchronous web service communication. We have implemented this using REST protocols as explained in an IVOA note.