Comments on Spectrum Data Model 0.9

[Ivo Busko]

Anita Richards wrote:
<snip>
> to SDSS; what do other people think, e.g. ISO, ALMA?  I would also
> like to know what Ivo Busko (SpecView designer) makes of it.
<snip>

I also liked the model very much. Seems to be very
complete.

My reading is biased towards the spectral formats I 
implemented in specview, so I may have missed potential
problems in parts of the model that do not relate
specifically with what specview can do. For instance,
there is nothing in specview to deal with time
dependencies, thus I cannot say much on that regard
from a practical, implementation viewpoint.

I attempted to "fit" the spectral formats implemented in
specview into the model, and not a single one failed to
do so. I could have used such a model, if it were available
5 years ago or so, to completely design the specview
Spectum interface from scratch. As a matter of fact, I can
use it now to add new capabilities not supported yet, such
as variable resolution...

Well, there is a single minor point where the model and
the "real data" I used disagree: data providers usually
do not care to calibrate the background data to flux 
density units. The few formats that allow for a background
array (STIS, IUE, ACS) provide then in some sort of raw
counts. Thus if the requirement in paragraph 4.4 of the
model document is to be enforced, these spectra must be
delivered without the background array. Unless the data
provider adds an extra "calibration step" at the delivery
point (if feasible).

As for the main issue addressed by Anita: I don't see the
apparent redundancy in information content as a problem,
IF a solution based on WebServices (or equivalent) technology
is adopted by both providers and consumers. In that light the
Spectrum Data Model can be considered as describing an 
interface, not an implementation. Other issues addressed by
Anita can all be handled in such a framework as well.

Thus in the example of a spectrum where the resolution, say,
is the same for all data points, the delivery (that is, the
thing that actually goes thru the wire) will carry a single
instance of a Resolution element. The interface implemented 
at the receiving end will handle that format transparently to
the consumer code, such that one can still write 

resolution = dataPoint[i].getResolution() 

according to the interface (data model) specs, and get the correct
value for the resolution for each data point i.

However, outside the scope of a webservices infrastructure, 
Anita's concerns are still valid. Presently I wouldn't know
how to handle them.

-Ivo

 *********************************************************************
 *  Ivo C. Busko, PhD                        e-mail: busko at stsci.edu *
 *  Senior Systems Software Engineer                                 *
 *  Science Software Branch                                          *
 *  Engineering and Software Services Division  Voice: (410)338-4472 *
 *  Space Telescope Science Institute             FAX: (410)338-4767 *
 *  3700 San Martin Drive                                            *
 *  Baltimore MD 21218-2410  USA                                     *
 *********************************************************************