Photometry in VO Spectrum Model

[Jonathan McDowell]

Adding support for magnitude photometry to the Spectrum data model
------------------------------------------------------------------

At ADASS it was requested that we add better support for magnitude
photometry to Spectrum, specifically adding a magnitude zero point
and a way to provide a transmission curve.

I've considered several ways to do this.

(A)
 Alternative 0:
 - the magnitude zero point allows you to go from the data values
(in mag) to an absolute flux (in Jy or similar units). This is
very like a coordinate system. We could add a FluxFrame specialized
from CoordFrame with a Zero attribute with value, ucd and unit:
  FluxFrame.Name       B
  FluxFrame.UCD        phot.mag
  FluxFrame.Zero.Value 4893.0
  FluxFrame.Zero.Unit  Jy
  FluxFrame.Zero.UCD   phot.flux.density;em.freq

  Pro: Rigorous approach. Could be generalized to other 
   situations.
  Con: We don't normally think of the y axis as a coordinate. Adding
   a CoordFrame for it could be confusing, add complexity, and
   reduce compatibility with STC.

  Alternative 1: Just add a single value Spectrum.PhotZero
  to the top level object, required to be in Jy
  Con: Ugly (clutter up top level object) and inflexible (not
   everyone wants to give the zero point in Jy?)

  Alternative 2: The other obvious place to add it is in
   Characterization. We could subclass the Char.FluxAxis (Figure 3)
   to have a special Photom object with Photom.Name, etc.
  Con: Reduces symmetry in the Char description. But maybe 
   not too badly.


(B) - 
 Alternative 0 - 
  the transmission curve has been discussed in the
  Observation/Characterization
 data model subgroup; it is the 'level 4' characterization, or Sensitivity,
 for the spectral coordinate. We could add a new Sensitivity object
 to the Spectrum characterization, with a single field holding an
 IVORN URI to another instance of Spectrum holding the transmission curve.
 We would add the field:
  Char.SpectralAxis.Coverage.Sensitivity.URI

 Pro: a long term generalization.
 Pro: Providing a URI is a minimal implementation change rather than adding
  a complicated structure.
 Pro: Since many datasets may share the same transmission curve,
  a URI reference rather than an in-place pair of data arrays is much
  more efficient.
 Pro: Also works for X-ray ARF curves, needed for publishing e.g. Chandra data.
 Con: Adding Sensitivity is something that was deliberately left out
  of the current IVOA Characterization doc and deferred for later.
 Con: Adding Sensitivity to Spectrum.Char.*Axis.Coverage in the object
  model (where I argue it belongs) 
  adds it for all axes, not just the spectral axis.
  (The TimeAxis sensitivity would represent a time-variable sensitivity,
   and the SpatialAxis sensitivity would be a spatial QE map). 
  This added complexity is not needed for the other axes at this time.
  However, we could just say that you should only use it for the SpectralAxis
  case for now.

 Alternative 1: Add it somewhere else in the model, e.g. at the top level.
 Con: As for (A), it's an ugly, cheap getout to add things at the top level.

 Alternative 2: Add it as an extra field to the Char.FluxAxis.Photom
  object posed in (A)'s alternative 2 above.
 Con: when Char does do Sensitivity, we may want to replace it.
 So the Alternative-2 proposal becomes
  Char.FluxAxis.Photom.Name       B
  Char.FluxAxis.Photom.UCD        phot.mag
  Char.FluxAxis.Photom.Zero.Value 4893.0
  Char.FluxAxis.Photom.Zero.Unit  Jy
  Char.FluxAxis.Photom.Zero.UCD   phot.flux.density;em.freq
  Char.FluxAxis.Photom.Sensitivity.URI   ivo://photom/B_Johnson_KPNO2004

I think either Alternative 0 or Alternative 2 are workable in each case;
I request feedback.
  - Jonathan