VOEvent priorities

[Rob Seaman]

The artifice of any data structure is a trade-off between elegance and  
completeness.  Any of the IVOA "Simple" protocols have the option of  
simply omitting some feature deemed too inelegant.

In the case of VOEvent, the key design trade-off was in supporting  
generic params instead of attempting to construct a complete  
observation data model and using innumerable specific XML elements/ 
attributes.

Dick's comments are a good example of where we need to be focusing our  
attention.  Which features of time series should be simply omitted,  
and which can be addressed by (for instance) pointing to external  
complex content?

Rob
--

On Feb 3, 2010, at 2:11 PM, Dick Shaw wrote:

> Well, it's easy to think of astrophysically motivated examples of  
> timeseries that are more than simple lists of flux vs. time  
> coordinate: a time series of spectra of CVs, where multiple narrow  
> features (emission or absorption profiles) are the variable  
> phenomenon of interest, or a series of images showing a spatially  
> varying component within an extended object (aurorae over Jupiter,  
> or variability within a gaseous nebula), etc. Like Roy, I wonder how  
> these more complex representations of time-variable phenomena might  
> be represented, even if the Working Group is not yet ready to write  
> the specification. Or to put it another way, can we see how the  
> proposed specification might be generalized at some later time to  
> incorporate more complex data objects?
>
> Cheers,
> Dick
>
> On Wed, 03 Feb 2010 09:37:20 -0800
> Roy Williams <roy at cacr.caltech.edu> wrote:
>> Joshua Bloom wrote:
>>> The idea of timeseries is that it has a time axis. We should be  
>>> able to represent gravity chirp signals, sn light curves, pulsar  
>>> pulse shapes, etc. But it's certainly not a kitchen sink on  
>>> purpose. Those examples you propose don't pass the smell test of  
>>> being a time series.
>>>
>> Josh
>> I note that the web page about the proposed "simpleTimeSeries" (*)  
>> does not say how to represent any time series except for light  
>> curves in optical wavebands. In fact it says there: "The primary  
>> use for SimpleTimeseries ... is to exchange light-curve data ..."
>> So how other time series be represented in the proposed schema?  
>> Gravity chirp signals, list of image URLs, ephemeris, etc etc.  
>> Looks like  NOTE and DVAL can be combined (?) to allow general time  
>> series to be represented. I am not clever enough with schema to see  
>> what is really allowed.
>> Could I ask that either:
>> -- the web page include examples on representing time series that  
>> are not light curves?
>> Or
>> -- rename the schema to reflect its lesser scope, perhaps call it  
>> simpleLightCurve?
>> Cheers
>> Roy
>> (*) http://dotastro.org/simpletimeseries/
>> -- 
>> California Institute of Technology
>> 626 395 3670