SED Data Model: Questions and Comments

[Gilles DUVERT]

Hi,

DM is not just the sum of its parts. One has to make choices. The need 
is to insure data QUALITY and MAINTAINABILITY. Keep things simple. DM 
should describe the physics of the data, that unite, not the habits of 
the data producer, that divide.

So:
Jonathan McDowell wrote:

>Reply to Igor's message of Jan 21:
>
>
>Ideology:
>
>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.
>  
>
A measure is a value and an error. If there is no flux calibration, the 
measurement does not exist, and a data model shall not be concerned by this.
DO NOT PERMIT TO WRONG OR UNRELIABLE DATA TO BE OUT IN THE VO!!!

>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, ...??
>  
>
USE FREQUENCY, this is the core of reality, insensitive to media. Does a 
bracket gamma line takes a cold because the weather that day was cold 
and humid and it did not take its scarf? Leave the gory details to the 
producer of the data. Leave the end-user convert metadata frequencies to 
whatever unit it pleases himself.

>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.
>
>
>  
>
Let the DM support standard functions (sigma, gauss, lorentz) that fit 
99% of needs, and leave the transform of the data to this functions to 
the  expertize of the data producer. He knows best.

>(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).
>  
>
first case (table of spectra and table of positions for the spectra) is 
just a table with spectra, since a spectrum is more than often the 
spectrum of something that has a location-> done.

2nd case is really a data cube. Add polarisation that makes 4 
dimensions, if I do not count the fact that a measure is a (value,error) 
doublet and that 'spectrum' can be a complex . This is already supported 
by FITS standards and seems to please everybody (?). Should have a DM of 
its own, that sums up, e.g., Transforms(WCS), Spectra, Images...

> - Jonathan
>  
>

-- 
----------------------------------------------------------------------------
Gilles DUVERT, Astronome        | Gilles.Duvert at obs.ujf-grenoble.fr
Laboratoire d'Astrophysique     | Phone: +33 (0)4 76.51.48.85
Observatoire de Grenoble        | Fax:   +33 (0)4.76.44.88.21
BP 53X  F-38041 GRENOBLE CEDEX  | LAOG (http://www-laog.obs.ujf-grenoble.fr)
Dir. Technique JMMC(http://mariotti.ujf-grenoble.fr) Resp. Informatique LAOG
----------------------------------------------------------------------------