Hot Wiring the Transient Universe

Infrastructure for rapid-response astronomy
edited by
Roy Williams Sarah Emery Bunn Rob Seaman

A compendium from a writing team founded at the workshop "Hot-wiring the Transient Universe 2" in Santa Cruz, California, April 2009
http://hotwireduniverse.org

The collection Copyright © 2010 by Roy Williams, Sarah Emery Bunn, and Rob Seaman The individual sections Copyright © the Contributors
Cover design by Pete Marenfeld
All rights reserved.
Printed in the United States of America.
First Printing: October 2010
Full text available athttp://hotwireduniverse.org
Preface

Orbiting satellites and giant astronomical surveys are monitoring much of the sky regularly, detecting vast numbers of variable astronomical objects, some with exciting and energetic astrophysics such as blazar eruptions, cataclysmic variables and supernovae; and some much closer, perhaps discovery of a potentially Earth-impacting asteroid.

A VOEvent is a message about an astronomical event: a change in brightness or position in the sky. The message can be sent to other observers for follow-up observations, or it can be added to other data about the event to aid understanding. It is the follow-on to the successful GCN (Gamma-ray Coordinates Network), and provides a structured, machine-readable alternative to the Astronomer's Telegram and IAU Telegrams.

Many existing and future surveys are using VOEvent for rapid event notifications, including CRTS, GCN (Fermi and SWIFT), LIGO, LOFAR, LSST, MOA, OGLE, PTF and SVOM. This book explores transient surveys and classification, what VOEvents mean and how to build them, the rich structure of the VOEvent 2.0 standard, working with the Virtual Observatory infrastructure, and ideas on an interoperable transport network. The book is organized first with discussions of time-domain astronomy, and why both interoperability and rapid response are valuable; the VOEvent standard itself is discussed; then Chapter 3 is about available software that can handle events. The last chapter is about the interaction of VOEvent with the Virtual Observatory, that can knit the system together with global discovery and democratic access.

Roy Williams, Sarah Emery Bunn, and Rob Seaman, editors.
Acknowledgements:
This work has been supported by the National Science Foundation, grants AST-0122449 and OCI0915473.
The editors thank the authors: Joshua Bloom, John Brewer, Robert Denny, George Djorgovski, Ciro Donalek, Matthew Graham, Rick Hessman, Lynne Jones, Ashish Mahabal, Norman Gray, Bruce Truax, Tom Vestrand. The editors thank Los Alamos National Laboratory and the University of California, Santa Cruz.
Table of Contents
Introduction .......................................................................................... 6 W. Thomas Vestrand
1   Time Domain Astronomy............................................................ 7   1.1   Large Synoptic Surveys ....................................................................8
Lynne Jones
1.2   Handling the Event Deluge ..........................................................16
Roy Williams
1.3   The Meaning of Events .................................................................22 Ashish Mahabal, S.G. Djorgovski, Ciro Donalek
2   About VOEvent .......................................................................... 32   2.1   What is VOEvent?..........................................................................33 Rob Seaman
2.2   Extending VOEvent for more complex data.............................38 Roy Williams, Matthew Graham
2.3 Time Series in VOEvents..................................................................45 John M. Brewer, Joshua S. Bloom
3   Software for VOEvents.............................................................. 50   3.1   Event Handling with SkyAlert......................................................51 Roy Williams
3.2   Python code-binding for VOEvent .............................................58 Roy Williams
3.3   An iPhone App for Transient Events .........................................60 Bruce Truax
3.4   Understanding and Using the VOEvent Network....................73 Robert B. Denny
4   Events and the Virtual Observatory......................................... 77   4.1   Querying events with Simple Event Access Protocol...............78 Matthew Graham
4.2   Finding VOEvent resources .........................................................83 Matthew Graham and Roy Williams
4.3   Vocabularies and Semantics for VOEvent.................................87 Frederic V. Hessman and Norman Gray
5   Appendices ................................................................................... 97   5.1   VOEvent Specification ..................................................................98 Rob Seaman, Roy Williams and 10 others
5.2   Simple Event Access Protocol (SEAP) Version 0.5 .............. 121 Matthew Graham and 7 others
5.3   A Proposal for Digital Signatures in VOEvent Messages..... 134 Robert B. Denny
Introduction

W. Thomas Vestrand
Los Alamos National Laboratory
The nature of observational science, and astronomy in particular, is being transformed (as is so much of modern life) by the assimilation of new information technology. A central theme throughout the history of astronomy has been the mapping of the Universe to greater and greater distances and, in the last half century, over broader and broader ranges of the electromagnetic spectrum. As we have conducted more comprehensive surveys, it has become clear that there are rapid changes in the distant Universe with durations measured in days or even seconds, and that those ephemeral changes provide important clues about the nature and evolution of our Universe. One spectacular example was the discovery of a flash of light, associated with a gamma-ray burst at a distance of 7.5 Billion light years (z=0.94), that for 5 seconds was bright enough to be visible to the naked eye. However, that flash—the most luminous ever recorded by humankind—was not discovered by a human observer. The discovery and initial real-time follow-up of this cosmic explosion, which marked the collapse of one of the very first massive stars in the Universe and announced the formation of a black hole, was conducted entirely by autonomous robotic instruments communicating through the internet.

The scientific potential of this Time Domain Astronomy has placed it high in US astronomical community priorities for the next decade and helped give the Large Synoptic Survey Telescope (LSST) the top ranking for new ground-based programs. But the key unsolved problem for exploring fast astrophysical transients in a variability survey with the scope of LSST is mining the torrent of data— which for LSST will be something like a 3.2 Giga-pixel image every 10 seconds—to recognize important variations in a scene full of normal variations and command follow-up observations in real time. With its predicted discovery of thousands of transients every night, the LSST threatens to drown us in a “flood of data”, conduct denial of service attacks on our robotic follow-up telescopes, and in the end leave us thirsty for knowledge. For fast transients this challenge is particularly acute because humans do not have the attention span, memory, or reaction time required to monitor the huge volumes of data, recognize the important variations, and promptly command follow-up observations.

Mastering the challenges that massive variability surveys like the LSST project pose for rapid-response astronomy requires the development of new infrastructure. The VOEvent communication standards are an important foundation block of the new infrastructure. Meetings that enabled VOEvent development also helped foster discussion and ideas about how the next generation infrastructure could be built using machine learning, event brokers, and other new information technology techniques. This book came to be as a response to the need to both document and disseminate some of the evolving standards and to articulate some of those new ideas.

1 Time Domain Astronomy

The first section of this chapter is centered on the biggest time-domain survey of them all, the LSST (Large Synoptic Survey Telescope), about the design and cadence of synoptic surveys. The second section is about the ‘event deluge’ – how to manage the flood of astronomical events that will be coming. The third section covers classification and characterization of transient events, especially in the timelimited case where rapid follow-up may be necessary for full understanding.
Photo credit Flickr/SoNewFangled
1.1 Large Synoptic Surveys

Lynne Jones
University of Washington
What is a “large synoptic survey”? While exact definitions of what makes a survey “synoptic” differ, the general characteristics of “large synoptic surveys” include: a sky sampling rate that is sensitive to astronomical phenomena that change over time, a large amount of sky coverage to provide a statistically significant sample of those phenomena, and data processing that can expose the transient or variable nature of the astronomical objects within the survey. Generally, these surveys are also intended to provide data on a wide variety of objects, leveraging the wide sky coverage and time sampling of the survey to serve many science goals.

The precise science goals of a particular survey depend on the scientific questions the survey planners wish to address. What is required are observations sensitive to time-varying phenomena - typically the variability is in the brightness of the object being studied but the position or color of the object could vary instead or as well. In theory, a record of the entire sky with very fine time resolution, high sensitivity (faint limiting magnitude), excellent astrometric and photometric accuracy, and multi-wavelength observations would yield enough data to characterize and study in-depth every kind of transient and variable object, requiring no or very few limits on these scientific goals. In practice, the goals of the survey have to be balanced with the resources available, with limitations on sky coverage, observational cadence (time resolution), sensitivity, wavelength coverage, and (to a lesser extent) accuracy and data processing capability.

How to achieve this balance and connect goals with observing strategy? This, of course, is a tough question with more than one potential answer. The final goal of the survey should be to provide a statistically significant sample (or samples) of the kind of object (or objects) of interest to the survey planners, with well-understood selection biases and completeness functions, and with as much data as necessary or possible for characterizing each individual member of each population, so that the underlying science question (or questions!) can be answered (e.g. “What does the orbital distribution of Trans-Neptunian objects (TNOs) imply about the evolution of the Solar System” “How do the distance and redshift distributions of Type Ia SN constrain models of the expansion of the universe?”).

Achieving a statistically significant sample to address a particular problem implies that there is a number of target objects of a particular nature (whether this is at a particular redshift or spatial position or metallicity or just of a general classification) that must be discovered. As a first step, the luminosity function or number density function combined with an expected magnitude and distance distribution gives an estimate of the number of target objects which can be expected in a given area of sky coverage to a particular sensitivity limit (limiting magnitude).

Generally speaking, for a given telescope system there are tradeoffs between sky coverage and limiting magnitude: in a given total amount of time, either fewer fields can be observed with longer exposure times (and thus fainter limiting magnitudes), or more fields can be observed with shorter exposure times (and thus brighter limiting magnitudes). There are, however, some limitations: exposure times should not get much shorter than the readout plus slew/settle time of the telescope to avoid inefficient observing and should not be longer than the timescale of variability of the target object to maximize sensitivity to that variability. Within this envelope, there will usually be a range of acceptable exposure times, where the final trade between sky coverage and limiting magnitude will be set by the requirements of the science case. For example, if target sample size is most important and the luminosity function increases quickly with limiting magnitude, longer exposure times will be desirable (this is illustrated in Figure 1). If on the other hand, sensitivity to changes in the target distribution with location are important, greater sky coverage will be most desirable. It is possible to improve the final sample size result by going to a telescope system with a larger field of view or higher sensitivity due to a larger diameter primary mirror, a higher system throughput (due to better optical components, a more sensitive detector, or smaller atmospheric absorption) or a better point-spread function (better seeing), but the basic tradeoff is still present.

Figure 1: For a survey with a given total time span and throughput, there are tradeoffs between limiting magnitude in a given exposure and total survey area (see the black dashed line), that are parameterized by the exposure time. For a particular limiting magnitude and sky coverage (at a particular exposure time), the resulting sample size can be calculated. The sample size as a function of exposure time (indicated by the vertical dotted lines) for populations with power law luminosity functions of various alpha indexes (LF proportional to 10^alpha) are illustrated. Steep luminosity functions (1.0 line) produce larger sample sizes when less sky is covered to a fainter limiting magnitude; shallow luminosity functions (0.1 line) do better with a shorter exposure time and more sky coverage.

For transient and variable objects there is an additional complication to estimating the resulting sample size, which is the frequency, timescale and amplitude of the target object’s variability. This variability must be detected to identify an object as a member of the target sample. The frequency of variability can be included into the estimated sample size at least roughly by just multiplying by the expected rate or duty cycle times the total survey lifetime. The effects of the timescale of variability are trickier, as there are vastly different time periods available for detecting different kinds of variable or transient objects. The optical counterparts of gamma ray bursts brighten quickly within minutes to hours then fade over hours to days, while supernovae brighten over a period of hours to days and then fade over a period of tens to hundreds of days; neither of these events repeat. M-dwarf flares occur and disappear within minutes but recur often although unpredictably, while periodic variables may vary on a timescale between hours to days but repeat on a definite schedule, making it possible to phase observations from different periods back together. Other objects display primarily astrometric variability rather than photometric variability objects in our solar system display motions visible on timescales between seconds to hours (which may also carry them out of the survey area if the sky coverage is not large enough) while stars display parallax and proper motion changes which may only be visible on timescales of years. To detect any of these kinds of variability, multiple observations of the same object have to take place within the timescale of variability and often with a particular cadence within that timescale.

The photometric and astrometric accuracy of the survey also influence how often observations must take place in order to detect variability, as does the amplitude of the variability itself. Higher signal to noise measurements of the variability (due either to greater accuracy in the measurement or larger variability) mean that fewer observations are necessary before the variability can be detected and identified. In practice, accuracy is typically dominated by the effects of the limiting magnitude of the system itself and the amplitude and timescale of variability are determined by the target objects themselves. The major survey planning decision, especially for large synoptic surveys with multiple science goals, is how to reconcile the observing cadence required by each science goal with maintaining the required sample sizes, when sky coverage or exposure time (and thus limiting magnitude) must be reduced to allow time for multiple observations of the same targets.

However, there is yet another twist - how to identify the target objects of interest among the background of millions of other potential variable or transient objects? The observations described above are the minimum requirement to detect objects which are consistent with being members of the target population, but this results in a pool of candidates contaminated with other variables or transients. Reducing that contamination requires additional observational data either to determine the full shape of the transient or variable lightcurve, or to determine the velocity and acceleration vectors of a solar system object, or to determine the spectral energy distribution of the object through observations at multiple wavelengths or in multiple filters. For example, accurate identification of Type Ia supernova from their light curves requires multi-color observations of each potential SN separated by a few days, while identification of a fast-moving Near Earth Object (NEO) requires at least two observations, preferably in the same filter, with a separation of 30 minutes to an hour and repeated over several days within a period of 15 to 30 days, during which time the NEO has crossed a large portion of sky - requiring large sky coverage as well as frequent observations. The process of winnowing out the contaminants and identifying the true members of the target sample is the heart of “classification”, which is described in more detail in section 1.3, but a primary requirement will always be “more data”.

Luckily the required additional observations can come from many places. Often, and particularly for large synoptic surveys, it is most practical to generate at least some of these followup observations within the survey itself, translating to further balancing of survey time between sky coverage, limiting magnitude, and repeat observations of the same fields. For a target sample which is very numerous, with a high contamination rate but some potentially distinguishing characteristic (such as color or a lightcurve which is distinctive with additional data points), obtaining additional observations within the survey itself will likely be the most efficient method of reducing contamination and obtaining a better sample. Still, this is not always practical or even possible. Some kinds of objects are only identifiable with observations at wavelengths other than those achievable at the survey telescope, while others may need so many observations or different kinds of observations (such as spectra) that the survey telescope would be too far diverted from its primary purpose. In these cases, it is better to generate the followup data at other telescopes. Much of the rest of this book is devoted to the nuts and bolts of how to request this followup data through VOEvents and the process of communicating this information through the network of telescopes and observers available to obtain these additional observations.

A final consideration when planning a synoptic survey is how to process the data to detect the target objects in the survey. Briefly summarized, methods for detection of variables or transients boil down to generating a catalog of objects which are ‘different’ (in brightness or position) in an image acquired from the survey telescope from what is expected for that region of sky. One common method is to create a ‘template image’ from a series of images previously obtained of the same field, match this template to the image from the telescope being searched for variables or transients, and then to subtract the two to create a difference image. The matching process must include matching the point-spread function of the template and science image, as well as aligning their coordinate systems. Source detection algorithms are then run on the difference image to look for objects which varied in brightness or position between the template and science image. Another common method is to create calibrated catalogs from each image directly, match objects from the catalogs created from each image with the same objects from the other catalogs using spatial correlations, and again look for things which vary in brightness or position. Each method has its advantages and disadvantages, among which are: difference imaging is typically more computationally expensive but does well at removing extended non-variable objects such as galaxies, can detect variability in non-stellar profiles, and can perform better in crowded fields, while catalog searches require more accurate calibration but do not require template images and can be used to search for variability in data from different telescopes. For further discussion of difference imaging techniques, see [1], [7]. For a few examples of catalog searches, see [25], [8], [5] and [27]. A direct comparison of a catalog search for variability versus difference imaging for OGLE-II can be found in [30]. Generally, good results can be obtained as long as there is a match between the method’s strengths and the science goals.

How does this all work in reality? There are many examples of synoptic surveys over the past few decades; a few are mentioned here. Due to hardware limitations (smaller telescopes, smaller fields of view), most past surveys have focused on one primary science goal. Still, the data from many of these projects has been adopted to search for many other kinds of variable or transient objects. Three surveys which were originally designed to search for potentially hazardous NEOs - the Lowell Observatory Near Earth Object Survey (LONEOS)[6], the Near-Earth Asteroid Tracking (NEAT) survey [22] and the Catalina Sky Survey (CSS)[17] - have (respectively) been used to discover RR Lyrae [20], joined in collaboration with the Palomar-Quest survey [10] to provide supernova candidates for the Nearby Supernova Factory [2], and serve as the source of data searched for all kinds of variability in the Catalina Real-Time Transient Survey (CRTS) [11].

Most of the observations of the Sloan Digital Sky Survey (SDSS) Stripe 82 were obtained primarily for a supernovae search [12], but Stripe 82 has provided a wealth of information about transients and variables of many kinds - see [5] and references therein. OGLE was designed to find microlensing events [28], but it and its successors OGLE-II and OGLE-III have found a similar multi-purpose success [29] from Cepheids [26] to transiting planets [4]. Other surveys originally designed to search for non-variable phenomena such as weak lensing at very faint limiting magnitudes have also been used to search for variable or transient objects - the Deep Lens Survey (DLS) [3] and the Subaru/XMM-Newton Deep Field (SXDF) [21] have both been searched for a wide range of variable and transient objects.

It is interesting to see the progression that has occurred, from searching for a particular target population (such as Type Ia SNe or Near Earth Objects or Trans-Neptunian Objects) to searching for a wide variety of objects. Current or imminent synoptic surveys, such as the Palomar Transient Factory [18], [23], Skymapper [16] and PanStarrs1 (PS) [9], and significantly larger future synoptic surveys, such as PanStarrs-4 and the Large Synoptic Survey Telescope (LSST) [15], [19], will be searching for all kinds of known transients and variables, as well as previously unknown objects where the requirements for understanding these ‘unknown unknowns’ are still developing.

Balancing the requirements for detecting and identifying a wide range of transients and variables is challenging, but these surveys are planning to meet the challenge with multi-color observations (typically some or all of u, g, r, i, z and y filters) over large portions of the sky (approximately 20,000 square degrees). Very large fields of view (7-10 square degrees) will allow these surveys to cover the sky on a rapid observational cadence; while the base plan is to cover all of the visible sky every few days (for LSST) or subsets of the visible sky every few days (PS4), it is likely that an entire range of revisit times between a few hours to several days may be explored for greater sensitivity to variability at a wider range of timescales. Data processing will be intensive - difference imaging will be used to detect transients and variables, and then software pipelines will run to identify moving objects, linking their detections into orbits. Accurate calibration of photometry and astrometry on a global reference scale requires more processing. LSST will send out public VOEvents describing the millions of transient and variable detections each night. Huge databases (upwards of 12 PB for LSST at the end of its 10 year survey) of objects and all of their detections will be created and available for queries. Users will be able to use this database to identify and classify the target samples of interest to them, as well as access the VOEvent stream to get real-time updates on targets.

These large synoptic surveys will open a whole new scientific window into the time-domain for astronomy, giving us the next evolutionary step and moving us fully into the ‘action movie’ of the universe.
References
[1] Alard, C. (2000). Image subtraction using a space-varying kernel. A&AS, 144:363–370. Alard, C. and Lupton, R. H. (1998). A Method for Optimal Image Subtraction. ApJ, 503:325–+.
[2] Aldering, G., et. al., (2002). Overview of the Nearby Supernova Factory. In J. A. Tyson & S. Wolff, editor, Society of Photo-Optical Instrumentation Engineers (SPIE) Conference Series, volume 4836 of Presented at the Society of Photo-Optical Instrumentation Engineers (SPIE) Conference, pages 61–72.

[3] Becker, A. C., Wittman, D. M., Boeshaar, P. C., Clocchiatti, A., Dell’Antonio, I. P., Frail, D. A., Halpern, J., Margoniner, V. E., Norman, D., Tyson, J. A., and Schommer, R. A. (2004). The Deep Lens Survey Transient Search. I. Short Timescale and Astrometric Variability. ApJ, 611:418–433.
[4] Bennett, D. P., et. al,. (2010). Masses and Orbital Constraints for the OGLE-2006-BLG-109Lb,c Jupiter/Saturn Analog Planetary System. ApJ, 713:837–855.
[5] Bhatti, W. A., Richmond, M. W., Ford, H. C., and Petro, L. D. (2010). Variable Point Sources in Sloan Digital Sky Survey Stripe 82. I. Project Description and Initial Catalog (0 hr ≤α≤ 4 hr). ApJS, 186:233–258.

[6] Bowell, E., Koehn, B. W., Howell, S. B., Hoffman, M., and Muinonen, K. (1995). The Lowell Observatory Near-Earth-Object Search: A Progress Report. In Bulletin of the American Astronomical Society, volume 27 of Bulletin of the American Astronomical Society, pages 1057–+.
[7] Bramich, D. M. (2008). A new algorithm for difference image analysis. MNRAS, 386:L77–L81.
[8] Bramich, D. M., Vidrih, S., Wyrzykowski, L., Munn, J. A., Lin, H., Evans, N. W., Smith, M. C., Belokurov, V., Gilmore, G., Zucker, D. B., Hewett, P. C., Watkins, L. L., Faria, D. C., Fellhauer, M., Miknaitis, G., Bizyaev, D., Ivezi "c, Zˇ., Schneider, D. P., Snedden, S. A., Malanushenko, E., Malanushenko, V., and Pan, K. (2008). Light and motion in SDSS Stripe 82: the catalogues. MNRAS, 386:887–902.

[9] Chambers, K. C. and Pan-STARRS (2004). PS1 - The Prototype Pan-STARRS Telescope. In Bulletin of the American Astronomical Society, volume 36 of Bulletin of the American Astronomical Society, pages 1400–+.

[10] Djorgovski, S. G., Baltay, C., Mahabal, A., Rabinowitz, D., Drake, A., Donalek, C., Glikman, E., Graham, M., Williams, R., Ellman, N., Scalzo, R., Bauer, A., Nugent, P., and PQ Survey Team (2009). The Palomar-Quest Digital Synoptic Sky Survey: Summary and Initial Results. In American Astronomical Society Meeting Abstracts, volume 214 of American Astronomical Society Meeting Abstracts, pages 407.10–+.

[11] Drake, A. J., Djorgovski, S. G., Mahabal, A., Beshore, E., Larson, S., Graham, M. J., Williams, R., Christensen, E., Catelan, M., Boattini, A., Gibbs, A., Hill, R., and Kowalski, R. (2009). First Results from the Catalina Real-Time Transient Survey. ApJ, 696:870–884.
[12] Frieman, J. A., et. al, (2008) The Sloan Digital Sky Survey-II Supernova Survey: Technical Summary, Astron.J. 135:338-347
[13] Mendez, J., et. al (2008). The Sloan Digital Sky Survey-II Supernova Survey: Technical Summary. AJ, 135:338–347.
[14] Huber, M. E., Everett, M. E., and Howell, S. B. (2006). Color and Variability Characteristics of Point Sources in the Faint Sky Variability Survey. AJ, 132:633–649.
[15] Ivezic, Z., Tyson, J. A., Allsman, R., Andrew, J., Angel, R., and for the LSST Collaboration (2008). LSST: from Science Drivers to Reference Design and Anticipated Data Products. ArXiv e-prints.
[16] Keller, S. C., Schmidt, B. P., Bessell, M. S., Conroy, P. G., Francis, P., Granlund, A., Kowald, E., Oates, A. P., Martin-Jones, T., Preston, T., Tisserand, P., Vaccarella, A., and Waterson, M. F. (2007). The SkyMapper Telescope and The Southern Sky Survey. Publications of the Astronomical Society of Australia, 24:1–12.

[17] Larson, S., Beshore, E., Hill, R., Christensen, E., McLean, D., Kolar, S., McNaught, R., and Garradd, G. (2003). The CSS and SSS NEO surveys. In Bulletin of the American Astronomical Society, volume 35 of Bulletin of the American Astronomical Society, pages 982–+.
[18] Law, N. M., et. al, (2009). The Palomar Transient Factory: System Overview, Performance, and First Results. PASP, 121:1395–1408.
[19] LSST Science Collaborations, Abell, P. A., Allison, J., Anderson, S. F., Andrew, J. R., Angel, J. R. P., Armus, L., Arnett, D., Asztalos, S. J., Axelrod, T. S., and et al. (2009). LSST Science Book, Version 2.0. ArXiv e-prints.

[20] Miceli, A., Rest, A., Stubbs, C. W., Hawley, S. L., Cook, K. H., Magnier, E. A., Krisciunas, K., Bowell, E., and Koehn, B. (2008). Evidence for Distinct Components of the Galactic Stellar Halo from 838 RR Lyrae Stars Discovered in the LONEOS-I Survey. ApJ, 678:865–887.

[21] Morokuma, T., Doi, M., Yasuda, N., Akiyama, M., Sekiguchi, K., Furusawa, H., Ueda, Y., Totani, T., Oda, T., Nagao, T., Kashikawa, N., Murayama, T., Ouchi, M., Watson, M. G., Richmond, M. W., Lidman, C., Perlmutter, S., Spadafora, A. L., Aldering, G., Wang, L., Hook, I. M., and Knop, R. A. (2008). The Subaru/XMM-Newton Deep Survey (SXDS). V. Optically Faint Variable Object Survey. ApJ, 676:163–183.

[22] Pravdo, S. H., Rabinowitz, D. L., Helin, E. F., Lawrence, K. J., Bambery, R. J., Clark, C. C., Groom, S. L., Levin, S., Lorre, J., Shaklan, S. B., Kervin, P., Africano, J. A., Sydney, P., and Soohoo, V. (1999). The Near-Earth Asteroid Tracking (NEAT) Program: an Automated System for Telescope Control, Wide-Field Imaging, and Object Detection. AJ, 117:1616–1633.

[23] Rau, A., Kulkarni, S. R., Law, N. M., Bloom, J. S., Ciardi, D., Djorgovski, G. S., Fox, D. B., Gal-Yam, A., Grillmair, C. C., Kasliwal, M. M., Nugent, P. E., Ofek, E. O., Quimby, R. M., Reach, W. T., Shara, M., Bildsten, L., Cenko, S. B., Drake, A. J., Filippenko, A. V., Helfand, D. J., Helou, G., Howell, D. A., Poznanski, D., and
[24] Sullivan, M. (2009). Exploring the Optical Transient Sky with the Palomar Transient Factory. PASP, 121:1334–1351.
[25] Sesar, B., et. al. (2007). Exploring the Variable Sky with the Sloan Digital Sky Survey. AJ, 134:2236– 2251.
[26] Soszynski, I., Poleski, R., Udalski, A., Szyman #ski, M. K., Kubiak, M., Pietrzynski, G., Wyrzykowski, L., Szewczyk, O., and Ulaczyk, K. (2010). The Optical Gravitational Lensing Experiment. The OGLE-III Catalog of Variable Stars. VII. Classical Cepheids in the Small Magellanic Cloud. Acta Astronomica, 60:17–39.
[27] Telezhinsky, I., Eckert, D., Savchenko, V., Neronov, A., Produit, N., and Courvoisier, T. (2010). The catalog of variable sources detected by INTEGRAL I: Catalog and Techniques. ArXiv e-prints. [28] Udalski, A., Szymanski, M., Kaluzny, J., Kubiak, M., and Mateo, M. (1992). The Optical Gravitational Lensing Experiment. Acta Astronomica, 42:253–284.
[29] Udalski, A., Szymanski, M. K., Soszynski, I., and Poleski, R. (2008). The Optical Gravitational Lensing Experiment. Final Reductions of the OGLE-III Data. Acta Astronomica, 58:69–87. [30] Wozniak, P. (2008). Crowded Field Photometry and Difference Imaging. In Manchester Microlensing Conference.
1.2 Handling the Event Deluge
Roy Williams
California Institute of Technology
We consider how event handling will change as the discovery rates scale up in the future. We summarize here the different types of data that can help to resolve the nature of an astronomical transient, direct its dissemination, and prioritize the follow-up response.
The Coming Flood
More than ten years ago, the gamma-ray burst (GRB) community ignited the excitement over transient astronomical events. GRBs were an enigma until ultra-fast event dissemination allowed optical identification of afterglows, leading to rich data and rich science. The events back then were both valuable and infrequent: every new GRB could make a career for a young astronomer, and they were only detected every few days. However, in the next few years, surveys [1] such as LOFAR, Pan-STARRS, LSST and SKA will produce a flood of hundreds of events every 24 hours, with the scientific jewels surrounded by dross. By analogy, a hundred years ago, the daily newspaper provided a low-rate, highvalue summary of the world, but now there is such a flood of “news” information that we must be very selective in what we read. In this article we suggest some ways to build this selectivity for astronomical transients, so that machines can select and deliver the most valuable events to astronomers.

Of course different people ascribe value differently. An astronomer may be interested in a particular type of variable source, or a particular set of sources; or in finding comets with a backyard telescope; or in finding unknown examples of a known type of source. All of us on this planet are interested in finding devastating objects that could collide with the Earth. Thus we expect the infrastructure for astronomical transients to allow end-users to select in advance what types of events they want, and we expect specialist “event brokers” that disseminate only certain kinds of transients to their target audiences. Such dissemination should happen quickly, so that the essential telescope resources can be directed for followup, and we expect these decisions to be taken automatically by machines. We also expect multiple repositories of past events, with sophisticated query interfaces, to enable statistical and correlation studies of large numbers of events.

The ideas here apply not just to astronomy, but also in other areas of society where events must be followed by rapid, often expensive actions. For example, earthquake early warning systems could shut down elevators, computers, etc, in the seconds between detection and the time the earthquake waves need to propagate. A Geiger counter at a homeland security installation scans cargo, and issues events, whose importance is compared with warnings from other sources, and may trigger a manual inspection. A power or data network must respond to reports from multiple sources to detect unusual events, and (occasionally) bring in a human to evaluate. Everything said here about astronomical events can be also understood in a general sense, to refer to any event stream.
Event Selection
This selectivity will be predicated on there being enough information to make such selections. However, when an astronomical transient occurs, it may not be clear immediately if it was caused by exciting new astrophysics that should get rapid follow-up, or if it is an ordinary object that gets much less attention. The immediate data that describes the new transient may be no more than a single number, perhaps just a magnitude measurement. Of course, a transient survey is picking up differences between “now” and “the past” which may or may not be due to astrophysics: that measurement may actually be the product of an artifact or processing error, causing an event report that has zero interest.
Follow-up observation will be in short supply in the era of the event deluge. Faint objects can only be observed with the largest telescopes, that are already over-subscribed, and objects with uncertain position require deep wide-field imaging to look for possible counterparts. But selection of “interesting” events is subject to the same quality measures of any selection process, being the false-positive and false-negative rates. False positives are uninteresting things that waste valuable follow-up resources, and false negatives are exciting objects that were not identified as such. It will be important to bring together all possible information, as quickly as possible, and to build new ways of automated information fusion, in order to minimize both false positives and false negatives.
Telescope Selection
It will also be important for telescope resources to be directed effectively. Traditionally, an observing proposal specifies exactly which objects are to be observed; alongside this will emerge a new kind of proposal that specifies a fruitful event stream and a real-time selection algorithm that will fill the observing schedule in near real-time. It is this algorithm that the committee will judge, rather than a set of target objects. Further, the committee should understand that false positives are part of any selection process, and should not punish the observer for past observations that turned out to be sub-optimal. In addition to selecting targets in real time, observers (or their automated surrogates) will optimize which telescope should be used for the follow-up. This will obviously depend on local conditions (horizon, cloud etc), but will also depend on what kind of observation yields the most useful information in classifying the transient. Work is in progress on implementing these ideas[2][3].

Some event data may be released immediately and publically, some may be held private. The advantage of private data is that scientific credit for discoveries can be closely controlled. But public release and openness generally produces a greater total scientific return, because of the wider variety of observations and data that accrue. Furthermore, the funding sources for astronomical surveys often require public data release.
Annotation
All this close selection implies that enough information is available to make a selection. It is analogous to a patient presented to a doctor with a bad headache: that information alone is not enough for diagnosis or treatment until further information is available, such as medical history or further tests. That first data item is not enough, so the doctor builds a portfolio of different types of information, which is used for judgment. The same happens with astronomical transients, each portfolio including information from archives, follow-up observations, comments, results from software, and other sources.

Thus annotation is the process of adding information to a first detection, in order to give a more complete picture of what is happening in the sky. Archives may be used to select observations of the source in the past, either from the same survey, or from published surveys, building up a panchromatic light curve of the object. Follow-up observation can occur, perhaps automatically, adding photometry and spectroscopy to the portfolio. People can examine the portfolio and add interpretations and evaluations. Software can run on the portfolio, generating new data that is put into the portfolio.
Heterogeneous and Multisource Data
One of the difficulties encountered in portfolio building is that the data is heterogeneous: for example the source may or may not be in the footprint of an archival dataset, or the number of points in the light curve may be variable, there may be zero or more existing classifications (eg. Galaxy, recurrent nova, etc), or there may be multiple human evaluations. Standard data mining algorithms expect each portfolio to have exactly the same format -- a “database record” or a “point in a feature space” – so these do not work well in the context of heterogeneous portfolios. Prioritizing these portfolios is often like the choice offered in so many stories and movies: between the ‘well known but bland’ candidate, versus the ‘mysterious but exciting’ candidate (See Mahabal et. al. in Section 1.3).
Another difficulty arises because the data comes from multiple sources. Different authors of information may use different names for the same thing, different units, different ways to group or transform data, etc. This can make it very difficult to compare multi-sourced data and reach actionable conclusions. We can solve this by asking authors to define their metadata in advance of the arrival of the transient event, and in a structured fashion. Only if that metadata and structure can be kept simple enough, and yet also sufficiently expressive, then trusted, quantitative comparisons can be made.

When the data is both heterogeneous in content and in source, it becomes quite difficult to work with many of the software solutions that exist to handle event streams. The StreamSQL paradigm[4] uses extensions to the SQL language, designed for tables, but repurposed for real-time streams of records. However, the IVOA[5] has settled on a flavor of XML called VOEvent for the transmission of astronomical events, and processing those would need XML streaming and filtering technologies. There is though a further complication here: we really want to be processing portfolios (sets of events with citation structure).
Let us consider some processes that can happen once a survey detects and announces a new transient. First a new portfolio is created to hold whatever data is available, and then some of these may happen:
• Adding rich data: for example from previous data of the same survey or fetching from remote archives, adding results of software evaluation, or adding human writing.
• Follow-up observation: when observations are taken of the event, the results should be fed back into the portfolio, so that a complete picture is available. This is an important class of rich data.
• Summarizing: New data is added to the portfolio that converts earlier annotation into higher level semantic concepts, such as presence of host galaxy or radio source, association with known nova, etc. A summary is not “rich” data, but rather a condensation of rich data into perhaps a single number that expresses its meaning.
• Triggering: The portfolio is used in a Boolean function to determine what actions to take. Different purposes and different people will use triggers to get precisely the events they want.
• Taking Action: Each trigger is associated with an action to take if that trigger evaluates True. Examples of actions are messaging, execution of software, remote robotic observation, etc. Actions can also generate new data that is added to the portfolio.

These processes can drive the entire enterprise of event dissemination through a cyclic workflow: a trigger fires, causing new data to be added to the portfolio, so that another trigger fires, causing something else, etc. At the survey itself, triggers can determine whether the event is even made public, and receivers of the event can use triggers to determine the accumulation of data to the portfolio – for example “if the event is in the footprint of survey X, then fetch and annotate with what survey X has.” Requesting follow-up, deciding that an event is interesting, and even waking up a human for an opinion, can all be done through this trigger-action paradigm.
Human Computing
While machines are capable of many types of information processing, they are not so good where something new is present that has not been programmed. Certainly we expect the future flood of events to be mostly handled by machines, with the uninteresting ones never seen by a human expert, but some may be escalated in importance and come to the attention of such experts through a message, or even being urgently awoken in the night.

There could be a large number of other people also involved in the enterprise, volunteers recruited from the internet, with some, but by no means expert, ability. All people have excellent image analysis capabilities: they could, for example, look at an image of a star field and determine quickly and accurately if there is an artifact, such as a satellite trail, interference from a nearby bright star, or one of many Earthbound artifacts: from the telescope, camera, or electronics. While many of these types of common artifacts can be detected by machine, there are always new types, or artifacts that are a combination of known types. Since the transient detection software is looking for differences between new and past observations, such artifacts, though rare, will be inevitably found and thus pollute the event stream.

This type of ‘citizen science’ has been both popular and extremely useful in GalaxyZoo[6] and CitizenSky[7], and we expect it to be the same with events. A new aspect with events, different from the traditional web-based citizen science, could be that events are ‘pushed’ to the volunteers, so they can respond with their mobile device immediately. Another novel aspect to citizen science could be the recruiting of a cadre of dedicated volunteers to work at a more expert level, looking at light curves or other non-image data; they would need to be sufficiently motivated to study and take a test, to be inducted to this higher level.

Data Mining
Software components can be executed, perhaps in response to a trigger, and the results added back into the event portfolio. For example, taking four images of the sky, separated by several minutes in time, is a good way to find asteroids; this is because software can compare the four source lists and detect the moving object. In this case, the result is a probability that an asteroid is present, together with position, velocity etc. Thus complex data is reduced to meaning: a single numerical “probability of asteroid”. Other annotation components can be used to determine the association between the new transient and a host galaxy, which increases the chance that the transient is from a supernova, or between the transient and a known radio source, which increases the chance that the transient is from an active galaxy.
Information Fusion
When all the annotation is assembled into a portfolio, a difficult problem arises, which is summarizing all that information into a classification of the transient (supernova, asteroid, cataclysmic variable etc), and further, converting that classification into a decision about follow-up priority. Even when the problems of multi-sourced data are solved, it is still very difficult for a machine to fuse all the information into a trustworthy decision. Much work has been done on such problems in the machine learning community. However the best successes have come when there is a comprehensive training set that includes good coverage of all possible outcomes; or when each transient is represented with the same high-quality data, such as a long and regularly-sampled light curve, high-accuracy photometry, or a spectrum. Unfortunately, transient events are not like this: the most interesting objects are the rare ones, and the high-quality data is that which appears as a result of the expensive follow-up. Another difficulty is that astronomers are less interested in the objects that are already known and classified: rather they want the ones of a rare class that are not yet identified by others.
References
[1] LOFAR: http://www.lofar.org/, Pann-STARRS: http://pan-starrs.ifa.hawaii.edu/, LSST: http://www.lsst.org/ and SKA: http://www.skatelescope.org/
[2] R.C. Smith, R. Seaman, and P. Warner, Integrating VOEvent into the ground-based O/IR system at NOAO, Astron. Nachr. 329 (2008) 241.
[3] Alasdair Allan et. al., eSTAR: Building an Observational GRID,
http://adass.org/adass/proceedings/adass02/reprints/FO1-3.pdf
[4] StreamSQL
http://en.wikipedia.org/wiki/StreamSQL
[5] Rob Seaman, Roy Williams, Alasdair Allan et. al, Sky Event Reporting Metadata (VOEvent), a Receommendation of the IVOA,
http://www.ivoa.net/Documents/latest/VOEvent.html
[6] GalaxyZoo
http://www.galaxyzoo.org/ [7] CitizenSky
http://www.citizensky.org/
1.3 The Meaning of Events
Ashish Mahabal, S.G. Djorgovski, Ciro Donalek California Institute of Technology
The classification of complex celestial events
Exploration of the time domain is rapidly becoming one of the most exciting new research frontiers in astronomy, prompted by the new generation of synoptic sky surveys ([1,2,3] to name a few). The sky is no longer seen as changing in a slowly or an orderly fashion; besides the fairly well understood galactic and extra-galactic sources there are important physical phenomena occurring on scales as short as seconds, whose rapid and appropriate follow-up promises to broaden substantially our understanding of the physical universe, and perhaps lead to a discovery of previously unknown phenomena. They range from the studies of the Solar system (e.g., searches for the potential planetary hazard asteroids), to stellar evolution (variable and exploding stars of all sorts), to cosmology (supernova standard candles) and extreme relativistic astrophysics (GRBs, blazars). Essentially every field of astrophysics is touched and enhanced with the exploration of the time domain, and many interesting phenomena can be only studied in the time domain.

This new generation of synoptic sky surveys – at all wavelengths – is also rapidly moving data-intensive astronomy from the Terascale to the Petascale regime. Given this large increase in data volumes, in addition to sharpening of the standing challenges of effective data mining and knowledge extraction from the large and complex data sets, there are now new challenges posed by the transient nature of time-domain phenomena, with the addition of the time dimension to the observable parameter space. We are moving towards the (near) real-time exploration and analysis of massive data streams.

An effective scientific exploitation of this new and growing wealth of data depends critically on our ability to identify rapidly the most interesting events, and to follow them up in some resource-optimized fashion in order to obtain the necessary data for their physical interpretation and understanding. As the data and event discovery rates increase dramatically, from ~ 0.1 TB and ~ 10 – 10^2 events per night now, to ~ 30 TB and 10^5 – 10^6 events per night in the LSST [4] era, available follow-up facilities would be simply overwhelmed, and unable to react to all potentially interesting events. The essential enabling technologies will be automated, robust classification and decision making for the optimal use of follow-up facilities. Given the exponential growth of data rates, the traditional “manual” approach from the past will simply not scale to the next generation of surveys, especially if one is interested in the rarer transients.

Consumers of transient events are usually interested only in a particular type, e.g., supernovae of a given type to be used either as cosmological standard candles, or as the probes of the endpoints of stellar evolution; gravitational microlensing events, especially with the possible planetary signatures; blazar flares to be correlated with high-energy events; and in the future, possible electromagnetic counterparts of the gravitational wave detections; etc. The key challenge is that a broad diversity of the fundamentally different physical phenomena look the same at the instance of their event detection, e.g., a “new” or a much brighter point source relative to the baseline image; at that point, essentially nothing is known about its physical nature of the degree of interest (see Fig. 1 for some examples). A desired output is to evaluate a probability of any given event as belonging to each of the possible known classes. Self imposed probability acceptance cut-off can then allow individual consumers to decide if a particular event is worth expending their resources in following it. The most interesting outcome may be the events that do not fit any of the known patterns – possible examples of new types of astronomical objects or phenomena.

The key challenges are thus in the dynamical, real-time characterization and classification of transient events, and the optimal decision making for their follow-up, which are the subjects of this chapter. This entails some special challenges beyond the traditional automated classification approaches, which are usually done in some feature vector space, with an abundance of self-contained data derived from homogeneous measurements. Here, the input information is generally sparse and heterogeneous: there are only a few initial measurements, and they differ from case to case; many sources of noise, instrumental glitches, etc., can masquerade as transient events in the data stream; new, heterogeneous data arrive, and the classification must be iterated dynamically. Some classifiers may be optimal for a particular type of events, but not for others; if a battery of different classifiers is deployed, their output must be
combined in some optimized fashion.
Figure 1. Examples of transient events from the CRTS sky survey [1]. Images in the top row show objects which appear much brighter that night, relative to the baseline images obtained earlier (middle row). On this basis alone, the three transients are physically indistinguishable, yet the subsequent follow-up shows them to be three vastly different types of phenomena: a flare star (left), a cataclysmic variable powered by an accretion to a compact stellar remnant (middle), and a blazar, flaring due to instabilities in a relativistic jet (right). Accurate transient event classification is the key to their follow-up and physical understanding.

Thus, the technological associate classification probabilities for any given event as belonging to key scientific and
challenge is to
a variety of known classes of variable astrophysical objects and to update such classifications as more data come in, until a scientifically justified convergence is reached. The process has to be fully automated, robust, and reliable; it has to operate from sparse and heterogeneous data; it has to maintain a high completeness (not miss any interesting events) yet a low false alarm rate; and it has to learn from the past experience for an ever improving, evolving performance. All of these challenges require some novel approaches, and we discuss them below.
Types of data
The simplest way to express the issue of classification is to say that we would like to attach a definite label to each transient found. It is easier said than done. In most cases a spectrum is the sure shot way to do this. Of course obtaining spectra is expensive, especially given the large number of transient candidates, a majority of which belong to well known types. As a result, one has to consider alternatives. The alternatives will typically provide a set of possible classes and associated probabilities which can then be refined using additional observations. In short, characterizing the event/object and when required proceed to classification using additional data if needed.

Colors: Imaging in multiple filters provides one with colors (which form, in essence, a very low resolution spectrum). The colors can be used to classify objects. One of the best examples has been to look for quasars of different types. (e.g [5]). Different supernovae too display different colors and this has been used in projects like the SN Typing Machine [6] to determine the type and phase of a SN. Similarly other transients have characteristic colors that help identify them. The loci of different transients are not nonoverlapping, so colors, by themselves, are often more useful to eliminate other classes with high confidence than to determine a particular class. One can train Neural Networks, Bayesian Networks etc. to use colors as inputs and return possible classes.

Light curves: How the flux of a transient varies as a function of time depends on the physical processes inside the progenitor and/or in its vicinity (see Figures 1, 2 for example). A SN, for instance, rises more gradually. A periodic variable does just that – vary periodically. A Catacysmic Variable (CV) has episodes of activity that are not periodic, the brightness of a blazar too varies sporadically. In addition, there is extrinsic variability due to, for instance, eclipsing. Besides the standard lightcurve modelling that can provide periods (in case of periodic variables e.g. using generalized Lomb-Scargle periodgram [7]) an interesting technique that is useful also in case of non-periodic variables is the Gaussian Process Regression (GPR) described later. For dense lightcurves methods are available even if the data points are unequally spaced [8] while for sparse ones hardly any. Historical data is often available at the locations of a transient, but this is generally in the form of upper limits which depend on various factors like lunar phase and sky conditions making them extremely difficult to interpret using any existing methods. Large gaps often exist between different parts of the lightcurve making it difficult for interpretation even when several datapoints may be present. Methods involving Generalized Autoregressive Conditional Heteroscedastic (GARCH) and Autoregressive Moving Average (ARMA) modeling [9] may prove useful in such analysis.

These two types of data, colors and lightcurves, are optical-centric. But the same concept extends to other wavelengths e.g. infrared (60 cm, 40 cm), radio (25 GHz, 1.4 GHz) etc. (a set of colors) and when, for instance, a transient is monitored at, say, 1.4 GHz (a lightcurve).
In some cases, as in Gamma-rays, the error circles are large and one has to perform cross-matching with, say, catalogs at optical wavelengths, and look for possibly varying objects as likely transient candidates.

•

Figure 2. Color-color plot (two left plots) and light curve (right) for a transient from CRTS based on g, r, i, z data from the Palomar 60-inch telescope. The color-color plots show the position of the transient at different epochs (asterisks) wrt the stellar locus (points). The light curve shows how the brightness varied during that time, with different symbols representing different Gunn-Thuan filters. Though the lightcurve extends over a large period (4 months in this case), initial classification is carried out with as few as two points.

Context: A lot of the pertinent information may be contextual in nature, e.g., the light curve and observed properties of a transient might be consistent with it being a cataclysmic variable star, or a blazar, or a supernova. If it is subsequently known that there is a galaxy in close proximity, the supernova interpretation becomes much more plausible. Such information, however, can be characterized by high uncertainty and absence, and by a rich structure – if there were two galaxies nearby instead of one then details of galaxy type and structure and native stellar populations become important, e.g., is this type of supernova more consistent with being in the extended halo of a large spiral galaxy or in close proximity to a faint dwarf galaxy? Presence of a radio source associated with the transient is another example of contextual information that can rule out a large number of classes immediately. The ability to incorporate such contextual information in a quantifiable fashion is highly desirable, and yet, this is very hard to implement in the traditional survey processing pipelines, and to quantify in some manner that is amenable to machine processing and classification.
Archival data and priors
If one were to try to classify objects based on just their latest observations and without taking into consideration past observations of other objects, it would be an impossible task. Since a majority of objects observed in a survey are of known types, observations of other objects of the same type are available from before. A meaningful characterization of the parameter space occupied by all objects tell us of (1) distributions as a function of different parameters, and (2) relative abundances of different objects in different parts of the parameter space. Together they provide us with probabilities of a newly detected, previously unknown object belonging to each of the different previously known classes with some probability.

Besides priors involving such relatively straightforward parameters like magnitudes and colors, priors are also constructed from quantities like dm/dt (to characterize variability in a certain timeframe - see Figures 3, 4), Galactic latitude (to determine the likelihood of a transient being extra-galactic in nature) etc.
It is the priors that allow defining expressions like p(α| βγδ (indicating the likelihood of αbased on the presence of β,γ,δ) etc.
€ €
€

Figure 3. Examples of prior distributions of selected observables for different types of astrophysical variable sources compiled from the literature, and processed by us. Top: Box plots of flux variability amplitudes for different types of objects (plotted along the X axis), sampled with time baselines of 1 day (left) and 2 days (right). There are clear qualitative differences in behavior among different types of objects, and they depend on the time baseline. The bottom row shows the prior distributions for one sources, the RR Lyrae stars, with flux (magnitude) change after one day (left), priors can be used within the classification methods described in the text. particular type of variable
and color (right). These
Classification methods
Modern synoptic sky surveys present some novel challenges for automated classification of detected events. Reliable and robust real-time classification is essential in order to exploit the full scientific potential of these surveys, and conduct optimized follow-up observations. The classification often needs to be carried out using minimal information in order to catch some of the most interesting objects. The requirement to perform the analysis rapidly and objectively, coupled with massive and persistent data streams, implies a need for automated classification and decision making. This generally has to be done using sparse and heterogeneous measurements for individual events, both from the survey pipelines and existing archives.

Different machine learning algorithms have been used to attack the problem. The choice of the method depends on the information available and desired separation of classes. For example, Bayesian techniques are very effective in dealing with missing data; other techniques are best suited to deal with light-curves, such as Gaussian Process Regression; Neural Networks [10] can be used to obtain very accurate classification but they need the data to be complete and tend to be somewhat blackboxy. Unsupervised methods, like the Self Organizing Maps (SOM) [11], can be used to cluster data without providing a training set and offer also a powerful way to visualize clusters in multidimensional data. With a large number of available methods, we can not hope to be complete here but cover a small number of techniques which are especially useful even when only a small number of observations are present.

Bayesian Networks (BN). Bayesian methodology is desirable and attractive for this task, since it can deal with missing data effectively. A BN is a probabilistic graphical model represented through directed acyclic graphs (DAG), whose nodes represent parameters, and the missing arcs represent conditional independence assumptions. These networks can be used to compute the probability distribution of a subset of parameters when other parameters are observed (the so called probabilistic inference). To describe a BN we need to specify the graph topology and the parameters of each conditional probability distribution. An attractive feature of BNs is their ability to learn from the data. In the Bayesian approach we generate (and subsequently, update) a library of prior distributions capturing, for example, brightness changes in a certain filter over a certain time interval, conditional on object type such as type Ia Supernova. Such distributions need to be estimated for each type of variable astrophysical phenomenon that we want to classify. Then an estimated probability of a new event belonging to any given class can be evaluated from such pieces of information as are available.

Figure 4. Example of a Bayesian Network for transient classification. We currently use this configuration for classification of CRTS transients. Each of the three colors is a multinomial node. The output class is also a multinomial node with possible outputs being SN, CV, Blazar, AGN, UV-Ceti and all else combined in to a sixth class. In the presence of even a single input parameter, output is available. Updating the network is easy when more data becomes available (both, improved classification, and retraining).

Gaussian Process Regression (GPR) GPRs can be used for modeling, prediction and curve fitting (see [12] for examples). For example, when used with lightcurves, they can be effective in determining class membership, given a small number of observations in a single band at different epochs. In this approach, each object class (eg, SN Type Ia) has to have its own model. For each class the marginal likelihood is computed and the classification is based on the likelihood ratios.

For each class of objects though there are variations amongst lightcurves of individuals (e.g. peak brightness, ascent period, descent period, max delta-mag etc.), the class itself can in principle be modeled using a function (perhaps a combination of components including one or more periods as well as lengthscales and Poisson noise). Such a function can have hyperparameters so that for each individual lightcurve one can determine these parameters with an associated confidence (see Figure 5). This is exactly what a GPR does. The more points there are, the more secure the match to a class will be. For different classes one determines the best fitting functions with variance in the hyperparameters. Then one can compare input datapoints against such a library asking for confidence of a fit for each of the types. It is not expected to be great at subclasses, but the type of variability (e.g. SN versus periodic variables versus blazars) can be discerned using GPRs quicker than other methods. The more traditional methods can then take over.
Figure 5. A SN lightcurve during the GPR modeling process. The uncertainty is greater where less data is available (gray area).
Other methodologies (see [13, 14] for more examples and references). There are many other techniques, both supervised and unsupervised that can be applied under different circumstances. We talk about supervised models, when for some examples the correct results (targets) are known and are given in input to the model during the learning process, thus, for a subset of data in the input space there must be an accurate knowledge of the desired property. Supervised methods are usually fast and very accurate but the construction of a proper training, validation and test set is crucial. In the unsupervised learning, the model is not provided with the correct results during the training; these models can be used to cluster the input data in classes on the basis of their statistical properties only. The Multilayer Perceptron (MLP) is one of the most used Neural Network model: it consists of multiple layers of computational units, usually interconnected in a feed-forward way. Each neuron in one layer has direct connections to all the neurons of the subsequent layer. MLPs have been successfully used for tasks like star-galaxy separation, artifacts removal, evaluation of photometric redshift, etc. Figure 6 shows a generic neural network.
Figure 6. Schematic representation of a Neural Network with four inputs, one hidden layer, one output unit.
One of the most used unsupervised models are the Self-Organizing Maps that project high dimensional input data into a low dimensional output space. They can be used for clustering and provide also a powerful data visualization and correlation hunting tool.

Combining diverse classifiers (see [15, 16, 17] for examples and more references and Figure 7 for a conceptual overview). Results from the different classifiers can be combined through a fusion module using a sleeping experts framework, where each specialist makes a prediction only when the instance to be predicted falls within its area of expertise. Sleeping experts can be seen as a generalization of the IFTHEN rule: IF the condition is satisfied for an expert THEN activate that expert. For example some classifiers work better when certain inputs are present, and some others may work only when certain inputs are present. External and contextual knowledge can be used to awaken experts or put them to sleep and modify online the weight associated with each classifier. Contextual information can be highly relevant to resolving competing interpretations. Such information, however, can be characterized by high uncertainty and a rich structure. It has been shown that using such a framework is a powerful way to decompose complex classification problems. The fusion module can help to improve the classification, narrowing down the number of competing classes and leading to optimal follow-ups and new discoveries.

Figure 7. Combining different classifiers is a complex issue. Different classifiers work better in the presence of different input data. Keeping that in mind they can be selectively used (sleeping expert mode, as described in text). In some cases when the data do not lie in the exclusive domain of any one expert, multiple methods can be run and the likelihoods combined in standard probabilistic ways.
Feedback incorporation
Once the classification process is complete at a given iteration, an optimal decision needs to be made about expending valuable follow-up resources (e.g., obtain additional measurements using a more powerful instrument, diverting it from other tasks) in real time. This would include an automated identification of the most discriminating potential measurements from the available follow-up assets, so that the system would request specific, high-priority follow-up measurements that would have the highest impact on the iterated event classification, and thus the final automated classification and decision making. There are two parts to this challenge. First, what type of a follow-up measurement – given the available set of resources (e.g., only some telescopes/instruments may be available) – would yield the maximum information gain in a particular situation? And second, if the resources are finite and have some kind of a cost function associated with them (e.g., you can use only so many hours of the telescope time), when is the potential for an interesting discovery worth spending these resources? This can be carried out using Bayesian formalism as described in [18].
Once the additional observations are obtained, they get fed back in to the system and the gamut of classification methods is rerun in order to get firmer probabilities. If the classification is certain, the observations get used in the priors. If not, and if the object is still considered interesting enough to follow, another round of determining which disambiguating observations to carry out happens.

Citizen Science
Given that there will be tens of thousands of transient candidates competing for scarce resources, it is impossible to eyeball even those that survive the myriad of classification steps mentioned earlier. Human neural networks can come to the rescue in such a case. Details about citizen science are provided elsewhere in this book. Here we would like to highlight one particular aspect, the synergy between machine learning and human pattern recognition expertise to improve the machine learning methodologies. It is ideal to use a two-level (and iterative) strategy to harvest the pattern recognition abilities of humans and hardwiring those fuzzy concepts. For generality we talk here of "objects" represented by "parameters" in a multi-dimensional space. We start with a representative sample of several hundred to few thousand examples comprised of two types: (1) those securely belonging to the different classes (as deduced by experts), and (2) those near the class boundaries. The parameters of the individual objects are presented as patterns (in different ways, as elaborated below) to the "community" somewhat ala GalaxyZoo. An order or two more of objects in the same large parameter space are then presented. Based on where the human pattern recognition engines set the class separators, the computer code to do so automagically is modified and used for the entire dataset (which typically is several orders bigger in case of the largest projects).

Visualization plays a key role here. How to display multidimensional data on a 2-dimensional screen has been a perennial problem with a variety of partial solutions that suit different problems and different people. A multitude of these are used. Some people are good with shapes, some with colors, some with contours. To every individual all these are initially provided, and based on the best returns, a display mode to individual match is done, and that mode is subsequently used with that individual. The rest of the methodology parallels that described in the Citizen Science section.
Figure 8. A piece of the complex classification process of collecting data, comparing it with archival data and various priors to obtain a set of transients worth following.
How it all ties together
We have provided a flavor of the complexity involved in classification of complex celestial events in terms of the datasizes, the size of the parameter space, the steps and methods involved in separating the typical transients from the unusual cases, determining follow-up priorities and feedback mechanisms. While all these steps are currently possible and in fact being executed for a few surveys like the CRTS, we are not yet at the level where we get even hundreds of transients per night, and the priors are far from perfect since the past information comes from a variety of surveys and observations which are, together, rather inhomogeneous. But the situation improves with every additional transient studied.

The interaction of the various components happens using various agents, protocols and websites like VOEvent, SkyAlert, portfolios, etc. as described elsewhere in the book. Collectively they lead to the physical interpretation of the events.
References
[1] First Results from the Catalina Real-time Transient Survey, A.J. Drake, S.G. Djorgovski, A. Mahabal et al., 2009 ApJ, 696, 870
[2] The Palomar-Quest Digital Synoptic Sky Survey, S.G. Djorgovski, C. Baltay, A.A. Mahabal, A.J. Drake et al., 2008, AN, 329, 263
[3] LSST: from Science Drivers to Reference Design and Anticipated Data Products, Z. Ivezic, J.A. Tyson, R. Allsman, J. Andrew, R. Angel, et al, for the LSST Collaboration,
http://arxiv.org/abs/0805.2366
[4] LSST Book, chapter 8, http://www.lsst.org/files/docs/sciencebook/SB_8.pdf
[5] Colors of 2625 quasars at 0 < z < 5 measured in the Sloan Digital Sky Survey photometric system, Richards, G.T. et al., AJ, 2001, 121, 2308
[6] Not Color Blind: Using Multiband Photometry to Classify Supernovae, Dovi Poznanski, Avishay Gal-Yam, Dan Maoz, Alexei V. Filippenko, Douglas C. Leonard, Thomas Matheson, http://arxiv.org/abs/astro-ph/0202198
[7] Bretthorst, G. L., 2003, 309, Frequency Estimation and generalized Lomb-Scargle Periodgrams, in Statistical Challenges in Astronomy, Eds. E D. Feigelson and G. J. Babu, Springer [8] Vio, R., Strohmer, T. and Wamsteker, W., 2000, PASP, 112, 74, On the reconstruction of irregularly sampled time series
[9] Tripodis, Y., and Buonaccorsi, J. P., 2009, J Stat. Planning Inference, 139, 4039, Prediction and Forecasting in linear models with measurement errors
[10] [Neural Networks for Pattern Recognition, Clarendon Press, Oxford, 1995.
[11] Self Organizing Maps, T. Kohonen, Springer Berlin, 1995.
[12] Gaussian Process Regression, http://www.gaussianprocess.org

[13] New Approaches to Object Classification in Synoptic Sky Surveys, C. Donalek, A. Mahabal, S.G. Djorgovski, S. Marney, A. Drake, M. Graham, E. Glikman, R. Williams, 2008, in Proc. Intl. Conf. on Classification and Discovery in Large Astronomical Surveys, AIP Conf. Ser., 1082, 252.
[14] Mining Astronomical Massive Datasets, C. Donalek, PhD Thesis, 2006.
[15] Using and combining predictors that specialize. Y. Freund, R. E. Schapire, Y. Singer, M. K. Warmuth, Proceedings of the 29th Annual ACM Symposium on the Theory of Computing, 1997 [16] How to Use Expert Advice, N. Cesa-Bianchi, Y. Freund, D. Haussler, D. P. Helmbold, R. E. Schapire, M. K. Warmuth, Journal of the ACM, Vol. 44, No. 3, May 1997, pp. 427-485
[17] Mixing Bayesian Techniques for Effective Real-time Classification of Astronomical Transients, A. Mahabal, S.G. Djorgovski, C. Donalek, A. Drake, M. Graham, B. Moghaddam, M. Turmon, R. Williams, 2009, in Proc. ADASS XVIII, eds. M. Ohishi et al., A.S.P. Conf. Ser. in press.
[18] The Bayes Net Toolbox for Matlab, K. Murphy
http://code.google.com/p/bnt/
2 About VOEvent

VOEvent is a structured message protocol for ‘representing, transmitting, publishing and archiving the discovery of a transient celestial event, with the implication that timely follow-up is being requested.’ The first section describes the format, and the second and third sections describe extensions of the protocol to more complex data such as tables and time series.
Photo credit: Flickr/Mike Baird
2.1 What is VOEvent?
Rob Seaman
National Optical Astronomy Observatory
We present the essence of VOEvent. The subsequent sections in this chapter describe advanced features for representing complex data structures and time series. VOEvent is an evolving standard [1] maintained and extended by a living community, the IVOA VOEvent working group [2]. These two links bear emphasis:

Standard :
http://ivoa.net/Documents/latest/VOEvent.html
Community:
http://voevent.org
Why VOEvent?

Humans have pondered the import of changes within the “eternal” sky for thousands of years. Astronomers have studied the dynamic universe since Tycho Brahe discovered his “Stella Nova” (since promoted to the ranks of the supernova) in 1572 [3]. Reports of celestial events were among the first telegrams sent over the newly laid transatlantic cable in 1866.

VOEvent seeks to combine the rich semantics of astronomical telegrams (for example CBAT [4], MPC [5], ATel [6] and many more), with the instant delivery of the Gamma-ray bursts Coordinates Network (GCN) [7], while building on modern software standards of the International Virtual Observatory Alliance (IVOA) [8].

Rather than supplanting the roles of prior alert publishers, VOEvent offers a path forward to a common interoperating transient alert infrastructure. Every snapshot of the sky may contain the signatures of multiple diverse time varying phenomena of interest to many stakeholders for disparate investigations. Separating the technology for reporting supernovae, for instance, from that for reports of solar system objects, variables stars, gamma-ray bursts and so forth has served to obscure the resulting science and to complicate observational logistics. Software systems have been needlessly duplicated.
The VOEvent XML Schema
VOEvent is an IVOA Recommendation – that is, it has been adopted as an international standard. As with many other IVOA standards, VOEvent is based on XML, the Extensible Markup Language [9]. XML is ubiquitous in worldwide web technologies and simply provides a structured way to build a nested hierarchy of elements, to attach attributes to those elements, and to assign values to each. An additional constraint on many IVOA standards, including VOEvent, is a schema to apply rules on the arrangement and numbers of each element and attribute and on their allowed values. XML Schema [10] can be an often-entertaining technology for the designers of a standard. Providing a battle-hardened VOEvent schema [11] is a priority of the VOEvent v2.0 development effort. A well-crafted schema permits the validation of documents (in this case VOEvent messages, also referred to as “packets”) against the requirements of the standard, and can even be used to automatically create software to parse such messages.

IVOA Recommendations are normative – that is, they have the final word on the rules for Virtual Observatory formats and protocols. But it is the VOEvent schema where the rubber meets the road. As a practical matter, the schema enforces the rules. The alternative is for a standard to be defined by a particular software implementation. The limitation with the latter notion is that it ties a user, a project, or an organization to that software package through a roller coaster of operating system updates and external project life cycles. We will not describe the subtleties of schema usage further, but it is important to know that a VOEvent schema exists to capture the format’s rules. The one fact to remember should you find yourself speaking to a fussbudget programmer is that schema is singular. The plural is schemata.
The <VOEvent> Element
The one required element in any VOEvent message naturally enough is <VOEvent>. XML elements are surrounded by angle brackets (“<>”) as with the more familiar HTML tags. This is not the place to describe all the ins-and-outs of XML usage – many references exist online or on computer bookshelves. Suffice it to say that the<VOEvent> element has three attributes,ivorn, role, andversion. The usage of the version is relatively self-explanatory. The role attribute permits, for instance, distinguishing a test message from an actual celestial alert.

The funny word, IVORN, refers to an International Virtual Observatory Resource Name [12]. This is the identifier that distinguishes one celestial transient alert message from another. The format resembles other types of web addresses, for example:
ivo://my.observatory#message17
The first part of the IVORN represents the publisher. The second part (after the “#”), identifies the specific message. For further details about IVORNs (or any other issue in this section) please consult appendix 5.1, the working draft of v2.0 of the VOEvent standard. Always remember that the current normative standard is available at:
http://ivoa.net/Documents/latest/VOEvent.html
The VOEvent schema controls how the elements of the standard can nest. In general a VOEvent packet may contain exactly one copy, or otherwise no copy, of each of the six major elements described below:
<Who> – Author information
<What> – Event characterization
<WhereWhen> – Targeting for follow-up observations
<How> – Instrumental setup
<Why> – Scientific inferences
<Citations> – Threads of empirical investigation
In addition, each of the major elements can contain<Description> elements for human-readable content and<Reference> elements to point to external content.
The <Who> Element
The nesting rules of XML do not enforce a particular order for elements on the same hierarchical level. We discuss the <Who> element first, but a message’s elements may be reordered without changing their meaning. The <Who> element is used to provide curation metadata describing the origin of the observational information in the VOEvent message. This may include a description of the Author and Publisher and a publication date (and time) for the particular message. The words have their typical usage here – the Author is responsible for the scientific content of the message, while the Publisher is responsible for the numerous logistics associated with distributing the message.

While detailed curation information may be written to individual messages, it is more likely that an <AuthorIVORN> sub-element will be used to reference a registered resource record describing an Author who may publish numerous VOEvent messages. Similarly, information about the Publisher is usually implicit in each message’s own IVORN, an attribute of the<VOEvent> element. See section 4.2 for more information about using the IVOA Registry to locate virtual resources.
The <What> Element
The work of describing the actual celestial phenomena falls to the <What> element. Something happened in the sky. What was it? At its most basic, the <What> element contains one-or-more <Param> subelements. A<Param> associates the name of a quantity with its value, for example:
<Param name="mag" value="13" ucd="phot.mag;em.opt.R" />
IVOA Unified Content Descriptors (UCDs) are discussed further in section 4.3 and in [13]. Parameter attributes may also include units, and <Param> elements may be nested inside <Group> elements to provide simple data structures. More advanced usage is described in sections 2.2 and 2.3.
The <WhereWhen> Element
While the <What> element describes the dependent variables of some observation (or set of observations), the<WhereWhen> element describes the independent variables to indicate where and when the phenomena were observed. More generally,<WhereWhen> provides targeting information for followup observations. Spatial and temporal coordinate systems are tied together in astronomy, and so they are tied together in the IVOA and VOEvent. Recommendation [1] and in the document Observatory” (STC) [14].
Details are in section 3.4 of the “Space-Time Coordinate Metadata
IVOA VOEvent for the Virtual
A key aspect of celestial coordinates is that fundamentally the location of the observer must be provided in addition to the location of the astronomical object or phenomena that are being studied. STC provides a list of <AstroCoordSystem> defaults that tames some of this inherent complexity.
The <How> Element
The <How> element is where a project can provide information describing the instrument that was used to make the observation in question. A list of <Reference> elements can be provided, linking to external RTML (Remote Telescope Markup Language) documents that describe the instrument. Please consult the RTML documentation [15].
The <Why> Element
VOEvent can be viewed as a language for conducting discussions of scientific investigations. Phenomena are discovered, described, and announced. Communities of like-minded individuals (or robotic facilities) receive these alerts and conduct follow-up observations resulting in follow-up VOEvent messages. The intent of this empirical conversation is to understand the physics and cosmic history underlying the observed phenomena. The<Why> element provides a facility for the scientific assessment resulting from this conceptual mangling [16].

The <Why> element itself allows two attributes – a measure of theimportance of the VOEvent alert, and a estimate of when the implicit call for follow-up observationsexpires. Within the<Why> element are a list of <Concept> and<Name> elements to associate the phenomena with known classes of phenomena or with specific astronomical objects. These may be grouped using the <Inference> element which has attributes asserting a probability that the inference is correct and associating a description of the relation between the VOEvent alert and the<Concept> or<Name> elements within.
VOEvent <Citations>
The final major ingredient to a VOEvent message is the <Citations> element. As described under <Why>, alert messages often result in follow-up observations that are themselves expressed as VOEvent messages. The<Citations> element permits associating each message with others earlier in the particular empirical chain [17], via a list of <EventIVORN> elements referring to the earlier message identifiers.

Each <EventIVORN> must also have acite attribute describing whether the current message is afollowup of the cited message, or rather is a retraction or supersedes the previous message. By superseding previous messages, chains of follow-ups can be split or merged should it later be discovered that they describe different (or rather identical) phenomena.
The VOEvent Network Architecture
VOEvent is transport neutral, that is, a celestial transient alert might well be delivered via an unofficial channel (one could puckishly suggest a fortune cookie or carrier pigeon) and still result in important scientific discoveries and follow-up observations. However, it was recognized immediately that creating the VOEvent standard and developing a reliable distribution mechanism went hand-in-glove.

Numerous project-tied systems have been VOEventNet [18], VO-GCN [19], eSTAR implementations are interoperable, for example, events from VO-GCN flow to SkyAlert. Even more importantly, interoperability will permit current facilities to evolve into the celestial transient alert networks of tomorrow. Figure 1 shows one possible model of how VOEvent-based transient alert messages from the Large Synoptic Survey Telescope (LSST) [22] will flow from the telescope on Cerro Pachon in Chile to data centers in both hemispheres and onward to the larger VOEventNet. prototyped, developed, and deployed, for example,
[20], and SkyAlert [21]. The key is that separate

Each project’s

benefit from different arrangements of network
the basic sequence is numbered in Figure 1:

1. Celestial transient alerts are generated by the LSST pipeline
2. Alerts are published via a registered VOEvent broker
3. The full feed of messages is sent to the LSST Archive Center
4. Regional data centers also receive all alerts
5. Most LSST follow-up observations will occur in the south
6. VOEventNet streams and features are available to LSST
7. Users connect via general purpose alert services like SkyAlert
References
[19] Latest IVOA VOEvent standard
http://www.ivoa.net/Documents/latest/VOEvent.html [20] IVOA VOEvent Working Group
http://voevent.org
Figure 1. Proposed architecture for LSST transient alerts. transient alert architecture will links and servers. For LSST, [21] Tycho Brahe, De Stella Nova, 1573
http://www.texts.dnlb.dk/DeNovaStella/Index.html (in Danish)
[22] CBAT: IAU Central Bureau for Astronomical Telegrams
http://www.cbat.eps.harvard.edu/index.html
[23] MPC: IAU Minor Planet Center
http://www.minorplanetcenter.org/iau/mpc.html
[24] ATel: The Astronomer's Telegram
http://www.astronomerstelegram.org
[25] GCN: The Gamma-ray bursts Coordinates Network
http://gcn.gsfc.nasa.gov
[26] IVOA: International Virtual Observatory Alliance
http://www.ivoa.net
[27] XML: Extensible Markup Language
http://www.w3.org/XML
[28] XML Schema
http://www.w3.org/XML/Schema
[29] VOEvent Schema (version 1.1)
http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd
[30] IVORN: IVOA Resource Names
http://www.ivoa.net/cgi-bin /twiki/bin/view/IVOA/ResourceNameSemantics [31] UCD: IVOA Uniform Content Descriptors
http://www.ivoa.net/Documents/latest/UCD.html
[32] STC: IVOA Space-Time Coordinates Metadata
http://www.ivoa.net/Documents/latest/STC.html
[33] RTML: Remote Telescope Markup Language
http://www.uni-sw.gwdg.de/~hessman/RTML, or
http://monet.uni-goettingen.de/twiki/bin/view/RTML (twiki)
[34] Andrew Pickering, The Mangle of Practice, U. of Chicago Press, 1995.
[35] R. Seaman, Thread safe astronomy, AN v329 n3 p237, March 2008.
http://arxiv.org/abs/0802.0262
[36] VOEventNet: An implementation of a VOEvent network
http://voeventnet.caltech.edu
[37] VO-GCN: VOEvent-compliant GCN
http://www.cacr.caltech.edu/hotwired2/program /presentations/HTU2_VOGCN_Barthelmy.pdf [38] eSTAR: eScience Telescopes for Astronomical Research
http://www.estar.org.uk
[39] SkyAlert
http://www.skyalert.org
[40] LSST: Large Synoptic Survey Telescope
http://www.lsst.org
2.2 Extending VOEvent for more complex data
Roy Williams, Matthew Graham
California Institute of Technology
The VOEvent standard has been well taken up by the community since 2006, and there have been thousands of events in this format. Now there is interest in new schema for VOEvent 2.0, specifically to be able to put small tables, time series, ephemeris etc into the packet. We also discuss the use of linking to connect to complex data, and ask if any extra structure is actually needed, or if linking can always be the answer. We present some use cases for such extra structure, consider representing these within the current VOEvent structure, and suggest a simple table extension of VOEvent, that is already IVOA Recommendation, that would represent all the use cases in a simple way.
Introduction
VOEvents [1] are intended to communicate the discovery of a transient celestial event, with the implication that timely follow-up is being requested and reported back. It should include information that allows decisions and classifications to be made by human or machine. Since the IVOA Recommendation [1] of VOEvent 1.1 (June 2006), many astronomical projects have expressed interest in building VOEvents, and some are actually doing so, and have created hundreds or thousands of events. The next challenge is to consider improvements to the 1.1 specification, that may make the information in the packet more useful, more clear, or more comprehensive; but without putting an undue burden on the parsing software or invalidating existing version 1.1 events. In this note, we consider some use cases for VOEvent and the data structures that would be appropriate.

One of the objectives of VOEvent is to establish it as an alternative way to publish first discovery, in the way that Astronomer's Telegram [2] and CBAT [3] are. These event notices are usually English text, unreadable to machines, but some have a small table or list as part of the notice. If we believe that VOEvent should be able to express whatever these other publications can express, then VOEvent should be able to hold this extra data, and furthermore, we should make that data structured, and thus accessible to machines also.

VOEvent is an RSS/Atom feeds, these last being XML dialects that are not compatible with VOEvent 1.1. However, the point of this note is not to question or suggest syntax for VOEvent, but to ask if more complex data extensions should be in it. If the answer is yes, these extensions can also be represented – to some extent
– in these other kinds of syntax.
The VOEvent data model from 2006 has several components: <Who>, <What>, <WhereWhen>, <How>,
<Why>, together with <Citation>, <Reference>, and <Description>. The <Reference> element is to
contain links to documents and data objects that give further information about the event. The <Why> section assigns one or more causes of the event, in a probabilistic way, to the possible astrophysical processes, where the names of those processes can include concepts from an IVOA-controlled standard vocabulary.
Most of these do not concern us in this note, but specifically:
XML model. Other serialization possibilities are also in use, such as JSON and
<Reference>
VOEvent defines a <Reference> element, which allows linking from the event packet to external resources by the URI mechanism, for example:
<Reference uri="http://gcn.gsfc.nasa.gov/gcn/notices/sw0041000msni0284.fits" type="url"/>
This allows web links, so that a complex data object (eg FITS file) can be available to readers of the VOEvent, but without it being carried everywhere and stored in event repositories. Currently the values of the “type" attribute are a closed enumeration:voevent, url, rtml, and ivorn. In VOEvent2, this is expanded to an open form, properly specifying the semantic nature of the linked resource. For example:

<Reference
type="http://ivoa.net/rdf/formats#fits-image"
uri="http://…./sw0041000msni0284.fits"/>
identifies by the type attribute that the reference is to a FITS image. A private vocabulary could also be used:
<Reference
type="http://my.home.page/definitions#36"
uri="http://my.home.page/images/7463736252.jpg"/>

to say that this is a Johnson V-band image of a globular cluster -- since that is what ‘definition#36' resolves to. The typing of the link can always be resolved if you are unfamiliar with it to a humanreadable description. This means that parameters and hypotheses in the packet can be defined in the formal terms of the Semantic Web, rather than just natural language descriptions of what the data means.

In VOEvent, it is always recommended that big data be linked rather than included in the VOEvent. Small data objects can also be linked in this way. However, in many cases (eg a 3x3 table), there may be reasons to include it directly with the packet: perhaps the event author does not wish to set up a web server and guarantee permanent links, and perhaps the intended recipients cannot fetch URL links. Therefore, in this paper, we are considering a way to put structured data in the VOEvent packet that are small, in the above sense.

<What>
The <What> element is to contain data from a vocabulary that is specific to a given event, or type of event. In the VOEvent model, parameters are defined in the <What> section through a text description, UCD, unit, etc so that event consumers can know precisely what is meant, for example

<Param name="Sun_Distance" value="132.21"
unit="deg" ucd="pos.angDistance">
<Description>Angular distance from the sun to the event position</Description></Param>

Thus the Parameters, and a mechanism for grouping them, can be used by an author to define precisely the data they wish to express. Parameters can also be collected into a <Group> element, to make relationships clear. For example a quantity and the error in that quantity can be Grouped together to show their close connection.

Learning from the past: the FITS format
In moving forward with VOEvent, we may be able to take lessons from the FITS standard. While there are still matters of concern, FITS has been remarkably durable and effective, with essentially all working astronomers having some knowledge of it. FITS is therefore a model to be imitated.

The metadata object of a FITS file is a keyword-value pair, similar to the <Param> construct in VOEvent, except that the FITS metadata describes a multi-dimensional array, and the <Param> describes an event. There is no schema or complex data model inherent in the way that FITS metadata is kept, nothing but names and values. Yet structure and standards emerge when a community uses this clay to build data and tools. The keywordsBITPIX, NAXIS, NAXIS1, NAXIS2, etc are in all FITS files to explain how to read the data array, just as VOEvent has sky position and time as requirements for all events. Some conventions have become very widespread, for example the WCS keywords CTYPE1, CRVAL1, CD1_1, etc that define how the data array maps to the sky.

However, a FITS file is not fully machine-readable, in the semantic sense. There is no widely-accepted way to find the meaning of the keywords: the file says FWDX3=253, but the term is not defined. Some attempts have been made to build a formal dictionary, for example [4], but nothing is widespread. In VOEvent, we intend to correct this problem, as described in the next section.
Event Stream
In order to control the collection of Parameters used in the <What> section, the concept of “Stream" has been proposed [5], which separates the definition of the Parameters from their values. This provides for authors to build a registry of the keywords (i.e. Param and Group names) that will be used in their events, with machine-readable descriptions of each. This we call an event 'Stream', which will be available through the IVOA registry. So this is the bargain: in exchange for a universal way to find the meaning of all the keywords, all the keywords must be defined in the Stream, and event providers cannot simply use new keywords without updating the Stream record.

The idea is that all VOEvents that come from a specific instrument or project will all have the same structure, so that parameters and their meaning are defined in advance, and kept in the VO Registry for reference. Then when an event is actually issued, only the parameter name, group, and value are needed.

However, Parameters are intended only for primitive data objects (float, integer, string etc), and we might consider an additional more complex, structured object as part of VOEvent 2.0. In this note, we collect use cases from different projects to ask if the current and proposed VOEvent structure can carry the kind of data objects that the authors wish to express. The intention is to use these use cases as a way to understand what extensions might be added to the VOEvent 2.0 specification. We take several examples from published reports in the Astronomer’s Telegram, also called ATEL [14].

Use cases for complex data
• Light curve

Crucial information about a celestial object is contained in its light curve, which is a history of its (photon) output. Machines can extract the light curve and make decisions on the nature of the source. For example, from ATEL 2323, we find this light curve:

Date (start/stop) Exposure Ph.Index F(2-10 keV)
[ks] [erg/cm2/s]
---------------------- -------- ----------- ----------
2009-12-01 16:38-16:56 1.0 1.58+/-0.05 1.14e-10
2009-12-02 00:30-00:50 1.2 1.56+/-0.05 1.32e-10
2009-12-03 15:25-15:40 1.0 1.60+/-0.06 1.22e-10
2009-12-04 00:43-02:43 2.7 1.52+/-0.03 1.58e-10
Another light-curve (ATEL 2289) shows information in addition to optical magnitude, the distance, phase, number of observations, and names of observers.
UT Date r(AU) d(AU) Phase R_mag Exp. Observers
-----------------------------------------------------
Oct 10 1.090 0.289 64.2 15.37 34 Barajas
Oct 11 1.085 0.276 64.6 15.28 38 Foster
Oct 17 1.056 0.202 67.7 14.79 31 Somers, Hicks
Oct 22 1.031 0.150 72.2 14.10 53 McAuley, Shitanishi
There are many examples of small light curves that can be found in the Astronomers Telegram or CBAT notices, so this is an important use case.
• Object list
We consider some requirements forming within the LSST group [6], where some suggestions (L. Jones) include this:
• RA/Dec ± dRA/dDec of diasource
• Mag ± dMag of Diasource
• LSST catalog objects (stars/galaxies) within X " of this RA/Dec (median mag in ugrizy and rms mags or other variability info in catalog, plus their RA/Decs, plus their star/galaxy likelihoods)
• other diasources within Y" of this RA/Dec in the past Z number of days (their Ra/Dec/mags)

Here we see the suggestion that the event report should contain a list of nearby objects in the sky, and another list of observations of the objects nearby in time. Other examples of object lists could come from listing known nearby galaxies or radio sources, as these can change the priors for the classification process.
• Frequency series
The LOFAR [7] radio antenna array will be coming to full operation in 2010, and the team, in preparation for routine publication of radio transients, has defined an event template (an event “stream") for those transients. What they wish to publish is a set of radio frequency bands, each defined by a minimum and maximum frequency, and flux density. While the current stream has just two bands (Band1 and Band2), there is a desire to have multiple bands. This could be described as a table, with columns: min frequency, max frequency, and flux, and a row of the table for each band.
• Ephemeris for a minor planet
A major driver for research in transient astronomy is the discovery of Near-Earth asteroids. After discovery, an ephemeris is published, being the future position of the asteroid as a function of time. The Minor Planet Center has a service to compute such ephemerides, with results like this:

Year day h min ----RA---- ---Dec--- elong mag RA(sec/min) Dec(sec/min)
2010 03 17 12 09 22 38.3 +44 17 19 126.4 20.6 -0.19 -2.60
2010 03 17 16 09 22 35.4 +44 06 55 126.4 20.6 -0.18 -2.60
2010 03 17 20 09 22 32.6 +43 56 30 126.3 20.6 -0.17 -2.61
2010 03 18 00 09 22 29.9 +43 46 04 126.3 20.6 -0.16 -2.61
2010 03 18 04 09 22 27.4 +43 35 38 126.3 20.6 -0.16 -2.61

The detection and follow up of such unknown asteroids is a major driver for funding transient surveys, and should therefore be expressible with VOEvent. Such a time series does not contain observations, only predictions; so we would not expect, for example, anything about the observational equipment or filters used, since no observations have been taken.
• Classifications for asteroids
In ATEL 2372, there is a set of possible classifications for a newly discovered asteroid, based on comparison between spectra. The asteroid is classified according to its closest spectral match among known asteroids:

MISFIT OBJECT NAME
0.61 93 Minerva
0.97 3192 A'Hearn
1.10 1017 Jacqueline
1.13 1041 Asta
1.18 5294 Onnetoh TAXONOMIC CLASS (THOLEN) (BUS) CU C C C C X
• Probability density from gravitational wave detector
The LIGO project [8] is building software pipelines to create alert events for the broad community, in case of a discovery of a burst or inspiral source. Given that the detection comes from four instruments with different locations, orientation, etc, it means that the sky localization is not compact, but rather is a probability map over a wide area [9]. The LIGO team is already developing a representation of this probability density in terms of a set of “tiles”, each 0.5 degrees square, with an associated probability. Thus a LIGO event will include this table of tiles, from which follow-up observers will derive an observing plan.
Representing the use cases
With existing VOEvent structure
In this section, we will describe how each of the use cases could be met within the existing VOEvent (v1.1) data model. We also consider the “stream" concept (as represented by the VOEvent registry infrastructure [5]) to be part of the existing data model.
• Light curve
Each column in the light curve can correspond to a Param element in the<What> section and each row in the table to a Group of these Params: for example, the first row becomes an object called “row1”:
<Group name='row1'>
<Param name='Date' value='2009-12-01 16:38-16:56'/>
<Param name='Exposure' value='1.0' unit='ks'/>
<Param name='Ph.Index' value='1.58+/-0.05' unit=''/>
<Param name='F(2-10 keV)' value='2009-12-01 16:38-16:56' unit='erg/cm2/s'/>
</Group>
Unfortunately this means that all the rows have their own name, and it breaks the Stream model, since each possible Group name would need to be defined there, and they are potentially unbounded: row1, row2, row3, ….
• Object list
Two types of list are specified in the use case: a list of nearby objects in space (within 30 arcsec.), and a list of the objects nearby in time (observations of objects within the last 24 hours). The first type can be addressed using the same approach described in section 3.1.1 by mapping each object to a Group of Params, one for each object attribute, although, as noted above, it would not be possible to build a Stream record for that structure.
• Frequency series
The table can be represented as in section 3.1.1 with each band (row) corresponding to a Group containing Params for min frequency, max frequency and flux, although, as noted above, it would not be possible to build a Stream record for that structure, unless the number of frequency bands to be used is locked in at the Stream level.
• Ephemeris
Philosphically, the correct section for this type of information is the <WhereWhen> section since it relates to targeting in spacetime. Rots [10] describes how this can be achieved within the framework of STC (Space Time Coordinates, [11] ). See also [12] , for an example of an ephemeris representation that uses over 300 lines of XML for three lines of ephemeris.

Classification for asteroids
Philosophically, the correct section for this type of information is the <Why> section since it deals with scientific characterization, in this case, the set of possible classifications for a newly discovered asteroid. Each possible classification would correspond to a separate <Inference> element. One problem is that the only way to express a quantitative measure of the plausibility of a particular<Inference> is through its “probability" attribute, which takes a floating-point value between 0.0 and 1.0 (inclusive). In the use case, however, the plausibility of each classification is specified through the value of the “misfit" parameter, which is some goodness of fit measure. These values could be represented in the <What> section as a set of Params but this is not likely to be a list of known cardinality and so, as above, it cannot be described in the stream specification.
• Probability density map
As noted above, the LIGO team have decided to represent the density sky map as a collection of tiles, perhaps 0.5 degree square, each with probability and other information. Each tile could then be expressed as a Param or Group of Params in the <What> section, although (as above) this cannot be expressed in the stream definition because of the potential unknown cardinality of the list. The more natural location for this information is in the <WhereWhen> section and although STC can represent footprints, it does not associate probabilities with these, so it would be difficult this way.

By extending VOEvent 1.1
VOEvent is intended to be both structured and pragmatic and, although it is possible to meet many of these use cases with the existing data model, the resulting representation tends to be rather unwieldy: for example, a Group of Params for each row in a table. The open-ended nature of (tabulated) lists is also somewhat at odds with the required cardinality imposed by the stream model and so limits the amount of validation that the stream concept facilitates. Finally, there are areas where the current VOEvent data model does not meet the requirements of the use case and an extension is necessary.

It should be noted that one alternative solution to representing the data indicated by all these use cases is to simply include the text, much as it is represented above. This would allow humans to see the data, in much the same way as they do now when reading an ATEL or CBAT notice; but it does not give machines meaningful access.

An existing schema for tabular data
All the use cases in section 2 can be met by extending the VOEvent 1.1 data model to include a simple representation for tabular data. VOTable [13] is the default IVOA standard for representing tabular data but is perhaps too complex for these purposes (certainly not all features of it are required here) and is known to have a history of validation and code-binding issues. For these reasons, other IVOA WGs have defined simple tabular representations, e.g. TableSchema in the VODataService standard from the Registry WG.

A very simple table schema is available as part of STC [11] . Another advantage of using the STC is that existing rigorous standards for space-time coordinates, already used in VOEvent, can also be used for subclasses of the table, such as light curves and other time series.

<STCTable xsi:schemaLocation="stcTab.xsd
http://hea-www.harvard.edu/~arots/nvometa/v1.30/stcTab.xsd">
<Table>
<!-- Header definition -->
<Header>
<TH id="Time">Time</TH>
<TH id="FDVal">FluxDensity</TH>
<TH id="FDErr">FD Error</TH>
</Header>
<!-- and table body -->
<TR><TD>123.4</TD><TD>56.7</TD><TD>.98</TD></TR>
<TR><TD>133.4</TD><TD>46.7</TD><TD>.98</TD></TR> <TR><TD>143.4</TD><TD>36.7</TD><TD>.98</TD></TR> <TR><TD>153.4</TD><TD>26.7</TD><TD>.98</TD></TR> <TR><TD>163.4</TD><TD>16.7</TD><TD>.98</TD></TR>
</Table>
</STCTable>
Conclusions
Use cases from across the community provide a requirement to represent tabular data/information within a VOEvent packet. Although some of these can be met within the framework of the existing VOEvent data model using deconstructed representations, these are not largely pragmatic. There also remain a number of use cases which cannot be met in this manner. Therefore it seems reasonable to propose extending the VOEvent 1.1 data model in the following manner:
• Introduce a simple tabular representation based on the existing tabular construct within the IVOA STC specification as another allowed element within the<What> section.
• Open the “type" attribute of the<Reference> element to take a URI value. This allows any reference to an external resource to be semantically typed and so arbitrarily (large) complex data constructs can be linked to in a meaningful manner.
• Add an additional attribute to the<Inference> element in the<Why> section to allow a more general plausibility measure to denote goodness of fit, etc.
References
[1] http://www.ivoa.net/Documents/latest/VOEvent.html
[2] Astronomer's Telegram, http://astronomerstelegram.org
[3] Central Bureau for Astronomical Telegrams,
http://www.cfa.harvard.edu/iau/cbat.html
[4] http://iraf.noao.edu/projects/ccdmosaic/imagedef/fitsdic.html
[5] http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEventStream-0.2.html [6] http://www.lsst.org/
[7] http://www.lofar.org
[8] http://www.ligo.org
[9] A.C.Searle, P.J.Sutton, M.Tinto, G.Woan Robust Bayesian detection of unmodelled bursts, http://arxiv.org/pdf/0712.0196
[10] Rots, A., 2009, XML for MPC Ephemerides and other Time Series,
http://www.cacr.caltech.edu/hotwired2/program/presentations/MPCTimeSeriesRots.pdf
[11] http://www.ivoa.net/Documents/latest/STC.html
[12] http://hea-www.cfa.harvard.edu/~arots/nvometa/STC/MPC.xml
[13] http://www.ivoa.net/Documents/VOTable/

2.3 Time Series in VOEvents

John M. Brewer
San Francisco State University, University of California, Berkeley Joshua S. Bloom
University of California, Berkeley

Here we present the SimpleTimeseries semantics and an XML realization, intended to serve as the standard mechanism for representing time series data within VOEvent. In addition to marking up traditional light curves (flux or magnitude changes with time), SimpleTimeseries has been designed to allow publishing of phased light curves, space motion, Doppler shift, and even gravity wave strain measurements with minimal software investment. It is relatively simple to construct and even read and yet can be strictly validated by standard parsers.

Motivation
Synoptic surveys are transforming astronomical data collection from static photoshoots of the night’s sky to full-scale cinematographic productions. The ensuing data deluge presents new opportunities for scientific exploration of transients and variable stars but also new challenges. A crucial component to the efficacy of these pursuits is the timely dissemination of new discoveries.

Thankfully, VOEvent[1] provides a standard messaging protocol to describe celestial transients at an instance of time. However, for the recipients of event discovery to use their precious telescope time to follow up sources of interest to them, increasingly they will place the onus on the discovery engines to publish light curves of the events. These light curves -- and the ones created from followup observations
-- will serve as cornerstone of classification and inference.

The Berkeley Transient Classification Pipeline (TCP)[2,3], currently working with data from the Palomar Transients Factory (PTF)[4], is a project whose goal is rapid classification of astronomical transients from image difference data. Data captured at the telescope is sent through an image subtraction pipeline and light curves of any changing sources are forwarded on to TCP. After classifications are made, interesting candidates are sent on to a follow-up marshal that decides wether and how to allocate additional resources. The SimpleTimeseries XML format was designed, in part, with these needs in mind. Recognizing that a format that could handle more than just light curves would also benefit the larger astronomical community, we worked with the VOEvent working group to make our nascent format a standard.

Overarching Goal: Simplicity and Applicability
Time series have been published for centuries, but there is, as of yet, no canonical representation. Ten different astronomers are likely to publish nearly identical light curves in at least 10 slightly different formats. To manage and react to the enormous expected data flows, a predictable and standard time series format is crucial. Custom programming should not be necessary in order to parse the data stream from each new provider.

Figure 1. Sample output of a light curve in SimpleTimeseries format when viewed in a web browser. An XSL stylesheet could also render a plot of the light curve in addition to the data table.

Goals
Based on our experience with TCP and conversations with the VOEvent working group, we identified several key requirements for a time series format:
• Human and machine readable
• Light weight and easy to implement
• Extensible for time series data beyond light curves
• Integrates with existing standards
• Simple machine validation of data products

Efforts such as the IVOA Spectral Data Model [5] provide a way to represent time series. However, by allowing a high degree of flexibility in data representation, custom coding is required to ensure data integrity for each new data publisher. SimpleTimeseries provides a flexible model for time series, but in such a way as to enforce consistency and ease machine readability via the XML schema. By using XML it is also possible to provide style sheets to display the data in multiple human readable formats.
A SimpleTimeseries Light Curve
At the time of this writing, SimpleTimeseries is undergoing final revisions to better fit within VOEvent and comply with best practices established by the VO. The example below provides a good overview of how you can use SimpleTimeseries, but for the most up-to-date schema, please visit http://dotastro.org/simpletimeseries.
Structure
SimpleTimeseries is an XML format consisting of four major components:
• Time system (TIMESYS)
• Band Passes or Filters (BAND)
• Field Descriptions (FIELD)
• Time Series Data (SERIES, ELEM, TIME)

The most complex component is the time series data, though the only required axis in a SERIES isTIME. The first three items can be thought of as all of the meta-information which describes your data. This enables the data to be described by a relatively straight forward and space-conserving format. Each of the meta-data elements itself is described by Virtual Observatory Uniform Content Descriptors (UCD)[6]. In general, machine readable data are contained in attributes, and human readable data are stored as element values.

TIMESYS
TheTIMESYS element is a container which holds the definition of the time system. This includes the type of time system used (ie barycentric Julian days), any zero-point offset, the units of time used in the data (ie days, seconds, etc.), default integration time, wether the data is period folded rather than using absolute times, the time scale, and the reference location for the time.
<TIMESYS>
<TimeType ucd="time;pos.frame;pos.heliocentric" unit="day">
hjd
</TimeType>
<TimeZero ucd="time.epoch;arith.zp" unit="day">0</TimeZero>
<TimeUnits ucd='time.epoch' datatype='float' unit='day' />
<TimeWidthDefault ucd="time.period" unit="seconds">
10.0
</TimeWidthDefault>
<TimeSystem ucd="frame.time.scale">TDB</TimeSystem>
</TIMESYS>
BAND
For most time series, the band pass in which the data was recorded is almost more important than the data itself. AllFIELD elements require a reference to aBAND.
<BAND ucd="instr.filter;em.opt" bandid="I"
description="The Johnson-Cousins I-band">I</BAND>
<BAND ucd="instr.filter;em.opt" bandid="V">V</BAND>

The required UCD provides standard machine readable information. The value of the element is a human readable label, and a brief description can be stored in the description attribute. An optionaluri attribute can also be used to link to a more thorough treatment of the filter characteristics.
FIELD
Data in the series is identified by a reference to a FIELD not by its position in a table. This reference makes it trivial for a machine to quickly and accurately identify the data, its type, and the band pass it was recorded in.

<FIELD fld="imag" bandid="I" ucd="opt;phot;i" datatype="float"
unit="mag">I-band photometry</FIELD>
<FIELD fld="vmag" bandid="V" ucd="opt;phot;v" datatype="float"
unit="mag">V-band photometry</FIELD>
SERIES
Like TIMESYS, SERIES is just a container. WithinSERIES lie one or moreELEMs which hold data relating to a particular timestamp.ELEM in turn contains the mandatoryTIME element and zero or more values, each of which must reference a FIELD. A single FIELD may only be referenced once in each ELEM. Unlike a traditional table, the field references make it necessary to include only data values which were actually recorded. This saves space and reduces the proliferation of ‘no data’ proxies (such as 9999.99) which currently pepper astronomical time series.

<SERIES>
<ELEM row='1'>
<TIME><T>2448919.8</T></TIME>
<MAG fld="imag"><VAL>17.535</VAL><ERR>0.03</ERR></MAG>
<MAG fld="vmag"><VAL>17.327</VAL><ERR>0.03</ERR></MAG>
</ELEM>
<ELEM row='2'>
<TIME><T>2448922.82</T></TIME>
<MAG fld="imag"><VAL>17.697</VAL><ERR>0.032</ERR></MAG>
<MAG fld="vmag"><VAL>17.424</VAL><ERR>0.03</ERR></MAG>
</ELEM>
<ELEM row='2.5'>
<TIME><T>2448923.87</T></TIME>
<MAG fld="vmag"><VAL>17.493</VAL><ERR>0.032</ERR></MAG>
</ELEM>
<ELEM row='3'>
<TIME><T>2448925.86</T></TIME>
<MAG fld="imag"><VAL>17.933</VAL><ERR>0.039</ERR></MAG>
<MAG fld="vmag"><VAL>17.603</VAL><ERR>0.03</ERR></MAG>
</ELEM>
...

Value elements can be one of position ( POS_EQ and POS_LB), double precision floating point value (MAG, FLUX, and DVAL), or string (NOTE). The position elements for instance, group RA and DEC with their uncertainties to aid readability. Each of the numerical value elements can have 0, 1, or 2 error values and can be designated as upper or lower limits in addition to measured values.

<MAG fld="vmag" limit="upper">
<VAL>17.535</VAL>
<ERR>0.03</ERR><ERR>-0.06</ERR>
</MAG>
The NOTE element is designed to allow attaching human readable notes about data quality, authorship, seeing, etc. to the data. An integer code can also be included in theNOTE to aid machine readability. Conclusion
The strength of SimpleTimeseries lies in its singular focus, simplicity in construction, and strictness in validation. As long as there is a time axis, it will be easy to publish and consume everything from transient light curves, the apparent motion of an asteroid, a gravity wave strain measurement of a neutron star coalescence event, or even just a list of upcoming observing times. The inclusion of SimpleTimeseries in the VOEvent standard enables a richer understanding of the event without the need for human interaction or extensive custom programming.
Acknowledgements
We would like to thank A. Allen, B. Denny, P. Kubánek, A. Rots, R. Seaman, D. Starr, R. Williams, and the participants of the HotWired II VOEvent Working group meeting for their invaluable assistance. Their contributions have made SimpleTimeseries into a robust and easy to use time series standard.
References
[1] Seaman et al. Sky Event Reporting Metadata (VOEvent) Version 1.1
http://ivoa.net/Documents/latest/VOEvent.html (http://voevent.org)
[2] Bloom et al. Towards a real-time transient classification engine. Astronomische Nachrichten (2008) vol. 329 pp. 284
[3] Starr et al. Real-time Transient Classification and Broadcast Pipeline. Astronomical Data Analysis Software and Systems ASP Conference Series (2008) vol. 394 pp. 609
[4] Law et al. The Palomar Transient Factory: System Overview, Performance and First Results. arXiv (2009) vol. astro-ph.IM
[5] McDowell et al. IVOA Spectral Data Model Version 1.03
http://www.ivoa.net/Documents/latest/SpectrumDM.html
[6] Martinez et al. The UCD1+ Controlled Vocabulary Version 1.23 http://www.ivoa.net/Documents/latest/UCDlist.html
3 Software for VOEvents

This chapter describes tools and web services for managing events and networks. Skyalert is a web-based system for authoring and disseminating events, and the second section is about a VOEvent library in Python. The third section discusses an iPhone app for a specific event stream (CRTS), and finally there is a way to build a VOEvent transport infrastructure.
Photo Credit: Flickr/Lord Nibbo
3.1 Event Handling with SkyAlert
Roy Williams
California Institute of Technology
The Skyalert project collects and disseminates observations about time-critical astronomical transients, and adds annotations and intelligent machine learning to those observations. The information can be “pushed” to subscribers, who may be either humans or machines that control telescopes. Subscribers can prepare precise “triggers'” to decide which events should reach them and their machines, that may be based on the generic event, or on the specific vocabulary of parameters that define a particular type of observation. The system will not be centralized, but rather a set of interoperating nodes with caching. The twin thrusts are automation of process, and discrimination of interesting events.

An important qualitative change is happening in astronomy. The ability to survey large areas of the sky deeply and repeatedly, and to process the data in real time, has opened a whole new field of research: time domain astronomy. The sky is now studied as an ever-changing collection of dynamical phenomena, with moving objects, objects that change in brightness, or those that appear in an explosive manner. Many of these phenomena can be understood only through time-domain studies, and often require a rapid follow-up using a variety of ground-based telescopes.

Events are Universal: The ideas here apply not just to astronomy, but in other areas of society where events must be followed by rapid, often expensive actions. In all cases, it is good to keep the data and those evaluations in a structured manner—what we call a portfolio. The components of Skyalert are:
• A web-based event broker, allowing subscription so that events are delivered in near-real time.
• A web-based publishing system, so that authenticated users can inject events that may be delivered to others.
• An event repository, storing all events that come through the broker, and allowing bulk queries and drill-down.
• An interoperable event broker, conforming to international (IVOA) standards for event services.
• Open-source software to allow local implementations as well as the web-based application.
Skyalert.org [1] is a prototype system that has handled many different event streams. It is designed to work well with amateur astronomers and students, as well as professional astronomers scheduling followup on the big NSF-funded telescopes, operated by NOAO and its partners, or on the emerging worldwide robotic telescope networks.
Skyalert Design Goals
Many new event streams are coming online or are planned for the future. Thus, it is time to deploy a system that can work with events in general, rather than a custom solution for each survey or spacecraft. The system should encourage adoption of a standard framework and interoperability, avoiding duplication of effort in implementing similar systems.

From the web interface, subscribers can arrange to get event packets immediately (“pushed”). Users can build “alerts” consisting of a trigger and an action. Whenever an event is injected, it is tested against the trigger, and if it passes, then the action occurs. Actions can be messaging (email, IM, robotic telescope), fetching from archives, or running a computation. One objective of Skyalert is to encourage robotic follow-up in near real time to catch the most exciting, largely unknown, physics of rapid transients. Once such observations are made, we will encourage submission of that data to Skyalert as events, which will be added to the web page for the original event, and of course the follow-up event can be sent to subscribers and other event brokers.

Authors of events build semantic content in advance, through an “event stream”, which expresses the common metadata shared by all the events that belong to that stream[2]. The stream has a description of these events, and semantic definitions of the parameters that will be used to describe each event of the stream. There can also be a template-builder to define the “Overview” presentation of the event. Streams can be private or public, with access roles according to owner, group, and public. Authors can gain trust by injecting and removing “test” events in a private stream.

Figure 1: Here is the concept of Portfolio. This example portfolio from Nov 9, 2009, shows several events: (1) the original observations from the CRTS survey (top gray bar), (2) a robotic follow-up observation from the New Mexico Skies observatory 18 minutes later, (3) a human assessment of the meaning of the portfolio, and (4) a collection of archival results. A Portfolio can also contain events from data mining modules, a sort of a “computational follow-up”, where complex data is reduced to a simple quantity. Here (5) four images are analyzed for motion.

Each event will have a collection of data that we call a portfolio of data: a collection including spectra, cutouts, etc, from many different surveys and observations. A portfolio is defined through a citation mechanism inherent in the VOEvent packet [3], where one event can cite another. Thus an event with no citation becomes its own portfolio, but an event with a citation to another joins the portfolio that the other is in.

Skyalert integrates multi-sourced heterogeneous data, so long as the event author builds the metadata (event stream) through the web-based authoring interface. The evidence is thus collected, for past evidence of variability, for nearness to a galaxy, for excess infrared flux, and so on, that can help to classify that source. The data will be available not only to human clickers, but also through an Annotator API, which will be called in real time for data mining when the event is injected to Skyalert.

Skyalert allows events to become part of conversations in both traditional and new social media. One priority will be integration with the Central Bureau for Astronomical Telegrams [4], the Minor Planet Center [4], Astronomers Telegram [5], etc. Other media, such as Twitter, Facebook, Second Life, Google Wave, etc, should be used as places for humans and machines to see and comment on events. Skyalert also offers recent events in modern formats: Twitter, Facebook, Microsoft Worldwide Telescope, Google Sky, etc.

Skyalert allows software components called annotators, which can analyze the existing portfolio and add new data to it, for example fetching archival images, or comparing FITS images to detect motion of a source, or reduction of a spectrum to a single number of interest. These high-level criteria can then be used to trigger action, as with any other parameter in the portfolio.
Skyalert will be part of an emerging international infrastructure of astronomical transients using the VOEvent protocol [3]. There are now many streams and many follow-up facilities, and a general agreement to use the “VOEvent” protocol for representing and communicating astronomical transients. The system will use the international distributed Registry of the Virtual Observatory to enable publishing and discovery of event streams [2], so that all interested parties can subscribe to future events and browse past events from that stream. When a new event stream or service is created, its detailed metadata will be written and recorded by the author in a standard way.

Skyalert has a detailed access policy, so that people can confidently use Skyalert in the early stages of a project, when events are for a small group only. Skyalert is also available to download and install locally, and is built on Django; it requires Python, a relational database such as MySQL, with web service provided by Apache.

Real-time follow-up observations are crucial to a full understanding of the science of transients. These authors are already collaborating with event providers, building new collaborations with providers of events, with the amateur astronomy community, and with owners of robotic telescopes.

Figure 2: Skyalert has several types of display and outreach. Above left is a display of recent events, with click-through to detailed portfolio. Below left is the full sky with recent events, shown with Microsoft Worldwide Telescope. WWT can show many image surveys, and access NED, Simbad, and other catalog resources. At right are the Twitter and Facebook streams, with detections automatically broadcast from the reduction pipeline, and also the human-built interpretation several hours later.
How to Use Skyalert
Event and Stream Browsing
The front page of the Skyalert web page shows graphically the most recent portfolios and which streams have been active (see Fig 2, top left) . Recent events can also be seen by selecting a specific stream (“browse event streams”), and selecting portfolios from there. Each portfolio is shown as a collection of events, and each event can be seen in different representations. Fig 3 shows a portfolio display: by hovering the mouse over each event, different representations can be chosen: Overview, or Params, or raw XML.

Figure 3: The portfolio display shows each event of the portfolio as a gray bar (four events here), and for each event there are three representations: Overview, Parameters, and Raw XML. The sky images here are part of the Overview of the CRTS event. The portfolio can also be viewed in Microsoft Worldwide Telescope (top right).
Available event streams (as of Jan 2010) are shown in the screen shot of Fig 4. For each stream, you can see the semantics and description, or go to the portfolios that are instances of that stream.
Figure 4: Some event streams whose metadata has been ingested to Skyalert.
The semantics part of the stream describes the stream and its author, and has a list of parameters that describe an event of that stream. Parameters can be grouped, and each has a description, units, data type, and UCD (Unified Content Descriptor [6]). Parameter values that are URLs are identified with a UCD meta.ref.url, indicating that the data content is not in the value itself, but is a complex data object under the link.

Creating Alerts
An alert is a combination of a Boolean trigger expression and an action: the trigger decides if the action will happen. Each trigger runs on each portfolio as soon as it can, but not all triggers can run on all portfolios; a trigger needs a specific set of streams before it can run. For example, am alert may need an event from stream A and one from stream B: the A stream may be the newly-discovered transient, and the B events come from an annotation. Other triggers may require only a single event from a single stream. In any case, whenever a new event is added to a portfolio, that portfolio is checked against all triggers to see which can run.

When creating a new alert, Skyalert needs to know which event streams are necessary to run it. If an alert needs multiple streams, multiple selections can be made in the usual OS/browser dependent ways. A trigger is a boolean expression written in Python, for example:
CRTS["First Detection params"]["magnitude"] < 17
and event["role"] != "test"
which is looking for bright transients detected by the CRTS stream (Catalina Real-Time Survey), which are not test events. In the forms for creating alerts, the parameter names are ‘live’, meaning that clicking on a parameter name inserts the relevant text in the trigger expression. When the expression is complete, click the Save button, which evaluates the expression and reports back any syntax errors.

Once the trigger expression is saved, another button (“See Events”) shows all the previous portfolios that satisfy it. At the top of the form is information about what action should take place. Currently the only action being publically offered is the email alert.
Authoring an Event Stream
Skyalert accepts reports of astronomical transients or information about them, using the VOEvent XML format. Injecting such data requires careful thought and some interaction with the Skyalert team. Before sending events, the meaning of the parameters should be defined. The authoring workflow is as follows:

1. Design the stream. Think carefully about what data you want to expose in the event. Some parameters are numbers and strings, and can be used to make decisions; some parameters are URLs that link to complex data objects. To help you design a stream:

• Look at the existing event streams at skyalert.org (OGLE, Catalina, SWIFT, etc). At the bottom of each stream detail page is a sample event from that stream.
• Look at the annotated sample VOEvent. All the gray text is boilerplate, the essentials are highlighted in yellow. Make sure you move the mouse over each highlight to see the explanation.
• Work with the Skyalert Team (write to help@skyalert.org) to create a sample event that shows your parameters, each with description, unit, semantic descriptor (UCD), data type (int, float, string).
• You can include complex data objects with a Param whose value is a URL link. In this case, make sure the UCD of that Param is meta.code.url so that Skyalert knows it is a URL.

2. Upload your stream. This will be done by Skyalert staff (help@skyalert.org), using the agreed sample event, which has all the metadata. You will be asked to check that your stream appears correctly in the web interface. If you are running your own Skyalert system, you can login as an account with staff status and do this yourself.
3. Test Events. Build code that can create events from your event stream. It is important that test events be labeled role="test" in the first element of the VOEvent, so they are not mixed with real astronomy.
4. Send events to Skyalert. You can send events, by arrangement, to a remote Skyalert server, including the one at skyalert.org. This is done through a popular Instant Messaging protocol (XMPP also known as Jabber [7]). There is software (Java or Perl) on the Skyalert site that will inject new events.
How Skyalert Works
Figure 5 shows the architecture of the system. Portfolios of VOEvents are stored in a database, with a web front end. The web application can also be used to set up streams for authoring, and to set up triggered subscriptions for real-time delivery. It is not only messaging that can happen as a result of a trigger being satisfied, but any other kind of code; in fact there is an Annotator API which allows access to an existing portfolio, then the creation of a new event and injection into the system.

When an event arrives, either locally through the loader interface, or remotely through the XMPP interface, several things happen. The event is checked for correct XML syntax, and that it conforms to the VOEvent schema, then the parameters and other information is extracted and cached in a relational database. If the event has a citation to another event, and that other event is in the database, then the new event joins the portfolio of that other. Next, we take all the alerts that are in the system, and decide if the new event should cause any action.

Note that we have a cyclic workflow here: arrival of event A can cause an action to run which injects a new event B, and so there is a possibility of infinite runaway. In order to prevent this, event streams have an ordinal number (1, 2, 3, …), and a rule requiring the triggering event (such as A) to have a lower ordinal that the consequent events (such as B). Thus we assign ordinal 1 to events that come ab initio, from the sky, and ordinal 2 to those that are created as a consequence of that, and so on, so no infinite cycles can occur.

Figure 5: Interactions with Skyalert: (1) Browsing the events and streams, (2) Authors inject new events (3) Subscribers get immediate notification, (4) Annotation components can respond to new events with arbitrary actions, including injection of new events.
Conclusion
Skyalert is a web-based or downloadable application for handling events in general, rather than special code for each event. It can display the events in many ways, collect relevant data into portfolios, run machine learning code, send messages, and do all this in near real time.

References
[1] Skyalert collects and distributes astronomical events in near-real time: http://skyalert.org [2] M. Graham and R. Williams, Finding VOEvent Resources, Section 4.2 in this book.
[3] R. Seaman, R. Williams, A. Allan, et al, Sky Event Reporting Metadata (VOEvent), IVOA Recommendation, http://www.ivoa.net/Documents/latest/VOEvent.html
[4] Central Bureau for Astronomical Telegrams, http://www.cfa.harvard.edu/iau/cbat.html, and Minor Planet Center, http://www.cfa.harvard.edu/iau/mpc.html
[5] Astronomer’s Telegram, http://astronomerstelegram.org
[6] S. Derriere et al, An IVOA Standard for Unified Content Descriptors, IVOA Recommendation, http://www.ivoa.net/Documents/latest/UCD.html
[7] Extensible Messaging and Presence Protocol (XMPP), a set of open XML technologies for presence and real-time communication developed by the Jabber open-source community, http://xmpp.org/
3.2 Python code-binding for VOEvent
Roy Williams
California Institute of Technology
VOEventLib is arranged as a package within a package. The outer level is the code binding technology used to build a parser from a documented XML schema, and the inner level is the actual parser, with a utility package, documentation, example code, and example events.
Parsing, Modifying, and Building VOEvents
VOEventLib is a reference implementation and parser for the VOEvent2 XML specification, now under discussion at the IVOA (Sept 2010). For more information about VOEvent, see VOEvent in wikipedia [1], or read the the VOEvent wiki at IVOA[2] or the draft specification of VOEvent 2.0 [3]. There is also the Skyalert web application [4] for publishing and dissemination of real-time astronomical events. First the parser itself (inner package). Use this command to get the software:
svn checkout https://ligo-vcs.phys.uwm.edu/svn/VOEventLib/lib
Once you have this directory tree, put the lib directory in your PYTHONPATH, then run and modify the example programs. The get and set methods of VOEventLib are all defined in the detailed documentation, which is too long to publish here, so we will discuss some of the example programs.
# parse the event from the file name
v = parse(filename)
# set the ivorn to something else
v.set_ivorn('ivo://sample/survey#123')
# set the author
v.get_Who().get_Author().set_contactName(['Mickey Mouse'])
# look for a specific param in the event
param = findParam(v, '', 'EVENT_ID')
if param:

print "old EVENT_ID is %s" % param.get_value()
# change the value of the param
param.set_value(873646)
# output to standard output
v.export(sys.stdout, 0)
The event is parsed from a sample event in the given file, then the IVORN changed using the set method. The contact name for the event is set – note that the schema allows multiple contact names, and therefore the argument of set_contactName is a list. Then a specific parameter is found and changed, then the modified event output. Other methods allow construction and modification of <Table> data, a new feature of the VOEvent 2.0 specification.
Automatic Code Generation from XML Schema
The other package contains the engine used to gbuild the VOEvent parser directly from the XML schema, and may be of more general use than just VOEvent. It uses a pure python package called generateDS to make the python code, together with Sphinx to autogenerate package documentation from the documented schema.

The package generateDS generates Python data structures (for example, class definitions) from an XML Schema document. These data structures represent the elements in an XML document described by the XML Schema. It also generates parsers that load an XML document into those data structures, and copies schema annotation into documentation of the python code (docstrings). This package was written by Dave Kuhlman. For more information see the generateDS web page.

Sphinx is a tool that makes it easy to create intelligent and beautiful documentation, written by Georg Brandl and licensed under the BSD license. It uses the embedded documentation in the Python code (docutils) to build the HTML documentation. For more information see the Sphinx web page.
Use this command to get this code-generation part of the software, and the VOEvent implementation that is built with it:
svn checkout https://ligo-vcs.phys.uwm.edu/svn/VOEventLib
The schema generates the code automatically
<xs:complexType name="Param">
<xs:annotation>
<xs:documentation> What/Param definition. A Param has name, value, ucd, unit, dataType; and may have Description and Reference.</xs:documentation>
</xs:annotation>
<xs:choice maxOccurs="unbounded">

<xs:element name="Description" type="xs:string"/>
<xs:element name="Reference" type="Reference"/>
</xs:choice>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="ucd" type="xs:string"/>
<xs:attribute name="value" type="xs:string"/>
<xs:attribute name="unit" type="xs:string"/>
<xs:attribute name="dataType" type="dataType" default="string"/>
</xs:complexType>

generates the methods and documentation shown below. Notice that the documentation element from the XML schema is correctly copied into the docstrings of the python code, and from there to the automated documentation of those methods.
class VOEvent.Param()¶
What/Param definition. A Param has name, value, ucd, unit, dataType; and may have Description and Reference.
add_Description(value)¶
add_Reference(value)¶
get_Description()¶
get_Reference()¶
get_dataType()¶
get_name()¶
get_ucd()¶
get_unit()¶
get_value()¶
insert_Description(index, value)¶
insert_Reference(index, value)¶
set_Description(Description)¶
set_Reference(Reference)¶
set_dataType(dataType)¶
set_name(name)¶
set_ucd(ucd)¶
set_unit(unit)¶
set_value(value)¶

3.3 An iPhone App for Transient Events
Bruce Truax
Diffraction Limited Design LLC
Abstract When the LSST comes online later this decade it should prove very efficient at discovering transient events in the heavens. Some of these transient events will be short lived or will move rapidly across the sky and will benefit from follow up observations by professional and amateur astronomers. Useful follow up can only occur if the interested observers can be made aware of the events in a timely manner. Under the auspices of the LSST program an iPhone application has been developed as a testbed for transient notification distribution. Using current surveys such as the Catalina Real Time Survey an iPhone app has been created which allows quick access to recent transient events and has the ability to send immediate notifications to users based on their interests.
The Goals of the Transient iPhone App
The Large Synoptic Survey Telescope (LSST) will provide a fire hose of transient events when it comes online in 2015: according to some estimates it will prove so effective at finding transient events that it may report thousands every night. Some of these transient events will be short lived or will move rapidly across the sky and will benefit from follow up observations by professional and amateur astronomers. There will also be many laypeople who will be interested in the transient events discovered each night. Part of the charter of the LSST is to disseminate the discoveries to interested parties in the astronomy community (both professional and amateur) as well as to the general public. The question of how best to distribute this information needs to be investigated well before opening the nozzle on the fire hose of discoveries.

Smart personal communicators such as the iPhone, Blackberry, Palm, and Windows Mobile devices offer an excellent method for dissemination of transient event information. Smartphones have the ability to provide a rich interface to information in an easy to use, always on and always handy device. These devices also have the ability to provide instant notifications to their owners. Creating client applications and a notification system for such devices allows interested individuals to be alerted to transient events almost immediately and the notifications can be linked to a summary display of information with enough detail to let an astronomer know whether they should leave dinner with their family and rush to the observatory.
One question which is often asked is “Why create an application dedicated to a device? Wouldn’t a web based solution which be more universal?”
Many content providers have sites specifically designed for mobile users. These sites reformat content in a way that better fits the smaller screens of mobile devices. A combination of email notifications and a mobile formatted site would be a potential alternative to building a transient event notification system and may actually be a worthwhile project on its own. The problem with this approach is that current web standards do not allow a browser-based approach to provide as rich and responsive an experience as a native application. Native applications have the ability to present the information formatted to take advantage of the strengths of a particular device. Additionally, there are internal device features that a native application can leverage. For example, almost all new smart phones have built in GPS (Global Positioning System). the local horizon. coordinates to a computer controlled telescope. A native application can also take advantage of local storage and download and store information for events of interest. This information can be viewed at a later time when the device is out of contact with a network. In summary, mobile versions of the transient A native application can use the GPS to determine if an event is currently above

One could even imagine using the Bluetooth capability of the phone to send repository web sites may be useful, but native applications can provide a much richer experience for the users.

Having decided to create a native application the next decision is the selection of the device. The device should be selected based on ease of development and a large, easy to reach user base that is a good match to the end user demographic being targeted. The platform must also have a good method for distribution of the software to the user.

The iPhone/iPod Touch platform does an excellent job addressing all these criteria. First, the user base is large and growing rapidly. If the application is written to work on both the iPhone and iPod Touch the current installed base is greater than 90 million units. The software development environment is very easy to use and the software API’s provided as part of the development kit makes it possible to develop applications quickly. Apple also provides a very convenient method for application distribution in their very successful App store.

Another plus for the iPhone platform is the recent introduction of Push Notifications. This allows iPhone and iPod users to receive rapid notifications of events very soon after they are submitted to the notification system. The push notification system provides a way to send events (at no cost) to any subscribed iPhone or iPod touch user. The notification appears as a pop-up alert on the screen with an optional notification sound and short message. These events can be tied to the application allowing it to quickly download data related to the event as soon as the application is launched.
The Transient Events Application
The Transient Events application on the iPhone provides users with a single, easy to use application for notification and review of transient events from multiple sources. The major goals of the application are listed below:

• Aggregate transient events from multiple sources
• Allow specification of filter parameters so only those events of interest are presented to the user.
• Notify users of new events as they occur
• Provide a quick method to scan all recent events of interest
• Allow the user to easily view detailed information for specific events

The purpose of the application is not to replace the existing web sites which provide very detailed information on each event but rather to summarize the important information and present it to the user on a portable device which they have with them at all times.

The LSST project will not be built and operating for several years, so we have chosen to build a prototype with an existing transient alert survey, the Catalina Realtime Transient Survey (CRTS)[1], which operates on three telescopes, two in the Catalina mountains in Arizona and one in Siding Spring, Australia. The CRTS events are served through event-handling software called Skyalert [2], which is delivering CRTS events to the Transient App. In the future, we hope to deliver other event streams in addition to CRTS.
Application Design from the Users Perspective
The iPhone is a combination of a Unix based computer with full time web access, GPS, orientation sensing, a graphical touch interface and of course, a phone. The challenge when designing an application is to utilize these features to provide information in a compelling way so that the application is used on a regular basis.

Simple to use
A well-designed iPhone application is simple to use and requires zero, or minimal instruction. By using the Apple supplied user interface elements in a manner that is consistent with other iPhone programs and by following the Apple Human Interface Guidelines, programs are often self explanatory. If custom designed interface elements are used their use should either be obvious or easily discoverable with experimentation. Simplicity also implies limiting features and avoiding too many complex options.
Responsive
The iPhone/iPod Touch platform uses a sub GHz processor for power conservation and it is limited to the available network speed that in the case of the telephone network in remote locations can be quite slow. Care must be taken when writing software for the platform not to allow the system to lock up because of long process steps or because the software is waiting on a network download.

It is not anticipated that the Transient Events App will perform any complex, time consuming processing steps but the data being displayed does need to be downloaded from the network which may, at times be slow. The recommendation for such situations is to download information in the background and update the views dynamically as the information becomes available. If possible, during the download process the user should be allowed to scroll through the completed data and even make selections. If this is not possible the user should be kept informed of the progress with a dynamically update progress indicator.

Responsiveness also requires that the data service be available 100% of the time. Since this application depends on a data repository for its content it is critically important that this information be available, otherwise the user will open the application and be presented with a blank screen.
Ability to use when no network is available
Having stated that the network data must always be available, there will be times when a user will want to use the software in a remote location when there is no network available. The two prime examples are iPod Touch users who only have network connections when in range of a WiFi hotspot and iPhone users who may be at a remote observing location that has neither WiFi nor cell phone service. To make the software useful when there is no network connection the user is allowed to bookmark interesting objects. When an object is bookmarked its overview and detail information are downloaded and stored on the device. If the user launches the application and the device does not detect an available network the user still has the ability to view bookmarked events.

Transient Events App Layout
The Transient Events application is a client application that displays event information from a source database. Upon launch the user is presented with a listing of recent transient events that meet a set of user defined criteria. Figure 1 shows a typical list of events. Each object will be displayed with a title, which is the event type (if characterized, if it has not been characterized then the type will simply state “Unknown”). Underneath the title will be the RA and DEC coordinates of the event and the time of detection in Universal Time. The title will be color coded to allow the user to quickly determine if the event is visible from the currently selected location. If the title is green the object is currently visible, if it is yellow then the object will be visible once it comes above the horizon (or above the minimum elevation angle if this parameter has been set) and if the title is red then the object never rises above the minimum elevation angle at this location. The location can be set using the built in GPS or by selecting a location from a built in list of observatories.
Figure 1. Event Listing
If the user is interested in a particular event they can touch the event taking the user to a detailed display of information. Figure 2 shows an example of the detailed data for a Supernova event. The detail display shows the event ID, coordinates, magnitude, event time and the Azimuth and Elevation coordinates. In addition, a series of images are shown which display the transient nature of the event. The transient area is highlighted with a box. The user can view the reference image and four of the current images by touching the forward and back triangles or simply by swiping the images left and right with a finger. There is also an option for viewing a detailed finder chart web page.
Figure 2. Event Detail
If the object is of interest the user can press the “+” symbol and add this event to a list of bookmarked events. When an event is bookmarked the data will be saved locally allowing the user to quickly retrieve the data in the future even if they are not connected to a network. Bookmarks are accessible by touching the Bookmarks icon shown in Figure 2.

The user can be notified of new events in three ways. If the application is running pressing the “Refresh” button shown in the upper right corner of Figure 1 downloads the latest list of events. Similarly, quitting and restarting the application reloads the latest list of events. The user also has the option of turning on notifications. If they turn on notifications a new event will result in a pop-up message on the screen of their iPhone or iPod even if the Transient Events application is not running. A sample notification is shown in Figure 3. This notification will be accompanied by an alert sound. If the user unlocks their phone the Transient Events application will launch and the detailed information for this event can be viewed immediately.
Figure 3. Transient Notification
Currently the number of transient events is relatively small, a few per night. As the surveys become more numerous and larger in scope the events could number in the 100’s/night. If each of these events generates both a notification and an entry in the table, the amount of information will become overwhelming. To help the user manage the amount of information displayed and the number of notifications presented they have the option of adjusting filters to define which events are of interest. Figure 4 shows the filters which are currently available to the users. This page also allows the user to easily turn notifications on and off.
Figure 4. Event Filter Settings
Transient Events Infrastructure
Data is supplied to the Transient Events app through a server that is a duplicate of the Sky Alert system at Caltech. There are thus two redundant servers, each running the Skyalert software [1], and each getting real-time events (via Jabber/XMPP) from a server at Caltech, which is broadcasting events from various event streams. A schematic representation of the infrastructure is displayed in Figure 5. When a transient object is discovered a VOEvent stream is broadcast to all listeners. The Jabber/XMPP server subscribes to these events and then rebroadcasts them to the Skyalert/Caltech Transient Event server, and the LSST/NOAO transient event server which add them to their repository databases. When a user launches Transient Events the app builds a POST query and transmits it to the LSST server. The POST query contains the filter information set by the user consisting of the types of events, maximum magnitude and maximum event age. The server queries the database to retrieve events matching the filter settings and formats them into a JSON string that is returned to the app. The JSON string is parsed by the app into an array of separate events.
Figure 5. Transient App Infrastructure
Using http POST for the query allows the app to operate over port 80. This is important as it avoids problems with firewalls. The body of a typical POST query is shown in Figure 6. Each section of the post query is separated by an & and consists of a keyword and a value. Notice that separate entries are required for each “wantedClass”.
maxAge=11.000000&maxMagnitude=23.000000&streamNames=CRTS&resumptionToken=0&wantedClass=High+P roper+Motion+Star&wantedClass=Mira+Variable&wantedClass=Comet
Figure 6. Typical POST query
The data from the server is returned is in the form of a JSON (JavaScript Object Notation) string. JSON is similar to XML with keys and values but much less verbose. See Figure 7 for an example of the JSON data for a single event. In a JSON string the keys and values are separated by colons, arrays of objects are enclosed in square brackets and key/value pairs are separated by commas.

JSON strings are easy for both the server and the client because there are readily available libraries which can convert data to and from this format. On the client side the SBJSON library is used. This is a category which adds functionality to the NSString object. Using this category the JSON string is parsed with a single method call to JSONValue. This call parses the data into an array (NSArray) of dictionary objects. Each event is an entry in the array and each entry in the array is converted to an NSDictionary of key-value pairs.

[
{ "positionalError": 0.0011999999999999999,
"findingChartImage": [

"pastImgs": [
"http://nesssi.cacr.caltech.edu/catalina/20100206/1002061210274147147x.html"
],
"freshImageURL": [
"freshImageURL": [
0001.arch.jpg",
0001.arch.jpg",
0002.arch.jpg",
0002.arch.jpg",
0003.arch.jpg",
0003.arch.jpg",
0004.arch.jpg"
],
"firstIVORN": "ivo://nvo.caltech/voeventnet/catot#1002061210274147147",
"objectName": [],
"stream": "CRTS",
"firstEventTime": "2010-02-06T04:54:44",
"triggerIVORN": "1002061210274147147",
"localIVORN": "1002061210274147147",

""
],
"furtherInfoURL": [

"http://www.skyalert.org/events/8799/"
],
"lightCurve": [

"http://nesssi.cacr.caltech.edu/catalina/20100206/1002061210274147147p.html" ],
"ingestTime": "2010-02-05T21:18:31",
"magnitude": "17.912001",
"referenceImageURL": [

"http://lsst
tes.tuc.noao.edu/tesProxy/catalina/20100206/jpg/1002061210274147147.master.jpg" ],
"RA": 78.911569999999998,
"otherImgs": [

"http://nesssi.cacr.caltech.edu/catalina/20100206/1002061210274147147s.html" ],
"triggerEventTime": "2010-02-06T04:54:44",
"Dec": 21.059470000000001,
"type": "Comet",
"findingChart": [

"http://voeventnet.caltech.edu/feeds/ATEL/CRTS/1002061210274147147.atel.html" ]
},
{
"resumptionToken": "0" }
]
Figure 7. JSON response for a single event

Notice that the response from the server does not contain any image data. All images are represented by hyperlinks. This keeps the data downloads fast and relatively small. The images seen in the detailed event view are downloaded on demand in a background thread when the page loads. This is important because it keeps the network traffic and the use of client memory low. Using a background thread keeps the application responsive as the images are downloaded. As mentioned earlier these are important design considerations for portable devices.

Depending on the filter settings selected by the user the number of selected events can vary from none to hundreds. To avoid downloading large amounts of data over what could be a slow network connection the server sends event information in groups of 10. At the end of each group the server appends a resumption token. The resumption token is a pointer to the next database record to be searched if more events are requested. The token is set to 0 if there are no more events satisfying the filter parameters. When the application receives a non zero resumption token it displays “More…” in the last row of the table. If the user wishes to review more events they touch this row. When the app detects the touch of “More…” it sends a new POST request to the server and returns the latest resumption token. The server then uses the resumption token to know where to resume the event search and then it returns the next (up to) 10 events. Upon receiving the next batch of events the application appends them to the end of the table.
Producing and Handling Notifications
Producing a notification
Generation of a notification is divided into three separate tasks: registration for notifications, production of notifications and delivery to the device. The communications paths are shown schematically on the right side of Figure 5.
When the Transient Events app launches it contacts an Apple server and requests a device ID. This device ID remains the same for the life of the device. The ID is sent to the LSST Event server along with event filter information as a POST request and looks very similar to the post query shown in Figure 6. The event server adds this information to a database of devices (or updates the database in the event the device already exists). The filter information is parsed and implemented as one of the general trigger expressions that are available in the Skyalert-powered Event server. The device is now registered for push notifications.

Each time an event is received or an event classification is updated, the database of devices is queried to see which devices are interested in this event. For example, if an event is classified as a supernova the server will search through the list of those devices which are registered to receive supernova notifications. The server then checks that the brightness of the event satisfies the event magnitude setting for the device. If the event satisfies all filter criteria the server produces a notification packet containing the device ID, the text of the notification and some additional metadata and sends this packet to the Apple Push Notification Server.

The Apple server handles delivery of the notification. Based on the information received when the device initially requested the device ID the push system knows how to contact the device (which cell system it is on or if it should be located via IP address on a WiFi network). The Apple server then takes responsibility for message delivery.
Handling a notification
When a notification arrives at the device (iPhone or iPod Touch) a notification message is displayed and an alert sound is played. The Transient Event app is also “badged” with the number 1 indicating that there is a notification waiting. This is all handled by the iPhone OS with no intervention by the application and no coding by the programmer.

If the device was in sleep mode when the notification arrived it will wake up and display the notification. If the device is unlocked before it re-enters sleep mode the iPhone OS will launch the application and pass the notification message packet to the application.

If the device is on when the notification arrives the notification is displayed and the notification box gives the user the option of dismissing the box by pressing “Close” or opening the app by pressing “View” (see Figure 3). If the user presses “View” the app is launched and the notification message packet is passed to the application.
Figure 8 Flowchart of how data and notifications are handled by the application
When the application opens after a notification has been issued it receives an NSDictionary containing the notification message packet information. The application requests the value for the eventID key in the dictionary. This is the triggerIVORN which is displayed at the top of the event detail page (see Figure 2). After receiving and parsing this information the app requests the latest events from the server. As the events arrive their triggerIVORN is compared to the triggerIVORN which was passed in with the notification and the event with the matching triggerIVORN is highlighted with a blinking ALERT as shown in Figure 9.
Figure 9. Display of a Notification Event
It should be noted that an event can generate two notifications. In the above Figure if the user asks to be notified for both Unknown events and Comets a notification will be generated when the event is first entered into the system, at which point it will be classified as Unknown. When the event is later classified as a comet a second notification will be generated.
Server Protocol Support
To support the iPhone Transient App, a special query-response protocol has been built and implemented into the Skyalert server. It is a RESTful http query, with arguments representing the streams from which events are wanted, the brightness threshold, the maximum age, and the classification of the events, with 17 classes to choose from. The results come back in the JSON format, as noted above, including event time, position, and magnitude, as well as:

• freshImageURL: an array of links to images representing the new data. It is the difference between this and the reference that is presumably the reason this transient is being disseminated.
• referenceImageURL: an array of links to images representing the situation before the discovery of the event, for comparison with fresh images. In addition, there are the following parameters for each transient:
• furtherInfoURL: A link back to the Skyalert page for this event, including a portfolio of relevant information that may aid interpretation.
• findingChart: an array of HTML page where the finding chart is shown.
• findingChartImage: an array of image URLs where the finding chart is shown.
• pastImgs: an array of HTML page showing past images from this stream
• otherImgs: an array of HTML page showing archival data from other surveys
• lightCurve: an array of HTML pages or images showing magnitude history -- the light curve.
Extensibility to future surveys
Implementing the LSST Transient Event Server as the repository for the iPhone Transient Events App will make it relatively simple to extend the application to new surveys. Surveys that provide event data in the same form as the current CRTS stream will be simple to incorporate with only minor enhancements to the application. If the event streams are significantly different the application will check the eventStream value and format the display in a manner that is appropriate for the data.

The event query protocol was made purposely general to enable the Transient App is to be extended to more streams, including those with different telescopes and other wavelengths. However, terms such as “magnitude” and “light-curve” are not appropriate at X-ray or radio wavelengths, although closely related terms replace them. The emphasis on images as the primary means of discovery is perhaps more of a problem in extending this protocol.
Summary
An easy to use iPhone/iPod touch application has been created to provide users with a way to view recent transient events. The application uses a client/server model that minimizes network traffic only downloading data of interest to the user as it is requested. The application incorporates a notification system to inform the users of events of interest in a timely manner. The server/client software have been designed for easy future expansion as additional surveys come on line.

References
[1] Catalina Realtime Transient Survey, http://crts.caltech.edu.
[2] Skyalert, software for event dissemination and repository, Section 3.1 in this book and also at http://skyalert.org.
3.4 Understanding and Using the VOEvent Network
Robert B. Denny
DC-3 Dreams, SP
The VOEvent network carries VOEvent messages from authors to subscribers. It consists of a backbone of interconnected brokers, plus additional value added publishing and delivery services with their own entry and exit points. Authors originate VOEvent messages, and subscribers receive them. How they get from one to the other is the subject of this chapter.
Background
VOEvent messages carry time-sensitive information about transient astronomical events. Depending on the type of event, the time sensitivity can range from seconds to days. The network has been designed to deliver messages in seconds.
Messages originate with authors, and terminate with subscribers. There are relatively few authors and many subscribers. The VOEvent network offers a variety of ways to both publish and subscribe.
The VOEvent Backbone

Figure 1. The VOEvent Backbone
The core component of the VOEvent network is its backbone. The backbone is formed by a set of brokers which are interconnected. Each broker provides both publish and subscribe services. When a message is published to a broker, it is immediately distributed by that broker to all of its locally connected subscribers and to one or more other brokers to which it is interconnected. Those brokers, in turn, immediately distribute the message to their subscribers and to all of the brokers to which they are interconnected. This all happens in seconds.
The backbone uses the Internet and a TCP socket-based protocol designed for the purpose and intentionally made simple. The protocol is described in the IVOA Note VOEvent Transport Protocol 1.1 [1].
Value-Added Services – SkyAlert

Figure 2. The Caltech SkyAlert System
The VOEvent network is not limited to the services provided by the backbone. At the California Institute of Technology, a team has created the SkyAlert system. It also accepts VOEvent messages from authors and delivers them to subscribers while acting as a broker on the backbone. What sets it apart from backbone brokers is the wide variety of value-added services it provides to subscribers. SkyAlert is described in more detail iin Section 3.1 of this book.

Subscribing to the VOEvent Network
Before deciding how you want to subscribe, you should consider your present and future needs. If you want to receive personal notification of events, then SkyAlert is currently the right way to go. Be on the lookout for future systems which may also deliver personal alerts. SkyAlert provides event delivery by SMS, Email, instant messaging (XMPP), on the sky layer of the Google Earth web service, on the Microsoft Worldwide Telescope, and even Facebook. The detail contained in these postings varies widely, so be sure your chosen delivery method contains the information you need. Go to the SkyAlert home page [3] for details.

If you plan to drive a robotic observatory with event triggers, you’ll probably want to subscribe directly to the backbone. You will need to implement the VOEvent Transport protocol as a subscriber. You’ll also need to parse the VOEvent XML messages to extract the trigger data contained therein. For more information on this, see the section Reading and Making VOEvent Messages below. Many of the messages on the backbone will be of no interest, so once you have extracted the data from the XML, you’ll need to discard uninteresting messages.
Publishing to the VOEvent Network
Publishers must construct VOEvent messages which are XML documents that conform to the IVOA Technical Specification Sky Event Reporting Metadata (VOEvent) [4]. Within this specification is a great deal of freedom to include data specific to the type(s) of events you may wish to publish, as well as external references to other VOEvent messages and supporting data for your trigger. For more information on this, see the section Reading and Making VOEvent Messages below.

Once you have constructed a VOEvent message, you currently have two choices for publishing. You can publish directly to the backbone, or you can publish to an instant-messaging (XMPP) service that is part of the Caltech SkyAlert system.

To publish to the backbone, you’ll need to implement the VOEvent Transport protocol as a publisher per the VOEvent Transport Note [1]. Publishing to the backbone permits you to digitally sign your messages, assuring their authenticity and integrity from you to each subscriber who cares to check your signature. The signature method supported by VOEvent Transport is described in the IVOA Note A Proposal for Digital Signatures in VOEvent Messages [2], and referenced by the VOEvent Transport Note[1]. If you wish to publish via SkyAlert, you’ll need to implement the XMPP-based Jabber protocol plus Publish/Subscribe, and have a channel assigned to you by Caltech. The XMPP protocol provided by SkyAlert can encrypt your messages, and requires you to authenticate with the serve before it will accept message from you.
Reading and Making VOEvent Messages
VOEvent messages are XML documents which adhere to Sky Event Reporting Metadata (VOEvent)[4]. This specification and the corresponding XML schema refer to other XML specifications including Space-Time Coordinate Metadata for the Virtual Observatory [5] (STC). Taken as a whole, the specification is rather complex. Fortunately, in practice, the VOEvent messages in actual use represent a small subset of the possibilities.

In order to make it easier to read and make VOEvent messages, the author has written a reduced schema[7] which is suitable as input to binding tools such as JAXB, Liquid and several binding tools available for Python. By using one of these tools, all of the data in the VOEvent message is mapped to objects with corresponding properties. This approach is a real time.

There is also a public web-based VOEvent validator which will do a deep check of a VOEvent message[8]. The check is performed against the previously mentioned reduced schema. Not only is XML structure checked, but also ordering and spelling of tags plus correctness of the data in many of the elements and attributes. While developing your tools and pipelines which produce VOEvent messages, use this web site to check your messages for correctness.
Operating a Broker
If your organization has multiple publishers and subscribers on-site, or if you have a solid connection to the internet and wish to assist the VOEvent network, or if you want the visibility of having a node on the backbone for whatever reason, you may wish to operate your own broker.

Developing a conforming broker is not a simple undertaking, and it requires a skilled development team. A badly behaving or unreliable broker is a liability to your publishers and subscribers, and could adversely affect the rest of the backbone.
Available Software
This author has developed Dakota, a freely available cross-platform and open source receiver/broker and message sender package. It is described in the IVOA Note Dakota: A Cross Platform VOEvent Broker[6].
The lightweight broker can serve as a message receiver since it receives and stores all incoming VOEvent messages on its disk. The message sender is a separate command-line tool that reads a VOEvent message from a disk file and delivers it to a specified broker, with optional digital signature. The receiver/broker will check any digital signature it encounters. Dakota contains no tools for constructing or parsing VOEvent (XML) messages.
Dakota run on most recent Linux distributions, a few BSD variants, Mac OS X (Leopard or later), and Windows XP/Vista/7. Feel free to contact the author for details at rdenny@dc3.com. References
[1] VOEvent Transport Protocol 1.1
http://www.ivoa.net/Documents/VOEventTransport
[2] A Proposal for Digital Signatures in VOEvent Messages
http://ivoa.net/Documents/latest/VOEventDigiSig.html
[3] Welcome to SkyAlert
http://www.skyalert.org/
[4] Sky Event Reporting Metadata (VOEvent)V1.11
IVOA Technical Specification
http://ivoa.net/Documents/latest/VOEvent.html
[5] Space-Time Coordinate Metadata for the Virtual Observatory
http://ivoa.net/Documents/latest/STC.html
[6] Dakota: A Cross Platform VOEvent Broker
http://ivoa.net/Documents/DakotaBroker/
[7] VOEvent Mini-Schema
Documentation : http://voevent.dc3.com/schema/
Schema : http://voevent.dc3.com/schema/VOEventMini-v1.1.xsd
[8] Online VOEvent Message Validator
http://voevent.dc3.com/vomsgchk/
Events and the Virtual Observatory

The Virtual Observatory is a generic name for ways to achieve interoperability of astronomical data; one of its children is the VOEvent protocol. The first section here is about a standard query interface for event repositories, and the second is about using the VO Registry to find event streams and event services. The third section is about achieving interoperability of the meaning (semantics) of events using formal vocabularies.
Photo Credit: Flickr/Jay Adan
3.5 Querying events with Simple Event Access Protocol
Matthew J. Graham
California Institute of Technology
Abstract The Simple Event Access Protocol (SEAP) provides a standard mechanism to query services containing VOEvent packets. Not only are positional searches supported but also queries against who created or published the event, how the event was observed, and what was observed, both in terms of measured quantities, e.g. flux, and the interpreted nature of the event, e.g. supernova. Queries against specific values as well as ranges of values are possible. Services offering this capability will be discoverable in the VO registry.
Introduction
From an event producer’s perspective, VOEvent can be a fire-and-forget technology: once an event packet has been cast into the ether, it ceases to be of any further operational concern. For an astronomer, however, this ephemerality can be disconcerting – what if they missed the initial announcement or want to mine past events looking for correlations and causations, either between events or against known sources?

Within the VOEvent infrastructure, repositories provide a persistence layer to address these issues. Yet not all repositories are equal; there is scope for a spectrum of them, ranging from repositories that carry all events ever published by anyone to bespoke ones which only store events from a particular source, e.g. the Catalina Real-time Transient Survey, or of a particular type, e.g. more than 90% plausibility of being a supernova.

The Simple Event Access Protocol (SEAP, [1]) provides a standardized interface to repositories to facilitate interoperability. It is analogous to the other ‘simple’ VO data access protocols – Simple Cone Search (SCS, [2]) and Simple Image Access (SIA, [3]) – in providing a lightweight parameter-based mechanism for querying VOEvents that have been stored in some fashion.
Basics
A call to a SEAP service consists of a basic HTTP GET request including a list of ampersand-delimited keyword-value arguments:
http://some.seap.server?key1=value1&key2=value2…
The keywords identify which aspect of a VOEvent is being queried, e.g. spatial position or reported event type – asteroid, supernova, GRB, etc. -- and the values describe the specific value or range of values of interest, e.g. mag < 15 or within the last 24 hours. When multiple keywords are used, the results, if any, will satisfy all constraints: for example, a search employing both a spatial keyword and one relating to object type will only return events of that type within that region.
The default response from the service is a VOTable containing at least two pieces of information for each event that matches the query:
• the full IVOA identifier (IVORN) of the VOEvent
• an URL from which the full VOEvent packet may be retrieved
Other data might also be returned but that is very much a service-dependent issue. SEAP services might also offer the same response content in alternate formats, e.g. as a KML document or as a JSON structure, but that also will be service-dependent. Nevertheless such additional features will be described in the metadata record for a particular SEAP service in the VO registry.
A failed query should respond in a manageable fashion so that the query originator understands why their search did not work. This is both in case of error, e.g. a parameter value has been specified in an incorrect format, and where things are not necessarily erroneous, e.g. a spatial search exceeds the spatial coverage of the available data.
Keywords
The set of possible keywords that can be used in a SEAP call is summarized in Table 1. These essentially allow a query to be made against any of the major sections of a VOEvent packet, i.e. any of the Who, What, WhereWhen, How or Why elements. The data type of the corresponding value to a particular keyword must be in the specified format, e.g. the ‘ivorn’ value must be an IVOA IVORN-compliant string. The keywords can optionally be prefaced with a scheme of “seap”, e.g. seap:concept=’GRB’, to unambiguously identify them as belonging to the SEAP domain (namespace). This might be necessary for a service that augments its SEAP capability with extra parameters of similar meaning, e.g. size could also refer to a limit on the number of returned results.

Table 1. The possible keywords that can be used in a SEAP call Keyword
response.content Data Type string

ivorn stream IVORN IVORN
authorivorn IVORN
contactname string
how string Description
The format of the response; possible values include: ivorn (default), full, custom, and kml
The identifier of the VOEvent The identifier of the stream from which the packet originated
The identifier of the author of the VOEvent
The contact name of the person who created the VOEvent
How the observation that resulted in the VOEvent was performed
pos
size
time
param
concept float/pos range The position of a region of interest float
ISO-8601
param range string

citation.cited citation,role boolean string
The radius of a region of interest A time (interval) of interest
A reported parameter of interest
What the underlying physical event is thought to be
Which events have cited this one?
The role of any citing event; possible values are: followup, supersedes, and retraction
Value rules
Multi-component values, e.g. a RA, Dec position, use a comma (“,”) as the separator between components. Embedded white space is not allowed and two successive commas indicate an empty item, as does a leading or trailing comma.
Most queries requesting matches to specific values will be against IVORNs or strings whilst those involving regions, times and parameters of interest will commonly be looking for a match against a numeric range of values. These use a forward slash (“/”) as the separator between range limits. The range is defined as inclusive, i.e. including the range limits, and if a third value is specified, it is a step size for traversing the indicated range. An open range may be specified by omitting either range limit: for example,pos=120/240,/-45 will search for events with 120 ≤ RA ≤ 240 and Dec ≤ -45.
Certain values permit a qualifier, e.g. time, and these use a semicolon “;” as the separator between the keyword values and a qualifier string.
The logical NOT of a value is specified by preceding the value with a “!”. For example, pos=!120/240, will search for events outside the region 120 ≤ RA ≤ 240.
Finally, keywords are not case sensitive but string values are.
Positional range
The full syntax for values of the “pos” keyword is:
pos = minval1/maxval1,minval2/maxval2;coordsys
where minval1/2 are (optional) lower limits andmaxval1/2 are (optional) upper limits for their respective coordinates and coordsys is an (optional) keyword indicating the coordinate system to use. The default coordinate system is ICRS – RA and Dec in decimal degrees – but alternate systems such as “GALACTIC” are allowed, although whether they are supported is a service-dependent issue.
Temporal range
The full syntax for values of the “time” keyword is:
time = minval/maxval;type
whereminval andmaxval are (optional) lower and upper limits in ISO-8601 format andtype specifies the DateTime reference as detailed in the VOEvent standard [4]. Possible values fortype are:
1 isotime – this denotes the time that the observation reported in the VOEvent packet was made
2 pubtime – this denotes the time that the VOEvent packet was created/published The default value is isotime and this value is assumed if no qualifier is specified.
Parametric range
The full syntax for values of the “param” keyword is:
param = “name”,minval/maxval;”unit”
where name is the (optional) parameter name, minval and maxval are the (optional) lower and upper limits to the parameter value, and unit is an (optional) qualifier specifying the parameter unit. For example, param=”mag1”,18/20 will search for events with a parameter named “mag1” that has a value between 18 and 20. When the parameter value is a string then minval and maxval need to be identical and string equivalence will be sought for, e.g.param=”filter”;”Gunn z”/”Gunn z” will search for events with a parameter named “filter” and a value of “Gunn z”.

In VOEvent, Params are often arranged in (named) Groups. The name used in the param value can therefore be qualified by the Group name (as a prefix and using a period (“.”) as a separator between the Group name and the Param name) if the search is for a specific parameter within a specific Group. For example,param=”Ast1.mag1” will look for a Param called “mag1” within a Group called “Ast1”. Matching just on the Group name can be achieved by omitting any Param name but keeping the period separator; for example,param=”Ast1.” will find all events with a Group called “Ast1”.

VOEvent 1.1 does not support the specification of data types on parameters. It is therefore left to the individual service to interpret parametric ranges; however, the general assumption should be that when numerical characters are used in a range expression, e.g. 18/20, then a numerical search range is intended and the query should be parsed as such. For example,param=”mag1”,19/ will search for events where the numerical value of the parameter named “mag1” is greater than 19 rather than those where the value of the parameter named “mag1” come after “19” in a alphanumeric ordering. Note, however, that in VOEvent 2.0 parameters can have a data type associated with them.

Data type information is available for parameters in the registry record for a particular VOEvent stream and so a SEAP service could always retrieve the relevant record and check whether a given query is syntactically correct, e.g. whether the specified parameter takes numerical values if a numerical range is present.
Examples
Fig. 1 shows the following positional constraints around a point with RA=120, Dec=15:
• pos = 120,15
• pos = 120,15 & size = 0.5
• pos = 119.5/120.5,14.5/15.5
• pos = 120,14.5/15.5
• pos = 119.5/120.5,15
• pos = 120,15 & size = !0.5
• pos = !119.5/120.5,!14.5/15.5

(b) illustrates how the “size” keyword is used to specify the radius of a region of interest centered on the point identified by the “pos” keyword. (f) shows how a negation appears on the “size” keyword when it is used – any negations on the “pos” keyword are invalid n this context.
Figure 3. Different positional constraints. In (f) and (g), the shaded region is the area being defined, i.e. the circle and the square denote regions of exclusion.
Registering SEAP services
The VO registry allows users to discover astronomical resources – data collections and services – that match specified metadata requirements. A service supporting a SEAP interface should be registered as a Service or subresource (e.g. a VOEventServer) with a capability of type “voe:SimpleEventAccess”.
References
[1] Graham, M.J., Allan, A., Seaman, R., Wlliams, R., Auden, E., Denny, R., Rots, A., Warner, P., Simple Event Access Protocol (SEAP), v1.0, 2010
http://www.ivoa.net/Documents/latest/SEAP.html
[2] Williams, R., Hanisch, R., Szalay, A., Plante, R., Simple Cone Search, v1.03, 2008
http://www.ivoa.net/Documents/latest/ConeSearch,html
[3] Tody, D., Plante, R., Simple Image Access Specification, v1.0, 2009
http://www.ivoa.net/Documents/SIA/20091116
[4] Seaman, R., Williams, R., Allan, A., Barthelmy, S., Bloom, J., Graham, M., Hessman, F., Marka, S., Rots, A., Stoughton, C., Vestrand, T., White, R., Wozniak, P., Sky Event Reporting Metadata (VOEvent), v1.11, 2006
http://www.ivoa.net/Documents/latest/VOEvent.html

3.6 Finding VOEvent resources
Matthew J. Graham and Roy Williams California Institute of Technology
The VO registry infrastructure can be used to allow publication, discovery, and utilization of VOEvent resources. In particular, two types of resource specific to VOEvent are defined as registry schema: VOEventStream and VOEventServer. The stream schema describes a scientifically coherent collection of events that come from the same motivation, team, project, or experiment. Each event of a stream uses the same vocabulary (parameters) to describe events. The server schema describes which computers and interfaces can be used to send out future events (subscription capability) and/or can run queries on past events (query capability). It is describes the streams that it knows, and then the capabilities it offers for each of those streams.
Introduction
Although VOEvent is, by its nature, a very ephemeral construct, much of its associated infrastructure concerned with the generation, dissemination and persistence of packets is not. Working with VOEvent then involves working with the components of the VOEvent system but how does one discover what and where these are, how to work with them and what they are capable of ?

The VO registry [1] is essentially a Yellow Pages for astronomical resources. Anything that is describable and identifiable – a resource – can be stored: not just data and services but also organizations, projects, software, etc. The registry holds a list of resource descriptions which are expressed as structured metadata, enabling automated processing and searching. Different types of resources conform to specific schema for that resource type.

The VOEvent infrastructure can be seen to be composed of two such resource types (defined as schema) [2]: VOEventStream, which encapsulates a set of events with a common provenance, and VOEventServer, which provides access points for getting event data in various ways.

Using the registry for VOEvents
The type of activities that are supported by having VOEvent resources in the registry include:
• Resolving an event: the unique identifier for an event is a concatenation of a stream identifier and an
event number within that stream. A question to the registry finds which VOEventServer has the query capability for that stream, and then that server can be probed to get the full event metadata.
• What is this event: the event identifier contains the VOEventStream identifier, from which the registry can produce the descriptive text, contact information for the responsible people, and so on.
• Subscription to a stream: VOEventServers are being built to push events to those who want them by a variety of messaging protocols; in order for an astronomer to set this up, the registry is asked which servers provide the "subscription capability" for the given stream, so that the astronomer can work with that server to set up future delivery of events.
• Creating a stream: A survey or project may wish to publish an event stream. The registry will provide a way to define the nature of the coming events (VOEventStream) and where to get them (VOEventServer), and thus allow others to find and subscribe to those events.
• What does this parameter mean: Each event has a set of keyword parameters; the registry can be used to find out their meanings.
Identifiers and VOEvents
Every resource in the VO has a globally unique identifier (known as an IVORN - International Virtual Observatory Resource Name) [3], which provides a means for retrieving the metadata record for a specific resource from any registry. These identifiers begin with the scheme “ivo:” and have a modular syntax affording the control of the relevant parts to the appropriate entities:
ivo://my.datacenter.here/resourceName#localName
By splitting this into pieces, we can find other IVORNs buried inside. As with any URI, there can only be 0 or 1 pound signs (#) in the IVORN. If it is present, thelocalName (after the #) is not understood by the registry system, i.e. it is not retrievable. The part before the # (or the whole IVORN if there is no # present), however, is a reference to a retrievable resource record within the registry system. It is composed of the Authority ID (ivo://my.datacenter.here), which establishes a provenance for a set of particular resources, such as the holdings of an astronomy data center, and the Resource Key (resourceName), which identifies a particular resource within the set.
VOEvents from a particular source are not registered individually in the registry but rather as the coherent collection that is a VOEventStream. Each VOEvent can then be thought of as a representative of a class of events (the stream). The syntax for the IVORN of a VOEvent is:
ivo://my.datacenter.here/streamName#eventName
By splitting this on the # sign, we can look up the stream in the registry and find the meaning of parameters used in events from this stream. We can also discover which resources (VOEventServers) are handling this stream, either where can we subscribe for future events or where can we access stored past events.
The VOEventStream Metadata Record
The resource description for a VOEventStream uses the common metadata of all VO resources [4] and also metadata that is peculiar to a VOEvent stream. Among the former will be:
• Identifier: the IVORN of the stream
• Title and short name: the formal name of the stream (e.g. the Catalina Real-time Transient Survey) and an abbreviated reference for it (e.g. CRTS)
• Curation: information about the publisher and creator of the stream with contact information
• Content: the nature of the stream’s content as a set of subject categories (e.g. radio astronomy, gamma-ray bursts) as well as a text description of it and a reference URL to relevant web pages (e.g. the survey website)
• Coverage: the sky coverage of the stream with the simplest representation being “AllSky”, or another being a cone of the sky. The temporal coverage of the stream can also expressed here listing both previous and expected observing periods. Spectral coverage can also be expressed here.

Parameter templates
A key feature of the VOEventStream concept is that each stream has a defined set of named “parameters” and a member event of a stream should only use parameters that are part of the specified list for that stream. While a VOEvent will specify a value of the correct data type for a parameter, the registered definition of the parameter will be valueless. Thus a ParamTemplate in a VOEventStream record would look like:

<Param name=”max” ucd=”meta.number” dataType=”int”>
<Description>Maximal number of records to retrieve
</Description>
</Param>
but all that is needed in the event itself is the name-value association:
<Param name=”max” value=”50”/>
All of the other information can be added if the author desires so that the VOEvent can stand by itself. But when the event stream has been properly registered then only the name and value are strictly necessary.
In VOEvent, parameters can be collected into groups: for example, a measurement and its error estimate can be combined:
<Group name=”Rmag”>
<Param name=”value” ucd=”phot.mag;em.opt.R” dataType=”float” value=”17.3”/> <Param name=”error” ucd=”phot.mag;em.opt.R;stat.err”
dataType=”float” value=”0.1”/>
</Group>
The same information can be identically described in a VOEventStream record just by omitting the actual values. Note also that VOEvent and VOEventStream cannot have Groups within Groups: a Group may only contain Params and not other Groups.
The same rules of uniqueness are also in force for ParamTemplate and Groups in VOEventStream as for Params and Groups in VOEvent:
• Each Param must have a name. A Group without a name is equivalent to having a name which is the null string.
• Names must be unique within the set of Params not in a Group.
• Names must unique for the set of Params within a given Group.
• Groups must have unique names – this means that only one Group can be nameless.
The VOEventServer metadata record
Once the stream is defined in the registry, we want to know what kinds of services are available to deal with it. These are known as Capabilities in the VO registry model. With VOEventServer, there are three kinds of VOEvent-specific capability that we can describe:

• subscription: a client can submit a criterion, e.g. R magnitude brighter than 17, and events will be sent by the server in the future which satisfy that criterion.
• formal query: this is the Simple Event Access Protocol (SEAP, [5]), a formal request-response protocol for querying VOEvents.
• informal query: a web page with forms by which a collection of events can be browsed in some way.

The capability of a server is split further into Interfaces, which express precisely how a client can access the capability. For example, the subscription capability could be achieved by having the event sent out by email, instant messaging, or some bespoke messaging protocol. These are three different interfaces to the subscription capability and each will have different metadata associated with it (e.g. email address vs. phone number).

As with VOEventStream above, a resource description for a VOEventServer uses the common metadata of all VO resources [4] and also metadata that is peculiar to a VOEvent server. The first case of the latter is a list of streams to which the server can provide access through one of its capabilities. The details of the various capabilities and their respective interfaces are then described.

Capabilities and interfaces
Although a VOEventServer can have any number of capabilities, two that are defined specifically to support the VOEvent infrastructure are SimpleEventAccess and Subscription.

The SimpleEventAccess defines metadata relating to the characteristics of a SEAP access point that the server might provide, such as the maximum query region size that is supported and a test query that can be used to ensure that the SEAP service is functional. Since the SEAP uses a straightforward HTTP endpoint, the details of the interface can be described using common VO resource metadata.
<capability xsi:type="voe:SimpleEventAccess"
standardID="ivo://ivoa.net/std/VOEventSEAP">
<interface xsi:type="vs:ParamHTTP" role="std">
<accessURL use="base">
http://nvo.caltech.edu/voeventnet/seap</accessURL>
</interface>
<maxQueryRegionSize>
<maxRecords>10000</maxRecords>
<testQuery>
<seap:pos>120,15<seap:pos>
<seap:size>0.5<seap:size>
<testQuery>
</capability>
The Subscription gives details of the various ways in which a client can receive future events, most of which information resides in the different interfaces under this capability. Specific metadata is defined in these interfaces for those access protocols peculiar in VO usage to VOEvent: Jabber, TCPV and RSS.
<capability xsi:type="voe:Subscription"
standardID="ivo://ivoa.net/std/VOEventSubscribe">
<interface xsi:type="voe:Jabber">
<accessURL>http://moriori.cacr.caltech.edu</accessURL>
<securityMethod standardID="ivo://ivoa.net/std/UserPass"/>
<feedNode streamId="ivo://nvo.caltech.voeventnet/catot">

home/moriori.cacr.caltech.edu/catalina</feedNode>
</interface>
<interface xsi:type="voe:RSS">
<accessURL>http://www.voeventnet.org</accessURL>
<feed streamId="ivo://nvo.caltech.voeventnet/catot">
http://www.voeventnet.org/feeds/Catfeed.xml</feed>
</interface>
<supportsFilters>true</supportsFilters>
</capability>
References
[1] Graham, M.J., 2008, AN, 329, 304

[2] Graham, M.J., Williams, R.D., Allan, A., Plante, R., Seaman, R.,VOEventServer: an XML Encoding Schema for Resource Metadata for Collection of Events, v0.3, 2010
http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEventServer-0.3.html
[3] Plante, R., Linde, T., Williams, R., Noddle, K., IVOA Identifiers, v1.12, 2007
http://www.ivoa.net/Documents/latest/IDs.html
[4] Plante, R., Benson, K., Graham, M.J., Greene, G., Harrison, P., Lemson, G., Linde, T., Rixon, G., Stebe, A., the IVOA Registry Working Group, VOResource: an XML Encoding Schema for Resource Metadata, v1.03, 2008
http://www.ivoa.net/Documents/latest/VOResource.html

[5] Graham, M.J., Allan, A., Seaman, R., Williams, R., Auden, E., Denny, B., Rots, A., Warner, P., Simple Event Access Protocol (SEAP), v0.5, 2009
http://www.ivoa.net/Documents/latest/SEAP.html

3.7 Vocabularies and Semantics for VOEvent

Frederic V. Hessman
Institut für Astrophysik, Georg-August-Universität Göttingen Norman Gray
Department of Physics and Astronomy, University of Glasgow

This book is about real-life science and practical implementations of strategies for catching and processing astronomical events. The gentle reader is probably asking herself “why in the world is there a section about something as obscure and irrelevant as ‘semantics’?” The answer is actually quite simple: the “semantic” part of the problem is concerned with making explicit the meaning of a VOEvent message, because the whole point of VOEvent is to transport meaningful content. Wiktionary [1] defines semantics as “the study of the relationship between words and their meanings” or (to paraphrase slightly) “the individual meanings of words, as opposed to the overall meaning of a message.” Thus, semantics in VOEvent is 1) the attempt to clearly identify the astronomical descriptions used to characterize an event, and 2) to put those meanings in a clear and machine processable context relative to the other content of the message and the scientific point of dealing with such messages. Computers are very good at processing strings and transporting bits – semantic technologies are about making meanings just as conveniently processable.

Semantics has become important in VOEvent and modern astronomy in general for a very simple reason: as long as astronomical information was being processed by humans, one could count on there being both senders and receivers with the right astronomical training capable of insuring that the content was reasonable and intelligible, and either phone or email access to ask “what's column X supposed to mean?”. In the age of massive astronomical surveys, this is no longer possible. While astronomers can count on it being possible to transfer terabytes of images, spectra and tables nearly seamlessly between themselves and their applications, there is no really universal means of saying that an image is of a galaxy, the spectrum is of a brown dwarf, and that the table contains the wavelengths of telluric lines. Both technical and social changes mean that data is now shared more promiscuously, and users and their computers receive it from multiple sources, so that informal semantic arrangements (the “what is column X?”) are becoming inadequate. The whole point of VOEvent is to permit computers to produce and process astronomical events, but since many producers are capable of emitting reports on a wide range of astronomical events and most receivers are interested in only a small subset of all possible events, being able to clearly describe and recognize the semantic content of a VOEvent is crucial to making the protocol generically useful.

There are several different forms and levels of the organization of semantic information. The ultimate semantic solution is to teach computers to process information in some semblance to how an astronomer would do it, but pending some unbelievable development in artificial intelligence, this is unlikely to happen soon. In any case, such an elaborate machine `understanding' is not necessary. A real astronomer knows what a “spiral galaxy” is, that a real instance has a position on the sky, angular and geometric size, brightness and other properties. A real astronomer can guess that "SN Ia" probably means that this is a label for a Type Ia supernova and that they occur in spiral galaxies. These fairly lightweight structural relation are what we hope to encode at this initial stage; more sophisticated `understanding' -- such as the knowledge that an object which possesses an RA and a Dec must be an astronomical object of some type -- is perfectly feasible, and usefully deployed in other disciplines such as biology, but more than we need to worry about right here.

We can distinguish various levels of formality here (and the descriptions are formalised in, for example, [2] and the more compendious [3]. A ‘controlled vocabulary’ is a simple list of approved terms and descriptions; a ‘taxonomy’ and a ‘thesaurus’ have more or less additional hierarchical structure, such as broader/narrower relations (`compact object' is a broader term than ‘quasar’) or relations (such as the famous Yellow Pages cross reference, ‘Boring: see Engineers’). The standard definition of an ‘ontology’ is “an explicit specification of a shared conceptualization” (after [4]): this is a useful definition, but it covers a huge range of possibilities, all the way down to controlled vocabularies, and so it is often restricted to the case where a thesaurus has a ‘formal IsA’ relation. The distinction is simple: saying, in an ontology, that compact objects have a subclass called quasars means that anything which is a quasar is also a compact object, as a matter of logical necessity; saying, in a thesaurus, that ‘cars’ have a narrower, or more specialized, concept of ‘wheels’ does not imply that everything that is a wheel is also a car! Loosely, thesauri are useful for searching, and ontologies are necessary for making deductions. Most, but not all, of the examples we mention below are thesauri, but for our purposes we will lose no precision in referring to them indiscriminately as `vocabularies'.

There are several examples of astronomical taxonomies in common use: the NASA Taxonomy [5] keeps an official list of terms used to describe a wide variety of information from various missions and organizations to “audiences” and “work breakdown structures”; and the “Astronomy Visualization Metadata” (AVM) taxonomy [6] is an international standard used to describe the content of astronomical outreach media (permitting an image of a spiral galaxy to be labelled as such). The latter has a very clear hierarchical structure. Also, the IAU produced an official thesaurus of astronomical terms in 1993 (http://www.aao.gov.au/lib/thesaurus.html) for the benefit of librarians, containing not just a list of words but their translation into several (European) languages and a modest level of connections between terms (“narrower” and “broader”). Finally, there is an Ontology of Astronomical Object Types [7] which has been produced under the auspices of the IVOA—this is intended for reasoning rather than search, but illustrates the intricacy of what is possible.

Historically, the semantic content of a VOEvent package was based on the assumption that the producers were specialists for one type of event—e.g. gamma-ray bursts or supernovae—and that the receivers knew their producers and could expect to process implicitly defined and well-known content. The only real semantic content that was clearly defined was the simple “Unified Content Descriptors” (UCD) system created by the Virtual Observatory to identify the rough content of tabular data - things like “em.wl” for “wavelength”, “pos.eq.ra” for “Right Ascension”, “phot.mag;em.opt.R” for Rmagnitude, “meta.table;meta.id” as the closest description for “catalogue number”. This is important semantic content supported in the <What> section of a VOEvent via the <Param> entries, each of which can be assigned one or more UCD values. However, this is semantic content of the most primitive kind describing the content at the lowest level of a VOEvent. In the <Why> section of a VOEvent, the <Concept> entries were provided for transporting higher-level semantic content, e.g.

<Why probability="100">
<Concept type="name">Tycho's Stella Nova</Concept>
<Concept>SN Ia</Concept>
</Why>
but the content itself was not based on any clear system: if one saw "SN Ia" in one message and "Type Ia supernova" in another, it was left to the poor receiver, or their regular expressions, to be clever enough to catch all the expected and unexpected possibilities, or risk not catching an interesting event.

One might have expected that, since all of these semantic problems are common to all Virtual Observatory projects and not to VOEvent alone, the IVOA would have long since solved these problems by creating clear semantic standards. To some extent, this is true: the IVOA has formalised UCDs as a vocabulary for astronomical data (note that UCDs, deriving ultimately from a census of column names at CDS, form a taxonomy of astronomical data, not of astronomical objects -- thus there is a UCD for an `abstract', but no UCD for a `star'), and has adopted SKOS (see below), but there are still important parts of the jigsaw missing. The much-heralded “utypes” will provide a syntactic bridge for linking data and concepts, but the meaning of “data model” and the means of publishing what such things are supposed to be -- true semantic content or mere software class descriptors -- is different depending upon whom one talks to. Thus, the always practically minded VOEventist is yet again faced with the problem of a well-defined task with an apparently non-standarized solution path. The IVOA's adoption of SKOS, as a means of describing and relating vocabularies, is an important step on the route out of this thicket, and we describe it in some detail below.
Note that here and below we are careful to talk of vocabularies, plural. Though it may seem obviously useful to have a single master vocabulary, such a thing is unwieldy, would remain unfamiliar to most scientists, and would require a major effort to agree on. Instead it is reasonable to have multiple smaller, and more specialized, vocabularies, which can be developed in a more agile fashion, and which can be interrelated using standardized SKOS structures.

This section treats two fundamentally semantic and yet very practical aspects of VOEvent: namely the creation and the recognition of intelligible semantic content in an event message. First, we identify where the semantic information is contained within the elements of a VOEvent document. Then, a simple means of publishing the possible content is described. Finally, the practical aspects of using the published content to produce and process VOEvent documents is outlined. While some of the details may only apply to early versions of VOEvent, the general ideas should remain valid for the foreseeable future.

Vocabularies in the VO
While the IVOA has not defined what vocabularies could be used within a semantic context like VOEvent, it has specified how such information should be published. Following the work being done for the “semantic web”—developing the structures to communicate meaning on the web—the IVOA has recommended using the W3C's “Simple Knowledge Organization System” or SKOS. The W3C describes SKOS thus: “Using SKOS, concepts can be identified using URIs, labeled with lexical strings in one or more natural languages, assigned notations (lexical codes), documented with various types of note, linked to other concepts and organized into informal hierarchies and association networks, aggregated into concept schemes, grouped into labeled and/or ordered collections, and mapped to concepts in other schemes” [8]). In short, SKOS provides a standardized framework for sharing and documenting vocabulary lists. This is obviously exactly what we need for the IVOA in general and VOEvent in particular, so the vocabulary document produced by the IVOA semantics workgroup mainly described how SKOS is used and gave a few examples.

This sounds fairly simple and, in principle, it is. Unfortunately, vocabularies published using the SKOS standard can be expressed in different formats and the IVOA didn't place any restrictions on or make any recommendations for the formats of choice. In practice, astronomical vocabularies are likely to be published/accessed in one of two formats: RDF/XML and “Turtle”. NASA, for instance, publishes its SKOS taxonomies in RDF/XML (“RDF” means “Resource Description Framework”, and RDF/XML is a serialization of RDF into something which can be read by an XML parser). Here is a section from the NASA “locations” taxonomy [9], which illustrates how a vocabulary can be published in a very real-world semantic context:

<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
xmlns:skos='http://www.w3.org/2004/02/skos/core#'
xmlns:nt2='http://nasataxonomy.jpl.nasa.gov/cvFields#'
xmlns:dcterms='http://purl.org/dc/terms/'
xmlns:dc='http://purl.org/dc/elements/1.1/'>
<skos:Concept rdf:about='loc:83'>
<skos:prefLabel>Phoebe</skos:prefLabel>
<skos:broader rdf:resource='loc:65'/>
<nt2:status>Approved</nt2:status>
<nt2:type>Descriptor</nt2:type>
<nt2:code>83</nt2:code>
<nt2:inputdate>2004-05-01</nt2:inputdate>
<dcterms:dateAccepted>2004-06-11</dcterms:dateAccepted>
<dcterms:modified>2004-06-11</dcterms:modified>
</skos:Concept>
...
</rdf:RDF>

Anyone familiar with XML will recognize the content right away, even without a previous knowledge of SKOS. The first line simply states that the document is XML. The <rdf:RDF> element has attributes describing the namespaces used, e.g. the RDF/XML and SKOS definitions as well as the standard Dublin documentation standards. The rest is a single SKOS concept for a location with the cryptic label “loc:83” (this is a URI, though unfortunately the namespace 'loc:' has not been declared in the RDF file -- we can guess it should be something like:
xmlns:loc='http://nasataxonomy.jpl.nasa.gov/xml/locations.skos#')
Each concept has one or more preferred labels <skos:prefLabel> that are human-readable strings. In this case, the preferred label tells us that location loc:83 is actually an astronomical object called “Phoebe” (FOOTNOTE: more properly, loc:83 names “the concept of Phoebe”: Phoebe is a thing you find in the sky; the concept of Phoebe is something you find in a library index or on a computer). Solar system experts will immediately recognized that Phoebe is one of Saturn's moons and hence of obvious interest to NASA. This concept has a single ontological entry in the form of a “broader than” reference to the concept “loc:65”, which -- unsurprisingly -- is Saturn. The other concept entries are NASA internal things (<nt2:...>) or purely documentation items expressed using the internationally accepted Dublin Core vocabulary (<dcterms:...). One immediately notices that the real astronomical content of the <skos:Concept> boils down to a very small number of things:
• the name “loc:83” is associated with the astronomical object “Phoebe”
• the hierarchically broader concept associated with “loc:83” is “loc:65”, “Saturn”
The rest is just syntax information and documentation. Note that “loc:65” is the concept for Saturn, not the string “Saturn”. This is good for several reasons: “Saturn” can mean other things in other semantic contexts; “Saturn” might be spelled differently in different languages (NASA's loc:65 Concept could have included the labels <skos:prefLabel xml:lang='en'>Saturn</skos:prefLabel> and <skos:prefLabel xml:lang='zh'> </skos:prefLabel> appropriate for Chinese end-users). The label “loc:83” thus remains an unambiguous and universal label for a clear astronomical concept, one of Saturn's moons. To what extent that Saturn can be considered a “broader” term than one of its satellites is defined by the context: in somebody else's taxonomy, the broader term might have been “moons of planets”, but the creators of the NASA taxonomy were very happy to have an official list of locations with a minimum of ontological baggage.
The same document expressed in “Turtle” looks like the following:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix nt2: <http://nasataxonomy.jpl.nasa.gov/cvFields#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<loc:83>

nt2:code "83";
nt2:inputdate "2004-05-01";
nt2:status "Approved";
nt2:type "Descriptor";
dcterms:dateAccepted "2004-06-11";
dcterms:modified "2004-06-11";
a skos:Concept;
skos:broader <loc:65>;
skos:prefLabel "Phoebe".

You may or may not find this more readable; it clearly requires a specialised parser. What is possibly not obvious is that the RDF/XML form also, strictly, needs a special parser. The RDF/XML format is a flexible one, and for example permits the string-valued relations to be expressed as attributes:

<skos:Concept rdf:about='loc:83'
skos:prefLabel='Phoebe'
nt2:status='Approved'
nt2:type='Descriptor'
nt2:code='83'
nt2:inputdate='2004-05-01'
dcterms:dateAccepted='2004-06-11'
dcterms:modified='2004-06-11'>
<skos:broader rdf:resource='loc:65'/>
</skos:Concept>
Few RDF/XML writers take advantage of the flexibility the format offers, and so these files can often be processed as 'just XML', but one should be aware that doing so is not completely reliable.
NASA's RDF/XML “taxonomies” stand alone in the sense that they define a semantic context with welldefined entries but which make no references to a higher semantic level. For instance, “loc:3” is “Planetary Systems” around the Sun, but there is no way to connect this concept to exoplanetary systems (before the Kepler mission, this wasn't a problem for NASA scientists, but they will presumedly have to revise their location vocabulary). This shows that scientific vocabularies are dynamic objects whose versions must be updated and maintained. The IAU 1993 thesaurus suffers considerably from signs of aging; the IVOA is attempting to rectify this by creating and maintaining a new thesaurus (LINK!).

The other obvious observation is that the NASA taxonomies probably do not correspond to ESA's location taxonomy (not published, if it exists). Two different organizations are likely to create different vocabularies for the same purpose but with very different formats, ranges, and limits. When NASA and ESA computers want to cooperate, there must be a means by which ESA can understand that NASA means “Saturn's moon, Phoebe” when it says “loc:83” and vice versa. Thus, it is generally not enough to simply publish your vocabulary, you should also aim to publish a mapping of (at least part of) your vocabulary into another one. Until the IVOA publishes its own all-purpose master vocabulary, the only relevant master translations are to the AVM taxonomy and the IAU thesaurus of 1993, despite the limitations and errors of the latter, as published by the IVOA semantics working group.
Mapping is a long-standing problem: you can either map into and out of a large vocabulary, or you can publish a set of peer-to-peer mappings. There is no simple answer to which is best.
Even when large vocabularies like NASA's taxonomies or the IAU thesaurus exist, this does not mean that one should not publish and use one's own: master vocabularies are, by definite, monstrous things with many useless entries for any particular purpose (VOEvent probably doesn't need a special vocabulary entry for the concept of an armillary sphere, present in the IAU 1993 thesaurus). A specialpurpose vocabulary is easy to define, easy to publish, easy to use, but can still be connected to the larger astronomical world outside via references to external vocabularies. Managing the trade-offs here is an engineering decision, not an exotic semantic one.
The practical steps in creating and using vocabularies within the VOEvent context are described in the remaining subsections.
Step 0: Where is the semantic content of a VOEvent document?
The VOEvent Version 1.1 protocol contains several parts whose content can and should be placed in a clear semantic context. “Clear” here means that the recipient of a VOEvent document has the possibility of identifying the terms used by the creator in a manner suitable for automatic processing by a computer and with a minimum of human pre-intervention or guesswork.

<What>
This section is obviously the heart of a VOEvent document, since it describes in technical detail what the event consists of in detail.

The <Param> elements used within <What> are the fundamental units of information and have the attributes “name” (string), “ucd”, “value” and “unit”. While the UCD values should be taken from the official IVOA UCD list (LINK!) only, the values are presumedly some real numbers, and the units are supposed to be taken from the Vizier list and grammar of standard units, it is obviously beneficial if the names of the parameters can be uniquely identified. Some parameters will be highly specific to some instrument, others like fluxes and epochs are often easily described by the UCD, but others may be standard concepts for which a random name might hide the semantic content. For example, “ucd=phot.mag;em.opt.R” says that the parameter describes the brightness of something in an R-filter, but not whether that filter is a Johnson, Bessel, Sloan, “R” from RGB, or some other reddish filter. Formally, the VOEvent protocol lets the publisher communicate such details in the form of a <How> element, e.g. via a link to an RTML document (LINK!), but in practice VOEvents should be as selfcontaining as possible.

The <Group> element is used with <What> to group <Param>'s into meaningful units and so have the attributes “name” and “type”. The VOEvent standard does not place any restrictions on either attribute, but a publishable semantic description of such is again obviously advantageous. With a single <Param> value, it may be possible to guess the semantic content by the UCD term only (as with the red magnitude above), but for <Group>s this is unlikely to occur for if there is no standardized way of expressing the content of the “type” attribute.

<Why>
This VOEvent element obviously contains the most semantic information: this is the whole point of this element, but also the reason that its semantic usage has been minimal within the burgeoning VOEvent community. A <Why> element contains one or more <Name>'s, <Concept>'s, and <Inference>'s, fields.

The VOEvent standard says “the value of a <Concept> element uses a controlled vocabulary to express the hypothesized astrophysics” but admits that such a controlled vocabulary does not yet exist. In fact, the goal is to create a VOEvent-specific controlled vocabulary for VOEvent version 2.0 definition, in which case the possible form of the <Concept> content will be clearly defined.
The <Name> element is generally to be used for object names, e.g. those recognized by SIMBAD or NED, so semantic contextual information should not be placed here but in a <Concept>.
The <Inference> element has the optional attributes “probability” and “relation”. The former is clearly a number (between 0 and 1) but the latter “... is a natural language string that expresses the degree of connection between the <Inference> and the event described by the packet” and so contains obvious semantic content which needs to be clearly specified. The VOEvent 1.1 document suggests using things like “associated” and “identified” but places no normative constraints on the field, making it difficult to publish and interpret. Standardisation would be useful here: there is an extensive literature on 'argumentation ontologies', which covers more than would be required here, but which could be cherrypicked usefully.
Thus, the semantic content of a VOEvent document can be reduced to
• the name attributes of <Params> (in <What>, only partially covered in a standard VOEvent vocabulary)
• the name and type attributes of <Groups> (Ibid.)
• the content of <Concept> (in <Why>, easily covered with vocabulary)
• the relation attribute of <Inference> (in <Why>, best covered with a standard VOEvent vocabulary)

In order to understand how this content can be placed in a simple and computer-manipulatable semantic context, one first has to get to know the means by which the semantic content can be documented in general.
Step 1: Choose/Publish your vocabulary
The simplest choice of vocabulary is one already defined and published and appropriate to your needs. Within VOEvent, you have the choice of the IAU thesaurus and the AVM taxonomy published as example vocabularies by the IVOA semantics working group, the vocabulary used by the Catalina Sky Survay, and -- hopefully available by the time this book is published -- the prototypical VOEvent master vocabulary.

If you need a different vocabulary, you will have to publish your own. Using the NASA taxonomies as examples, this might be something like the following: imagine that you operate a visual sky survey project called “Blue & Red” only capable of distinguishing between blue and red variable stars. You choose to define your own vocabulary for the three types of variable objects you can find -- blue, red, and white stars -- and for the two types of measurements made, the red and blue visual magnitudes:

<?xml version="1.0" encoding="ISO-8859-1"?>
<rdf:RDF
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
xmlns:skos='http://www.w3.org/2004/02/skos/core#'
xmlns:dcterms='http://purl.org/dc/terms/'
xmlns:foaf='http://xmlns.com/foaf/0.1/'
xmlns:iau93='http://www.ivoa.net/rdf/Vocabularies/IAUT93#'
xml:base='http://www.blueandred.org/rdf/BlueAndRed/v9.3'>
<skos:ConceptScheme rdf:about="">
<dcterms:title xml:lang="en">BlueAndRed</dcterms:title>
<dcterms:description xml:lang="en">
A vocabulary for the "Blue &amp; Red" variable star survey.
</dcterms:description>
<dcterms:creator>
<rdf:Description><foaf:name>Johanna Kepler</foaf:name></rdf:Description> </dcterms:creator>
<dcterms:created>2010-12-25</dcterms:created>
</skos:ConceptScheme>
<skos:Concept rdf:about='#redVars'>
<skos:prefLabel xml:lang='en'>red variables</skos:prefLabel>
<skos:definition>Variables that are brighter in the red than in the
blue.</skos:definition>
<skos:broader rdf:resource="iau93:VariableStars" />
<skos:broader rdf:resource="iau93:RedStars" />
</skos:Concept>
<skos:Concept rdf:about='#blueVars'>
<skos:prefLabel xml:lang='en'>blue variables</skos:prefLabel>
<skos:definition>Variables that are brighter in the blue than in the
red.</skos:definition>
<skos:broader rdf:resource="iau93:VariableStars" />
<skos:broader rdf:resource="iau93:BlueObjects" />
</skos:Concept>
<skos:Concept rdf:about='#whiteVars'>
<skos:prefLabel xml:lang='en'>white variables</skos:prefLabel>
<skos:definition>Variables that are neither particularly red nor
blue.</skos:definition>
<skos:broader rdf:resource="iau93:VariableStars" />
</skos:Concept>
<skos:Concept rdf:about='#blueMag'>
<skos:prefLabel xml:lang='en'>blue brightness</skos:prefLabel>
<skos:definition>Blue visual magnitude estimated using a comparison
LED.</skos:definition>
<skos:broader rdf:resource="iau93:VisualMagnitude" />
</skos:Concept>
<skos:Concept rdf:about='#redMag'>
<skos:prefLabel xml:lang='en'>red brightness</skos:prefLabel>
<skos:definition>Red visual magnitude estimated using a comparison
LED.</skos:definition>
<skos:broader rdf:resource="iau93:VisualMagnitude" />
</skos:Concept>
</rdf:RDF>

The <skos:ConceptScheme> serves to document the vocabulary and its creator. Normally, one would place the top taxonometric entries in “top concept” elements to aid navigation, but this vocabulary is so small that this is totally unnecessary. Like NASA, one could have chosen a more obscure set of labels -e.g. “123abc” for “redVars” -- since the formal names set by the “rdf:about” are URIs, and so really for computer consumption only. However, it's just as easy to be more explicit and human-readable. For a full set of “good practice” recommendations, see the IVOA white paper on vocabularies (http://www.ivoa.net/Documents/REC/Semantics/Vocabularies-20091007.html#practices), and you can download a validator for your vocabulary at [10].
The corresponding translation entries have been included here as “broader” entries, assuming that the burden on the publisher and consumer is minimal for such a small vocabulary.
This vocabulary document should be available at a clearly reachable URI, e.g.
http://www.blueandred.org/rdf/BlueAndRed/v9.3/BlueAndRed.skos
and should preferably be mirrored at the IVOA for long-term documentation purposes and ease of access. The namespace for the vocabulary terms was also given in the xml:base attribute in the vocabulary above. An ideal documentation strategy is to make the nominal URI of the entire vocabulary, e.g.
http://www.blueandred.org/rdf/BlueAndRed/v9.3
a normal HTTP-accessible webpage: the URI http://www.ivoa.net/rdf/Vocabularies/IAUT93 (i.e. without the “#” separator between root address and vocabulary label) is actually a browseable list of the IAU 1993 thesaurus entries.
Step 2: Add/Parse the vocabulary to/from the VOEvent document
In order to make the “Blue and Red Variable Stars” and VOEvent vocabularies accessible, you must define your namespace and add it to the VOEvent document (or note the namespace so you can reference the items when reading a document referring to the “BlueAndRed” vocabulary):

<?xml version="1.0" encoding="UTF-8"?>
<voe:VOEvent
ivorn="ivo://BlueAndRed.org/events#123457"
role="observation"
version="1.1"
xmlns:voe="http://www.ivoa.net/xml/VOEvent/v1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:br="http://www.BlueAndRed.org/rdf/BlueAndRed/v9.3#"
xmlns:voe="http://www.ivoa.net/rdf/Vocabularies/VOEvent/v1.0"
xmlns:iau93="http://www.ivoa.net/rdf/Vocabularies/IAUT93#"
xsi:schemaLocation="http://www.ivoa.net/xml/VOEvent/v1.1
http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd">
This entry permits semantic references in the <What> section like:
<What>
<Param name="br:blueMag" value="12" unit="mag" ucd="phot.mag;em.opt.B"/> <Param name="br:redMag" value="19" unit="mag" ucd="phot.mag;em.opt.R"/> <Reference uri="http://www.BlueAndRed.org/events/123456"/>
<Description>visual magnitudes</Description>
</What>
in which the blue- and red-magnitudes of the observations are documented using a specialized vocabulary. Similarly one can then have entries in the <Why> section like:
<Why importance="0.9" expires="2010-12-31T23:59:59">
<Concept>br:objTyp2</Concept>
<Description>

More blue light than red light and not seen last year, so must be a blue variable star.
</Description>
<Inference relation="voe:identified" probability="0.1">
Awfully big brightness difference, so maybe a brand new proto-planetary nebula with no Halpha?
<Concept>iau93:PlanetaryNebulae</Concept>
</Inference>
</Why>
which uses both a specialized object classification and a standardized VOEvent inference vocabulary.
Step 3: Consuming external vocabularies
The previous two steps were enough for a publisher: defining and publishing vocabularies and then using them in VOEvent documents. The trickier part is left for the consumer: how do I identify whether the new semantic information is interesting?

The first step is simply to parse the VOEvent documentation. Since the document has been parsed as XML anyway, identifying the elements with the foreign vocabulary information is straight-forward. In the example above, it may or may not be necessary to parse the <What> information: the UCD entries clearly identify the magnitudes as being bluish and reddish magnitudes. In the <Why> section, the clearest need is to be able to parse the concept information: am I interested in new blue objects and/or things potentially related to planetary nebulae? The full parsing of the <Why> information in the example above would consist of two steps: determining whether the identification is interesting and whether the inference is of relevance.

To determine if “br:blueVars”. easy to interpret, NASA's “loc:83” is fairly obscure. Accessing the SKOS file for the “BlueAndRed” vocabulary is easily done via the namespace
“iau93:VariableStars” and “iau93:BlueObjects”.
declaration, however, yielding a clear reference to If your VOEvent filter is interested in blue variable

objects, then it may certainly be appropriate to continue parsing this VOEvent document. If you are also interested in planetary nebulae, then the reference to the concept in the <Inference> section is very simple: even if one doesn't keep the entire IAU 1993 thesaurus in memory, one can easily keep a sub-set of interest and test concepts and inferences against it.

Although we have talked, above, of parsing random external vocabularies, this is not something one would want to do very often. It is better regarded as a 'compile-time' operation in most cases. a <Why> concept is relevant and interesting, one first has to identify what is meant by The vocabulary names are often of little direct use: while “iau93:PlanetaryNebulae” is
Conclusions
Producing and consuming VOEvent documents without expressing or appreciating their full semantic context is a shame: it is really easy to place events in a clearer astrophysical semantic context, thereby helping consumers to judge the potential scientific interest and impact. VOEvent vocabularies are easily expressed, easily stored, easily found, and easily parsed. Shame on you if you don't use them!
References
[1] Wiktionary: http://en.wiktionary.org/wiki/semantics
[2] ISO 5964:1985, Documentation — guidelines for the establishment and development of multilingual thesauri. International Standard, 1985
[3] BS 8723-1:2005, Structured vocabularies for information retrieval
[4] T. R. Gruber. A translation approach to portable ontology specification. Knowledge Acquisition, 5(2):199–220, 1993. do:10.1006/knac.1993.1008
[5] NASA taxonomy: http://nasataxonomy.jpl.nasa.gov/fordevelopers/#skos
[6] Hurt, Christensen, and Gauthier 2008, “Virtual astronomy metadata project”
http://www.virtualastronomy.org/AVM_Version1.1May312008.pdf
[7] Ontology of Astronomical Object Types
http://www.ivoa.net/Documents/latest/AstrObjectOntology.html [8] http://www.w3.org/TR/2009/REC-skos-reference-20090818/ [9] NASA “locations” taxonomy
http://nasataxonomy.jpl.nasa.gov/xml/locations.skos [10] Vocabulary validation
http://code.google.com/p/volute/downloads/list
4 Appendices

The three appendices are the standards under development in the International Virtual Observatory Alliance: The VOEvent 2.0 working draft, The Simple Event Access Protocol (SEAP) working draft, and an IVOA Note on authentication of VOEvent packets.
Photo credit: Flickr/aMichiganMom
4.1 VOEvent Specification
Version 2.0 Working Draft
Editors:
Rob Seaman, seaman@noao.edu Roy Williams, roy@caltech.edu
Authors:
International Virtual Observatory Alliance

Rob Seaman, National Optical Astronomy Observatory, USA Roy Williams, California Institute of Technology, USA Alasdair Allan, University of Exeter, UK
Scott Barthelmy, NASA Goddard Spaceflight Center, USA Joshua S. Bloom, University of California, Berkeley, USA John M. Brewer, Yale University, USA
Matthew Graham, California Institute of Technology, USA Frederic Hessman, University of Gottingen, Germany Szabolcs Marka, Columbia University, USA
Arnold Rots, Harvard-Smithsonian Center for Astrophysics, USA Tom Vestrand, Los Alamos National Laboratory, USA Przemyslaw Wozniak, Los Alamos National Laboratory, USA

VOEvent [21] defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community. VOEvent is focused on the reporting of photon events, but events mediated by disparate phenomena such as neutrinos, gravitational waves, and solar or atmospheric particle bursts may also be reported.

Structured data is used, rather than natural language, so that automated systems can effectively interpret VOEvent packets. Each packet may contain one or more of the "who, what, where, when & how" of a detected event, but in addition, may contain a hypothesis (a "why") regarding the nature of the underlying physical cause of the event. Citations to previous VOEvents may be used to place each event in its correct context. Proper curation is encouraged throughout each event's life cycle from discovery through successive follow-ups.

VOEvent packets gain persistent identifiers and are typically stored in databases reached via registries. VOEvent packets may therefore reference other packets in various ways. Subscribers, human or machine, receive immediate notification of events, based on previously defined criteria. Packets are encouraged to be small and to be processed quickly. This standard does not define a transport layer or the design of clients, repositories, publishers or brokers; it does not cover policy issues such as who can publish, who can build a registry of events, who can subscribe to a particular registry, nor the intellectual property issues.
1. Introduction
Throughout human history, unexpected events in the sky have been interpreted as portents and revelations. Modern curiosity seeks to use such transient events to probe the fundamental nature of the universe. In decades to come the scientific study of such events will be greatly extended, with new survey telescopes making wide-area systematic searches for time-varying astronomical events, and with a large number of robotic facilities standing ready to respond. These events may reflect purely local solar system phenomena such as comets, solar flares, asteroids and Kuiper Belt Objects, or those more distant such as gravitational microlensing, supernovae and Gamma-Ray Bursts (GRBs). Most exciting of all may be new and unknown types of event, heralding new horizons for astrophysics. Searches for astrophysical events are taking place at all electromagnetic wavelengths from gamma-rays to radio, as well as quests for more exotic events conveyed by such means as neutrinos, gravitational waves or high-energy cosmic rays.

For many types of events, astrophysical knowledge is gained through fast, comprehensive follow-up observation — perhaps the immediate acquisition of the spectrum of a suspected optical counterpart, for example — and in general, by observations made with instruments in different wavelength regimes or at different times. To satisfy these needs, several projects are commissioning robotic telescopes to respond to digital alerts by pointing the telescope and triggering observations in near real-time and without human intervention. These include, for instance, Skyalert[6] in the USA, and RoboNet-1.0 [13] and eStar[3] in the United Kingdom. Automated systems may also query archives and initiate pipelines in response to such alerts.

Many projects have been conceived — some now in operation — that will discover such time-critical celestial events. These include a large number of robotic survey and monitoring telescopes with apertures from tens of centimeters to tens of meters, large-field survey projects like CRTS [9], PTF [32], PanSTARRS [10] and LSST [8], satellites like Swift and Fermi [12], and more singular experiments like LIGO [7]. The community has demonstrated that robotic telescopes [14] can quickly follow-up events using the standard outlined in this document. In the past, human-centric event alert systems have been very successful, including the Central Bureau for Astronomical Telegrams (CBAT) [2] and the Astronomer's Telegram (ATEL) [1], but these systems use predominantly natural-language text to describe each event, and do not have sophisticated selection criteria for subscribers. The GRB Coordinates Network (GCN) [4] reports one of the most fruitful event streams of current times, and its events are transmitted very successfully for follow-up within seconds or minutes. With VOEvent, we would like to leverage the success of GCN by making it interoperable with other producers of events, and by generalizing its transport mechanisms.

A much larger rate of events can be expected as new facilities are commissioned or more fully automated. These rates indicate events that must be handled by machines, not humans. Subscribing agents must be able to automatically filter a tractable number of events without missing any that may be key to achieving their goals. In general, the number of pending events from a large-scale survey telescope (such as LSST) that are above the horizon at a given observatory during a given observing session may be orders of magnitude larger than a human can sift through productively. Selection criteria will need to be quite precise to usefully throttle the incoming event stream(s) — say — "give me all events in which a point source R-band magnitude increase of at least -2.0 was seen to occur in less than four hours, that are located within specified molecular column density contours of a prioritized list of galactic star forming regions". In practice the result of complex queries such as these will be transmitted through intermediary "brokers" — which will subscribe to VOEvent-producing systems and provide filter services to client groups ("subscribers") via specialized VOEvents. Filtering will often be based on coincidence between multiple events. A gravitational wave detector may produce a large number of candidate events, but the interesting ones may be only those that register with multiple instruments.

Handling the anticipated event rates quickly and accurately will require alert packets to be issued in a structured data format, not natural language. Such a structured discovery alert — and any follow-up packets — will be referred to as a VOEvent. VOEvent will rely on XML schemata [30] to provide the appropriate structured syntax and semantics. These schemata may be specific to VOEvent or may reference external libraries such as the IVOA's Space-Time Coordinate (STC) metadata specification [18], the Remote Telescope Markup Language (RTML) [15], or the simpleTimeSeries specification from the dotAstro project [31]

VOEvent is a pragmatic effort that crosses the boundary between the Virtual Observatory and the larger astronomical community. The results of astronomical observations using real telescopes must be expressed using the IVOA VOEvent standard, be recorded and transmitted via registries and aggregators within and outside the VO, and then be captured and filtered by subscribing VO clients. Each event that survives rigorous filtering can then be passed to other real (or possibly virtual) telescopes, for instance via RTML, to acquire real follow-up observations that will confirm (or deny) the original hypothesis as to the classification of the object(s) or processes that generated that particular VOEvent in the first place. This must happen quickly (often within seconds of the original VOEvent) and must minimize unnecessary expenditures of either real or virtual resources.

VOEvent is a mechanism for broadcasting discoveries that others may wish to follow-up, and this purpose defines its scope. An astronomical discovery that cannot benefit from immediate follow-up is not a good candidate for expression as a VOEvent.

Following the Abstract and Introduction, this document contains a discussion of appropriate VOEvent usage in §2. Section 3 is the heart of the document, conveying the semantics of a VOEvent packet. Explicit examples of VOEvent packets are in §4, and linked references in §5.

1.1 Changes from VOEvent 1.1
• The concept of event stream in introduced in section 2.2, this in new in VOEvent 2.0. The stream metadata acts as a template for the events in the stream, and is registered with the VO registry.

• The section on transport of VOEvents has been removed, so it can be handled in its own standards process.
• The section on Registry enhancements to support VOEvent has been expanded and clarified.
• The <Param> elements can now have <Description> and <Reference> elements
• The value of a <Param> element can now be expressed as an element in addition to an attribute.
• The <Param> element now has an attribute "dataType" to express the meaning of the parameter value (int, float, string).
• There is a new <Table> element to express simple tables, see section 3.3.3.
• There is a new <SimpleTimeSeries> element to express time series, with particular application for light curves. See section 3.3.4.
• The VOEvent packet structure still conforms to the IVOA Space-Time Coordinates standard, but there is a new, simplified schema for these elements that is completely within the VOEvent schema.
• The semantic implication of a <Citation> element is clarified: section 3.7
• The <Reference> element has a more sophisticated notion of type as a general URI rather than enumeration of a few.
2. Usage
This document defines the semantics of an alert packet known as VOEvent [21]. In this document, the word packet will refer to a single, syntactically complete, VOEvent alert or message, however transmitted or stored. The transmission of such a packet announces that an astronomical "event" has occurred, or provides information contingent on a previous VOEvent through a citation mechanism. The packet may include information regarding the "who, what, where, when & how" of the event, and may express one or more "why" hypotheses regarding the physical cause of the observed event and the likelihood of each of these hypotheses.
2.1 Publishing VOEvent Packets
VOEvent packets express sky transient alerts. VOEvent users subscribe to the types of alerts pertinent to their science goals. In addition to Publisher and Subscriber, the following roles define the interchange of VOEvent semantics:

• An Author is anyone (or any organization) creating scientific content suitable for representation as a sky transient alert. An author will typically register with the IVOA registry, so that the <Who> element of VOEvent packets can be small and reusable, expressing only the IVOA identifier needed to retrieve the contact information for the author.
• A Publisher receives alerts from one-or-more authors, and assigns a unique identifier to each resulting packet. Either the author or the publisher generates the actual XML syntax of the event, but the publisher is responsible for the validity of the packet relative to the VOEvent schema. Publishers will register with the IVOA registry as described below.
• A Repository subscribes to one or more VOEvent streams, persists packets either permanently or temporarily, and runs a service that allows clients to resolve identifiers and apply complex queries to its holdings. A given packet had one Publisher but may be held in more than one Repository. Public repositories will register with the IVOA registry.
• A Subscriber is any entity that receives VOEvent packets for whatever purpose. Subscribers can find out how to get certain types of events by consulting the lists of publishers and repositories in the IVOA registry. A subscription is a filter on the stream of events from a publisher: the subscriber is notified whenever certain criteria are met. For example, the filter may involve the curation part of the event (e.g., "all events published by the Swift spacecraft"), its location ("anything in M31"), or it may reference the detailed metadata of the event itself ("whenever the cosmic ray energy is greater than 3 TeV").
• A Broker or Relay, also sometimes known as a Filter, is any combination of the atomic roles of Publisher, Repository, or Subscriber that also offers arbitrary application-level functionality. See the IVOA VOEvent Transport Note [21] for further discussion.

2.2 VO Identifiers (IVORNs) and Publishers
VOEvent benefits from the IVOA identifiers developed for the VO registry. Such an identifier is called an IVORN, that is, an International Virtual Observatory Resource Name. It is required to begin with "ivo://", and will stand in for a particular packet. A registered VOEvent packet is one that has a valid identifier — meaning that a registry exists that can resolve that identifier to the full VOEvent packet. VOEvent identifiers thus provide a citation mechanism — a way to express that one VOEvent packet is a follow-up in some fashion of a previous packet. For these reasons, VOEvent packets will often contain VO identifiers [16]. These take the general form ivo://authorityID/resourceKey#local_ID, and are references to metadata packets that may be found at a VO registry or VOEvent repository. There are several types of metadata schema that the registry can hold. For the purposes of VOEvent, the principal schemata are:
• VOEvent: the metadata packet for an alert resulting from the observation of a transient celestial

event. This schema is defined in this document.
• VOEventStream: the metadata packet for a stream of VOEvents, including information about who
is running it, the parameters that may be included and their meaning. The VOEventStream may also
be shortened to just 'stream', they mean the same thing.
• VOEventServer: the metadata packet to describe a service that provides VOEvents, which may be
past events from a repository query service, or may be events sent in near real-time from a
subscription service. The server definition includes the list of streams whose events are kept, the
service endpoint to query the repository, or the endpoint to resolve a VOEvent identifier.
• Author Organization: this metadata describes an author, including contact information and a
description of the project. The VOEvent <Who> element contains either a reference to an author's
IVORN or explicit contact information sufficient to describe the author.
When such an identifier is resolved, it means that the VOEvent metadata packet is obtained in exchange for the identifier. Such resolution happens through the global, distributed IVOA registry in stages. The registry is queried to locate a repository holding the relevant packet, and then the repository is queried for the packet itself. The part of the IVORN before the "#" symbol points to the VOEventStream of which the event is a member; the whole IVORN (that includes the local_ID) points to the event itself. Thus VOEvent identifiers are overloaded; they contain a stream identifier, then the "#" sign, then the local reference within that stream.
This is a key point in understanding VOEvent identifiers: The Event identifier also expresses the Stream identifier. For example:
• ivo://nvo.caltech/voeventnet/catot#1004071150784109051
• This identifier points to a specific VOEvent (number 1004071150784109051) that is an instance of
the stream called ivo://nvo.caltech/voeventnet/catot. However, this IVORN will not resolve from the
global VO registry, but only from a repository that has this stream of events.
• ivo://nvo.caltech/voeventnet/catot
• This Stream identifier can be looked up in any VO registry, returning a description, who runs it, the
names, semantics, and descriptions of the parameters used in the events, how to subscribe, etc. In
this case, the stream represents optical transients from the CRTS survey. For resolving the event
itself, we want a repository that will have the event, so a query would be used like this: "Find
repositories that keep the events from this Stream"
The nature of a standard service to query VOEvent server records and the metadata necessary to describe a Stream remain under debate in the VOEvent Working Group.
2.3 Authentication and Authorization
VOEvents provide a mechanism for alerting members of the astronomical community to time-critical celestial phenomena. As a result of such an alert, significant hardware, software and personnel assets of the community may be retargeted to investigate those phenomena. The scientific and financial costs of such retargeting may be large, but the potential scientific gains are larger. The success of VOEvent — and of observations of astronomical transients in general — depends on minimizing both intentional and unintentional noise/spam associated with this communications channel. All of the familiar internet security worries apply to VOEvents. These questions are addressed elsewhere.

2.4 Registry Enhancements
The registry enhancements (proposed elsewhere) will make it easier to work with VOEvents. These consist of metadata records called VOEventStream and VOEventServer, as described below.
2.4.1 VOEventStreams in the VO Registry
The stream metadata defines the meanings of the parameters and table columns that are used in a homogeneous collection of events from a specific project, instrument, or observatory. The VO Registry will hold these definitions, and will have the following purposes and capabilities.

• Resolving an event: the unique identifier for an event is a concatenation of a stream identifier and an event number within that stream. A question to the Registry finds which VOEventServer has query capability for that stream, and then that server can be probed to get the full event metadata.
• What is this event: the event identifier contains the VOEventStream identifier, from which the Registry can produce the descriptive text, contact information for the responsible people, and so on.
• Subscription to a stream: VOEventServers are being built to push events to those who want them by a variety of messaging protocols; in order for an astronomer to set this up, the Registry is asked which servers provide the "subscription capability" for the given stream, so that the astronomer can work with that server to set up future delivery of events.
• Creating a Stream: A survey or project may wish to publish am event stream. The Registry will provide a way to define the nature of the coming events (VOEventStream) and where to get them (VOEventServer), and thus allow others to find and subscribe to those events.
• What does this Parameter mean: Each event has a set of keyword parameters; the Registry can be used to find out their meanings.
2.4.2 VOEventServer in the VO Registry
Once the stream is defined in the registry, the question is how to find it, with the kinds of services that might be wanted. These are known as Capabilities in the VO registry model. Three kinds of capability that we can mention are subscription, formal query, and informal query. If a server supports a subscription capability, it means that a client can submit a criterion (for example "R magnitude brighter than 17"), and events will be sent by the server in the future which satisfy that criterion. A formal query capability implies the existence of a formal request-response protocol by which queries can be made and results returned; this will be the "Simple Event Access Protocol" when it becomes an IVOA recommendation. An informal query capability means a web page with forms by which a collection of events can be browsed in some way.

The capability of a server is split further into Interfaces, which express precisely how the capability can be accessed by a client. For example, subscription capability could be achieved by having email, instant messaging, or text message sent; these are three different interfaces to the subscription capability, and there is different metadata associated with each (email address vs phone number for example).
3. VOEvent Semantics
A VOEvent packet provides a general purpose mechanism for representing information about transient astronomical events. However, not all VO data are suitable for expression using VOEvent. The VOEvent schema [6] is as simple as practical to allow the minimal representation of scientifically meaningful, time critical, events. VOEvent also borrows other standard VO and astronomical schema, specifically STC for space-time coordinates and simpleTimeSeries to represent light curves and other time series. The usual IVOA standards such as registries and UCD identifiers are used. VOEvent has a strong interest in the development of complete and robust astronomical ontologies, but must rely on pragmatic and immediately useful prototypes of planned facilities.

By definition, a VOEvent packet contains a single XML <VOEvent> element. Multiple <VOEvent> elements may be jointly contained within a larger XML document, but these should be handled as separate alert packets. A <VOEvent> element may contain at most one of each of the following optional sub-elements:

<Who>
<What>
<WhereWhen> <How>
<Why>
<Citations>
<Description> <Reference>

Identification of scientifically responsibel Author Event Characterization modeled by the Author Space-Time Coordinates of the event
Instrument Configuration
Initial Scientific Assessment
Follow-up Observations
Human Oriented Content
External Content

Only those elements required to convey the event being described need be present; the ordering of elements is immaterial to interpretation, but may be important for efficient processing in demanding applications. The intent of VOEvent is to describe a single astronomical transient event per packet. Multiple events should be expressed using multiple packets. On the other hand, complex observations may best be expressed using multiple follow-up packets or via embedded <References> to external resources such as VOTables or RTML documents. XML structures other than those listed in this document should be used with care within a <VOEvent> element, but some applications may require the freedom to reference schema outside the scope of this specification. Section 4 contains examples of complete VOEvent packets.

3.1 <VOEvent> — identifiers, roles and versions
A <VOEvent> expresses the discovery of a sky transient event, located in a region of space and time, observed by an instrument, and published by a person or institution who may have developed a hypothesis about the underlying classification of the event.
The <VOEvent> element has three attributes:
3.1.1 ivorn — Each VOEvent packet is required to have one-and-only-one identifier, expressed with the ivorn attribute. VOEvent identifiers are URIs [16]. As the issuance of duplicate identifiers would diminish the trust placed in systems exchanging VOEvents, it is anticipated that a number of VOEvent publishers will be founded to issue unique IVORNs from a variety of useful and appropriate namespaces. The identifier actually contains TWO IDENTIFIERS: the first part is the identifier for the publisher, and the event identifier is built from this, then a # symbol, then a local string that is meaningful only in the context of that publisher.
3.1.2 role — The optional role attribute accepts several possible values, including these:
• The value "observation" is the default if the role is missing; this means that the packet describes an observation of the actual universe.
• The value "prediction" indicates that the VOEvent describes an event of whatever description that has yet to occur when the packet is created.
• The value "utility" means that the packet expresses nothing about astrophysics, but rather information about the observing system. This could be used, for example, for a satellite to express that it has changed its configuration.
• A "test" means that the packet does not describe actual astronomical events, but rather is part of a testing procedure of some kind.
• It is the responsibility of all who receive VOEvent packets to pay attention to the role, and to be quite sure of the difference between an actual event and a test of the system or a prediction of an event that has yet to happen.
• 3.1.3 version — The version attribute is required to be present and to equal "2.0" for all VOEvent packets governed by this version of the standard. There is no default value.
For example, a <VOEvent> packet resulting from Tycho Brahe's discovery of a "Stella Nova" in Cassiopeia on 11 November 1572 [25] might start:
<VOEvent ivorn="ivo://uraniborg.hven#1572-11-11/0001" role="observation" version="2.0" xmlns:... >
The xmlns attribute refers to one-or-more standard XML namespace declarations that may optionally help define the contents of a packet.
3.2 <Who> — Curation Metadata
This element of a VOEvent packet is devoted to curation metadata: who is responsible for the information content of the packet. Usage should be compatible with section 3.2 of the IVOA Resource Metadata specification [17].
Typical curation content would include:
3.2.1<Author>
Author information follows the IVOA curation information schema: the organization responsible for the packet can have a title, short name or acronym, and a logo. A contact person has a name, email, and phone number. Other contributors can also be noted.
An example of Author information might be:
<Author> <title>Rapid Telescope for Optical Response</title>
<shortName>Raptor</shortName>
<logoURL>http://www.raptor.lanl.gov/images/RAPTOR_patchLarge.jpg</logoURL> <contactName>Robert White</contactName> <contactEmail>rwhite@lanl.gov</contactEmail> <contactPhone>+1 800 555 1212</contactPhone> </Author>
3.2.2<AuthorIVORN>
As an alternative to quoting Author information over and over, this information can be published to the VO registry, then referenced through an IVORN. The <AuthorIVORN> element contains the identifier of the organization responsible for making the VOEvent available. Event subscribers will often use this as their primary filtering criterion. Many subscribers will only want events from a particular publisher, or more precisely, from a specific content creator. In general, <AuthorIVORN> should be a VOResource identifier that resolves to an organization in the sense of [17]. Publishers and subscribers may use this VOResource to exchange curation metadata directly.
3.2.3 <Date>
The <Date> contains the date and time of the creation of the VOEvent packet. The required format is ISO-8601 (e.g., yyyy-mm-ddThh:mm:ss.s, see [29]). The timescale — for curation purposes only — is assumed to be Coordinated Universal Time (UTC). Discussion of date and time for the expression of meaningful scientific coordinates may be found in [18] and [27].
Minimal <Who> usage might resemble:
usage might resemble:
05T01:23:45Z</Date> </Who>
Tycho first noted SN 1572 on 11 November of that year. The event was published in Tycho's pamphlet De Stella Nova by 5 May 1573, thus this later date is placed in the curation metadata. More detailed curation metadata can be retrieved directly from the publisher.
3.3 <What> — Event Characterization
The <What> and <Why> elements work together to characterize the nature of a VOEvent. That is: <What> has author-defined parameters about what was measured directly, or other relevant information about the event, versus <Why> is a data model of fixed schema about the hypothesized underlying cause or causes of the astrophysical event.

In general, an observation is the association of one or more dependent variables with zero or more independent variables. The <WhereWhen> element, for example, is often used to express the independent variables in an observation — where was the telescope pointed and when was the camera shutter opened. The <What> element, on the other hand, is typically used to express the dependent variables — what was seen at that location at that time.

A <What> element contains a list of <Param> elements which may be associated and labeled using <Group> elements. It may also contain <Table> elements, and <simpleTimeSeries> elements. See §4.1 for an example of usage.
3.3.1 <Param> — Numbers and strings with semantics
<Param> elements may be used to represent the values of arbitrarily named quantities. Thus a publisher need not establish a fixed schema for all events they issue. Unified Content Descriptors (UCDs) [19] may be used to clarify meaning. Usage of <Param> and <Group> is similar to the VOTable specification, see §4.1 of [22].

A <Param> may contain elements <Description> and <Reference>. Like most VOEvent elements, these can be used to give further descriptive documentation about what this parameter means. The <Param> may also contain an element <Value> for the value of the parameter, as an alternate to the 'value' attribute defined below: if both are present, the attribute takes precedence ofv the element. This allows parameter values to include a richer variety of text strings, to avoid strings being changed by Attribute-Value normalization [**] that is part of the XML specification.
The following attributes are supported for <Param>:
3.3.1.1 name — A simple utilitarian name that may be used elsewhere in the packet. This name may or may not have significance to subscribing clients.
3.3.1.2 value — A string representing the value in question. No range or type checking of implied numbers is performed.
3.3.1.3 unit — The unit for interpreting value. See §4.3 of [22] which relies on [26].
3.3.1.4 ucd — A UCD [19] expression characterizing the nature of the <Param>.
3.3.1.5 dataType — A string specifying the data type of the <Param>. Allowed values are "string", "int", or "float", with the default being "string".
For example, here are three values from a GCN [4] notice:
TRIGGER_NUM = 114299 RATE_SIGNIF = 20.49 GRB_INTEN = 73288
In VOEvent, these can be represented as:
<Param name="TRIGGER_NUM" value="114299" ucd="meta.id" /> <Param name="RATE_SIGNIF" value="20.49" ucd="stat.snr" >
<Description>Best significance after trying all
algorithms</Description>
<Reference uri="http://gcn.gsfc.nasa.gov/swift.html"/> </Param>
<Param name="GRB_INTEN " value="73288" ucd="phot.count" />
3.3.2 <Group> — collection of related Params
<Group> provides a simple mechanism for associating several <Param> (and/or <Reference>) elements, for instance, an error with a measurement. <Groups> may NOT be nested. <Group> elements may have a name attribute, and unlike VOTable usage, may also have a type attribute:
3.3.2.1 name — A simple name such as in §3.3.1.1.
3.3.2.2 type — A string that can be used to specify the "datatype" of simple application dependent data structures.
In a GCN notice, for example, we might see this line:
GRB_INTEN: 73288 [cnts] Peak=1310 [cnts/sec]
which could be expressed with one Param with a Value element, and the other with a Value attribute:
<Group type="GRB_INTEN">
<Param name="cnts" ucd="phot.count" >
<Value>73288</Value> </Param>
<Param name="peak" value="1310" ucd="arith.rate;phot.count" /> </Group>
Note also that there cannot be Groups within Groups: a Group may only contain Params and not other Groups. There are rules of uniqueness Params and Groups in VOEvent:
• Each Param must have a name. A Group without a name is equivalent to having a name which is the null string.
• Names must be unique within the set of Params not in a Group.
• Names must unique for the set of Params within a given Group.
• Groups must have unique names: this means that only one Group can be nameless.
3.3.3 <Table> — simple tabular data
This element is intended for a short and simple table. It should be noted that longer tables, or any table, can be linked using a <Reference> element. There are five elements defined in this subsection: Table, Field, Data, TR, TD.

A <Table> element can contain a sequence of <Field> elements, one for each column of the table, then a single <Data> element that contains the data of the table, which is represented as a sequence of table rows, which are <TR> elements, each containing a sequence of <TD> elements for the table cells. For a full table, where every cell has a value, the number of <TD> elements in each row should be the same as the number of <Field> elements. There is then a 1-to-1 correspondence between them for each row.

The Table can contain <Description> and <Reference> elements to add documentation; the <Field> elements can also contain these. Thus the <Table> can contain, in order, an optional <Description> and <Reference>, then a sequence of one or more <Field> elements, then a <Data> element. The <Field> element can also contain optional <Description> and <Reference> and nothing else. The <Data> element can contain only <TR> elements, each of which can contain only <TD> elements. The following explains the attributes that are allowed for these five elements.
The following attributes are supported for <Table>:
3.3.3.1 name — A simple utilitarian name that may be used for identification or presentation purposes. This name may or may not have significance to subscribing clients.
3.3.3.2 type — A string representing the type of the Table, that consumers can use for presentation or parsing. For example, a table of type "spectralLines" could mean to some community to expect columns (i.e. the <Field>s) named "wavelength", "width", "name" to define spectral lines.
The <Field> element defines the semantic nature of a Table column, and is structured similarly to the <Param> element of section 3.3.1. The following attributes are supported for <Field>: 3.3.3.3 name — A simple utilitarian name that may be used elsewhere in the packet. This name may or may not have significance to subscribing clients.
3.3.3.4 unit — The unit for interpreting the values as given in the <TD> table cells See §4.3 of [22] which relies on [26].
3.3.3.5 ucd — A UCD [19] expression characterizing the nature of the data in this table column. 3.3.1.6 dataType — A string specifying the data type of the table column. Allowed values are "string", "int", or "float", with the default being "string".
The following is an example of a Table element. Note the dataType attribute that is used to interpret the values in the table cells.
<Table> <Description>Individually Referenced Moduli and Distances for NGC 0931 from NED</Description> <Field name="(m-M)" unit="mag" ucd="phot.mag.distMod"/> <Field name="err(m-M)" unit="mag" ucd="phot.mag.distMod;stat.err"/> <Field name="D" unit="Mpc" ucd="pos.distance"/> <Field name="REFCODE"
ucd="meta.bib.bibcode"/> <Data>
<TR><TD>33.16</TD><TD>0.38</TD><TD>42.9</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.32</TD><TD>0.38</TD><TD>46.1</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.51</TD><TD>0.48</TD><TD>50.4</TD><TD>2009ApJS..182..474S</TD></TR> <TR><TD>33.55</TD><TD>0.38</TD><TD>51.3</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.71</TD><TD>0.43</TD><TD>55.2</TD><TD>2009ApJS..182..474S</TD></TR> <TR><TD>34.01</TD><TD>0.80</TD><TD>63.3</TD><TD>1997ApJS..109..333W</TD></TR> </Data> </Table>
3.3.4 <SimpleTimeseries> - time series data
This element is intended to quickly encode time series data and encourages a complete description of the data while keeping overhead to a minimum. A minimum SimpleTimeseries contains just a description of the time system used, <SPACETIMESYS>, and an empty <SERIES>.
Below is an outline of the basic tag structure.
<SimpleTimeseries>
<TITLE>
<DESCRIPTION>
<SPACETIMESYS>
<WhereWhenRef>
...OR...

<TimeFrame>
<TimeScale>
<ReferencePosition>
<TimeZero>
<Period>
<SpaceFrame>
<SpaceRefFrame>
<ReferencePosition>
<TimeDefaults>
<PositionDefaults>
<NOBAND> <BAND> <FIELD> <SERIES> <ELEM> <TIME> <T> <UNC> <RESOLUTION> <POS> < FLD_VAL>

The <SPACETIMESYS> element sets up the <TimeFrame> and (optional) <SpaceFrame> reference frames needed for describing astronomical data with a time axis and includes the ability to specify phased rather than absolute time. In the context of a VOEvent, the relevant reference frame may already be in the <WhereWhen> element, and so it is possible to simply reference it using the <WhereWhenRef> element. The syntax in both cases is borrowed from STC. In addition to the reference frame, the <SPACETIMESYS> can contain time and position defaults for the series data.

Once the time frame has been specified, a description of what data will be in the series is accomplished using <BAND> and <FIELD> elements. For data not taken in a particular bandpass (ie spectroscopy) you can specify <NOBAND>. The <FIELD> elements provide both human and machine readable descriptions of the data which may be in the series in addition to an optional default value for missing data values. The value of the <FIELD> element is a human readable label.
The following attributes are supported for <FIELD>:
3.3.4.1 fld — required — A unique identifier for the FIELD. This will be used by the individual field values to identify the data being recorded.
3.3.4.2 bandid — required — A reference to the bandid of a BAND or NOBAND element. 3.3.4.3 ucd — required — Virtual Observatory Uniform Content Description describing the type of data this field represents (ie "opt;photo;i").
3.3.4.4 datatype — required — The data type (such as "float") of the data for this field.
3.3.4.5 unit — required — Units that the data are in (ie 'ABmag')

3.3.4.6 default — optional — The value that processors should assign for this FIELD for ELEM which do not have a reference to this fld id. In the absence of a default, no value will be assigned. The default must match the datatype of the FIELD.

A <SERIES> is composed of a collection of <ELEM> elements which contain a required <TIME> and zero or more field values using the <POS>, <MAG>, <FLUX>, <DVAL>, or <NOTE> elements (represented in the outline as FLD_VAL). The contents of each field value is described by a reference to a <FIELD> element through a fld attribute and can contain uncertainties and a comment. Only data actually recorded needs to be present in a given <ELEM>, so there is no need for missing data flags. It is possible, however, to specify that a given value is a limit measured to that value.
The following is an example of a SimpleTimeseries. Full documentation for SimpleTimeseries can be found at http://dotastro.org/simpletimeseries/.
<SimpleTimeseries>
<DESCRIPTION>Light curve in two filters (in [mag]) of supernova 1992bg</DESCRIPTION> <SPACETIMESYS>
<WhereWhenRef WhereWhenID="whereWhen"/>
<!-- matches ID in WhereWhen element -->
<TimeDefaults>
<WIDTH unit="second">100.0</WIDTH>
<!-- default integration time -->
</TimeDefaults>
</SPACETIMESYS>
<BAND ucd="instr.filter;em.opt.I" bandid="I" description="Johnson-Cousins I-band">I</BAND> <BAND ucd="instr.filter;em.opt.V" bandid="V">V</BAND> <FIELD fld="imag" bandid="I" ucd="phot.mag;em.opt.I" datatype="float" unit="mag">I-band photometry</FIELD> <FIELD fld="vmag" bandid="V" ucd="phot.mag;em.opt.V" datatype="float" unit="mag">V-band photometry</FIELD> <SERIES>
<ELEM row='1'>
<TIME><T>2448919.8</T></TIME> <!-- In jd, specified in time frame --> <MAG fld="imag"><VAL>17.535</VAL><ERR>0.03</ERR></MAG> <MAG
fld="vmag"><VAL>17.327</VAL><ERR>0.03</ERR></MAG></ELEM> <ELEM row='1.5'>

<TIME><T>2448920.72</T></TIME>
<MAG fld="vmag"><VAL>17.37</VAL><ERR>0.036</ERR></MAG></ELEM> <ELEM row='2'> <TIME><T>2448922.82</T></TIME>
<MAG fld="imag"><VAL>17.697</VAL><ERR>0.032</ERR></MAG>
<MAG fld="vmag"><VAL>17.424</VAL></MAG></ELEM>

<ELEM row='2.5'>
<TIME><T>2448923.87</T></TIME>
<MAG fld="vmag"><VAL>17.43</VAL><ERR>0.032</ERR></MAG></ELEM> </SERIES>
</SimpleTimeseries>
3.4 <WhereWhen> — Space-Time Coordinates
A VOEvent packet will typically include information about where in the sky and when in time an event was detected, and from what location, along with spatial and temporal coordinate systems and errors. If either the spatial or temporal locators are absent, it is to be assumed that the information is either unknown or irrelevant. VOEvent v2.0 uses the syntax of the IVOA Space-Time Coordinate (STC) specification version 1.30 or later; the <WhereWhen> element may reference an STC [18] <ObsDataLocation> element to provide a sky location and time for the event. VOEvent publishers should construct expressions that concisely provide all information that is scientifically significant to the event, and no more than that. See §4.1 for an example of usage.

STC expressions are used to locate the physical phenomena associated with a VOEvent alert in both time and space as described below. The <ObsDataLocation> element is a combination of information describing the location of an observation in the sky along with information describing the location of the observatory from which that observation was made. Both the sky and the observatory are in constant motion, and STC inextricably relates spatial and temporal information.
<WhereWhen> <ObsDataLocation> <ObservatoryLocation/>
<ObservationLocation/> </ObsDataLocation> </WhereWhen>
3.4.1 ObservationLocation
The <ObservationLocation> should contain a link to a coordinate system, <AstroCoordSystem>, as well as the actual coordinates, <AstroCoords>, containing a reference back to the coordinate system specification. For example:

<ObservationLocation>
<AstroCoordSystem id=" UTC-FK5-GEO" />
<AstroCoords coord_system_id=" UTC-FK5-GEO">
<Time unit="s">
<TimeInstant>
<ISOTime>2004-07-15T08:23:56</ISOTime> </TimeInstant> <Error>2</Error>
</Time>
<Position2D unit="deg">
<Value2>
<C1>148.88821</C1>
<C2>69.06529</C2>
</Value2>
<Error2Radius>0.03</Error2Radius>
</Position2D>
</AstroCoords>
</ObservationLocation>
Specifying errors is optional but recommended for both time and space components.
The <AstroCoords> element has a coord_system_id attribute and the <AstroCoordSystem> has a id attribute. The value of both of these should be identical, and represent the space-time coordinate system that will be used for the event position and time.

A coord_system_id and id are built from a time part, a space part, and a "center" specification, concatenated in that order and separated by hyphens. Astronomical coordinate systems are extremely varied, but all VOEvent subscribers should be prepared to handle coordinates expressed as combinations of these basic defaults:

• The time part can be UTC (Coordinated Universal Time [27]), TT (Terrestrial Time, currently 65.184 seconds ahead of UTC), or TDB (Barycentric Dynamical Time).
• The space part can be equatorial coordinates (right ascension and declination) expressed in either the ICRS or FK5 coordinate systems.
• The center specification can be TOPO (i.e., the location of the observatory), GEO (geocentric coordinates), or BARY (relative to the barycenter of the solar system).
• It is assumed that the center reference position (origin) is the same for both space and time coordinates. That means, for instance, that BARY should only be paired with TDB (and vice-versa). See the STC specification [18] for further discussion. The list of <AstroCoordSystem> defaults that VOEvent brokers and clients may be called upon to understand is:
• TT-ICRS-TOPO
• UTC-ICRS-TOPO
• TT-FK5-TOPO
• UTC-FK5-TOPO
• TT-ICRS-GEO
• UTC-ICRS-GEO
• TT-FK5-GEO
• UTC-FK5-GEO
• TDB-ICRS-BARY
• TDB-FK5-BARY

The STC specification, in particular <ObsDataLocation> and its contained elements, allows more exotic coordinate systems (for example, describing planetary surfaces). Further description of how VOEvent packets might be constructed to convey such information to subscribers is outside the scope of this document. As with other elements of an alert packet, subscribers must be prepared to understand coordinates expressing the science and experimental design pertinent to the particular classes of sky transients that are of interest.

In short, subscribers are responsible for choosing what VOEvent packets and thus coord_system_id values they will accept. Further, subscribers may choose not to distinguish between coordinate systems that are only subtly different for their purposes — for instance between ICRS or FK5, or between TOPO or GEO. As software determines whether a packet's coord_system_id describes a supported coordinate system, the question is also what accuracy is required and what coordinate transformations may be implicitly or explicitly performed to that level of accuracy.

A similar question faces the authors of VOEvent packets, who must make a judicious choice between the available coordinate system options to meet the expected scientific needs of consumers of those packets. If a detailed or high accuracy coordinate system selection is not needed, UTC -ICRS-TOPO would be a good choice as an interoperability standard.
3.4.2 ObservatoryLocation
The <ObservatoryLocation> element is used to express the location from which the observation being described was made. It is a required element for expressing topocentric coordinate systems. An instance of <ObservatoryLocation> may take two forms. In the first, an observatory location may be taken from a library, for example:

<ObservatoryLocation id=" Palomar" />
The name of the id attribute is in red italics, indicating a specific registered observatory, other examples being: Keck, KPNO, JCMT, MMTO, VLA, etc. , or it may indicate one of the following generic observatory locations:
• GEOSURFACE - any location on the surface of the earth
• GEOLEO - any location in Low Earth Orbit (altitude<700 km)
• GEOGSO - any location within Geostationary orbit altitude
• GEONBH - any location within 50,000 km of the geocenter
• GEOLUN - any location within the Moon's orbit

For example, a packet might contain the following <ObservatoryLocation> to indicate that the coordinates expressed in the <WhereWhen> element are located with an accuracy comprising the Earth's surface:
<ObservatoryLocation id=" GEOSURFACE" />
VOEvent Brokers are designed to comprise a high reliability, low latency, network. These qualities can be used, as with mirroring the STC schema, to provide robust access for VOEvent Subscribers by serving the library of observatory information.

The second option for <ObservatoryLocation> is that an observatory can be located by specifying the actual coordinate values of longitude, latitude and altitude on the surface of the Earth. Note the use of a coordinate system for the surface of the Earth (UTC-GEOD-TOPO) is natural for an observatory location, whereas coordinate systems in the previous section are for astronomical events.

<ObservatoryLocation id="KPNO">
<AstroCoordSystem id=" UTC-GEOD-TOPO" />
<AstroCoords coord_system_id=" UTC-GEOD-TOPO"> <Position3D> <Value3>
<C1 pos_unit="deg">248.4056</C1>
<C2 pos_unit="deg">31.9586</C2>
<C3 pos_unit="m">2158</C3>
</Value3>
</Position3D>
</AstroCoords>
</ObservatoryLocation>
3.4.3 Parsing the WhereWhen Element
When parsing a VOEvent packet, the following pseudocode may be of use to provide the time, the right ascension and the declination, if the author used ICRS spatial coordinates and UTC time.
Let x =/voe:VOEvent/WhereWhen/ObsDataLocation/
ObservationLocation/AstroCoords
If x[@coord_system_id=‘UTC-ICRS-TOPO’] then
Let Time = x/Time/TimeInstant/ISOTime
Let RA = x/Position2D/Value2/C1
Let Dec = x/Position2D/Value2/C2

The coordinate system is first checked to verify that it is set to a specific value(s), UTC-ICRS-TOPO. In practice, a subscriber may not care about the difference between ICRS and FK5 (of the order of 0.01") or between TOPO and GEO (in terms of timing, this is of the order of 25 ms for ground-based and lowearth-orbit observatories). Software may be written to simply accept anything that contains ICRS or FK5, TOPO or GEO.

3.4.4 Solar Events
The following coordinate systems are recognized for solar event data:

• UTC-HPC-TOPO - Cartesian helio-projective coordinates (solar disk)
• UTC-HPR-TOPO - Polar helio-projective coordinates (coronal events)
• UTC-HGS-TOPO - Stonyhurst heliographic coordinates
• UTC-HGC-TOPO - Carrington heliographic coordinates

What this means is that these coordinate combinations will be supported in the library and that, hence, use of VOEvent by the solar research community is supported. It does not imply, of course, that all VOEvent participants are expected to recognize and handle these solar coordinates - nor, for that matter, that solar subscribers be able to handle equatorial coordinates.
3.4.5 Events Observed from Spacecraft
Transient event alerts resulting from observations made on distant spacecraft may reference coordinates that require correction for ground-based follow-up. The precise definition of "distant" will depend on the objects observed, the instrumentation and the science program. For remote objects such as gammaray bursts or supernovae, it is likely that spatial coordinates measured from spacecraft in Earth orbit will be immediately useful — indeed, the error box of the reported coordinates may be much larger than than the pointing accuracy of the follow-up telescope. On the other hand, the field of view of the instrument on that telescope may be many times larger than the error box. Subscribers must always balance such concerns — this is just one facet of matching "scientific impedance" between discovery and follow-up observations.

Even if the spatial targeting coordinates require no correction, the light travel time may be quite significant between a spacecraft and any follow-up telescopes on the Earth. Subscribers may need to adjust wavefront arrival times to suit.

Authors of such events may choose to handle reporting the location of the spacecraft in different ways. First, they may simply construct the complex <ObservatoryLocation> element that correctly represents the rapidly moving location of an orbiting observatory. Further discussion of this topic is outside the scope of the present document, see the STC specification [18]. Of course, any subscribers to such an event stream would have to understand such an <ObservatoryLocation> in detail and be able to calculate appropriate time-varying adjustments to the coordinates in support of their particular science program.

Alternately, an author of event alert packets resulting from spacecraft observations might simply choose to correct their observations themselves into geocentric or barycentric coordinates. Finally, for spacecraft in Earth orbit, authors might choose to report an <ObservatoryLocation> such as GEOLUN, indicating a rough position precise to the width of the Moon's orbit. These two options might be combined by both making a geocentric correction — for instance, to simplify the handling of timing information — with the reporting of a GEOLEO location, for example.

3.5 <How> — Instrument Configuration
The <How> element supplies instrument specific information. A VOEvent describes events in the sky, not events in the focal plane of a telescope. Only specialized classes of event will benefit from providing detailed information about instrumental or experimental design. A <How> contains zero or more <Reference> elements (see §3.9) and <Description> elements, that together characterize the instrument(s) that produced the observation(s) that resulted in issuing the VOEvent packet. A URI pointing to a previous VOEvent asserts that an identical instrumental configuration was used:
<How> <Description> The Echelle spectrograph </Description> <Reference uri="http://nsa.noao.edu/kp012345.rtml" type="rtml" /> </How>
3.6 <Why> — Initial Scientific Assessment
<Why> seeks to capture the emerging concept of the nature of the astronomical objects and processes that generated the observations noted in the <What> element. Natural language words and phrases are used to express the hypothesized astrophysics, pending a standard VO ontology or formal UCD-like vocabulary of astronomical concepts (see [19] and [20], for example). The <Why> element has two optional attributes, importance and expires, providing ratings of the relative noteworthiness and urgency of each VOEvent, respectively. Subscribers should consider the importance and expires ratings from a particular publisher in combination with other VOEvent metadata in interpreting an alert for their purposes. The publishers of each category of event are encouraged to develop a self-consistent rating scheme for these values.

3.6.1 importance — The importance provides a rating of the noteworthiness of the VOEvent, expressed as a floating point number bounded between 0.0 and 1.0 (inclusive). The meaning of importance is unspecified other than that larger values are considered of generally greater importance.

3.6.2 expires — The expires attribute provides a rating of the urgency or time-criticality of the VOEvent, expressed as an ISO-8601 [29] representation of some date and time in the future. The meaning of expires is application dependent but will often represent the date and time after which a follow-up observation might be belated.

A <Why> element contains one or more <Concept> and <Name> sub-elements. These may be used to assert concepts that specify a scientific classification of the nature of the event, or rather to attach the name of some specific astronomical object or feature. These may be organized using the <Inference> element, which permits expressing the nature of the relation of the contained elements to the event in question as well as an estimate of its likelihood via its probability attribute.
3.6.3 <Concept> — classification
The value of a <Concept> element uses a controlled vocabulary to express the hypothesized astrophysics. This standard VO ontology or formal UCD-like vocabulary of astronomical concepts vocabulary is still in development (see [19] and [20], for example).
3.6.4<Description> — natural language
This element provides a natural language description of the concept, either as a replaement for the <Concept> element, or as an elaboration.
3.6.5<Name> — identification
<Name> provides the name of a specific astronomical object. It is preferred, but not required, to use standard astronomical nomenclature, e.g., as recognized by NED [23] or SIMBAD [24].
3.6.6<Inference> — hypotheses inferred
An <Inference> may be used to group or associate one or more <Name> or <Concept> elements. <Inference> has two optional attributes, probability and relation:
3.6.6.1 probability — The probability attribute is an estimate of the likelihood of the <Inference> accurately describing the event in question. It is expressed as a floating point number bounded between
0.0 and 1.0 (inclusive). In particular, note that a probability of 0.0 can be used to eliminate <Inferences> from further consideration.

3.6.6.2 relation — The relation attribute is a natural language string that expresses the degree of connection between the <Inference> and the event described by the packet. Typical values might be "associated" - a SN is associated with a particular galaxy - or "identified" - a SN is identified as corresponding to a particular precursor star. Such a one-to-one identification is considered to be the default relation in the absence of the attribute.

This example asserts that the creator of the packet is 100% certain that the event being described is equivalent to Tycho's Star, which has been identified as a Type Ia Supernova, and is "associated" with the SN remnant known as 3C 10. This was an important discovery, but is no longer a very urgent one:

<Why importance="1.0" expires="1574-05-11T12:00:00"> <Inference probability="1.0"> <Name>Tycho's Stella Nova</Name> <Concept>stars.supernova.Ia</Concept> </Inference>
<Inference probability="1.0" relation="associated"> <Name>3C 10</Name> <Concept>ISM.SNRemnant</Concept>
<Description>Supernova remnant</Description>
</Inference>
</Why>

3.7 <Citations> — Follow-up Observations
A VOEvent packet without a <Citations> element can be assumed to be asserting information about a new celestial discovery. Citations reference previous events to do one of three things:

• follow-up an event alert with more observations or other relevant data, or
• supersede a prior event with better, equivalent information, or
• issue a complete retraction of a previous event.

Citations form the edges of a directed graph whose nodes are VOEvent instances; they allow merging multiple events into a single related thread, a way to collect multi-sourced data into a coherent whole. Projects that implement VOEvent handling may decide to implement for different conditions of citation
-- perhaps assuming a sparse or structured citation graph, or a small or large arity for each event. We recommend that the meaning of 'citation' should be a strong one: if a reader is to understand an event, then the reader should understand the cited event. This is the relation between a comment and a post, between one observation of a transient and another relevant observation. However, not everything should be cited: while the papers of Einstein may be relevant, they need not be always cited! A different notion is that of association of sources: as in a radio source being near an optical source. If an author wishes to express this notion, the <Inference> element can carry this information (see section 3.6.6).

A <Citations> element contains one or more <EventIVORN> elements. The standard does not attempt to enforce references to be logically consistent; this is the responsibility of publishers and subscribers.
3.7.1 <EventIVORN> — Cited event and relationship
An <EventIVORN> element contains the IVORN of a previously published VOEvent packet. Each <EventIVORN> describes the relationship of the current packet to that previous VOEvent. An <EventIVORN> element has one required attribute:
3.7.1.1 cite — The cite attribute accepts three possible enumerated values, "followup", "supersedes" or "retraction". There is no default value.
The value of the cite attribute modifies the VOEvent semantics. In contrast to a VOEvent announcing a discovery (i.e., a packet with no citations), a VOEvent may be explicitly a "followup", citing one or more earlier packets — meaning that the described real or virtual observation was done as a response to those cited packet(s). In this case, the supplied information is assumed to be a new, independent measurement.

The cite may be "supersedes", which can be used to express a variety of possible event contingencies. A prior VOEvent may be superseded, for example, if reprocessing of the original observation has resulted in different values for quantities expressed by <What> or <WhereWhen> or if the investigators have formed a new <Why> regarding the event. On the other hand, if a later observation has simply resulted in different measurements to report, this would typically be issued as a "followup".

When a citation is made with a "supersede" or "retraction" attribute, it is assumed that *all* of the previous information is superseded: and so the cited event is no longer needed. If there is datum X and datum Y in the original, and X gets improved calibration, then Y must also be copied to the new event, or else its value will no longer be seen.

A "supersedes" cite can also be used to merge two or more earlier VOEvent threads that are later determined to be related in some fashion. The VOEvents to be merged are indicated with separate <EventIVORN> elements. The proper interpretation of such a merger would depend on a VOEvent client having received all intervening packets from all relevant threads. Finally, "supersedes" can be used in combination with a "followup" to divide a single VOEvent into two or more new threads. First, follow-up the event in one packet and then supersede the original event, rather than the follow-up, in a second packet (with a second identifier that can start a second thread).

The "retraction" cite indicates that the initial discovery event is being completely retracted for some reason. The publisher of a retraction may be other than the publisher of the original VOEvent — subscribers are free to interpret such a situation as they see fit.
Splitting, merging or retracting a VOEvent should typically be accompanied by a <Description> element discussing why such actions are being taken.
An attempt is made to retract the sighting of Tycho's supernova:
<Citations>
<EventIVORN cite="retraction">
ivo://uraniborg.hven#572-11-11/0001</EventIVORN>
<Description>Oops!</Description>
</Citations>
3.8 <Description> — Human Oriented Content
A <Description> may be included within any element or sub-element of a VOEvent to add human readable content. <Descriptions> may NOT contain <References>. Users may wish to embellish Description sections with HTML tags such as images and URL links, and these should not be seen by the XML parser, as they will cause the VOEvent XML to be invalid against the schema. However, it is possible to use the CDATA mechanism of XML to quote text at length, so this may be used for complicated tagged Descriptions. See the example in section 4 for usage.
3.9 <Reference> — External Content
A <Reference> may be included in any element or sub-element of a VOEvent packet to describe an association with external content via a Uniform Resource Identifier [16]. In addition to the locator for the content, there is also a locator for the meaning of the content, which is another URI, specified by the 'type' attribute. This can be as simple as a format (eg "fits", "html"), or something like this:
type="http://me.edu/myScheme#EccentricityInclinationCovariance"
where the link leads to a machine-readable description of the meaning of the content. In addition, a local name may be attached to the global resource, so that meaning can be used as a namespace in other elements. A <Reference> must be expressed as an empty element, with attributes only.

It is anticipated that VOEvent packets will often include <References> to such content as finding charts, cut-out images, light-curves, object catalogs, SQL queries and instrumental configurations — to list only a few. This content will be expressed in various graphics and image formats such as FITS, as VOTables [22], as RTML [15] documents, as MIME-typed web content in general, or as native VOEvents.

The 'type' of a Reference may also be of higher semantic content, it can be a link to an explanation of how to read the content and what it means; an explanation that may be targetted to either a human or a machine. In this way the semantic web can be connected to the VOEventNet.

A <Reference> element has three attributes:
3.9.1 uri — The identifier of another document. Should follow URI syntax.
3.9.2 type — The type of the document. Should follow URI syntax. The default value is "url".
3.9.3 name — A short, optional name to be used in descriptive text.

A <Reference> used to provide general purpose ancillary data with well-defined meaning. Here a fits image is presented (h.fits), and also a link to the data model that is needed for a machine to understand the meaning.
<Group type="MyFilterWithImage">
<Reference uri="http://.../data/h.fits"
type="http://.../data-models/#h-filter-image/> </Group>
An example of the indirection of a VOEvent packet using <Reference>
<VOEvent ivorn="ivo://raptor.lanl#235649409/sn2005k" role="observation" version="2.0"> <Reference uri="http://raptor.lanl.gov/documents/event233.xml" type="voevent:"> </VOEvent>
4: VOEvent Example
This imaginary event is a brightness measurement of a past supernova from the RAPTOR [11] telescope. The <What> section reports a <Description> and <Reference> followed by a <Param> about seeing and a <Group> with the actual report: the magnitude is 19.5, measured 278.02 days after the reference time, which is reported in the <Wherewhen> section. There is a <Table> of measured distances to the presumed host galaxy, and a <SimpleTimeSeries> of previous magnitude measurements, also referred to the reference time. The packet represents a follow-up observation of an earlier event, as defined in the <Citations> element.

<?xml version="1.0" encoding="UTF-8"?>
<voe:VOEvent ivorn="ivo://raptor.lanl/VOEvent#235649409" role="observation" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:voe="http://www.ivoa.net/xml/VOEvent/v2.0"
xmlns:sts="http://dotastro.org/simpletimeseries"
xsi:schemaLocation="http://www.ivoa.net/xml/VOEvent/v2.0 VOEvent-v2.0_sts.xsd"> xsi:schemaLocation="http://www.ivoa.net/xml/VOEvent/v2.0 VOEvent-v2.0_sts.xsd"> 15T14:34:16</Date>
</Who>
<What>
<Description>An imaginary event report about SN 2009lw.</Description>
<Reference uri="http://raptor.lanl.gov/data/lightcurves/235649409"/> <Param name="seeing" value="2" unit="arcsec" ucd="instr.obsty.site.seeing"/>
<Group name="magnitude">
<Description>The time is days since the refernce time in the WhereWhen section</Description> <Param name="time" value="278.02" unit="day" ucd="time.epoch" />
<Param name="mag" value="19.5" unit="mag" ucd="phot.mag"/> <Param name="magerr" value="0.14" unit="mag" ucd="phot.mag; stat.err"/>
</Group>
<Table>
<Description>Individually Referenced Moduli and Distances for NGC 0931 from NED</Description> <Field name="(m-M)" unit="mag" ucd="phot.mag.distMod"/> <Field name="err(m-M)" unit="mag" ucd="phot.mag.distMod;stat.err"/>
<Field name="D" unit="Mpc" ucd="pos.distance"/> <Field name="REFCODE" ucd="meta.bib.bibcode"/> <Data>
<TR><TD>33.16</TD><TD>0.38</TD><TD>42.9</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.32</TD><TD>0.38</TD><TD>46.1</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.51</TD><TD>0.48</TD><TD>50.4</TD><TD>2009ApJS..182..474S</TD></TR>
<TR><TD>33.55</TD><TD>0.38</TD><TD>51.3</TD><TD>1997ApJS..109..333W</TD></TR> <TR><TD>33.71</TD><TD>0.43</TD><TD>55.2</TD><TD>2009ApJS..182..474S</TD></TR> <TR><TD>34.01</TD><TD>0.80</TD><TD>63.3</TD><TD>1997ApJS..109..333W</TD></TR> </Data> </Table> <SimpleTimeseries xmlns="http://dotastro.org/simpletimeseries"> <DESCRIPTION> Images of Supernova 2009lw by various groups in the month following discovery. Times are in days since the refererence epoch in the WhereWhen. </DESCRIPTION> <SPACETIMESYS>
<WhereWhenRef WhereWhenID="Raptor-2455100"/> </SPACETIMESYS> <!-- this is a brief description of the bandpass --> <BAND ucd="instr.filter;em.opt" bandid="clear" description="Unfiltered">Clear/Unfiltered Optical</BAND> <BAND ucd="instr.filter;em.opt" bandid="R" description="Cousins R-Band">R Band</BAND> <BAND ucd="instr.filter;em.opt" bandid="V" description="Cousins V-Band">V Band</BAND> <BAND ucd="instr.filter;em.opt" bandid="unknown" description="Unknown optical band">Unknown Optical</BAND> <FIELD bandid="R" fld="rMag" ucd="opt;phot;R" datatype="float" unit="mag">R-band photometry</FIELD>
<FIELD bandid="V" fld="vMag" ucd="opt;phot;V" datatype="float" unit="mag">V-band photometry</FIELD>
<FIELD bandid="clear" fld="clearMag" ucd="opt;phot;clear" datatype="float" unit="mag">Clear photometry</FIELD> <FIELD bandid="unknown" fld="unknownMag" ucd="opt;phot;unknown" datatype="float" unit="mag">Unknown photometry</FIELD> <SERIES> <ELEM row='1' uri="http://astro.berkeley.edu/~bait/2009/sn2009-n0931.gif"> <TIME><T>59.5</T></TIME>
<MAG fld="unknownMag"><VAL>18.4</VAL></MAG></ELEM> <ELEM row='2' uri="http://www.rochesterastronomy.org/sn2009/n931s1.jpg">
<TIME><T>60.75</T></TIME>
<MAG fld="clearMag"><VAL>18.6</VAL></MAG></ELEM> <ELEM row='3' uri="http://astrosurf.com/nazaret/images/supernovas/2009lwGMUL_CR20091202.jpg"> <TIME><T>68.462</T></TIME>
<MAG fld="rMag"> <VAL>18.26</VAL></MAG></ELEM> <ELEM row='4' uri="http://perso.wanadoo.es/d-rodrig/SN/SN09/SN2009lw-RZD.jpg">
<TIME><T>70.5</T></TIME></ELEM>
<ELEM row='5' uri="http://www.rochesterastronomy.org/sn2009/n931s2.png"> <TIME><T>72.5</T></TIME></ELEM>
<ELEM row='6' uri="http://www.rochesterastronomy.org/sn2009/n931s3.jpg"> <TIME><T>79.272</T></TIME>
<MAG fld="vMag"> <VAL>18.4</VAL></MAG></ELEM>
<ELEM row='7' uri="http://www.astrosurf.com/matajur1976/ccdsky/ngc931_20100118_lrgb.jpg"> <TIME><T>118.5</T></TIME></ELEM>
</SERIES> </SimpleTimeseries>
</What>
<WhereWhen id="Raptor-2455100">
<ObsDataLocation>
<ObservatoryLocation id="RAPTOR"/>
<ObservationLocation>
<AstroCoordSystem id="UTC-ICRS-TOPO"/>
<AstroCoords coord_system_id="UTC-ICRS-TOPO">
<Time>
<TimeInstant>
<ISOTime>2009-09-25T12:00:00</ISOTime> </TimeInstant>
<Error>0.0</Error>
</Time>
<Position2D unit="deg">
<Value2>
<C1>37.0603169</C1> <!-- RA --> <C2>31.3116578</C2> <!-- Dec --> </Value2>
<Error2Radius>0.03</Error2Radius>
</Position2D>
</AstroCoords>
</ObservationLocation>
</ObsDataLocation>
</WhereWhen>
<How>
<Description>
<![CDATA[This VOEvent packet resulted from observations made with <a
href=http://www.raptor.lanl.gov>Raptor</a> AB at Los Alamos. ]]>
</Description>
</How>
<Citations>
<EventIVORN cite="followup">ivo://raptor.lanl/VOEvent#235649408</EventIVORN> </Citations>
<Why>
<Concept>process.variation.burst;em.opt</Concept> <Description>Looks like a SN</Description>
<Inference relation="associated" probability="0.99"> <Name>NGC0931</Name> </Inference>
</Why>
</voe:VOEvent>

5. References
[1] ATEL: The Astronomer's Telegram
[2] http://www.astronomerstelegram.org
[3] CBAT: Central Bureau for Astronomical Telegrams
[4] http://cfa-www.harvard.edu/iau/cbat.html, or
[5] http://cfa-www.harvard.edu/iau/DiscoveryInfo.html (discovery schema) [6] eSTAR: eScience Telescopes for Astronomical Research
[7] http://www.estar.org.uk
[8] GCN: The Gamma-Ray Burst Coordinates Network
[9] http://gcn.gsfc.nasa.gov
[10] Skyalert: Event publisher and disseminator
[11] http://skyalert.org/
[12] LIGO: Laser Interferometer Gravitational Wave Observatory [13] http://www.ligo.caltech.edu
[14] LSST: Large Synoptic Survey Telescope
[15] http://www.lsst.org
[16] CRTS: Catalina Realtime Transient Survey
[17] http://crts.caltech.edu/
[18] Pan-STARRS: the Panoramic Survey Telescope & Rapid Response System [19] http://pan-starrs.ifa.hawaii.edu/public/index.html
[20] RAPTOR: RAPid Telescopes for Optical Response
[21] http://www.raptor.lanl.gov, and
[22] http://www.thinkingtelescopes.lanl.gov (Thinking Telescopes Project) [23] Swift and Fermi: NASA Gamma-Ray observatories
[24] http://swift.gsfc.nasa.gov/docs/swift/swiftsc.html http://fermi.gsfc.nasa.gov/ [25] RoboNet: RoboNet-1.0
[26] http://www.astro.livjm.ac.uk/RoboNet
[27] ROBOT: A list of robotic telescope projects
[28] http://www.astro.physik.uni-goettingen.de/~hessman/MONET/links.html [29] RTML: Remote Telescope Markup Language
[30] http://www.uni-sw.gwdg.de/~hessman/RTML, or
[31] http://monet.uni-goettingen.de/twiki/bin/view/RTML (twiki)
[32] ID: IVOA Identifiers
[33] http://www.ivoa.net/Documents/latest/IDs.html
[34] RM: Resource Metadata for the Virtual Observatory
[35] http://www.ivoa.net/Documents/latest/RM.html
[36] STC: Space-Time Coordinates Metadata for the Virtual Observatory [37] http://www.ivoa.net/Documents/latest/STC.html
[38] UCD: Unified Content Descriptor
[39] http://www.ivoa.net/Documents/latest/UCD.html, or
[40] http://cdsweb.u-strasbg.fr/UCD
[41] VOConcepts: a proposed UCD for Astronomical Objects, Events, and Processes [42] http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors [43] VOEvent: Sky Event Reporting Metadata
[44] http://www.ivoa.net/Documents/latest/VOEvent.html
[45] http://www.ivoa.net/xml/VOEvent/VOEvent-v2.0.xsd (schema)
[46] http://www.ivoa.net/Documents/latest/VOEvent_transport.html (transport) [47] http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOEvent (working group) [48] VOTable: Format Definition
[49] http://www.ivoa.net/Documents/latest/VOT.html
[50] NED: NASA/IPAC Extragalactic Database
[51] http://nedwww.ipac.caltech.edu/
[52] SIMBAD: Set of Identifications, Measurements and Bibliography for Astronomical Data [53] http://simbad.u-strasbg.fr/Simbad
[54] TYCHO: De Stella Nova
[55] http://www.texts.dnlb.dk/DeNovaStella/Index.html (in Danish)
[56] UNITS: Standards for Astronomical Catalogues: Units
[57] http://vizier.u-strasbg.fr/doc/catstd-3.2.htx
[58] UTC: the future of Coordinated Universal Time
[59] http://www.ucolick.org/~sla/leapsecs
[60] Checksum: FITS Checksum Proposal
[61] http://heasarc.gsfc.nasa.gov/docs/heasarc/fits/checksum23may02
[62] ISO 8601: standard representation of dates and times
[63] http://www.cl.cam.ac.uk/~mgk25/iso-time.html
[64] XML: Extensible Markup Language
[65] http://xml.coverpages.org/xml.html, and
[66] http://xml.coverpages.org/schemas.html, or
[67] http://www.ucc.ie/xml (FAQ)
[68] Attribute-Value Normalization
[69] http://www.w3.org/TR/REC-xml/#AVNormalize
[70] SimpleTimeseries: A Standard method for sharing time-series data
[71] http://www.dotastro.org/simpletimeseries/
[72] PTF: Palomar Transient Factory
[73] http://www.astro.caltech.edu/ptf/

International Virtual Observatory Alliance
4.2 Simple Event Access Protocol (SEAP) Version 0.5
IVOA WG Internal Draft 2009 September 30
Author(s):
Matthew Graham (Editor)
Alasdair Allan
Rob Seaman
Roy Williams
Elizabeth Auden
Bob Denny
Arnold Rots
Phil Warner

The Simple Event Access Protocol (SEAP) will provide a mechanism to query services containing VOEvent packets. SEAP will be analogous to the Simple Time-range Access Protocol (STAP) and Simple Image Access Protocol (SIAP). Currently, VOEvents are provided through a number of transport mechanisms - Jabber/XMPP, RSS, TCPV - by organizations such as VOEventNet and eStar. In addition, six VOEvent streams have been wrapped in a STAP web service for a searchable event interface prototyped with VOExplorer. The SEAP protocol should be able to incorporate astronomical, solar and STP events. Use cases include both users searching for event data through VOExplorer as well as telescope operators searching for followup events.
1. Introduction
The Simple Event Access Protocol (SEAP) provides a simple parameter-based mechanism for querying VOEvents that have been persisted in some fashion.
2. Service Interface Requirements
A service implementation that is compliant with this standard must meet the following requirements:
The service must respond to a HTTP GET (IETF RFC 2616) request represented by a URL having two parts:
• A base URL of the form:
• http://<server-address>/<path>?[<extra-GET-arg>&[...]]
• where <server-address> and <path> are URI-compliant components indicating the domain and local location path where the service is deployed. The <server-address> may end with one or more locally supported URL arguments, <extra-GET-arg>; these arguments are not recognized parts of the SEAP and thus are treated opaquely by clients of the service as part of the base URL.
• Note that when it contains extra GET arguments, the base URL ends in an ampersand, &; if there are no extra arguments then it ends in a question mark, ?.
• Examples:
• http://nvo.caltech.edu/SEAP?
• http://nvo.noao.edu/SEAP?stream=Essence&
• Every query to a given SEAP service uses the same base URL.
• Constraints expressed as a list of ampersand-delimited GET arguments of the form:
• <name> = <value>
• where <name> is a parameter name specified by this specification (see Section 3) and <value> is its value. The constraints represent the query parameters which can vary for each successive query. The order of the name-parameter pairs is not significant.
• The baseURL and constraint list are concatenated to form the query.
• There may be other parameters in the query, but this document does not specify their meaning or usage. If a query includes an optional parameter, either one specified by this document or not, that is not supported by the service implementation, the service must ignore that parameter.

A query following this syntax represents a request for information on events matching the specified query constraints.
The service must respond with an XML document in the VOTable format , which represents a table of
astronomical events that match the specified constraints.

The base MIME-type of the HTTP response should be text/xml. The more specific form text/xml;content-=x-votable may optionally be used. The MIME-type, text/xml;votable shall not be considered legal as it is not compliant with the MIME-type standard. The XML content of the response must be compliant with the VOTable schema version 1.1. [VOTable].
The VOTable MUST comply with these conditions:
• There must be a single RESOURCE in the VOTable, and that contains a single TABLE.
• The TABLE must have FIELDs where the following UCD [UCD] values have been set. There must be one FIELD with each of these UCDs:
• Exactly one FIELD must have ucd="meta.id" with an array character type (fixed or variable length) representing an ID string for that record of the table. This identifier may not be repeated in the table and it could be used to retrieve that same record again from that same table
• Exactly one FIELD must have ucd="meta.ref.ivorn" with an array character type (fixed or variable length) representing the IVORN of the VOEvent described by that record of the table.
• Exactly one FIELD must have ucd="meta.ref.url;meta.main" with an array character type (fixed or variable length) representing the location from which the full VOEvent packet corresponding to that record of the table may be retrieved.
• There may be other FIELDs in the table. Their specification should include a description, datatype, and UCD.
The service may respond with a XML document in the KML format...
The service must respond with a stubbed version of the VOTable in the case of error. This must happen if any of the values of the parameters cannot be parsed to their proper datatypes, or if the numbers are out of range (seap:pos.ra = 361.0, for example). The service may also make an error return if the search region (given by seap:pos.* parameters) is larger than the maxQueryRegionSize of the SEAP Capability (see Section 4).

In the case of error, the service MUST respond with a VOTable that contains a single PARAM element or a single INFO element with name="Error", where the corresponding value attribute should contain some explanation of the nature of the error. If an INFO element is used, it must appear as a direct child of one of the following elements:

• the root VOTABLE element (which is preferred by this document), or
• the RESOURCE element
If a PARAM element is used, it must appear as a direct child of one of the following elements:
• the RESOURCE element, or
• a DEFINITION element below the root VOTABLE element
Other conditions may NOT be considered erroneous, for example, if a search is in the Southern hemisphere and the VOEvent stream coverage is in the Northern hemisphere. This type of query is different from an error return; it should return a VOTable as described above, with metadata, but no data records. In particular, any search regions of zero size should not return an error condition. This is because an application may be more interested in the metadata than the data, and send a flxied query simply to discover the fields delivered by the service.
3 Data Model
This section describes the constraints (query parameter + value) allowed by this specification for use in service queries. A query parameter is expressed as a UTYPE [REF] with a scheme of: seap.
3.1 Response metadata
UTYPE Data Type Possible values Default value Status seap:response.content string ivorn, full, custom,kml ivorn MUST
3.1.1 seap:response.content
This represents the supported content of the VOTable as the return data format. A fully compliant SEAP service must support this utype as a parameter.
The data type for this utype is a string.
Possible return values associated with this utype are:

• ivorn (default) - a VOTable of IVORNs for each VOEvent packet matching the query
• full - a VOTable of VOEvent packets
• custom - a VOTable of selected VOEvent metadata
• kml - a KML document of VOEvent metadata
3.2 Constraint (Query) metadata UTYPE Data Type Possible valuesDefault Statusvalue
seap:ivorn IVOA IVORN compliant (string) MUST seap:stream IVOA IVORN compliant (string) MUST seap:authorivorn string MUST seap:contactname string MUST seap:how string MUST seap:pos float/pos range MUST
seap:size float/pos range MUST
seap:time ISO-8601 compliant (string)/time range
MUST
seap:param param range MUST seap:concept string MUST seap:citation.cited boolean true, false false MUST
seap:citation.role string
• seap:ivorn:
This represents the IVORN [1] of the VOEvent.
• A fully compliant SEAP service must support this utype as a parameter. The data type for this utype
is a string which conforms to the IVOA identifier specification [3].
• seap:stream:
This represents the IVORN [1] of the stream (publisher) from which the VOEvent packet
originated. It is expected that the stream publisher has previously registered with the VO registry [2].
A fully compliant SEAP service must support this utype as a parameter. The data type for this utype
is a string which conforms to the IVOA identifier specification [3].
• seap:authorivorn.
This represents the IVORN [1] of the author of the VOEvent, i.e. the entity who is responsible for
its scientific content. It is expected that the author has previously registered with the VO registry [2].
A fully compliant SEAP service must support this utype as a parameter. The data type for this utype
is a string which conforms to the IVOA identifier specification [3].
• seap:contactname:
This represents the contact name, or subset thereof, of the person who created the VOEvent packet.
A fully complaint SEAP service must support this utype as a parameter. The data type for this utype
is a string.
• seap:how:
This represents how the observation that resulted in a VOEvent publication was performed. The
VOEvent specification [4] presents the element as the instrument configuration. A fully compliant
service must support this utype as a parameter and must include all sub-elements of in the query
execution.
• seap:pos:
This represents the position of the region to be queried. This utype is used in conjunction with the
following utype:
• seap:size
A fully compliant SEAP service must support this utype as a parameter. The data type for this utype
is a pos range.
• seap:size
This represents the size of the (circular) region to be queried. This utype is used in conjunction with
the following utypes:
• seap:pos
A fully compliant SEAP service must support this utype as a parameter. The data type of this utype is
a float or range of floats.
• seap:time
This represents the date for searching. A fully compliant SEAP service must support this utype as a
parameter. The data type of this utype is an ISO-8601 DateTime.
• seap:param
This represents a Param element specified in the VOEvent packet. If a param has been specified in followup, supersedes,MUSTretraction
the query and no events contain that param, no events will be returned. A fully compliant SEAP service must support this utype as one or more parameters. The data type of this utype is a param
range.
• seap:concept
This represents the concept element as specified in the VOEvent packet. A concept is represented by
a utype from a standard vocabulary [5]. A fully compliant SEAP service must support this utype as
one or more parameters. The data type for this utype is a string.
• seap:citation.cited
This represents whether the VOEvent packet has been cited. A fully compliant SEAP service must
support this utype as one or more parameters. The data type for this utype is a Boolean. The default
value is false.
• seap:citation.role
This represents the role of any citation. A fully compliant SEAP service must support this utype as
one or more parameters. The data type for this utype is a string. Possible values are: followup,
supersedes, retraction
4 Constraints
This section defines the syntax for specifying constraints in service queries. This is consistent with that of the IVOA Parameterized Query Language [PQL].
4.1 Parameter rules
• 4.1.1 Single-valued parameters
• Parameters that are single-valued are assumed to have a constant value. Any reserved characters (see

Sec. 4.1.9) must be URL-encoded if they are used.
• 4.1.2 Multi-valued parameters
Parameters that are multi-valued (e.g. positions) use a comma (",") as the separator between successive values. Embedded white space is not permitted. Individual values that are empty should be represented by the empty string and two successive commas indicate an empty item, as does a leading or trailing comma.
• 4.1.3 Range-valued parameters
Parameters that specify a range of values use a forward slash ("/") as the separator between range limits. The range is defined as inclusive, i.e. including the range limits. If a third value is specified, it is a step size for traversing the indicated range. Note that if the parameter does not support a step size then this value will be ignored. An open range may be specified by omitting either range limit. For example: seap:pos = 120/240,/-45 will search for events with a RA value between 120 and 240 inclusive and with a Dec value less than or equal to -45
• 4.1.4 Qualifiers
Parameters that support a qualifier, e.g. time, use a semicolon (";") as the separator between parameter values and a qualifier string. Multiple qualifiers can be expressed through successive semicolons.
• 4.1.5 Missing or null-valued parameters
If a parameter is not included in a query, its value is unset; no value has been specified. If a parameter is given a null value, e.g. "seap:pos =", the parameter value has been set and the value is the null string. Whether or not a null parameter value is significant is dependent on the individual parameter. If only the parameter name is given, e.g. "seap:pos", it is the same as if the parameter was not specified and the parameter value is unset.
• 4.1.6 Case of parameters
Parameter names shall not be case sensitive but parameter values shall.
• 4.1.7 Order and cardinality of parameters
Parameters may be specified in any order in a service query. Duplicated parameters may be ignored or a particular value chosen for the parameter.
• 4.1.8 Boolean values
Boolean values may be specified as either "0" or "false" and "1" or "true" respectively. The absence of an optional value is equivalent to logical false.
• 4.1.9 Reserved characters
The following characters are defined as reserved, both as a result of the URL specification (RFC 2396 [REF]) and this specification. When they appear in the value of parameter, they should be URL-encoded.

Character Reserved usage
? Separator indicating the start of the URL query string
& Separator indicating parameters in the query string
= Separator indicating name and value of a parameter
# Separator indicating start of a URL fragment
, / ; Separator between individual values in ranges or lists
4.2 Positional range
A range in a positional constraint is specified as:
seap:pos = minval1/maxval1,minval2/maxval2;coordsys
where minval1/2 are (optional) lower limits for their respective coordinates, maxval1/2 are (optional) upper limits for their respective coordinates and coordsys is an (optional) keyword indicating the coordinate system to use.

The default coordinate system is ICRS: RA and Dec in decimal degrees. Alternate values for the coordinate system should be taken from Table 3 in the STC specification [REF]. It is an error if the specified coordinate system is not supported by the service.
For example:
• seap:pos = 120/240, will search for events with a RA value between 120 and 240 inclusive
• seap:pos = ,/-45 will search for events with a Dec value less than or equal to -45
• seap:pos = ,60/ will search for events with a Dec values greater than or equal to 60
• seap:pos = 200/250,50/60;GALACTIC will search for events with 200 < l < 250 and 50 < b < 60 in galactic coordinates
4.3 Temporal range
A range in a temporal constraint is specified as:
seap:time = minval/maxval;keyword
where minval is an (optional) lower limit in ISO-8601 format, maxval is an (optional) upper limit in ISO8601 format, and keyword specifies the DateTime reference as detailed in the VOEvent standard [VOEVent]. Possible values for keyword are:
• isotime - this denotes the time that the observation reported in the VOEvent packet was made
• pubtime - this denotes the time that the VOEvent packet was created/published
The default value for keyword is isotime and if no value is specified then this value is assumed. For example:
• seap:time = "2009-02-01T00:00:00Z"/"2009-02-02T00:00:00Z" will search for events where the observation was made between 1st and 2nd February 2009
• seap:time = /"2009-03-15T00:00:00:Z";"pubtimeq" will search for events created/published up until 15th March 2009
4.4 Parametric range
A range in a parametric constraint is specified as:
seap:param = "name",minval/maxval;"unit"
where name is the (optional) parameter name, minval is an (optional) lower limit and maxval is an (optional) upper limit to the parameter value, and unit is an (optional) keyword specifying the parameter unit. For example:

• seap:param = "mag1",18/20 will search for events with a parameter named "mag1" that has a value between 18 and 20
• seap:param = "mag1",;"Jy" will search for events with a parameter named "mag1" whose value is expressed in units of "Jy"

Note that in the VOEvent data model, Params are often arranged in (named) Groups. The name used in a parametric can therefore be qualified by the Group name (as a prefix and using a period ('.') as a separator between the Group name and the Param name) if the search is for a specific parameter within a specific Group. For example:
• seap.param = "Ast1.mag1" will look for a Param called "mag1" within a group called "Ast1". Matching just on a Group name can be achieved by omitting any Param name but keeping the separator, thus:
• seap.param = Ast1.
If there is no separator then it is assumed that this is a search on a Param name (default behaviour).

VOSpace 1.1 does not support the specification of data types on parameters. It is therefore left to the individual SEAP service to interpret parametric ranges; however, the general assumption should be that when numerical characters are used in a range expression, e.g. 18/20, then a numerical search range is intended and the query should be parsed as such. For example:

• seap.param = "mag1",19/ will search for events where the numerical value of the parameter named "mag1" is greater than 19 rather than those where the value of the parameter named "mag1" come after "19" in an alphanumeric ordering. If "mag1" does not take numerical values then this should return an error.

Data type information is available for parameters in the registry record for a particular VOEvent stream and so a SEAP service could always retrieve the relevant record and check whether a given query is syntactically correct, e.g. whether the specified parameter takes numerical values if a numerical range is present.

4.5 Equivalent expressions
The following expressions are considered to be semantically equivalent:

• seap:param = "name"
• seap:param = "name",
• seap:param = "name",;

4.6 Constraint negation
The logical NOT of a constraint is specified by preceding the parameter value with a "!". For example:
• seap:pos = !120/140, will search for all events outside the region 120 ≤ RA ≤ 140
• seap.param = "mag1",!18/20 will search for events with a parameter called "mag1" whose value is

outside the range 18 ≤ mag1 ≤ 20
• seap:param = "mag1",;!"Jy" will search for events with a parameter called "mag1" whose units are not
"Jy".
• seap:param = !"mag1" will search for events with a parameter not called "mag1"
When seap:size is being used, the negation must be appear on it - any negations on seap.pos are invalid.
4.7 Multiple constraints
Multiple constraints are applied in conjunction (logical AND). For example:
• seap:pos=120/140,10/15&seap.param="mag1" will search for all events within the range 120 ≤ RA ≤
140 and 10 ≤ Dec ≤ 15 and which has a parameter called "mag1"
If the same constraint is expressed more than once, the service may choose to respond to one of them or to treat the query as syntactically erroneous.
5 Registering SEAP services
A service supporting a SEAP interface should be registered in an IVOA registry as a Service or subresource (e.g. VOEventServer) with a capability of type "voe:SimpleEventAccess" [VOEventService].
5.1 The SimpleEventAccess Resource Extension
An abstract complex type is defined so that the value of thestandardID attribute can be set to an appropriate fixed URI representing the service standard. For the<voe:SimpleEventAccess> capability, this
is theSEAPCapRestriction complex type:
<xs:complexType name="SEAPCapRestriction" abstract="true"> <xs:complexContent> <xs:restriction base="vr:Capability"> <xs:sequence> <xs:element
name="validationLevel" type="vr:Validation" minOccurs="0"
maxOccurs="unbounded" /> <xs:element name="description" type="xs:token" minOccurs="0" /> <xs:element name="interface" type="vr:Interface" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute
name="standardID" type="vr:IdentifierURI" fixed="ivo://ivoa.net/std/VOEventSEAP" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType>
voe:SEAPCapRestriction Metadata Elements
Element Definition validationLevel RM Name: ResourceValidationLevel Value type: integer with requiredvalidatedBy attribute taking an ID: vr:Validation (see definition for listing of allowed values.) Semantic Meaning:
An evaluation via a numeric grade that indicates the quality of the capability description and whether its implementation is functionally with applicable standards.
Occurrences: optional; multiple occurrences allowed
description Value type: string:xs:token Semantic Meaning:
A human-readable description of what this capability provides as part of the overall service
voe:SEAPCapRestriction Metadata Elements Element Definition
Occurrences: optional
interface Value type: composite:vr:Interface Semantic a description of how to call the service to access this capability Meaning:
Occurrences: optional
The fixed URI representing the Simple Event Access Protocol (SEAP) standard is defined by the standardID attribute:
voe:SEAPCapRestriction Attribute Attribute
standardIDRM Name: Value type: Semantic Meaning: Use:
Definition
Service.StandardURI
URI: ivo://ivoa.net/std/VOEventSEAP
the IVOA ID for the VOEvent SEAP standard.
Required
TheSimpleEventAccess capability is then defined as an extension of the abstract <SEAPCapRestriction>: voe:SimpleEventAccess Type Schema Definition
<xs:complexType name="SimpleEventAccess">
<xs:complexContent>
<xs:extension base="voe:SEAPCapRestriction"> <xs:sequence>
<xs:element name="maxQueryRegionSize" type="voe:RegionSize" minOccurs="0">
<xs:element name="maxRecords" type="xs:int" minOccurs="0"> <xs:element name="testQuery" type="voe:Query" minOccurs="0"> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The capability defines three elements relating to characteristics of the SEAP:<maxQueryRegionSize>, <maxRecords> and <testQuery>:
voe:SimpleEventAccess Extension Metadata Elements
Element Definition
maxQueryRegionSize Value type: composite:voe:RegionSize Semantic The maximum query region size in spatial and temporal extent. Meaning:
Occurrences: optional
voe:SimpleEventAccess Extension Metadata Elements Element Definition maxRecords Value type: integer: xs:int Semantic Meaning:
The largest number of records that a query will return. A value of zero or less indicates that there is no explicit limit.
Occurrences: optional
testQuery Value type: composite:voe:Query Semantic Meaning:
A query that will result in at least one matched record that can be used to test the service.
Occurrences: optional
The<maxQueryRegionSize> is of the complex type<voe:RegionSize>:
voe:RegionSize Type Schema Definition
<xs:complexType name="RegionSize"> <xs:sequence> <xs:element name="long" type="xs:float"> <xs:element name="lat" type="xs:float"> <xs:element name="time" type="xs:float"> </xs:sequence> </xs:complexType>
The elements of this specify the maximum extent along the longitudinal (R.A.), latitudinal (Dec) and temporal axes that the service can handle:

voe:RegionSize Metadata Elements
Element Definition long
Value type: float:xs:float Semantic The maximum size in the longitudinal (R.A) direction Meaning:
Occurrences: mandatory
lat
Value type: float:xs:float Semantic The maximum size in the latitudinal (Dec) direction Meaning:
Occurrences: mandatory
time
Value type: float:xs:float Semantic The maximum range along the temporal axis
voe:RegionSize Metadata Elements Element Definition
Occurrences: mandatory
The <testQuery> child of the<SimpleImageAccess> capability is of the complex type <voe:Query>:
voe:Query Type Schema Definition

<xs:complexType name="Query"> <xs:annotation> <xs:documentation>A query to be sent to the service</xs:documentation> <xs:documentation>Details to be filled in once the SEAP has been fully defined.</xs:documentation> </xs:annotation> </xs:complexType> The elements of this specify the parameters that constitute a query to the service:
voe:Query Metadata Elements
Element Definition seap:authorivorn
Value type: URI:vr:IdentifierURI Semantic The IVORN for the author of the VOEvent Meaning:
Occurrences: optional
seap:contactName
Value type: string:xs:token Semantic The contact name associated with a VOEvent Meaning:
Occurrences: optional
seap:how
Value type: URI:xs:anyURI Semantic Meaning:
The URI of the document describing the instrumental setup used to produce the VOEvent
Occurrences: optional
seap:pos
Value type: string:xs:token Semantic The positional bounds of the search Meaning:
Occurrences: optional
seap:size
Value type: string:xs:token Semantic The size of the search region Meaning:
Occurrences: optional
seap:time
Value type: string:xs:token Semantic The temporal bounds of the search Meaning:
Occurrences: optional
seap:param
Value type: string:xs:token Semantic The parametric constraints of the search Meaning:
Occurrences: optional
seap:concept
Value type: string:xs:token Semantic The conceptual nature of a VOEvent Meaning:
Occurrences: optional
seap:citation.cited
Value type: boolean:xs:boolean Semantic Indicates whether a VOEvent has been cited or not Meaning:
Occurrences: optional
seap:citation.role
Value type: string:xs:token Semantic The role of a VOEvent
Allowed followupvalues:
superseded retraction
Occurrences: optional
5.2 Example
This illustrates how a service with a SEAP capability might appear in the registry:
This illustrates how a service with a SEAP capability might appear in the registry:
09-23T00:00:00Z" updated="2008-09-23T00:00:00Z" status="active"

xsi:schemaLocation="http://www.ivoa.net/xml/VOEventService/v0.1 VOEventService.xsd" xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0"
xmlns:voe="http://www.ivoa.net/xml/VOEventService/v0.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <validationLevel
validatedBy="ivo://nvo.caltech/registry">1</validationLevel> <title>VOEventNet VOEvent Server</title> <shortName>voeventnet</shortName>
<identifier>ivo://nvo.caltech/voeventnet</identifier> <curation>
<publisher ivo-id="ivo://nvo.caltech/CACR">Center for Advanced Computing Research</publisher> <creator><name>Roy Williams</name></creator>
<date role="creation">2006-04-01</date>
<contact><name>Andrew Drake</name> <email>ajd@cacr.caltech.edu</email></contact> </curation>
<content>
<subject>VOEvent</subject>
<subject>transient astronomy</subject> <description>VOEventNet gathers streams of astronomical alerts and reports in a common format, and acts as a clearinghouse, so that both people and robotic systems can get the alerts quickly enough to respond with follow-up observations.</description>
<referenceURL>http://www.voeventnet.org</referenceURL> <type>Other</type> <contentLevel>University</contentLevel> <contentLevel>Amateur</contentLevel> <contentLevel>Research</contentLevel>
</content> <voeventStream>ivo://nvo.caltech.voeventnet/catot</voeventStream> <capability xsi:type="voe:SimpleEventAccess" standardID="ivo://ivoa.net/std/VOEventSEAP"> <interface xsi:type="vs:ParamHTTP" role="std">
<accessURL use="base">http://nvo.cattech.edu/voeventnet/seap</accessURL> </interface> <maxQueryRegionSize>
<maxRecords>10000</maxRecords>
<testQuery>
<seap:pos>120,15<seap:pos>
<seap:size>0.5<seap:size>
<testQuery>
</capability>
... </Resource>
References
[1] [PQL] IVOA Table Access Protocol Parameterized Query Language, Version 0.2, IVOA Internal Working Draft 2009 May 20

International Virtual Observatory Alliance
4.3 A Proposal for Digital Signatures in VOEvent Messages
IVOA Note 2008 May 14
Author(s):
Robert B. Denny
The advantages of digitally signing VOEvent messages are well understood. This paper presents a proposal for accomplishing this with standards-based technology and having no impact on VOEvent message formats, minimal programming requirements, and an adaptable trust model.
1. Introduction
At the Hot Wiring the Transient Universe workshop in July, 2008 (attended by the author) there was some discussion about security. S. L. Allen gave a talk VOEvent Authentication via XML digital signatures (since published as a paper, see References). Attendees generally agreed that there is a need to at least authenticate VOEvent messages in order to verify their source and integrity. Encryption was not a significant consideration. Allen’s paper covers the issues and technology well. Advantages of using signed VOEvent messages include assurances that

• no changes have occurred (or been made) to the message,
• the message truly came from the originator, and thus
• no 3rd party can forge a message from the originator.

Since the workshop, discussions have continued, focusing mainly on enveloped versus detached signatures, canonicalization, aggregation of VOEvent messages to reduce traffic, and whether to sign individual messages in an aggregate. Also being discussed is the usefulness of nested signatures, with some being applied during transit of the message.

Throughout those discussions, it has been assumed that XML Signature and the X.509 (PKIX) certificate and trust model would be used. The author feels that, for completeness, at least one alternate technology and method should be presented and considered. A prototype implementation has been made (to validate practicality and determine speed), and is presented herein.
2. Objectives and Characteristics
This paper presents a proposal for authenticating VOEvent messages with PGP digital signatures. The proposed system has the following objectives and characteristics:
• Separate: no changes to the VOEvent XML schema, no canonicalization issues, etc.
• Elective: no impact on existing VOEvent message parsers
• Flexible: simple yet adaptable trust model, centralized hierarchy possible but not required
• Simple: minimal programming requirements (in contrast to XML Signature)
• Fast Start : keys and certificates can be generated in minutes, coding of sign/verify in days or less
• Cross-platform: can be implemented on virtually any operating system
• Strong: well known algorithms, sufficient strength for message value
• Standards: Internet standards based
3. PGP Trust in VOEvent
The PGP trust model lends itself well to the VOEvent environment. The following narrative assumes the reader understands the PGP “web of trust” model and digital signature concepts. PGP (like X.509) uses a key-pair system, in which the secret key is possessed only by the originator and the public key is freely distributed to recipients. In short, a message is signed using the originator's secret key and validated using the originator's public key. In order to prevent forgeries, the originator signs his public key as well, before distributing it. Recipients must be certain that they have a genuine copy of the originator's (signed) public key. Without that certainty ("trust"), they can't be certain that signatures were truly applied by the originator. In PGP, trust is added via countersignature.

Herein, the term key will refer to a signed public key (also known as a certificate). With PGP, there is no need for a hierarchy of trust with a master “root”. Instead, trust is distributed. In this proposal, given that the presence of a digital signature in a VOEvent message has no impact on receivers, a VOEvent message originator and a VOEvent message receiver pair can decide to use signed messages without action on anyone else’s part.
3.1 Initial Low Volume Scenario
The originator first provides his (signed public) key to the receiver such that the receiver is 100% certain that it is authentic[1]. The receiver then countersigns the originator’s key with his secret key, indicating that he trusts the key enough to use it for signature validation. At this point, both parties have everything they need to use signed VOEvent messages.

The originator starts sending his VOEvents with digital signatures. Again, this has no impact on other receivers. However, the receiver with whom he established a relationship can immediately begin to validate the incoming messages using the originator’s key. As time goes on, other receivers may become interested in validating the signatures on the originator’s messages. The originator can provide his key to anyone. The receiver just has to be 100% certain that it is authentic[1]. Anyone can validate the signatures on incoming messages. There is no need for involving a Certification Authority to whom the originator must prove his identity and pay money.

3.2 Scaling with Growth
While this simple scheme should suffice at least in the short term, it does not scale. If the number of interested receivers gets “too large” the burden on originators to prove that their key is genuine could become too great. In this case, PGP’s “web of trust” feature is useful. Originators could collect signatures on their key by having others countersign them and return the key with the new signature. As the originator’s key is passed around and signed, it eventually gets a “large” number of countersignatures on it.

At this point, other parties can decide that one or more of the parties that countersigned the originator’s key are “trusted introducers”, and that the presence of their countersignature(s) on the originator’s key is/are enough to prove that it is genuine. This relieves the originator from having to provide first-hand proof of key authenticity to everyone.

3.3 Identity in Public Key
The public key contains its owner’s identification. Normally this is constructed from a name, an email address, and a comment. In this application, it is suggested that the name be set to the author IVORN and the other fields left blank. Thus the key is identified by the IVORN of the originator as registered with IVOA. This permits the receiver to match up the identification of the key with the AuthorIVORN element (if present) in the VOEvent message itself, a further assurance of authenticity. See the example in Figure 3.

[1] Face to face contact is best, but the key can also be validated with some out-of-band check of the key fingerprint. For example, the originator’s key could be downloaded from a web site, and then a phone call or email message could cross-check its fingerprint.
4. Format of Signed and Validated VOEvent Messages
In order to avoid impacting either the VOEvent schema or existing parsers, both the digital signature and validation results are enclosed in XML comments. Thus, parsers that do not support signed messages are unaware of the signature’s presence. Including validation results in a validated received message provides a record of validation in event messages stored by the receiver.

The digital signature header is placed between the xml declaration and the rootVOEvent tag, as shown in Figure 1. The hyphens in the signature header are converted to equal signs, as XML comments cannot contain more than one hyphen in a row. These must be converted back to hyphens before validating by the receiver. The digital signature block is placed following the closing/VOEvent tag, as shown in Figure 2.
5. Prototype System
In the prototype system, PGP signing and validation services are provided by the open-source Gnu Privacy Guard (GnuPG) tool. This tool is freely available on virtually all OS platforms and it is actively maintained. Two versions are available. Version 2 (the latest) is much larger and more complex since it contains support for both OpenPGP and S.MIME (and thus X.509 PKI). Version 1.4.8 is sufficient for this application, and it is mature. Thus, GnuPG version 1.4.8 is recommended for this application, and was used in the demonstration system. A 1024 bit DSS (signing) key-pair was generated with a bogus IVORN as the key ID, and then used for signing messages. The Perl scripts, public/secret keys, and other bits used for the prototype are available at http://solo.dc3.com/~rdenny/VoDigiSig.zip. The passphrase for the secret key is "test".

Perl scripts are used to sign and validate VOEvent messages. Perl seems to be widely used for VOEvent processing and it lends itself to this sort of work, so it is a natural choice. However, virtually any language could have been used. Figure 4 shows the script for signing a message and Figure 5 shows the script for validating a signed message. The validation script leaves the validation results in the message for future reference as shown in Figure 3. It can be seen that the required code for signing and validating is minimal.

5.1 Validation of Integrity
In order to verify that no changes are made to the VOEvent message, including spurious line endings, the following pipeline was used to sign then validate a VOEvent message:
send.pl < orig.xml | recv.pl > rcvd.xml
The results of the test are shown as a diff listing fororig.xml versusrcvd.xml in Figure 6. It can be seen that there are no differences apart from the addition of the signature validation results in XML comments inrcvd.xml. Note the IVORN is displayed, as a result of using it as the signing key ID (as suggested in section 3.3).
5.2 Signing and Validating Rates
Scaling of this system is clearly affected by the time it takes to sign or validate a VOEvent message. For the demonstration system, the Perl benchmark package was used to test the rates of signing and validation. 100 cycles each of signing and validation were run and the timing results were encouraging. Output was redirected to the null device, so if it were to go to a real file, the time would increase. It took an average of 260 milliseconds to sign a message, and 190 milliseconds to validate. This was done on Windows XP running on a 2GHz Pentium CPU. Windows has a slower process activation time than most Unix-derivatives, so this was a worst-case test. In any case, this simple test shows that a modest system can sign or validate hundreds of thousands of message per day.
6. Conclusions and Discussion Points
It has been shown that there is a simple alternative to XML Signature (and related canonicalization issues) which provides the protection and authentication afforded by digitally signed VOEvent messages. However, the method presented diverges from the views of the IVOA and uses a cryptographic system that is considered by some to be somehow substandard. Is PGP (as described by RFC 4880 and implemented in GnuPG) truly substandard? If the use of PGP becomes a roadblock, should we consider some PKIX/X.509 method that still embeds the signature info in XML comments, outside of the VOEvent document? Most of the important advantages would remain.

The VOEvent Working Group has several major tasks ahead, and digital signatures is one of them. If XML Signature is used, digital signatures become canonicalization issues, creating one larger task out of important? Or is something akin to the system presented here "good enough"?

The science environment places a high value on breadth of thought and rigor. The engineering environment places a high value on finding solutions that are "good enough" and have the lowest risk/reward quotient. These two views during a design process can at times be orthogonal. But in the end, the design must be implemented. It is always better to have at least one complete working production implementation in hand before adopting a standard. In a sense, this is engineering rigor. Lessons are always learned when fielding systems based on a proposed standard. Often, the first prototype is (or should be!) thrown away. Design-and-decree standards have a history of high failure rates. Are we headed down that path with XML Signature? Will we end up with an ad-hoc "practical subset "? Is that even possible? Will we have done a large amount of work and made compromise decisions in order to accommodate XML Signature in VOEvent 2.0? Should we even set ourselves up for that?

Finally, can we afford to wait for (maybe) years before having the benefits of signed VOEvent messages? Or is it essential that we not make a misstep by adopting something rashly just to get going much sooner? If the reader takes anything away from this Note, the author hopes it will be the desire to find technical problems in this proposal and raise them on the VOEvent mailing list.
cross-correlated with VOEvent 2.0 and
two separable ones. Is XML Signature that
References
[1] Alfarez, A-R, 1996, The PGP Trust Model (PDF)
[2] http://netresearch.ics.uci.edu/Previous_research_projects/agentos/related/security/abdul-rahmanpgp-trust.pdf
[3] Allen, S.L., 2007, VOEvent Authentication via XML digital signature, (informal, given at HTU Workshop)
[4] http://www.cacr.caltech.edu/hotwired/program/presentations/xmldsig.pdf
[5] Allen, S.L., 2008, VOEvent Authentication via XML digital signature, Astron. Nach., 329, 298-300 (2008).
[6] http://www3.interscience.wiley.com/cgi-bin/fulltext/117927641/PDFSTART [7] Ashley, J.M. et al., 1999, The Gnu Privacy Handbook (PDF)
[8] http://gnupg.org/gph/en/manual.pdf
[9] Callas, J. et al., 2007, OpenPGP Message Format (RFC 4880) (PDF) [10] http://tools.ietf.org/html/rfc4880
[11] Eastlake, D. et al., XML Signature Syntax and Processing (RFC 3275) [12] http://www.ietf.org/rfc/rfc3275.txt
[13] Howes, E., 2004, GnuPG Command Reference (unofficial, but excellent) http://www.spywarewarrior.com/uiuc/gpg/gpg-com-0.htm
[14] Koch, W. et al., Gnu Privacy Guard
[15] http://gnupg.org/
[16] Zimmerman, P., 2001, Why OpenPGP’s PKI is better than an X.509 PKI (editorial) http://www.openpgp.org/technical/whybetter.shtml