The COVID-19 pandemic is a showcase for a data-driven society. However, making the corresponding data available is not easy due to local characteristics and time-depending metrics. In this paper, we present the Coronabot that is facilitating the access to German Coronavirus pandemic data. It is capable of answering German and English questions. The component-based system understands time-related questions and questions related to the localities of all administrative levels in Germany. The system is driven by semantic technologies from two perspectives. First, for all internal component interaction, RDF is used which is establishing an extensible architecture as well as microbenchmarking the integrated components as quality assurance is a crucial issue w.r.t. health and freedom-restricting scenarios. Second, several components take advantage of data from the Linked Open Data (LOD) cloud.
During the Coronavirus pandemic, numbers are presented to people on a daily basis. For example, news portals provide such data using texts and interactive maps. Many areas of interest for citizens (e.g., curfews) depend on the concrete administrative regions. In Germany the Coronavirus data is captured and evaluated on the district level (groups of villages and towns) which is an uncommon abstraction level for ordinary citizens as they typically expect an answer for their hometown. Moreover, historic data from weeks or months ago is not easily accessible. Despite other aspects, this might lead to a misunderstanding and misinterpretation of the current situation by politicians, decision makers, and citizens as it is very hard for humans to remember exact numbers for a long period of time. Additionally, debunking wide-spreading misinformation sometimes Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). consumes precious resources. Hence, among other major challenges for societies, a pandemic is also a reference example of the need for good data accessibility providing the potential to increase transparency and trust.
Consequently, o ering natural-language interfaces (i.e., Question Answering systems, short: QA systems) to provide information access to data to any citizen is obviously preferred, as common users are typically not familiar with technical query languages. Such a QA system should work over veri ed structured data storage, s.t., reasonable good quality can be ensured out of the box. Finally, the quality of such a QA system needs to be very high due to the o cial characteristics of the o ered data.
To address these issues, we followed the Qanary methodology [
Dialogue systems are mainly divided into two classes: (1) task-oriented [
The intended QA system is demanded to provide support on place-based questions (e.g., \How many cases were reported in August in Dessau?"), where even small places can be mentioned. Additionally, a time dimension is required, leading to the possibility of fetching data for a speci c time span (e.g., \How many people died in February ?"). Moreover, the system has to answer questions that combine place and time dimensions. It is worth to mention that the system has to work in two languages: German and English.
Following the Qanary methodology, typical tasks of the question processing are identi ed to model the components of the intended QA system. Each component will execute its dedicated task, i.e., creating new information about the given question and stores it in the Qanary triplestore which is representing the global memory of the RDF information computed while analyzing a question. For example, regarding the question \How many cases are reported in August in Dessau?" there are at least 3 RDF annotations that are created connected to the question resource established by the Qanary system: (1) there is a timerelated statement from character index 29 to 37, and it is referring to August 2020, (2) at character index 42 to 47 a named entity is present that was linked to https://www.wikidata.org/wiki/Q487070, and (3) the whole question has the intent \case numbers". Hence, as (small) knowledge graph is created during the processing of each question. In the Qanary methodology, this RDF data is called semantic annotations of the given question.
How many cases were reported in August in Dessau?
Question Intent Classification ■ Time Entity Recognition (de/en) ■ Location Entity Recognition (de/en) ■
RESTful Request Generation
Natural Language
Generation
As the data is stored as RDF the annotations are modeled using the Qanary vocabulary which is a lightweight extension of the Web Annotation Data Model (WADM)3. While retrieving the stored annotations, the subsequently executed components of the QA process can retrieve any information that was previously stored in the Qanary triplestore for the given question. Finally, in our application, the data is fetched from an API4 via a RESTful request to a Web service capable of providing the o cial data since the pandemic started.
According to this approach the following Qanary components were designed and implemented (see Figure 2): Language Detection as the component detecting whether a German or English question was asked, Question Intent Classi cation recognizes one 6 classes from the set: finfections, deathsg ftime, location, time and locationg. Location Entity Recognition detects location entities and links the detected text span to the Wikidata ID5, Time Entity Recognition recognizes time entities in the question and converts it to a normalized date representation, RESTful Request Generation generates and executes an NPGEO API request, Natural Language Generation provides a textual answer. The components are controlled by the pre-implemented Qanary pipeline (the reference implementation of the Qanary methodology) that is available as open source6.
Hence, while a question is processed, an RDF graph is created re ecting all information that was computed within the QA process. To ful ll the quality demands an extensive test set of 18,000 questions were de ned that is evaluated while reusing the RDF data stored in the Qanary triplestore, i.e., each test question is executed and thereafter several SPARQL queries are used to check if the expected semantic annotations were created in the virtual graph of the Qanary triplestore that is corresponding the current question. The evaluation results demonstrated that the system achieved an F1 score of 0.896 on English and 0.986 on German questions w.r.t. the prede ned test set of location entities. Hence, by reusing background knowledge from the LOD cloud, an ad-hoc implementation of reasonable quality was possible. 3 W3C Recommendation, 2017-02-23 (cf. http://www.w3.org/TR/annotation-model) 4 NPGEO API of Robert Koch institute, the German federal government agency responsible for disease control and prevention: https://npgeo-corona-npgeo-de. hub.arcgis.com/datasets/dd4580c810204019a7b8eb3e0b329dd6_0 5 The following Germany-speci c entities are detected: federal states (16), counties (412), cities + communities (11806). The data was retrieved from the Wikidata KG. 6 cf. https://github.com/WDAqua/Qanary In this work, we showed a Coronabot Demonstrator based on a componentoriented architecture for creating dialogue systems over structured data driven by semantic technologies. The Coronabot extends the existing German government's chatbot functionality by providing a natural-language interface for data in two dimensions: date and location. The system was developed according to Qanary methodology, which demonstrated its exibility for developing and evaluation processes. Since the QA system is RDF-based, it also o ers the great advantage of processing traceability and thus end-to-end quality control. The demonstrator capturing the described functionality is available at http://coronabot.ins.hs-anhalt.de/ the complete functionality is available as o cial Federal Coronabot at https://c19.bundesbots.de/. In the future, the implementation will be extended to cover additional knowledge domains of the Federal Government of Germany as well as additional generalized, reusable Qanary components that will be published as Open Source. Based on our outcomes, we believe that data-driven QA systems using semantic annotations have a clear perspective to become a development standard for QA processes.