Future Development

The future development discussion has been well thought in the MathLang group. Most of the ideas has been discussed in many occasions during weekly group meet- ings. They have been initially and partially described in MathLang papers, but were then put together and summarised in the thesis of M. Maarek. In this sec- tion we recall them and shortly present them to the reader nin order to provide a general idea of further MathLang development challenges.

7.1.2.1 Extending DRa

The DRa encoding system is a part of the ongoing MathLang project. As future work, we need to concentrate on the evaluation and improvement of the DRa sys- tem and to test it on a number of bigger examples. We also need to work further on the DRa ontology and to refine the instances of the class StructuralRhetorical- Role. Namely, we need to separate the depth level of structural units labels from the actual meaning of a unit. For instance “section” and “subsection”, for the representation purposes, differ only in the embedded relation. Therefore we have to investigate how the depth level can be incorporated within the DRa ontology.

One of the advantages of the DRa encoding is modularization. We still need to investigate how this modularization should work, and how we can actually reuse the annotated distinct chunks of text in other documents. In addition to that, we need to research how we can relate some parts of a document in another document.

This would require a review of both aspects CGa and DRa.

We also need to investigate how a mathematician could add his own intended relation to the DRa system. For instance, he might want to add the explanationOf relation which could be used to express the statement: “this example is an ex- planation of such definition”, which might be written in the RDF triples format like that: (example, explanationOf, def inition). We have to incorporate this kind of possibilities within the DRa markup system.

7.1.2.2 Automatisation of CGa+TSa encoding

At the current development stage, the MathLang user is required to annotate and specify grammatical role (in a CGa aspect) for each symbol in every CML statement. In addition to that, the user has to write a signature (symbol name, number of input and output types together with their grammatical roles) for that symbol in the preamble of the document. In most of the cases, a lot of symbols are used more than once in a document, which still have to be annotated explicitly by the user. This makes the annotation process time consuming. We believe that this process can be done with a computer assistance and much faster if we develop specific software. Let us assume that the user annotates only the first instance/usage of a symbol and provides a signature of that symbol in the preamble. If this symbol has been used further in a document, the proposed tool should be able to parse the symbol and annotate it in the whole document accordingly to the signature provided in the preamble. Such a tool needs to be able to parse formulas of the original CML document, which is possible due to the presentation of the document in TEXmacs and XML format. Of course this annotation will be designed for a symbol whose spelling does not change across the whole document.

7.1.2.3 Informal Justification aspect (IJa)

The CGa aspect does not provide a direct way of linking reasoning statements or references to existing theorems. In the CML document it is usually done via the use of a number of words like: hence, since, then or by. This aspect will provide a way to annotate those references and link between statements.

In addition, the CGa local scoping does not provide a way to differentiate “considerations”, “assumptions” or “hypothesis” of declarations. The meaning of these textual components will be exposed by this aspect. The relations between them might be expressed with theb extended DRa. Such provided annotation will

be automatically checked and will complete the initial CGa structure into a more formal document.

7.1.2.4 Meta-logic aspect (MLa)

As described by M. Maarek in his thesis, another possible aspect for MathLang is concerned with “meta-logic”. A text that has been annotated with CGa+DRa+IJa contains the logic and semantic information that a CML document could have. Such text could possibly still contain holes in the reasoning and logic, but this purely depends on the author writing style. This aspect will provide a generic language to describe some of the existing logical frameworks. This would allow the user to chose the final destination framework he wants to work with (e.g., the Tarski-Grothendieck Set Theory – the Mizar system, the Zermelo-Frankel Set Theory – the Isabelle system, the Calculus of Inductive Constructions – the Coq system, etc.). A text annotated with the Meta-logic aspect will be analysed under the well-formation and well-use of the aspect. The proof itself will be checked in the final logical framework.

7.1.2.5 Automatisation while building the Mizar document

As we have seen, the theoretical formalisation and computer implementation of the first three aspects provided a number of useful tools that automatically generate a number of computerised versions of the text each used for a different purpose and each enjoys a different level of formality. It is important to research further automatisation of building a Mizar Text-Proper skeleton in the TEXmacs editor. Furthermore, it is useful to have an additional tool for supporting the transfor- mation of the CGa annotated statements into the Mizar formula level. It is also important to study in depth the stage where a Mizar FPS version is fully formalised into Mizar. A number of issues need to be investigated to support building Mizar statements:

• How to employ search engines (like grep or semantic mining MML Query) to look up MML in order to find a proper Mizar counterpart for an identifier used in a CML text and explicitly stated in its MathLang CGa version. • How the MathLang noun description construction could be reused to find a

• How to deal with the freedom that MathLang gives while computerising a common mathematical document.

• We also need to express the hints for transforming a dependency graph into a Mizar FPS Text-Proper skeleton, in terms of formal rules which we aim to prove correct and to implement. Moreover, our aim is to start building a computer tool which will support the Mizar specialist with the migration process from a CML+MathLang document to Mizar FPS.