VOUnits RFC

[Marco Molinaro]

Hi everybody,
sorry if I look repetitive, but I'm trying to clear up my own ideas while
giving my small contribution to this conversation.

2013/7/31 Markus Demleitner <msdemlei at ari.uni-heidelberg.de>

> Deferring unit validity (as opposed to well-formedness, which I'd
> define to mean here "parseable with the top-level grammar with
> arbitary unit strings") to the "application level" and at the same
> time disallowing scale factors make that migration goal murky at
> best.
>

I can see a growing complexity in letting unknown_units be validated and
managed at user's layer.
Complexity due to the need of using some support service to 'convert' them
to standard units that will allow data to be interoperable.
It will also be a problem because support services need to be maintained in
a way applications can trust them on the short and long term.

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.


> A simple example where that's necessary: SED building.  If you can't
> parse the unit strings of both the flux and the spectral coordinate,
> that just won't work.  True, the data models try to work around this
> by limiting the units allowed there ("application level"), but,
> really, I'd much prefer if VOUnit were enough to build a tool that
> can do this regardless of whether we're talking about spectra,
> images, or camboodles.
>

I agree unknown_units here complicate things, but uncertainties are
important also in this example and rounding or messing up with
scale-factors will not help.


> It's not so much about conversion as about keeping VOTables a
> superset of FITS binary tables.
>
> I'd be happy with this, except I don't think the complexity of the RE
> matters much, and thus
>
> [+-]?(\d+\.?\d*|\.\d+)([eE][+-]?\d+)?
>
> wouldn't hurt anyone and reduces surprising validity problems
> significantly.
>

I do agree that the case sensitiveness on 'e' will not be a problem.
I wonder what happens to the '10x'-s actually existing, if we are
considering the intersection of existing standards.


> >   * I think it would be good to include language in the spec that
> >   deprecates this in most cases, as OGIP does, for example; and
>
> If you absolutely must; however, I'd still much more like easily
> computable units, so I'd much rather deprecate the unknown units.
>

I think I'm on a position where I like the generic float scale-factors but
without deprecating unknown units.
What if you exclude the possibility of having a costum symbol for Planck's
constant, how will you deal with kpc/h values? using a scale factor for the
h?


> >   * I think it's still necessary to permit 'unknown units' to deal
> >   with the 'jupMass' case.
>
> This discussion has shown that there's probably no way around it.
> It's clearly destroying my use cases, but since...
>

Here's where I don't agree with Markus. I think we can live with both, and
the below (b) point will be the one that will define in the future which is
the best solution.
Maybe data providers will go for full-SI units, maybe jupMass will be
highly used for exoplanets; excluding now one of these two capabilities
does not make sense to me.


> (a) I currently have nothing to offer that would cover the use cases
> behind this, and
> (b) here's to hoping that the data providers will like the automatic
> convertability well enough that they'll restrict themselves to "known"
> units whenever humanly feasible...
>
> > Would people here agree about the importance of this use-case, and
> > this as the resolution?
>
> ...you'd have my agreement.
>

I don't know if my position is in agreement or not.
Just one last thing: how VOUnits will consider the unit string "kpc/h" I
used above? Will the app parse it and consider it completely unknown? Or
will it consider the '/' and then kpc valid, and search only for that
strange 'h'? (Of course this falls if unknown_units are deprecated).

Cheers,
       Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20130801/f9ca70b3/attachment-0001.html>