VOunits draft

[Hervé Wozniak]

Hi all,

Le 27/05/2009 01:38, Alberto Micol écrivait :

...
>> Bear in mind that the distance estimate may be accurate only to +/- 
>> 50% and may scale with the hubble constant...
> Exactly, any astronomical (hence physical) quantity has got an error, 
> there is no point
> in transmitting information with higher precision than what the error is.
> 
> Hence, to answer your question:
> 
> 1.- What's wrong with saying that 1 Mpc is just 3.08568025E+22 meters?
> 
> {
> or even just 3.086E+22 given that 1 Mpc is essentially not the measured 
> value,
> but a rounded version of it, and if you want to get back the number in Mpc:
>  3.086E+22 / 3.08568025E+16 = 1.001 Mpc is well within the error.
> 
> 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.)
> }

May I remember all that a distance (and many other quantities) is 
(hopefully) not measured within a +/- 50% in a numerical simulation! :-)

For a given uncertainty in the original data (observational and 
simulated), what is acceptable as an error level is ultimately under the 
responsibility of the final user. So, we must provide him/her all the 
information to estimate this final error, that might be different from 
the original one (higher or equal to the original one).

> 
> 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 guess we cannot avoid SI prefixes. Mpc is an example of the SI 
prefixes used for a non-SI unit.

> 
> 3.- It is up to the user to ultimately decide which units are relevant 
> to him.
> If the original datum is stored in Mpc, but the astronomer wants to 
> express it
> in units of milky way diameters, it is up to her to do so.
> The mere fact that the original number was in Mpc does not mean that the
> user will use it in Mpc. So it does not matter what unit is used on the 
> wire. The client
> will have to translate it anyway to what the user wants (e.g. "milky way 
> diameters").

I fully agree with the first part, but not the second. The units used 
for the communication between the various 'internal' VO interface 
(invisible for the final user) should maintain the quality of the 
original data as much as possible. Imho, the choice of the unit system 
for internal VO communication is part of an interface specification.


> 
> More importantly...
> 
> 4.- The world is much more heterogeneous than any example I have seen on 
> this mailing list.
> If we take one example, just ONE of them, wrong conclusions are to be 
> derived.
> Mpc seems simple to handle if you look at one and only one service...
> 
> In the VOSphere (as Sebastien Derriere calls the environment where VO 
> lives)
> answers from different services will have to be combined, and if each of 
> those services
> talk different units, the first thing the application/user will have to 
> do is to
> convert them all to the same unit (e.g, the milkyway diameter unit).
> That is the client will have to know how to translate all input units to 
> the user's required
> unit (probably first going to some common intermediate unit).
 >
> Much easier if all those services already answered all using the same 
> agreed (on-wire) units.
> The client will have less to do (nothing to interpret), hence less 
> errors will be introduced,
> and the overall system will be more performant.

I fully agree. Does the user has also to define the 'common intermediate 
unit' or is a task of the VO to define it? In my opinion, the point is 
there.

> 
> 
> Alberto -- just back from the nice banquet
> 
> 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.
> 
> Maybe more clearly:
> A client queries N servers:
> The server side workload is shared among all the N queried servers, 
> while the client would have
> to do it all by itself.
> 
> 
> 

-- 
Herve WOZNIAK

Astronome
Observatoire Astronomique de Strasbourg
UMR 7550 Universite de Strasbourg - CNRS
11, rue de l'Universite, F-67000 Strasbourg

Tel/Phone : +33 3 90 24 24 45   Fax : +33 3 90 24 24 32

mel/mail : herve.wozniak at unistra.fr skype : herve.wozniak

http://herve.wozniak.fr/