lhncbc / ucum-lhc Goto Github PK

An expression like {g} is a little weird since it seems pretty meaningless (and more often than not I'd expect you'd mean g, grams, rather than {g}, a unitless annotated expression), but it is nonetheless perfectly valid. The validator, however, doesn't seem to think so:

This is even weirder because it seems totally willing to behave correctly in other cases, like {a} instead of a for years:

Hi, can you please include into a documentation how to correctly reference when using ucum-lhc in another open source project? For example when LOINC and UCUM is used, their terms apply which is totally fine. But how to correctly reference this?

Would it be sufficient to have a third party license file containing all license texts/terms-of-service from all references? So the following ones:

• https://github.com/lhncbc/ucum-lhc/blob/master/LICENSE.md
• https://loinc.org/kb/license/
• https://ucum.org/trac/wiki/license

Or would something else be required?
Thanks

In ucum.csv, there might exist a typo in the Guidance for stere:

Typo:
... used for measuring firewoord

Correction:
... used for measuring firewood

First of all, great package! I am not sure if this is the right place to report issue here. But I notice that conversion from MG/ML (usually used in RxNorm, eg. rxcui 861487) to % is giving the incorrect result as

0.5 mg/mL = 50000.00 %

The correct result should be 0.05 %

Thanks!

Hi, are there any plans to provide typescript definition files for this project? Thanks!

For pure UCUM codes I am quite sure that g.m2-1 is invalid. The result in the online validator is g.m2-1 (gram*[meter2]) is a valid unit expression so the parser just drops the -1 part. (related dalito/ucumvert#8)

Or is this a question of the UCUM version? I am wondering because of

g.(m2)-1 (gram*[square meter]) is a valid unit expression.
An exponent (-1) following a parenthesis is invalid as of revision 1.9 of the UCUM Specification. 
Did you mean m2-1?

The UCUM LHC demo interprets mcg as

mcg (millicentigram) is a valid unit expression.

This interpretation is based on multiple prefixes m and c combined with a single base unit g. Multiple prefixes are not allowed per UCUM section 4.2:

The unit symbol to be combined with the prefix must not itself contain a prefix. Such a prefix-less unit symbol is called unit atom.

How to represent gestational age using ucum units

Where to create a UcumLhcUtils object that contains those two functions, from the server side?
var ucum = require('@lhncbc/ucum-lhc');
var utils = ucum.UcumLhcUtils.getInstance();

Thanks!

Regards,
.. Lin

The demo page allows uploading of CSV. It would be a nice addition to state the required CSV format (since CSV is not a formal standard, and quite some variants are used in de practice - standard Excel to CSV export did not work for me).
I got it to work with:

• commas as delimiter (not semicolon)
• all fields double quoted ("ml", etc., not just ml, ...)
• \r\n line ends (Unix style \n did not work)
  Maybe more formats are allowed, but the only way to find out what works now is by trial-and-error.

When using the Validator on https://ucum.nlm.nih.gov/ucum-lhc/demo.html we get the following issue:
According to the provided Unit Expression Syntax Rules it should hold that:
"Parentheses may be used to override normal left-to-right evaluation of an expreession. For example kg/m.s2 divides kg by m and multiplies the result by s2. kg/(m.s2) divides kg by the result of multiplying m by s2." which aligns perfectly with 2.2 §10 "nested terms" from the ucum-specification (https://ucum.org/ucum.html).

Unfortunately i find that a

      kg/(m.s2) evaluates correctly to (kilogram/[meter*[second - time2]]), 
      kg/(s2.m) evaluates to               (kilogram/[second - time2]*meter)

, which seems to be something different. We encountered the problem when validating

      dyn.s/cm5/m2 <=> dyn.s/(cm5.m2).

I thought, that maybe exponents need to be put in parenthesis too, but that did not help either:

      kg/((s2).m) evaluates to             (kilogram/[second - time2]*meter)

In the file unitString.js:
// A regular expression for validating annotation strings.
static VALID_ANNOTATION_REGEX = /^\{[!-z|~]*\}$/;

My Proposal:
Annotation strings should be allowed to contain Chinese characters and like, such as:
{片} ... for {tablet}

Proposed regular expression:
// A regular expression for validating annotation strings.
static VALID_ANNOTATION_REGEX = /^\{[!-z|~\u4e00-\u9fa5]*\}$/;

Validated examples:
{片} ... for {tablet}
{肌酐} for {creat} [ Usage: nmol/mmol{肌酐} ... for nmol/mmol{creat} ]
{蛋白质} for {prot} [ Usage: nmol/mg{蛋白质} ... nmol/mg{prot} ]
...

Maybe this is a proposal for the UCUM Specification per se.

Entering m(/s) in the web-validator gives: m(/s) (1/[second - time]) is a valid unit expression. The "meter" is lost. I would expect that this fails validation.

Another interesting edge case is m.(/s). It passes validation and gives m.(/s) (meter*[1/[second - time]]) is a valid unit expression. - This should probably also fail at least according to

• Syntax in BNF form in the specification
• ucum-state-automaton figure
• formal grammar page

These formal grammars only allow "/" as unary operator at the beginning of a "main term" but not as unary operator of a "term". Interestingly, the written specification only says: The division operator can be used as a binary and unary operator, i.e. a leading solidus will invert the unit that directly follows it. - This is what your code does for m.(/s).

Note- these results were taken from the interactive demo available at https://ucum.nlm.nih.gov/ucum-lhc/demo.html.

Note: Test value deliberately chosen to be challenging/confusing for UCUM but the syntax is correct I believe.

Should the grunt-extract-sourcemap dependency be declared in the development dependencies? Got the following error from npm:

npm WARN [email protected] requires a peer of grunt@>=0.4.0 but none is installed. You must install peer dependencies yourself.

There are unit conversions that require valence in order for the conversion to be correct.

An example would be: Phosphorus which has a valence 5 converting from mmol/L to meq/L.

I'm using Node & Babel, ES6 import is part of my team's coding style guide.

This works:

const ucumlhc = require('@lhncbc/ucum-lhc');
const ucum = ucumlhc.UcumLhcUtils.getInstance();

While this does not:

import ucumlhc from '@lhncbc/ucum-lhc';
const ucum = ucumlhc.UcumLhcUtils.getInstance();

The latter throws the following error:

TypeError: Cannot read property 'UcumLhcUtils' of undefined

Please advise and thank you in advance!

Hi, first thank you for this library.

I'm trying to use it in a new empty node project from scratch, but I'm getting the next error Error: Cannot find module 'is-integer'

After installing it manually I've got the next one Error: Cannot find module '../data/ucumDefs.json'

Looking at the node_modules/@lhncbc/ucum-lhc folder seems the is-integer package is not declared as a dependency in the package.json file and the data folder is missing

Per UCUM 2.1.6.1, "The full range of characters 33–126 can be used within a pair of curly braces (‘{’ and ‘ }’)." However, it doesn't look like the validator throws an error against annotations containing characters outside this range (like spaces and extended ASCII characters):

Note that extended ASCII characters aren't allowed anywhere in UCUM anyway: "All expressions of The Unified Code for Units of Measure shall be built from characters of the 7-bit US-ASCII character set exclusively." (UCUM 2.1.3.1)

Also, thanks for this tool!

In file https://github.com/lhncbc/ucum-lhc/blob/master/browser-dist/ucum-lhc.js
Line 2

https://raw.githubusercontent.com/lhncbc/ucum-lhc/master/browser-dist/ucum-lhc.js

The vast majority of <sup> tags are correctly closed with </sup>, however some are closed with <.sup>

In ucum.csv, there might exist a typo in the Guidance for parsec:

Typo:
..., nad used to measure large distances to ...

Correction:
..., and used to measure large distances to ...

Note- these results were taken from the interactive demo available at https://ucum.nlm.nih.gov/ucum-lhc/demo.html. That page links to here so I assume the version of code running at that URL is essentially the same as hosted here.

Results from running certain test cases through the tool were not as expected. Note these were deliberately chosen to be "challenging " for UCUM given some if it's characteristics (notably not using the same base units as SI) but even so some of these results look wrong.

`

`

convertUnitTo() does not support an input value of 0. Try 0m to km.

e.g.: https://ucum.nlm.nih.gov/ucum-service/v1/toBaseUnits/mPa

To the best of my knowledge the UCUM data definition (ucum-essence.xml) doesn't include synonyms for unit codes, with the exception of a textual name/description and (sometimes) a "printSymbol".

So, where is the "synonym data" drawn from in this implementation to provide the checkSynonyms() function? Is this supplemental data that's been added to the master UCUM file from another source?

In ucum.csv, there might exist a typo in the Guidance for Ampere:
unit of electric current equal to flow rate of electrons equal to **16.2415×10^18** elementary charges moving past a boundary in one second or 1 Coulomb/second

Proposed correction:
unit of electric current equal to flow rate of electrons equal to **6.2415×10^18** elementary charges moving past a boundary in one second or 1 Coulomb/second

Note: This issue specifically refers to the online web service

Given the query URL:

https://ucum.nlm.nih.gov/ucum-service/v1/toBaseUnits/mmol/L

The response is:
<UCUMWebServiceResponse ServerDateTime="2018-11-26T16:11:55"> <WebServiceRequest> http://ucum.nlm.nih.gov/ucum-service/v1/toBaseUnits/mmol/L </WebServiceRequest> <Response> <SourceUnit>mmol/L</SourceUnit> <ResultBaseUnits>mol.m-3</ResultBaseUnits> <ResultQuantity>1.0</ResultQuantity> <ResultBaseUnitsList> <BaseUnit Name="mol" Exponent="1"/> <BaseUnit Name="m" Exponent="-3"/> </ResultBaseUnitsList> </Response> </UCUMWebServiceResponse>

I believe the ResultQuantity should be 1000 (or 10^3) in this case, as 1mol/L == 1000mol/m^3