In this section we describe the work done in the project building mathematical applications using OpenMath. There were two main approaches used: to add OpenMath support to an existing application, or to construct a new application using OpenMath tools.
The reader will recall that the layer of software which translates between an OpenMath encoding and a piece of software's own internal format is called a phrasebook. The task of adding OpenMath support to an existing application is therefore mainly the process of writing one or more phrasebooks, although it can also involve the specification of new content dictionaries. More than one phrasebook might be required if an application is expected to interpret the same input in different ways, for example a computer algebra system would generally simplify the OpenMath expression:
<OMOBJ> <OMA> <OMS cd="transc1" name="arcsin"/> <OMI> 1 </OMI> </OMA> </OMOBJ>to something like:
<OMOBJ> <OMA> <OMS cd="arith1" name="divide"/> <OMS cd="nums1" name="pi"/> <OMI> 2 </OMI> </OMA> </OMOBJ>(i.e. , although + 2 n , n would be better). However, in some circumstances it might be required to do computations in floating point, in which case it might return
<OMOBJ> <OMF hex="182d4454fb210940"/> </OMOBJ>
Writing a phrasebook requires a great deal of knowledge about the semantics of the underlying application and expertise in this area is more important than expertise in OpenMath (since its semantics are very explicit). The project has developed a number of libraries (see 6.1) to assist in the reading and writing of encoded OpenMath objects. In addition there have been some experiments with generic phrasebooks designed to carry out the translation as a separate process.
AXIOM is a strongly-typed computer algebra system marketed and developed by NAG Ltd. The system is implemented in its own special-purpose language which runs on top of a Lisp kernel. During the project NAG experimented with adding OpenMath support to the kernel by building on top of the C library developed by INRIA (see 6.1), extending some of AXIOM's data types so that they could export instances of themselves using the XML encoding, and adding the capability to run as a server, reading and writing OpenMath objects on a socket. Some of these features will be included in the next commercial release of AXIOM (AXIOM 2.3), in late 2000.
Early in the project a student from the University of Bath implemented a MathML package for Reduce, which extended the system to accept input and print results in that format. NAG built a wrapper for Reduce which used an XSL transformation engine to convert OpenMath to and from MathML so that it could operate as a simple server. While slow, this was a quick and re-usable solution which provided an interesting test bed for both the XSL stylesheets (see 6.5) and the Reduce MathML support.
One advantage of OpenMath is that it can lead to a ``plug and play'' approach to linking together mathematical components. To demonstrate this a Java applet was developed which used STARS (see 6.3.1) as an editor/rendering tool which allowed a user to enter an expression to be integrated. The formal integral was shipped to either the AXIOM or Reduce servers (as described above) to be evaluated. The resulting expression was displayed in the applet using a second instance of STARS.
GAP is a system for computational discrete algebra developed by a worldwide community and currently maintained by the University of St Andrews. It is distributed under ``copyleft'' conditions, i.e. it can be used freely by anybody but not included in a commercial product.
A GAP share package was developed at St. Andrews and is now available to users via FTP. It uses an application based on the INRIA C Library (see 6.1) to read and write OpenMath objects from files, sockets etc.
A phrasebook for Mathematica was developed at INRIA, based on the MathLink protocol and the OpenMath C Library (see 6.1). Its design is similar to that of the GAP phrasebook in that it is a separate process which sits between Mathematica and the client application, although the implementation details are different. It can be obtained by contacting the INRIA team.
NAG is perhaps best known for its numerical libraries, which are written in a variety of languages including Fortran-77. An important facet of these libraries is the comprehensive nature of the documentation which describes the background to each algorithm, the parameters of each routine, details of how to interpret errors and a fully-worked example. As well as printed documentation, NAG has used a number of online formats over the years, with PDF being the current favourite (because of its cross-platform nature and ability to render mathematics faithfully). As an experiment NAG decided to produce a version of one of its routine documents which used MathML to display mathematical expressions, and provided interactive access to the routine using OpenMath.
The approach chosen was to allow the user to input the problem (in this case constrained minimisation of a multivariate expression) in a Java applet running inside an appropriate (in principle MathML-supporting) browser. The problem would be encoded as OpenMath and sent to a server which was capable of executing the NAG routine and returning the result. Unlike the previous examples, this server would be written from scratch as an OpenMath application. Its interface would be defined in terms of an OpenMath object described in a private content dictionary (although the individual components were defined using symbols from standard CDs).
This server can be used in a variety of contexts provided that the input is encoded in OpenMath (as opposed to binary data laid out in memory according to ANSI Fortran rules, for example). Equally, since the interface is well-defined, it would be possible to use a different server (incorporating a more powerful NAG routine or the Matlab optimisation toolbox or ...) from the client relatively easily.
The components were constructed using generic tools. The client was written in Java and made use of the STARS (see 6.3.1) applet from Stilo for translating the user input to OpenMath and displaying it in MathML. The server was written in Aldor  and used the Aldor OpenMath Library (see 6.1) for reading and writing the OpenMath objects. It also used standard Aldor bindings to the NAG Library to solve the problem. While we could have written everything from scratch the availability of all these tools made building the software much more straightforward.
This experiment has proved extremely successful and NAG is now considering the development of a toolkit to allow the rapid deployment of its algorithmic software in this way.
This is far from perfect, since there is much information in the formulae that cannot be recovered from the text. A few examples of this are given below.
OMV) x would recover this formula: there is no need to know that it is q.
We therefore built a prototype formula search engine on some of the formulae in the abstracts of the LMS JCM. As envisaged in the plan, this was built on top of the MFD2 search engine  from INRIA (see section 6.2). The formula search engine was given a database of formulae from the abstracts of the journal (there is no reason why this could not be from the whole journal, but for the purpose of this exercise it was felt that concentrating on the abstracts of as many articles as possible was better than looking at a few articles in depth). While time did not permit a user-driven evaluation, the points described in the following sub-sections were noted.
<OMS cd="nums1" name="pi"/>they would be
<OMS cd="..." name="pi"/>
$O(\ell N^2 \log N$)Clearly what is meant is the transposition of the last two characters:
$O(\ell N^2 \log N)$which prints so similarly that the difference cannot be detected by examining the paper result.
Unfortunately for any hopes of automatic correction, the formula given is
inside parentheses, so the misplaced
) would be picked up as closing
the parenthesis. One cannot require that a LaTeX formula be
``parenthesis correct'', because of interval notations such as [0, 1) (or
the variant [0, 1[ common in France).
An algorithm is given that recognises (in O(lN2log N) time, where N is the size of the input and l the depth of a precalculated Schreier tree) when a transitive group (G,) is the action on one orbit of the action of G on the set of ordered pairs of distinct elements of some G-set (that is, is isomorphic to an orbital of (G,)).Here the relation between the formulae (e.g. N and G), which would be vital for any decent understanding of the mathematics, is carried by the text. Techniques such as OMDoc [2,3], which build on OpenMath, may well be necessary to make any sense of this.
The situation is even worse if we consider the abstract of .
We give an algorithm that takes as input a transitive permutation group (G,) of degree n = mchoose2 and decides whether or not is G-isomorphic to the action of G on the set of unordered pairs of some set on which G acts 2-homogeneously. The algorithm is constructive: if a suitable action exists then one such will be found, together with a suitable isomorphism. We give a deterministic O(snlogcn) implementation of the algorithm that assumes advance knowledge of the suborbits of (G,). This leads to deterministic O(I2) and Monte-Carlo O(snlogcn) implementations that do not make this assumption.Here I is totally undefined (one guesses that it is the size of the input), as are c and s.
How should OpenMath express the extra information in equations 7.1
It would have been possible to base the syntax very closely on that of the
limit symbol. This would, in some sense, reflect the underlying
formal mathematics, but probably not the way these symbols are used in
Instead, using the same methodology as in
was decided to make the main argument of O into a lambda-expression.
While this might seem to cause problems on the rendering side (who would
want to see
O(x.x7)?), these problems have already been solved
int. One advantage of this is that it is
possible to deal with functions of more than one argument, as in the
translation of equation 7.1, which would be structured as follows (ignoring
the complexities of causing the l to render as l, which are not
germane to this discussion).
<OMA> <OMS name="O" cd="asymp1"/> <OMBIND> <OMS name="lambda" cd="fns1"/> <BVAR> <OMV name="N"/> <OMV name="l"/> </BVAR> <OMA> <OMS name="times" cd="arith1"/> ... </OMA> </OMBIND> <OMA> <OMS name="list" cd="list1"/> <OMS name="infinity" cd="nums1"/> <OMS name="infinity" cd="nums1"/> </OMA> </OMA>
It was decided to make the place to which
the implicit limit is taken be a second argument to the O symbol. This
allows for a value of
unknown in places where the OpenMath generator
is unable to determine a sensible value.
However, many areas for future development have been highlighted by this application of OpenMath to ``real life'' data.
The book is an introduction to abstract algebra for first year undergraduate students in Mathematics, Computer Science and Electrical Engineering. It distinguishes itself contentwise by its focus on algorithms and applications. Interactivity is obtained through
The authors of Algebra Interactive are Arjeh M. Cohen, Hans Cuypers, and Hans Sterk. Many core Java applets have been written by L. van Gastel, A. Heck and G. Simons. Technical assistance was carried out by C. Huiban and W. Kortsmit. At Springer-Verlag, details regarding design, layout, software, and commercial aspects were sorted out by A. Einzmann, M. Feith, T. Fuhrmann, F. Schmidt, V. Wicks. Further contributions at RIACA/EUT came from S. Ball, A.E. Brouwer, A. Blokhuis, J. Geraats, W. de Graaf, S. Hoop, M. Lavrauw, R. Lindenbergh, S. van Rijnswou, M. Smeets, A. Steinbach, R. Ushirobira, J. Veerman, R. Verstappen, and H.A. Wilbrink. The GAP development team in St. Andrews helped including GAP as a back engine in Algebra Interactive and provided useful suggestions. The integral source and running version of GAP are to be found on the CD Rom.
The idea at the last stage of this subproject was to translate the content files of the electronic version of this book, usually referred to as IDA1 within the project, in such a way that the mathematics would be encoded in OpenMath. Joint study with Michael Kohlhase en his group at Saarbrücken has led to the definition of an XML standard for such a document, called OMDoc. The reason behind this choice of a new standard is that more than simply OpenMath is required to set up the structure of an interactive book (or document). An important OMDoc feature is that both the CD's (conceptually) created within the text and the OpenMath object present in the document can be extracted automatically. By means of ad hoc programming, a first translation from the IDA1 source texts to OMDoc has been achieved. Furthermore, Chapter 1 of IDA has been manually reworked to a full OMDoc. Using the latest Mozilla browser (and its MathML display capabilities), this chapter can be professionally visualized. All mathematics, including the symbols inserted in sentences, are in OpenMath, as can be visualized by clicking them (forcing the raw OpenMath to appear in a popup window). This shows that the expressions are "ready for use" in any conceivable application. Further progress on interfaces with backengines has given us the possibility to formulate in the OpenMath language the queries needed for interactivity of the gapplet kind (as enabled in IDA1). This OpenMath version of the gapplets appearing in OMDoc are called "omlets". A direct positive effect is that the output of omlets now appears naturally displayed in the text; this is a huge improvement over the clumsy ASCII string displayed in IDA1 as gapplet output. The big improvement however is that we now have a very flexible source, from which many versions of the book (and personally adapted displays) can be made by means of style files.
The new version has been shown at the International Conference in Lisbon, November, 2001, by Dr. Hans Cuypers of RIACA/EUT Eindhoven.
SMASH, Springer's Mathematical Assistant System Heidelberg is based on the technology for IDA2. The goal is to create a collection of pages containing useful concise information for the engineer for each relevant topic, with back engines enhancing the interactivity, and possibly data bases supporting the knowledge supply. The use of the backengines GAP and Mathematica (via JLink) has been successfully demonstrated. A convincing prototype on prime numbers has been completed, and the outlook for a major project in this direction is promising. The idea would be that a future version or successor to JOME will play the role of an authoring tool, and that database tools, extending MDF2, will be used in which OpenMath helps to find the expressions in the database corresponding in a meaningful way to a given query.