general comments to SSAP and SDM from outside

[Doug Tody]

Hi Petr -

I agree that support for continuum normalized spectra is important,
and am convinced by the arguments made that this is often just as
useful for analysis as flux calibrated spectra.

I don't think the issue of continuum normalized spectra is
adequately addressed in the documents currently, and we probably
need to add some explicit mention of how to represent this
case.  This issue came up some time ago as well (for example see
http://www.ivoa.net/forum/dm/0502/0929.htm).  The suggestion at the
time was that we use the UCD "phot.fluxDens;arith.ratio" to address
this case (there is no UCD currently expressly for continuum normalized
flux values, although we might want to consider adding in the future).

The suggestion to add "normalized" as a form of flux calibration is
something we should consider.  What do others think?  Possibly this
could also be considered as a case of relative or absolute flux
calibration where the flux is a unitless ratio.

Regarding support for IRAF-Onedspec format for spectra (a linearized
spectrum represented as a 1-D image), I feel this is too limited a
format to be pushed as a new general standard, as we cannot express
basic things such as errors, quality flags, variable spectral
resolution, nonlinear dispersions, etc., with this format (although
nonlinear dispersion support might be possible now that we have general
FITS spectral WCS support).

Nonetheless, as you say a lot of client software accepts spectra
in this form so perhaps we can find a way to deliver software
in this form, and provide tools for publishing such software.
The only thing is, to get VO spectra into a client application is
an issue of more than the data format and data model.  We also need
client software which can form and issue a query to an SSA service,
select spectra, and download them over the Internet; legacy software
which is not yet VO-enabled probably cannot do all these things.
Hence some new software will be required no matter what we do.

One simple solution the might be do do the conversion on the client
side, and have an option to write out spectra locally in this format
for consumption by legacy software.  The advantage of this approach
is that it would work for access to any SSA service regardless of what
(standard) output formats it supports.  It is certainly also possible
for an SSA service to have the capability to return spectra in this
format, but as I say, it is not general enough to be a core format.
If a service supports 1-D images as an output format, this would be
an optional capability indicated in the list of supported formats,
and a query with FORMAT set to the appropriate MIME type (as in your
email) would specify that this is the format the client wants back.

In the case of IRAF itself we are working already to interface IRAF
directly to SSA, at which time it will be able to read Spectrum-DM
compliant spectra directly, and all the IRAF tasks will be usable
directly on VO-compliant spectra.  Other tools such as VOSpec, SPLAT,
Specview, etc. either already have this capability, or there are plans
to add it.  For other apps or environments, we have middleware such
as VOClient in development which will make this easier in the future.
Ultimately I think this is the best solution.

> Most of the spectra from ground
> are served by a  single server tool (Pleinpot by P. Prugniel)

This sounds interesting - maybe we can get this software updated
to support an SSA service interface.  We have various other service
toolkits either available now or in production (my own DALServer code
for example) which could include support for directly publishing
spectra in this format.  Having several such ready to use toolkits
is probably the best approach for making it easier for small data
providers to publish such spectra.

	- Doug