OpenMath 2 Table of Contents

Previous: 3 OpenMath Encodings
This: 4 Content Dictionaries
    4.1 Introduction
    4.2 Abstract Content Dictionaries
        4.2.1 Content Dictionary Status
        4.2.2 Content Dictionary Version Numbers
    4.3 The Reference Encoding for Content Dictionaries
        4.3.1 The Relax NG Schema for Content Dictionaries
        4.3.2 Further Description of the CD Schema
    4.4 Additional Information
        4.4.1 Signature Dictionaries
   Abstract Specification of a Signature Dictionary
   A Relax NG Schema for a Signature Dictionary
        4.4.2 CDGroups
   The Specification of CDGroups
   Further Requirements of a CDGroup
    4.5 Content Dictionaries Reviewing Process
Next: 5 OpenMath Compliance

Chapter 4
Content Dictionaries

In this chapter we give a brief overview of Content Dictionaries before explicitly stating their functionality and encoding.

4.1 Introduction

Content Dictionaries (CDs) are central to the OpenMath philosophy of transmitting mathematical information. It is the OpenMath Content Dictionaries which actually hold the meanings of the objects being transmitted.

For example if application A is talking to application B, and sends, say, an equation involving multiplication of matrices, then A and B must agree on what a matrix is, and on what matrix multiplication is, and even on what constitutes an equation. All this information is held within some Content Dictionaries which both applications agree upon.

A Content Dictionary holds the meanings of (various) mathematical "words". These words are OpenMath basic objects referred to as symbols in Section 2.1.

With a set of symbol definitions (perhaps from several Content Dictionaries), A and B can now talk in a common "language".

It is important to stress that it is not Content Dictionaries themselves which are being transmitted, but some "mathematics" whose definitions are held within the Content Dictionaries. This means that the applications must have already agreed on a set of Content Dictionaries which they "understand" (i.e., can cope with to some degree).

In many cases, the Content Dictionaries that an application understands will be constant, and be intrinsic to the application's mathematical use. However the above approach can also be used for applications which can handle every Content Dictionary (such as an OpenMath parser, or perhaps a typesetting system), or alternatively for applications which understand a changeable number of Content Dictionaries (perhaps after being sent Content Dictionaries in some way).

The primary use of Content Dictionaries is thought to be for designers of Phrasebooks, the programs which translate between the OpenMath mathematical object and the corresponding (often internal) structure of the particular application in question. For such a use the Content Dictionaries have themselves been designed to be as readable and precise as possible.

Another possible use for OpenMath Content Dictionaries could rely on their automatic comprehension by a machine (e.g., when given definitions of objects defined in terms of previously understood ones), in which case Content Dictionaries may have to be passed as data. Towards this end, a Content Dictionary has been written which contains a set of symbols sufficient to represent any other Content Dictionary. This means that Content Dictionaries may be passed in the same way as other (OpenMath) mathematical data.

Finally, the syntax of the reference encoding for Content Dictionaries has been designed to be relatively easy to learn and to write, and also free from the need for any specialist software. This is because it is acknowledged that there is an enormous amount of mathematical information to represent, and so most Content Dictionaries are written by "ordinary" mathematicians, encoding their particular fields of expertise. A further reason is that the mathematics conveyed by a specific Content Dictionary should be understandable independently of any application.

The key points from this section are:

4.2 Abstract Content Dictionaries

In this section we define the abstract structure of Content Dictionaries.

A Content Dictionary consists of the following mandatory pieces of information:

  1. A name corresponding to the rules described in Section 2.3.

  2. A description of the Content Dictionary.

  3. A revision date, the date of the last change to the Content Dictionary. Dates should be stored in the ISO-compliant format YYYY-MM-DD, e.g. 1966-02-03.

  4. A review date, a date until which the content dictionary is guaranteed to remain unchanged.

  5. A version number which consists of a major and minor part (see Section 4.2.2).

  6. A status, as described in Section 4.2.1.

  7. A CD base which, when combined with the CD name, forms a unique identifier for the Content Dictionary. It may or may not refer to an actual location from which it can be retrieved.

  8. A series of one or more symbol definitions as described below.

A symbol definition consists of the following pieces of information:

  1. A mandatory name corresponding to the rules described in Section 2.3.

  2. A mandatory description of the symbol, which can be as formal or informal as the author likes.

  3. An optional role as described in Section 2.1.4.

  4. Zero or more commented mathematical properties which are mathematical properties of the symbol expressed in a mechanism other than OpenMath.

  5. Zero or more formal mathematical properties which are mathematical properties of the symbol expressed in OpenMath. Note that it is common for commented and formal mathematical properties to be introduced in pairs, with the former describing the latter.

    A Formal Mathematical Property may be given an optional kind attribute. An author of a Content Dictionary may use this to indicate whether, for example, the property provides an algorithm for evaluation of the concept it is associated with. At present no fixed scheme is mandated for how this information should be encoded or used by an application.

  6. Zero or more examples which are intended to demonstrate the use of the symbol within an OpenMath object.

Some pieces of information which might logically be thought to be part of a Content Dictionary, such as the types or signatures of symbols, are better represented externally. This allows for new variants to be associated with Content Dictionaries without the Dictionaries themselves being changed. A model for signatures is given in Section 4.4.1.

Content Dictionaries may be grouped into CD Groups. These groups allow applications to easily refer to collections of Content Dictionaries. One particular CDGroup of interest is the "MathML CDGroup". This group consists of the collection of core Content Dictionaries that is designed to have the same semantic scope as the content elements of MathML 2 [17]. OpenMath objects built from symbols that come from Content Dictionaries in this CDGroup may be expected to be easily transformed between OpenMath and MathML encodings. The detailed structure of a CDGroup is described in Section 4.4.2 below.

4.2.1 Content Dictionary Status

The status of a Content Dictionary can be either

  • official: approved by the OpenMath Society according to the procedure outlined in Section 4.5;

  • experimental: under development and thus liable to change;

  • private: used by a private group of OpenMath users;

  • obsolete: an obsolete Content Dictionary kept only for archival purposes.

4.2.2 Content Dictionary Version Numbers

A version number must consist of two parts, a major version and a revision, both of which should be non-negative integers. In CDs that do not have status experimental, the version number should be a positive integer.

Unless a CD has status experimental, no changes should ever be introduced that invalidate objects built with previous versions. Any change that influences phrasebook compliance, like adding a new symbol to a Content Dictionary, is considered a major change and should be reflected by an increase in the major version number. Other changes, like adding an example or correcting a description, are considered minor changes. For minor changes the version number is not changed, but an increase should be made to the revision number. Note that a change such as removing a symbol should not be made unless the CD has status experimental. Should this be required then a new CD with a different name should be produced so as not to invalidate existing objects.

When the major version number is increased, the revision number is normally reset to zero.

As detailed in Chapter 5, OpenMath compliant applications state which versions of which CDs they support.

4.3 The Reference Encoding for Content Dictionaries

The reference encoding of Content Dictionaries are as XML documents. A valid Content Dictionary document should conform to the Relax NG Schema for Content Dictionaries given in Section 4.3.1.

An example of a complete Content Dictionary is given in Appendix Appendix A.1, which is the Meta Content Dictionary for describing Content Dictionaries themselves. A more typical Content Dictionary is given in Appendix A.2, the arith1 Content Dictionary for basic arithmetic functions.

4.3.1 The Relax NG Schema for Content Dictionaries

	# *********************************************
# Relax NG Schema for OpenMath CD
# *********************************************

default namespace = ""

include "openmath2.rnc" {start = CD}

CDComment = element CDComment { text }
CDName = element CDName { xsd:NCName }
CDUses = element CDUses { CDName* }
CDURL = element CDURL { xsd:anyURI }
CDBase = element CDBase { xsd:anyURI }
text-or-om = (text | OMOBJ)*
CDReviewDate = element CDReviewDate { xsd:date }
CDDate = element CDDate { xsd:date }
CDVersion = element CDVersion { xsd:nonNegativeInteger }
CDRevision = element CDRevision { xsd:nonNegativeInteger }
CDStatus = element CDStatus {
   "official" |
   "experimental" |
   "private" |
Description = element Description { text }
Name = element Name { xsd:NCName }
Role = element Role {
   "binder" |
   "attribution" |
   "semantic-attribution" |
   "error" |
   "application" |
   "constant" }
CMP = element CMP { text }
FMP = element FMP { 
  attribute kind {xsd:string}?,
# allow embedded OM
Example = element Example { text-or-om }
CDDefinition =
  element CDDefinition {
    (Name & Role? & Description),
   (CDComment | Example | FMP | CMP)*
CD =
  element CD {
    (CDComment* & Description? &
     CDName & CDURL? & CDBase? &
     CDReviewDate? & CDDate & CDStatus & 
     CDUses? & 
     CDVersion & CDRevision),
    ( CDDefinition,CDComment* )+


4.3.2 Further Description of the CD Schema

We now describe the elements used in the above schema in terms of the abstract description of CDs in Section 4.2. Unless stated otherwise information is encoded as the content of the relevant element.


The name of the Content Dictionary.


The text occurring in the Description element is used to give a description of the enclosing element, which could be a symbol or the entire Content Dictionary. The content of this element can be any XML text.


The review date of the Content Dictionary.


The revision date of this version of the Content Dictionary.


The major version number of the CD.


The minor version number of the CD.


The status of the Content Dictionary.


The CD base of the CD.


The text occurring in the CDURL element should be a valid URL where the source file for the Content Dictionary encoding can be found (if it exists). The filename should conform to ISO 9660 [11].


The content of this element should be a series of CDName elements, each naming a Content Dictionary used in the Example and FMPs of the current Content Dictionary. This element is optional and deprecated since the information can easily be extracted automatically.


The content of this element should be text that does not convey any crucial information concerning the current Content Dictionary. It can be used in the Content Dictionary header to report the author of the Content Dictionary and to log change information. In the body of the Content Dictionary, it can be used to attach extra remarks to certain symbols.


The element which contains the definition of an individual symbol.


The name of a symbol.


The role of a symbol: it must be one of binder, attribution, semantic-attribution, error, application, or constant.


The text occurring in the Example element is used to give examples of the enclosing symbol, and can be any XML text. In addition to text the element may contain examples as XML encoded OpenMath, inside OMOBJ elements. Note that Examples must be with respect to some symbol and cannot be "loose" in the Content Dictionary.


A Commented Mathematical Property.


A Formal Mathematical Property. It may take an optional kind attribute.

4.4 Additional Information

Content Dictionaries contain just one part of the information that can be associated to a symbol in order to define its meaning and its functionality. OpenMath Signature dictionaries, CDGroups, and possibly collections of extra mathematical properties, are used to convey the different aspects that as a whole make up a mathematical definition.

4.4.1 Signature Dictionaries

OpenMath may be used with any type system. One just needs to produce a Content Dictionary which gives the constructors of the type system, and then one may build OpenMath objects representing types in the given type system. These are typically associated with OpenMath objects via the OpenMath attribution constructor.

A Small Type System, called STS, has been designed to give semi-formal signatures to OpenMath symbols and is documented in [4]. The signature file given in Appendix A.3 is based on this formalism. Using the same mechanism, [3] shows how pure type systems can also be employed to assign types to OpenMath symbols. Abstract Specification of a Signature Dictionary

Signature dictionaries have a header which specifies the type system being used and the Content Dictionary containing the symbols for which signatures are being given. Each signature takes the form of an OpenMath object in an appropriate encoding.

  1. A type definition: the name of the Content Dictionary or of the CDGroup (cfg. Section 4.4.2) that represents the type system being used.

  2. A CD name: the name of the CD for which signatures are being defined.

  3. A review date as defined in Section 4.2.

  4. A status: as defined in Section 4.2.

  5. A series of signatures which are OpenMath objects in some encoding. The objects must represent types as defined by the type definition. A Relax NG Schema for a Signature Dictionary

The following is a reference encoding of a signature dictionary, designed to be used with Content Dictionaries in the XML encoding.

# *********************************************
# Relax NG Schema for OpenMath CD Signatures
# *********************************************

default namespace = ""

include "openmath2.rnc" { start = CDSignatures }

CDSComment = element CDSComment { text }
CDSReviewDate = element CDSReviewDate { text }
CDSStatus = element CDSStatus {
   "official" |
   "experimental" |
   "private" |
CDSignatures =
  element CDSignatures {
    (CDSReviewDate? & CDSStatus),
    (CDSComment | Signature)*
attlist.CDSignatures =
  attribute cd { xsd:NCName },
  attribute type { xsd:NCName }
Signature = element Signature { attlist.Signature, OMOBJ? }
attlist.Signature = attribute name { text } Examples

An example of a signature dictionary for the type system STS and the arith1 Content Dictionary is given in Appendix A.3. Each signature entry is similar to the following one for the OpenMath symbol <OMS cd="arith1" name="plus"/>:

<Signature name="plus">
<OMOBJ version="2.0">
  <OMS name="mapsto" cd="sts"/>
   <OMS name="nassoc" cd="sts"/> 
   <OMV name="AbelianSemiGroup"/>
  <OMV name="AbelianSemiGroup"/>

4.4.2 CDGroups

The CD Group mechanism is a convenience mechanism for identifying collections of CDs. A CD Group file is an XML document used in the (static or dynamic) negotiation phase where communicating applications declare and agree on the Content Dictionaries which they process. It is a complement, or an alternative, to the individual declaration of Content Dictionaries understood by an application. Note that CD Groups do not affect the OpenMath objects themselves. Symbols in an object always refer to content dictionaries, not groups.

For an application to declare that it "understands CDGroup G" is exactly equivalent to, and interchangeable with, the declaration that it "understands Content Dictionaries x1, x2  xn", where x1  xn are the members of CDGroup G. The Specification of CDGroups

CDGroups are XML documents, hence a valid CDGroup should

  • be valid according to the schema given in Figure 4.1,

  • adhere to the extra conditions on the content of the elements given in Section

Apart from some header information such as CDGroupName and CDGroup version, a CDGroup is simply an unordered list of CDs, identified by name and optionally version number and URL.

# Schema for OpenMath CD groups

# info on the CD group itself

default namespace = ""

CDGroupName = element CDGroupName { xsd:NCName }
CDGroupVersion = element CDGroupVersion { xsd:nonNegativeInteger }
CDGroupRevision = element CDGroupRevision { xsd:nonNegativeInteger }
CDGroupURL = element CDGroupURL { text }
CDGroupDescription = element CDGroupDescription { text }
# info on the CDs in the group
CDComment = element CDComment { text }
CDGroupMember =
  element CDGroupMember {
    CDComment?, CDName, CDVersion?, CDURL?
CDName = element CDName { xsd:NCName }
CDVersion = element CDVersion { xsd:nonNegativeInteger }
CDURL = element CDURL { text }
# structure of the group
CDGroup =
  element CDGroup {
    (CDGroupMember | CDComment)*
start = CDGroup

Figure 4.1 Relax NG Specification of CDGroups Further Requirements of a CDGroup

The notion of being a valid CDGroup implies that the following requirements on the content of the elements described by the schema given in Section are also met.


The XML element CDGroup is the outermost element in a CDGroup document.


The text occurring in the CDGroupName element corresponds to the name of the CDGroup. For the syntactical requirements, see CDName in Section 4.3.2.


The text occurring in these elements contains the major and minor version numbers of the CDGroup.


The text occurring in the CDGroupURL element identifies the location of the CDGroup file, not necessarily of the member Content Dictionaries. For the syntactical requirements, see CDURL in Section 4.3.2.


The text occurring in the CDGroupDescription element describes the mathematical area of the CDGroup.


The XML element CDGroupMember encloses the data identifying each member of the CDGroup.


The text occurring in the CDName element corresponds to the name of a Content Dictionary in the CDGroup. For the syntactical requirements, see CDName in Section 4.3.2.


The text occurring in the CDVersion element identifies which version of the Content Dictionary is to be taken as member of the CDGroup. This element is optional. In case it is missing, the latest version is the one included in the CDGroup. For the syntactical requirements, see CDVersion in Section 4.3.2.


The text occurring in the CDURL element identifies the location of the Content Dictionary to be taken as member of the CDGroup. This element is optional. In case it is missing, the location of the CDGroup identified by the element CDGroupURL is assumed. For the syntactical requirements, see CDURL in Section 4.3.2.


See CDComment in Section 4.3.2.

4.5 Content Dictionaries Reviewing Process

The OpenMath Society is responsible for implementing a review and referee process to assess the accuracy of the mathematical content of Content Dictionaries. The status (see CDStatus) and/or the version number (see CDVersion ) of a Content Dictionary may change as a result of this review process.

OpenMath 2 Table of Contents

Previous: 3 OpenMath Encodings
This: 4 Content Dictionaries
Next: 5 OpenMath Compliance