Fwd: Light curves in the IVOA

[Doug Tody]

Another point - The problem here is really time series, of which a
light curve is only one example.  Of course it is the most common
one, but in general time series analysis and time series data in an
archive can have anything on the Y axis.  The UCD can say what this
quantity is.  The same is true for spectra, and the model already
supports this.  (Hence for example SLiCAP is not the right name for
the general time series interface).

In some specific context such as a VOEvent it might be appropriate
to restrict the data to a simple light curve, however this is just
a matter of subsetting the model.

 	- Doug


On Tue, 22 Jun 2010, Douglas Tody wrote:

> Roy, all -
>
> Not surprisingly I support Raul's suggestion that a time series
> interface be based upon SSA and its underlying data model.  The 1D
> spectrum and time series cases are about 95% identical in terms of
> what is required for the DM and access protocol.  Similarly there
> are plans for a photometry interface to access filter data (Jesus
> and FB can say more about this), and we plan to support SEDs as well.
> All of these cases are quite similar, and we are already 90% of the
> way there.  It is extremely attactive to have consistency among all
> these interfaces, especially for services and data analysis packages
> which deal with more than one class of data.
>
> Roy - SSA is a much better basis for this than legacy SIA; SSA already
> has a powerful enough query interface and the data model is greatly
> enhanced and well aligned with time series data.
>
> Re nested GROUPs - this appears to be from an earlier version of the
> data model (hence the "sed:").  This is no longer used in SSA/Spectrum,
> which eliminates the complex and problematic nested GROUPs.
>
> Re time scale - this is already present in the current model
> (UTYPE = CoordSys.TimeFrame.Name, UCD = time.scale).  See for example
> Appendix D of the SSA specification.
>
> If we consider using SSA/Spectrum as the basis for time series data
> some improvements are likely to be needed.  Probably timeSeries
> wants its own distinct interface (SLiCAP or whatever), to allow some
> customization for this class of data.  We should look at other cases
> such as the work done in VOEvent, TSDS, etc. to see if any important
> things are missing.
>
> Some things already known to be needed:
>
>     o   Improved Photometry model: this is already being worked on by
>         e.g. ESAC and SAO.  It is needed for most of our use cases
>         and should be common.
>
>     o   For time series being able to have more than one flux value per
>         time sample is important.  However I think this can already be
>         done with the current representation, with few if any changes.
>
> Although the full query interface and data model may look complex,
> it can all be fairly simple in terms of typical usage, for example if
> a format such as CSV/TSV is selected by the user for output (a common
> use case).  Sophisticated analysis programs would use something else
> such as VOTable, FITS, or XML.  The same time series content could
> be represented in XML within a VOEvent as well.  This illustrates
> the importance of separating the data model from the representation.
>
> (I am doing a lot of travel currently so have limited time for these
> emails; apologies if I am slow to respond).
>
> 	- Doug
>
>
> On Mon, 21 Jun 2010, Roy Williams wrote:
>
>> 
>>
>>  -------- Original Message --------
>>  Subject: Re: Light curves in the IVOA
>>  Date: Wed, 16 Jun 2010 07:52:08 -0700
>>  From: Roy Williams <roy at cacr.caltech.edu>
>>  To: Raul Gutierrez Sanchez <raul at cab.inta-csic.es>
>>  CC: Doug Tody <dtody at aoc.nrao.edu>, Rob Seaman <seaman at noao.edu>
>>
>>  Raul
>>  I would like to start launching and interoperating light curve services,
>>  and what you have done is a most of the work that is needed, so I am very
>>  happy about your real live services!
>>
>>  Perhaps we can think about writing a real document about what a light
>>  curve service should look like? That way we can ensure that they real
>>  interoperate. I have a few small questions and concerns about what you
>>  have implemented, and I wonder if I could ask if there could be slight
>>  modifications to your services? Please find attached the two files
>>  (lightcurve-menu.xml and light-curve-instance.xml), where the first is a
>>  listing of links, and the second is a light curve.
>>
>>  (1) I see in both of the attached files that you have GROUP containing
>>  GROUP. This recursion in VOTable is something that is difficult for many
>>  parsers and code-binders, and I fought against it when it was introduced
>>  into the VOTable specification. Would it be possible to just delete GROUPS
>>  altogether, since the utype of the PARAMs already reveals its position in
>>  the hierarchy. The GROUPs seem like a lot of extra
>>  complication that adds no information!
>>        <GROUP utype="sed:Segment.Frame">
>>         <GROUP utype="sed:Segment.Frame.Sky">
>>            <PARAM utype="sed:Segment.Frame.Sky.Type" ??./>
>>
>>  (2) I see that time is represented by barycentric MJD as in the types
>>  and values below. I am not clear on the meaning of your MJD -- it is
>>  1300 days from which reference point? But I do not see much of the STC
>>  technology that has been crystallizing in the IVOA with the efforts of
>>  Demleitner (*). Do you think it would be possible to modify your service
>>  to report something more like that?
>> 
>> sed: Segment.Frame.Sky.Equinox value="2000.0"
>> sed: Segment.Frame.Time.Type value="MJD"
>> sed: Segment.Frame.Time.RefPos value="BARYCENTRIC"
>> sed: Segment.Coverage.Location.Time.Value value="1305.88"
>> sed: Segment.Coverage.Region.Time.Start value="1305.87"
>> sed: Segment.Coverage.Region.Time.End" value="1305.89"
>>
>>  (*) http://www.ivoa.net/Documents/latest/VOTableSTC.html
>> 
>>
>>  (3) I see that some of your data values have "99.0" for the flux value,
>>  which obviously means missing data. But is there any way in the SSAP or
>>  VOTable specification to say in the metadata "whenever you see 99.0 it
>>  means missing data".
>>
>>  Thank you
>>  Roy Williams
>> 
>> 
>