The OpenMath Consortium is a group of individuals from industry and academia who are attempting to develop a standard for the representation and communication of mathematical information between distributed computer applications.
No one computer application does everything and information frequently needs to be shared by people and by applications. We need to be able to transfer mathematical objects between applications, even applications running on different computers. This transfer involves a transcription from the sender's internal representation of the object to one used by the receiver.
For example, application A contains an internal representation for a mathematical object. Application B needs to get A's object and represent it in B's own internal form. Once the transfer is made, B may manipulate the object and pass another object back to A. Or B may have no further need for A or even pass the object on to a third application.
Examples of such applications are:
There have been four OpenMath workshops sponsored in part by the European Community's HCM Network "Editing and Computing":
Forthcoming workshops will be held in
The fifth OpenMath Workshop will be held on Friday and Saturday, January 12 and 13, 1996, at the University of Bath, Bath, UK. The local coordinator for this workshop will be James H. Davenport.
A detailed program will be distributed several weeks before the workshop. It is anticipated that demonstrations of prototype OpenMath implementations will be available and that several talks will discuss details of the OpenMath Definition document.
To join the general OpenMath discussion, please send an e-mail message containing the line
to openmath-request@can.nl.
The OpenMath Definition Report is being prepared by several authors, including
Much of this talk is based on the report.
The author list will soon be expanded to include the members of the communications subcommittee.
[OpenMath workshops and discussion groups have included representatives from the Maple, Mathematica, AXIOM, and SINGULAR groups.]
We are dealing with the task of exchanging mathematical objects, with (perhaps) typographical, bibliographical, and other information attached.
In OpenMath we
The model consists of six layers:
The OpenMath Object is the highest level of representation (inside OpenMath) of a mathematical entity; it contains a maximum of semantic and structural information. OpenMath guarantees that whenever an OpenMath Object is sent via OpenMath, the received copy will be (semantically) equivalent to the original.
Encoding is a linearization of the data structures. We foresee
three probable encodings:
For an application to be OpenMath-compliant, the following must be true: if an internal object is encoded and then decoded using OpenMath, the resulting object must be semantically equivalent to the first object.
It is not necessary for an OpenMath-compliant application to actually implement all the above layers: it is sufficient to create a valid encoding from an internal form or vice-versa.
Note, however, that the translations must produce objects that are semantically equivalent to those produced by an application using the OpenMath model and the rules for moving between layers.
As OpenMath focuses on exchanging semantical contents, we need an object that represents the intended meaning of mathematical concepts. Such an object is called a context and deals with a certain area of mathematics or computation. There will be contexts for linear algebra, polynomials, trigonometry and so on.
A context can depend upon other contexts. This is called nesting or inheritance. The set of contexts forms a directed acyclic graph with one unique root context called the OpenMathContext. All other contexts implicitly inherit from OpenMathContext and all other inheritance must be explicitly listed.
A context is a named object that can contain
Operation signatures are similar to those in AXIOM:
It is not usually mandatory for a application that "understands" a context to actually implement functions for all operation signatures.
[But implementation can be queried and opsigs can be marked as requiring implementation.]
A phrase book is an application-specific module that translates to and from the application's internal object representation and the OpenMath Object representation. Clearly, there is a non-trivial relationship between phrase books and contexts: as the phrase book is used to generate OpenMath objects, various contexts are queried and specified to state the object semantics.
Note that OpenMath defines the form for contexts but the implementation of a phrase book is up to the application programmer.