To know what a user's question is about is a crucial step in the Question Answering (QA) process. Thus, the Expected Answer Type (EAT) of a question enables to signi cantly narrow down the search eld and improve the QA quality. In this paper, we present a Web user interface (UI) and a RESTful API for the hierarchical EAT classi cation over DBpedia. The provided functionality enables end-users to get the EAT predictions for 104 languages, see the con dence of the prediction, and leave feedback. In addition, the API enables researchers and developers to integrate the EAT classi cation into their systems.
The Knowledge Graph Question Answering (KGQA) systems are aimed to
answer entity-oriented questions. For example, while asking a question { like
\Where was Angela Merkel born?" { we expect to see an entity with the type
\Place" (e.g., Hamburg). In this case, \Place" (or even better: \City") is the
expected answer type (EAT). Such types are typically organized into
hierarchical type ontologies [
Following the example question, the EAT hierarchy may look as follows:
dbo:City ! dbo:Settlement ! dbo:PopulatedPlace ! dbo:Place2 where
the rst type is the most speci c one and the last { the most general one.
Recently, many research papers have demonstrated that QA systems may bene t
from the EAT classi cation [
In this paper, we present the Web UI and RESTful API for the hierarchical EAT classi cation over DBpedia3. As we extended our previously developed Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). 1 http://mappings.dbpedia.org/server/ontology/classes/ 2 dbo { is a pre x for http://dbpedia.org/ontology/ 3 https://webengineering.ins.hs-anhalt.de:41009/eat-classification
category value
approach [
The expected answer type is sometimes referred to as target type in the context
of entity-oriented search [
The tool works on top of the approach previously developed by the authors [
“Extended” Resource Type Classifier type1, type2, type3, type4, type5
Question text 1
2 Resource Classifier5 3 4 5 type1 Hierarchy
Retriever type1,...,typen
Question text Resource Classifier1
KG type1 - the most specific (e.g., dbo:City) typen - the most general (e.g., dbo:Place) given question. After doing so, the corresponding DBpedia hierarchy is fetched instead of an independent prediction of EAT for each granularity level (see Figure 2). Hence, the extended approach di ers only in the resource classi er.
Figure 2 demonstrates that in the previous approach, no hierarchy consistency check is done. Thus, the predicted types may belong to a di erent hierarchy, which is unacceptable as the prediction becomes inconsistent. In addition, the hierarchy size is limited only to ve types. On the other hand, the extended approach predicts the most speci c resource answer type and fetches the rest of the hierarchy from a KG (e.g., DBpedia) thereafter (via hierarchy retriever). The hierarchy retriever just executes the SPARQL query and formats the nal output.
PREFIX rdfs : < http :// www . w3 . org /2000/01/ rdf - schema #> SELECT ? sType WHERE { <type > rdfs : subClassOf * ? sType .
FILTER ( CONTAINS ( STR (? sType ) , " dbpedia . org / ontology ") ) } # the 'type ' placeholder is replaced with the predicted type
Listing 1. Retrieving super types of a given answer type from DBpedia. In this case, the resource answer type hierarchy is consistent and not limited to a speci c size.
For training and evaluation, we used the DBpedia dataset of the SMART Task. We reuse our previously prepared multilingual extension for the dataset4 and ne-tune the classi er using multilingual language model5 that supports 104 languages.
The evaluation of the obtained EAT classi er demonstrated reasonable
results: (1) category prediction { Accuracy := 0:977, (2) type ranking { NDCG@5
:= 0:745; NDCG@10 := 0:710 [
The Web UI of the EAT classi er is presented in Figure 3. The description of
the numbered elements is as follows: (1) question input eld, (2) switch button
that enables to get the additional prediction with the model [
The RESTful API6 of the EAT classi er has GET endpoints for both currently provided models. After providing the parameter question containing the question's text, the service returns a dictionary with the following elds: category (holds on of "resource", "literal", or "boolean"), answer type (if canse of predicting not a resource, then the primitive data is stored in the array, e.g., ["number"] or ["boolean"], else one or more elements corresponding to the resource hierarchy, e.g., ["dbo:Person", "dbo:Agent"]); and confidence { a oat value f 2 [0; 1] corresponds to the models con dence of the prediction. 4
In this work, we presented the Web UI and the RESTful API for retrieving EAT predictions and validating EAT classi ers. Currently, two EAT components are integrated. Among the DBpedia Ontology types (resources), the tool is capable to distinguish between literal and boolean answer types. The EAT classi er is capable of providing predictions for questions given using up to 104 languages, and showed reasonable quality w.r.t. SMART Task evaluation over the DBpedia dataset. 6 https://webengineering.ins.hs-anhalt.de:41020/docs
For future work, we plan to improve the approach w.r.t. the quality and extend it to other ontologies (e.g., Wikidata) to enable comparability. We would like to atten the architecture of the classi er (see Figure 1) s.t., only one model is used for the prediction. In addition, it is worth paying attention to the robustness of the model w.r.t. corrupted input data (e.g., spelling mistakes).