As shortly presented in 2.1.6: “Service Oriented Architecture”, the QALL-ME Framework is implemented on the basis of a Service Oriented Architecture (SOA) with web service (WS) technology. In this section you will get a conceptual overview of the QALL-ME Framework’s system architecture. In 2.3.1 we will describe the workflow between the question answering (QA) components of the system before we will have a closer look at the components themselves in section 2.3.2.
The QALL-ME Framework QA system workflow is managed by the QA planner. In Figure 2.1 you can find a conceptual view on this workflow in the planner. As can be seen, this workflow is pretty linear: starting from the reception of the input question with context, the planner processes the inquiry until it has an answer.
The QA planner has five input parameters of which three are somehow given in the user’s inquiry: the asked question as well as a spatiotemporal context in form of the current time and the user’s location (cf. 2.1.4: “Spatiotemporal Anchoring of Questions”). The two other input parameters can be considered to be more or less static as they usually don’t change with the inquiry: a collection of facts that is inserted into the answers database (cf. 2.1.2: “Structured Answer Data Sources”) and a collection of pattern mappings (cf. 2.1.5: “Recognizing Textual Entailment for QA”). The latter is entered into a static pattern store which is used in the Query Generation component. The collection of pattern mappings is either created manually – as has been done in the QALL-ME project (cf. 2.4: “By the Way: What is QALL-ME?”) – or a suitable learning subsystem has to be developed which creates the required mappings (cf. 5: “Possible Extensions”). The single output parameter of the QA planner is the found answer.
The workflow which is depicted in Figure 2.1 represents both the monolingual QA workflow as well as the crosslingual QA workflow (see also 2.1.1: “Multilingual QA”). Depending on the language of the input question and the user’s location, the QA planner selects appropriate component implementations on the way to the answer. There are three kinds of components:
- language-specific
the component is implemented once for each language that the QA system shall be able to handle for input questions; the QA planner has to choose from these implementations
- location-specific
the component is implemented once for each location at which the QA system shall be able to answer questions; this is in line with the spatial anchoring of questions, cf. section 2.1.4: “Spatiotemporal Anchoring of Questions”; the QA planner has to choose from these implementations
- system-wide
the component is implemented only once for the whole QA system, i.e., it has language and location independent functionality and the QA planner uses this implementation for all input questions
In Figure 2.1 you may find all language- and location-specific components annotated with a relevant UML 2 comment; all other components are system-wide components and implementations of these are provided by the core framework. In the following section the components in the depicted QA workflow are presented in more detail.
