UCD problem in SSA/SpectrumDM

[Petr Skoda]

>> And maybe the required concepts of spectra cutout, rebining and 
>> normalization could be introduced here without changing the DM and protocol 
>> - just by some explanatory add-ons.
>
> Ok, some clarification would be fine here, and this has been a point of
> confusion I guess.
>

OK - I will prepare some add-on (mainly explaining the scientific use 
cases  - e.g. the rectification oif continua and try to explain the 
difference from the stellar synthesis model (I will contact Miguel 
Cervino if it is coerrectly explained)

> This is a perennial problem; I am not sure we can solve it in a minor
> document revision.  COLLECTION is a good start as it abstracts the
> issue to the scienfific type of data being searched/accessed.

I have the same feeling - that collection should be rather homegeneus set 
of data of the same structure -i.e.  one spectrograph or spectrograph mode
(for imaging spectrographs) - to give sense the data should be directly 
comparable - e.g. for overplotting. I can select more such a sources - 
i.e. services (individual SSA records) if needed, but it is currently big 
problem to select only one instrument - perhaps some query by 
characterisation will be possible in future SSAPs but I do not have it now 
in clients anyway.

>
> In general I think it is better to classify data by the scientific
> characteristics (collection, instrument) rather than by the origin
> (ESO).  Just putting up one service for all data at a site is too
> simplistic.
>

Does someone from DAL WG have objections against this idea ?
I have heard arguments that the SSA services list will be to large (e.g. 
ESO will publish one day all of the spectra from all instruments - many 
having spectroscopic modes ....)
Lets make some geneal recommendation in the sense above (or another if 
justified) and put it in the revised SSA

>> And what is an absolute must is a case of photometric series - e.g. the 
>> COROT archive
> I don't understand the problem Petr - can you expand upon this?
> SSA can support time series of spectra for example, if we just search
> based upon time.  True photometry data would be better handled by a
> TimeSeries service

I am afraid that in the DAL there is a still misunderstanding of term 
"photometry". E.g. the so called Photometry Data Model is something 
different than most of astronomers would understand  under this concept .
It is strongly biased by its origin  in space jargoon (and namely in ESA 
and Chandra - high energy astronomy), where the way of thinking is rather 
different from optical astronomers.

The photomery in sense of the DM proposal is in fact something called 
"Spectrophotometric  Calibrations" and its goal is to apply proper 
corrections to different colors to fit SED - i.e to convert between 2 
filters.
But in amateur astronomy and most of the ground-based optical astronomy
by photometry of the star is understood the TIME SERIES of intensities 
(either RELATIVE converted to  differential magnitudes) or ABSOLUTE - 
converted to the standard filter (e.g. Geneva system of Johnson) - the 
conversion is done as part of reduction (and the methods are part of the 
scientific know how - depending on the nature of the instrument as well as 
properties of the object)

But usually the photometry is used to study the TIME EVOLUTION  of an 
object (e.g. novae or SNe) or the PERIODIC events (pulsation, orbital 
motion in multiple system, AGN activity etc ....)
So the crucial information is to show given LIGHTCURVE (i.e intensities in 
several filters plotted  in time (the x-axis is usually some HJD) or (most 
common) in PHASE of the given PERIOD - this is a proper PHOTOMETRY 
LIGHTCURVE.

And what COROT archive does is to use SSA for getting the information of 
that time dependency of given filter - so on "wavelength" axis is time and 
on vertical is a intensity in one filtr.
The Characterization obtained by the service is thus just giving the 
values from FITS headers that some  are probably mission-specific.

The advantage of this attitude is obvious. When properly described 
metadata (UCD and utypes) are given, we could immediately publish
huge archives of photometry observations in SSA.
The curent approach is to get tables from e.g. Vizier - in form of 
VOTABLE and use some general tool like TOPCAT to display it.
But if SSA wrapped the SPLAT and VOSPEC can be used immediately with all 
the analytic features.

In any case the people from SVO (Enrique ?) might explain the reasons for 
their solution. For more details see the COROT archive in SSA registry and 
try to play with it.


>
> Well we can improve matters I expect, but we will never completely
> eliminate confusion and misunderstanding.  Ultimately some actual human
> interaction may be needed, e.g. a support discussion list/newsgroup.

That discussion I would like to see here in DAL.


>
> Yes, this is important for services that service high resolution
> spectra.


> This would appear to be a client app issue.  It is similar to
> the multi-resolution problem for images.  Ultimately we need a
> multi-resolution solution, plus cutouts for very small regions such
> as individual spectral lines.

Exactly - I hope that explaining the reasons for cutout in the document 
would help to understand the implementors of SSA why they should bother to 
program it.

> I am sure that by proper hints and 
>> examples most of the useful things may be done already now - but is has to 
>> be said explicitly how.
>
> SSA already gets us much of the way towards providing these
> capabilities - it already provides more than any application has yet
> used.


   Ultimately we need more work on the client application side
> before it is worthwhile to evolve the service capability.
Absolutely - but even with current clients it may be done lot of science 
work if the server will provide basic services like spectra cutout (using 
the BAND), will 
be able to select different sets of FLUX calibration (especially 
of most scientific importance are absolute and normalized).

In future versions would be desirable to be
able to convolve the spectra with gaussian using the info about spectra 
resolution power or some kind of rebinning according to this)


> available for advanced analysis software development.  I think this
> is more of an issue currently than what we have available for VO
> development.

As I said many times from the scalability reasons most of the work has to 
be done on server to reduce the data flow (cutout) or select proper set 
(flux calibrated or normalized or simply return what it has).
Concerning normalization - it might be done on-the fly as well, but most 
probably it requires humen intervention during reduction phase and so the 
server should return simply another set if available.

I can rework this in a some case study  to be added in the informal part 
of the revised document.

BTW - I think it would be good to add more examaples in appendix of real 
service (not prototype SDSS which is still not available) - the example 
being full including the characterization, provenance etc.
And I would like to ask Alberto and Bruno to describe it on some ESO case 
- best UVES spectra.

Because those who will need to understand the SSA to be able providing 
their spectra will be surely ground-based astronomers from smaller 
observatories then people fromspace projects (they are in IVOA already 
involved).

When do you expect to start the revision of SSA (this minor) ?

>
> 	- Doug
>

Best regards,

Petr
*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************