RFC initiated for Simple Spectral Access protocol

[Doug Tody]

On Fri, 22 Jun 2007, Jesus Salgado wrote:

> I fully agree with the fact that SSA can/should not impose any output
> format. I (with my VOSpec developer hat) would prefer to have a single
> format so the implementation is easier in the client but We (with my
> data provider hat) cannot accept I am forced to change to a format that,
> for my particular project/archive, it is not the better one to
> characterize my data.
>
> In fact, all the data producers consider their format is the optimal for
> their data and, even when some could consider the SED data model (both
> XML or FITS serialization) better, I do not know any data producer who
> share this opinion. On the other hand, the resources necessary to
> transform the legacy/original format to the SED DM one could result in
> many data providers never wanting to be part of the VO effort.

This is why SSA needs to support pass-through of native project data
(which it already does); being project-specific, the native data will
often contain more detailed information than is available via a standard,
more generic model.

The reason this alone is not enough though, is that it will not be
possible for every client application to understand the details of every
project-specific spectral data format in the world, now and in the future.
Mediation to a standard model can lose some information, but it makes it
possible for an arbitrary client app to analyze spectra from any source.
This only has to be done once, by the data provider, rather than many
times, in each client application.  No information is lost since the
native data is still available.

(We are repeating old ground here and have long since diverged from the
original issue).


> So, in my opinion, we should live with legacy/native data and we should
> add the necessary info in the SSA VOTable output to enable a VO
> application to deal with this format (if possible)
>
> This is why, in case we have a native format referenced in the SSA
> output, some fields should be set as compulsory for foreign data, i.e.
>
> Dataset.SSA.SpectralAxis
> Dataset.SSA.FluxAxis
> (WARNING! The previous two fields which define the columns where the
> spectral coordinate and the flux are stored have disappeared from the
> SSAP spec 0.97 (they are in version 0.91)! We assume this is by mistake)
>
> (Note: In case it is assumed the VO client is forced to get the project
> datamodel from Dataset.DataModel and then, in some way, understand the
> structure of the file to allow the data parsing, etc., that would open
> another debate)

We had to remove the SpectralAxis / FluxAxis metadata because we realized
we could not define what this means.  For native data, the data can be
in any format (not necessarily the specific FITS binary table format
VOSpec supports).  What if the native format is XML for example (as
for Sloan), or a FITS 1-D image as in some archives?.  Since the native
format could be anything there is no (general/simple at least) way to
specify what the value of SpectralAxis is, or how to interpret it.

These fields could still be returned as optional metadata, if the
native format is known to the client via the DataModel value as you
mention above.  This is more a convention than a standard though, since
it would only work for some subset of the data.

> Dataset.SpectralSI
> Dataset.FluxSI

These are supported.

	- Doug