Time series data in VOEvent

Frederic V. Hessman hessman at astro.physik.uni-goettingen.de
Tue Jun 12 02:24:58 PDT 2007


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/voevent/attachments/20070612/2e6e285f/attachment-0003.html>


More information about the voevent mailing list