RFC initiated for Simple Spectral Access protocol

[Doug Tody]

Two points here:

1) SSA does not impose any format; FITS is fully supported as an output
format.

2) We are confusing the standard VO interchange format with the
native project format as produced by the project and stored in the
remote archive.  Pass-through of native project spectra is already
supported (this is format=native) and could make things easier for the
minimally-compliant data provider - although metadata generation is
probably the harder problem.

In the ideal case, a service will read native spectra into an in-memory
implementation of the Spectrum data model, and dynamically output whatever
format the client application prefers (we already have software which can
can do this).  A good service implementation will support pass-through
of native data as well; the client may or may not be able to do anything
with this, but native data may be preferable for some analysis.

The issue we are discussing here, is if there should be a recommended
format for the VO interchange (wire) format, where the data has already
been converted to be compliant with the Spectrum model.

	- Doug


On Fri, 22 Jun 2007, Anita M. S. Richards wrote:

> >> - Section 1.4.1 states "VOTable is preferred if only one format is
> >> supported".  I would suggest not preferring one data format over another
> >> and leaving it to the data providers to decide. For an "archival" SSA
> >> service, which is the more likely type of service to offer only one
> >> format, FITS may be a better choice.
> >
> > This may be a controversial point, but my opinion is that VOTable may
> > prove to be a better choice as an interchange format (not necessarily for
> > archive storage) for metadata-rich VO spectra, especially since an SSA
> > client already has to support VOTable for queries.  Astronomy software is
> > already adapting to support VOTable.  I suspect that most new spectral
> > services and client software will prefer to support VOTable over FITS.
> > I think it is useful to suggest a format for those who will only implement
> > one format.  If there is sufficient disagreement we can reconsider the
> > point though.
> >
>
> I'm afraid that I am with Randy on this.  Yes, VOTable is very convenient
> for some things, but the danger is that if we emphasise it too much for
> spectra, service providers may think that they don't have to support
> anything else.  In fact the majority of spectra at present are probably
> FITS or ascii or goodness knowns what, and in future large data volumes
> may be xml/binary.  Why should we impose a format on spectra when we don;t
> for images? VO tools can handle FITS perfectly well. If I had a large
> collection of FITS spectra with numerous
> extension tables giving the processing history etc., I would not want to
> convert the whole lot to VOTable.  Before someone says that it is
> possible, yes, maybe, but that isn't the point - we should impose the
> minimum requirements on data providers. It is much better to make sure
> that there are tools which can handle at least the few commonest formats
> and convert them if necessary - which may often involve converting a
> sub-set or cutout. More importantly, the metadata must be preserved.  But
> that is not really the province of this discussion.
>
>
> best wishes
>
> Anita
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AstroGrid Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>