IVOA and ADASS?

[Rob Seaman]

I support Roy's call for simplicity, but TimeSeries seems as simple as  
LightCurve to me.  VOEvent permits aggregating general purpose params,  
and so should the time series.  I don't believe this fact alone will  
complicate the new schema or its usage.

Also, Roy is right to aim for the simplest possible time framework  
here.  We are not looking to duplicate all of STC - and if some  
application does require arbitrarily complex time handling, a time  
series can be constructed from individual follow-up packets.  However,  
long established astronomical usage provides for expressing flavors of  
both topocentric and barycentric time scales.  We should be guided -  
here as elsewhere - by usage.  What is the minimum number of time  
scales required?  Start with that for v2.0.

For the specification the more basic question is whether a time series  
is to be expressed in a point-like or vector-like fashion.  That is,  
in particular, is each time series data point timestamped individually  
(and absolutely) - or rather, is a relative vector coupled with an  
overall absolute timestamp?  I tend to think (at the moment) that it  
should look something like [StartTime, deltaT1, deltaT2,  
deltaT3, ...]  For some applications, a heuristic for expressing an  
even grid would be better:  [Start, delta, 1, N].  In the spirit of  
Roy's comments, we should pick one and only one of these strategies.

Ah!  I see more messages arriving!

Rob
--
On Jul 2, 2008, at 11:37 AM, Joshua Bloom wrote:

> Roy-
>
>> Can I wave the flag of simplicity?
>>
>> (1) Any chance we can reduce the scope in the hopes of simplicity  
>> and efficiency? What I mean is to call it specifically "Light  
>> Curve" in place of the general "Time Series". The former we  
>> understand well (magnitudes and Janskys), but the latter could  
>> easily get out of control, and start to include time series of  
>> tensorial fiber bundle functors and things like that.
>>
>
> We could, but the need for extensibility of any standard we propose  
> would quickly necessitate expanding to a full-blown time-series.  
> E.g. people will want to be able to represent their bandpass  
> parameters as comprehensively as they know it and may balk with a  
> "you describe any color you want as long as its BVRIz". The way I  
> see VOTimeseries is as a restricted form of the spectral model, but  
> at it's heart a simple VOTable.
>
>> (2) On the matter of "time", can we also reduce scope? Can we agree  
>> on a single system like Julian Day? If we need to generalize to  
>> Ganymedian siderial time, then we are lost. (IMHO).
>
> I dont believe so.  There are SO many different systems which are  
> the most natural representation of time for the way in which the  
> data is taken. For simplicity, we could certainly require the use of  
> a truncated number (TJD instead of JD) but heliocentric,  
> topocentric, or geocentric should be accommodated from the get go.  
> If the goal is broad community acceptance, where people are putting  
> out their light curves in this form, then I think the standard needs  
> to be more open to multiple time representations --- you could  
> always restrict what an aggregating site emits for simplicity. But  
> true, Ganymedian siderial time can wait for version 2.0.
>>
> J
>