SED Data Model: Questions and Comments

[Jonathan McDowell]

Reply to Igor's message of Jan 21:

Technical:

1. Are the SIDIM parameters required? Right now they are optional
in the model, but required if you serialize in FITS. Their values
are implied by the required units and UCD, but Pedro would
like us to have them explicitly. Perhaps these parameters
should be moved in the model to the actual coordinate/flux fields
rather than be in the frame. I'll try and make a proposal on this
soon.

2. Missing FITS keywords for required DM fields.

Coverage.Location.Time.Value: I've added this as DATE-OBS (MJDOBS
would be another option).

Coverage.Extent.Sky: Added this as APERTURE

Coverage.Extent.Time: EXPOSURE  

Coverage.Location.Spectral, Coverage.Extent.Spectral: For the photometry
case it seems overkill to repeat these which are just the same as
the SpectralCoord values. Even for spectra, they are easily derivable
from the data. I'm inclined to make these optional after all.

3. This was an error for Coverage.Extent.Time, fixed now

4. Coverage.Location.Sky is an SEDCoord in the UML model
but a simple TextParam in the XML model. This was a (semi-)conscious
denormalization of the serialization for simplicity (in English:
the file format is simplified relative to the internal representation).


Ideology:

1. Continuum normalized fluxes.

Good suggestion, but it's a UCD rather than a unit issue.
These spectra are ratios of two flux spectra, therefore the
unit is 'dimensionless'. There is a ucd word arith.ratio; we can
propose a new ucd word spect.continuum and have
  ucd="arith.ratio;spect.continuum"

2. No flux calibration.

I'm still thinking about this one. In your case (shape right,
flux cal absent) one could just put a huge systematic error
bar on, but it would be better to have a special tag.

The harder case is when the shape is globally wrong. This
is also common: no division by instrument sensitivity, so
that the shape is locally right (you can see lines and measure
redshifts) but globally wrong. So we need
a 'counts spectrum' case too.

3. Atmosphere and vacuum wavelengths

As you note, we do support both in the document (with proposed
UCD em.wl.air). The problem for the DM group is:
what extra metadata do you need to let applications make the correction
from air to vacuum? Airmass, temperature, humidity, ...??

4. Resolution and line spread functions

Yes, I agree the line spread function needs to be in a future
version - but not in this version. The Resolution object will
need to be expanded, just as the Support object can be expanded
to Sensitivity.

However, I don't like your solution, because I think it
makes this special way of handling the Gauss-Hermite
resolution function. I think what we need to do is define
a standard VO way of defining parameterized functions
(maybe with XML type name VOFunction), and a way of 
declaring that the resolution is a function. It might
end up looking not so different from your solution, but
you wouldn't have a concept "ResolutionGH" - you'd
have a concept "ResolutionFunction" so 

<Resolution>
 <ResolutionFunction>
  <GHFunction>    (or: <Function name="Gauss-Hermite">
   <argument name="lambda" ucd="em.wl">
   <argument name="dlambda" ucd="em.wl,arith.diff">
   <param name="sigma" value="...">
   <param name="h3" value="...">
   <param name="h4" value="...">
  ....

The points here are that 
  (1) GHFunction can be reused in contexts other than Resolution
  (2) The format for a Function is always the same with name, <argument>.., <param>.., 
      so that you can do some base things on any function (like iterate on the parameters)
      and you don't have to design the object for every function you use.
  (3) We'll need some mechanism for keeping track of such defined functions,
      maybe with URIs to code to execute them. - how do we add a new function to the list?
  (4) It's explicit that the Resolution is being given as a function. In other
      words, if I have three resolutions:
          (a) Resolution with simple sigma
          (b) Resolution with GH function
          (c) Resolution with Lorentzian function
      we want it to be obvious that (b) and (c) are like each other but different from (a),
      and that isn't true in your approach.


(5) 2D and 3D multi object spectra (in private email to me)

Your proposal (table of spectra and table of positions for the spectra)
is OK for a multi-fiber system, but I don't think it's good for a real
data cube (integral field, or X-ray CCD) where the natural representation
is a true 3-dimensional pixel array. We can define both models
and a transformation between them. I'm not quite ready to handle this
until we have an implementation of SSAP on the floor
and working. (recall we have the format, but not the SSAP protocol
at this time).

 - Jonathan