Musings

It’s not often that one can claim 100% annual growth for something, let alone 1000%. Alas, I can take little credit; it’s all by dint of the efforts of the intrepid (but essentially hapless) spammers. Trackback spam went from a “mere” 9400/month at the beginning of the year to 94,000/month in December.

The discussion of Wiki software in my previous post really crystallized things for me. The bottom line was that, if I was going to “invest” in some Wiki software, I was, almost inevitably, going to pop the hood and meddle with the source code. And, in all my experience, the source code for any project written in PHP is going to look like the racoons have gotten loose in the trash again.

So, if I went down the list of Wiki software, and eliminated all those written in PHP, that would drastically narrow the scope of my indecision. Of the handful of packages left, Instiki, written in Ruby on Rails seemed like a good bet.

What does it look like? Well, here’s a copy of the front page of my wiki (the wiki itself is password-protected). More details below the fold.

There’s an interesting cross-blog conversation about using blogs a research collaboration tool. I thought I’d take a little break from calculating KR groups and make a few comments.

What makes a good collaboration tool? The particular project I’m taking a break from is one that Dan Freed, Greg Moore and I have been slowly plodding along with. We’ve been conversing by conference-call and emailing around TeXed notes. Most of those notes need revising, in light of subsequent conversations … Not at all atypical. Indeed, it more or less describes most of the collaborations I’ve ever had. At the end of the day, I have an email box full of notes and comments and revisions thereof, all jumbled together in a not-very-coherent mess.

What we really need is a Wiki, where we can collect our results, make corrections, raise issues to be dealt with, etc. Blogging software is all very nice, but it really doesn’t lend itself to this “going back and revising” process that characterizes ongoing research. It’s a great tool for communicating with others, but it’s less than ideal for the purpose I’ve described. Heck, blogging systems don’t even have Revision Control.

I’ve been looking into Wikis for a while now. There are lots of different ones out there. But if we start restricting to those which have reasonable facilities for doing Math, the field narrows quickly.

• MediaWiki uses texvc to edit formulæ. Dave Harvey (whom I met in Minnesota) designed blahtex as a drop-in replacement for texvc. But, MediaWiki isn’t XHTML-safe, so the advantage of blahtex (the ability to output MathML) may be moot.
• Bob McElrath uses Zwiki. And he maintains LatexWiki, a plugin for ZWiki, which produces PNG equations. Unfortunately, ZWiki is a resource-pig, and for that and other reasons, Bob seems has given up on it.
• TiddlyWiki, with the jsMath plugin is mind-blowingly cool (once you realize that the whole damned Wiki is running locally … in Javascript … in your browser). There is a server-side implementation, which Bob seems to be maintaining now. With access-control features and version-control, that may graduate TiddlyWiki from “personal notebook” to the “collaboration tool” I’m after. But jsMath (like most client-side tools for rendering math) seems kinda slow. And I wish it supported more of LaTeX.

There are other Wiki possibilities; MoinMoin seems quite good. But everything I’ve mentioned needs work before I’d find it a completely satisfactory solution. Whatever the installation requirements on the server-side, I want entering content to be as easy and LaTeX-like as possible. Ideally, it would use itex2MML server-side, and serve static pages, as much as possible.

Public or Private

A lot of the discussion revolves around whether this online research ought to take place in public or in private. It seems to me rather strange to advocate hard for doing it publicly and then, when you actually go to set it up, do so privately.

Personally, I’m of the opinion that most people really don’t want to know how the sausage is made. Urs Schreiber is marvellously uninhibited when it comes to discussing work-in-progress in his blog. That’s great, if you can do it. One of my New Years resolutions is to try to do more of that kind of “thinking aloud” here on Musings.

Ultimately, it’s not an either/or proposition. There are some things are best kept under wraps; others would benefit from input from others. For instance, even if I had that hypothetical private Wiki set up for this project with Dan and Greg, there would be at least one public page, entitled Examples to Calculate. It would be great to get some feedback on orientifold backgrounds to which to apply our analysis. Right now, for instance, I’d like some examples of Calabi-Yau orientifolds with O7-planes, where the underlying Calabi-Yau has

• Nontrivial fundamental and/or Brauer group.
• $(\mathrm{H}^2(X)_{\text{tor}}\oplus \mathrm{H}^3(X)_{\text{tor}})$ remains nontrivial after tensoring with $\mathbb{Z}[1/2]$.
• If the example is physically-interesting, as a Type-IIB flux vacuum, so much the better.

Suggestions?

Update: Wiki Wishlist

Just for clarity, what I think I’m looking for in a Wiki (list to be updated, as warranted):

1. Serves static (X)HTML pages.
2. When the user clicks “edit”, uses AJAX to swap the (X)HTML+MathML content with the wiki+LaTeX text for editing.
3. Is sufficiently plugable, so that I could wire in itex2MML on the server-side.
4. Either is good enough to emit well-formed XHTML (sounds unlikely), or could use Sam Ruby’s Javascript to allow MathML in HTML4.
5. I’m willing to use Apache’s native access control capabilities, so built-in ACL’s are a plus, but not a requirement.

One of the weirder byproducts of having started this blog was being invited to speak at a conference on the Evolution of Mathematical Communication … in Minneapolis … in December.

Not being one to shrink from mere weather, I was enticed by the prospect of meeting Roger Sidge, the man behind Mozilla’s MathML support, Robert Miner and Neil Soiffer of Design Science, and a lot of others whose names I’d heard, but would now be able to associate with a face.

It was quite a bit more fun than I expected.

T. V. Raman gave an inspiring talk. I think he’s more optimistic about the XML-based (AJAX, XForms, …) future of the Web, and what it means for delivering mathematical content, than most. His bottom line seems to be that, at least for our purposes, plugins (whether this one or this one) are no longer anathema and they enable us to deploy MathML and SVG (and whatever fancy technologies come after them) without waiting for a certain dominant browser-maker to catch up.

Andrew Odlyzko gave a beautiful historical talk about the adoption rate of new technologies. Lots of entertaining facts. But the main point, and the fact that astounded me, was that —even today — only about 10% of papers published in Math are available in some open-access form (either from the arXivs or elsewhere). Wow! What could the other 90% of authors be thinking?

Robert Miner gave a demo of MathDex, their forthcoming Mathematical Search Engine. If you’ve ever tried to search for something mathematical on Google, you know that it’s a basically hopeless task. First of all, you need some mechanism for entering the mathematical expression you’d like to search for. Second, just as Google needs to know that “Göttingen”, “Goettingen”, gottingen”, etc. are all the same search term, a mathematical search engine needs to normalize queries for mathematical expressions. It’s a tricky problem, but they’ve made considerable progress (not that you’ll be able to see much on the publicly available website, yet). So far, they’ve just been playing with a database consisting of Wikipedia articles and arXiv eprints. One of the next things they’ll index are the blogs here on golem (a rich source of MathML on the web).

In my talk, I made a pitch for various ways in which what we do hereabouts could be made easier. I talked about the prospects for embedding MathML and SVG in HTML(4/5)¹, for being able to copy/paste² MathML formulæ. My laptop died³ rather unceremoniously before my talk. So, instead of a fancy Keynote presentation, I was relegated to giving a totally retro (and, in the context of the conference, wonderfully ironic) blackboard talk. Surprisingly, it went quite well.

A large fraction of the MathML Working Group was in attendance. And, it appears, they really are serious about trying to come up with some sort of recommendation about input syntaxes. Superficially, that makes a lot of sense. There are, for instance a bunch of TeX-like input syntaxes, and it would be nice if, at some core level, they were interoperable. That is, however, trickier than it seems. Blahtex is designed to be compatible with texvc, as used on Wikipedia. itex2MML is based on WebTeX. There are also a bunch of other converters (TeX4ht, Hermes, …) that are designed to operate on complete (La)TeX documents. Deciding what would be valuable as a compatible subset is not straightforward.

Anyway, I heard some great talks, had some great conversations, and the weather wasn’t even that cold …

Sam Ruby has been busy. He’s been lobbying for changes in the HTML5 Specification which will, ultimately, enable embedding of MathML and SVG in HTML5 documents. As a proof-of-concept, he unveiled a Javascript that enables embedding MathML and SVG in current HTML4 documents. If your browser supports MathML and/or SVG in XHTML, Sam’s script will make them work in HTML4.

Goodbye Draconian error-handling!

There are some restrictions. XML empty element syntax is not supported. So, in MathML, e.g. <none/> would have to be changed to <none></none>. I counted twelve lines of itex2MML code which would have to be changed to accommodate Sam’s script. That was too good to pass up.

So here’s itex2MML 1.1.6. The only change was to “fix” those 12 lines, to eliminate XML empty-element syntax. At least for Gecko-based browsers, following Sam’s instructions, you can now happily use it¹ to embed MathML in good old HTML4 (or, for that matter, faux XHTML) pages, served as text/html.

Share and enjoy!

A Well-Oiled Machine

Slightly off-topic, but I just wanted to announce that one of my pet MathML-rendering bugs got fixed. What warms my heart, though, is the chronology. I submitted the bug Sunday night. In less than an hour, Phil Ringnalda had created a test-case, and cc’d Boris Zbarsky. Zbarsky quickly diagnosed the problem and, the next morning proposed a patch. The following day, the fix was approved by Roger Sidje, and checked-in. From initial bug report to check-in of the solution? 40 hours and 6 minutes.