VOEvent priorities

[Matthew Graham]

Hi,

OK, my ideal concept of the VOEvent world does not have these  
temporally-oriented things (TOTs) explicitly in the VOEvent but  
referenced externally. This requires that VOEvent have a general  
referencing mechanism (tick), a concept scheme (controlled vocabulary)  
for stating what sort of resource is being referenced (this is a time  
series, this is a light curve, etc), and that the VO have a standard  
way of representing finding charts, frequency series, etc. as  
standalone resources. I don't believe that VOEvent should be a loose  
bag for explicitly stated associated data products to an event.

However, I acknowledge (magnanimously) that there are people who want  
to include simple TOTs such as light curves in the VOEvent and  
SimpleTimeSeries would seem to cater to this need.

VOTable allows for the inclusion of "simple" tables through the inline  
<TR><TD> representation and also has an external reference mechanism  
to larger/more complicated tables (binary, stream, etc). Could we not  
follow suit and support both Josh's SimpleTimeSeries for inline  
representations and my strongly-typed reference mechanism for external  
representations. We could also bring pressure to bear on the DM group  
to define standard serializations of the appropriate data models for  
various TOTs as a high priority.

	Cheers,

	Matthew

On Feb 3, 2010, at 1:55 PM, Alasdair Allan wrote:

> Dick,
>
>> Well, it's easy to think of astrophysically motivated examples of  
>> timeseries that are more than simple lists of flux vs. time  
>> coordinate...
>
> Yup, and that's pretty much why we've been stalled on this since the  
> first HTU meeting, despite all signing the napkin back in Tucson,  
> we've been talking about it for two years since then.
>
>> 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.
>
> Agreed, interesting. But possibly not a topic for this working  
> group. We're in need of a specific engineering solution to a stated  
> problem. That's including light curves (flux vs time) inside our  
> event packets.
>
>> 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?
>
> Perhaps a better topic for the DAL group.
>
> Al.