Re: [Plastic-devs] spectrum load message

[Mark T. <m.b...@br...>]

On Tue, 12 Sep 2006, Isa Barbarisi wrote:

> Dear Mark,
> 
> I agree with the approach about defining additional arguments in the 
> message related more to the type of object (spectrum) than to the 
> format  of this object (votable, fits..). In fact, this is what we tried 
> to do when we defined the first SSAP definition.
> During the process of implementation of VOSpec, we found that only a few 
> parameters are needed to manipulate most of the spectra formats. Of 
> course, not all the possible spectra serializations can be used in 
> VOSpec, but that collection of parameters allows our application to 
> display thousand of spectra in different formats from ~15 different 
> projects.
> 
> List of parameters:  C: compulsory - O: Optional
> ------------------------------------------------------------------------------------------------------------------------------------------- 
> 
> Title - <title> - C - e.g. "ISO SWS01  Spectrum Target: M31_BULGE"
> URL - <url> - C - e.g.   
> "http://pma.i....../jsp/product.jsp?obsno=40001501"
> ServerTitle - <server_title> - O - e.g. "ISO Data Archive"
> WaveLengthColumnName - <wave_column_name> - C - e.g. SWAAWAVE
> FluxColumnName - <flux_column_name> - C - e.g. SWAAFLUX
> WaveUnitsScaleq  - <wave_units_scaleq>  - C - e.g. 1.E-6
> WaveUnitsDimeq  - <wave_units_dimeq>  - C - e.g.  L
> FluxUnitsScaleq    - <flux_units_scaleq>    - C - e.g. 1.E-23
> FluxUnitsDimeq    - <flux_units_dimeq>    - C - e.g. MT-2
> Ra   - <ra> - O - e.g 10.691809995
> Dec - <dec> - O - e.g    41.27003
> Format - <format> - C - e.g spectrum/fits 
> --------------------------------------------------------------------------------------------------------------------------------------------- 
> 
> 
> Our proposal is to have (at least) all the compulsory fields in the 
> message, so VOSpec (as message consumer) and e.g. Aladin and Astroscope 
> (as message senders) could be immediately updated to load spectra using it.
> Note that all the information requested is already present in the 
> existing SSAP services, and it is going to be included (perhaps with 
> some minimal syntax changes) in the next SSAP specification.

Isa,

thanks for your message.  I hadn't given much thought to these additional
metadata items.  I suppose in most cases they can be obtained from
the spectrum itself after retrieval, but in some cases the information
is available before retrieval (and useful) because the relevant fields 
are filled in for each row of the SSAP response table.

So I've revised my proposal, as follows:

   boolean ivo://votech.org/spectrum/loadFromURL( String url, String id,
                                                  Map meta )

      Loads a spectrum or SED. id is an identifier as for the VOTable
      load message - use the URL if there's no reason to do otherwise.
      The meta argument is a map/struct containing additional 
      information about the type of data found at url which encodes 
      the spectrum. The entries of this map take the form of 
      utype->value pairs, where the keys (utypes) are as defined 
      in the SSAP specification, e.g. "Access.Format" for MIME
      type. As many or few of these entries as are known may be
      filled in.

Discussions on the SSAP standard including the most recent
draft can be found at http://www.ivoa.net/twiki/bin/view/IVOA/SsaInterface
(see sec 7.5 of the SSA query interface V0.95 doc).

Sending this message should be easy to implement by an SSAP client 
(e.g. AstroScope) which wants to pass the spectrum selection on to
viewers, since it can just scoop up the fields from the relevant 
row of the SSAP response VOTable and pass them on in a Map without 
having to know or care what they mean.

VO-friendly spectrum viewers such as VOSpec should be well-equipped 
to receive and act on such messages, since in order to understand
SSAP queries which they already do, they must know how to make
sense of fields keyed by utypes in this way.  The various optional
and compulsory parameters that you describe above can be included,
as well as any others that may be available.

And an added bonus is that decisions about what metadata items 
are/can be/should be passed by the message is taken care of by the
DAL/DM groups whose job it is to worry about such things, rather 
than us plastickers who (well, speaking for myself) may not 
understand spectra so well.

This message can of course be used to pass spectra around which
do not result from actual SSAP queries, since you can add metadata
map entries by hand as if they'd come from SSAP (or just leave the
metadata map empty).

Opinions?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/