A More Canonical Form of Content MathML to Facilitate Math Search

Many common equivalences in mathematics are due to commutative and associative laws. In the math search problem domain, handling these equivalences poses a challenge, but the nature of Content MathML and the use of XPath queries make way for an easy solution. Using Content MathML, a mathematical expression is encoded as an ordered labeled tree where nodes correspond to operators, relations, functions and values that correspond to the prefix notation of that expression; where an apply element is used to apply operators and functions to a set of arguments. For example, when encoding 2 + 3 , a prefix tree will be created where the apply element is the parent of three children + , 2 and 3

<apply> <plus/> <cn>2</cn> <cn>3</cn> </apply>

When creating an XML Query to search for that expression, the search will be for a specific structural pattern (an apply with three children: plus, 2 and 3) where the order of the children can be specified or ignored. As a result, in the case of commutative binary operator: + , × , and , or , xor , order is not important. Consequently, the equivalences related to commutative law will be handled on the math query processing side by simply identifying these operators and creating the corresponding XML Query where the order of these operands is immaterial.

Handling equivalences due to associativity is also straightforward because binary operators where the associativity law holds ( + , × , and , or , xor , > , >= , < , <= ) correspond to n-ary operators in Content MathML. For example, when encoding the following expressions 2 + 3 + 4 , there can be two equivalent Content MathML encodings, the first encoding treats plus as a binary operator applied to two operands 2 and sub expression 3 + 4 :

<apply> <plus/> <cn>2</cn> <apply> <plus/> <cn>3</cn> <cn>4</cn> </apply> </apply>

The second encoding treats plus as an n-ary operators; the following prefix tree is created where the plus operator has three operands:

<apply> <plus/> <cn>2</cn> <cn>3</cn> <cn>4</cn> </apply>

Converting binary operators that satisfy the associativity law into n-ary operators offers an easy solution to this problem. As a result, during the processing of mathematical content, whenever an associative relation such as 2 + 3 + 4 or 2 + 3 + 4 is encountered, it needs to be converted into an n-ary relation where + is applied to three operands 2, 3, and 4. This will dictate a conversion of the math query that searches for 2 + 3 + 4 or 2 + 3 + 4 into an n-ary relation and create the corresponding XML Query pattern for which to search. If the operator requires order of its elements ( > , >= , < , <= ) order will be specified in the XPath expression accordingly. Clearly, binary operators that are defined as n-ary operators in Content MathML are to be transformed into n-ary operators on the math query and content sides.

The inverse of a function in Content MathML is handled by applying the inverse element to a function. For example the following is the encoding of the inverse of the sin function sin - 1 x :

<apply> <apply> <inverse/> <sin/> </apply> <ci>x</ci> </apply>

Additionally, Content MathML offers a set of explicit predefined inverse functions for hyperbolic and trigonometric functions, arcsin for example, and results in the following encoding.

<apply> <arcsin/> <ci>x</ci> </apply>

Functions can be used as operators within apply elements or can be used as arguments to other operators. For example, the expression sin + cos , can be represented in the document as follow:

<apply> <plus/> <sin/> <cos/> </apply>

This is considered the addition of sin and cos functions in some function space according to the MathML specification document. However, in most cases a function is applied to its operands by enclosing it in an apply element and results in the following encoding:

<apply> <plus/> <apply><sin/>....</apply> <apply><cos/>....</apply> </apply>

If the user is searching for an addition operator applied to a sin and cos functions, then the user is searching for sin + cos ; the assumption is that he/she intends to search for sin added to cos in the second example regardless to what they're applied to. The two representations are similar where the first is a more general form of the other. However, both representations need to be allowed in the canonical form because an author can create a function as a complex expression, F + G ( x ) for example, where the plus operator will clearly use the more general form of encoding.

Another example is applying the integral to a sin function directly where the user is looking for the integral of a sin function that can be represented in the document as ∫ sin or ∫ sin x with the following Content MathML representations:

<apply> <int/><sin/> </apply>

or

<apply> <int/> <apply><sin/><ci>x</ci></apply> </apply>

A more complicated example is when applying an operator to a function that is represented as an identifier, as in the application of the differentiation operator to a function f. When querying, the user enters diff(f). On the document side, the derivative of a function f can be represented as f ' or f ' x

<apply> <diff/> <ci> f </ci> </apply>

or

<apply> <diff/> <apply> <ci type="function"> f </ci> <ci> x </ci> </apply> </apply>

When querying, both representations need to be retrieved.

As a result, when a user is searching for an operator with functions as its argument in the general form, the issue will be resolved on the query processing side by generating an XML Query to look for both representations.

When a variable f, for example, is considered as a function and applied to an argument, it can be represented in two ways, one way where the attribute type is used to specify that f is a function, and the other where the type attribute is omitted.

<apply> <ci type="function">f</ci> <ci>x</ci> </apply>

In the canonical form, when a variable is applied to any number of arguments, its type needs to be declared explicitly. This will provide for a better search when a user is looking for a function f. In this case, an XML Query expression will simply look for an identifier with the type attribute specified as a function.

Another issue is user-defined functions where the function itself is a compound expression. For example F + G ( x ) . Even though the plus operator is applied to two variables, clearly in this case the two variables are intended to be functions. These cases need to be identified and normalized accordingly by adding the type attribute set to function.

<apply> <apply> <plus/> <ci> F </ci> <ci>G </ci> </apply> <ci> x </ci> </apply>

The canonical form will not allow the use of deprecated representations from Content MathML version 1.0 that are discouraged. For example, the fn and reln elements are deprecated in MathML 2.0 in favor of the apply element and will not be supported by our canonical form. Another example is how MathML 2.0 represents mathematical constants. MathML 2.0 offers a more compact form where the constant is represented by a single construct. For example, imaginary I is represented using Content MathML 2.0 as <imaginaryi/>. In addition, MathML 2.0 supports two forms of representation of mathematical constants from version 1.0 but discouraged

For example, imaginary I can be also represented as: <cn type=constant> $ImaginaryI; </cn> and <cn type=constant>

During the normalization process, one way to handle these equivalences is to identify and transform the deprecated formats into the format that is introduced by MathML 2.0. For the purpose of this research, MathML documents in the repository will not include any discouraged representations from Content MathML 1.0

The element log can be used as either a binary operator (taking logbase as a qualifier) or as a unary operator. If a logarithmic base is not provided, logbase 10 is considered as the default value. As a result, the following two Content MathML expressions are equivalent:

<apply> <log/> <logbase> <cn> 10 </cn> </logbase> <ci> x </ci> </apply>

and

<apply> <log/> <ci> x </ci> </apply>

When the user is searching for a log, the user can specify the logbase in the query that will be transformed into the corresponding structure pattern. If the user specified a logbase of 10 then the search will be for a pattern that includes that logbase. But if the document does not include logbase 10 because it is the default value, then that document will not be retrieved. This equivalence can be resolved during the content normalization process by simply adding the logbase 10 as a qualifier when log is used as a unary operator in mathematical documents.

Another equivalence issue that is related to the logarithm is the use of the natural logarithm ln. Content MathML offers an explicit unary operator <ln/> to represent the natural logarithm. ln x for example, has the following encoding:

<apply> <ln/> <ci>x</ci> </apply>

The same expression can be encoded implicitly by using the log operator as a binary operator with the exponential as the logbase. ln x is equivalent to log e x and encoded as follows:

<apply> <log/> <logbase> <exponentiale/> </logbase> <ci>x</ci> </apply>

This equivalence will be handled the same way as the inverse of hyperbolic and trigonometric functions. Mathematical content that uses the implicit representation of the natural logarithm will be converted into the representation that used the ln operator. The user will be allowed to use both formats, and while processing the math query, a query that uses log e x will be converted into the ln x format.

When searching for an integer 4 for example, the user can simply write +4 or just 4. In a document, an integer can be represented in two equivalent MathML forms

<cn>+4</cn>

and

<cn>4</cn>.

To deal with this equivalence on the content side, all real, integer, and rational numbers that do not have an explicit positive sign will be assigned a + sign. The user on the math query side will not be required to make the positive sign explicit. But during math query processing, an explicit sign will be added.

Encoding a negative number can cause an equivalence issue. For example, -2 can be represented applying the minus operator as a unary arithmetic operator thus creating the additive inverse of the number 2 or by simply adding a negative sign in front of the number.

<apply> <minus/> <cn>2</cn> </apply>

and

<cn>-2</cn>

Additionally, when encoding the expression 2 - 3 for example, the number 3 can be encoded as the additive inverse of that number or can be encoded by simply applying the minus operator as a binary arithmetic (subtraction) on two positive numbers 2 and 3.

<apply> <plus/> <cn>2</cn> <apply> <minus/> <cn>3</cn> </apply> </apply>

and

<apply> <minus/> <cn>+2</cn> <cn>+3</cn> </apply>

In the canonical form, when minus is used as a binary operator, it will be considered as a representation of the subtraction operation and it will not be considered as the additive inverse of the second argument. In addition, any number where the minus is used as a unary operator to negate will be replaced by the same number representation with the negative sign added to it.

The composition of functions f and g, denoted f o g , can be represented as the application of the compose element to f and g. In addition, the same expression can be represented using a nested apply f g x . Both representations are equivalent, and there needs to be a decision as to what MathML representation should be allowed in the normalized form while allowing the use of both representations in the math query language.

<apply> <apply> <compose/> <ci type="function"> f </ci> <ci type="function"> g </ci> </apply> <ci> x <ci/> </apply>

and

<apply> <ci type="function"> f </ci> <apply> <ci type="function"> g </ci> <ci> x </ci> <apply> </apply>

The normalized form should support the use of the compose element and convert the nested application of functions into that format.

Additionally, the compose element in Content MathML is an n-ary operator, meaning, f o g o h can have two equivalent representations even when using the compose element. This issue is similar in nature to the issue of handling equivalences due to associative laws discussed earlier and will have a similar solution.

Integrals can be made definite by specifying the domain of integration. These restrictions can be represented by specifying limits (upper and lower) on bound variables or by simply specifying an interval or a condition. The lowlimit and uplimit pair is used along with bound variables in Content MathML that correspond to this notation ∫ 0 a f x .

<apply> <int/> <bvar><ci>x</ci></bvar> <lowlimit><cn>0</cn></lowlimit> <uplimit><ci>a</ci></uplimit> <apply> <ci>f</ci> <ci>x</ci> </apply> </apply>

The same expression can be represented using an interval instead of limits ∫ [ 0 , a ] f ( x ) using the following Content MathML representation:

<apply> <int/> <interval> <cn>0</cn> <ci>a</ci> </interval> <apply> <ci type="fn">f</ci> <ci>x</ci> </apply> </apply>

The use of interval in the representation of an integral, as fas a search is concerned, can be viewed as a more general case of ∫ 0 a f x since Content MathML does not require the use of a bound variable in that case. When querying, both syntaxes need to be allowed in the math query language. In the normalization process however, the canonical form needs to be restricted to one form over the other. In this case, the canonical form will be limited to the use of limits and any use of interval element will be converted into lowlimit and uplimit elements. This is possible because the type of closure in the case of intervals associated with integrals is considered irrelevant as far as search is concerned. This eliminates the need to create OR XQuery expressions that search for both forms.

In Content MathML, the total order of differentiation can be specified using an optional degree element because each identifier used in the partial differentiation can have its own order specified. As a result, ∂ 2 ∂ x ∂ y f can have two equivalent representations: One with the total order of partial derivative specified and one without

<apply> <partialdiff/> <bvar><ci> x </ci><degree><cn> 1 </cn></degree></bvar> <bvar><ci> y </ci><degree><cn> 1 </cn></degree></bvar> <degree><cn> 2 </cn></degree> <ci type="function"> f </ci> </apply>

or

<apply> <partialdiff/> <bvar><ci> x </ci><degree><cn> 1 </cn></degree></bvar> <bvar><ci> y </ci><degree><cn> 1 </cn></degree></bvar> <ci type="function"> f </ci> </apply>

The total order of partial differentiation will remain optional in the canonical form because it can be inferred since each bound variable can have its own order specified, also the user will not query for the total order.

<apply> <partialdiff/> <bvar><ci> x </ci><degree><cn> 2 </cn></degree></bvar> <ci type="function"> f </ci> </apply>

or

<apply> <partialdiff/> <bvar><ci> x </ci></bvar> <bvar><ci> x </ci></bvar> <ci type="function"> f </ci> </apply>

This equivalence needs to be resolved on the canonical form where the author cannot declare that variable multiple times and instead the author is required to specify an order of the partial derivative associated with each identifier used even if it is of the first order. On the query side, however, the syntax of the query language will not allow the user to repeat an identifier, and if the user specified a variable without an order, the assumption is that the order of the partial derivative associated with that identifier is 1.

Additionally, order of the identifiers for the partial derivative is preserved using Content MathML. For example, ∂ 2 ∂ x ∂ y f is different from ∂ 2 ∂ y ∂ x f . For the purposes of this research, the assumption is that order of partial differentiation is irrelevant as far as search is concerned. As a result, when the user writes D_{x,y}(f), it is equivalent to D_{y,x}(f) query.

Vectors are represented using a designated vector element. However, Content MathML regards vectors as equivalent to a single-column matrix where the transpose of a vector is equivalent to a single-row matrix. As a result, in documents, a vector [1, 2, 3] can be represented in three different equivalent formats: as a vector, as matrix with a single row, or as a matrix with a single column.

<vector> <cn> 1 </cn> <cn> 2 </cn> <cn> 3 </cn> </vector>

or

<matrix> <matrixrow> <cn> 1 </cn> <cn> 2 </cn> <cn> 3 </cn> </matrixrow> </matrix>

or

<matrix> <matrixrow><cn> 1 </cn></matrixrow> <matrixrow><cn> 2 </cn></matrixrow> <matrixrow><cn> 3 </cn></matrixrow> </matrix>

On the content side, however, because of matrix multiplication, the author should not be restricted to one representation of a vector and any notational equivalence issue needs to be resolved on the math query side through the creation of appropriate OR queries. On the math query side, however, there is not a designated syntax for a vector; the user can simply query for a vector by specifying a matrix with a single row or column. For example, the user query matrix[a; b; c] will generate an XPath expression looking for a vector OR a matrix with a single row OR a matrix with a single column with the elements 1, 2 and 3 according to that order.

The type attribute used in cn and ci elements indicates the type of the number or variable respectively. It is also used in the declare element when creating user defined variables or functions. The user is allowed to search for numbers and variables of specific types, but the authors are not required to set the type attribute in their cn and ci elements. These elements do have a default type value, real for cn and empty string for ci. One way to normalize these elements is to set their type value; however, this might interfere with the author's intent when not declaring a type. For example, an author can write <cn>2</cn> and intend this to be an integer. In this case, adding the default type value of real will be erroneous. Searching for variables or numbers with a specific type in the case of documents where the author did not specify a particular type is an issue. One solution could be to require the author to specify the type attribute associated with Content MathML elements. This can either be done directly in the case of the cn number or through the use of the declare elements where an identifier is associated with a particular type.

In addition, the attribute values for Content MathML elements, if present, should be normalized by removing surrounding white spaces. The assumption at this time is that authors do specify a value for the type attribute for cn and ci elements and that when attributes are present, their values are normalized.