VOEvent draft specification 0.3
Frederic V. Hessman
Hessman at Astro.physik.Uni-Goettingen.de
Tue Jan 4 08:35:53 PST 2005
Dear colleagues,
As someone very interested in VOEvent but from a totally different
perspective, allow me to respond to Roy's
comments/questions.
First of all, to "heat up" the discussion, I've prepared an RTML
equivalent to the optical flash example done in the
present rtvo.net proposal for VOEvent, called VOTransient: it's
available at our Twiki RTML site:
http://monet.uni-sw.gwdg.de/twiki/bin/view/RTML/ExampleForVOTransient
My point in doing so is definitely NOT to play down the work which has
been done for VOTransient/VOEvent - indeed, I've added
a few very nice things to the most recent working version of RTML by
looking to see where the VOTransient ideas were
coming from. My points are:
1) the discussion of VOEvent is obviously still dominated by interest
in transients (which are just one form of event);
2) that we've been thinking about XML documents/interfaces for quite a
bit longer and for a much broader potential class of
uses, and hence
2) >90% of what VOTransient does and what VOEvent is described to have
to do is what the RTML community as well as
everyone else perhaps NOT interested in transients or events has to
do as well. This means that one has to be very careful when
interpreting the VOTransient diagram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fig1.gif
Type: image/gif
Size: 4807 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20050104/3cf214b7/attachment-0001.gif>
-------------- next part --------------
since this implies a natural hierarchy, whereas my version of what
this diagram and a similar diagram for RTML would be the following
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOEventRTML.jpg
Type: image/jpeg
Size: 31844 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20050104/3cf214b7/attachment-0001.jpg>
-------------- next part --------------
This implies either that
1) VOEvent can naturally be build from RTML plus an event-specific
schema or that
2) BOTH can be built from appropriate building blocks.
Of course, we can approach things with a "let a thousand flowers bloom"
approach, resulting in RTML, VOEvent,
LSSTXML, PanSTARRSXML, MeadeXML and many more. A more intelligent
approach would be to have each
specialized XML use be able to add it's own bits to a more general
scheme which we can all more-or-less agree upon.
Those of us seriously interested in telescope networking would be very
grateful if we could agree upon a basic framework and
not have to ultimately speak dozens of XML dialects (well, at least to
have to write dozens of XSLT scripts).
We've stuck quite a bit of work into RTML so our ideas of how to
organize the information to make it maximally
useful while minimally complex have definitely evolved, even if it's
not obvious to the newcomer.
With this very personal perspective, I naturally find the
structure of the information in RTML more natural than in the current
VOTransient schema. However, I'd be quite
willing to exchange it for a better system.
Now, however, I'll argue that the best solution for the VOEvent
community would be to use the framework provided by
RTML 3.0 and stick the transient-specific things as add-ons/plug-ins,
even allowing that some of RTML which is
too specific to optical/IR ground-based telescopes might have to be
taken out and made into a plug-in as well.
As a first attempt to illustrate the idea of combining RTML and
VOTransient, I've stuck all the really specific transient parts of
VOTransient into an RTML <Other> tag in what I think looks like the
best of both worlds. Certainly, this document does
everything which the transient community needs. Again see
http://monet.uni-sw.gwdg.de/twiki/bin/view/RTML/ExampleForVOTransient
Maybe what we really need is IAUTelescope, IAUObservation,
IAUInstrument,... which one can put together into
RTML (for scheduling within networks) and VOEvent (for VO access to
events) and many other specialized
protocols.... In any case, the problem goes far beyond VO and
telescope networks alone so it seems a shame for
all of us to invent different wheels and it even raises the question of
whether the VO community is the best place to
discuss this.
Now to specific questions/comments.
> -- We call for additional schemas to represent "instrument
> configuration" and "event description". The RTML project provides the
> former for optical telescopes: what other schemas should be
> incorporated in these roles?
Admittedly, RTML was born with optical telescopes in mind, but there
are very few places where it really shows. VOTransient
does state whether the signal is electromagnetic or not and I confess
not having thought about how RTML might do
this. No, I also haven't thought about how one might describe an
observation with a radio interferometer (other than
<Aperture type="effective"> and I'd love to see a more detailed
discussion of how non-standard telescopes might
be described in VOTransient or RTML. The RTML concept of generic
<Camera>'s and <Spectrograph>'s should be fairly
robust, even when we might need a few more of them (and there's always
the possibility of producing your own <Device>'s).
RTML offers a clear means of separating the different parts of interest
(e.g. document info in <History>, purpose
info in <Project>, people info in <Contact>, technical info in
<Telescope>, <Camera>, <Spectrograph>, <Device>,
and scheduling info in <Schedule> and <Observation>, calibration info
in <Calibration>,....) but it also permits
users to combine them in astronomically meaningful hierarchies.
Admittedly, in my VOTransient equivalent,
I've reduced the "event" into a reported observation within a
<Schedule> and thus had to stick the derived target
parameters into the <Target> itself, embedded in the <Schedule>. For
someone who comes from the idea of having
proposals being submitted and then receiving a report on the
observations made, this makes perfect sense; for an
anonymous triggered event or a generic VOEvent, this model is not quite
as natural but it's certainly not unnatural
(the triggered observation did have to be scheduled, after all).
A possible alternative would be to offer an
<Event><Target/><Observation/></Event> model as an alternative to the
<Schedue><Target/><Observation/></Schedule> or even
<Target/><Schedule><Observation/></Schedule>
hierarchy which are more natural for RTML used for telescope networks.
> -- Is it reasonable to have a single "importance" number (section 3.6)
> between 0 and 1 that expresses "something" about the importance of the
> event?
Either there's a IAU-type agreement about "importance" (lots of luck)
or we simply accept that the reported importance is subjective
(e.g. in RTML, a <Priority> as a positive integer in the usual
observing proposal sense which, in true Ptolemian tradition starts at 0
and decreases infinitely as the number increases!).
> -- We have the basic type of an event chosen from the list: discovery,
> followup, intendedFollowup, merge, veto, reject (section 3.1). Are
> these the right types?
>
> -- Existing systems characterize events by their astrophysics, for
> example the IAU telegram uses this list: Comets, Supernovae, Novae,
> Outbursts Of Unusual Variable Stars, Features On Planetary Surfaces.
> How can we (should we?) settle on an event description like this?
RTML uses multiple <Classifications> (e.g. "optical flash", "gamma-ray
burst", "spiral galaxy",...) - see our list of ~50 at
http://monet.uni-sw.gwdg.de/twiki/bin/view/RTML/SchemaContentTargetType
. These obviously need
to be made VO-standardized.
> -- Should we specify event time by Julian day number? Is this
> unambiguous and universal?
One needs to permit both vague and precise time values, the assumption
being that things are imprecise if not
accompanied with precise information about the system and the error in
the values.
> -- Two existing systems have definitions of "event type", including
> Comet, Microlensing, etc etc (see sections 5.1 and 5.3). Can we make a
> comprehensive list of such "event types" for submitters to select
> from?
Here's lots of overlap with the general characterization: why not
"optical flash" plus "gamma-ray burst" or maybe
"star field" plus "microlensing event"? That way "comet" doesn't have
to be an event type (and all astronomical
objects are going to have some finite timescale for
variable/appearance-disappearance).
Rick
------------------------------------------------------------------------
------------------------
Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte Tel. +49-551-39-5052
Geismarlandstr. 11 Fax +49-551-39-5043
37083 Goettingen http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------
-------------------------
> So what are we trying to achieve?
>
> There are several projects coming online that will discover immediate
> events in the sky, for example Swift, Ligo, Pannstars, Palomar-Quest,
> and LSST. There are also many new robotic telescopes that will
> follow-up such events very quickly. In the past, several
> "human-centric" event systems have been very successful, for example
> the IAU telegrams, the Gamma-ray burst Coordinate Network, the
> Astronomer's Telegram, etc. These systems use natural-language text to
> describe the nature of the event, and send all qualified events to all
> subscribers.
>
> However, we expect a larger number of events as the new projects come
> online, and we expect them to be handled by machines. We expect
> subscribers to make a careful filter for the events they want, for
> example events from a specific survey, events that will be above the
> horizon. There could be very detailed subscription requirements,
> perhaps events where the R-band magnitude increase was at least 2.
> Machines can select events based on coincidence. A gravitational wave
> detector, for example, might produce a large number of candidate
> events, but the interesting ones coincide with candidates from another
> detector. Further, the interoperability that we propose here will
> allow event federation: for example finding coincidence events between
> Swift and Ligo.
>
> To enable this more sophisticated processing, we should
> (1) Build a more structured message that is accessible to machines, and
> (2) Create a uniform citation system for event messages, and
> (3) Separate message structure from transport
>
> To illustrate (1), the position of an event in the sky, for example,
> should be defined formally in the VOEvent packet instead of being part
> of a text descriptions -- and therefore inaccessible to a machine. For
> (3), we need not rely on email for moving VOEvent messages, but other
> protocols would be more useful for machines, perhaps web services.
>
> There is no intention here of destroying existing systems, but rather
> achieving the goals described above with minimal re-engineering. At
> this point, we are interested only in (1) above: reaching
> international agreement on the semantic content of an event message.
> This will form the basis of a valuable interoperability.
>
> Over the last few weeks, a small group of us (Bloom, Graham, Plante,
> Stoughton, Williams, Wozniak) have been drafting a document that
> starts this semantics of a structured VOEvent. The draft specification
> is at
> http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-0.3.htm
>
> Please take a look and render your comments to this group. (If you
> would like to edit the document directly, please us strikethrough (<s>
> ... </s>) to delete, and font color (<font color="red"> .... </font>)
> to add new text. Please also note your changes in the change history
> at the end.
>
> Specific questions:
>
> -- What other astrophysical event-reporting systems are out there that
> we have not mentioned in the document?
>
> -- We call for additional schemas to represent "instrument
> configuration" and "event description". The RTML project provides the
> former for optical telescopes: what other schemas should be
> incorporated in these roles?
>
> -- Can events from existing systems be represented (in principle) by
> the draft semantics?
>
> -- Is it reasonable to have a single "importance" number (section 3.6)
> between 0 and 1 that expresses "something" about the importance of the
> event?
>
> -- We have the basic type of an event chosen from the list: discovery,
> followup, intendedFollowup, merge, veto, reject (section 3.1). Are
> these the right types?
>
> -- Existing systems characterize events by their astrophysics, for
> example the IAU telegram uses this list: Comets, Supernovae, Novae,
> Outbursts Of Unusual Variable Stars, Features On Planetary Surfaces.
> How can we (should we?) settle on an event description like this?
>
> -- Should we specify event time by Julian day number? Is this
> unambiguous and universal?
>
> -- When we specify sky position, is it reasonable to expect J2000
> coordinates with error box that may be disk, ellipse, or polygon?
>
> -- Two existing systems have definitions of "event type", including
> Comet, Microlensing, etc etc (see sections 5.1 and 5.3). Can we make a
> comprehensive list of such "event types" for submitters to select
> from?
>
> Thank You
> Roy Williams
>
> --------
> California Institute of Technology
> roy at caltech.edu
> 626 395 3670
>
More information about the voevent
mailing list