VSO Data Model
The VSO Data Model provides a set of template descriptions for information required to describe, access, and search solar data sets in a variety of archives. It is an abstract model, not a suggested set of keywords to be used in data nor in databases. Because of the ubiquity of the FITS standard and the wide use of certain conventions, we provide illustrative values of FITS keywords for certain data elements; but neither the adoption of any set of particular keywords nor the FITS data model at all are required for a data description to conform to the model. The VSO Element Names, are used at a level of abstraction once removed from the search parameters of the data providers. They should be completely internal to the VSO procedures for decoding information from user interfaces, not sent in in queries to data providers. We have deliberately avoided the use of FITS-compatible keyword names to emphasize this point.
VSO Search Parameters
VSO search parameters are those data descriptors for which queries are supported by the VSO in behalf of client applications or requests. These are the parameters that can best discriminate among a large collection of heterogeneous data. They must therefore be supported by the data providers as search parameters applicable to a large subset of the data archives. They must map to parameters in the server data dictionaries in a well-defined and meaningful way. They must also be selected so that the number of data sets meeting a particular selection criterion is small compared to the total number: for the VSO an astronomical type search parameter of Object (Sun) is not particularly useful as a discriminator.
The VSO search parameters are divided into a few groups, each described under one of the major subsections. These categories are understood to be orthogonal, in the sense that they can be used to construct non-trivial AND queries. Of course they are not strictly orthogonal: selection of a particular data source (instrument) may automatically restrict the available observing times for example, and vice-versa. Nonetheless it is useful to treat the major categories as if they were orthogonal and treat any dependencies as implicit selections or limits.
No particular set of search parameters is required. In the absence of a relevant element or group of elements in its data description, a dataset is assumed to match all queries. For example, if no wavelength information is supplied, then the server will return all records for any selected (or deselected) wavelength interval. If a parameter is not searchable but has a default value, then that value can be supplied directly in the data description. For example, an archive of data all taken at the same wavelength is unlikely to have wavelength as a searchable key in its database, but could (and should) supply that wavelength as a fixed value in its data description to avoid inappropriate satisfaction of client queries.
The current parameter list is not intended to be exhaustive, and it may be useful to add additional search elements and categories in future. The categories chosen are those for which the VSO either has attempted to implement a search service or contemplates doing so. So far, only a few of the parameters can be searched in the VSO, and these are marked with asterisks in the following list. The elements are described in detail by group under the following sections.
- Observing Time
- Target Location
- Observer Location
- Spectral Range
- Wave_Bands (may be deleted in future versions)
- Wave_Step (may be deleted in future versions)
- Data Organization
- Wave Mode Sampling
- Degree_Step (may be deleted in future versions)
- Data Source
Suggestions for Additional Search Parameters
The following search parameters or categories are under consideration for possible inclusion in future versions of the VSO Data Model:
- Data processing information - menu?
- Data format - menu? Possible data formats may include: ASCII, FITS, JPEG, GIF, PNG, MPEG, TIFF
Nicknames for famous combinations of Search Parameters were introduced in Version 1.7 of the Data Model in a separate table. Here they are incorporated in the defining document. Certain problems remain to be resolved. For example, mechanisms are required for designating a logical OR of menu-type parameters, and for specifying whether a Bounding_Radius is an inner radius or an outer radius.