Symbols for case sensitive and case insensitive units overlap for different use cases

[timbrisc]

Issue migrated from trac ticket # 5810

component: unit definitions | priority: major

2022-05-10 23:58:53: [email protected] created the issue

---

I am currently working on adding support for case insensitive units to my implementation of UCUM. According to the specification document, case sensitive and case insensitive unit symbols may not be mixed (e.g. g/HR is not a valid UCUM unit). There exist quite a few units that share the same unit symbol for both the case sensitive and the case insensitive variant which is not an issue as they still refer to the same unit or use case (e.g. [AU]).\

In my implementation I initially wanted to incorporate the case insensitive symbols into the existing processing pipeline assuming that the symbols used for each format are distinct except for the special cases that match up for the same unit. A problem occured when I verified wether the two sets of unit symbols actually are distinct apart from the aforementioned special cases. The following unit symbols are shared across the case sensitive and case insensitive entries in the UCUM Essence file and describe different units or use cases thereby introducing ambiguity when evaluating unit terms:\

S -> Siemens (c/s) and Second (c/i)\ [G] -> Newtonian constant of gravitation (c/s) and standard acceleration of free fall (c/i)\ G -> Gauss (c/s) and Gram (c/i)\ RAD -> radiation absorbed dose (c/s) and radian (c/i)\

This is unfortunate seeing as all other unit symbols are distinct when they describe different units or use cases and although mixing the different formats is not allowed, keeping the two sets of unit symbols separate from one another for future iterations can help to streamline UCUM libraries/APIs and the processing of units by not having to specifically accomodate these (currently) four units when generating display names, converting units and verifying their validity.