[SPECTRA] Some thoughts on the spectral model
dtody at nrao.edu
Fri Sep 19 10:55:32 PDT 2003
Hi Jonathan -
I hope that others will respond to your message, but I have some comments
along the lines of what we discussed in Victoria.
> As those of you who were at the recent NVO meeting know, I have been
> taking a look at the datasets referred to in the spectral use survey led
> by Doug Tody. Here I note a grab-bag of things that came out of this
> study we should keep in mind for the spectral data model. In general,
> the model for spectra presented earlier covers most of these cases, but
> doesn't have a good place to put things like exposure and response
Both object spectra and calibration spectra would be useful to have online
with consistent data model support, but our priority should be to support
object spectra from large spectral surveys. A data model that supports
"typical" spectra surveys (if there is such a thing) will probably also work
for virtual object spectra constructed on the fly, e.g., from spectral
data cubes. We should address this hopefully simpler problem first
and then perhaps extend the data model to describe calibration spectra.
Calibration spectra can be idiosyncratic hence difficult to describe with
a general data model, at least without making it complex.
Some spectral surveys to look at include SDSS, 2DF, VIRMOS, DEEP2, IUE,
FUSE (note some of these were not included in our spectral survey).
> 7) Although not different from the data model's point of view,
> I'm particularly concerned by the SDSS spectral FITS files.
> These have an n x 4 FITS image, where n is the number of
> wavelength points and the 4 layers are different observables
> (data, continuum-subtracted data, error, mask). This breaks
> the FITS paradigm (e.g. BUNIT is meaningless since the 4th
> plane has different units from the other 3) while using four
> n x 1 images would have been perfectly legal FITS allowing
> use of meaninful metadata. SDSS is by far not the only offender
> in this respect. Data providers will haave to take particular
> care in describing such datasets to the VO, and I suspect the
> data will have to be reformatted prior to transfer along the
> wire if generic VO tools to be developed to operate on
> spectra are to have a chance at swallowing these data.
The best way to solve this problem is to have our SSA services convert
data from the various proprietary spectral data formats into the data
model we implement in SSA. We can then return the spectrum data to the
client in simple ascii, XML/VOTable, HTML (for display), or FITS. In the
latter case would need to invent a FITS format for 1D spectra. In effect,
equivalent spectra in the SSA spectral data model would be available to
the client in any of these formats. We also plan to provide a link to
the raw external data file (if available), but it will be most useful
to have the data provider deal with the details of the many different
spectral data formats out there.
More information about the dm