## 3 Results
### The UCUM Parser  
The UCUM web presence does not provide users with an official implementation of the standard. Instead, the specification document extensively describes the guidelines which a possible implementation has to adhere to without specifying how exactly the results are to be achieved. For this project, we revised our RESTful UCUM implementation from previous research efforts. By using our own implementation for the current LUMA project, we were certain of its capabilities and also easily able to make changes to it if necessary. We designed the RESTful UCUM service's response structure to comply with the FHIR Parameters [23] resource commonly used for exchanging information within the FHIR digital ecosystem and common denominator between all back-end software components used for LUMA. In a more general sense, parsing describes \"the process of structuring a linear representation in accordance with a given grammar\" [24]. In the case of UCUM, this linear representation is a string that is analyzed in order to gain further insights into how it relates to the syntactic rules (grammar) and semantics laid out by the UCUM specification. In order to assess the meaning and validity of an input string in the context of UCUM there are only a handful of components that need to be evaluated:  
* A metric prefix (optional);
- A unit symbol or an integer;
- A dimension exponent (optional);
- An annotation (optional). * \".\" for multiplication;
- \"/\" for division. * Parentheses further regulating the order of operations  
These components, from here on referred to as tokens, are the smallest semantically meaningful bits of information that a UCUM unit can be decomposed to. Annotations themselves are meaningless for machine processing within UCUM, but they are allowed to contain the entire range of ASCII symbols ranging from 33-126, which includes both arithmetic operators, parentheses and strings that would otherwise be considered invalid. Due to the fact that we wanted to retain annotations for generating a unit's display name in full (e.g., \"g[feathers]\" to \"grams of [feathers]\") we needed to account for this problem when initially performing syntax checks and separating the tokens afterwards. In the next step, the tokens are rearranged from an infix style notation to a postfix style notation, also known as reverse polish notation. In reverse polish notation, operators follow their operands. This style of notation is of particular interest in computer science, as it enables the stack-based processing of expressions [25]. The UCUM expression \"L/(24.h)\" is a \"Volume Rate\" in LOINC. After splitting the tokens and converting them into reverse polish notation, the output would look like this:  
L 24 h. /  
Now there is no need to make use of parentheses in order to clarify the order of operations. One of the ways to convert an infix notation to reverse polish notation is [PERSON]'s Shunting-Yard algorithm [26]. For our use case, we can further simplify it. The reasons for the simplification are twofold. Firstly, all operators are left-associative, and secondly, the operators have equal precedence based on the fact that only multiplication and division are possible. After splitting the string into tokens and rearranging them via the Shunting-Yard algorithm, a binary tree reflecting the initial infix notation is generated. It is visualized in Figure 3.  
Due to the fact that many UCUM units are derived units that are made up of other units, this binary tree will generally undergo further changes until only base units and integers remain, at which point it is traversed to generate its canonical form. A token initially falls either into the category of operator or operand. In order to evaluate the expression, all created nodes also contain various other pieces of information, such as their value, a metric prefix exponent, their dimensionality or annotations. Creating such a node for an operator is trivial; operands, on the other hand, require a more elaborate approach.