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:
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).
Received on 2005-06-13Z11:28:05