VOEvent Working Group First meeting of VOEvent WG at an IVOA Interop Small but intensely interested group Much accomplished in the short time since the WG was created (Pune Interop) Thanks to Roy Williams, Alasdair Allan, Arnold Rots, Rob Seaman, et al. for work well done

VOEvent Working Group Alasdair summarized main features of VOEvent protocol (along with a number of editorial comments) Some tension remained between desire to be concise (for extremely rapid response events) and complete (for the historical record) The discussion resolved much of this tension

VOEvent Working Group Alasdair summarized main features of VOEvent protocol (along with a number of editorial comments) Some tension remained between desire to be concise (for extremely rapid response events) and complete (for the historical record) The discussion resolved much of this tension

VOEvent Working Group Comments and suggestions included: –Rename Hypothesis tag as Why –Distinguish between use of term registry in VOEvent document and registry as in Resource Registry. VOEvents do not go into the Resource Registry; VOEvent publishers and public VOEvent databases do. –Distinguish between functional roles (create, publish, aggregate, store) and implementation –Allow diverse modes of subscription, from peer-to- peer to more hierarchical. Look at RSS (Really Simple Syndication) as a possible subscription model.

VOEvent Working Group Comments and suggestions (contd): –For very rapid notifications, suggest two-part approach. VOEvent-Lite provides minimum essential info, followed by more detailed information linked by Citation/Reference. –Rich grammar does not mean that all VOEvents have to use every language element. –Need to think about security model. Main point is authentication (are VOEvents coming from trusted sources?), though authorization also matters when data is proprietary. Adopt Grid/Web Services security implementation. Add simple Authentication tag to Curation: certificate/signature goes here...

VOEvent Working Group Comments and suggestions (contd): –Do not over-plan for implementation architecture. Agree now on protocol and evaluate implementations. –Should include new VOEvent.Role = Prediction to include events like eclipses, transits, occultations, solar flare-induced events, etc. New Role is required rather than just using future date/time in order to distinguish Predictions from Events in the historical record. –Might want a way to express time-to-live or urgency,i.e., for how long does this information matter?

VOEvent Working Group Comments and suggestions (contd): –UCDs are appropriate in VOEvent for describing measurements of quantities –Some UCDs are relevant to Hypothesis, but mappings are more difficult –Debated idea of extending UCDs, or developing ontology, to describe astronomical events unambiguously. Out of scope. –Get VOEvents working now. Recommend IAU Thesaurus as initial source of event naming/classification. Review event database and look at common usage, most frequent event types. Revisit need for standard terminology.

VOEvent Working Group Comments and suggestions (contd): –VOEvent does not replace or absorb RTML. VOEvent notifies, RTML carries out observation based on receipt of notice. –Consider promoting RTML through the IVOA document standards process (visibility)

VOEvent Working Group Interfaces with other WGs –Registry WG for registering VOEvent publishers and publication services –VOQL for creating OpenSkyNode interfaces to VOEvent databases