Although it is not required by the QALL-ME Framework, the question pattern to query pattern mappings (cf. 2.1.5) which are used in the QueryGenerator implementations are currently probably always manually created; at least this is the way all our demo components work. It would be much nicer, though, if the question patterns could somehow be learned automatically, maybe by deriving them from question corpora and the used domain ontology.

The current implementation of the QAPlanner uses reverse geocoding to find the country for the geocoordinate location at which a question was posed. This country information is then used to select the correct location specific services. Currently the reverse geocoding parts are hard wired in the QAPlanner; it would be nicer, though, to have this functionality in an extra web service so that one can easily switch to another reverse geocoding implementation if necessary. Additionally the fallback ways for finding the country information based on the location string which is also given in each inquiry could be improved. This fallback is always used in case the used reverse geocoding service is unavailable.

The source code of the current implementation of the framework and of the demo components can always be improved further. Possibilities for making smaller improvements are often already indicated directly in the sources with “TODO” markers.

Currently the performance of the EntailmentTester components that are used in the different language demo subsystems is far from the state-of-the-art in recognizing textual entailment research. This situation could be improved by using better textual entailment recognizers that are freely available, such as the EDITS system.

Maybe it would be nice to use a UDDI registry in the QALL-ME Framework for the discovery and automatic binding of suitable web services. Currently all used web services in the framework have to be manually specified which is more or less a semi-dynamic binding only.

Currently the web services in the QALL-ME Framework are orchestrated with Java code. More flexibility and easy of use could be gained by using the open standard WS-BPEL for web service orchestration.