Fwd: Light curves in the IVOA

[Douglas Tody]

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
>
>