## 3 Results
### Mapping LOINC to UCIM  
Having explained the fundamentals of generating the base unit representation for a given UCUM unit, we want to now present the results and some more thoughts on formalizing the relationship between LOINC and UCUM. In order to establish a mapping between the two standards, the subset of _Properties_ that conformed to the quantitative _Scale_ axis was used to formulate a base unit representation for each entry. The process of formulating such a representation incorporated the following steps:  
1. Check the official LOINC data set to see which example units are associated with a certain _Property_;
2. Verify if they are consistently commensurable across all entries;
3. Compare the example units to keywords in the LOINC guide to see if they line up semantically. If there were no example units given for a _Property_, we formulated an example based on keywords in the LOINC guide. A \"Mass Concentration\" should reflect the fact that it describes a mass divided by a volume, for example. The LOINC guide also served as the authoritative point of reference when deciding on how to deal with small inconsistencies in the data set. Strong inconsistencies that were not able to be reconciled were disregarded. They are mentioned in the evaluation. It is important to note that there was a lot of wiggle room when choosing an appropriate unit to generate the base unit representation from initially. That is due to the fact that picking one such unit is arbitrary as long as it reflects the intent of the _Property_. A gram, kilogram and pound all describe the concept of a mass, and it does not matter which one of these is chosen when generating the base unit representation. There is a caveat to this though: when going from instance level to the level of the underlying model (the canonical form), we have to be mindful of the loss of semantic precision. A gram describes a mass, but not every mass is measured in grams. In the context of LOINC and UCUM, this means there are multiple _Properties_ represented by the same combination of base units. For example, both \"Length\" and \"Volume/Area\" share the same base unit meter, but the meaning they convey on the instance level appears rather different. In other words, this mapping is unidirectional. This is even more so the case for dimensionless _Properties_, the most prominent example being the default unit \"the unity\" with a value of one. These types of units also make a common appearance as numeric values such as \"24\" or \"10\"-3\", but there are also quite a few unit symbols such as \"%\" and \"mol\" that are nothing but dimensionless values. In addition, units are also able to annul each other, which can result in a dimensionless unit, as is the case with \"g/g\". While these expressions and their conversions into one another are all legitimate within UCUM, there is the question of how this  
Figure 4: The figure shows the final unfolding of the binary tree. The dotted nodes are not actual children. Instead, they signify the metric prefix exponent (blue), value (red) and dimension (green) associated with the respective UCUM symbol. Note that the initial division operator and its subtree have been inverted by multiplying the dimension exponent with minus one. aspect should be accounted for in the context of this project, seeing as there are 78 LOINC _Properties_ that are dimensionless. They are often related to ratios or certain \"scores\" and \"counts\" expressed as annotations such as \"{ct_score}\". For this initial implementation of LUMA, we have not yet opted to decrease the flexibility offered by a broad range of possible choices until we receive more feedback on how to handle them. Table 2 shows an excerpt of the created mappings. Something that becomes apparent when studying the table is how simple formulating a base unit representation often is.