www.estar.org.uk authors: rob seaman, national optical astronomy observatory, usa roy williams,...

www.estar.org.uk

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 [email protected] group …

Alasdair Allan, University of Exeter, UKAlasdair 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

2

www.estar.org.ukWhere I left off …

• An draft release of version 0.9 of the standards document can be found at,

http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-0.90.htmlhttp://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-0.90.pdf

• The collaborative schema development at,

http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/

• Software development hosted by Sourceforge at,

http://sourceforge.net/projects/voevent/


3

www.estar.org.ukWhy 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.


4

www.estar.org.ukTwo 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.


5

www.estar.org.ukThe document

• A <VOEvent> element may contain zero or more of each of the following sub-elements:

<Citations> <Curation> i.e., "Who?" <What> <WhereWhen> <How> <Hypothesis>

<Description>

• Alternately, a <VOEvent> may be completely empty except for a single <Reference> element.


6

www.estar.org.ukVOEvent itself …

• Each <VOEvent> 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.


7

www.estar.org.ukCitation

• 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.


8

www.estar.org.ukCuration (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,

<Curation> <PublisherID>ivo://uraniborg.hven</PublisherID> <Date>1573-05-05T01:23:45Z</Date> </Curation>

• Additional information can be added as per RTML 3.1


9

www.estar.org.ukWhat

• The <What> and <Hypothesis> elements work together to characterize the nature of a VOEvent.

• <What> was factually measured or observed to occur, but <Hypothesis> is an attempt to explain this in terms of its underlying cause(s).

• A <What> element contains a list of <Param> elements which may be associated using <Group> elements.


10

www.estar.org.ukHypothesis

• <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 <What> element.

• Natural language words and phrases are used to express the hypothesized or formal UCD-like vocabulary of astronomical concepts.


11

www.estar.org.ukWhere & 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.


12

www.estar.org.ukHow

• The element is used to provide instrument specific information should this be deemed necessary.

<How> <Instrument> <Name>Mosaic Camera</Name> <Location>Mayall 4m Telescope, Kitt Peak,

AZ</Location> <Reference uri="ivo://nsa.noao/kp012345"

type="voevent" /> </Instrument> </How>


13

www.estar.org.ukDescription

• This optional element permits the VOEvent packet to contain additional human-readable information of unspecified format.

• A <Description> may be included within any element or sub-element of a VOEvent to add human readable content.

• <Description> may contain <Reference>, and vice versa, for instance, to allow a client to recognize a URL embedded in an otherwise only human-readable block of text.


14

www.estar.org.ukReference

• It is anticipated that VOEvent packets will often include <Reference> 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.


15

www.estar.org.ukReferences as packet indirection

• Just a quick justification packet indirection by using the <Reference> element.

<VOEvent id="ivo://raptor.lanl/235/sn2005k” role="actual" version="0.90"> <Reference uri="http://raptor.lanl.gov/docs/e233.xml"type="voevent" /> </VOEvent>

• The <Reference> 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.


16

www.estar.org.ukDown 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!


17

www.estar.org.ukImplementation of VOEvent

How do we distribute VOEvent messages?

• Transport methods?

• System architecture

• VO Registries


18

www.estar.org.ukEvent 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.


19

www.estar.org.ukPublishing


– 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…


20

www.estar.org.ukSubscription


– 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?


21

www.estar.org.ukSearching


– 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.


22

www.estar.org.uk

VOEventDatabase

Registry

Hierarchical

Event Provider

EventConsumer

Event Provider

Event Provider

VOEventAuthority


23

www.estar.org.uk

Peer-to-Peer

LocalAuthority

EventProvider

LocalRegistry Aggregator

EventConsumer

• The world is flat and interconnected…

EventConsumer

EventConsumer

EventConsumerAggregator


24

www.estar.org.ukWhat’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.


25

www.estar.org.ukShould 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…


26

www.estar.org.ukConclusions

• 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.

www.estar.org.uk authors: rob seaman, national optical astronomy observatory, usa roy williams,...

Documents

voevent session

usa voevent disclaimer

ivoa interoperability

things simple slide

single event

usa tom vestrand

usa robert white

usa scott barthelmy