features for VOEvent v2.0

[Roy Williams]

Hey Lynne, thanks for starting this discussion!

 > I would like to see orbital elements and ephemerides allow for 
uncertainties in the elements and in the
 > ephemeris predictions. I don't know if that has already been thought 
of, but I know the most common source
 > of ephemerides at the moment (the MPC) often doesn't include an 
ephemeris error, so thought it might be
 > worth mentioning.  


This makes it difficult to know how to make an IVOA-sanctioned model for 
an ephemeris. Some people think it should include complex error domains, 
others want the simplicity of uncorrelated errors, or even with no error 
estimate at all.

> The orbital elements would allow different types of orbital elements 
> too, right? (like an a/e/i/node/arg_peri/mean_anomaly/epoch set  vs. a 
> q/e/i/node/arg_peri/time_peri/epoch set of elements).  There are 
> several different standard sets of parameters, but for a complete set 
> there are several required elements - seems like a natural fit for an 
> XML schema, rather than params.

That is true for well-agreed data types, there could be galleries of 
schema and automated semantic lookup, managed by the LSST MOPS group, 
which define the data model. Special schemas for special tasks. It is 
very difficult to change these once they are in use. If LSST does not 
want to be responsible for the schemas, the IVOA will have to it, but 
they must try and find agreement between most providers -- a lengthy 
process.

The Param and Group structure is for authors who wish to work at the 
level of keyword-value pairs, albeit each with rich semantics.  It is 
like building a FITS header. There is fast startup, simplicity, 
locality, and flexibility for authors. If you have a telescope that can 
do ABC filters, you make a set of Params named Amag, Bmag, Cmag and you 
are done. You do not register a standard schema with a registration 
authority.

One of the often unsaid problems of the schema approach is the idea that 
it solves all validation problems. If you get a gas bill for $1,000,000, 
then you know it is bogus, even though it is syntactically correct, the 
amount is a floating-point number. So there always needs to be 
validation code added, even for automatically-generated code.

> One question - how is the line drawn to decide whether it is better to 
> have a param where users go look up the definition of the param vs. 
> having an official XML tag for a value? (sorry if that is a silly 
> question .. I have a feeling that is actually what all the discussion 
> is about, but I don't know what goes into weighing that decision - is 
> it how often users will need to access the value in software or is it 
> something like standardized definitions exist so should be used?)

The XML mechanism is a good fit for automated validation, code binding, 
etc, and implies the infrastructure to support it. The Param mechanism 
is for quick start and concentrating on the meaning first. Once the 
names of the Params are defined by the Designated Community, the XML 
schemas can replace them. For myself, I do not know how to combine 
schemas from different sources in a reliable way -- I mean the VOEvent 
schema from IVOA and the orbitalElementBayesian schema from LSST MOPS.

Roy

-- 

California Institute of Technology
626 395 3670