SED Data Model version 0.92

[Doug Tody]

Hi Randy -

Thanks for taking a look at this and providing some feedback.

> I just  discovered the IVOA SED Data Model document version 0.92 and
> wanted to ask some questions about it. Since we have been anxiously
> awaiting an SSAP for distributing spectral data from MAST, we were happy
> to see progress being made.
> 
> First of all, I am confused why the document has changed from the Simple
> Spectral Data Model to the SED Data Model when it will be used to
> "represent SED, spectra and time series data".  Do you plan to write
> separate documents for each data type?

It is still called Simple Spectral Access and the "spectral data model"
is not restricted to SEDs.  SEDs, spectra, and time series are all
spectrophotometric (spectral) data.  Basically they are all sequences of
spectrophotometric data points, just organized in different ways.

There is no intention to write a different document for each of these
types of data although we do expect that service instances will generally
support only one type.  Accessing 1D spectrum is probably the most common
use case and the whole interface should reduce to something fairly simple
for this case.  (Although every time we have this discussion people want
to add more features to the model).

> Also, I am confused about the FITS serialization in section 8.1. Are
> you requiring variable-length arrays and not allowing array fields
> within the binary table itself?  I would think not all data sets require
> variable-length arrays and the FITS standard even recommends a simpler
> format when this feature is not necessary.

Good point, the document does talk explicitly about variable length arrays
and that should probably be revisited.  Whether a fixed or variable array
is used should probably be left up to the data provider.  Fixed arrays
are preferred where they are sufficient.  The data model does not care,
it is purely a representation issue.

> Finally, I think there are errors in the sample FITS header shown.
> It look like there are actually 15 fields, not 14 (there are 2 sets of
> TTYPE2 & TFORM2 keywords), and there is no THEAP keyword describing the
> offset to the data heap. Unless the convention has changed, this should
> have the value of NAXIS1 * NAXIS2 if there is no gap between the binary
> table and the data heap.

You are correct, this is an error.

	- Doug