PropertyUnitData.xml and conversion information

Continuing the discussion from Invalid UCUM units in Archetype Designer:

The PropertyUnitData.xml file is important to Archetype Designer as a way to specify which units are valid and available. However, the file also contains a lot of information about conversion factors between units, much of which is erroneous and/or imprecise.

This information was probably important to maintain when this file was first created, but now there’s a maintained JS library for doing conversions, as well as validation of UCUM expressions.

I suggest we remove the conversion information from the file, and point to the ucum-lhc library for doing conversions.

1 Like

Interesting library :wink:

Who is more entitled to give feedback here? @borut.fabjan what do you think on this proposal?

I would not dare to take sights on whether we should remove it - I would to listen to what AD or CPB needs. The only “issue” I see is the library you mention is in JS, whereas the rules we have are in XML - so a bit more tech-language-agnostic.

1 Like

Also, a few conversions are more complicated than just a conversion factor + coefficient. The information provided to convert °Fahrenheit to °Celsius is simply not sufficient for example.

Graeme (and probably others from the fhir camp) have done lots of good work on this:

There is a ucum_essence file Ucum-java/src/main/resources/ucum-essence.xml at master · FHIR/Ucum-java · GitHub

and services based on this to e.g. validate and convert.

For a few units, conversion requires special handling and is managed in special handlers, e.g. Ucum-java/src/main/java/org/fhir/ucum/special/CelsiusHandler.java at master · FHIR/Ucum-java · GitHub

To me openEHR’s property units file is mainly relevant to list common units + properties and groupings and as such is probably useful for some tools.

Conversion cannot be reliably done based on this file in all cases, even if we fix the errors.

So, I agree with Silje that this (mis-)information is best removed as ‘beyond scope’ and we can point to the JS lhncbc/ucum-lhc lib and the FHIR UCUM Java lib as well where needed.

2 Likes

Thanks @sebastian.iancu and @sebastian.garde!

Another potential direction could be to strip the PropertyUnitData.xml file not only of the conversion information, but also of all the base (“primitive”) units and properties, and point to ucum-essence.xml for this information. This would constrain our xml file to only the compound units and properties we need to maintain to be able to use modelling tools efficiently, leaving it a fraction of the size and much more maintainable.

Ok clear; we could do this.
But we’ll need AD to adapt to it, as perhaps it is being still in use somewhere. Would it be ok @borut.fabjan ?

1 Like