1.1. Monoliths

At a very simple level, an interactive query system simply accepts queries from a user, which return responses from the data. In systems like Arras and Tact, the single monolithic software package controls everything in the diagram.

1.2. Web interface

With the advent of graphical browsers for the World Wide Web, however, it is possible to provide a fairly attractive interface at a much lower cost than would otherwise be possible. It may still make sense to devise special-purpose user interface software for specific purposes, but we can go a long way without it, just relying on the users to have chosen a Web browser they like reasonably well. The Web, that is, exposes an interface between the user interface and the data in the back end. This interface sets certain limits to our freedom — we must now use HTML to describe what the user sees (we can use arbitrary XML if we are willing to require that the user have an XML-capable browser) and the user's interactions with the server are limited to what can be done using HTML forms (and possibly a browser scripting language like Javascript) — but within those limits we can develop better user interfaces at a lower cost than if we were building from scratch. Even more important, we can now swap front- and back-ends in and out. We can experiment with different user interfaces by writing different front-end forms and HTML style sheets. In theory, we can also experiment with different back ends by substituting one for the other and using the same front end; in practice, the existing systems built on this model don't easily allow for swapping different back ends in and out, because the interface between the front end and the back end varies with the specific product used as the back end. Because different commercial products rarely support identical interfaces, this means it's rarely possible to swap a new back end in with minimal effort.

1.3. Mots 15

The Mots 15 system differs from the generic Web-based system primarily by exposing a generic query interface in front of the back-end-specific query interface, in order to buffer the front end and back end from each other. Ideally, this generic query interface should follow some open specification; ideally, it should provide all the functionality we want (to keep life simple), and no more (so that it is easy to build back ends if we want to do it ourselves); the exact choice depends on the tradeoff between these incompatible goals. Assuming that we have some suitable query language, and a way to translate from it into the query language of the back end, then any XML query engine may be used as back end. A SQL dbms may be the most flexible back end. The design made by MSM for this would involve a few light-weight scripts which run on top of’ the SQL database system. The SQL system itself would in this design produce not elements but element pointers, which would be used to extract the elements from a saved copy of the XML file. The task of translating from the open query language to the proprietary back end query language is, of course, simplified if the back end accepts the open query language itself. Another alternative would be using the corpus management system Corpus WorkBench (IMS, Stuttgart) as the MOTS back end, possibly combined with an XML query facility. This would allow for more advanced linguistic queries.