Page 1

Formal Aspects of Computing (1999) 11: 326–342

c ? 1999 BCS

Formal Aspects

of Computing

LΩUI: Lovely Ωmega User Interface

J¨ org Siekmann, Stephan Hess, Christoph Benzm¨ uller,

Lassaad Cheikhrouhou, Armin Fiedler, Helmut Horacek,

Michael Kohlhase, Karsten Konrad, Andreas Meier,

Erica Melis, Martin Pollet and Volker Sorge

FB Informatik, Universit¨ at des Saarlandes, Saarbr¨ ucken, Germany

Keywords: Automated deduction; Mathematics; User interface; Agents; Dis-

tributed Artificial Intelligence; Human Computer Interaction

Abstract. The capabilities of a automated theorem prover’s interface are essential

for the effective use of (interactive) proof systems. LΩUI is the multi-modal

interface that combines several features: a graphical display of information in a

proof graph, a selective term browser with hypertext facilities, proof and proof

plan presentation in natural language, and an editor for adding and maintaining

the knowledge base. LΩUI is realized in an agent-based client-server architecture

and implemented in the concurrent constraint programming language Oz.

1. Introduction

The effective use of an interactive theorem proving system depends not least on

the capabilities of its user interface. A major problem is the adequate access to the

overwhelming amount of information manipulated by these systems. This requires

structure-oriented overview facilities, and selective and precise content-oriented

display.

The LΩUI system is a state-of-the-art user interface for Ωmega, a proof assis-

tant system for mainstream mathematics based on proof planning [BCF97]. Some

of LΩUI’s distinct features are the graphical visualization of the information in

proofs, a selective term browser as well as proof and proof plan presentation

in natural language. The user can add new information to partial proofs, which

helps to understand and guide the proof search. LΩUI is implemented as a client

in the distributed agent architecture MathWeb [FrK99, FHJ99].

Correspondence and offprint requests to: Prof. Dr J¨ org Siekmann, FB 14, Universit¨ at des Saarlandes,

D-66041 Saarbr¨ ucken, Germany. http://www.ags.uni-sb.de

Page 2

LΩUI: Lovely Ωmega User Interface327

We start the paper with the design motivation which influenced the devel-

opment of the LΩUI system. In Section 3, various display facilities including

graphical and natural language presentations are described. This is followed in

Section 4 by an illustration of a number of control mechanisms for the effective

use of proof techniques. Section 5 is devoted to the client-server architecture.

Finally, we discuss some related work and directions for further work.

2. Design Objectives

In the field of interactive theorem proving, design principles for the development

of graphical user interfaces are still relatively rare. Some guidelines are presented

in [Eas98]. The design objectives that we have focused on for our interface are:

Multi-Modal Visualization. In any proof state the system should display the

proof information to the user at different levels of abstraction and detail and

furthermore in different modes (e.g. as the graphical representation of a proof

tree, as a linearized proof, or in verbalization mode).

Lean Processing. The interface should work reasonably fast, and its installa-

tion in other environments should be possible with minimal effort and storage

requirements.

Anticipation. The system should minimize the necessary interaction with the user

by suggesting commands and parameters at each proof step. Optimally, the system

should be able to do the straightforward steps autonomously.

One principle mentioned in [Eas98] is the guideline that “there should be a

number of complementary views of the proof construction and the user should

be able to choose to see any number of the views simultaneously”. In other words,

a multi-modal visualization is desirable. Most proof systems however concentrate

just on one single view of the proof rather than on alternative presentations. In

contrast, LΩUI provides different and complementary views of a proof such as a

graphical display or a linearized proof (see Section 3). The traditional graphical

tree representation of the proof is enhanced by dedicated browsers for selected

textual information (see Fig. 1) and intensive use is made of hypertext techniques

in order to illustrate connections between physically distant, but logically related

portions of proofs in both the text-based and the graphical modes. For instance

it is easy to inspect a proof line’s premises with these links and to return to the

starting point by clicking on the corresponding history button in the symbol-

bar. To add a natural language view of proofs, LΩUI calls the Proverb proof

presentation system that structures and verbalizes proofs in natural language (see

Section 3.3).

The lean processing principle has led to a distributed system architecture of

LΩUI/Ωmega, where LΩUI is realized as an autonomous software agent (see

Section 5), which can be sent over the Internet as an applet while the Ωmega

server resides on a dedicated host. Since LΩUI is an autonomous agent, it main-

tains its own representation of the proof state and autonomously computes the

visualization information by using local computational resources, thus reducing

the communication bandwidth to a minimum. Thus the architecture inherits the

advantage from two kinds of setup: From one, where the whole deduction system

is installed locally on the client machine (local computation) as well as from

one, where the logical and graphical computations are centralized on a server the

Page 3

328 J. Siekmann et al.

user communicates with, say, by a remote X connection. This enables the realiza-

tion of the concept of direct manipulation [Shn92], which allows for immediate

feed-back and a minimal time a user has to wait until an action takes effect.

Direct manipulation is supported since LΩUI can react to many forms of user

interaction immediately by manipulating its internal representation of the proof

state rather than calling the server.

Anticipation to minimize user interaction, has always been a concern of

interactive systems, for instance by disabling commands that are nonsensical (i.e.

pre-selecting legal actions) or generating lists of commands that are advisable

in a current situation. In LΩUI’s internal representation of the proof state,

many interface-related reasoning tasks can be performed without the help of

the underlying proof system. For example, LΩUI supports and complements

the agent-based command suggestion mechanism [BeS98a] provided by its host

system Ωmega.

We shall elaborate on these issues in the following sections.

3. Multi-modal Views

LΩUI’s presentation features are, to a certain extent, influenced by Ωmega’s

central three-dimensional proof data structure PDS, which will be presented in

section 3.1. The two subsequent sections discuss the principal proof presentation

capabilities in LΩUI: a structural tree visualization with references to terms

and inference steps and a natural language display. To start with, consider the

following example:1

Theorem 1 (Example) Given that a ⊂ b and b ⊂ c. Then a ⊂ c.

A proof of this theorem can be generated in Ωmega in many ways, the

easiest is by calling an external reasoner for such a simple problem, e.g. the

first-order theorem prover Otter [McC94], which quickly finds the proof. This

external proof is then translated into Ωmega’s proof format and inserted into the

central proof data structure PDS. Now, LΩUI provides different components to

view this data structure (see Fig. 1 for a screen-shot). As in traditional theorem

proving systems, LΩUI can present a proof in a linear text form, in our case

as a higher-order variant of Gentzen’s natural deduction (ND) calculus (as in

the upper right frame in Fig. 1). The formula of the highlighted line is pretty-

printed in the term browser (see the lower right frame in Fig. 1). For long proofs,

such a presentation lacks transparency and structure. Therefore LΩUI offers two

additional representations:

• as a tree that models the logical dependencies between the different proof

lines, (see the upper left frame in Fig. 1),

• as a text in natural language as it would appear in a mathematical text-

book (see Xdvi-window in the lower right corner of Fig. 1). Currently, only

completed proofs can be presented in natural language.

Furthermore LΩUI uses hypertext techniques to visualize essential connec-

tions, e.g. between the proof lines in the standard linearized proof and the

corresponding nodes in the tree representation.

1All examples in this paper are chosen for presentation purposes, not as an example of realistic

scale.

Page 4

LΩUI: Lovely Ωmega User Interface329

Fig. 1. The LΩUI interface presenting the proof for Theorem 1. The standard text presentation

is given in the upper right frame, whereas the corresponding proof tree is given in the upper left

frame. The term browser in the lower right frame displays the formula of the currently focused proof

line/node. The lower left frame provides information on different message streams from the Ωmega

system. The lower-right Xdvi-window presents the verbalized proof as generated by Proverb.

The command menu bar on top of the entire frame in Fig. 1 provides access

to Ωmega’s proof tools that are organized in pull-down menus. Icons are used

as shortcuts to specific commands or sub-menus. Command suggestions for the

next proof step are presented for quick and easy selection in a special suggestion

window. Finally, a control window (see the lower left frame in the window

displayed in Fig. 1) provides access to the output streams of Ωmega’s processes.

In the following subsection we shall present the details of this visualization and

the motivation underlying its design.

3.1. Hierarchical Proof Plan Data Structure

Finding a proof with Ωmega can be viewed as a process that interleaves proof

planning [Mel98, ChS98], plan execution, and verification, all of which is data-

driven by the so-called Proof Plan Data Structure (PDS).

This hierarchical data structure represents a (possibly partial) proof at different

levels of abstraction, called proof plans. Its nodes correspond to steps of the

derivation and are justified by methods. Conceptually, each justification represents

a proof plan for the corresponding derivation step at a lower level of abstraction

(the expansion of the justification). It is computed when the method is expanded.

A proof plan can be recursively expanded, until a proof at the calculus level

Page 5

330J. Siekmann et al.

has been reached. In Ωmega, we keep the original proof plan in the expansion

hierarchy of the PDS. Thus, the PDS makes explicit the hierarchical structure

of proof plans and retains it for further applications such as proof explanation

or analogical transfer of plans.

When the expansion process is completed, a verifier can check the correctness

of the proof. The expansion of macro steps provides the basis for an integration

of external reasoning components – such as an automated theorem prover (ATP)

or a computer algebra system (CAS) – if each reasoner’s results can (on demand)

be transformed into a sub-PDS. New pieces can be added to the PDS by directly

calling methods and rules, by inserting facts from a database, or by calling some

external reasoner.

LΩUI supports Ωmega’s three-dimensional PDS in many ways. For instance,

different layers of the PDS can be analyzed separately and switching to another

layer is supported by context menus for each node. In this sense, LΩUI imple-

ments the philosophy of multi-dimensional representations of proofs within its

visualization and control facilities.

3.2. Visualization – Proofs as Tree-like Maps with Associated Content

If the proof information is conveyed in only one mode by the user interface, it

can lead to problems:

• Presentation in linear form fails to convey the structure of a proof.

• Presentation in tree form may soon become difficult to survey because of the

large annotations associated with each node.

Because of the inadequacies of purely linear or tree formats, a central design

decision in LΩUI was to separate the structure of the proof tree from its content.

Consequently, the visualization of a proof in LΩUI consists of three parts:

• a proof tree in a purely structural form, where the individual nodes convey

status information through their shape and colour.

• a linear form of the content of the proof, by individual lines.

• a number of co-reference facilities for the connections within and between the

tree and the linear proof visualization forms.

The linear form of the proof display is fairly standard in most of its parts,

where each derivation step is presented in one single line. These steps of a

derivation usually fit into a reasonably sized window as the associated display

demonstrates (see the upper right part of Fig. 1). This may not be the case for

entries in the part named “term”. Therefore a separate frame selectively displays

a single term in full length, which can be activated by clicking on the term of

interest in the linear format.

Logical proofs are in general acyclic directed graphs rather than trees, hence

the graphical display of such structures poses problems: If a pure tree display

is produced by duplicating identical subproofs, the tree may grow very large.

If, alternatively, multiple subtrees are displayed only once with pointers to the

other positions, these pointers may easily render the visualization confusing and

unmanageable. Therefore, LΩUI represents nodes with multiple predecessors (i.e.

subproofs used more than once) as co-reference nodes: The subproof is displayed

only in one place, and the other occurrences are represented as a special node –

Page 6

LΩUI: Lovely Ωmega User Interface 331

the co-reference node. In a sense, co-reference nodes take the role of a lemma,

but a co-reference node is not necessarily promoted into a lemma.

Using this convention, proof graphs can be visualized in LΩUI as proper

trees, where node categories (representing the status of the node in the PDS) are

expressed by colour and shape. The shape illustrates the major node category

and colour variations express more fine-grained distinctions:

Terminal nodes are represented by upward pointing triangles, where assumptions,

assertions, and hypotheses are distinguished by their colour (green, yellow, and

orange).

Intermediate nodes are represented by circles, where ground, expanded, and unex-

panded nodes are distinguished by colour (dark blue, bright blue, and light blue).

Open nodes are represented by squares. Since there are no further categorical

distinctions for open nodes, they have the same colour (red).

Co-reference nodes, which may or may not be terminal nodes, are represented by

downward pointing triangles, they are uniquely coloured in grey.

Open nodes represent subgoals in the proof which have not been solved

yet, i.e. they are subject to further derivations. Intermediate nodes represent the

respective level of abstraction in the PDS: Ground nodes are at Ωmega’s calculus

level, i.e. a set of ND rules that is large enough to ensure completeness. The

other intermediate nodes represent inference steps at higher levels of abstraction.

Expanded nodes are nodes where the expansion to the next lower level was

already calculated, but is not displayed. In unexpanded nodes, the expansion has

not yet been calculated.

In order to obtain a good view of the proof tree, the user has commands to

manipulate the appearance of that tree:

zooming between tree overviews and enlarged tree parts,

scrolling to a desired tree part,

focusing on a subtree by cutting off the remaining tree parts,

abstracting away from details of a subtree derivation by hiding the display of

that subtree, which then appears as a double-sized red triangle.2

Because of the different forms of proof display, especially tree structure and

content, various overview formats are offered for the entire proof, where the

references between elements of this overview are very selective and only triggered

by explicit user commands. There are four different forms of co-references in

LΩUI’s display:

• Co-references within the linear form, including the “Pretty Term” frame. Two

facilities are offered here. One is activating the “Pretty Term” browser, which

is done by clicking on the term of interest. The selected term is then displayed

in full length in the “Pretty Term” frame, while the line in which that term

appears is highlighted (see Fig. 1). The other facility is for inspecting individual

justifications of a derivation, which is achieved by clicking on the premise of

interest in a selected line of proof. Again, this line is highlighted.

2Note that this subtree abstraction is different from abstraction levels in the PDS.

Page 7

332J. Siekmann et al.

• Co-references within the proof tree. Through this facility the connection of

a co-reference node is re-established temporarily. Pointing to a co-reference

node leads to the temporary appearance of a line between that node and the

node it co-refers to, that is, the root of the subtree representing the subproof

hidden behind the co-reference node.

• Co-references between the linear form and the proof tree. The connection be-

tween structure and content can be established through this facility. Clicking

on a node activates a yellow box next to that node in the tree display which

contains a label and a term. The referred line in the linear form of the proof

is highlighted.

• Co-references between plain text and the proof tree, the linear form and the

menu bars of LΩUI. There are currently two co-references of this kind. One

is from the node of a proof tree or proof line to a verbalization of the

justification of this node in natural language as described in Section 3.3.

The second kind of co-reference is from hypertext documents (like the online

documentation), where hyperlinks can be used to directly activate LΩUI

commands (see Section 4).

3.3. Proofs in Natural Language

While LΩUI cannot read natural-language input yet,3it makes use of the Proverb

system [HuF97] to present proofs in natural language. Proverb employs state-

of-the-art techniques of natural language processing and generation.

Like mostapplication-oriented natural

Proverb has a pipelined architecture [Rei94] consisting of three processing phases,

each realized by a dedicated component: a macro-planner, a micro-planner, and

a surface realizer. The macro-planner linearizes a proof and plans communicative

acts by a combination of hierarchical planning and focus-guided navigation. The

micro-planner then maps communicative acts and domain concepts into linguistic

resources, it paraphrases and aggregates such resources to produce a text structure

that contains all necessary syntactic information. The realizer TAG-GEN [KiF95]

executes this text structure and generates the surface sentences that are passed

on to LaTEX2e. The formatted text is then finally displayed in an Xdvi-window

(cf. Fig. 1).

While the underlying architecture is standard for many language generation

systems, Proverb has a number of special features that are particularly useful

for presenting mathematical proofs: a focus mechanism to control the presenta-

tion of proof steps in context, paraphrasing capabilities to augment the system’s

expressiveness, and aggregation operators that can be employed to express facts

that share some of their referents and predicates.

The focus mechanism is inspired by Reichman’s theory of discourse [Rei85]. It

hypothesizes a set of nested focus spaces which regulate referential accessibility

of discourse referents, that is, lemmata, theorems, and logical facts in the domain

of mathematical proofs. The focus spaces are used to anticipate whether or not

a particular discourse referent in the communicative act considered is in the

addressee’s focus of attention. This determines for example whether the premises

language generationsystems,

3We are currently working in a collaborative effort within the SFB 378 to read a mathematical text

from a text book.

Page 8

LΩUI: Lovely Ωmega User Interface333

for a derivation step are omitted, explicitly repeated, or implicitly hinted at by

the conclusion or the method justifying that step.

The paraphrasing capabilities are based on the systematization of Meteer’s

Text Structure [Met92] that guarantees the compositional expressibility of domain

concepts in natural language terms through a hierarchy of semantic categories. For

example, depending on the embedding context the logical predicate para(C1,C2)

can verbally be expressed as a quality relation (“line C1 is parallel to C2”), as

a process relation (“line C1 parallels C2”), or as a property ascription (“lines C1

and C2 are parallel” or “the parallelism of lines C1 and C2”).

Finally, the aggregation operators constitute some specific instances of gen-

eral and linguistically-motivated structure modification operations, such as those

found in [DaH93]. Apart from domain-specific, pattern-based optimization rules,

there are two sorts of aggregation operators with a general scope in Proverb

that handle predicate grouping and semantic embedding. The predicate grouping

aggregation condenses two assertions with the same predicate into a single one,

e.g. Set(F) ∧ Set(G) can compactly be expressed as “F and G are sets”. Semantic

embedding allows the skilful verbalization of one assertion, such that it embeds

into another one. For example in Set(F)∧Subset(F,G) the verbalization of Set(F)

as the noun phrase “the set F” allows this expression to be embedded into “F is

a subset of G,” yielding “The set F is a subset of G”.

Altogether, implementing the linguistically motivated concepts of focus

spaces, paraphrasing, and aggregation into Proverb significantly contributes to

the production of a shorter and better readable proof verbalization in compar-

ison to a direct verbalization of the lines of a proof trace. The presentation of

mathematical proofs in natural language by Proverb can be further improved by

taking into account the user’s background knowledge and associated reasoning

capabilities.

A more recent presentation facility is the natural language presentation at

the more abstract level of proof plans [MeL99]. Proof planning is based on

reasoning steps similar to those used by mathematicians. It is therefore more

natural to generate a verbalization on this level. The communication with the

user is facilitated by presenting a verbalization of a method in a hypertext window

when the corresponding node of the tree presentation is clicked on. This hypertext

presentation of a method offers further links to the verbalization of proofs of

subgoals introduced by the method (see Fig. 2). Currently, this local presentation

of methods can be aggregated to a global presentation of the whole proof plan,

but needs further elaboration.

4. Controlling Ωmega

Ωmega’s main functionalities are available via the structured menu bar in

LΩUI’s main window. Its entries partition the conceptually different facilities

of the Ωmega-system into topics, such as Theories, Extern, Planner, and Agent.

These provide all commands of the respective conceptual category. Commands

may be further grouped into submenus. For example, the topic Rule provides

different inference rules that define the basic calculus of the Ωmega system. These

rules are grouped into categories reflecting their logical effect on a proof, for

instance elimination or introduction rules.

One important feature of LΩUI is its dynamic and generic menu extension,

i.e. commands are incrementally added at run-time when they are required and

Page 9

334 J. Siekmann et al.

Fig. 2. Verbalization of a proof planning method.

the user can easily create new menu entries by specifying new commands. This

is achieved by defining commands separately from Ωmega’s core system. Some

commands are then loaded initially. Others – for instance, commands that execute

domain specific tactics – are loaded only when the appropriate theory (see below)

is imported. Thereby a command is always attached to a single menu topic and,

if appropriate, to one or several submenus.

Theories. Mathematical knowledge in Ωmega is hierarchically structured with

respect to so-called theories, which contain signature information, axioms, defini-

tions, theorems, lemmata, and the basic means to construct proofs, namely rules,

tactics, planning methods, and control knowledge for guiding the proof planner.

Each theorem T has its home theory and therefore a proof of T can use

the theory’s signature extensions, axioms, definitions, and lemmata without ex-

plicitly introducing them. A simple inheritance mechanism allows the user to

incrementally build larger theories.

The user can both use and manage Ωmega’s knowledge base through LΩUI. In

particular, it is possible to load theories or their single components incrementally

and separately, browse through available assertions and import them into the

active proof. Furthermore, if a theorem has been proved and the proof is verified,

it can be stored in its home theory.

Rules and Tactics correspond to inference steps at different levels of abstraction.

(We will refer to both rules and tactics with the generic term inference). While

rules belong to a (low level) logic calculus, tactics are more abstract. They are

programs that, when executed, produce a sequence of less abstract inference steps.

Generally, each inference is associated with exactly one command which invokes

it in a given partial proof.

The hierarchic organization of theories and their incremental importation not

only affects their availability for a proof but also LΩUI’s menu structure. Since

theories contain rules and tactics, these are also incrementally loaded and each

attached command is dynamically appended to the corresponding topic in the

menu. Since rules are always defined in Ωmega’s base theory, they are just sorted

Page 10

LΩUI: Lovely Ωmega User Interface335

Fig. 3. Command Widget.

by their type: elimination rules, introduction rules, structural rules, etc. The menu

for tactics is divided into sub-menus according to the theories the tactics belong

to. These sub-menus can be further classified according to the categories specified

within these theories. This supports the user in navigating and finding appropriate

inferences. An inference can be listed in several subtopics

Inferences are applied by executing the attached commands. In general, it

is necessary to provide some arguments for the application of an inference,

which can be specified inside a generic command window. The command window

adjusts itself automatically to the number of arguments and provides some help

to find the requested parameters (cf. Fig. 3 for an example). The user specifies

the arguments either by manually entering them or by a mouse-click on the

appropriate node.

Planner. Ωmega’s proof planner searches in the space of partial proof plans,

where methods are the plan operators. The planner transforms a partial PDS by

method application and by recursive method expansion until it obtains a complete

PDS, i.e. a PDS which represents (can be expanded into) an ND proof.

The commands for Ωmega’s planner are grouped into LΩUI’s planner menu.

The interface displays the growing partial plan as an abstraction of the PDS.

External Systems. Ωmega employs several ATPs, constraint solvers, and

CASs as external reasoners to be applied to specific proof problems. Auto-

mated theorem provers that are currently available to Ωmega are the first-

order systems Otter, Spass, ProTeIn, Bliksem, Satchmo, Waldmeister, and

EQP, (cf. [BCF97, HuF96, FrK99]) and the higher-order theorem provers Tps

(cf. [BeS98b] and Leo [BeK98]. The computer algebra systems include the ex-

perimental system µCAS (cf. [KKS98]) as well as the full-blown systems GAP,

Maple, and Magma.

Fig. 4. Concurrent ATPs.

Page 11

336 J. Siekmann et al.

An interesting aspect of Ωmega is its ability to employ several ATPs con-

currently. The graphical user interface supports the control of parallel ATPs by

providing a special widget as displayed in Fig. 4, which helps the user to monitor

the activities of every single running ATP. Messages report the status of an ATP

as either not available, still running, or whether the prover has found a proof

or failed to do so. The window enables the user to interactively tailor the time

resources given to single ATPs or to kill running processes entirely.

Command Suggestion Mechanism. Another feature of Ωmega that can only be

fully exploited with a graphical user interface is its elaborate mechanism to guide

the user when interactively proving a theorem. It suggests commands, applicable

in the current proof state – more precisely commands that invoke some ND-

rules or tactics – together with sets of suitable instantiations of the command

arguments. It is based on two layers of autonomous, concurrent agents which

steadily work in the background of the Ωmega system and dynamically update

their computational behaviour with respect to the state of the proof and/or

specific user queries of the suggestion mechanism. By exchanging information via

blackboards the agents cooperatively accumulate useful command suggestions

which are then heuristically sorted and presented to the user.

These suggestions are displayed in a separate window (see the right side of

Fig. 1). The entries of this window are constantly updated by the suggestion

mechanism, which is based on the computation of the society of agents. The

command that is most likely to be useful in the current proof state is always in

the first position. However, the user can choose any of the proposed commands.

As long as the command is not yet executed (by confirming the argument settings

in the corresponding command widget), the suggestions are still updated, giving

the user the opportunity to rethink his decision.

The suggestion mechanism always proposes a command together with several

possible sets of instantiations for the command’s arguments. Such a set is a

meaningful combination of parameters, e.g. proof lines, terms, etc., the command

is applicable to. The sets are heuristically sorted and the best one is immediately

proposed to the user by providing it as default arguments to the command. How-

ever, all other computed sets of argument instantiations can still be displayed and

chosen within the respective command widget. One can browse the suggestions

or ask for a single argument (cf. the arrow buttons on the lower left and next

to the arguments in Fig. 3, respectively). Furthermore, the user can specify one

or several of the arguments as fixed and call the suggestion mechanism again by

clicking on the recompute button (cf. Fig. 3) to get possible suggestions for the

remaining parameters.

Online Help. The online documentation of Ωmega contains descriptions of com-

mands, planning methods, and the content of the theories. It is based on HTML

and can be viewed with any standard web browser. Besides the usual references

to related help topics, the hyperlink mechanism is extended to allow interaction

with LΩUI, i.e. the execution of commands and call of menus by clicking on

links within a help page. This yields a nice tool that is used inter alia to introduce

new users to the system (see Fig. 5). Furthermore the documentation of theorems

and problems contains commands to import them into a current problem or to

execute a proof script respectively.

Page 12

LΩUI: Lovely Ωmega User Interface337

Fig. 5. The online help system.

5. The Agent Architecture

A mathematical assistant system calls for an open and distributed system ar-

chitecture. In such an architecture, the developer of a deduction system or a

respective tool upgrades it to a so-called mathematical service by wrapping it into

an agent-oriented parcel, with an interface to a common mathematical software

bus [Hom96, HoC96].

The functionality of the software bus is realized in the MathWeb system

(see [FrK99, FHJ99] for details) by the trader model shown in Fig. 6, which

limits the central administration of the bus to a so-called trading point that

provides routing and authentification information to the mathematical services.

We will describe this model in more detail below.

We have implemented and experimented with our MathWeb system, where the

integrated theorem proving systems and tools can be distributed worldwide and

interact over the Internet. They can be dynamically added to and subtracted from

the coordinated reasoning repertoire of the complete system. For this, we have

embedded all of Ωmega’s external reasoners presented in the previous section.

Now, they jointly handle an average load of tens of thousands of inference

problems a day.

LΩUI is now just one of the cooperating mathematical services, but it is

special in the sense that it is the only part directly visible to and interacting with

the user. In this way it has to meet special requirements: LΩUI must be able

to display the mathematical services that are currently active, it must be able

to suggest external services that may be appropriate for the current task, and it

Page 13

338J. Siekmann et al.

URL

(Oz)

Trading Point

OTTER

SPASS

TPS

PROTEIN

Ω

LOUI

Client

(Oz)

Service

Point

(Oz)

Service

Point

(Oz)

Service

Point

(Oz)

Service

Point

(Oz)

mega

offer service

offer service

distributed Oz application

offer service

offer service

request

accept/deny

distributed Oz application

Fig. 6. The architecture for distributed mathematical services.

must be able to control external systems of which it might not always be able to

get complete information.

Locating the services that are currently available is achieved by providing

LΩUI with a list of services that might be available, and it then tries to contact

each of these services during initialization and tests whether a connection with the

service is possible. Apart from this, LΩUI’s own representation of the service’s

capabilities is currently limited to a general classification of the service, for

instance whether it is a theorem prover or a computer algebra system, and some

information about command syntax and flag settings that are important for

controlling the service needs extension by a list of more specific qualities and

weaknesses of the service.

Given its limited knowledge about collaborating services, LΩUI’s answer to

the problem of finding the right one is pragmatic: it simply starts all problem-

related services on the mathematical bus. The user can eliminate those reasoners

that she thinks might not be suitable to solve the problem. LΩUI will call selected

services in parallel in order to maximize the likelihood of success and minimize

the waiting time of the user. The use of several reasoners for the same task has the

additional advantage of cross-validating results if needed. In any case, the proofs

found by these systems have to be transformed into the internal proof format of

the Ωmega system; this proof transformation process itself runs in parallel to the

ongoing user interaction.

The

Ωmega’s logical kernel from its graphical user interface has increased both its

efficiency and maintainability.

It is quite common in local computer networks that users have relatively

low-speed machines on their desktop, whereas some high-speed servers that are

accessible for everyone operate in the background. Running the user interface on

the local machine uses the local resources that are sufficient for this task, while

the more powerful servers can be exploited for the really complex task of actually

searching for a proof.

The maintenance advantage applies to both the user and the developer. Ωmega

is a rather large system (roughly 17 MB of Common Lisp (CLOS) code for the

Maintenance Advantage. The agentarchitecturethat separates

Page 14

LΩUI: Lovely Ωmega User Interface 339

main body of the current version), comprising numerous associated modules (such

as the integrated automated theorem provers and computer algebra systems)

written in various programming languages. It is a difficult task to install the

complete system, in particular, successful installation depends on the presence of

(proprietary) compilers or interpreters for the respective programming languages.

In our architecture the user only installs the LΩUI client, which connects

to the main system and exchanges data with it via the Internet. Thus the user

interacts with the client, which can be physically anywhere in the world, while the

Ωmega kernel is still on our server (here in Saarbr¨ ucken, where it is maintained

and developed). Since LΩUI is realized via the distributed programming system

environment Mozart/Oz [Smo95],4which is freely available for various platforms

including UNIX and the MS-Windows family of operating systems, this keeps

the software and hardware requirements of the user moderate. The installation

of the client is further simplified by running LΩUI as a Netscape applet, i.e.

LΩUI is automatically downloaded via the Internet. Thus we are able to provide

current versions of Ωmega and LΩUI without the need for re-installation at the

user’s site.

To reduce the bandwidth needed for communication, Ωmega implements an

incremental approach based on Smalltalk’s MVC triad5, which only transmits

the parts of the PDS that are changed by a user action. This not only improves

response time for a low-bandwidth Internet connection but also focuses the user’s

attention to the effects of an action.

Since the presentation of the proof tree is defined by a context-free grammar,

it is rather easy to connect LΩUI to provers other than Ωmega; we have

experimented with Leo [BeK98] and InKa [HuS96] and λ-Clam [RSG98]. In

this sense LΩUI can be seen as a generic proof viewer.

Distributing Ωmega. Up to this point, we have considered a client-server network

with one server that is dedicated to Ωmega itself and several clients that use

this server. In reality, a Ωmega network may consist of several servers that can

be accessed via a gateway service. The gateway daemon runs on one machine

that provides the Ωmega service. It can start the actual Ωmega process and its

associated modules on any of the servers, depending on their current work load.

In this way, we are able to employ the whole computational power of a local

area network with a background of several larger servers.

6. Related Work

User interfaces are the subject of an important discipline in computer science

with its own conferences, workshops and research groups. Many industrial ap-

plications spend substantial effort just on the interface with up to eighty percent

of the systems source code being developed for a friendly interface. The tech-

niques and methods of this discipline slowly but surely find their way even to

rather theoretically oriented fields such as automated theorem proving, where the

importance is increasingly well recognized.

Most interfaces of ATP systems provide graphical illustrations of proof struc-

tures and their elements, and facilities to set up commands in the proof environ-

4http://www.mozart-oz.org/

5See forinstance

overview.

http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

for an

Page 15

340J. Siekmann et al.

ment. The semantics of proof steps are often expressed by graphical objects and

annotations. Examples for this sort of visualization are binary decision diagrams

for first-order deduction systems [PoS95], which have special display facilities

for the relation between quantified formulae and their instantiation, and natural

deduction displays of sequent proofs [Bor97] where the scoping structure of the

proof is visualized by adjacent or by nested boxes enclosing segments of proof

lines. Another presentation technique displays proof steps in an appropriately

formatted and interactive way. The Theorema system [BJK97] can present a

proof in natural language by employing fixed natural language schemata. Details

that are temporarily hidden can be exposed by clicking on the corresponding root

of the proof line.

A verbalization component on top of Nuprl uses a natural language generator

and presents proofs at the level of tactics [HMB99].

CtCoq [BKT94] is a rather elaborate presentation system which distributes

the proof information about a proof over three sections of a multi-paned window:

a Command window records the script of commands sent to the proof engine, a

State window contains the current goals to be proved, and a Theorems window

contains the results of queries into the proof engine’s theorem database.

Other approaches put particular emphasis on visualization by making the

tree format of the proof structure explicit in the display. The user interface of

the SEAMLESS system [EuM97] provides display facilities for a proof graph at

different levels of abstraction in a framed window: a variety of lay-out operations

includes zooming and reuse of lemmata.

The user interface of INKA [HuS96] allows for the display of induction

proof sketches at varying levels of detail. Its features include status information,

typically expressed by different colouring, context-sensitive menus of possible user

actions, and proof by pointing.

The proof verification systems VSE [HLS96] has a very elaborate user interface

that enables the proof engineer to verify industrial software by visualizing relations

between underlying theories (specifications).

The ILF system [Dah98] uses an interface to display proofs in natural lan-

guage and in a tree like structure, where the logical content of nodes is displayed

separately. Furthermore, queries can be sent to the MIZAR library and several

first-order automatic theorem provers running in parallel under control of the

interface.

Ωmega in some sense combines features of SEAMLESS, CtCoq, and ILF. Its

graphical display is similar to that of SEAMLESS, but the set of node categories

and their display is fixed to the particular proof environment. However, LΩUI’s

tree visualization can easily be adapted to a different set of node categories and

display options. Its display of status information is similar to that of CtCoq, but

the database window is handled differently. The concurrent handling of external

reasoners is related to ILF, but since Ωmega’s logic is higher-order, a larger

variety of automatic systems has been integrated. The handling of co-references

and the combination of tree-like and linear display together with the hyper-link

mechanism to visualize references between both are unique to LΩUI.

7. Conclusions

LΩUI represents an agent-based, distributed approach to user interfaces for

theorem provers. It provides advanced communication facilities via an adaptable