Notations for Formula Presentations

OMDoc documents are made of mathematical items which can contain mathematical formulas; the latter may be presented to the screen or print media. The ActiveMath presentation system uses XSLT and Velocity to convert the OMDoc fragments to rendered HTML, XHTML, or PDF. For the mathematical formula to be presented well, an amount of notations are defined which produce XSLT templates.

This handbook page explains by examples how notations are conceived, authored, and used in ActiveMath.

Notations are, traditionally, rules to encode graphically a conceptual construction.

ActiveMath notations are similar, they are made of:

  • a prototype OpenMath expression
  • the rendering of this prototype in MathML-presentation
  • a few extra attributes that describe the context of this notation

These prototypes are enough for ActiveMath to generate a stylesheet that will render any expression to HTML, MathML, and TeX. 

In ActiveMath, notations are provided by any collection that is loaded. To see the notations defined in your current ActiveMath, invoke Tools > Symbol Presentations.
This tool allows you to test the rendering of an OpenMath expression or to get a list of all the notations defined.
Try this on the ActiveMath demo as user eva.

The fact that any collection can contain notations may lead to conflicts... currently, these are not reported but the resulting notation is the "concatenation of the two notations", quite a visible effect! 

A basic example

Let us construct a basic example for the symbol free-group:

<symbolpresentation id="pres-free-group1" xref="free-group">
<notation>
<OMOBJ>
<OMA>
<OMS cd="free-groups" name="free-group"/>
<OMV name="alphabet"/>
</OMA>
</OMOBJ>
<math>
<mrow>
<mo>F(</mo>
<mi>A</mi>
<mo>)</mo>
</mrow>
</math>
</notation>
</symbolpresentation>

This first example will render expressions such as this prototype. Let us try, with the notations of the jEditOQMath tutorial, to render $Fn(S)$. You should obtain something similar to F(S).

If not using SluMBase, ActiveMath needs to be restarted everytime the notations have been changed. Alternatively, one can use the symbol-presentation-tool.

Note the variable names: the OpenMath expression has a variable, named A, which is the same as the content of the MathML's mi element: all variables are replaced this way.

Having the OpenMath in mind is a good idea here since authoring notations involves fine-grained OpenMath matching. But nothing prevents you to use a QMath expression instead of the OpenMath, yielding instead:

<symbolpresentation id="pres-free-group1" xref="free-group">
<notation>$Fn(A)$
<math>
<mrow>
<mo>F(</mo>
<mi>A</mi>
<mo>)</mo>
</mrow>
</math>
</notation>
</symbolpresentation>

 Multiple Parameters

Now, what about the formula written down as F(a,b), the free group on two generators?
If you try to input $Fn(a,b)$, you will get a non-presented-symbol free-group(a,b) which is not what one wishes. Actually, this formula does not use the same notation, it has been shortened once more by the removal of the bracket. One needs to add a notation for this:

<symbolpresentation  id="pres-free-group2" xref="free-group">
<notation>
<OMOBJ>
<OMA>
<OMS cd="free-groups" name="free-group"/>
<OMA>
<OMS cd="set1" name="set"/>
<OMV name="a"/><OMV name="b"/>
</OMA>
</OMA>
</OMOBJ>
<math>
<mrow>
<mo>F(</mo>
<mi>a</mi>
<mo>,</mo>
<mi>b</mi>
<mo>)</mo>
</mrow>
</math>
</notation>
</symbolpresentation>

The scary bit here is that we would need to introduce a notation for each possible size of the generating set... instead we need n-arity for which a special symbol in the ompe content-dictionary has been defined and a special element in MathML has been allowed:

<symbolpresentation  id="pres-free-group2" xref="free-group">
<notation>
<OMOBJ>
<OMA>
<OMS cd="free-groups" name="free-group"/>
<OMA>
<OMS cd="set1" name="set"/>
<OMA><OMS cd="ompe" name="nary"/>
<OMV name="x"/>
</OMA>
</OMA>
<OMV name="alphabet"/>
</OMA>
</OMOBJ>
<math>
<mrow>
<mo>F(</mo>
<nary>
<mi>x</mi>
<mo>,</mo>
</nary>
<mo>)</mo>
</mrow>
</math>
</notation>
</symbolpresentation>

To be continued, about:

  • clickability of the symbols and mo
  • Various attributes of the notations element which yields the various contexts when a notation is chosen (e.g. language, learning-context, ...)
  • And example with various learning contexts as can be seen in the example ActiveMath content

Trackback URL for this post:

http://eds.activemath.org/en/trackback/13

Back to Basics

>OMDoc documents are made of mathematical items which can contain
>mathematical formulas

What does this mean?
What constitutes mathematical items and mathematical formulae?
Which type of input from which type of input/output source is allowable?
What is the BNF ("Backus Naur Form") ?

Re: Back to basics

Albert,

this is kind of a general question which is at least answered in the DTD and the tutorial.

Here are direct short answers:

What does this mean?

It does mean that the textual content of a mathematical item is made of an interleave of characters and OMOBJ elements. This textual content is encoded in XML as child-content of the CMP elements.

What constitutes mathematical items and mathematical formulae?

”Mathematical items” is the name given to the OMDoc content entities, they are XML elements representing such entities as definitions, examples, exercises, theorems, proofs, motiviations…. In more technical terms, mathematical items are considered to be all possible children of the theory element which can have a CMP child.

Which type of input from which type of input/output source is allowable?

Strictly speaking, only text content and OMOBJ elements are allowed. If you are using the OQMath processor then you can write the OMOBJ using the QMath compact syntax (see the tutorial) which is then replaced by an OMOBJ element.

What is the BNF (“Backus Naur Form”) ?

For just CMPs, a summary of OMDoc would be inCMP = (characters|OMOBJ)*. This is too short since textref, omlet and other elements are actually also allowed as child of the CMP elements. Using jEditOQMath and pressing “<” should give you the possible children at each point.

To get a better idea of the structure, you could use DTD-explorer, e.g. the combined DTD example. It is not really complete but a full element-per-element reference documentation is known to be a missing piece (see, e.g., AMATH-520, for which I have not yet found a real convincing solution, would be willing to start a discussion about that).