A modest proposal for VOEvent

[Rob Seaman]

Howdy,

My goal is to create a draft of the v2.0 VOEvent specification to be  
ratified by the WG at Hotwired II.  These are the issues and my  
proposals for each:

1) Orbital elements.  See appended message from Francesco.  Pan-STARRS  
has been working with the Minor Planet Center to define a VOEvent- 
based specification.  We should follow their lead.  The MPC is the  
only game in town.

2) Time series.  We need some way to express simple tables within the  
packet and more complex tables within the same data stream.  Let's  
leverage VOTable for both, perhaps with (extreme) simplifications.

3) General improvements to References.  These are not controversial.

4) General improvements to Params.  (Datatypes and disallowing  
duplicates.)  Non-controversial.

5) Improvements to schema as described by Bob Denny.  Non- 
controversial.  Our packets must be simple to author and simple to  
validate.

6) Modifications to language of spec to accommodate formal  
vocabularies.  Non-controversial.

7) Possible small modifications to spec to support functionality such  
as registering VOEventStreams, SEAP, Portfolios, etc.  Non- 
controversial.

8) Digital signatures and private messaging.  Non-controversial that  
this is not a VOEvent issue, per se.

9) Supporting generalized external schema.  Required by Heliophysics  
Knowledgebase and to support other external formats in the future.   
Non-controversial as long as brokers can ignore what they don't  
understand.

10) Moving STC hooks from VOEvent schema to this external structure.   
Providing native VOEvent WhereWhen subelements for typical community  
targeting use cases.  Technically non-controversial.  Critical to our  
continued success.  Applications that need access to gory STC details  
will be able to do so.  The majority of applications that don't will  
result in (much) simpler packets that can actually be validated  
against the schema.

WG action items:

	A) comment now with alternative positions

	B) attend Hotwired if you want to influence the direction of the  
standard

	C) handling the spec now will let us focus on functional issues like  
transport at Hotwired

Rob
----

Begin forwarded message:

> From: Francesco Pierfederici <fpierfed at lsst.org>
> Date: February 20, 2009 3:55:31 PM GMT-07:00
> To: Rob Seaman <seaman at noao.edu>
> Subject: MOPS Events
>
> Hi Rob,
>
> Following our conversation, here is what we would like to use.
>
> Our orbital elements are in cometary form and so something like this
> would be nice:
> <orbit>
>  <q units="AU" value=123 />
>  <e units="" value=123 />
>  <i units="deg" value=123 />
>  <node units="deg" value=123 />
>  <time_peri units="MJD" value=123 />
>  <arg_peri units="deg" value=123 />
>
>  <epoch units="MJD" value=123 />
>
>  <src values="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  
> 21" />
> </orbit>
>
> Then we would add geocentric ephemeris
>
> <ephemeris type="geocentric">
>  <ra units="deg" value=123 />
>  <dec units="deg" value=123 />
>  <mjd units="MJD" value=123 />
> </ephemeris>
>
> And the detections used to derive the orbit
>
> <detections>
>  <ra units="deg" value=123 />
>  <dec units="deg" value=123 />
>  <mjd units="MJD" value=123 />
>  <obscode units="" value=123>
> </detections>
>
> Of course the units="MJD" is probably wrong...
>
> We could unify the ephemeris and detections blocks by just dropping
> the type param in ephemeris and setting obscode=0 in there...
>
>
> Thanks!
> Francesco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20090220/eed59ac0/attachment-0001.html>