Forum: Instiki – Topic: Bugs

Apparently, math is completely broken in Opera 12. I installed Opera 12 today and since then, I’ve been getting “Error parsing MathML: ErrorUnknown source” errors in place of every formula. Firefox works fine, so it’s not a server bug.

On http://golem.ph.utexas.edu/wiki/instiki/show/Sandbox I get the error message, while the demos from http://www.mathjax.org/demos/ work without complaint, so I guess it’s an instiki or itex2mml bug - or a bug in Opera, of course.

Forum: Instiki – Topic: Feature Requests

Sorry for not answering for so long - but I would still like to discuss the feature I wrote about a few months ago.

Is this a feature that is implemented somewhere? :

Your short description is slightly … underspecified. So looking at an actual implementation would be helpful to me, in deciding whether this is something to implement in Instiki.

That’s true, my description is underspecified - it was just some ideas shooting through my head that I didn’t formulate clearly, and I also didn’t research existing approaches. The problem can be described as follows:

Both mathematical concepts and their presentation are moving targets. Mathematical notation is developed together with mathematical concepts and is permanently being refined afterwards, as one can witness in the discussions on nLab. Notations are the “interface” through which humans interact with mathematical concepts, so elegant, intuitive, consistent notations are important for understanding them. However, it has been a time-consuming job to keep notations consistent and to update existing work to new notations, effectively impeding the improvement of notation and in the end mathematics itself - at least because of time wasted, and IMO also by suboptimal notation leading to suboptimal intuition.

I think that this is a consequence of a deeper problem, namely that authors have to manipulate the presentation of the mathematical concepts they describe. My opinion is that in collaborative mathematics platforms, article authors should rather manipulate the mathematical concepts themselves. TeX-derived typesetting systems are very good at typesetting mathematical notation and should be used for presentation, but when describing mathematical concepts, you shouldn’t be bothered with such details. Rather than using TeX, I’d suggest using syntax customized for the respective field of mathematics.

What I wanted to point out is that software for collaborative mathematics platforms like nLab may offer the chance to solve that problem and maybe even endorse improvement of mathematical notation by making a clear distinction between mathematical notation on the one hand, and mathematical presentation on the other hand. Mathematical concepts would be stored using a schema/ontology spanning all fields of mathematics. Mathematical notation (=wiki syntax) defined for each respective field of mathematics could then be used to write about these concepts. The presentation would be implemented using transformation from the schema/ontology to MathML or TeX or whatever.

Once there is a mechanism for representing ontologies/schemata of mathematical concepts, it becomes possible for authors to choose any notation offered, or define their own. When the notation is changed to a newer version, automatic migration schemes may enable easier switching to new notation. And as for the presentation, the reader could then himself decide whether he prefers the comma category written using a downwards arrow or a slash.

I actually found a project that might have similar aims, namely SWiM. But what I see in the related article doesn’t really look like what I’d expect from a wiki - the source code in the screenshot on page 4 looks worse than LISP, in my eyes. I think that this problem is caused by forcing authors to use some one-size-fits-all notation of OpenMath or similar, so my suggestion should make such a wiki usable.

Forum: Instiki – Topic: Feature Requests

That sounds like a request for macro-support in itex. For a variety of reasons, that’s unlikely to happen.

What I mean is a research-friendly facility

• to define vocabularies for abstract mathematical languages (notations), and
• to render terms of that language in configurable ways. An implementation of this idea might use Turing-complete macros, but would be using a sledgehammer to crack a nut.

I, for one, would be against this. It would actually hinder collaboration as everyone would have to learn the local conventions every time they wanted to edit a page, and stuff that worked on one wouldn’t work on another.

I’m sure there’s a solution for that: A vocabulary could be modelled in a distributed fashion much like OWL ontologies or XML Schema Definitions, which allow for importing other “vocabularies” (ontologies/schemata). One could even imagine a versioning and migration scheme to implement the global refactorings I mentioned in my first post. I haven’t thought this through, but that might even be a practical application of basic category theory ;) BTW this also has the advantage that a user doesn’t have to learn the language again and again.

Forum: Instiki – Topic: Feature Requests

As far as I can see, there’s a lot of discussion about notational conventions on nLab, e.g. in the article on comma categories. However, there’s a huge number of articles that would have to changed if some notation actually was to be consistently adopted. I haven’t made any scientific investigations, but it seems clear to me that this hinders improvement of notation. Good notation is essential for making mathematics intuitive and useable, so wouldn’t it make sense to add powerful features for expressing and experimenting with notations?

A first step would be separating data and presentation, e.g. writing “\commacategory{F}{G}” or similar (not necessarily itex) instead of “F \downarrow G”. The concrete notation would be specified at a separate stage. This could happen

• globally by the site operators to consistently change all occurences
• per-article by the authors e.g. to avoid notation clashes
• individually by the user based on his preferences.

If this was done in every article, changing notations would become a matter of seconds. This would of course mean that in the case of nLab, some thousands of articles have to be changed (maybe some heuristics could be used to speed this up), but that has to be done only once and then hopefully never again. Future search-and-replace style global “refactorings” for generalizing or normalizing notation would become possible, too.

The major technical challenge I see would be finding a good mechanism for specifying abstract notations. The rest should be pretty straightforward.

What do you think about this?