features for VOEvent v2.0

[Matthew Graham]

Hi Lynne,

If it's an official XML element (<eccentricity>) then this can be encoded into an XML Schema and VOEvent packets can be validated against the schema to make sure that they have this element (if it's mandatory). You can specify in the schema what data type the value of element should have (integer, float, particular string) and limiting values for ranges. So the syntax is perfectly well described but the actual meaning of the element is not. You can put descriptive text in the schema to say what you mean by this term but it's not the easiest thing to read. 

On the other hand, if it is a parameter with the name "eccentricity" then all the XML Schema will specify is that there must be an element called <Param> which has certain attributes such as name, unit, ucd, etc. From the schema, there is no way to validate that the specified value is syntactically correct since it is just dealing with another "Param". The value of a Param called "eccentricity" could be set to "Harvard professors" but the schema would still validate it. On the other hand, the name of the param could be a reference to something explaining exactly what it means as I described in my previous mail.

The loose-form Param is what we currently have in VOEvent 1.1. Adopting a naming convention for Param names does not change the VOEvent schema. Adding <eccentricity> will change the schema and mean that software will have to cope with VOEvent 1.1 packets and VOEvent 2.0 packets.

	Cheers,

	Matthew



On Apr 7, 2010, at 4:03 PM, Lynne Jones wrote:

> 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/46e84f55/attachment-0001.html>