Recent Posts by Bernhard Stadler
posted almost 3 years ago
Bernhard Sta...
4 posts

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. 
posted almost 3 years ago
Bernhard Sta...
4 posts
edited almost 3 years ago 
Forum: Instiki – Topic: Feature Requests
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 timeconsuming 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. TeXderived 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 onesizefitsall notation of OpenMath or similar, so my suggestion should make such a wiki usable. 
posted 3 years ago
Bernhard Sta...
4 posts

Forum: Instiki – Topic: Feature Requests
What I mean is a researchfriendly facility
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. 
posted 3 years ago
Bernhard Sta...
4 posts

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
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 searchandreplace 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? 