|
IVOA Sky Transient Metadata
Version 0.1
IVOA WG Internal Draft 2004-10-08
- Author(s):
- Joshua Bloom
- Matthew Graham
- Chris Stoughton
- Roy Williams
- Przemyslaw Wozniak
|
|
Throughout human history, unexpected events in the sky have been interpreted as portents and omens. In the next years this study will be greatly extended with digital technology, with many new projects making wide-area systematic searches for transient events in the sky. Such transients may be local phenomena (comets, asteroids, Kuiper-belt objects, etc), or more distant (novae, cataclysmic variables, supernovae, gamma-ray bursts, lensing events, etc). Most exciting of all would be new and unknown types of transient, heralding a new field of astrophysics. Searches for astrophysical transients are taking place at all the electromagnetic wavelengths from radio to gamma, but also underway are gravitational wave searches, neutrino detectors, and high-energy cosmic ray searches.
For many types of transients, astrophysical knowledge is gained through fast, comprehensive followup observation -- a spectrum for example -- and by views with different types of instrument. To satisfy this need, several projects are setting up robotic telescopes, that can respond to a digital message to point the telescope and make observations -- but in near-real-time and without human intervention. We can also imagine automated systems for examining archives that respond to reports of transients.
Therefore we propose the following sequence for building an information infrastructure for transients, obtaining international agreements where necessary to ensure interoperability.
In building the VOTransient packet, we make use of the IVOA identifier syntax that has been developed as part of the VO registry framework. These identifiers are recognizable because they begin with ivo://, and they are meant as a stand-in for a particular metadata packet that is obtainable from a VO registry. A registered VOTransient packet is one that has a valid identifier -- meaning that a registry exists that can resolve that identifier to the full packet. The identifiers thus provide a citation mechanism, a way to express that one VOTransient packet is a follow-up of a previous packet.
Another way to use VO identifiers is for efficiency. One section of the VOTransient schema is about authorship (who is responsible for this candidate discovery), and that section may be replaced by a VO identifier which points to the relevant "organization". If a group creates VOTransient packets regularly, all with the same authorship, it would then be efficient for them to use the same VO identifier in each packet rather than sending the whole list of people and contacts each time.
We are expecting VOTransient packets to be used as the basis of an information infrastructure of databases, or registries, that hold VOTransient packets, keyed by their identifiers. These databases may harvest packets from each other, so that a packet may be held at more than one database. In addition to the harvesting protocol, there would be three ways for clients to interact with the database servers:
An announcement of a new phenomenon in the sky may eventually be Nobel-prize material, and we hope that a VOTransient packet would be the chosen medium for the very first announcement. However, we felt that the astronomical community would generally be happy with an open system, and therefore VOTransient packets do not contain any information about intellectual property restrictions on the data they contain. If there are projects that produce "secret" packets, they can certainly work within a closed system of clients and servers, without allowing any harvesting. We felt this latter solution to be simpler and more effective than demanding that all servers understand a schema for IP restriction.
A VOTransient packet expresses the discovery of a sky transient, located in a specified spacetime region, observed by some instrument, and published by some some group of people. This "Discovery" type is the primary purpose of VOTransient and the default packet type.
packetType (may be discovery, followup, intendedFollowup)
The "packetType" may have other values that modify the semantics: besides the "Discovery" type, a VOTransient may have type "Followup", and cite one or more other packets -- meaning that the observation was done as a response to cited packet. In this case, the positional information is assumed to to be a new, independent measurement, not just a repeat of what was in the cited packet.
The packetType may also be "IntendedFollowup", which expresses an intention of following up on the cited packet. In this case, the positional information is interpreted as a "region of study" in the followup observation ("this is where we will look").
packetRole (may be Real, TestPleaseIgnore
Another flag that may be present in the packet is the "packetRole" which can take the default value "Real", meaning that the packet describes an observation of the sky, or it may take the value "TestPleaseIgnore", meaning that the packet DOES NOT DESCRIBE ASTRONOMY, but rather is part of a testing procedure of some kind. It is the responsibility of all who receive VOTransient packets to pay attention to the packetRole, and be quite sure of the difference between a real discovery and a test of the system.
The VOTransient packet may include information about where and when the transient was detected, complete with error boxes of various kinds, as noted below. If the spatial or temporal locators are not present, it is to be assumed that the information is either unknown or irrelevant.
Coord1 (float, angle in degrees)
Coord2 (float, angle in degrees)
Frame (string, default J2000)
The sky position will be expressed by a pair of angular coordinates, in degrees, and a "frame" name that allows intepretation of those coordinates. The default frame is "J2000", in which case the coordinates are interpreted as right ascension and declination in the J2000 frame. The error estimate of a sky position may be expressed as a circular, elliptical, or polygonal region of error. Furthermore, the positional estimate could be disconnected -- for example the sky position could be an intersection of two annuli.
Time (float, modified Julian Day)
Time will be expressed as a modified Julian day number (number of days since November 17th, 1858). The MJD includes a fractional day to arbitrary precision. There are semantically distinct intervals associated with the event: the error interval of the beginning of the transient, and the estimate of the duration of the transient. The former would subsume exposure times, interval since last observation, as well as statistical errors in determining time.
detectionChannel (string)
While much astronomy has been done by collecting photons, other types of detector are appearing that may have the ability to detect transients. Thus the traditional "wavelength regime" of the photon astronomer is generalized to "detectionChannel", that may be "Electromagnetic" (together with the wavelength range), or "Gravitational Wave", "Neutrino", or "Cosmic Ray", or others.
Another section of the VOTransient packet indicates the instrument with which the transient observation was made, together with information about how the instrument was being used. For an optical telescope, for example, the description micht include aperture, bandpass, and magnitude limit; for an Xray telescope it might include high and low energy bandpass and flux limits.
instrumentName (string)
instrumentType (one of set of known schema)
We model the instrument as a combination of an "instrumentName" (eg Palomar 60-inch), and an instrument type (eg "opticalTelescope"). The instrument type implicitly refers to a schema for that type of instrument, a schema that has been agreed among domain experts. The instrument description can then be written as an instance of the relevant schema.
This is another occasion where a VO identifier could be used as an abbreviation of providing full instrument metadata. If a survey team always uses its instrument in the same configuration, it may be worth registering the metadata packet that describes the instrument, so that an identifier can be used in place of repeating the description for each VOTransient packet. In this case, the available information would be: instrument name, instrument type, and the identifier for the specific configuration.
A section of the VOTransient packet is devoted to curation information: who is responsible for the information content of the packet. We follow the IVOA Resource Metadata document [1] in defining curation.
Publisher (string)
An entity responsible for making the resource available. Examples of a Publisher include a person or an organization. Users of the resource should include Publisher in subsequent credits and acknowledgments. The Publisher may be either a text string or a VO identifier pointing to an organization.
Contributor (string)
An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person or an organization. Users of the resource should include all Contributors in subsequent credits and acknowledgments.
Contact (string, e-mail address)
The e-mail address for contacting the persons responsible for the resource. Contact is split into two components for clarity, Contact.Name and Contact.Email.
Date (YYYY-MM-DD)
A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability (i.e., most recent release or version) of the resource. ISO8601 is the preferred format (YYYY-MM-DD).
Reliability (float between 0 and 1)
Reliability of an observation is highly subjective, and therefore difficult to interpret by another, yet at the same time it should be possible for the observing team to indicate reliability by comparison with other observations made by the same team. Therefore we simply state that any creator of VOTransient packets should make the reliability number however they wish; they may publish an explanation or not. Zero means unreliable,
and unity means very reliable. However, it should be stated that a reliability of zero is NOT the same as setting the PacketRole to TestPleaseIgnore.
a (href=URL string)
It may be that there are images, spectra, time-series or other information that acts as supporting evidence for the transient detection. These may be linked from the VOTransient packet by the usual HTTP mechanism <a href=http://...>. In order to keep VOTransient packets small and nimble, the actual content of these links may not be included.
ivoID (ivo identifier URI)
As noted in the Introduction, VOTransient packets may contain VO identifiers, as defined and discussed in [2]. They take the form ivo://authority/resourceKey, which are references to metadata packets that may be found at a VO registry or VOTransient database.
The lookup procedure is similar to looking up a URL on the world wide web: each registry controls a number of authority IDs. These are like domain names on the net: each is resolved to exactly one endpoint machine through a system of distributed knowledge. Once that machine is discovered, it should be able to resolve the secondary part of the identifier, the resourceKey. Indeed, the machine that holds an authority ID has made a promise to resolve all the resourceKeys that it has issued.
As work continues on the VOTransient structure, we will work with the IVOA to define a message protocol by which a packet may obtain a valid IVOA identifier from a database of such packets. Broadly speaking, the creator of the packet (client) would be submit to the server a packet with empty identifier, the server check syntax and respond with the same packet, but with the ivo:// identifier filled in.