SED serialization

[Doug Tody]

Miguel -

This is very useful as I think it helps illustrate how complex SEDs
can be, especially if we consider heterogeneous or theory data, or
dynamically computed SEDs.  While a multi-segment spectrum (or time
series) can be considered a special case of a SED, in general SEDs
can be much more complex than this.

If I understand your argument correctly, you are saying that:

     o	Spectrum as it stands is the right approach for the case of
 	"simple" 1-D spectra (although some more features such as
 	for modeling photometry may be required).

     o	For SEDs what is mainly needed is a high level description
 	of the overall SED object.  The individual observations or
 	datasets ("segments") which contributed to the SED can be
 	anything, and are best dealt with by pointing to primary
 	datasets that describe these (e.g., a separate 1D-spectrum,
 	image cutout, etc.  Existing interfaces such as SSAP, SIAP,
 	TSAP, etc. could then presumably be used to get at this data.

Perhaps smaller Spectrum or whatever objects can be directly included,
but this could get complicated - we should think more carefully about
what this really means.

The following is an especially good point:

     > The VOTables that the applications will deal with (and also users)
     > will be smaller in size and, hence, virtual memory (e.j. my set of
     > high-resolution spectra results, that I would include in a single
     > VOTable in the SED dm will have a size about 4Gb).

This could also be the case for time series or theory data of course.

In a case like this, there really is no way we can practically
include the individual datasets directly as segments, and some means
of pointing to the external data is required.  Then if the analysis
needs to go look at the primary data it can use an existing interface
appropriate to that data to access it.

 	- Doug