VOUnits RFC

[Frederic V. Hessman]

On 1 Aug 2013, at 14:48, Marco Molinaro <molinaro at oats.inaf.it> wrote:

> On the opposite, generic float scale-factors can be parsed and used as are, if we strictly mandate standard units and symbols.
> But relying only on generic float scale-factors has a problem on scale-factor calibration and time-variability that can only in part be solved, e.g. the uncertainty on the scale-factor may be negligible once considered in combination with an error bar for the observable. Of course there are cases where this latter assumption will not work.
> Also, using float scale-factors can make it easy to compare quantities but it has some problem in comparing units.
> 
> If I say my weight is 1 in units of 'MarcoWeight' I have a problem at application level, the app has to search for 'MarcoWeight' and translate it in kg (e.g.).
> If I say my weight is 1 in units of '8.4e+1kg' the application is happy during conversion but is not able to find if unit '8.4e+1kg' is equal, comparable or different from unit '8.41e+1kg'.
> 
> The example is stupid but I think it is all around similar things we are discussing.

No, the example is exactly what we're worrying about.

Isn't the point that
	- the standard is for now AND for the intermediate future
	- we need to (gently) push things in the long-term direction
	- we need scaling now to handle non-SI units which are out there whether one likes it or not
	- simple pre-factor scaling with a standard floating point number is trivially parsed, so no complaints
	- scaling is NOT easily compared with other scalings, so this won't be good enough in the long run; no metadata, no semantics, no embedded context to help out
	- unknown_units are easily parsed
	- since the VO is intrinsically networked, looking up unknown_units is not a big deal unless you're reducing data on a desert island
	- providing simple translations of unknown_units into scalefactors and SI units  is not rocket science (google already does it for millions)
	- providing semantic contexts for units would not be difficult in the intermediate future  (though it does need to be done)
	- getting a semantic meaning for the unit will let your app deal with previously un-encountered units in the long run
	- keeping a semantic meaning means your data is easier to pass on (sure, you're using 8.4e+1 instead of your colleagues 8.41e+1, but you both know it's a "MarcoWeight")

An example for the intermediate future:

	- your app gets "km/s/h" and sees that "km/s" is close but doesn't know what to do with the rest
	- your friendly units-interpreter-service says:
		- "km/s" is trivial and undoubtedly the best guess
		- "h" could be
			- "hour", generic context
			- "Planck's constant", generic physical context, not often combined with a velocity, but you never know ….
			- "Hubble factor", probably based on the standard "h_100" scaling, cosmological context
	- your software knows you're reducing Type Ia supernova spectra, and guesses from the semantic context you want a hubble factor.

No, we don't get this functionality now, but we get this later, because all of the groundwork is already laid.

Rick