VOEvent priorities

[Rob Seaman]

Let me describe how this looks from the viewpoint of the chair.  While  
nobody values a robust discussion more than I do (anybody want to  
challenge that assertion?), engineering choices must be timely or they  
risk becoming moot.  This is the central message of VOEvent-based  
science, after all.

VOEvent is an IVOA standard, but the VOEvent community extends outside  
of the IVOA context.  The people reading this email are the most  
diverse of any IVOA WG - and yet we have found common ground where  
other WGs have not, and done so time-and-again.  It concerns me that  
some of our group have recently expressed private reservations about  
the - hmm, how shall I say? - lack of timeliness of the IVOA process  
in certain instances.

The goal in systems engineering is not to find the optimum solution -  
it is to find a satisfactory solution and then to actually implement  
it.  We should keep this goal of "satisficing" (yes, a real word) in  
mind throughout our discussions.  I might (and have, on occasion)  
recommend the same to other WGs.

VOEvent needs time series - which is to say that sufficient numbers of  
our diverse user base need time series.  (And those who don't, needn't  
use this v2.0 feature.)  A time series is a "thing" to be described  
and so belongs in <What>.  Native STC usage in VOEvent is limited to  
<WhereWhen> (where, for instance, orbital elements belong as targeting  
coordinates for future observations).  So time series *in VOEvent  
packets* will not use STC.  (And no, I don't see our combining  
VOEvent's dependent variables with its independent variables into one  
colossal <WhatWhereWhen> element.)

We will not embed the VOTable schema within the VOEvent schema, so  
time series *in VOEvent packets* will not use VOTable.  VOEvent can  
already reference external content including VOTables, but external  
references do not address the need to embed simple time series in  
transient alert packets.

On the other hand, the SimpleTimeSeries specification is satisfactory  
- and can be made even more so through some small tweaks.  The team  
that created SimpleTimeSeries has demonstrated that they are willing  
to make said tweaks.

Thus, our best approach to a usable solution is SimpleTimeSeries.  We  
undoubtedly passed by other potential solutions on the road from HTU-1  
to today.  There is no convincing argument to discard SimpleTimeSeries  
and turn around to pursue these now.

Now then, I thoroughly expect that the IVOA DAL group or some other WG  
will pursue a "ComplicatedTimeSeries" specification at some point.   
And perhaps in 3-5 years such a thing will exist - and perhaps it will  
be based on STC or VOTable or both.  This will not be timely for our  
purposes, and we have no way of knowing now whether the specification  
resulting from such a process will be useful for our purposes.  If it  
such a thing does add significant utility, then this can be supported  
as a feature of a future VOEvent update.

By all means, let's challenge SimpleTimeSeries with how it might  
support various VOEvent use cases.  We should use our efforts to  
improve the solution on the table, not to saw the legs out from under  
it.

Rob