ivoa-std / VOUnits

Units in the VO
Creative Commons Attribution Share Alike 4.0 International
0 stars 4 forks source link

Missing units (inconsistencies within the spec) #19

Closed nxg closed 1 year ago

nxg commented 2 years ago

There are a few inconsistencies within the VOUnits spec.

Table 2 (which can be regarded as the master list of known, deprecated, and preferred units mentions that % is a known units in the CDS syntax, only. However Table 14 in Appendix B mentions that % is recognised in the VOUnits syntax, and lists the unit Sun (meaning ‘relative to Sun’) as existing in VOUnits also (this is not mentioned in Table 2 at all).

Questions:

msdemlei commented 2 years ago

On Tue, May 24, 2022 at 05:02:25AM -0700, Norman Gray wrote:

  • Appendix B is noted as informative rather than normative, so there is no formal inconsistency here. However what inconsistency there is, is confusing, so this should be fixed.

Agreed.

  • Should % be accepted as a VOUnits unit? To some extent this ‘unit’ is equivalent to a scalefactor of 0.01 so its acceptance or deprecation should potentially align with issue #18; but it's also very commonly found in practice, and is an actual symbol rather than a standalone number, which would suggest that it could or should be permitted irrespective of the resolution of that issue.

While I'm at this point very skeptical of naked scale factors, on the % I'd pull a "practicality beats purity". We could have a footnote pointing out that "we're aware that % is not a unit but a scale factor, but since 0.01 is such a common scale factor and % has been used so widely to denote it, we're sanctifying this one usage. Don't even think of coming around with ppm and ppb."

On the other hand: if we let % in, what could we reasonably say against ppm? It may not be all the craze in astronomy, but in environmental science they (thank $DEITY) they have a lot more of those than of %.

Oh, dang.

  • Should Sun be accepted as a VOUnits unit? If so, someone will have to explain what that unit represents, and in particular, for example, what its dimensions are.

I'd make this a challenge: "If you think that 'Sun' should be allowed, then make a writeup what machines should do when they encounter 'Sun'". Me, I currently can't really imagine how that actually should work. Sun/m**3 is a density? Sun/s a speed?

     -- Markus
nxg commented 2 years ago

For what it's worth, the QUDT2 units catalogue has some coverage here. This is relevant partly because the Unity library uses a fragment of this, but also because it's quite often cited in standards-type discussions on units, as something which has had quite a lot of careful thought and negotiation put into it.

This does have an entry for ppm, as well as parts-per-thousand, -billion and -trillion, with unit symbol ppm (etc). The other dimensionless things in this catalogue are currencies (obviously out of scope for us), bits, bytes, angular measures, some relatively arcane dimensionless units such as the decade, decibels, and a few weird composite things like ‘cubic decimetre per cubic metre’. It also has ‘Number’ and ‘UNITLESS’ as units (I'm not sure what the distinction is), but neither of the latter two has a ‘unit string’ associated with it.

I'd be inclined to suggest that something can be a ‘unit’ if there's a character or string which denotes it, such as % or ppm. That would seem to accommodate the well-known such multipliers, without opening the door to the confusion that a bare number seems to invite.

nxg commented 2 years ago

Part of this issue should probably be making the standard explicit about which table is the authoritative/normative list of recognised units.

I think that list should be Table 2.

If so, then I/we should check that the tables in Appx.B are not inconsistent with this.

nxg commented 2 years ago

...and other tables in (normative) Sect.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 Tables 4–7) as 'informative'. Even if so, informative sections should be at least consistent with normative ones.

nxg commented 1 year ago

Re % being accepted as a unit: I've just updated the Unity library (see commit) to accept % as a VOUnits unit. Table 2 in this document is generated from this library (see target known-units.tex in the Makefile), so Table 2 will be updated when the next Unity release is incorporated here.

nxg commented 1 year ago

Re inconsistencies: The ‘may’/‘should’ language in Sects. 2.7 and 2.8 seems, on a second examination, to clearly enough indicate what is normative and what is informative. I'm happy to be disagreed with, but propose making no change here.

I've added a general remark at the beginning of Appx.B (see 8905bf6) to say that any VOUnits-related inconsistencies between this section and Sect.2 should be interpreted in favour of the latter.

Re Sun and ppm: there is a noticeable lack of clamour to keep either, so I propose simply dropping these. In which case this issue can possibly be closed.

nxg commented 1 year ago

Correction: In issue #18, Baptiste does explicitly propose including ppm.

nxg commented 1 year ago

Re Sun: there has been no persuasive explanation of what programs should do with a unit Sun, so I here explicitly propose dropping it.

Re ppm/ppb/ppt (and others dimensionless scaling ‘units‘): I don't disagree that these units have been seen in the wild (which is a very respectable argument for including them in VOUnits), but they don't do anything that a scaling-factor doesn't do (and see issue #18 of course), and so, in my perception, only add noise to the spec, and take us away from having % as the only dimensionless ‘unit’ (OK, I'm taking Radians as being dimensionful, which I appreciate is an arguable point).

Given the lack of agitation for these units, I'd like to defer this to an on-list discussion or interop. I'll leave the issue open until then, but propose deeming the other aspects of this issue to be resolvd.