Authors: Rob Seaman, National Optical Astronomy Observatory, USA Roy Williams, California Institute of Technology, USA Scott Barthelmy, NASA Goddard Spaceflight Center, USA Joshua Bloom, University of California, Berkeley, USA Frederic Hessman, University of Gottingen, Germany Szabolcs Marka, Columbia University, USA Arnold Rots, Harvard-Smithsonian Center for Astrophysics, USA Chris Stoughton, Fermi National Accelerator Laboratory, USA Tom Vestrand, Los Alamos National Laboratory, USA Robert White, LANL, USA Przemyslaw Wozniak, LANL, USA VOEvent Disclaimer: This talk does not necessarily represent the views of the group Alasdair Allan, University of Exeter, UK … then again some the material is uncontroversial, so as always your mileage may vary! : keeping things simple

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 1 Where I left off … An draft release of version 0.9 of the standards document can be found at, The collaborative schema development at, Software development hosted by Sourceforge at,

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 2 Why I’m here … I’m an event provider I’m an event consumer I push telescopes around the sky … … and therefore I want things as simple as possible! Completeness should, if necessary, be sacrificed in favour of getting something that works. If we run into porblems we can always fix it later.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 3 Two issues The document itself must be kept simple! The infrastructure built around VOEvent should similarly be kept simple. By this I don’t mean that the software implemented to parse the document, I mean the distribution and aggregation.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 4 The document A element may contain zero or more of each of the following sub-elements: i.e., "Who?" Alternately, a may be completely empty except for a single element.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 5 VOEvent itself … Each packet is required to have a unique identifier, expressed with the id attribute as a URI. It is anticipated that “a number of VOEvent registries will be founded to issue unique IDs from a variety of useful and appropriate namespaces”. The optional role attribute accepts two possible enumerated values, test or actual. The value actual is the default if the attribute is missing.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 6 Citation Citations reference previous events to do one of three things: –Follow-up on an previous event alert –Supersede a prior event with better information –Issue a complete retraction of a previous event In addition, citations allow merging multiple events into a single related thread, or contrarily, allow separating a single event into multiple threads.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 7 Curation (i.e. Who) This element of a VOEvent packet is devoted to curation information. In other words, who is responsible for the information content of the packet. A minimal curation information would be, ivo://uraniborg.hven T01:23:45Z Additional information can be added as per RTML 3.1

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 8 What The and elements work together to characterize the nature of a VOEvent. was factually measured or observed to occur, but is an attempt to explain this in terms of its underlying cause(s). A element contains a list of elements which may be associated using elements.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 9 Hypothesis seeks to capture the publisher's emerging concept of the nature of the astronomical objects and processes that caused the observations noted in the element. Natural language words and phrases are used to express the hypothesized or formal UCD-like vocabulary of astronomical concepts.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 10 Where & When The VOEvent may include information about where in the sky, and when in time, the event occurred. If not present, it is to be assumed that the information is either unknown or irrelevant. Where & when can be any legal STC expression. Publishers are advised to construct expressions that concisely provide all information that is scientifically significant to the event, and no more than that.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 11 How The element is used to provide instrument specific information should this be deemed necessary. Mosaic Camera Mayall 4m Telescope, Kitt Peak, AZ

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 12 Description This optional element permits the VOEvent packet to contain additional human-readable information of unspecified format. A may be included within any element or sub-element of a VOEvent to add human readable content. may contain, and vice versa, for instance, to allow a client to recognize a URL embedded in an otherwise only human-readable block of text.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 13 Reference It is anticipated that VOEvent packets will often include to such content as finding charts, cut-out images, light-curves, object catalogs, SQL queries, instrumental configurations — to list only a few. This content will be expressed in various graphics and image formats such as FITS, as VOTable, as RTML documents, as MIME-typed web content in general, or as native VOEvents documents.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 14 References as packet indirection Just a quick justification packet indirection by using the element. The element provides a publisher with the capability to distribute a very lightweight alert consisting of a pointer to a stored event packet. The id is set to the id of the original packet, allowing an intervening client such as an aggregator to persist the id in a backend database.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 15 Down with document bloat … The core authors are, in general, more or less happy with the current standards document and discussion has now turned to adding more power to the standard. However, typically this causes document bloat, and if we make things too complex, then event publishers will not adopt the standard. Simple interfaces for simple tasks, but more importantly simple interfaces for common tasks, no matter how complex!

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 16 Implementation of VOEvent How do we distribute VOEvent messages? Transport methods? System architecture VO Registries

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 17 Event infrastructure From the version 0.9 standards document, It is expected that VOEvent packets will be used as the basis of an information infrastructure of databases, or registries, that 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. I’m not sure I entirely agree with these ideas.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 18 Publishing From the version 0.9 standards document, –Publishing: a client creates a VOEvent packet without an IVO identifier, communicates with some database server to add the packet to the holdings and get the persistent identifier. There obviously has to be some sort of publishing mechanism, but I disagree that “centralization” is the correct way to go…

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 19 Subscription From the version 0.9 standards document, –Subscription: a client can create a query and lodge it within a VOEvent compatible database; whenever a packet comes in that matches the query, the client is immediately informed about the new packet. There obviously has to be some way to register to receive events. But why does this have to be a central service?

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 20 Searching From the version 0.9 standards document, –Search: a client can send a query to a VOEvent database server, and obtain all event packets which match it. If we want to do this then there does have to be some sort of central service, or at least an index of services. However again, centralization isn’t necessarily a good thing. Especially in real time systems.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 21 VOEvent Database Registry Hierarchical Event Provider Event Consumer Event Provider Event Provider VOEvent Authority

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 22 Peer-to-Peer Local Authority Event Provider Local Registry Aggregator Event Consumer The world is flat and interconnected… Event Consumer Event Consumer Event Consumer Aggregator

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 23 What’s the difference? Using a local authority and registry on a provider basis means that you remove the risk of central authorities not being there when needed We’re dealing with real time systems remember… But surely there is trust issues? Sure, but trust can be dealt with at a client level, there is no need to handle trust centrally either.

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 24 Should we get involved? Should we actually get involved in deciding how VOEvent messages are distributed anyway? Is the architecture of an event system actually the concern of this group? If so, in a real time system I would argue strenuously to avoid any sort of central authorization. But I’d argue that this isn’t really our business…

IVOA Interoperability Meeting, Kyoto (May 2005) VOEvent Session 25 Conclusions Current standard is fairly light weight. Need to keep it that way … Infrastructure to distribute event messages is important, but I’m not convinced it is something we need to, or should, get involved with. Instead let the infrastructure evolve naturally.