Shared mathematical meaning
Math-in-the-Middle connects system-specific descriptions to a common mathematical ontology. It grew within OpenDreamKit’s work on research environments for open mathematical software. Its central concern is semantic interoperability: exchanging a value is useful only when the receiving system interprets it correctly. Original paper
The research extends beyond a common file format. A mathematical operation has a domain, a result, and conventions that may differ between implementations. A system’s interface theory describes its concepts in relation to the shared ontology. That connection gives software a basis for translating operations and their arguments.
An adapter can preserve bytes and change meaning
Consider a proposed Axeyum adapter for a rational polynomial. One component might store coefficients in ascending order of degree; another might expect the leading coefficient first. A serializer can round-trip the list perfectly while an adapter gives it the wrong mathematical interpretation.
The contract therefore needs to describe the coefficient convention, the coefficient domain, and the variable. If the operation returns a root interval, the output contract must also specify whether the interval isolates one root, encloses at least one root, or only meets an approximation criterion. These are different guarantees.
This is an illustrative design test, not a reported defect in the compared systems. It shows why Axeyum should test semantics as well as serialization when it joins a CAS operation to a formal statement. MitM’s work on mathematical interfaces offers a relevant starting point.
Evidence of integration
The early paper reports initial interface experiments. Later OpenDreamKit deliverables describe distributed computations involving GAP, SageMath, LMFDB, and Singular, together with curated ontology contents and alignments. A fair account must include that later implementation evidence. D6.5 integration report, D6.8 ontology report
The project reports are evidence of the authors’ implementations and evaluations. This comparison has not rerun the historical environment. It also has not established that every integration returns a certificate accepted by Axeyum’s kernel. Semantic integration and output verification require separate examinations.
Comparison with Axeyum
Axeyum distinguishes a producer contract, which describes work that can be attempted, from a receipt for accepted work. A semantic interface adds another necessary question: what does that attempted operation mean for the particular input? Pinned frontier implementation
An Axeyum operation contract should state mathematical preconditions and representation conventions alongside its evidence requirement. A successful process exit cannot establish that an approximate result satisfies an exact theorem. A kernel proof of a translated statement cannot by itself establish that the translation matches the user’s intended problem.
A useful next experiment would connect one actual CAS operation to one native statement family. It should retain the input representation, conversion evidence, returned result, and acceptance decision. Deliberately mismatched coefficient conventions and guarantees should fail before the result enters later reasoning.
That gives the integrated-system vision a measurable obligation. The system must preserve mathematical meaning across each boundary it traverses. MitM is prior work on precisely that problem, and its experience should inform Axeyum’s interfaces rather than be reduced to a list of external tool connections.