Observing Applications via WWW

H.P. Stilmack, Joint Astronomy Centre, Hilo HI

R.J. Ivison, Royal Observatories, Blackford Hill, Edinburgh EH9 3HJ

J.K. Davies, Joint Astronomy Centre, Hilo HI

S. K. Ramsay-Howat, Royal Observatories, Blackford Hill, Edinburgh EH9 3HJ

Abstract

The Joint Astronomy Centre and the Royal Observatory, Edinburgh operate and manage the United Kingdom Infrared Telescope (UKIRT) and the James Clerk Maxwell Submillimetre Telescope (JCMT) on behalf of astronomers worldwide. Both telescopes have a Service Observing facility for observational programmes which can be performed by local staff on behalf of other investigators. Potential investigators have traditionally applied for time on these service programmes via electronic or postal mail to assessors and referees based in the partner countries. This paper presents a hypertext-based application method, incorporating some basic parameter-checking (e.g., instrument configuration, object visibility) and rapid feedback, on behalf of both telescopes.

Introduction

The service observing programme for UKIRT, where staff astronomers obtain small quantities of data for the user community, has been operational for over 10 years and is widely regarded as a successful venture. Statistically-speaking, data collected by staff astronomers during only 18 nights per year generates around 20% of the annual refereed publications from the telescope. One should bear in mind, of course, that some of these service-generated papers contain a high proportion of data obtained by traditional observers on either UKIRT or other telescopes, but the popularity and efficiency of the system cannot be questioned; it has been shown to work extremely well as a complement to the traditional system wherein an astronomer travels to the telescope to obtain data (Davies 1993).

A significant increase in the observing efficiency of the telescope is derived from the staff astronomer's familiarity with current instrumentation, and from the ability to tailor the observing schedule, for example, to make allowance for local weather conditions. The service observing mode also provides an opportunity to supplement data obtained in traditional observing time, to react quickly to new discoveries, to test the feasibility of large research programmes, to gather small amounts of data simultaneously with other facilities and, in some cases, to monitor sources on a frequent basis over a period of years, all of which improve the scientific capabilites of the telescope. From a scientific perspective, the service observing mode provides an opportunity to supplement data obtained in traditional observing time, to react quickly to new discoveries, to test the feasibility of large research programmes, to gather small amounts of data simultaneously with other facilities and, in some cases, to monitor sources on a monthly basis over a period of years.

In the past, service proposals for UKIRT have been submitted via electronic mail to staff at the Royal Observatory, Edinburgh; JCMT service programmes exist for the partner countries (UK, The Netherlands and Canada), and proposals are handled differently in each. For the UKIRT programme, which we will concern ourselves with here, the proposal form has until now been a simple text document containing the particulars of the principal investigators and collaborators, some justification for the proposed observations, the coordinates of the object, and a section in which the technical feasibility of the project is outlined and the observational techniques spelled out to the observer. A short-coming of this system that it does not prevent applicants from editing the form and deleting or ignoring certain key questions; for example, omitting to specify the visible brightness of the star (needed for target acquisition) is common. It is also hard to assess the technical feasibility of the observations if the applicant does not provide the infrared flux!

We have decided recently to develop a new facility which will employ the World Wide Web. Our intention has been to build on the success of the old system, rather than to begin from scratch.

Application Design

One of the principle advantages of the WWW-based system will be the generation of a new standard form, with fields which will be common to both JCMT and UKIRT (and many other telescopes), rather like the FITS standard for storage of data. The form can be fed into error-checking software, or into a queue-based observing facility. Our ultimate goal is to provide a sophisticated system, where the sophistication is transparent to the user and to the administrator.

After entering simple information regarding the applicant's address, etc., the user will be led through a logical series of questions and answers, with help and simple menus being provided throughout; each answer will undergo some simple error-checking, and further forms and questions will be generated based on answers to key questions. The process will culminate with the generation of a simple text document, as before, which can be reviewed and sent by electronic mail to the administrator of the service programme.

Some of the most important differences between the old system and the new, WWW-based system will be that

Of course, there will still be ample opportunity to use the text fields for any very specific observational details which cannot be accomodated by the standard form.

Implementation

The application form will be generated by a series of CGI scripts which will generate the fill-out forms seen by the user. The content of these forms will be determined by various factors, such as

The data entered into the forms will be saved to a temporary file each time a form is submitted. The file is identified by a unique filename generated when the first script in the series is run for the first time. If the saved responses file exists, each time a script is run it will read the contents of the file, merge them with any new input (with the new input having precedence), and rewrite the file. This mechanism allows a review method whereby any prior response can be altered up until the final submission of the observing application.

An application for service observing can be logically divided into two parts:

  1. Applicant identification, programme name, and scientific justification
  2. Observation specifications - objects, instruments, and settings
In this implementation, we have decided to treat each object/instrument/settings combination as a distinct observation. Multiple observations may be specified within a single Observing Application, but they should all relate to the same programme and justification. This being the case, each observation can be further broken into an object and instrument specification part, and an observational details part. Since the applicant identification data is constant for a particular programme, and since the observational details for a given observation are necessarily dependent on the instrument selected, the overall system divides logically into three main scripts, with an additional script to provide the review capability and a final script to submit the completed application data.

The data entered into each form is, as stated above, saved into a temporary file when the form is submitted. In order to easily accomodate data of nearly any type, including multi-line text and (possibly) various symbols, the data is, after being extracted from the CGI input stream, re-encoded in a modified URL encoding and written in the format "NAME=value", where NAME is the field name from the previous form and "value" is the URL-encoded value of that field, if any. Use is made of "hidden" fields to keep track of such information as

Many of these "hidden" values are not saved across script invocations, the main exception being the application identification number.

Value Checking

In the initial prototype application form, value and error checking are not yet implemented. We anticipate being able to check, within the review script, that This checking will probably require another script or scripts, interposed between the existing scripts, to perform error and value checking and inform the user if his/her entered values are inappropriate. The user would then be returned to the appropriate form and given an opportunity to edit her/his responses.

Postprocessing

The final step in this process is the submission of the collected data to a script which will perform the following functions:

This postprocessing is currently the subject of discussions at the Joint Astronomy Centre and the Royal Observatory. We hope to develop a generalised Telescope Application Format which could in principle be used for Service Observing programmes at any telescope anywhere. This (admittedly ambitious) project will obviously require a great deal more work.

Conclusions

The UKIRT and JCMT Service Observing programmes have been very successful. With this success has come increased use, which has in turn led to the need for some automation of the process. The prototype Service Observing form developed at the Joint Astronomy Centre is the first step toward providing a user-friendly, intelligent interface to the application process. By the time of this Conference, we expect to have further developed this prototype and be engaged in intensive pre-release testing of the system.