Posts with this logo use 
Low-functioning pinhead...
December 31, 2006
The Year in Spam
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.
December 23, 2006
Instiki
Update (2/15/2007):
My branch of Instiki has its own website, now.
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.
December 21, 2006
Blogs vs Wikis
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.
- remains nontrivial after tensoring with .
- 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):
- Serves static (X)HTML pages.
- When the user clicks “edit”, uses AJAX to swap the (X)HTML+MathML content with the wiki+LaTeX text for editing.
- Is sufficiently plugable, so that I could wire in itex2MML on the server-side.
- Either is good enough to emit well-formed XHTML (sounds unlikely), or could use Sam Ruby’s Javascript to allow MathML in HTML4.
- I’m willing to use Apache’s native access control capabilities, so built-in ACL’s are a plus, but not a requirement.
December 12, 2006
The Frozen North
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