SSA working draft

[Inga Kamp]

Hi Doug,

> >>> Why do you want to single one type of response format out? Why not have
> >>> them all equal?
> >>
> >> Not sure what you are referring to here; 1.4.1 describes the levels of
> >> compliance of a service, not response formats.
> >
> > This was referring to "if you provide only one format, then VOTable is the
> > preferred".
>
> Thanks for the clarification.
>
> Actually this is a good question: should we define a preferred format
> in which we would like to get spectra back?  This could be desirable
> so that clients don't have to be prepared to deal with all the various
> kinds of data formats (the main reason we define multiple formats
> is so that the client can get whatever it prefers).  If we suggest
> a format to support my tendency is to go with VOTable for spectra
> since it is much better than FITS for metadata, and ok in terms of
> efficiency in most cases for spectra, especially if protocol-level
> compression such as gzip is used.
>

Most Astronomers would not know what to do with a VOTable. It might be a
convenient format for all the metadata, but supposed that the person who
is exploring the VO and discovering the data actually wants to use it,
FITS is the more natural way to go. It works with all major astronomical
software and data analysis packages. Moreover, there are now many
FITS-readers out there, so that even non-Astronomers won't have any
problems with it. We should keep in mind that our end-clients are still
mostly humans and mostly astronomers.

> >>> Apertures need not be circular, so you may want to phrase the respective
> >>> sentence different.
> >>
> >> Only circular apertures are currently supported for on-demand spectral
> >> extraction and this should be adequate for point-source or compact
> >> objects (even for Grism data).  We could generalize this if needed,
> >> but it complicates the interface.
> >
> > How do you avoid confusion when people actually want to search for a
> > particular observing aperture? Wouldn't it be better to make this clear in
> > the name like EXTRACT_APER?
>
> In an earlier version of the interface we used the APERTURE parameter
> for this purpose as well.  But it is confusing to overload the parameter,
> and searching by aperture gets complicated in any case as one might have
> rectangular apertures and so forth.  Hence APERTURE is now used only for
> spectral extraction.  As you suggest, it might be useful to use a more
> specific parameter name to ensure that people don't confuse the meaning.
>
> There is no way in the current interface to query directly on
> the aperture size and geometry, but one can query on the spatial
> resolution, which for most spectra is roughly similar to the aperture
> size.  This does not cover the case where the aperture is much larger
> than the spatial resolution, however this is probably rare enough to
> not be worth supporting directly in the query interface.  One can always
> submit a more general query and refine the query on the client side
> using the more detailed spatial coverage information which comes back
> in the query response.
>

You have to see also the conflict with the data model. Both cases have
this aperture "keyword/parameter". However, once it's the extraction
aperture, once the instrument aperture. When we archive grism spectra, we
want definitely to store both and be able to pass both on in the response!
Even if the instrument aperture is not a query parameter, this causes
problems in the data model.

Cheers,
Inga

>  	- Doug
>