SED Data Model version 0.92

[Ivo Busko]

Hi, all

So in light of this clarification, I'll rephrase
my former post to say that the files Specview is
generating are SED 0.9 - compliant; they are not
directly related to any SSAP service.

Thanks, Pedro!

Cheers,

-Ivo




Pedro Osuna wrote:
> 
> Dear all,
> 
> 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
> IVOA specification).
> 
> 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
> tool at:
> 
> http://esavo.esa.int/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
> their data.
> 
> Among those services is the SLOAN spectrum service. This service is the
> only one currently giving SED v0.9 compatible spectra (through an SSAP
> protocol).
> 
> 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
> compatible form.
> 
> 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.
> 
> Cheers,
> P.
> 
> 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
> 
> 
> Software Engineer
> European Space Astronomy Centre
> (ESAC/ESA)
> 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