[Fwd: Re: [nvo-techwg] Time series data]

[Roy Williams]

Dear Data Model Group

As some of you may know, there is a movement within the transient 
astronomy community to standardize a format for expressing time series 
data, in order to compare unknown brightness curves with a database of 
known brightnesses.

You may also know of the suspicion that many "regular astronomers" have 
for the IVOA and its standards. They think the standards are too complex 
and difficult and of course everyone prefers to make their own standards 
anyway.

My interest is, as always, to see success for the Virtual Observatory, 
and so I would like for VO standards to be used. To achieve this, I 
believe that a united front would be better than a competition.

THEREFORE my question is a simple one: How can a brightness curve be 
represented in the IVOA? There are two choices that I have heard:

(1) The STC model (see note below from Arnold)
(2) The Spectrum/Characterisation model.

Which one of these should we put forward as "the IVOA solution for time 
series"?

Roy





-------- Original Message --------
Subject: 	Re: [nvo-techwg] Time series data
Date: 	Tue, 26 Jun 2007 16:17:56 -0400 (EDT)
From: 	Arnold Rots <arots at head.cfa.harvard.edu>
Reply-To: 	Arnold Rots <arots at head.cfa.harvard.edu>
To: 	Arnold Rots <arots at head.cfa.harvard.edu>
CC: 	Rob Seaman <seaman at noao.edu>, Doug Tody <dtody at nrao.edu>, 
"voevent at ivoa.net VOEvent" <voevent at ivoa.net>, NVO Technical Working 
Group <techwg at us-vo.org>, Steve Allen <sla at ucolick.org>, 
jcm at head.cfa.harvard.edu



I put together an example that encodes the complete information from
IAUC 8653 in an STC-compatible WhereWhen - if only it would allow
multiple instances of ObsDataLocation (or, alternatively, multiple
instances of WhereWhen). There are three of them in this example:
1. The ASAS observations, providing time, position, and magnitude
2. The Roalnd observations, again time, position, and magnitude
3. The orbital elements for the parabolic orbit fit.


> > There's a lot of interest in VOEvent in seeing a practical time  
> > series format emerge soon.  Several other action items (e.g., XML  
> > signatures for authentication, and the representation of orbits) came  
> > out of the recent "Hotwired" workshop, confirming that VOEvent will  
> > continue to have a large cross-section with many other (I and N) VO  
> > standards and activities.
> > 
> > In this case, I wonder whether "spectrophotometric" only begins to  
> > cover the pertinence of time series for sky transient - and time  
> > domain, in general - alerts.  In addition to contribution from gamma  
> > rays to long wavelength radio waves, we had two talks on neutrino  
> > telescopes, several on classification schemes including ways to  
> > recognize signals embedded in sequences of temporally varying  
> > measurements of all types, coincidence testing, etc.  We take the  
> > meaning of the word "event" very liberally.
> > 
> > Pragmatically, the piratical individuals engaged in VOEvent and HTN  
> > related projects just want a time series standard that is  
> > utilitarian, simple, yet flexible.  They won't have infinite patience  
> > waiting for it to arrive, however.  To gauge both the completeness  
> > and elegance of an acceptable standard, the consensus would likely be  
> > that STC resides somewhere outside our comfort zone.  I doubt we  
> > could be motivated to accept such a complicated sub-schema again.
> > 
> > > It was mentioned that VizieR is a major resource for light curves
> > > so I had a look to get a better feel for current practice.  What we
> > > have now for SSA could probably already be used for light curves such
> > > as we see in VizieR, but there are two areas where it could stand
> > > improvement for this data.  The support for photometric systems could
> > > be better - but we need this for spectra and images as well.  This was
> > > a major topic of dicussion at the recent Spectroscopy in VO workshop
> > > in Madrid for example.
> > 
> > If this is an ongoing debate, I'd suggest that a VOEvent-friendly  
> > prototype would specify a small number of standard systems that could  
> > be expanded later.
> > 
> > > The second thing is that it would be good to
> > > be able to have multiple flux values (photometric systems or filters)
> > > associated with each time value, as time series data often measures
> > > the object in multiple standard filters/bandpasses/photometric systems
> > > for each time sample.
> > 
> > Yes.  Something like multiple <params> per time step.
> > 
> > > A final issue is segmentation, as large time
> > > series taken over a long period of time are often segmented, with
> > > big time caps between the segments.
> > 
> > Yes, although VOEvent's follow-up citations provide one way of doing  
> > this.
> > 
> > > All of these issues came up in connection with SSA and spectra as
> > > well, but they were second order features (for spectra) and lower
> > > priority for the first version of SSA, hence were deferred.  But with
> > > the completion of SSA and the Spectrum data model, Characterization,
> > > etc., we are probably 90% of the way there already.
> > 
> > I guess the question I have is whether that 90% is sufficient for a  
> > functional prototype.  Alternately, how long would the remaining 10%  
> > take to converge?  My sense of the debate at last week's workshop is  
> > that a VOEvent consensus on a 90% solution could be ready in a few  
> > week's, not months.  This seems much more aggressive than a similar  
> > consensus for SSA, especially as you are using words like "lower  
> > priority" and "deferred".
> > 
> > > In terms of the data interface, it appears that a SSA service could be
> > > trivially modified to support time series data.   The query interface
> > > would probably work as-is.  For simple light curves, CSV/TSV output
> > > would probably be popular, and is essentially what existing services
> > > such as VizieR return now.  HTML or JPEG for a direct graphical view
> > > is also popular, and VOTable would be ideal for serious analysis;
> > > again this is much the same as for simple 1-D spectra.
> > 
> > We're a publication format.  Some of the things you mention could be  
> > included as external references, but really we're just going to want  
> > to define some XML element to be embedded in our packets.  I would  
> > imagine these will include VOTable-like <params>.  If alternate  
> > representations are needed for purposes outside VOEvent, it seems to  
> > me we just need to ensure that our quasi-human readable packet format  
> > maps onto an underlying common time series data model.  In that case,  
> > I would suggest that the VOEvent time series use case should be  
> > straightforward enough that the broader VO time series DM could and  
> > should simply support this.
> > 
> > If the SED DM is mature enough to start scribbling possible explicit  
> > time series representations, VOEvent would be delighted to evaluate  
> > these and comment.  If not, we will be tendering a simple, packet  
> > oriented representation of our own for other groups to comment.  In  
> > either case, we will be seeking a VOEvent related consensus quickly.
> > 
> > Rob
----------------------------


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: IAUC8653.xml
URL: <http://www.ivoa.net/pipermail/dm/attachments/20070626/33293679/attachment-0001.ksh>