International
Virtual
Observatory
Alliance
|
|
International Virtual Observatory Alliance |
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.
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], Pan-STARRS [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.
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.
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:
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:
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:
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.
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.
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.
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.
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).
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> | Identification of scientifically responsibel Author | |
| <What> | Event Characterization modeled by the Author | |
| <WhereWhen> | Space-Time Coordinates of the event | |
| <How> | Instrument Configuration | |
| <Why> | Initial Scientific Assessment | |
| <Citations> | Follow-up Observations | |
| <Description> | Human Oriented Content | |
| <Reference> | 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.
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:
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.
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:
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>
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.
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:
<Who>
<AuthorIVORN>ivo://uraniborg.hven/Tycho</AuthorIVORN>
<Date>1573-05-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.
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.
<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" />
<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:
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.
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".
<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>
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>:
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.493</VAL><ERR>0.032</ERR></MAG></ELEM>
</SERIES>
</SimpleTimeseries>
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>
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:
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:
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.
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:
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>
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 low-earth-orbit observatories). Software may be written to simply accept anything that contains ICRS or FK5, TOPO or GEO.
The following coordinate systems are recognized for solar event data:
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.
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 gamma-ray 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.
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>
<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.
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).
This element provides a natural language description of the concept, either as a replaement for the <Concept> element, or as an elaboration.
<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].
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>
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:
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.
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:
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>
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.
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#Eccentricity_Inclination_Covariance"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>
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">
<Who>
<AuthorIVORN>ivo://raptor.lanl/organization</AuthorIVORN>
<Date>2005-04-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>