VOUnit encodings

[Chalk, Stuart]

Norman

Thank you for the comments and context of the decision about allowing unknown units.  Clearly the IVOA community went through a thoughtful process and came out with a solution that works for its use cases.  For me, this domain perspective on units is very useful as I work on the units website I mentioned, so I appreciate the feedback.

Thanks again,
Stuart

> On Jul 27, 2018, at 6:53 AM, Norman Gray <norman at astro.gla.ac.uk> wrote:
> 
> 
> Stuart, hello.
> 
> On 26 Jul 2018, at 13:45, Chalk, Stuart wrote:
> 
>> I am surprised that there is a tolerance for unknown units.  Do you think that the community would ever re-evaluate this decision?  It would be much better if the parsers would flag an unknown unit as such and provide suggested units.
> 
> I think a reevaluation of that would be unlikely, now.  As I recall, the issues included:
> 
>  * The VOUnits activity had a fairly modest goal, to codify and tidy current practice: there were three or four 'unit specs' in circulation, none of which were completely precise.  For that reason, it didn't aim to add any restrictions that weren't absolutely necessary.
> 
>  * I don't think the IVOA felt it was in a position where it could, or even should, demand people rework their data releases.  'IVOA tools reject my data because of the unit strings?!'  Big wow.
> 
>  * Having a specific list of approved units would mean that there'd be a never-ending process of adding to that list.
> 
>  * Consider the unit 'jupiterMass'.  If that's the natural mass scale for the data you're releasing, then it's arguably inconvenient to you _and your users_ to have to use this instead in units of 10^{silly}.  Also, is 1 'jupiterMass' just an alias for some number of kg, or is it a calibrated/derived/notional mass in your particular dataset?  Both are reasonable, but only one could be the standard.  And does that also imply defining uranusMass, neptuneMass, nibiruMass, ...?
> 
> There are multiple responses to those, but those were the points of discussion.  The conclusion was to require 'vounit-compatible' unit strings to have a standard syntax, but to permit unknown units within that syntax, even though they may be misparsed (my pet example: a 'furlong' is a femto-'urlong'), as long as it is possible for the unknown units to be algorithmically identified.
> 
>> This becomes an important issue when you take into consideration the current move toward FAIR data (https://www.go-fair.org/) where the expectation is that FAIR data can be reused by other researchers and thus needs (in part) to have standardized units.
> 
> It's opening up a larger discussion, but having units in a standardised syntax, and even better using standard units, is a good thing, and certainly removes one of the possible barriers; however using someone's data without reading the release notes or other documentation is probably reckless.  Any decent data-release documentation is going to discuss the units being used in the data.
> 
> I should have mentioned earlier that there's significant overlap between the qudt.org set of units and the VOUnits ones (though we did have to add some astronomy units which weren't in the _long_ list of QUDT ones).
> 
> All the best,
> 
> Norman
> 
> 
> -- 
> Norman Gray  :  https://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK