UCD problem in SSA/SpectrumDM

[Doug Tody]

Hi Petr -

I am worried that what you suggest may be too ambitious for a minor
document revision.  We should limit this to minor backwards-compatible
changes, e.g., a few UCDs and some clarification of text otherwise
the goal of getting out a minor revision quickly (especially to fix
any a few minor errors like the UCD issue) will be lost.

On Mon, 23 Nov 2009, Petr Skoda wrote:
>>  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.

An instrumental data collection (data from only one instrument)
is still a "collection".  Collection is just a generalization of
"instrument", needed since not all data comes from some instrument.

A reasonable approach would be for any large collection to be exposed
as a separate service.  If a site has a lot of small collections it
might be better to have them in one service.  Note that in this case
the COLLECTION parameter could still be used to find data only from
some instrument, so long as there is some effort put into defining
the collections.

>> 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)
> ... So the crucial information is to show given LIGHTCURVE

Ok, so we are talking about time series and light curves as I mentioned
in my mail copied above.  Photometry is relevant to both spectra
and time series so I don't see there is such a big difference as you
suggest.  The current Spectrum data model is actually a fairly general
spectrophotometric data model and could (with a few enhancements)
be used for light curves as well as for spectra.  We could have a
variant of SSA for time series data (this has long been the plan),
or perhaps a SSA 2.0 could handle both since they are so similar.
SSA already pretty much works for time series data (e.g. SVO has
already done this), however it could use some additional features to
properly support time series data, e.g., a better photometric model,
support for multiple photometric samples per time value, possibly
segments, etc.

 	- Doug