Spectrum data model

[Mark Taylor]

On Tue, 12 Sep 2006, Jonathan McDowell wrote:

> > Spectrum.Data.SpectralAxis.Value - One of these should be 'must'
> > Spectrum.Data.TimeAxis.Value	 - depending on type of data?
> >  				   (not always SpectralAxis)
> > 
> > - but I have a conceptual problem with this section, and with the
> > example on p40 - surely the model is supposed to describe the data,
> > not 'be' the data! Is p40 just an example? Surely this model is not
> > saying that e.g. FITS binary spectra must be converted to ascii-based
> > xml?  Maybe this is useful as a standard for the actual data where
> > SEDs are constructed on the fly by the VO from many separate
> > photometry points? Is that consistent with the ESO tool, for example,
> > or with SPECFind/ or with the input formats expected by spectral tools?
> > But not for all spectra.
> 
> 
> We distinguish in the companion SSA protocol document between 'foreign'
> data and VOSpectrum serializations.  The problem is that "the input
> formats expected by spectral tools" currently encompass many dozens of
> different input formats, even  within FITS. This is very different from
> the image case, where everyone can interpret a FITS image. We felt that
> we had the responsibility to provide proposed specific serializations which
> could be VO standard ways of communicating spectral data. The SSA
> protocol will allow 'foreign', meaning that you didn't bother to 
> convert to one of these formats. But for those who do bother, it allows
> the possibility for your archive to also serve up a standard format.
> We provide standard formats in ascii XML, ascii VOTABLE and in
> FITS binary table. I believe that unless we can evolve towards
> such standards, spectra will NOT be interoperable. At first, not
> everyone will do such conversion, and you'll have to hope that
> your software can consume them. But if it catches on, the pressure
> to provide the conversion will increase.
> 
> We have had some success in interoperating with different sites
> using an earlier iteration of the formats.

Jonathan et al.,

this relates to a point that I raised with Markus Dolensky last
week and he forwarded to Doug concerning SSAP and serialization 
formats.  Since it's come up here, I'll shove my oar in.

My problem is that the information returned from an SSAP query 
gives the serialization MIME type, but no more - as you point out
above, the fact that a spectrum is encoded as FITS could cover any
number of specific serialization formats.  So a client trying
to make sense of a spectrum returned from SSAP, which only has
the MIME type got from the Access.Format response field to tell
it what kind of data is at the other end of the Access.Reference,
has an unneccessarily difficult job, in that it really has to
examine the data itself to work out what the serialization format is
(and in doing that it may end up downloading a large data file only 
to find out that it is in a format that it can't understand).

Possibly the intention is that an SSAP Access.Format of application/fits
means the data is in the FITS format defined in the Spectral DM 
document (ditto for application/x-votable+xml, application/xml), 
but I can't see this stated explicitly anywhere.

Otherwise, it seems to me that what is called for is an additional
field in the SSAP response which names the specific serialization 
format, if known.  This would require assigning some sort of name
to the XML, FITS and VOTable formats defined in the Spectral DM
document (presumably a URI of some sort).

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/