Time series data in VOEvent

[Frederic V. Hessman]

If data is included directly or indirectly in the VOEvent (so that  
anyone can judge for themselves what the event looks like and what is  
needed), then the only long-term solution is to provide it as a VOTable:

<?xml version="1.0"?>
<VOTABLE version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema- 
instance"
  xsi:noNamespaceSchemaLocation="http://www.ivoa.net/xml/VOTable/ 
VOTable/v1.1">
   <RESOURCE name="Raptor Alert Data">
     <TABLE name="GRB123456">
       <DESCRIPTION>Raptor B light curve</DESCRIPTION>
       <FIELD name="HJD"   ID="col1" ucd="time"                 
datatype="float" width="12" precision="4" unit="days"/>
       <FIELD name="I"     ID="col2" ucd="phot.mag"             
datatype="float" width="5"  precision="2" unit="magnitudes"/>
       <FIELD name="I-err" ID="col3" ucd="phot.mag;stat.error"  
datatype="float" width="5"  precision="2" unit="magnitudes"/>
       <DATA>
         <TABLEDATA>
         <TR><TD>2451234.5678</TD><TD>18.27</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5679</TD><TD>18.28</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5680</TD><TD>18.29</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5681</TD><TD>18.30</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5682</TD><TD>18.31</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5683</TD><TD>18.32</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5684</TD><TD>18.33</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5685</TD><TD>18.34</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5686</TD><TD>18.35</TD><TD>00.05</TD></TR>
         <TR><TD>2451234.5687</TD><TD>18.36</TD><TD>00.05</TD></TR>
         </TABLEDATA>
       </DATA>
     </TABLE>
   </RESOURCE>
</VOTABLE>

either as an included document (fragment?) or as a link.  Time-series  
data is a relatively simple case (time-resolved spectroscopy would be  
trickier), so why bother worrying about more than this?  From a  
formal point of view, one could include the parts of the VOTable  
schema in VOEvent as a VOEvent <TABLE> element (so one can treat the  
table as a trivial fragment which one could even stick in the  
<VOEvent> document).

Unfortuately, UCD1+ doesn't (yet) have "time.julian" or  
"heliocentric" atoms but this and more could be available soon in the  
"Standard Vocabulary" which one will be able to use in the ucd=""  
attributes with good conscience.  The same thing goes for the  
identification of the filter, so one will have something fairly  
obvious, unambiguous, and computer-parseable like

       <FIELD name="HJD" ID="col1"  
ucd="time.julian;location.heliocentric" datatype="float" width="12"  
precision="4" unit="days"/>
       <FIELD name="brightness" ID="col2"  
ucd="phot.mag;device.filter.Johnson-type.I" datatype="float"  
width="5"  precision="2" unit="magn"/>
       <FIELD name="error" ID="col3"  
ucd="phot.mag;stat.error;device.filter.Johnson-type.I"  
datatype="float" width="5"  precision="2" unit="magn"/>

The conversion from local to HJD is trivial for the publisher and  
takes care of most timing questions.

Rick


On 11 Jun 2007, at 6:16 pm, Doug Tody wrote:

> Hi Rob (and all you VOEvent guys) -
>
> Can you say a bit more please about the VOEvent/HTN use-case where
> time series data is concerned.
>
> I gather you want to embed a time series observation directly within a
> VOEvent packet - is this the case?  If so why - is such an observation
> taken in real time when the event is detected?  If so, is this sort
> of thing limited to time series, or could other forms of data be of
> interest as well?
>
> I should think another related use-case would be to follow up on
> a VOEvent by issuing a query to an unrelated data service to find
> time series or other data of interest on the object pointed to by
> the VOEvent.  If so, a common solution might be desirable.
>
> While up to a point one might want to integrate some observational
> data directly into the VOEvent, eventually use-cases such as these
> are likely to become complex enough that it will be desirable to
> encapsulate the object instances so that they can be manipulated by
> reusable code that knows nothing about VOEvent.  In short I think
> there may be an architectural question here which needs more thought,
> before deciding upon the best way to approach this.
>
> 	- Doug
>
>
> On Sun, 10 Jun 2007, Rob Seaman wrote:
>
>> Hi Doug, etc.,
>>
>>> The issue of time series data came up briefly in the NVO telecon  
>>> today.
>>> Since all the attention has been focused on spectra little has been
>>> done about this yet, although the Spectrum/SED data model upon which
>>> SSA is based was always intended to be general enough to support  
>>> time
>>> series data as well.  Both are spectrophotometric sequences, with
>>> the spectral coordinate varying in one case, and time in the other.
>>
>> 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
>>

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman     Hessman at Astro.physik.Uni-Goettingen.DE
Institut für Astrophysik          Tel.  +49-551-39-5052
Friedrich-Hund-Platz 1         Fax +49-551-39-5043
37077 Goettingen                 Room F04-133
http://www.Astro.physik.Uni-Goettingen.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
------------------------------------------------------------------------ 
-------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20070612/2e6e285f/attachment-0003.html>