VOunits draft

[Rob Seaman]

Hi Alberto,

> 1.- What's wrong with saying that 1 Mpc is just 3.08568025E+22 meters?

As Steve Allen pointed out:

>> Consider the issue of AU vs. m
>> AU is not SI.  m is SI, but beware
>>
>> 1 AU = 149597870691 m in TDB/TT units ("not SI" units according to  
>> IAU comm 52)
>> 1 AU = 149597870795 m in TCG units (IAU recommended for vicinity of  
>> earth)
>> 1 AU = 149597873011 m in TCG units (IAU recommended for solar system)
>>
>> Every application I know currently uses the "not SI" TDB/TT units.

The parsec is directly related to the astronomical unit (1 parsec =  
180*60*60/pi AU), so this issue applies to Mpc as well.

> Still, to be exact, the VO could declare that
> - the original representation was in Mpc
> - the precision stopped at the integral part of the Mpc.
> - a VO distance is always internally expressed in meters,
> - the VO conversion factor for (e.g.) Mpc is 3.0whateverE+16.)

That makes several new pieces of metadata just to preserve the  
original representation.

> 2.- Why do we need Zettameters? Why do we need SI prefixes?
>
> Is the E+22 formulation too simple and general to be acceptable?

I'm getting more confused about what is being suggested.  Are we just  
talking about the mantissa and exponent of floating point numbers?  Or  
is the suggestion that we have an explicit string representation for  
scientific notation?

In general it seems like this discussion has devolved into haggling  
about details of a proposed solution, when the requirements describing  
the problem space have yet to fully discovered.  I actually find yotta  
and yocto, zetta and zepto as charming as the Marx brothers they  
resemble.  Is "charming" a requirement on the VO?

While folks are discussing prefixes, note that centi, deci, deka and  
hecto are irregular and limited to certain cases, the centimeter being  
the most familiar.  The other cases are apparently areas (hectare =  
sq. hm) and volumes.

> 3.- It is up to the user to ultimately decide which units are  
> relevant to him.

VOEvent simply needs a method for accurately tagging the units as  
provided by event authors.  Perhaps this standard doesn't pertain to  
semantic usage as required by VOEvent?

> PS: I'm not forgetting the fact that all servers will probably have  
> to perform a conversion from the originally stored unit to the VO  
> standard one, but given that my client will have to wait for the  
> various streams coming from those different servers, that little  
> overhead introduced by the conversion will have less impact overall.

Perhaps the VOEvent brokers/clients sit outside the system  
encompassing the standard?

Rob