SED FITS Serialisation: multi-extension?

[Markus Dolensky]

Hi Alberto,

Would you mind specifying which parts of either the spectral DM doc ...

http://www.ivoa.net/twiki/bin/view/IVOA/IVOADMSpectraWP

or the SSA interface doc. ...

http://www.ivoa.net/internal/IVOA/InterOpMay2005DAL/ssa-v090.pdf

... triggered particular thoughts?

For instance, what is meant by a "VOTABLE accompanying the SED"?
There is going to be a VOTable query response, but the serialization can 
either be an XML or VOTable document or a FITS binary table.

The scope is 1d spectra and time series. Are you suggesting to expand 
this for V1.0 of the two docs?

Remember, we are trying to serialize a DM. So, are your suggestions 
aiming at expanding the DM or the way its implemented (serialized)?

 > Conclusions: I see only advantages in adopting MEF, am I biased?

Does it mean to give up on serializing a particular DM and to use 
existing formats instead?

BTW, the next step on the roadmap is to unify access to images, spectra 
and catalogues by means of ADQL.

This is just to better understand your comments that you thankfully took 
the time to put down.

Cheers,
Markus



Alberto Micol wrote:
> 
> Dear SSA/SEDers,
> 
> I'd like to comment on the serialisation aspects of the protocol
> which now states that each segment is one row in a fits binary table.
> 
> In such serialisation the characterisation is left completely to the 
> VOTable
> accompanying the SED, since it becomes impossible to characterise each and
> every segment with a single header.
> 
> That is fine IF the user does not care to know the origins of the segments.
> (And someone might claim that such a user in not too careful, to say the 
> least.)
> 
> My view is that the VO should simplify life of the users in other ways
> than just stripping off all the information that the data provider, mostly
> painfully, put together. :-)
> 
> My favourite solution would be to adopt a FITS extension for each of the 
> segments,
> each extension containing:
>  -  a header with VO keywords PLUS the original header keywords,
>  -  a binary table with scalar columns
> 
> In that way the work of the data provider would be happily recognised, and
> the user might be able to find any kind of details regarding any segment,
> from the calibration reference files used to calibrate a spectrum down to
> the acknowledgment sentence some times buried in some fits COMMENT or 
> HISTORY keyword.
> 
> The multiple extension FITS format would also allow to cover the 
> spectropolarimetry
> case (currently not supported at all), where for each wavelength
> the Stokes parameters will be also stored in separate scalar columns.
> 
> Also, I think that the echelle spectra are causing some troubles to
> the current format. Each of the multi order spectra should probably end up
> into its own extension.
> 
> Conclusions: I see only advantages in adopting MEF, am I biased?
> 
> Alberto
> Aside: With such a format, it would then also be easy to build a SED On 
> The Fly
> whereby a SED-OTF tool can compose SSAP queries to some selected 
> services and
> come back with a single multi-extension FITS file: it is just matter of
> appending any individually ssap-returned FITS file to the 
> multi-extension file.
> (Unless I'm wrong, I don't think that the current serialisation allow a 
> so simple
> assembling of the fits files).