The LIGO Open Data program has made an example of a data release associated with a detection of gravitational waves, available at
http://www.ligo.org/science/GW100916/. This is MOCK DATA, NOT A REAL DETECTION. However, when the advanced detectors are installed (~2015), LIGO hopes for several (real, astrophysical) detections each year, giving a new window to the extreme physics of neutron stars and black holes. Detection of the afterglow from these violent events will vastly improve the scientific impact of the LIGO detection, and these triggers will be released rapidly to the community to encourage follow-up observation.

However, the detectors will not have good sky localization, but rather probability maps (examples here and here) that are several degrees in size. Thus the task of the follow-up observer will be difficult, to pick out the correct, probably faint, optical transient that may last only seconds, or may take many days to come to maximum magnitude.

Perhaps the easiest part of the data to appreciate is the audio version. With a decent pair of earbuds or headphones, the “whoop” or “chirp” that can be heard around 17 seconds into the recording. Try sitting in the dark and listening to this, and imagine that this tiny sound is from an incredible explosion at incredible distance.

Last week was the Workshop on Gaia Science Alerts in Cambridge, England. The goal of the Gaia mission, once it is running in 2014,  is to make the largest, most precise three-dimensional map of our Galaxy by surveying a billion stars, as well as detecting millions of supernovae, cataclysmic variables, microlensing, and other transient celestial events and minor planets. However, the crucial follow-up observations are to be carried out by ‘the community’, meaning medium-sized telescopes that take the public Gaia alerts, make the observations, and return the results back to the mission. It became clear during the workshop that there should be a program to organize and motivate this community. There will be real-time communication of the alerts in standard protocols, for people or robots to read, registration and characterization of the available resources, and different kinds of participation depending on enthusiasm and capability. The science will be maximized by engaging the community at all levels: large, medium, and small telescopes, as well as those who have no telescope at all but can engage in ‘citizen science’ activities. How to achieve this needs to be decided, but it seems clear that the time for action is now.

This army of community follow-up resources will also be a critical part of other large astronomy projects; not only Gaia, but also discovering the afterglow of gravitational wave events from LIGO, and following up the stream of transients expected from the LSST project. Watch this space for details on how to become engaged. You and your telescope can join this valiant effort, for it is not a sin to covet the honour of a great discovery.

A new version of the Skyalert software is available (version 1.3), which is now also running on skyalert.org. Please report your bugs and problems to ! Some of the new features are:

• Compliance to the VOEvent 2.0 standard, now finalizing in the IVOA, including the ability to put small tables of data with each event.
• A validation service for VOEvent 2.0 packets.
• A web protocol for authoring events, in addition to the local and Jabber/XMPP protocols.
• Ability to resolve an event from its identifier (IVORN) to a simple, computer-readable format (JSON).
• A new pdf document Guide to Skyalert that explains browsing, alerts, authoring, developing, and administration.

There will be presentations on Skyalert at:

• Gaia Science Alerts workshop, Cambridge UK, July 11
• New Horizons, Oxford UK, Sept 19-23

The Recommendation of VOEvent 2.0 draws ever closer, after successfully running the gauntlet at the spring meeting of the International Virtual Observatory Alliance. Our thoughts now move beyond the standard to the exciting science that can be done now that interoperability is solved: we can have multiple authors and multiple software contributing to the rapidly-evolving picture of an astronomical transient, with machines fusing that data to make rapid, accurate decisions. We will need to think of how VOEvents are authored, forwarded, selected, stored, queried, and mined. In each of these cases, we wish to provide the most appropriate ‘representation’ of the data in the VOEvent. Below are some suggestions for this representation.

We want to keep the semantics of VOEvent as much as possible, so that the same data is available in all the representations as much as reasonable. We can focus on individual events, or extend the representation for the VOEvent aggregates that we have come to call ‘portfolio’. A portfolio is a collection of multi-sourced VOEvent packets whose subject is the same astronomical transient, and they are associated through citation of one by another — the observation is a VOEvent, combined with followups or classification results also formatted as VOEvents. The VOEvent is an observation of something: it is that something that brings multiple events together.

A single VOEvent, is an XML file. This representation carries the most fidelity to the intent of the original author, even though some links may be replaced for caching. A portfolio is a collection of VOEvent files that are mutually connected through citations in a graph, and it can be stored as a zip or tar etc. Querying is through Xpath, Xquery, or XML libraries like lxml or Jax. Custom API can be made made from the VOEvent schema through code binding.

Each event can be thought of as a key-value dictionary, one for each piece of data extracted from the event XML. Some keys are mandated by the VOEvent schema, (eg AuthorName, ISOtime) , and others come from the Group and Param name combinations specific to that stream, with the value an int, float, or string. Internal tables can be handled by allowing the value of such a key to be a vector — the values from the table column. A portfolio can then be a union of these dictionaries, each representing an event; to prevent name collision, each key would also contain the name of the event it comes from. This representation is natural for presentation templates and dictionary expressions: a table column such as e['lightCurve']['Vmag'] can become a python list of numbers. This representation is effective when a single portfolio is to be examined in detail, or annotated, perhaps classification of light curves or analysis of ephemeris. It can also be a table structure, with each row of the table having Stream, Group, Param, and Value, with queries that select on these tables.

Here we are not representing a single astronomical transient but rather astro-informatics, with many transients in a table, searching, selecting, sorting, visualizing, and clustering. The columns of the table come from the stream of which the events are instances. Each VOEvent is translated to a row in the table (internal tables are not shown in this representation). Some columns are defined in the VOEvent standard, such as sky position and time; others are part of the stream defintition (params). We can also represent a collection of similarly structured portfolios; perhaps an event from stream A together with one from stream B, one the observation and the other the classification. For portfolios, there is a choice about joins: we can work with multiple tables, each representing the events from a given stream, and portfolio relationships represented as foreign keys; alternatively, we can fuse all stream tables into one, so that each portfolio is represented by a single record of this super-table. Working in this representation, we use SQL queries that depend on Param and other values from the events.

The American Association of Variable Star Observers (AAVSO) has announced they have joined other astronomical organizations and projects such as Swift and CBAT in publishing their Alert Notices and Special Notices to a dedicated VOEvent stream. You can browse the events in the AAVSO stream.

More information on the AAVSO blog.

Skyalert has been upgraded to handle events that have tables in them, as part of the new VOEvent2 standard, now nearing finalization in the IVOA (International Virtual Observatory Alliance), a standards body. An example of a stream with tables is CSS_NEO, which provides rapid reports of moving objects from the Catalina Sky Survey, one of the most prolific discovery engines of NEOs — the asteroids that may pass dangerously close to Earth. Notices are received by Skyalert by email, then the table of observations parsed out and sent to the Minor Planet Center ephemeris generator, and the results put into an ephemeris table. The resulting event is then available for follow-up observation over the next hours and days. The are other streams that could benefit from the new table structure in VOEvent and Skyalert. There are plans to attach light-curves, so that the recently measured brightness can be evaluated in context, and an automated decision made for immediate follow-up or not.

In the next few years, there will be a possibility for scientific fame and fortune for those with small telescopes: finding the first afterglow of a gravitational wave event. The advanced LIGO and Virgo detectors will be online by 2014, and this exciting new branch of ‘dark astronomy’ opening up. Gravitational wave detections will not be well-localized on the sky, but rather have an extended “skymap” of probability on the sky (see here). A VOEvent table would be well-suited to represent this complex event footprint.

Busy this week with software releases, you can find them at http://lib.skyalert.org. The biggest package is the Skyalert software itself, so you can run your own web-database; it works with Django/Apache and MySQL, and is all made with Python.There is also the VOEventLib, a Python library for reading, building, and modifying VOEvent packets, in collaboration with Dave Kuhlmann. Each of these packages is completely integrated with the VOEvent 2.0 standard, so I hope the IVOA can ratify this standard at their upcoming meeting in Italy.

The Fermi satellite has been getting a lot of gamma-ray flares from the recent huge solar flare on Valentine’s Day. The gamma emission from the flare arrives at the Earth (and the Fermi observatory) within minutes, but the charged particles take a few days to travel the distance. The results of these storms of charged particles are being felt now, with the aurora visible in continental US, disruption of data and power grids, and other effects. Here are some of the Fermi events that indicate Solar Flare origin; notice how the interpretation and its probability change as more data is taken by the observatory.

Take a look at some of these recent solar flare events from Fermi: Feb 17, 16:14,Feb 17, 07:56,Feb 16, 14:23,Feb 16, 01:36,Feb 16, 01:36,Feb 15, 07:58,Feb 15, 03:09,Feb 15, 01:48,Feb 15, 00:36,Feb 14, 19:27,Feb 14, 17:24,Feb 14, 17:32.

There have been some improvements to Skyalert in the last weeks. The NASA Fermi satellite observatory has a gamma-ray burst detector onboard, whose results arre sent immediately to Skyalert; then as further information arrives about the meaning of that detection, updates arrive. In the past, these complex events were simply listed with the overwhelming set of technical data that come with each one. Now those data packets have been given a new overview that better explains the meaning, for example quoting the probability that the satellite detection came from an extragalactic gamma- ray burst, or interpretation as a terrestrial gamma-ray flash, or that the initial event was an instrumental artifact. To see this in action, click on any of the Fermi events on the front page of Skyalert. Those terrestrial gamma flashes are of great interest in themselves, arising from particle acceleration in the lightning of fierce storms on Earth.

The SWIFT satellite is another gamma-ray burst detector: events are automatically generated by the spacecraft as it turns and zooms on the bursts that it finds, taking images and spectra in various wavelengths. These so-called Notices come to Skyalert through the NASA GCN (Gamma-ray Coordinates Network). These are followed in the succeeding days by Circulars, written by astronomers who are observing the position of the burst with optical and radio telescopes, to determine first if there really was an extra-galactic gamma-ray burst (GRB), and if so, to gain a full understanding of the explosion through observation of the afterglow. The Circulars come by a different channel than the Notices, and the naming of the burst is different than iot was for the Notices, and of course they are in natural language (English), which computers understand poorly. The Skyalert team thanks Ashish Mahabal for building the software to make the semantic connection, so that the immediate and automated Notices about a GRB are followed by the interpretation and meaning, expressed as a series of Circulars. To see this, click on any of the SWIFT events on the Skyalert front page.

There has been an upgrade of the Skyalert software and the server OS in the last few weeks, which has caused some interruptions, for which we apologize. We hope that things are back on track again. We hope to bring back the Twitter stream soon.

We should point out that Skyalert is not just a web page of recent astronomical events, but can send immediate emails about events that you have pre-selected. To set up the email, you must first log in, then click on My Alerts and New Alert. Pick the stream from which you would like to select, then make the selection trigger according to the instructions. The simplest criterion is the word “True” which means that all events from that stream are emailed to you.

Two new streams will be coming soon: the CANDELS collaboration supernova alerts, and the IAU Central Bureau for Astronomical Telegrams. Watch this space.

This is about both astronomy and religion: interpretation of the heavenly voice and its meaning. Specifically, who does the interpretation, and what happens if the voice is available without interpretation. While I have plenty of colleagues on the astronomy side, I would appreciate any wisdom or examples from any of the religions that illuminate the argument.

The astronomy is the LIGO project, my new employer, which aims to detect ‘gravitational waves’ from cosmic events on the other side of the Universe. Even with half a billion dollars spent on the detectors, the signals are still very faint: think of the sound of a drop of water falling in a bucket (“boink”) but with a lot of noise: creaks and ploinks and whirring and buzzing sounds from the instrument and environment that are not gravitational waves, but can sound, to an untrained ear, just like them. Often these so-called ‘glitches’ come from known sources such as passing airplanes or seismic activity. So obviously the experts want to avoid mistakes and be very very careful to decide which might be a real signal (sometimes flippantly called the Voice of God) and differentiate it from the much more common instrumental artifacts. My job at LIGO is to help with the ‘open data’ effort: most publicly funded science experiments these days have a provision that all the data should become freely available to anyone, generally after a year or so from data-taking, to allow those who made the experiment to extract the scientific payload, and thus be rewarded for their work. This delay also gives time to calibrate the data and clean it of artifacts. So LIGO data will be open, hopefully with enough “interpretation” to point out the glitches and steer people away from mistaken conclusions.

Now for the religious side of this post, where my knowledge is less. Here too, there is a sacred document (Bible, Koran, etc) which consists of the Voice of God, as written by people. Even though the original writer of the sacred document may be inspired, and thus free of confusing human influence, there may be later people who have selected, paraphrased, or translated the original voice, and thus introduced ‘noise’. With LIGO, the signal from Nature is mixed with instrumental effects as loud or louder than the real signal; for the religious text, the signal from God is mixed with human frailty before we can read it. Sometimes it is difficult to achieve ‘open data’ for religious text, just as with scientific data, because of the risk of it being misinterpreted. In Judaisim, the Talmud is a collection of interpretation of the original data (the Bible); the Catholic and Protestant Christians differ over the need for a priest to interpret the Bible, or whether ‘open data’ is sufficient, meaning each believer can make up their own mind. I understand that the letters of Paul in the Christian Bible are particularly difficult to interpret correctly without deep knowledge and study. Among those who hold a given document sacred, sects and schisms are formed over interpretation.

Therefore I am interested in finding those parts of religious understanding that resemble the LIGO experience. Where in a sacred text is a false signal that looks like the truth? For what passages is it particularly easy for a naive reader to be led astray? What is the justification for requiring an interpreter between text and believer? What is the worst that can happen if the text is ‘open data’: does history have human suffering caused by naive reading of the text?