SED serialization

[Ivo Busko]

Doug Tody wrote:

<snip>

> Not greatly different, but the main point is that a SED may be worth
> considering as a new type of astronomical data (a primary type) and not
> just a fancy Spectrum.  That is, a SED could be a top level Dataset type
> (like Image Spectrum, TimeSeries) which is multi-segment, with an overall
> Characterization and Identification, and homogeneous units to summarize
> all the segments.  The individual segments can be instances of Spectrum,
> TimeSeries, or individual photometry points.  Auxiliary metadata might
> be required to describe how the SED was computed, especially in the case
> of dynamically computed SEDs, where one might want to include images
> cutouts for photometry from multiband imagers and so forth.
> 
> Spectral associations are slightly different, being informal
> associations of primary datasets rather than a single physical dataset.
> A multi-segment Spectrum could be considered an Association or a special
> case of a SED; both could be valid.
> 
> 	- Doug

Doug,

I still see a benefit in having a SED to be a special case of Spectrum. 
Being a subclass of Spectrum means that any application code that can 
handle a Spectrum instance, will be able to handle a SED instance 
transparently. It might not be able to provide everything that a 
SED-aware application is, but it won't crash or refuse to handle the SED 
data.

Maybe I am influenced by the design choices we made when writing the 
Specview application, but the "SED as a special type of Spectrum" design 
paradigm showed to be very useful in that case.

-Ivo