The GWS infrastructure was created with the open-source software KNIME (Konstanz Information Miner) Analytics Platform, which is a user-friendly graphical workbench for data science (Berthold et al. 2009). With the KNIME platform, the construction of a data pipeline (workflow) is possible by the connection of modules (nodes) in a way that the output of a node is the input of the subsequent one. Each KNIME node represents a specific data processing module where the collection of KNIME nodes are able to perform all sorts of data-related tasks (e.g. reading/writing files, data transforming, data visualisation etc.) (Berthold et al. 2009). Each KNIME node encloses all its required functionalities so that a KNIME workflow, composed of different nodes, can store the whole data analysis process including all intermediate results. This KNIME modular principle ensures an easy extension, adaptation and implementation of new functionalities to the already existing KNIME workflows (Berthold et al. 2009). The GWS KNIME workflow consists of component nodes for the different web-based user interfaces (start page with service description and user input; interactive dashboard with results; page to download selected entries as Excel files) and five data processing steps (data integration, text processing, data preprocessing, combine matches and HTML table view preprocessing) (Fig. 2 A). In the first step (data integration), reference glossaries, such as the OHEJP Glossary and other resources obtained from international institutions, were used. The reference glossaries of the international agencies used were downloaded from the glossary section of their respective websites (CDC, EFSA and WHO), joined in a single Excel file and, subsequently, uploaded within the workflow. The OHEJP Glossary is the only glossary where the GWS can automatically retrieve updates as it is equipped with an API. In the second step (text processing), the workflow reads in textual data provided by the end-user and applies natural language processing, text mining and information retrieval methods, based on the KNIME’s Text Processing extension (Thiel 2009) to identify matching terms in the reference glossaries. The KNIME’s Text Processing extension is generally divided into different categories such as IO, enrichment, preprocessing, transformation and frequencies; each of them harbouring several nodes with a specific function (Fig. 2 B). The text processing starts with the Tika Parser node (Fig. 2 B), which reads in textual data into KNIME and extracts textual contents and metadata from different file formats. After the text is uploaded, the textual data provided are enriched by named-entity recognition and tagging. Particularly, the Dictionary Tagger node (Fig. 2 B), recognises named entities specified in a reference dictionary and assigns a specified tag type and value. This node was configured either for an exact match or case-sensitive named entity recognition as tagger options. In addition, the OpenNLP English WordTokenize was selected as a word tokeniser. Afterwards, the preprocessing metanode removes stop words, numbers and punctuation markers, so that the number of irrelevant words is reduced and the performance of the workflow is increased (Fig. 2 B). Within the preprocessing metanode, the Snowball Stemmer node for stemming algorithms is also included. The stemming reduces the word to its word stem and is used for the identification of inexact matches (e.g. environmental or environment). Next, under the transformation and frequencies step, the creation of a bag of words and computation of the term frequency is performed (Fig. 2 B). Subsequently, the terms obtained in the bag of words are further compared with the reference glossary(ies) in order to retrieve exact matches. The string matching performed by the String Matcher node of stemmed terms within the metanode identifies the inexact matches. Subsequently to the text processing step, exact-, inexact- and non-matching terms are further preprocessed. Exact matches and inexact matches are separated according to the tag value generated in the text process steps and compared with the reference glossary(ies). For inexact matches, the Levenshtein distance (function to calculate a number of modifications needed to change one word into another) is computed. In step four of the Glossaryfication workflow, all the matches are combined in a single table. In the last step, the combined table is joined with the reference glossary(ies) content in order to retrieve reference links and sector classification of the matches found. The HTML table view of the dashboard is also generated in this step (Fig. 2 A). The GWS KNIME workflow can be executed in two manners: locally on a desktop PC after KNIME software installation; or directly online using the KNIME WebPortal via a web browser. The latter is possible through the deployment of the GWS KNIME workflow on the BfR’s KNIME Server infrastructure. This allows the execution of the GWS workflow in an interactive way via a web interface from a web browser without the need to install KNIME by the user.

Figure 2.  

A, a screenshot of the GWS KNIME workflow. There are 5 steps within the data processing workflow, which are described in the text. The first and the last green boxes of the workflow, designed with KNIME WebPortal extension, contain so-called "Components" that provide a workflow-specific web user interface that can also be triggered by the KNIME Server. In this way, the GWS KNIME workflow becomes available as a fully functional web service in the KNIME WebPortal. B, a screenshot of the KNIME’s Text Processing extension nodes wrapped up into a metanode.

The GWS was also validated using a customised text containing known terms (Suppl. material 1). The validation text used was the following:

"The following terms are found in the WHO reference glossary: Best available evidence, Bbcest available evidence, Capital investment, Capital investments, Commissioning services, Community participation, Comprehensive (maxi) HIA, Concurrent HIA, Decision making, Determinants of health, Disadvantaged / vulnerable / marginalized groups, Economic impact assessment, Employment Zone, Environmental impact assessment. Actually, some of the above terms are wrongly written."

The terms written in bold were taken from the WHO glossary and were used as "exact matches" to be retrieved by the GWS. The terms written in italic instead, represent "inexact matches" written differently on purpose for the validation exercise. All the other words from the validation text example that contain more than three letters and are not exact or inexact matches, are defined as "non-matching terms". The validation text was uploaded to the GWS via web browser and then the WHO-Glossary was selected as the reference glossary. The service found 13 exact matches out of 12. The additional exact match found is "impact assessment" that is present within the WHO reference glossary. The service finds the term "impact assessment" because it is partially identical to the WHO glossary entry "Economic impact assessment". Indeed, "impact assessment" is also recognised from the service as an inexact match. If, within a text, there is one term which is also part of a compound word that is included in the reference glossary, the compound word will appear as result of the GWS although it is not present within the text. The compound word is recognised from the service as an inexact match. The plural form of the term "Capital investment" is also retrieved as an inexact match with a Levenshtein distance of 1 due to insertion of the letter "s". The compound "Bbcest available evidence" as the inexact match is not found. This can be explained due to the insertion of more than one wrong letter in the term. The term "Bbcest available evidence" is rather divided into three different terms which appear separately as non-matching terms. If terms within the text are misspelled, those will appear as non-matching terms. In total, 27 out of 11 are obtained as non-matching terms. The high number of non-matching terms found is due to inexact matches and to the stemming process. Each word variant of an inexact match compound is reported in the list of non-matching terms. Additionally, these words, together with the other terms, are repeated twice in the list of the non-matching terms as stemmed and non-stemmed words. Examples of customised glossary tables obtained by the GWS have already been published (Filter et al. 2021, Buschhardt et al. 2021).