VOUnit for solar density or metallicity?

Norman Gray norman.gray at glasgow.ac.uk
Wed May 25 18:47:19 CEST 2022


Tom, hello.

On 25 May 2022, at 16:40, Tom Donaldson wrote:

> Thank you for the responses!  I think I am content with continuing to use Sun as the most reasonable available unit to describe the FIELDs we have, but I am less clear on why it would be considered valid according to the standard.
>
>>  Sun is a valid vounit symbol. It is described in the current Recommendation, and this
>>
>>  should not change in version 1.1 currently in preparation. The problem comes from the
>>
>>  validator that ignored Sun, but this should get fixed, see :
>>
>> https://heptapod.host/nxg/unity/-/issues/11<https://urldefense.com/v3/__https:/heptapod.host/nxg/unity/-/issues/11__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0C37XentP6REz1B5JpwoHuwQX6BYnX6-RUFiwlrFqMrpjaGG3s9iZpejm7qfPwwfoyVpyN8bKvrduzFJYMfRBJHzQu6Qc2LBgKed$>
>>
>  My reading of the document is that Sun appears in Tables 5 and 14.  The wording around and within those tables does suggest that it is a VOUnit.  However appendix C.4, which is the normative definition of the grammar, does not refer to either of those tables so would seem to say that Sun could not be recognized by the grammar.

Ah yes, it does appear in Table 5, too (Sect.2.8), and almost all of Sect.2 is normative.  That's definitely an error.  I'm fairly sure I have unit-tests in Unity that were intended to match these tables, but either I wasn't sufficiently systematic about assembling those, or else the table changed after the test-cases were written, and one way or another I omitted 'Sun', at least.

(The test cases are at <https://heptapod.host/nxg/unity/-/blob/branch/default/src/grammar/testcases.csv> , which isn't actually quite a CSV file, and is in a home-made format which prefers density over legibility *cough*).

So it's a straight inconsistency that 'Sun' is normatively present in Table 5 and normatively absent in Table 2.

A problem here is that Sect. 2 is a mix of specification and commentary.  Perhaps we should mark Sects. 2.7 and 2.8 (and contained tables) as 'informative'.  Even if so, informative sections should be at least consistent with normative ones.

>  I note that essentially all of the other units mentioned in Table 5 are also present in Table 2 which is referenced by the grammar definition.  Was Sun left out of Table 2 on purpose or an error?  Should C.4 have referenced more tables?  (or most likely, am I just misreading the document?)  Although all of section 2 is labelled “normative”, and section 2.8 contains Table 5, the wording there is just ambiguous enough to me that if I were implementing a validator I would probably favor the more explicit appendix C.4.

Agreed, and the first paragraph of C.4 was indeed intended to be read as excluding everything other than Tables 2 and 8.

So Sun was indeed left out of Table 2 both accidentally and on purpose.  I meant to leave it out, but also meant to raise on-list the question of whether it should go back in, but accidentally forgot (apologies, all!).

I've added to the document issues list at <https://github.com/ivoa-std/VOUnits/issues>

>  I’m not just asking to be pedantic (and to decide whether to surround our Sun with single quotes).  It turns out that astropy’s VOUnit validation also does considers Sun to be unknown (but does recognize all the other units in Table 5 that are also in Table 2).  Before starting an issue or PR with astropy regarding Sun, I want to make sure that it is indeed “officially” recognized by the standard.

'Pedantic' is my middle name.

So this means I now have two suggestions:

  1. We decide that 'Sun' either is or isn't a 'known unit'.
  2. We mark Sects. 2.7 and 2.8, and Tables 4--7 as 'informative' rather than normative (but still make them consistent with Table 2).

Re astropy's VOUnits validation: is that <https://kbarbary-astropy.readthedocs.io/en/latest/_modules/astropy/units/format/vounit.html>?  It has occurred to me to add a Python version of the Unity library, alongside the Java and C versions.  A basic implementation, with the same limited functionality as the C library, would be fiddly rather than hard.  Do you think that would be of interest to anyone?

All the best,

Norman


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK


More information about the semantics mailing list