VOEvent defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving the discovery of a transient celestial event, with the implication that timely follow-up is being requested. 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 required 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 the next decade 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, RoboNet-1.0  and eStar in the United Kingdom, and VOEventNet in the USA. 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 Palomar-QUEST , Pan-STARRS  and LSST , satellites like Swift , and more singular experiments like LIGO . RAPTOR  at the Los Alamos National Laboratory is another such project that is already operating with prototype support for VOEvent. In short, the community has demonstrated that robotic telescopes  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)  and the Astronomer's Telegram (ATEL) , but these systems use predominantly natural-language text to describe each event, and send every accepted event to all subscribers. The GRB Coordinates Network (GCN)  reports one of the most exciting 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 ("listeners") 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  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  or the Remote Telescope Markup Language (RTML) .
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. 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.
It is expected that VOEvent packets will be used as the basis of an information infrastructure of databases that will hold VOEvent packets keyed by their identifiers. These databases may harvest packets from each other, so that a packet may be held in more than one database. In addition to the harvesting protocol, there will be three ways for clients to interact with the database servers:
The subscription mechanism is expected to be the chief way in which users will be informed of new events. A subscription to an event publisher is a filter on the stream of events: whenever certain criteria are met for an incoming event, the subscriber is notified by a transport mechanism that the subscriber has chosen. The filter may involve the curation part of the event (e.g., "all events published by the Swift spacecraft"), the location ("anything in M31"), or they may involve the detailed metadata of the event itself ("whenever the cosmic ray energy is greater than 3 TeV").
The Repository will be queryable in various ways: to resolve packet identifiers to the metadata for which they stand, and to support a query mechanism and the corresponding standard service interface. The query mechanism may be written in terms of a standard query language (eg Xquery or ADQL), or it may allow certain standard queries.
The discovery of a new celestial phenomenon may be Nobel-prize material, and it is hoped that a VOEvent packet will be part of the initial announcement. The astronomical community generally prefers open systems therefore VOEvent packets do not convey intellectual property (IP) restrictions on the data they contain. Organizations can work within a closed system of clients and servers if privacy is required. This solution is simpler and more effective than demanding that all servers understand a schema for IP restriction.
VOEvent benefits from the IVOA identifier syntax developed for the VO registry. These identifiers will also be called IVORNs (International Virtual Observatory Resource Names); they are required to begin with "ivo://", and are meant to stand in for a particular metadata packet, obtainable from a VO registry. 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. The 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, as defined and discussed in . These take the general form "ivo://authorityID/resourceKey#localID", and are references to metadata packets that may be found at a VO registry or VOEvent repository.
The IVOA registry infrastructure can resolved identifiers to metadata packets. There are several types of metadata schema that the registry can hold, to describe different kinds of things. For the purposes of VOEvent, the principal schemas 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: first use any VO registry to find out which VOEvent repository has the relevant record, then send a query to that repository asking for the record itself. The part of the IVORN before the # symbol points to the publisher of the event; the whole IVORN (that includes the localID) points to the event. Thus VOEvent identifiers are overloaded; they contain a publisher identifier, then the # sign, then the local reference.
This is a key point in understanding how VOEvent identifiers work: The Event identifier contains also the Publisher identifier. Here is an example:
can be looked up in any VO registry, returning a description of the publisher, such as who runs it, how many events it has published, how to subscribe, etc. However, for resolving the identifier, we want a repository, so a different registry query would be used: "Find repositories that keep the events published by this publisher"
points to a specific VOEvent (number 60601) that was published by the Caltech publisher. However, this identifier will not resolve from the global VO registry -- only from a repository that has the Caltech-published events.
The scheme outlined here is analogous to ISBN identifiers for books (International Standard Book Number). An ISBN example is 1-55860-253-4: the first part (1-55860) identifies the publisher, and the second part (253) is a title identifier that is local to that publisher (and there is a check digit at the end).
The VOEvent Working Group has not yet standardized either the metadata describing a repository to the registry, not has it decided the nature of the standard service that allows repositories to be queried.
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 in other IVOA documents relating to VOEvent.
A VOEvent packet provides a general purpose mechanism for representing transient astronomical events. However, not all VO data are suitable for expression using VOEvent. The VOEvent schema  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 RTML to represent instrument configurations. 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:
Alternately, a <VOEvent> element may be completely empty except for a single <Reference> element used to express an indirection of the packet. The ivorn of such an indirected VOEvent packet should be set to the that of the referenced packet (see §3.9).
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 . 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 "1.1" 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  might start:
<VOEvent ivorn="ivo://uraniborg.hven#1572-11-11/0001" role="observation" version="1.1" 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 .
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, emai, and phonl. 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>firstname.lastname@example.org</contactEmail> <contactPhone>+1 800 555 1212</contactPhone> </Author>
As an alternative to quoting Author information over and over, this inofrmation 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 . 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 ). 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  and .
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> was factually measured or observed to occur, versus <Why> in terms of its hypothesized underlying cause or causes.
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. See §4.2 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)  may be used to clarify meaning. Usage of <Param> and <Group> is similar to the VOTable specification, see §4.1 of ; however, a <Param> must be expressed as an empty element and only the following attributes are supported for <Param> under VOEvent:
18.104.22.168 name A simple utilitarian name that may be used elsewhere in the packet. This name may or may not have significance to subscribing clients.
22.214.171.124 value A string representing the value in question. No range or type checking of implied numbers is performed.
126.96.36.199 ucd A UCD  expression characterizing the nature of the <Param>.
For example, here are three values from a GCN  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" /> <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:
188.8.131.52 name A simple name such as in §184.108.40.206.
220.127.116.11 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:
<Group type="GRB_INTEN"> <Param name="cnts" value="73288" ucd="phot.count" /> <Param name="peak" value="1310" ucd="arith.rate;phot.count" /> </Group>
Note that the UCDs above carry the semantics of photon counts and counts per second.
The <What> element may be used to convey arbitrarily detailed data structures, for example, the time series that follows. Applications with more stringent time handling constraints may demand the precision provided by the use of the Space-Time Coordinate specification  under the <WhereWhen> element. In particular, a simple UCD specification offers no facility for representing a desired timescale or reference location. Typical usage might combine the expression of a series of observations using a relative timebase under <What> with a precise expression of spatial and temporal coordinates under the <WhereWhen> element, representative of the entire series of observations. Applications with more stringent space or time coordinate handling requirements yet, may require successive follow-up packets be issued to correctly capture the dependency of <What> upon <WhereWhen> for each individual observation in a series or multi-site observation.
An example of specifying a simple time series:
<What> <Group type="phot_pt" > <Param name="mag" ucd="phot.ma;em.opt.R" value="13.2" /> <Param name="epoch" ucd="time.epoch" value="245523.12345 /> </Group> <Group type="phot_pt" > <Param name="mag" ucd="phot.mag;em.opt.R" value="13.4" /> <Param name="epoch" ucd="time.epoch" value="245523.46533" /> </Group> <Group type="phot_pt" > <Param name="mag" ucd="phot.mag;em.opt.R" value="13.0"/> <Param name="epoch" ucd="time.epoch" value="245523.76444" /> </Group> </What>
The VOEvent packet may include information about where in the sky and when in time the event was detected, from what location, and may include spatial and temporal coordinate systems and errors. If the role of the VOEvent packet is "prediction", the meaning of this element may be interpreted as a recommendation about where to point a telescope to find the astrophysics. If the spatial or temporal locators are not present, it is to be assumed that the information is either unknown or irrelevant. <WhereWhen> can, in general, be any legal VO STC expression, see ; note that this version 1.1 of VOEvent uses STC version 1.30. VOEvent publishers are advised to 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.
This section contains a brief overview of what is needed from the IVOA Space-Time Coordinates specification to be able to accurately specify the sky position of a VOEvent. The <WhereWhen> element is built as follows, as a combination of an observatory location and and observation location. The "xmlns" attribute is a namespace declaration in XML, so that all elements contained within come from the STC schema rather than the VOEvent schema.
<WhereWhen> <ObsDataLocation xmlns="http://www.ivoa.net/xml/STC/stc-v1.30.xsd"> <ObservatoryLocation/> <ObservationLocation/> </ObsDataLocation> </WhereWhen>
<ObservatoryLocation id="Palomar" xlink:type="simple" xlink:href="ivo://STClib/Observatories#Palomar"/>The name of the id attribute is in red, and should be same as the part after the # symbol in the link, in this case "Palomar", also in red. It may have a values indicating a specific registered observatory, such as: KECK, Palomar, VLA, KPNO, JCMT, MMTO, etc, or it may indicate a generic observatory location, where the following values have the following meanings:
<ObservatoryLocation id="KPNO"> <AstroCoordSystem id="UTC-GEOD-TOPO" xlink:type="simple" xlink:href="ivo://STClib/CoordSys#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>
<ObservationLocation> <AstroCoordSystem id="UTC-FK5-GEO" xlink:type="simple" xlink:href="ivo://STClib/CoordSys#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>
Error specification is optional, of course, but recommended, for both time and space components.
The AstroCoords are tied by a coord_system_id (="UTC-FK5-GEO") to an AstroCoordSystem that has been tagged by an identical id attribute, and that points to a coordinate system definition in a library through the xlink:href attribute; that library contains the full description of the coordinate system. Clearly, coord_system_id needs to be identical to id, although they could use any arbitrary string to communicate with each other. However, for clarity we will adopt a convention where this id string will be identical to the last part of the xlink:href. Therefore in the second through fourth lines of the above code the same string is repeated (colored in red) that is used to specify the coordinate system, in the example above it is "UTC-FK5-GEO". This string is the key to understanding the proper context for the coordinates. The coord_system_id should be the same in all three places: the two kinds of "id" attribute, and the part after the # symbol. The coord_system_id is built from a time part, a space part, and a center specification, concatenated in that order with hyphen as a separator.
One of the assumptions is that the reference position (origin) for space and time are the same. That means, for instance, that BARY should only be paired with TDB, and vice-versa. The list of currently supported standard AstroCoordSystems 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 allows more exotic coordinate systems, such as the surface of Jupiter, and it is possible that a future version of this document will address VOEvents that occur in these coordinate systems. We anticipate augmenting this list with one or more solar coordinate systems in the near future. Clients should decide which values they accept; they may not care about the differences between any of these and take all coordinate systems that contain, for instance, "ICRS" or "FK5", "TOPO" or "GEO". Parsers should look for the value of coord_system_id in AstroCoordSystem to see whether it is a coordinate system they support. The crucial issue here is that this mechanism allows the client to decide which events to accept on the basis of the accuracy it requires and what transformations it can perform. For an example of a full <WhereWhen> section, see the example in section 4.1.
We suggest that some Authors will not consider their space-time coordinates to be sufficiently accurate to render necessary a detailed choice of coordinate system. We also suggest that some Subscribers may wish to support only one coordinate system. In this case, we recommend the use of UTC-FK5-GEO as an interoperability standard.
When parsing a VOEvent packet, the following pseudocode may be of some use provide the time, the right ascension, and the declination, so long as the author has chosen to use the FK5 coordinates and Universal Time.
Let x = VOEvent/WhereWhen/ObsDataLocation/ObservationLocation/AstroCoords If x[@coord_system_id=‘UTC-FK5-GEO’] then Let Time = x/Time/TimeInstant/ISOTime Let RA = x/Position2D/Value2/C1 Let Dec = x/Position2D/Value2/C2
Note that this pseudocode checks that the coordinate system is set to a specific value as recommended above ("UTC-FK5-GEO"); if this is set to some other system (e.g, coordinates on the surface of Jupiter), then it will be more difficult to obtain right ascension and declination.
Also note that some subscribers will not want to be as restrictive in their selection of acceptable coordinate systems as this example. Depending on, especially, their accuracy requirements for timing, they may want to accept several, or even all, of the standard systems listed in the previous section
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 <References> (see §3.9) to RTML documents  characterizing 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> <Reference uri="http://nsa.noao.edu/kp012345.rtml" type="rtml" name="Echelle" /> </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  and , 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  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  and , for example).
This element providesa natural language description of the concept, either as a replaement for the <Concept> element, or as an elaboration.
An <Inference> may be used to group or associate one or more <Name> or <Concept> elements. <Inference> has two optional attributes, probability and relation:
18.104.22.168 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.
22.214.171.124 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>SN 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".
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 clients 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 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 . The type of the URI is explicitly specified to ease handling and speed access. A short local name may be attached to the global resource. 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 , as RTML  documents, as MIME-typed web content in general, or as native VOEvents.
A <Reference> element has three attributes:
3.9.1 uri The identifier of another document.
3.9.2 type The type of the document. Allowed values are "voevent", to reference a previously issued VOEvent packet (in whole or in part) "url", for a MIME-typed URL "rtml", to refer to an RTML  document (typically the one used to drive the telescope that made the observation(s) resulting in the event), or "ivo", to refer to IVO resources. The value of type is case insensitive.
3.9.3 name A short, optional name to be used in descriptive text.
A <Reference> used to provide general purpose ancillary data:
<Group type="MyFilterWithImage"> <Param name"=filter" value="H"> <Reference uri="http://.../h.fits" /> </Group>
An example of the indirection of a VOEvent packet using <Reference> (also see §4.3):
<VOEvent ivorn="ivo://raptor.lanl#235649409/sn2005k" role="observation" version="1.1"> <Reference uri="http://www.raptor.lanl.gov/documents/event233.xml" /> </VOEvent>
The author is RAPTOR , and the publisher is Caltech. The <What> sub-element seems to be about photon counts with poor seeing. The packet represents a follow-up observation of an earlier event, as defined in the <Citations> element. The position is stated with an error ellipse with axes 0.02 and 0.01, and position angle is 15 degrees. The time of the event has an error estimate of one second.
<?xml version="1.0" encoding="UTF-8"?> <VOEvent ivorn="ivo://raptor.lanl/VOEvent#235649409" role="observation" version="1.1" xmlns="http://www.ivoa.net/xml/VOEvent/v1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ivoa.net/xml/VOEvent/v1.1 http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd"> <Citations> <EventIVORN cite="followup">ivo://raptor.lanl/VOEvent#235649408</EventIVORN> <Description>This is an observation of the earlier event but with improved square-galaxy discrimination</Description> </Citations> <Who> <AuthorIVORN>ivo://raptor.lanl/organization</AuthorIVORN> <Date>2005-04-15T14:34:16</Date> </Who> <What> <Group name="SQUARE_GALAXY_FLUX"> <Param name="counts" value="73288" unit="ct" ucd="phot.count"/> <Param name="peak" value="1310" unit="ct/s" ucd="arith.rate;phot.count"/> </Group> <Param name="seeing" value="2" unit="arcsec" ucd="instr.obsty.site.seeing"/> <Reference uri="http://raptor.lanl.gov/data/lightcurves/235649409"/> <Description>This is the light curve associated with the observation.</Description> </What> <WhereWhen> <ObsDataLocation xmlns="http://www.ivoa.net/xml/STC/stc-v1.30.xsd" xmlns:xlink="http://www.w3.org/1999/xlink> <ObservatoryLocation id="KPNO" xlink:type="simple" xlink:href="ivo://STClib/Observatories#KPNO"/> <ObservationLocation> <AstroCoordSystem id="UTC-FKC-GEO" xlink:type="simple" xlink:href="ivo://STClib/CoordSys#UTC-FK5-GEO/> <AstroCoords coord_system_id="UTC-FK5-GEO"> <Time unit="s"> <TimeInstant> <ISOTime>2005-04-15T23:59:59</ISOTime> </TimeInstant> <Error>1.0</Error> </Time> <Position2D unit="deg"> <Value2> <C1>148.88821</C1> <C2>69.06529</C2> </Value2> <Error2Radius>0.03</Error2Radius> </Position2D> </AstroCoords> </ObservationLocation> </ObsDataLocation> </WhereWhen> <How> <Reference uri="http://www.raptor.lanl.gov/documents/phase_zero.rtml" type="rtml" name="Raptor AB"/> <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> <Why importance="0.8" expires="2005-04-16T02:34:16"> <Concept>process.variation.burst;em.opt</Concept> <Description>Fast Orphan Optical Transient</Description> <Inference relation="associated"> <Name>NGC1234</Name> </Inference> </Why> </VOEvent>
The <Reference> element provides a publisher with the capability to distribute a very lightweight alert consisting of a pointer to a stored event packet. The ivorn is set to the ivorn of the original packet, allowing an intervening client such as an aggregator to persist the ivorn in a backend database. Since the <Reference> type is explicitly declared, the contents of the packet can later be verified directly against expectations, requiring no preliminary classification of the packet.
<?xml version="1.0" encoding="UTF-8"?> <VOEvent ivorn="ivo://raptor.lanl/VOEvent#23564" role="observation" version="1.1" xmlns="http://www.ivoa.net/xml/VOEvent/v1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.ivoa.net/xml/VOEvent/v1.1 http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-v1.1.xsd"> <Reference uri="http://raptor.lanl.gov/VOEventRepository/23564"/> </VOEvent>