features for VOEvent v2.0

[Lynne Jones]

On Apr 7, 2010, at 3:33 PM, Matthew Graham wrote:

> Hi,
> 
> On Apr 7, 2010, at 2:56 PM, Roy Williams wrote:
> 
>> Lynne Jones wrote:
>>> 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.   
>> 
>> The LSST events can include whatever they like as Params. If you would like a parameter called "Eccentricity_Inclination_Covariance", there is no problem at all.
>> 
>> The question that we are chewing in the VOEvent Working Group is whether there should be special schema for orbital elements, meaning an XML element called <Eccentricity>.
>> 
>> In the former case, the author can be precise and idiosyncratic, but a human needs to read the description to find out what it really means. In the latter case, everyone is forced into the same data model that is defined by the IVOA, but the advantage is that different event providers can interoperate without a need for translation.
> 
> Except that there are mechanisms which allow interoperability with the first option as well. If you call your parameter: http://www.cacr.caltech.edu/~roy/myScheme#Eccentricity_Inclination_Covariance and have a human-readable description at that URL that we can interoperate. I can set up a thesaurus that says that "http://www.cacr.caltech.edu/~roy/myScheme#Eccentricity_Inclination_Covariance" is the same as "http://some.other.edu/~any/scheme#eci" and there is no need for a centralised data model.
> 
> 	Cheers,
> 
> 	Matthew


So this would allow users to automatically translate the VOevent description of ephemerides into ephemerides with error bars on the position, but also allow each publisher to generate ephemerides with different error definitions (for example, having 3 sigma error bars vs. 1 sigma error bars on the position). Sounds like that would be workable. 
Presumably the user would have software set up to do that translation for them into something that they would like to read, that is standardized for what they want, that also goes to look up that definition every now and then (perhaps not every time).

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. However, I suppose the number of VOevents that are issued for moving objects are probably lower than the number of events issued for most other types of objects, so without further information, I guess I am ambivalent. 

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

-Lynne




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