Re: [Gnumed-devel] Measurement conversion concepts

[Busser, Jim]

Further on this, I was wondering about the method of lookup / linkage to a 
conversion table… I gather these involve

        public.basic_unit (name_short, name_long)
        public.unit (fk, name_short, name_long, factor, shift)

Is it intended that

        public.basic_unit involves only these:

                http://www.unc.edu/~rowlett/units/sifundam.html

        ?? and what of things like prefix handling?

Here are some scenarios:

(1) involving shift -- I can think only of Fahrenheit and Celsius which would, 
in public.unit (not ref?) be

        (fk to F)       C       Celsius 1.8     32

        (fk to C)       F       Fahrenheit      0.55    -32

but noting that while the first conversion depends on a natural order of 
operations

        C ---> F = C x 1.8 + 32

going the other way, one must do

        F ---> C = (F - 32) x 0.55 requiring parentheses

i.e. they are not symmetric. This case maybe has to be individually provided 
for in whatever is the converting function. Is this an isolated case, or is 
anyone aware of any other biological measurements that involve (require) a 
shift?

(2) general cases where the measurements are what I will call "substrate 
independent", for example in expressing a length … in the following example of 
row population, I have omitted long names:

        (fk to cm)      m       100     0
        (fk to cm)      mm      0.1     0
        (fk to cm)      in      2.54    0
        (fk to cm)      ft      30.48   0

… these can all share the same conversion factors without any need for each of

        test_type.conversion_unit (where name = height)
        test_type.conversion_unit (where name = abdominal circumference)
        test_type.conversion_unit (where name = aortic aneurism dimension)

but do we require multiple sets of such rows, one set of 4 values where we 
rotate in

        public.basic_unit in {mm, cm, m, in, ft) keyed from a set of 4 rows in
        public.unit {one row each for the other 4 among mm, cm, m, in, ft}

??

and also do we need each item in public.basic_unit to *also* appear in 
public_unit with a conversion of 1 ("unity")?

(3) in the case of derived units, consider

        hemoglobin (mg / dL --> g/L)

        … should there be a value in public.basic_unit

                g/L

                with matching values in public.unit {g/L, mg/dL}

        … or should each component in the expression

                        mg and dL

        have to resolve to components in public.basic_unit

                        mg to g
                        dL to L

        and then be multiplied through by the component factors?

(4) what about when the units in question are substrate-dependent and involving 
things like molecular weights and valences

        mg/dL vs umol/L Calcium vs 1 mEq

        http://sitemaker.umich.edu/tutorial/files/handout_milliequiv.pdf
        http://www.unc.edu/~rowlett/units/index.html

-- JIm