A modest proposal for VOEvent

[Frederic Hessman]

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>