VOEvent session at IVOA Interop

[Roy Williams]

VOEvent session at IVOA Interop
-------------------------------
Beijing, 9am Thursday 5/17


(1) If anyone would like to give a short presentation at this session, 
or any topics that need discussion, please contact me. Currently we have 
Matthew Graham, Phil Warner, and myself.

(2) Technical objective is making extension schemas (see summary 
information below). If you would like to contribute to this in Beijing, 
the discussion begins at the Registry session 10am Tuesday 5/15. In any 
case, please contribute your thoughts by email to this group.

Thank you
Roy Williams
Caltech
VOEvent WG Chair

--------------------

Extension Schemas for VOEvent

One of the objectives for VOEvent at the Interop is to build ways of 
registering Repositories and Publishers with the VO Registry. The first 
way to do this is to fill in a registry form for a *Project* or 
*Organization* that deals with VOEvents, explaining everything in the 
description, or providing a URL that has the explanation. The associated 
IVORN can then be used in the VOEvent packets themselves, so that 
contact information does not have to be repeated for each published 
event. Another way to get involved is to fill in a form defining a 
*Dataset*, meaning a collection of past events, with an implication that 
there will be more.

In the VOEvent definition, several roles are defined, including Author, 
Publisher, Repository, and Subscriber. The Publisher accepts publication 
of events and accepts subscriptions; whenever an event is published, 
subscribers get it very quickly, if it matches the subscription criteria 
(eg "I only want bright supernovae in Virgo"). The publisher may support 
one or more transport protocols to push events to subscribers. The 
Repository stores events that may be aggregated from several publishers. 
It can take an event identifier (IVORN) and return the corresponding 
VOEvent packet. It can take queries about past events (eg. "give me all 
events in Virgo from April 2004")

** A /*Publisher*/ takes packets from an Author, checks the validity of 
a packet, and assigns a unique identifier to it; either the author or 
the publisher makes the actual XML syntax of the event, but the 
publisher is responsible for the XML-validity of that syntax. Publishers 
are expected to register with the IVOA registry as described below.

Publisher Capability Extension Schema
    Who is running it
    What kinds of events are published
    How to subscribe to a feed
       criterion for which ones are wanted by push protocol
    How to publish events
       permissions and authentication requirements
    Which push protocols are supported for publish and for subscribe
       Jabber
          server name
          feed name
          login name and password
       TCP Vanilla
          server name
          port number
          is there any authentication?
       RSS
          server URL
          how to get different feeds
          version of RSS

** A /*Repository*/ persists packets either permanently or temporarily, 
and runs a service that allows clients to resolve identifiers and apply 
complex queries to the set of events in the repository. A repository 
must subscribe to one or more input VOEvent streams. Repositories are 
expected to register with the IVOA registry.

Repository Capability Extension Schema
    List of publishers whose events are kept
    Queries by humans with web forms
    "SEAP" protocol endpoint to fetch events (SEAP not yet defined)
    endpoint for service that resolves event IVORNs
    Harvesting interface
    Can a client subscribe to a Repository?