Kuldeep Singh
email: kuldeep.singh@iais.fraunhofer.de

Andreas Both
email: andreas.both@unister.de

Saeedeh Dennis Diefenbach
email: dennis.diefenbach@univ-saint-etienne.fr

Saeedeh Shekarpour
email: shekarpour@uni-bonn.de

Towards a Message-Driven Vocabulary for Promoting the Interoperability of Question Answering Systems

Keywords: Semantic Web, Software Reusability, Question Answering, Semantic Search, Ontologies, Annotation Model

HAL is

I. INTRODUCTION

Web of Data is enormously growing (currently more than 84 billion triples 1 ) as well as enterprise data. Still, taking advantage of this rapidly growing data is challenging. Therefore, automatic as well as intelligent approaches are needed to (1) make sense of the data, (2) make the data accessible, and (3) provide easy-to-use interfaces for querying data. Question answering (QA) is multi discipline, and it bridges artificial intelligence, information retrieval, and knowledge base. Recently, the question answering community paid considerable attention for adapting and improving QA systems by taking Web of Data into account. As the result of these attempts, there is an emerging generation of QA systems, which are applied on Web of Data (e.g., [START_REF] Ben | Medical question answering: translating medical questions into sparql queries[END_REF], [START_REF] Lopez | Poweraqua: Supporting users in querying and exploring the semantic web[END_REF], [START_REF] Sun | Open domain question answering via semantic enrichment[END_REF], [START_REF] Unger | Template-based question answering over RDF data[END_REF]).

It is important to note that most of the available QA systems are more focused on implementation details and have limited reusability and extensibility in other QA approaches. Hence, considering the challenges of QA systems there is a need of a generalized approach for architecture or ontology of a QA system and semantic search to bring all stateof-the advancement of QA under a single umbrella. While many of these system achieved significant performance for special use cases, a shortage was observed in all of them. We figured out that the existing QA systems suffer from the following drawbacks: (1) potential of reusing its components 1 observed on 14 October 2015 at http://stats.lod2.eu/ is very weak, (2) extension of the components is problematic, and (3) interoperability between the employed components are not systematically defined. Therefore, there is a need for a descriptive approach that define a conceptual view of QA systems. This approach must cover all needs of current QA systems and be abstracted from implementation details. Moreover it must be open such that it can be used in future QA systems. This will allow interoperability, extensibility, and reusability of QA approaches and components of QA systems.

In this paper, we introduce a generalized ontology which covers the need for interoperability of QA systems on a conceptual level. We initiate a step towards a message-driven interoperable approach that will be used to build systems which follow a philosophy of being actually open for extensions. Our approach collects and generalizes the necessitated requirements from the state-of-the-art of QA systems. We model the conceptual view of QA systems using and extending the Web Annotation Data Model. This model empowers us for designing a message-driven approach for QA systems. To the best of our knowledge, in this way we will establish for the first time a conceptual view of QA systems.

The rest of this paper is structured as follows. Section II describes the diverse field of QA systems and its classification. It also covers current approaches for establishing an abstraction of QA systems and their limitations. Section III introduces dimensions of QA based on which many requirements to build open QA systems can be identified. Section IV describes the existing problem and our proposed idea of an implementation independent compatibility level in detail. Section V details the requirement of message-driven QA systems which are derived from the state-of-the-art QA approaches. Section VI illustrates our proposed ontology with a case study to address all the requirements. Conclusion and future work are presented in Section VII.

II. RELATED WORK

In the recent past, different systems for QA have been developed. This section provides a brief overview on various QA system, their scope of applicability, and their different components.

The QA systems can be distinguished based on scope of applicability and approaches. Some of them consider a specific domain to answer a query, they are known as closed domain QA systems. These QA systems are limited to a specific Knowledge Base (KB), for example medicine [START_REF] Ben | Medical question answering: translating medical questions into sparql queries[END_REF].

However, when scope is limited to an explicit domain or ontology, there are less chances of ambiguity and high accuracy of answers. It is also difficult and costly to extend closed domain systems to a new domain or reusing it in implementing a new system.

To overcome the limitations of closed domain QA systems, researchers have shifted their focus to open domain QA systems.

FreeBase [START_REF] Bollacker | Freebase: A shared database of structured general human knowledge[END_REF], DBpedia [START_REF] Auer | Dbpedia: A nucleus for a web of open data[END_REF], and Google's knowledge graph [START_REF] Singhal | Introducing the knowledge graph: things, not strings[END_REF] are few examples of open domain Knowledge Bases. Through KBs like Google's knowledge graph are not publically available. Open domain QA systems use publically available semantic information to answer questions.

Other type of QA systems described in [START_REF] Sun | Open domain question answering via semantic enrichment[END_REF] extract answers from an unstructured corpus (e.g., news articles), or other various form of documents available over Web. They are known as corpus based QA systems. QuASE [START_REF] Sun | Open domain question answering via semantic enrichment[END_REF] is one of such corpus based QA system that mines answers directly from the Web.

In 2011, a yearly benchmark series QALD was introduced. In the latest advancements, QALD now focus on hybrid approaches using information from both structured and unstructured data. Many open domain QA systems now use QALD for the evaluation. PowerAqua [START_REF] Lopez | Poweraqua: Supporting users in querying and exploring the semantic web[END_REF] is an ontology based QA system which answers the question using the information that can be distributed across heterogeneous semantic resources. FREyA [START_REF] Damljanovic | Freya: An interactive way of querying linked data using natural language[END_REF] is another QA system that increases system's QA precision by learning user's query formulation preferences. It also focuses to resolve ambiguity while using natural language interfaces. QAKiS [START_REF] Cabrio | Qakis: an open domain QA system based on relational patterns[END_REF] is an agnostic QA system that matches fragments of the question with binary relations of the triple store to address the problem of question interpretation as a relation-based match. SINA [START_REF] Shekarpour | SINA: semantic interpretation of user queries for question answering on interlinked data[END_REF] is a semantic search engine which obtains either keyword-based query or natural language query as input. It uses a Hidden Markov model for disambiguation of mapped resources and then applies forward chaining for generating formal queries. It formulates the graph pattern templates using the knowledge base. TBSL [START_REF] Unger | Template-based question answering over RDF data[END_REF] is a template based QA system over linked data that matches a question against a specific SPARQL query. It combines natural Language Processing capabilities (NLP) with linked data to produce good results w.r.t. QALD benchmark.

The field of QA is so vast that the list of different QA systems can go long. Besides domain specific question answering, QA systems can be further classified on type of question (input), sources (structured data or unstructured data), and based on traditional intrinsic challenges posted by search environment (scalability, heterogeneity, openness, etc.) [START_REF] Lopez | Is question answering fit for the semantic web? a survey[END_REF]. For a QA system, an input type can be anything ranging from keyword, factoids, temporal and spatial information (e.g., the geo-location of the user), audio, video, image etc. Many systems have been evolved for a particular input type. For example, DeepQA of IBM Watson [START_REF] Moschitti | Using syntactic and semantic structural kernels for classifying definition questions in jeopardy![END_REF], Swoogle [START_REF] Ding | Swoogle: a search and metadata engine for the semantic web[END_REF], and Sindice [START_REF] Oren | Sindice.com: a documentoriented lookup index for open linked data[END_REF] focus on keyword-based search whereas systems described in [START_REF] Harabagiu | Open-domain voice-activated question answering[END_REF] integrates QA and automated speech recognition (ASR). Similarly, there are several examples of QA based on different sources used to generate an answer like Natural Language Interfaces to Data Bases (NLIDB) and QA over free text.

Earlier in this section, we have observed that the field of QA is growing and new advancements are made in each of existing approaches over the short period of time. However, there is a need of an open framework for generating QA system that integrates state-of-the-art of different approaches. Now we discuss some approaches for establishing an abstraction of QA systems and semantic search.

Research presented in [START_REF] Uciteli | Search ontology, a new approach towards semantic search[END_REF] describes a search ontology to provide abstraction of users question. User can create complex queries using this ontology without knowing the syntax of the query. This approach provides a way to specify and reuse the search queries but the approach is limited in defining properties represented within the ontology. Using search ontology, user can not define the dataset that should be used and other specific properties. The QALL-ME framework [START_REF] Ferrández | The QALL-ME framework: A specifiabledomain multilingual question answering architecture[END_REF] The openQA [START_REF] Marx | Towards an open question answering architecture[END_REF] framework is an architecture that is dedicated to implement a QA pipeline. Additionally, here the implementation of a QA pipeline is limited to Java and cannot work agnostic to the programming language. For implementing an open framework for generating QA systems, it is important to define a generalized vocabulary for QA. It will be an abstraction level on top of all the existing QA approaches and will provide interoperability and exchangeability between them. This generalized vocabulary can be further used to integrate different components and web services within a QA system. DBpedia Spotlight [START_REF] Mendes | Dbpedia spotlight: shedding light on the web of documents[END_REF] is an open source web service for annotating text documents with DBpedia resources. AIDA [START_REF] Ibrahim | Aidasocial: Entity linking on the social stream[END_REF] is a similar project which uses the YAGO [START_REF] Suchanek | Yago: a core of semantic knowledge[END_REF] ontology. While the last two examples address only specific ontologies, AGDISTIS [START_REF] Usbeck | AGDIS-TIS -graph-based disambiguation of named entities using linked data[END_REF] is an approach for name entity disambiguation that can use any ontology. To leverage the capabilities of different available web services and different tools for QA systems, a generalized vocabulary is needed.

III. DIMENSIONS OF QUESTION ANSWERING SYSTEMS

When we look at the typical pipeline of QA systems, the complete QA process is oriented to three main dimensions as follows: (i) Query dimension: covers all processing on input query. (ii) Answer dimension: refers to processing on the query answer. (iii) Dataset dimension: is related to the both characteristics of and processing over employed datasets. Figure 1 presents these high level dimensions. Generally, all of various known QA processes either associated or interacted with QA systems are corresponding to one of these dimensions. In the following, each dimension is discussed in more detail.

1) Query Dimension: The first aspect of this dimension refers to the characteristics of the input query. User- supplied queries can be issued through multifold interface such as voice-based, text-based, and form-based. Apart from the input interface, each query can be expressed in its full or partial form. For instance, full form of a textual or voice query is a complete natural language query whereas partial form is an incomplete natural language query (i.e., either keyword-based query or phrase-based); or full form of a form-based query is a completion of all fields of the form. The second aspect of this dimension refers to processing techniques, which are run on the input query, e.g., query tokenization or Named Entity Recognition.

2) Answer Dimension: Similar to the input query, answer dimansion (i.e., refers to the retrieved answer for the given input query) also can have its own characteristics. Answer can have different types (e.g., image, text, audio) also with full or partial form. For instance, a given query can have either a single or a list of items as answer (e.g., the query "islands of Germany" has a list of items as answer). The system might deliver a complete answer (the full list of items) or partial answer (i.e., a subset of items). IV. PROBLEM AND IDEA

In this section we will present the problem observed from the state-of-the-art. Thereafter we will outline our idea for solving the problem.

Problem: Considering the related work it is clear that three groups of problems exist:

1) Lack of a generic conceptional view on QA systems: While there are many different architectures for QA system (e.g., [START_REF] Sun | Open domain question answering via semantic enrichment[END_REF], [START_REF] Harabagiu | Open-domain voice-activated question answering[END_REF], [START_REF] Marx | Towards an open question answering architecture[END_REF], [START_REF] Lopez | Poweraqua: Supporting users in querying and exploring the semantic web[END_REF]), most of them are tailored to specific and limited use cases as well as applications. Reusability and interoperability was not (enough) in the focus of such approaches. Creating new QA systems is cumbersome and time consuming as well as limited to domains or programming languages. 2) No standardized message format for QA systems: While there are plenty of available tools and services employed by QA systems, yet, interoperability is not ensured due to a missing message format. However, there might be great synergy effect while creating QA systems w.r.t. the combination of different tools. For example, in a given architecture, Named Entity Recognition (NER) and Named Entity Disambiguation (NED) are integrated in a single tool. NER solutions might be evolved and thus, implemented in either a novel way (e.g., in [START_REF] Mendes | Dbpedia spotlight: shedding light on the web of documents[END_REF]) or employ existing tools (e.g., the Stanford NER [START_REF] Finkel | Incorporating non-local information into information extraction systems by gibbs sampling[END_REF] used in [START_REF] Ibrahim | Aidasocial: Entity linking on the social stream[END_REF]). Thus, integrating a (new) NER approach without a standardized message format is also cumbersome and time consuming. However, integrating different components is very difficult and causes a lot of work for each new implementation. 3) Scalability and Coverage problem: Existing schemadriven approaches are mainly focus on the input query (even limited to textual representations of input query), and aren't flexible for fulfilling emerging demands which are not discovered yet (e.g., [START_REF] Uciteli | Search ontology, a new approach towards semantic search[END_REF]). Hence, considering the implementations of current QA systems (and their components) it can be observed they do not achieve compatibility due to their concentration on the implementation instead of the conceptial view. Instead, implementation details need to be hidden and the focus has to be on the message format communicated between the components of the QA system.

Idea: A conceptual view of QA systems has to be completely implementation-independent. Therefore, we introduce a vocabulary (i.e., schema) that addresses abstract definitions of the data needed for solving QA tasks. We will describe the data model by following the mentioned dimensions (cf., Sec. III).

1) Input Query: The abstract definition of the input query along with its properties used for the interpretation and transformation leading towards a formal query of the given dataset. 2) Answer: The abstract definition of the answer (i.e., the search result for the given input query) covering all its associated properties. 3) Dataset: The abstract definition for all kinds of data being used as background knowledge (i.e., for interpreting the input query and retrieving the answer). Please note that we do not describe a specific architecture. Instead our focus is the conceptual level, i.e., the format of the message that needs to be used as input and returned as output by the components of the QA system. Hence, properties need to be annotated to the question to make them available for the following components in the QA system pipeline. As each component of the QA system will use the message to retrieve and encode its knowledge about the question from the message, QA applications following this idea are called message-driven. Hence, information need to be annotated to the message to make it available for following components in the QA system pipeline.

We adapt the definition of annotations from the Web Annotation Data Model 2 .

Definition 1 (Annotation): An annotation is an object having the properties body and target. There should be associated one or more instances of the body property of an annotation object, but there might be zero body instances. There must be one or more instances of the target property of an annotation. For example, considering the question "Where was the European Union founded?" (target) it might be annotated that it contains the named entity "European Union" (body).

In many circumstances, it is required to retrieve the annotator (i.e., the creator) of annotations. Thus, we demand the provenance of each annotation to be expressable (e.g., while using several NED components and later pick one interpretation). We manifest this in the following requirement:

Req. 1 (Provenance of Annotations): The provenance of each annotation needs to be representable within the data model. The annotator needs to be a resource that identifies the agent responsible for creating the annotation.

Hence, if annotations are available, then each atom of the question can be annotated with additional information.

Definition 2 (Question Atom): The smallest identifiable part of a question (user query) is called question atom and denoted by q a . Thus, each given user query Q independent of its type consist of a sequential set of atoms Q = (q 1 , q 2 , . . . , q n ). For example, while considering the question to be a text, the characters of the string or the words of the query might be considered as question atoms, while a user query in the form of an audio input (e.g., for spoken user queries) might be represented as byte stream. Considering textual questions, main component might be parser or Part of Speech taggers. They are used to identify relations between the terms in a question. These relations can have a tree structure like in the case of dependency trees but also more complex ones like direct acyclic graphs (DAG) that are used for example in Xser [START_REF] Xu | Xser@ qald-4: Answering natural language questions via phrasal semantic parsing[END_REF]. Some QA systems such as gAnswer [START_REF] Zou | Natural language question answering over rdf: a graph data driven approach[END_REF] use coreference resolution tools, i.e., finding phrases that refer to some entity in the question. Moreover, a typical goal of QA systems is to group phrases in triples that should reflect the RDF structure of the given dataset. These examples imply the following requirement:

Req. 2 (Relations between Annotations): (a) It has to be possible to describe relations between annotations. (b) Using these relations, it has to be possible to describe a directed or undirected graph (of annotations).

Annotations of components do not always have boolean characteristics. It is also possible to assign a confidence, (un)certainty, probablity, or (in general) score for the annotations. Once again an example is the NED process, where for entity candidates also a certainty is computed (like in [START_REF] Mendes | Dbpedia spotlight: shedding light on the web of documents[END_REF]). This implies the following requirement:

Req. 3 (Score of Annotations): It should be possible to assign a score to each annotation. Note: The type of the score is an implementation detail, e.g., in [START_REF] Mendes | Dbpedia spotlight: shedding light on the web of documents[END_REF] the confidence (score) is within the range [0, 1] while in [START_REF] Ruseti | Qanswer-enhanced entity matching for question answering over linked data[END_REF] the score might be any decimal number.

In the next section the three main dimensions of QA system are described and necessary requirements are derived.

V. REQUIREMENTS OF MESSAGE-DRIVEN APPROACH

In this section while aiming for a conceptional level the requirements of message-driven approach for describing QA systems are derived from the state-of-the-art (cf., Section II). We present them following the dimensions of QA systems as described in Section III. Hence, on the one side a data model for messages in QA systems should be able to describe at least actual QA systems. On the other side the data model has to be flexible and extensible since it is not known how future QA systems will look like nor which kind of annotations their components will use. In general, there are two main attributes which we have to take into account:

• The proposed approach should be comprehensive in order to catch all known annotations used so far in QA systems. • It should have enough flexibility for future extensions in order to be compatible with the upcoming annotations.

A. Input Query

The input query of a QA system can be of various types. For example it might be a query in natural language text (e.g., [START_REF] Unger | Template-based question answering over rdf data[END_REF]), a keyword-based query (e.g., [START_REF] Shekarpour | Sina: Semantic interpretation of user queries for question answering on interlinked data[END_REF]), an audio stream (e.g., [START_REF] Luque | Geovaqa: a voice activated geographical question answering system[END_REF]), or a resource-driven input (e.g., [START_REF] Both | Get inspired: A visual divide and conquer approach for motive-based search scenarios[END_REF]). In all these cases the parts of an input query need to be identifiable as a referable instance such that they can be annotated during the input query analysis. Hence, we define the following requirement:

Req. 4 (Part of the Input Query): The definitions of part of the input query satisfies the following conditions: (i) Part consists of a non-empty set of parts and atoms: each part might be an aggregation of atoms and other parts. However, the transitive closure of the aggregation of each part needs to contain at least one question atom. (ii) For an input query an arbitrary number of parts can be defined. Please note that as we mentioned before, all of the requirements or definitions are independent of any implementation details. Thus, for instance, input query, atom or part have to been interpreted conceptually.

Examples from an implementation view are as follows: for text queries the NIF [START_REF] Hellmann | Integrating NLP using linked data[END_REF] vocabulary might be used to identify each part by its start and end position within the list of characters. Similarly, the Open Annotation Data Model [START_REF] Sanderson | Open annotation data model[END_REF] selects parts of a binary stream by indicating the start and end position within the list of bytes. We leave the actual types of atoms and properties of parts open, as it is depending on the implementation of the actual QA system. In a QA system the components of the analytics pipeline will annotate the parts of the query. Examples for such components are Part-of-Speech (POS) taggers (e.g., in [START_REF] Lopez | Poweraqua: A multi-ontology based question answering system-v1[END_REF]), Named Entity Recognition (NER) tools (e.g., in [START_REF] Cabrio | Qakis: an open domain QA system based on relational patterns[END_REF]) or Named Entity Disambiguation (NED) tools (like [START_REF] Usbeck | AGDIS-TIS -graph-based disambiguation of named entities using linked data[END_REF]). One possible scenario for a textual question is that first several parts are computed (e.g., with a POS-tagger). Thereafter a NED component might annotate the parts with the additional properties, expressing the current state of the question analytics, using the properties that are accepted in the NED community. As it is not known what kind of properties are annotated by which component, we will not define them here. Hence, we have to keep the annotations open for on-demand definition:

Req. 5 (Annotations of Parts): It has to be possible to define an arbitrary number of annotations for each part.

For example, for the input textual query "capital of Germany", the part "Germany" might be annotated by a NER tool as place (e.g., while using dbo:place 3 ).

B. Answer

Each QA system is aiming at the computation of a result. However, considering the QA task there are some demands of the type of the answer. For example, the QA task might demand a boolean answer (e.g., for "Did Napoleons first wife die in France?"), a set of resources (e.g., for "Which capitals have more than 1 mio. inhabitants?"), a list of resources, just one resource etc. Therefore, we define the following requirement:

Req. 6 (Answer): The question needs to be annotated with an object typed as answer. A resource of the type answer might be annotated with a property describing the type of the QA task (e.g., boolean, list, set, . . . ).

Of course, it is possible that the answer type is preconfigured by the user as well as that it needs to be derived automatically by the QA system from the given question.

Additionally only several types might be acceptable for the items been contained in the answer. For example, given the question "Who was the 7th secretary-general of the United Nations?" only specific resource types are acceptable as answer items (w.r.t. the given data). Here it might be dbo:person. From this observation we derive the following requirement.

Req. 7 (Types of Answer Items): An arbitrary number of types can be annotated, to express the types acceptable for the items within the answer.

As an answer is also an annotation of the question, the answer, its answer item types and any additional pieces of information might also be annotated with a score (cf., Req.

3), the annotator (cf., Req. 1) etc.

3 @prefix dbo: <http://dbpedia.org/ontology/>

C. Dataset

The proposed data model needs to take into account information about the employed datasets. The dataset dimension and its sub-dimensions were introduced in the section III. To include these dimensions to the data model, the following requirements are met:

Req. 8 (Dataset): A dataset provides an endpoint where the data can be accessed and statements about the dataset format can be gathered.

Req. 9 (Helper Dataset): A question should be annotated by an arbitrary number of helper datasets (which are subclass of dataset class).

Req. 10 (Target Dataset): At least there is one target dataset (which is subclass of dataset class). Both question and answer should be annotated by at least one target dataset (number of target datasets is arbitrary).

These requirements enables QA system components to easily (1) spot data, (2) access data, (3) query data. Please note that target datasets might overlap with the helper data sets and vice versa.

VI. CASE STUDY

In the previous section, we have collected the requirements for a data model describing the message of interoperable QA systems. As case study we know focus on an ontology that fulfills these requirements (although other formal representation will also comply with the requirements). Here, the Web Annotation Data Model (WADM 4 ) is used as basis that is currently a W3C working draft. The WADM is an extensible, interoperable framework for expressing annotations and is well accepted. In the following it is shown that how the identified requirements are met.

The WADM introduces the class Annotation of the vocabulary oa5 . Thus, any annotation can be defined as an instance of this class. The class Annotation has two major characteristics as the body and the target. The body is "about" the target and it can be changed or modified according to the intention of the annotation. The basic annotation model is represented in Turtle format 6 as follows: <anno> a oa:Annotation ; oa:hasTarget <target> ; oa:hasBody <body> .

The above pseudocode describes an annotation instance which is identified by anno. The anno has the properties target and body (i.e., each one is a resource). In the following, we extend the WADM in order to meet all requirements. For this purpose, a new namespace is introduced: @prefix qa: <urn:qa> .

In order to illustrate the implications, we use a running example with the question "Where was the European Union founded?". First an instance with the type qa:Question is Fig. 2. This picture represents an annotation of the question "Where was the European Union founded?". The part "European Union" is selected using a Specific Resource and a Selector. Moreover a semantic tag is associated to it. instantiated with the identifier URIQuestion. We extended the data model as the input query needs to be defined as well as the answer and the dataset. These concepts are represented by the classes qa:Question, qa:Answer and qa:Dataset which are used to identify questions, answers and datasets. For the example also a URI for the answer URIAnswer and for the dataset URIDataset is introduced. Then one can establish the corresponding instances: This means that annotations of this type need to have a target of type question. Analogously two new annotation types are introduced qa:AnnotationOfAnswer and qa:AnnotationOfDataset. In our example the question is annotated with an answer (anno1) and a dataset (anno2). Now, we will consider requirement 4. To select parts of a query the WADM introduces two concepts: Specific Resources and Selectors. In the WADM, there is a class called Specific Resource (oa:SpecificResource) for describing a specific region of another resource called source. We use this class for typing the concept of part of query in our data model. Assume "European Union" is a part of the input query. For this part, we instantiate a resource with the identifier sptarget1 and the type oa:SpecificResource. The WADM introduces the property oa:hasSource which connects a specific resource to its source. In our example, the source of sptarget1 is URIQuestion stating that "European Union" is a part of the input query. Another relevant class which can be captured from the WADM is the class oa:Selector. It describes how to derive the specific resource from the source. In our example we instanciate the resource selector1 which is a particular type of selector, namely a oa:TextPositionSelector. It descibes that the part "European Union" can be selected in the input query between the character 13 and 27. This is indicated using the properties oa:start and oa:end. This can be expressed via: If the expected answer format is a string, then this can be expressed with the following annotation: If the question in the example should be answered using a SPARQL endpoint available under the URI body5 (e.g., http: //dbpedia.org/sparql), this might be expressed by: <anno5> a oa:AnnotationOfEndpointOfDataset; oa:hasTarget <URIDataset> ; oa:hasBody <body5> . <body5> a qa:Endpoint ; qa:hasFormat dbr:SPARQL .

To fulfill requirements 9 and 10 two new classes are introduced qa:HelperDataset and qa:TargetDataset. This corresponds to a directed edge between the two annotations. Representing undirected edges is possible in a similar way. This shows that requirement 2 is also fulfilled.

To sum up, in this case study we expressed the demanded datamodel with a generalized ontology which is reusing the concepts of the Web Annotation Data Model. We have shown that it is able to address all the requirements identified in Section V. Moreover, we have illustrated the usage with an example. While using annotation, the data model is extensible and open for improvements. The complete case study is available as online appendix at https://goo.gl/vECgK5.

VII. CONCLUSION AND FUTURE WORK

In this paper we have motivated the high demand for an ontology which covers the need for interoperability of QA systems on a conceptual level. We distinguish our approach from other attempts to establish a QA system architecture. Instead we focus on the message level, s.t., everything needed to establish a QA system is included within the data model. Given the requirements and the corresponding case study to the best of our knowledge, we have established for the first time a message-driven interoperable approach that follows a philosophy aiming for QA systems actually open for extension.

Consequently, we collected the requirements for the data model from the recent works to cover also the needs of existing QA systems. However, previous work consider only specific scopes of applicability of QA systems (particularly many focus on text-driven QA). We have chosen an approach that is agnostic to the implementation and the actual representation of the input question and the answer as well as the data sets. Hence, it is a descriptive and open approach. This is an important milestone on the way to actual open QA systems.

We have shown in our case study that our requirements can be covered by the Web Annotation Data Model. Hence, a logical, extensible, and machine-readable representation is now available fulfilling the collected requirements. Eventually the proposed approach can be used for all the existing QA systems while transforming them into a message-driven (and therefore interoperable) implementations.

We see this work as the first step in a larger research agenda. Based on the presented data model (or its implementation as an ontology) the research community is enabled to establish a new generation of QA systems and components of QA systems that are interoperable. Hence, actually open QA systems are in sight. Based on our contribution the research community and the industry can work with a best-of-breed paradigm while establishing future QA systems and integrate novel components into their QA systems. Additionally, our approach enables developers to integrate several components with the same task (e.g., NED) and thereafter compare the results (e.g., with ensemble methods) to achieve the best results w.r.t. the considered domain or data. Consequently we will also aim at an implementation of an open QA system that can be used for comparable benchmarks (like it was done for entity annotation in [START_REF] Usbeck | GERBIL -general entity annotation benchmark framework[END_REF]) strengthening the competition of different approaches as well as measuring the influence of different data sets.

Fig. 1 .

 1 Fig. 1. Main dimensions of question answering systems.

3 )

 3 Dataset Dimension: This dimension also has a series of inherent characteristics such as (i) The type of a dataset refers to the format in which s dataset has been published, i.e., structured, semi-structured or unstructured. (ii) Domain of dataset specifies subject of information included. (e.g., movies, sport, life-science and so forth). If the domain of a dataset covers all subjects, the dataset is open domain. In contrast, a closed domain dataset is limited to a few number of subjects. (iii) The size of data obviously shows how big are the employed datasets. Datasets hold two sub-dimensions as follows: a) Helper Dataset Sub-dimension This dimension includes all datasets required for (i) providing additional information, (ii) training the models. In other words, the helper dataset is used for annotating the input query. Dictionaries like WordNet, gazetteers are examples of this kind of dataset. b) Target Dataset Sub-dimension Target datasets are leveraged for finding and retrieving answer of input query. For instance, Wikipedia can be a target dataset for search.

  <anno1> a oa:AnnotationOfQuestion ; oa:hasTarget <URIQuestion> ; oa:hasBody <URIAnswer> . <anno2> a oa:AnnotationOfQuestion ; oa:hasTarget <URIQuestion> ; oa:hasBody <URIDataset> .

  WADM introduces other types of selectors like Data Position Selectors for byte streams and Area Selectors for images. Hence, the requirement 4 is fulfilled. It is obvious that we can instantiate an arbitrary number of annotations for each part of a question. Thus, the requirement 5 is also met.The WADM defines the property oa:annotatedBy to identify the agent responsible for creating the Annotation, s.t., requirement 1 is fulfilled. To comply with requirement 3 a new property qa:score with domain oa:Annotation and range xsd:decimal is introduced. For example, if "European Union" is annotated by DBpedia Spotlight 7 with a confidence (score) of 0.9, this can be expressed as:

	<anno3>	a	oa:Annotation	;
		oa:hasTarget	<sptarget1>	;
		oa:hasBody	<semanticTag>	.
	<semanticTag> a	oa:SemanticTag	;
		foaf:page	dbr:European_Union .
	<anno3>	oa:annotatedBy	DBpedia spotlight ;
		oa:score	"0.9"ˆˆxsd:decimal .
	To fulfill requirement 6, in our data model a new
	class qa:AnswerFormat and a new type of annotation
	qa:AnnotationOfAnswerFormat are introduced:
	qa:AnnotationOfAnswerFormat a	owl:Class	;
		rdfs:subClassOf oa:AnnotationOfAnswer;
		owl:equivalentClass [
		rdf:type	owl:Restriction ;
		owl:onProperty	oa:hasBody	;
		owl:someValuesFrom qa:AnswerFormat
		].
				<sptarget1> a	oa:SpecificResource;
				oa:hasSource	<URIQuestion>;
				oa:hasSelector <selector1> .
				<selector1> a	oa:TextPositionSelector;
				oa:start	13 ;
				oa:end	27 .

  Both are subclasses of qa:Dataset. If DBpedia is considered to be a target dataset, this can be expressed as follows while URIDataset is http://dbpedia.org:

			<annoZ> a	oa:Annotation ;
			oa:hasTarget <annoX>	;
			oa:hasBody	<annoY>	;
			rdfs:label	"my anotation label" .
	<URIDataset> a	qa:TargetDataset	;
	rdfs:label "DBpedia version 2015" .
	Relations between two annotations <annoX> and
	<annoY> with a label can be expressed using a new
	annotation in the following way:

W3C First Public Working Draft 11 December 2014, http://www.w3.org/ TR/annotation-model/

W3C First Public Working Draft 11 December 2014, http://www.w3.org/ TR/annotation-model/

@prefix oa: <http://www.w3.org/ns/oa#> .

http://www.w3.org/TR/owl2-manchester-syntax/RDF 1.1 Turtle, W3C Rec. 2014-02-25, http://www.w3.org/TR/turtle/

@prefix dbr: <http://dbpedia.org/resource/>

Acknowledgments Parts of this work received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement No 642795 (WDAqua project). We thank Didier Cherix for his kind support while developing the approach.


Andreas Both
email: andreas.both@mercateo.com

Dennis Diefenbach
email: dennis.diefenbach@univ-st-etienne.fr

Kuldeep Singh
email: kuldeep.singh@iais.fraunhofer.de

Saedeeh Shekarpour
email: shekarpour@uni-bonn.de

Christoph Lange
email: langec@cs.uni-bonn.de

Qanary -A Methodology for Vocabulary-driven Open Question Answering Systems

Keywords: Semantic Web, Software Reusability, Question Answering, Semantic Search, Ontologies, Annotation Model

It is very challenging to access the knowledge expressed within (big) data sets. Question answering (QA) aims at making sense out of data via a simpleto-use interface. However, QA systems are very complex and earlier approaches are mostly singular and monolithic implementations for QA in specific domains. Therefore, it is cumbersome and inefficient to design and implement new or improved approaches, in particular as many components are not reusable. Hence, there is a strong need for enabling best-of-breed QA systems, where the best performing components are combined, aiming at the best quality achievable in the given domain. Taking into account the high variety of functionality that might be of use within a QA system and therefore reused in new QA systems, we provide an approach driven by a core QA vocabulary that is aligned to existing, powerful ontologies provided by domain-specific communities. We achieve this by a methodology for binding existing vocabularies to our core QA vocabulary without re-creating the information provided by external components. We thus provide a practical approach for rapidly establishing new (domain-specific) QA systems, while the core QA vocabulary is re-usable across multiple domains. To the best of our knowledge, this is the first approach to open QA systems that is agnostic to implementation details and that inherently follows the linked data principles.

Introduction

Data volume and variety is growing enormously on the Web. To make sense out of this large amount of data available, researchers have developed a number of domain-specific monolithic question answering systems (e.g., [START_REF] Lopez | PowerAqua: Supporting users in querying and exploring the semantic web[END_REF][START_REF] Damljanovic | Freya: An interactive way of querying linked data using natural language[END_REF][START_REF] Cabrio | QAKiS: an open domain QA system based on relational patterns[END_REF][START_REF] Ch | Template-based question answering over RDF data[END_REF]). These QA systems perform well in their specific domain, but find limitation in their reusability for further research due to specific focus on implementation details. Hence, creating new question answering systems is cumbersome and inefficient; functionality needs to be re-implemented and the few available integrable services each follow different integration strategies or use different vocabularies. Hence, an ecosystem of components used in QA systems could not be established up to now. However, component-oriented approaches have provided high values in other research fields (like service-oriented architectures or cloud computing) while increasing efficiency. This is achieved by establishing exchangeability and isolation in conjunction with interoperability and reusability. Increased efficiency of both creating new question answering systems as well as establishing new reusable services would be the major driver for a vital and accelerated development of the QA community in academics and industry.

However, currently the integration of components is not easily possible because the semantics of their required parameters as well as of the returned data are either different or undefined. Components of question answering systems are typically implemented in different programming languages and expose interfaces using different exchange languages (e.g., XML, JSON-LD, RDF, CSV). A framework for developing question answering systems should not be bound to a specific programming language as it is done in [START_REF] Marx | Towards an open question answering architecture[END_REF]. Although this reduces the initial effort for implementing the framework, it reduces the reusability and exchangeability of components. Additionally, it is not realistic to expect that a single standard protocol will be established that subsumes all achievements made by domain-specific communities. Hence, establishing just one (static) vocabulary will not fulfill the demands for an open architecture. However, a standard interaction level is needed to ensure that components can be considered as isolated actors within a question answering system while aiming at interoperability. Additionally this will enable the benchmarking of components as well as aggregations of components ultimately leading to best-of-bread domain-specific but generalized question answering systems which increases the overall efficiency [START_REF] Ferrández | The QALL-ME framework: A specifiable-domain multilingual Question Answering architecture[END_REF]. Furthermore it will be possible to apply quality increasing approaches such as ensemble learning [START_REF] Dietterich | The Handbook of Brain Theory and Neural Networks[END_REF] with manageable effort. Therefore, we aim at a methodology for open question answering systems with the following attributes (requirements): interoperability, i.e., an abstraction layer for communication needs to be established, exchangeability and reusability, i.e., a component within a question answering system might be exchanged by another one with the same purpose, flexible granularity, i.e., the approach needs to be agnostic the processing steps implemented by a question answering system, isolation, i.e., each component within a QA system is decoupled from any other component in the QA system.

In this paper we describe a methodology for developing question answering systems driven by the knowledge available for describing the question and related concepts. The knowledge is represented in RDF, which ensures a self-describing message format that can be extended, as well as validated and reasoned upon using off-the-shelf software. Additionally, using RDF provides the advantage of retrieving or updating knowledge about the question directly via SPARQL. In previous work, we have already established a QA system vocabulary qa [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF]. qa is a core vocabulary that represents a standardized view on concepts that existing QA systems have in common, on top of an annotation framework. The main focus of this paper is to establish a methodology for integrating external components into a QA system. We will eliminate the need to (re)write adapters for sending pieces of information to the component (service call) or custom interpreters for the retrieved information (result). To this end, our methodology binds information provided by (external) services to the QA systems, driven by the qa vocabulary. Because of the central role of the qa vocabulary, we call our methodology Qanary: Question answering vocabulary. The approach is enabled for question representations beyond text (e.g., audio input or unstructured data mixed with linked data) and open for novel ideas on how to express the knowledge about questions in question answering systems. Using this approach, the integration of existing components is possible; additionally one can take advantage of the powerful vocabularies already implemented for representing knowledge (e.g., DBpedia Ontology6 , YAGO 7 ) or representing the analytics results of data (e.g., NLP Interchange Format [START_REF] Hellmann | Integrating NLP using linked data[END_REF], Ontology for Media Resources 8 ). Hence, for the first time an RDF-based methodology for establishing question answering systems is available that is agnostic to the used ontologies, available services, addressed domains and programming languages.

The next section motivates our work. Sec. 3 reviews related work. In Sec. 4 the problem is will be broken down to actual requirements. Thereafter, we present our approach (Sec. 5) followed by a methodology to align existing vocabularies to our qa vocabulary in Sec. 6. In Sec. 7, we present a case study where a QA system is created containing actual reusable and exchangeable components. Sec. 8 concludes, also describing future research tasks.

Motivation

QA systems can be classified by the domain of knowledge in which they answer questions, by supported types of demanded answer (factoid, boolean, list, set, etc.), types of input (keywords, natural language text, speech, videos, images, plus possibly temporal and spatial information), data sources (structured or unstructured), and based on traditional intrinsic software engineering challenges (scalability, openness, etc.) [START_REF] Lopez | Is question answering fit for the semantic web? A survey[END_REF].

Closed domain QA systems target specific domains to answer a question, for example, medicine [START_REF] Abacha | Medical question answering: translating medical questions into SPARQL queries[END_REF] or biology [START_REF] Athenikos | Biomedical question answering: A survey[END_REF]. Limiting the scope to a specific domain or ontology makes ambiguity less likely and leads to a high accuracy of answers, but closed domain systems are difficult or costly to apply in a different domain. Open domain QA systems either rely on cross-domain structured knowledge bases or on unstructured corpora (e.g., news articles). DBpedia [START_REF] Auer | DBpedia: A nucleus for a web of open data[END_REF], and Google's non-public knowledge graph [START_REF] Singhal | Introducing the knowledge graph: things, not strings[END_REF] are examples of semantically structured general-purpose Knowledge Bases used by open domain QA systems. Recent examples of such QA systems include PowerAqua [START_REF] Lopez | PowerAqua: Supporting users in querying and exploring the semantic web[END_REF], FREyA [START_REF] Damljanovic | Freya: An interactive way of querying linked data using natural language[END_REF], QAKiS [START_REF] Cabrio | QAKiS: an open domain QA system based on relational patterns[END_REF], and TBSL [START_REF] Ch | Template-based question answering over RDF data[END_REF]. QuASE [START_REF] Sun | Open domain question answering via semantic enrichment[END_REF] is a corpus-based open domain QA system that mines answers directly from Web documents.

Each of these QA systems addresses a different subset of the space of all possible question types, input types and data sources. For example, PowerAqua finds limitation in linguistic coverage of the question, whereas TBSL overcomes this shortcoming and provides better results in linguistic analysis [START_REF] Ch | Template-based question answering over RDF data[END_REF]. It would thus be desirable to combine these functionalities of [START_REF] Ch | Template-based question answering over RDF data[END_REF] and [START_REF] Lopez | PowerAqua: A multi-ontology based question answering system-v1[END_REF] into a new, more powerful system.

For example, the open source web service DBpedia Spotlight [START_REF] Mendes | DBpedia Spotlight: shedding light on the web of documents[END_REF] analyzes texts leading to named entity identification (NEI) and disambiguation (NED), using the DBpedia ontology (cf., Subsection 3.2). AIDA [START_REF] Ibrahim | Aida-social: Entity linking on the social stream[END_REF] is a similar project, which uses the YAGO ontology (cf., Subsection 3.2). AGDISTIS [START_REF] Usbeck | AGDISTIS -graph-based disambiguation of named entities using linked data[END_REF] is an independent NED service, which, in contrast to DBpedia Spotlight and AIDA, can use any ontology, but does not provide an interface for NEI. The PATTY system [START_REF] Nakashole | PATTY: A taxonomy of relational patterns with semantic types[END_REF] provides a list of textual patterns that can be used to express properties of the YAGO and DBpedia ontologies. As these components have different levels of granularity and as there is no standard message format, combining them is not easy and demands the introduction of a higher level concept and manual work.

Related Work

We have already reviewed the state of the art of QA systems in section 2. Work that is related to ours in a closer sense includes other frameworks that aim at providing an abstraction of QA systems, as well as other ontologies used by QA systems.

Abstract QA frameworks

The QALL-ME framework [START_REF] Ferrández | The QALL-ME framework: A specifiable-domain multilingual Question Answering architecture[END_REF] is an attempt to provide a reusable architecture for multilingual, context aware QA. QALL-ME uses an ontology to model structured data of a specific domain at a time. However, it focuses on closed domain QA, and finds limitation to get extended for heterogeneous data sources and open domain QA systems.

openQA [START_REF] Marx | Towards an open question answering architecture[END_REF] on other hand is an extensible framework for answering questions using open domain knowledge. openQA has a pipelined architecture to incorporate multiple external QA systems such as SINA [START_REF] Shekarpour | SINA: Semantic interpretation of user queries for question answering on interlinked data[END_REF] and TBSL to answer questions. openQA requires all components of the pipeline to be implemented in Java. The OKBQA Hackathon9 , on the other hand, is a collaborative effort to develop knowledge bases and question answering systems that are generic and independent of programming languages.

Ontologies for question answering

Ontologies play an important role in question answering. First they can be used as a knowledge source to answer the questions. Prominent examples are the DBpedia Ontology and YAGO. DBpedia is a cross domain dataset of structured data extracted from Wikipedia articles (infoboxes, categories, etc.). The DBpedia Ontology is "a shallow, cross-domain ontology, which has been manually created based on the most commonly used infoboxes within Wikipedia". 10The YAGO ontology unifies semantic knowledge extracted from Wikipedia with the taxonomy of WordNet. The YAGO Knowledge Base contains more than 10 million entities and more than 120 million facts about these entities. YAGO links temporal and spatial dimensions to many of its facts and entities.

Ontologies can also be used to model the search process in a question answering system. For example, the research presented in [START_REF] Uciteli | Search Ontology, a new approach towards semantic search[END_REF] describes a search ontology that abstracts a user's question. One can model complex queries using this ontology without knowing a specific search engine's syntax for such queries. This approach provides a way to specify and reuse the search queries. However, the approach focuses on textual queries, i.e., it is not completely agnostic to possible question types (e.g., audio, image, . . . ). Search Ontology also does not cover other possibly useful properties, such as the dataset that should be used for identifying the answer.

However, so far no ontology has been developed that would provide a common abstraction to model the whole QA process.

Problem Statement, Requirements and Idea

Our work is motivated by existing QA systems not being sufficiently interoperable and their components not being sufficiently reusable, as pointed out in section 2. Related work on abstract frameworks and QA ontologies has not yet solved the interoperability problem fully, as explained in section 3. In this section, we provide a precise statement of the problem, from which we derive requirements for an abstraction, and finally present our idea for an ontology that can drive extensible QA infrastructures.

Problem statement

Question answering systems are complex w.r.t. the components needed for an adequate quality. Sophisticated QA systems need components for NEI, NED, semantic analysis of the question, query building, query execution, result analysis, etc. Integrating multiple such components into a QA system is inconvenient and inefficient, particularly considering the variety of input and output parameters with the same or similar semantics (e.g., different terms for referring to "the question", or "a range of text", or "an annotation with a linked data resource", or just plain string literals where actual resources are used). As no common vocabulary for communicating between components exists, the following situation is observable for components that need to be integrated: (1) a (new) vocabulary for input values is established, (2) a (new) vocabulary for the output values is established, (3) input or output values are represented without providing semantics (e.g., as plain text, or in JSON or XML with an ad hoc schema). Confronted with these scenarios, developers of QA systems have the responsibility to figure out the semantics of the components, which is time-consuming and error-prone. Hence, efficiently developing QA systems is desirable for the information retrieval community in industry and academics. We observed in Sections 2 and 3 that the number of reusable (components of) QA systems is negligible so far.

Requirements

From the previous problem statement and our observations, we derived the following requirements for a vital ecosystem of QA system's components:

Req. 1 (Interoperability) Components of question answering systems are typically implemented in different programming languages and expose interfaces using different exchange languages (e.g., XML, JSON-LD, RDF, CSV). It is not realistic to expect that a single fixed standard protocol will be established that subsumes all achievements made by domain-specific communities. However, a consistent standard interaction level is needed. Therefore, we demand a (self-describing) abstraction of the implementation.

Req. 2 (Exchangeability and Reusability)

Different domains or scopes of application will require different components to be combined. Increasing the efficiency for developers in academia and industry requires a mechanism for making components reusable and enable a best-of-breed approach.

Req. 3 (Flexible Granularity)

It should be possible to integrate components for each small or big step of a QA pipeline. For example, components might provide string analytics leading to Named Entity Identification (NEI) (e.g., [START_REF] Mendes | DBpedia Spotlight: shedding light on the web of documents[END_REF]), other components might target the Named Entity Disambiguation (NED) only (e.g., [START_REF] Usbeck | AGDISTIS -graph-based disambiguation of named entities using linked data[END_REF]) and additionally there might exist components providing just an integrated interface for NEI and NED in a processing step.

Req. 4 (Isolation)

Every component needs to be able to execute their specific step of the QA pipeline in isolation from other components. Hence, business, legal and other aspects of distributed ownership of data sources and systems can be addressed locally per component. This requirement targets the majority of the QAS platform, to enable benchmarking of components and the comparability of benchmarking results. If isolation of components is achieved, ensemble learning or similar approaches are enabled with manageable effort.

No existing question answering system or framework for such systems fulfills these requirements. However, we assume here that fulfilling these requirements will provide the basis for a vital ecosystem of question answering system components and therefore unexpectedly increased efficiency while building question answering systems.

Idea

In this paper we are following a two step process towards integrating different components and services within a QA system.

1. On top of a standard annotation framework, the Web Annotation Data Model (WADM 11 ), the qa vocabulary is defined. This generalized vocabulary covers a common abstraction of the data models we consider to be of general interest for the QA community. It is extensible and already contains properties for provenance and confidence. 2. Vocabularies used by components for question answering systems for their input and output (e.g., NIF for textual data annotations, but also any custom vocabulary) are aligned with the qa vocabulary to achieve interoperability of components.

Hence, a generalized representation of the messages exchanged by the components of a QA system is established, independently of how they have been implemented and how they natively represent questions and answers.

Thereafter, the vocabulary qa provides the information needed by the components in the implemented question answering system, i.e., a self-describing, consistent knowledge base is available -fulfilling Req. 1. Hence, any component can use the vocabulary for retrieving previously annotated information and to annotate additional information (computed by itself), i.e., each component is using this knowledge base as input and output. This fact and the alignment of the component vocabularies fulfills Req. 2, as each component can be exchanged by any other component serving the same purpose with little effort, and any component can be reused in a new question answering system. Following this process might result in a message-driven architecture (cf., Sec. 7) as it was introduced earlier for search-driven processes on hybrid federated data sources (cf., [START_REF] Both | A service-oriented search framework for full text, geospatial and semantic search[END_REF]). However, the methodology might be implemented by different architectures.

Approach

Web Annotation Framework

The Web Annotation Data Model (WADM), currently a W3C Working Draft, is a framework for expressing annotations. A WADM annotation has at least a target and a body. The target indicates the resource that is described, while the body indicates the description. The basic structure of an annotation, in Turtle syntax, looks as follows: <anno> a oa:Annotation ; oa:hasTarget <target> ; oa:hasBody <body> .

Additionally the oa vocabulary provides the concept of selectors, which provide access to specific parts of the annotated resource (here: the question). Typically this is done by introducing a new oa:SpecificResource, which is annotated by the selector:

<mySpTarget> a oa:SpecificResource ; oa:hasSource <URIQuestion> ; oa:hasSelector <mySelector> . <mySelector> a oa:TextPositionSelector ; oa:start "n"^^xsd:nonNegativeInteger ; oa:end "m"^^xsd:nonNegativeInteger .

Moreover one can indicate for each annotation the creator using the oa:annotatedBy property and the time it was generated using the oa:annotatedAt property.

Vocabulary for Question Answering Systems

In [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF] we introduced the vocabulary for the Qanary approach. Following the data model requirements of question answering systems, this vocabulary -abbreviated as qa -is used for exchanging messages between components in QA systems [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF]. Qanary extends the WADM such that one can express typical intermediate results that appear in a QA process. It is assumed that the question can be retrieved from a specific URI that we denote with URIQuestion. This is particularly important if the question is not a text, but an image, an audio file, a video or data structure containing several data types. URIQuestion is an instance of an annotation class called qa:Question. The question is annotated with two resources URIAnswer and URIDataset of types qa:Answer and qa:Dataset respectively. All of these new concepts are subclasses of oa:Annotation. Hence, the minimal structure of all concepts is uniform (provenance, service URL, and confidence are expressible via qa:Creator, oa:annotatedBy, and qa:score) and the concepts can be extended to more precise annotation classes.

These resources are further annotated with information about the answer (like the expected answer type, the expected answer format and the answer itself) and information about the dataset (like the URI of an endpoint expressing where the target data set is available). This model is extensible since each additional information that needs to be shared between components can be added as a further annotation to existing classes. For example, establishing an annotation of the question is possible by defining a new annotation class qa:AnnotationOfQuestion (using OWL Manchester Syntax):

Class: qa:AnnotationOfQuestion EquivalentTo: oa:Annotation that oa:hasTarget some qa:Question

For additional information about the vocabulary we refer to [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF].

Integration of (external) component interfaces

Following the Qanary approach, existing vocabularies should not be overturned. Instead, any information that is useful w.r.t. the task of question answering will have to be aligned to Qanary to be integrated on a logical level, while the domain-specific information remains available. Hence, we provide a standardized interface for interaction while preserving the richness of existing vocabularies driven by corresponding communities or experts. Existing vocabularies will be aligned to Qanary via axioms or rules. These alignment axioms or rules will typically have the expressiveness of first-order logic and might be implemented using OWL subclass/subproperty or class/property equivalence axioms as far as possible, using SPARQL CONSTRUCT or INSERT queries, or in the Distributed Ontology Language DOL, a language that enables heterogeneous combination of ontologies written in different languages and logics [START_REF] Mossakowski | Three semantics for the core of the Distributed Ontology Language[END_REF]. The application of these alignment axioms or rules by a reasoner or a rule engine will translate information from the Qanary knowledge base to the input representation understood by a QA component (if it is RDF-based), and it will translate the RDF output of a component to the Qanary vocabulary, such that it can be added to the knowledge base. Hence, after each processing step a consolidated representation of the available knowledge about the question is available.

Each new annotation class (with a specific semantics) can be derived from the existing annotation classes. Additionally, the semantics might be strengthened by applying restrictions to oa:hasBody and oa:hasTarget.

Alignment of Component Vocabularies

Our goal in this section is to provide a methodology for binding the qa vocabulary to existing ones used by QA systems. Of course, it is not possible to provide a standard solution for bindings of all existing vocabularies due to the variety of expressing information. However, here we provide three typical solution patterns matching standard use cases and presenting the intended behavior.

As running example we consider an implemented exemplary question answering system with a pipeline of three components (NEI+NED, relation detection, and query generation and processing; cf., Sec. 7). In the following the components are described briefly and also a possible alignment implementation of the custom vocabulary to qa.

NE Identification and Disambiguation via DBpedia Spotlight

DBpedia Spotlight [START_REF] Mendes | DBpedia Spotlight: shedding light on the web of documents[END_REF] provides the annotated information via a JSON interface. An adapter was implemented translating the untyped properties DBpedia Spotlight is returning into RDF using NIF. On top of this service we developed a reusable service that aligns the NIF concepts with the annotations of qa. First we need to align the implicit NIF selectors defining the identified named entities with the oa:TextPositionSelector while aligning the oa:TextPositionSelector with nif:String on a logical level iff nif:beginIndex and nif:endIndex exist. This is expressed by the fol-lowing first-order rule: rdf:type(?s, nif:String) • nif:beginIndex(?s, ?b) • nif:endIndex(?s, ?e) =∆ (÷?x • rdf:type(?x, oa:TextPositionSelector) • oa:start(?x, ?b) • oa:end(?x, ?e))

(1)

Additionally the identified resource of the named entity (taIdentRef of the vocabulary itsrdf) needs to be constructed as annotation. We encode this demanded behavior with the following rule:

Fig. 1 shows our SPARQL implementations of this rule. After applying this rule, named entities and their identified resources are available within the qa vocabulary.

Relation detection using PATTY lexicalization

PATTY [START_REF] Nakashole | PATTY: A taxonomy of relational patterns with semantic types[END_REF] can be used to provide lexical representation of DBpedia properties. Here we created a service that uses the lexical representation of the properties to detect the relations in a question. The service adds annotations of type qa:AnnotationOfEntity. Consequently, the question is annotated by a selector and a URI pointing to a DBpedia resource comparable to the processing in Fig. 1. For example, the question "Where did Barack Obama graduate?" will now contain the annotation:

PREFIX dbo: <http://dbpedia.org/ontology/> <urn:uuid:a...> a oa:TextPositionSelector ; oa:start "24"^^xsd:nonNegativeInteger ; oa:end "33"^^xsd:nonNegativeInteger ; <urn:uuid:b...> a qa:AnnotationOfEntity ; oa:hasBody dbo:almaMater ; oa:hasTarget [ a oa:SpecificResource ; oa:hasSource <URIQuestion> ; oa:hasSelector <urn:uuid:a...> ] ; qa:score "23"^^xsd:decimal ; oa:annotatedBy <http://wdaqua.example/Patty> ; oa:annotatedAt "2015-12-19T00:00:00Z"^^xsd:dateTime .

In our use case the PATTY service just extends the given vocabulary. Hence, components within a QA system called after the PATTY service will not be forced to work with a second vocabulary. Additionally, the service might be replaced by any other component implementing the same purpose (Req. 2 and Req. 4 are fulfilled).

Query Construction and Query Execution via SINA

SINA [START_REF] Shekarpour | SINA: Semantic interpretation of user queries for question answering on interlinked data[END_REF] is an approach for semantic interpretation of user queries for question answering on interlinked data. It uses a Hidden Markov Model for disambiguating entities and resources. Hence, it might use the triples identifying entities while using the annotation of type qa:AnnotationOfEntity, e.g., for "Where did Barack Obama graduate?" the entities http://dbpedia.org/resource/Barack_Obama and http://dbpedia.org/ontology/almaMater are present and can be used. The SPARQL query generated by SINA as output is a formal representation of a natural language query. We wrap SINA's output into RDF as follows:

PREFIX sparqlSpec: <http://www.w3.org/TR/sparql11-query/#> <urn:uuid:...> sparqlSpec:select "SELECT * WHERE { <http://dbpedia.org/resource/Barack_Obama> <http://dbpedia.org/ontology/almaMater> ?v0 . }".

As this query, at the same time, implicitly defines a result set, which needs to be aligned with the qa:Answer concept and its annotations. We introduce a new annotation oa:SparqlQueryOfAnswer, which holds the SPARQL query as its body.

sparqlSpec:select(?x, ?t) • rdf:type(?t, xsd:string) =∆ rdfs:subClassOf(oa:SparqlQueryOfAnswer, oa:AnnotationOfAnswer) • (÷?x • rdfs:type(?x, oa:SparqlQueryOfAnswer) • oa:target(?x, <URIAnswer>)• oa:body(?x, "SELECT . . . "))

The implementation of this rule as a SPARQL INSERT query is straightforward and omitted due to space constraints. Thereafter, the knowledge base of the question contains an annotation holding the information which SPARQL query needs to be executed by a query executor component to obtain the (raw) answer.

Discussion

In this section we have shown how to align component-specific QA vocabularies. Following our Qanary approach each component's knowledge about the current question answering task will be aligned with the qa vocabulary. Hence, while using the information of the question answering system for each component there is no need of knowing other vocabularies than qa. However, the original information is still available and usable. In this way Req. 4 is fulfilled, and we achieving Req. 2 by being able to exchange every component. Note that the choice of how to implement the alignments depends on the power of the triple store used. Hence, more elegant vocabulary alignments are possible but are not necessarily usable within the given system environment (e.g., an alternative alignment for Sec. 6.1, implemented as an OWL axiom, is given in the online appendix 12 ).

Here our considerations finish after the creation of a SELECT query from an input question string. A later component should execute the query and retrieve the actual resources as result set. This result set will also be used to annotate URIAnswer to make the content available for later processing (e.g., HCI components).

Case Study

In this section we present a QA system that follows the idea presented in Sec. 4.3. Note that in this paper our aim was not to present a pipeline that performs better by quantitative criteria (e.g., F-measure) but to show that the alignment of isolated, exchangeable Our exemplary QA system consists of three components: DBpedia Spotlight for named entity identification and disambiguation, a service using the relational lexicalizations of PATTY for relation detection, and the query builder of SINA. All information about a question is stored in a named graph of a triple store using the QA vocabulary. As a triple store, we used Stardog 11 .

The whole architecture is described in Fig. 2. Initially the question is exposed by a web server under some URI, which we denote by URIQuestion. Then a named graph reserved for the specific question is created. The WADM and the qa vocabularies are loaded into the named graph together with the predefined annotations over URIQuestion described in Sec. 5.2. Step by step each component receives a message M (cf., Fig. 2) containing the URI where the triplestore can be accessed and the URI of the named graph reserved for the question and its annotations. Hence, each component has full access to all the messages generated by the previous components through SPARQL SELECT queries and can update that information using SPARQL UPDATE queries. This in particular allows each component to see what information is already available. Once a component terminates, a message is returned to the question answering system, containing the endpoint URI and the named graph URI (i.e., the service interface is defined as process(M ) ae M ). Thereafter, the retrieved URI of the triplestore and the name of the named graph can be passed by the pipeline to the next component. Now let us look into detail about the working of each component. The first component wraps DBpedia Spotlight and is responsible for linking the entities of the question to DBpedia resources. First it retrieves the URI of the input question from the triple store and then downloads the question from that URI. It passes the question to the external service DBpedia Spotlight by using its REST interface. The DBpedia Spotlight service returns the linked entities. The raw output of DBpedia Spotlight is transformed using the binding from Subsection 6.1 to update the information in the triple store with the detected entities.

The second component retrieves the question from the URI and analyses of all parts of the question for which the knowledge base does not yet contain annotations. It finds the most suitable DBpedia relation corresponding to the question using the PATTY lexicalizations. These are then updated in the triple store (cf., Sec. 6.2). components is possible in an architecture derived from the Qanary methodology. In this paper, we have extended the vocabulary proposed in [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF] to align individual component vocabularies together to integrate them into a working QA architecture. Without such an alignment, these components cannot be integrated easily together because of their heterogeneity.

Our exemplary QA system consists of three components: DBpedia Spotlight for named entity identification and disambiguation, a service using the relational lexicalizations of PATTY for relation detection, and the query builder of SINA. All information about a question is stored in a named graph of a triple store using the QA vocabulary. As a triple store, we used Stardog 13 .

The whole architecture is depicted in Fig. 2. Initially the question is exposed by a web server under some URI, which we denote by URIQuestion. Then a named graph reserved for the specific question is created. The WADM and the qa vocabularies are loaded into the named graph together with the predefined annotations over URIQuestion described in Sec. 5.2. Step by step each component receives a message M (cf., Fig. 2) containing the URI where the triple store can be accessed and the URI of the named graph reserved for the question and its annotations. Hence, each component has full access to all the messages generated by the previous components through SPARQL SELECT queries and can update that information using SPARQL UPDATE queries. This in particular allows each component to see what information is already available. Once a component terminates, a message is returned to the question answering system, containing the endpoint URI and the named graph URI (i.e., the service interface is defined as process(M ) ae M ). Thereafter, the retrieved URI of the triple store and the name of the named graph can be passed by the pipeline to the next component. Now let us look into detail about the working of each component. The first component wraps DBpedia Spotlight and is responsible for linking the entities of the question to DBpedia resources. First it retrieves the URI of the input question from the triple store and then downloads the question from that URI. It passes the question to the external service DBpedia Spotlight by using its REST interface. The DBpedia Spotlight service returns the linked entities. The raw output of DBpedia Spot-light is transformed using the alignment from Subsection 6.1 to update the information in the triple store with the detected entities.

The second component retrieves the question from the URI and analyses of all parts of the question for which the knowledge base does not yet contain annotations. It finds the most suitable DBpedia relation corresponding to the question using the PATTY lexicalizations. These are then updated in the triple store (cf., Sec. 6.2).

The third component ignores the question and merely retrieves the resources with which the question was annotated directly from the triple store. The query generator of SINA is then used to construct a SPARQL query which is then ready for sending to the DBpedia endpoint.

We implemented the pipeline in Java but could have used any other language as well. The implementation of each component requires just a few lines of code (around 2-3 KB of source code); in addition, we had to implement wrappers for DBpedia Spotlight and PATTY (4-5 KB each) to adapt their input and output (e.g., to provide DBpedia Spotlight's output as NIF). Note that this has to be done just once for each component. The components can be reused for any new QAS following the Qanary approach.

Overall, it is important to note that the output of each component is not merely passed to the next component just like other typical pipeline architecture, but every time when an output is generated, the triple store is enriched with the knowledge of the output. Hence, it is a message-driven architecture built on-top of a self-describing blackboard-style knowledge base containing valid information of the question. Each component fetches the information that it needs from the triple store by itself.

In conclusion, the case study clearly shows the power of the approach. The knowledge representation is valid and consistent using linked data technology. Moreover, each component is now isolated (cf., Req. 4), exchangeable and reusable (cf., Req. 2), as the exchanged messages follow the qa vocabulary (cf., Req. 1), which contains the available pieces of information about the question, and their provenance and confidence. The components are independent and lightweight, as the central triple store holds all knowledge and takes care of querying and reasoning. As Qanary does not prescribe an execution order or any other processing steps, Req. 3 is also fulfilled.

The case study is available as online appendix 14 .

Conclusion and Future Work

We have presented an extensible, generalized architecture for question answering systems. The idea is driven by the observation that, while many question answering systems have been created in the last years, the number of reusable components among them are still negligible. Hence, the creation of new question answering systems is cumbersome and inefficient at the moment. Most of the created QA systems are monolithic in their implementation; neither the systems nor their components can be reused.

To overcome this problem, our approach follows the linked data paradigm to establish a self-describing vocabulary for messages exchanged between the components of a QA system. Qanary -the question answering vocabulary -covers the requirements of open question answering systems and their integrated components. However, our goal is not to establish an independent solution. Instead, by using the methodology of annotations, Qanary is designed to enable the alignment with existing/external vocabularies, and it provides provenance and confidence properties as well.

On the one hand, developers of the components for question answering (e.g., question analyses, query builder, . . . ) can now easily use our standard vocabulary and also have descriptive access to the knowledge available for the question via SPARQL. Additionally, aligning the knowledge of such components with our vocabulary and enabling them for broader usage within question answering systems is now possible. Fulfilling the requirements (cf., Req. 1-4) this ultimately sets the foundation for rapidly establishing new QA systems. A main advantage of our approach are the reusable ontology alignments, increasing the efficiency and the exchangeability in an open QA system.

Our contribution to the community is a vocabulary and a methodology, which take into account the major problems while designing (complex) question answering systems. Via alignments, our vocabulary is extensible with well-known vocabularies while preserving standard information such as provenance. This enables best-of-breed QA approaches where each component can be exchanged according to considerations about quality, domains or fields of application. Additionally, meta approaches such as ensemble learning can be applied easily. Hence, the approach presented in this paper provides a clear advantage in comparison to earlier closed monolithic approaches. Eventually, for the first time the foundations for a vital ecosystem for components of question answering systems is on the horizon. The paper already provides some components and the alignment of their vocabulary to the Qanary vocabulary. In the future, we will integrate further available components by implementing wrappers for them and specifying ontology alignments. Checking the logical consistency of alignments is also a future issue. Additionally an extension for benchmarking and a corresponding framework is planned to be established.

Fig. 1 :

 1 Fig. 1: Aligning identified NE to a new qa annotation using SPARQL

Fig. 2 :

 2 Fig. 2: Architecture of the exemplary question answering system.

2 Fig. 2 :

 22 Fig. 2: Architecture of the exemplary question answering system.

http://dbpedia.org/services-resources/ontology

YAGO: A High Quality Knowledge Base; http://www.mpi-inf.mpg.de/departments/ databases-and-information-systems/research/yago-naga/yago/

OKBQA Hackathon: http://2015.okbqa.org/development/documentation (last accessed: 2016-03-04)

http://wiki.dbpedia.org/services-resources/ontology (last accessed: 2016-03-08)

http://stardog.com/, community edition, version 4.0.2

https://github.com/WDAqua/Pipeline

Acknowledgments Parts of this work received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 642795, project: Answering Questions using Web Data (WDAqua). We would like to thank the anonymous peer reviewers for their constructive feedback.

Bibliography


Kuldeep Singh
email: kuldeep.singh@iais.fraunhofer.de

Andreas Both
email: andreas.both@mercateo.com

Dennis Diefenbach
email: dennis.diefenbach@univ-st-etienne.fr

Saedeeh Shekarpour

Didier Cherix
email: didier.cherix@gmail.com

Christoph Lange
email: langec@cs.uni-bonn.de

Qanary -the Fast Track to Creating a Question Answering System with Linked Data Technology

Keywords: Software Reusability, Question Answering, Semantic Search, Ontology, Annotation Model

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Motivation

The Web of Data is every day. Researchers have developed a variety of monolithic Question Answering (QA) systems (e.g., [START_REF] Lopez | PowerAqua: Supporting users in querying and exploring the semantic web[END_REF][START_REF] Damljanovic | Freya: An interactive way of querying linked data using natural language[END_REF]) to make sense out of the enormous amount of available web data. Although the field of QA is large and many state-of-theart QA systems exist, researchers are facing difficulties to reuse them because of their focus on implementation details and for lack of a generic approach for designing QA systems. For example, PowerAqua [START_REF] Lopez | PowerAqua: Supporting users in querying and exploring the semantic web[END_REF] links information available across distributed semantic resources to answer queries whereas TBSL [START_REF] Ch | Template-based question answering over RDF data[END_REF] presents an approach that parse the question to produce SPARQL template that depictis the internal structure of the question. However, TBSL provides better results regarding linguistic analysis of questions, whereas PowerAqua is limited w.r.t. linguistic coverage of questions. Combining the capabilities of both systems will provide better functionalities. However, these systems are monolithic and they cannot easily be combined, which reduces their applicability to new domains and the options for synergy effects.

In other research areas, such as service-oriented architectures or cloud computing, the vision of building an ecosystem of components within a dedicated field has already proven its significance for the rapid advancement of research. Therefore, establishing a methodology -on a conceptual and implementation level -is considered crucial for managing the challenges of question answering. The Qanary approach [START_REF] Both | Qanary -a methodology for vocabulary-driven open question answering systems[END_REF] provides such a methodology. Driven by linked data technology and particularly by vocabularies, it integrates the knowledge of QA components into an overall component-based QA system. However, the conceptual layer for QA systems leaves the implementation of the QA system open.

We have implemented the Qanary using a message-driven and light-weight architecture that provides a fast track for integrating QA components, and uses standard RDF technology. We present a reference implementation of a framework for QA systems, manifesting the abstract/conceptual layer of Qanary. The framework covers the main features of component-based systems, i.e., interoperability, exchangeability and reusability, flexible granularity, as well as isolation of components (cf. [START_REF] Both | Qanary -a methodology for vocabulary-driven open question answering systems[END_REF]). Therefore, a sophisticated framework level is achieved while hiding implementation details of the integrated components and establishing the qa vocabulary [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF] as representation of the knowledge about the user's question and the search query derived from it.

Following our long-term research agenda, this framework provides a significant step towards a best-of-breed approach for integrating the most suitable QA components for the planned domain of application. As components integrated by this framework, we initiate hereby an ecosystem for QA components and promote the reusability of existing technology. Hence, efficiency for establishing new QA systems is increased while the effort for providing reusable components is reduced.

The next section covers our approach to create a QA system following the Qanary methodology. We also briefly introduce the qa vocabulary. Section 3 presents a methodology for vocabulary-driven integration of QA components. Section 4 concludes.

Approach

Requirements for Open Question Answering systems

We have identified four key requirements, namely, interoperability, exchangeability and reusability, flexible granularity, and isolation for open QA systems [START_REF] Both | Qanary -a methodology for vocabulary-driven open question answering systems[END_REF]. The QA components are heterogeneous in their implementation, therefore, we have identified that a consistent standard interaction level, i.e., a (self-describing) abstraction of the implementation is needed to promote interoperability. This abstraction will further promote reusability to enhance efficiency of the user to build a new QA system. Hence, exchangeability and reusability are important requirements. Isolation is another identified requirement where each component should run independently of other components, i.e., it is enabled to be loosely coupled with QA systems. Flexible granularity of the components is required so they can be integrated at any step of the QA process, i.e., in contrast to other QA frameworks the granularity is not pre-defined and therefore open for future (special or general) components. To the best of our knowledge, no existing QA system or framework meets these requirements. Therefore, in our concrete implementation of the Qanary methodology, we aim at meeting these requirements.

The qa Vocabulary

In [START_REF] Singh | Towards a message-driven vocabulary for promoting the interoperability of question answering systems[END_REF], we presented a vocabulary for question answering (abbreviated as qa), for representing the knowledge about a question within a QA system. Following the Qanary methodology, the qa vocabulary7 is used to represent transitional results during the QA process, i.e., each component increases the knowledge about the given question by creating or enriching instances of the concepts qa:Question, qa:Dataset or qa:Answer. The qa vocabulary provides the main concepts needed to express the information for annotating a question with knowledge that was computed during the QA process. Each time a component is executed, properties (or information) such as provenance of annotation, score of annotation, relation between annotations, etc., are annotated to the message to make it available for subsequent components in the QA process. Hence, after every step of the QA process, the knowledge base (short: KB) is enriched with additional information about the question.

Integration by Vocabulary Alignment

We consider the fact that Qanary should not overrule existing (domain-specific) vocabularies. Therefore, it is intended to align existing vocabularies to the qa vocabulary, s.t., the computed data is available in a normalized representation and can easily be reused by other component just by knowing the concepts of qa. This can be done by using axioms or rules. The OWL subclass/sub property or class/property equivalence might be used to implement alignment axioms or rules. A reasoner or a rule engine can be used to map information from the Qanary KB to the input representation understood by a QA component (if the latter is RDF-based). A reasoner further translates the RDF output of a QA component to the extended vocabulary for uniformity, then adds it to the KB. An alternative option is to use SPARQL CONSTRUCT or INSERT queries to translate the data computed by a component to a representation that is aligned with the qa vocabulary.

Methodology for Vocabulary-driven Integration of Question Answering Components

To illustrate the power of the Qanary methodology, we took three independent components -DBpedia Spotlight [START_REF] Mendes | DBpedia Spotlight: shedding light on the web of documents[END_REF], PATTY [START_REF] Nakashole | PATTY: A taxonomy of relational patterns with semantic types[END_REF], and SINA [START_REF] Shekarpour | SINA: Semantic interpretation of user queries for question answering on interlinked data[END_REF] -arranged in the same order in the pipeline to build an exemplary QA system (cf. [START_REF] Both | Qanary -a methodology for vocabulary-driven open question answering systems[END_REF]). Here, we describe our approach of integrating them using Qanary with minimal programming effort. Our aim here was not to develop an actual QA system or to answer some specific questions by depicting a QA process, but to support and evaluate our claim that it is possible to reuse existing QA components by creating a new abstraction level for interoperability. Qanary enriches a process-independent KB in each step. Unlike in a traditional QA pipeline, the output of the first component, DBpedia Spotlight, is not directly passed to the second component, PATTY, but is fed into a KB via the abstract level defined by the qa vocabulary and by aligning existing vocabularies to it. The second component needs particular input, and it fetches required input directly from the KB and pushes its output back to KB. The third component does the same. Each component can access all the messages generated by the previous components stored in a triple store through SPARQL SELECT queries and can update that information using SPARQL UPDATE queries. We follow a three-step process to implement an exemplary QA system:

1. Information gathering: In general, every component has a particular need for information as input. To ensure free access to the required information, every QA component is enabled to execute SPARQL queries and can thus retrieve any knowledge about the question. As the qa vocabulary provides a normalized representation of the data, each component only has to know qa to access the data. For example, DBpedia Spotlight needs a text query as its input. It might fetch it from the question URI (<URIQuestion> a qa:Question), following linked data principles. Additional RDF information about the question can be retrieved by executing a SPARQL query, e.g., to fetch named entities already annotated within a textual question. To access existing components, we have implemented light-weight wrappers that send information to the particular component to wrap around and perform its action. The sample code8 is shown below:

// Execute a SPARQL query to retrieve the question URI String sparqlQuery = "PREFIX qa: <http://www.wdaqua.eu/qa#> SELECT ?questionURI FROM " + namedGraph + " WHERE {?questionURI a qa:Question}"; QueryExecution qExe = QueryExecutionFactory.sparqlService(endpoint, QueryFactory.create(sparqlQuery)); ResultSet result = qExe.execSelect(); URL uriQuestion = result.next().getResource("questionURI"); // Retrieve the question using an HTTP request RESTClient myRestClient = new RESTClient(); String question = rstclnt.getResults(uriQuestion.toString()); // Send the question to the DBpedia Spotlight (local, port 8099) String serviceUrl = "http://localhost:8099/" + URLEncoder.encode(question, "UTF-8"); String serviceResult = myRestClient.getResults(serviceUrl); 2. Information retrieval: Each component performs actions on extracted information and produces some results. In the next step, the wrapper retrieves the computed information from the component. Before pushing it to the KB, it is stored in a temporary location and the defined bindings to the qa vocabulary are applied.

3. Store results in triple store: After binding is applied on the retrieved information, the information is pushed to the KB, i.e. a triple store. Hence, following Qanary all QA components are independent from each other and reusable. For example, if a new state-of-the-art named entity disambiguation (NED) method evolves, or new input types come into the picture, researchers just need to replace the NED (in our case study this is DBpedia Spotlight), following above mentioned three steps and the new component can easily be integrated in the QA system. Additionally, it becomes reusable for any other QA system following the Qanary methodology.

A possible extension of the described QA system might incorporate support for spoken questions. Hence, a component C1 is required that translates an audio stream to a textual question, which is required by DBpedia Spotlight. The qa vocabulary is extensible and already covers the requirements for audio streams. Now the individual vocabulary of C1 needs to be aligned to qa. To integrate C1 into the QA system, a light-weight wrapper has to be implemented that fetches the required information and passes it to C1. The above mentioned three-step process will be followed and C1 can be integrated easily and efficiently into the QA system.

For details of the implementation of our exemplary QA system, please refer to our case study at https://github.com/WDAqua/Pipeline.

Conclusion

Qanary establishes a methodology independent from the process actually implemented by concrete QA systems. Hence, it is open for extension and ready for any new idea of how to solve QA tasks. Additionally our approach is built on top of formal logic to support reasoning and querying in a well-defined way and is independent from the actual implementation (the case study has to be considered as just one possible implementation). When a new requirement evolves, or a new component needs to be included in the pipeline, this can be accomplished via a "fast track" with minimal programming effort. Following the Qanary methodology, we meet all the requirements for a vital ecosystem of QA system components that are actually reusable. Hence, Qanary constitutes the first logical step towards actual open QA systems.

cf., https://github.com/WDAqua/QAOntology

using Apache Jena: https://jena.apache.org/

Acknowledgements Parts of this work received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 642795, project: Answering Questions using Web Data (WDAqua).

Bibliography