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.