SED Data Model: Questions and Comments

[Igor V. Chilingarian]

Hello,

During last month I've been working on SSA services for the Observatoire de
Paris, so I had to study exhaustively the SED Data Model draft v0.92
( http://hea-www.harvard.edu/~jcm/vo/docs/spec.html ). I have some comments,
questions, and suggestions concerning this document. They may be separated
into two parts: technical and ideological (comments made by me as by an
astronomer working in optical integral field spectroscopy).

I'll start with technical problems and questions.

1/ While in the paragraph about FITS serialization it is written that
dimensional equations are required, in the paragraph about Frame object it is
said that all the Frame fields are optional.

2/ Some "required" DM fields don't have corresponding FITS keywords in
the translation tables:
        Coverage.Location.Time.Value
        Coverage.Extent.*

3/ What is "Coverage.Exposure" -> "EXPOSURE"? It appears only in the
FITS<->DM translation tables

4/ While the UML class diagram shows inheritance(?) of SEDCoord type by
Coverage.Location.[Sky,Time,Spectral],
Coverage.Location.[Sky,Time,Spectral].Value's are declared as "Position"
and "TextParam" in the XML schema. Should they be "SEDCoord"?

==================
Now some ideological aspects.

1/ The most important problem is handling the spectra expressed in the
continuum-normalized fluxes. Many astronomers, especially ones working in
stellar physics, absolutely don't care about flux calibration. They prefer
to use continuum-normalized spectra, because it allows to measure easily
equivalent widths of absorption lines, fluxes of emission lines, etc.
Presently there is even no UCD (though it can be constructed) to describe
this sort of data, though zillions of spectra (especially high-SN
high-resolution Echelle) are available in this format. The
continuum-normalized representation is also very useful for comparing
spectra of different objects of different brightnesses.

We tried to discuss this question on the VO-related seminary in the
Observatoire de Paris two days ago, and all the astronomers agreed that
continuum-normalized spectrum is a very important particular case of the
spectra representation, and it should be separated from, say general
not-calibrated data. There should be UCD especially for this data type.

2/ How is it possible to describe the spectral data, where the flux
calibration is not absolute (i.e. the "shape" of the spectrum is correct,
and "counts" in any wavelength channel have the same ratio to F_nu or
F_lambda, but this ratio is unknown, or known with an awful precision)? This
is a very typical case for ground-based observations, for example if you
observe with a narrow slit, and seeing changes in time, the calibration
you'll get will be wrong, but spectra are still useful for numerous
astrophysical applications, such as spectral synthesis. In other words, the
problem is to describe SED in physical flux, but without absolute
calibration. In terms of Osuna-Saldago dimensional/scale equations it means
that we DO have the dimensional equation, but we don't have scale equation
for flux, e.g. "1.E+7 ML-1T-3" -> "Unknown ML-1T-3". So, my suggestion is to
remove the constrain for scale equation. If one provides the scale
coefficient, it should be used by the client, but is it not provided, there
should be a way to enter it (manually and/or automatically).

3/ Atmosphere and vacuum wavelengths. Probably it is not a question for DM
and DAL groups, because the possibility of having any of them is asserted in
the present draft. But how one can handle this? Optical astronomers will
never accept 6564.7A as Halpha wavelength (in vacuum), because everybody
knows that Halpha is 6562.85A (air wavelength)! For a moment (in SDM v0.92)
usage of AWAV is not recommended. The possible solution is to use wave
numbers or frequencies, that don't depend on the refraction coefficient, but
optical astronomers will not accept this! They don't even accept nanometers
instead of Angstroms. This raises a question of coding the rule for
converting AWAV<->WAV. Should it be specified in the metadata, or it should
considered as "well-known" on the side of VO clients, or we should provide,
say WEB-Service doing the job?

4/ Precise description of the spectral resolution . I raised this question
for a couple of times, so to make the data model self-sufficient, it is a
good idea to be able to describe in details the line-spread-function, that
may vary through the wavelength range, and may be quite complex (neither
Gaussian, nor Lorentzian). The function itself may be described in the
similar way to the transparency curve of the filter (for future, maybe even
for SDM v.2).

For a moment (for SDM 1.0) I'd like to propose to complicate the
"Resolution" field of the "Accuracy" object to add 2-, 4-, or 6-parametric
description of the line-spread function beside FWHM. What I mean is
Gauss-Hermite representation (van der Marel, Franx, 1993ApJ...407..525V):
the approach used by astronomers dealing with stellar kinematics of the
galaxies to describe LOSVD. The line-spread function can be described by 2,
4 or 6 parameters: dl (systematic shift in spectral coordinate), sigma
(dispersion of the approximate Gaussian) [, h3, h4 [,h5 ,h6] : Hermite
polynomials coefficients, describing deviations from Gaussian shape].
Usually 4 parameters are used, because one needs very good sampling and high
S/N ratio to extract h5 and h6 from observational data. In this case,
Resolution.FWHM can be computed.  On the other hand, this 6-param
representation should not be an obligation (as the "Resolution" object
itself): one may want to use only FWHM.

The XML-schema would be changed in the following way:

  <!-- A single SEDCoord (time or spectral coord) value. -->

  <xs:complexType name="SEDCoord">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="Value" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="Accuracy" type="Accuracy" />
          <xs:element minOccurs="0" maxOccurs="1" name="Resolution" type="Resolution" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="Resolution">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="FWHM" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="ResolutionGH" type="ResolutionGH" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="ResolutionGH">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="dl" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="sigma" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h3" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h4" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h5" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h6" type="DoubleParam" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


That's all for a moment. Probably I forgot something.
I appreciate if you're still reading this :)

With best regards,
						Igor