Re: [Gnumed-devel] the state of test measurement storage and display in GNUmed

[Busser, Jim]

On 2013-11-27, at 1:03 PM, Karsten Hilbert <address@hidden> wrote:

> On Wed, Nov 27, 2013 at 08:46:19PM +0000, Jim Busser wrote:
> 
>>> Changing the column name is out of the question for 1.4
>>> as it would change the API (and the hash which checks
>>> to API stability). Doing so would require extremely
>>> good reason. Linguistics-du-jour are not.
>> 
>> Before further responding to the "Linguistics-du-jour …"


I enjoy assuming it was good natured and meant to emphasize on-list how it 
should have to be something really critical (broken or patient endangering) to 
justify to make a change to a column name inside a release cycle (if at all), 
which BTW I wasn't actually asking for.

OTOH if I too-often post things that needed self-filtering, I'll appreciate 
some kind informing on that.

Meantime, when we have such situations as a mismatch between what something is 
called in the GUI

        Base unit

and what it is called in the backend

        conversion_unit

this can make it hard for anyone (other than maybe Karsten) attempting backend 
data analysis and data correction / standardization to manage these tasks.  Any 
difficulty to locate what we were looking for can confuse us into thinking we 
misunderstand something (which is already often enough the case). Accordingly, 
closing out the need to look for (non-existent) alternate explanations is 
beneficial when there is little or no downside.

Where -- as in this case -- the GUI and backend names remain mismatched, it 
might be helpful if these can be cross-referenced (each in the other) among 
{tooltip ; sql description}

As far as what if any GUI label might be an improvement, the suitability of 
"Base" is IMO limited to scenarios like

        1000, 100, 10, 0.1, 0.01 (--> Base 10)
        miles, yards, feet, inches (--> Base inches)

whereas what we more want in this column is a chosen / desired

        unit of aggregation /

        unit of common expression

        reference unit

        unit of standardization and normalization

and out of the above, I suspect

        Standard unit
or      Standard units

could be a better choice.

Note: while it is true that any praxis could make an arbitrary (non-standard) 
choice and designation for their "unit", they should probably be wanting to 
conform to some kind of local or regional standard where an international 
standard is either unknown or locally irrelevant.

-- Jim