SED Data Model version 0.92
Pedro.Osuna at sciops.esa.int
Tue Feb 1 08:52:06 PST 2005
there might be some confusion on the naming of the different things.
The Simple Spectrum Access Protocol refers to the protocol to access the
Spectra (as the SIAP does for images) whereas the SED Data Model
describes how those spectra should be modeled (to be compatible with the
The SSAP is not finished yet. There is only a version 0.1 document. We
have asked for the inclusion of a couple of dimensional parameters in
that protocol, and are already using it.
You can see a real service using SSAP registered data using our VOSpec
When inputing a target and clicking "Go", the tool will access the NVO
Registry and get those services registered as giving SSAP access to
Among those services is the SLOAN spectrum service. This service is the
only one currently giving SED v0.9 compatible spectra (through an SSAP
Therefore, we do have already a tool that accesses Spectra using
-current- SSAP and one of the services provides the Spectra in SED v0.9
As you can see, there are other five services giving SSAP access (ISO,
IUE, HST, FUSE, HyperLEDA) which do not -however- give their spectra in
SED v0.9 compatible form.
I hope this clarifies the issue.
On Tue, 2005-02-01 at 16:20, Doug Tody wrote:
> 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
Pedro Osuna Alcalaya
European Space Astronomy Centre
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 8131314
European Space Astronomy Centre
European Space Agency
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN
More information about the dm