A modest proposal for VOEvent

[Rob Seaman]

Rick,

Haven't seen anything further on this.  You have my blessing to tie  
this up with a pretty, pretty bow.  (Since you won't be traveling, you  
should have lots of time :-)  Give us something to vote on at  
Hotwired.  Maybe you can connect using the EVO stuff that Sarah can  
confide in you.

Rob
---

On Feb 23, 2009, at 12:24 AM, Frederic Hessman wrote:

> Here's a very good role for a simple VOEvent vocabulary:
>
> <Param name="PJ97T030" type="voe:MPCephemeris">PJ97T030 1998 03  
> 9.3751 ...</Param>
> <Group name="Pluto" type="voe:orbitalEphemeris">
> 	<Param name="q" type="voe:massRatio" ...> ...
> 	<Param name="e" type="voe:orbitalEccentricity" ...> ...
> 	<Param name="i" type="voe:orbitalInclination" ...> ...
> 	...
> </Group>
>
> where MPCephemeris is a narrower concept than orbitalEphemeris.   
> Will have to take a look in detail, but all of this (with the  
> probable exception of MPCephemeris) is already in IVOAT.  This  
> solves Petr's problem with the parsing of designations, e.g.
>
> 	<Param name="inclination" type="voe:orbitalInclination" ...>
>
> would be just as good - this is the whole point of using an official  
> vocabulary.  If VOEvent wants to keep the bytes trimmed, then
>
> 	<Param name="i" type="voe:orbi" ...>
>
> (and "voe:orbq", ....) would be just as good - this is for machines,  
> not poets.
>
> I suggest that everyone submit the "names" they have been using for  
> their own parcels so that we can construct an official VOEvent  
> vocabulary that can immediately be mapped to IVOAT/IAU93/..... and  
> hence made officially identifiable.    This would be a great goal  
> for VOEvent 2.0.
>
> Rick
>
> P.S. Does the current schema allow <Param>value</Param> or must one  
> use attributes?  Wouldn't this be a good change?  I personally find
>
> 	<Param name="blah" unit="furlongs">1.234</Param>
>
> much clearer than
>
> 	<Parram name="blah" unit="furlongs" value="1.234"/>
>
> since the content is emphasized.   Would this be an official change  
> in the direction of clearer structures and content?
>
>
>>> I'm a KISS Principle guy. The MPC has standard formats for  
>>> numbered asteroid and
>>> cometary elements already, the so-called "1-line" format(s).  
>>> Everyone knows what
>>> these are, how they are formatted, and what units they are in.  
>>> They've been
>>> around for many years. MP versus cometary can be determined by  
>>> inspection. So
>>> something as simple as
>>>
>>>  <orbitalElements>K01FI5V  7.7   0.15 K014L   0.10308 ...</ 
>>> orbitalElements>
>>>  <orbitalElements>    PJ97T030  1998 03  9.3751  ...</ 
>>> orbitalElements>
>>>
>>> would carry everything there is to know about the elements. If  
>>> only the number
>>> or designator is given, that could automatically reference the  
>>> MPC's orbital
>>> elements database. That would provide the "latest" elements if  
>>> that were
>>> preferable (maybe you want to specify the elements that WERE used  
>>> and not the
>>> elements TO use). So
>>>
>>>  <orbitalElements>K01FI5V</orbitalElements>
>>>  <orbitalElements>0029P</orbitalElements>
>>>
>>> Now what about NEOs which have only a rough short-arc orbit, and  
>>> for which there
>>> are no elements available? I've successfully used the MPC's "NEOCP  
>>> Ephemeris"
>>> format. Needless to say, the position of an NEO is not well known  
>>> very far
>>> ahead, so this would apply only to timely observations in response  
>>> to a VOEvent.
>>> In that case, some ephemeris lines covering the expected validity  
>>> period of the
>>> event, spaced an hour or two apart, should be "good enough". One  
>>> can do
>>> something like a Lagrange interpolation over that data and get a  
>>> pretty good
>>> position. So something like
>>>
>>>  <ephemeris name="A123456789">
>>>     <pos>2004 10 27 02    01.6915    -40.095</pos>
>>>     <pos>2004 10 27 03    01.6834    -40.167</pos>
>>>     ...
>>
>
>> Perhaps we can use the existing VOEvent structure, with no need to  
>> add any extra schema (see below). The Group type (eg ="ephemeris")  
>> tells the software what Params to expect inside. Everything can be  
>> represented with what we already have!
>> ----------------------------------
>>
>> <What>
>> <Group name="Pluto" type="orbit">
>> <Param name="q"             unit="AU"  dataType="float"  
>> value="123" />
>> <Param name="e"                        dataType="float"  
>> value="123" />
>> <Param name="i"             unit="deg" dataType="float"  
>> value="123" />
>> <Param name="node"          unit="deg" dataType="float"  
>> value="123" />
>> <Param name="time_peri_MJD" unit="MJD" dataType="float"  
>> value="123" />
>> <Param name="arg_peri"      unit="deg" dataType="float"  
>> value="123" />
>> <Param name="epoch"         unit="MJD" dataType="float"  
>> value="123" />
>> <Param name="src" value="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  
>> 18 19 20 21" />
>> </Group>
>>
>> Then we would add geocentric ephemeris
>>
>> <Group name="E012" type="ephemeris">
>> <Param name="ephem_type"                              
>> value="geocentric"/>
>> <Param name="ra"         unit="deg" dataType="float" value="123" />
>> <Param name="dec"        unit="deg" dataType="float" value="123" />
>> <Param name="mjd"        unit="day" dataType="float" value="123" />
>> </ephemeris>
>>
>> And the detections used to derive the orbit
>>
>> <Group name="D023" type="detections">
>> <Param name="ra"  unit="deg" dataType="float" value="123" />
>> <Param name="dec" unit="deg" dataType="float" value="123" />
>> <Param name="mjd" unit="day" dataType="float" value="123" />
>> <Param name="obscode"                         value="123" />
>> </Group>
>> </What>