Web 2.0 Science: Rise of the Wiki, Part III
In my previous posts (see above), I introduced wikis and an application for postgraduate physics education. The current `killer-app’ is the String Theory Wiki, which is far more up-to-date than the SPIRES HEP Reviews (though a pheno-oriented wiki would be nice, too). This time I’ll take a broader look at what else can be wikified.
A survey of wikis in science, by order of magnitude
(An homage to Charles and Ray Eames.) Here’s a tour of web spaces fertile for more wikis, roughly organized by the order of magnitude of users. Since this is rather long, here’s a summary:
Useful types of wiki: personal wiki, personal project wiki, collaboration wiki, research group wiki, department wiki, community wiki, wikipedia and wikibooks.
Personal wiki (1 author, many readers)
First of all, I think every scientist should have a personal web page. At the very least, a page with contact information, a small photo, and a bit about what you do. Why?
- People will Google you, be in control of what they find.
- The photo is necessary for prospective students/collaborators/etc. who want to recognize you when they visit your department.
- Those same people may want to find slides/notes for talks/courses you’ve given.
A good personal web page is like a CV, and it should be kept just as updated. But this is usually a pain. One has to edit an html file, upload to a server, update links, etc. And don’t forget to synchronize with a local copy on your personal computer. This is where the wiki comes in: you can bypass all of this and edit each page directly. Updates are easy: find the page you want to change, click `edit,’ make your change, click `save.’
(Don’t forget that any mistake you made is easily rectified, since wikis save the entire history of edits.)
But wouldn’t this mean anyone can edit your personal page? (Wasn’t this the point of wikis?) No! It doesn’t have to be publicly editable by everyone. The wiki feature that’s relevant here is ease-of-updating, nothing else. Such a wiki would be a regular website to the rest of the world, except for you, who can log-in and change it. It doesn’t even have to look like a wiki, as explained in this post on Acts of Volition.
Making a website look pretty takes a bit more effort this way, since you’re forced to do everything using cascading style sheets. But the pay-off is that you’ll never have to worry about design when updating content.
How many times have you cringed at a faculty webpage that’s woefully out of date? I know that professors have heaps of other responsibilities; but a web page is a public `relevant information about me’ kiosk. How many prospective grad students are you going to interest if your `research interests’ are oudated and misrepresentative? (And contrary to the image they try to present in their essays, most senior undergrads applying to your university have no idea what you work on… or maybe even who you are.)
Update (7 Oct): A good example of a personal wiki is Professor Peet’s website.
If you want to go above-and-beyond:
- Keep your personal wiki really up to date by posting your travel plans (so people know when you’ll be out), weekly office hours, etc. I imagine that with a little elbow grease, this can all be semi-automated with a widget.
- One could incorporate a micro-blog, but I can’t justify this professionally.
- One can include RSS feeds for relevant parts of a personal wiki, such as any updates to a class webpage (e.g. homework assignments) so that students can be informed when new material is posted.
Personal project-wiki (1 author, 1 reader)
This is slightly different from a personal website in that not only are you the only person who can edit the site, but you’re the only person who can view the site as well. The idea is to have a readily-accessible web notebook for research projects where you can write up ideas, include links, and upload processed data/graphics/talks. Why is this an upgrade over a regular, pen & paper notebooks?
- Physical notebooks are arranged chronologically; this isn’t the best format for reviewing your project
- A work-wiki can be accessed anywhere in the world and avoids having to actually lug around a big notebook
- Most wikis are -enabled
- You can easily cut and paste blurbs and graphics for correspondence
- You can insert hyperlinks to references
- Notes can be written and revised as one’s understanding of the project develops (especially useful for beginning graduate students)
- One can include a `toolbox’ of useful tools (Passarino-Veltman integrals, Feynman rules for your favourite model, etc.)
The bottom line here is organization. While you’re working on a project you end up with a pile of semi-organized papers, stack of worked out calculations, some computer files (graphics, talks, etc), and all sorts of sticky note reminders. When it comes time to write up, it’s a chore just to get everything organized. Even when you’re in the middle of a project, it’s a pain to go back to look up a reference from last month… who was that author again, and what was the arXiv identifier?
Here’s how I organize my project wiki:
- Front page: A list of timely notes and reminders, such as:
- Show [advisor] new paper on the arXiv, have we been scooped?
- Register to give talk at [workshop] by 19 Oct
- Don’t forget to check coefficients in box diagrams
- Abstract: A rough project title and abstract, written as best as I can. I update the abstract as I work through each project and better understand the goal and context.
- Steps: Ok, this is kind of silly, but I start out with an enumerated list of all of the steps required to finish the project. At the beginning, it’s very vague:
- Read background papers on X -> Y scattering
- Calculate SM background to this process
- Calculate BSM contribution
- Something next… has to do with programming?
But as I go progress, I fill things in:
- Read background papers (Done: 12 July)
- hep-ph/…: First paper on this.
- arXiv:0706.xxxx: Pedagogical review article
- arXiv:0707.yyyy: Lecture notes
- Calculate SM background (Done: 23 July)
- Box diagrams (check against hep-ph/…)
- Penguin diagrams (don’t forget Goldstone bosons)
- Calculate BSM contribution (In progress)
- Calculate branching ratio
- Write this up in FORTRAN, incorporate into existing library
- Something next… plot branching ratio?
- Look for enhancements over SM prediction
- Write paper?
- Resources: This is more than just a hyperlinked bibliography. Anything I ever use is recorded here, arranged in terms of the steps delineated above. This way I can go back to exactly the same resources I used if I have to check my work later on. For example:
- Background reading
- hep-ph/… (Thoughts: boring to read, focus on eq 23)
- arXiv:0706.xxxx (Good explanation of ___ effect.)
- arXiv:0707.yyyy (Explains
- Calculate SM background
- Peskin & Schroeder, p. xxxx: model calculation, I will follow this notation.
- Calculate BSM contribution
- arXiv:0704.xxxx: Feynman rules
- arXiv:0705.xxxx: Amplitude in particular region of parameter space, my calculation should match in this limit
- Background reading
- Data: A collection of uploaded plots, data sets, “sound bytes” for public outreach, or anything you’d like to have handy.
The goal is to have a wiki that, at any given time is `everything I need to know about my project.’ As a beginning graduate student, it’s easy to lose track of the big picture when doing one’s first project. This sort of wiki makes it easy to keep everything meticulously organized.
In addition to project-specific pages like those above, there are a few general pages I have in my wiki:
- A set of conventions and useful formulae
- Reference material on common calculations (notes for Weyl spinor Feynman rules, Fierz identities, Passarino-Veltman integrals,e tc.)
- Upcoming schools and conferences I’m interested in
- Papers I’d like to read when (if?) I have time
The main idea of this sort of wiki is that one utilizes the same build/rebuild-as-you-go philosophy as public wikis like Wikipedia. Only instead of many users each updating a little at a time, you are the sole user that updates many times.
Collaboration Wiki (restricted authors, restricted/private readers)
This is similar to the `personal project’ wiki, but is instead opened up to a group of users collaborating on a project. This, of course, was the main motivation for wikis in the first place.
In addition to collecting similar information as the `personal project’ wiki, a collaborative wiki would be an ideal medium to actually write a paper. As I understand it, the conventional model for paper writing between collaborators is that one member takes the lead in writing the first draft which then gets revised by everyone through comments and rewrites of particular sections. When the collaborators are far apart, this involves a lot of time spent waiting for the latest draft to be e-mailed back and forth.
The efficient (Web 2.0) way of approaching this task would be to have everyone write the paper simultaneously:
- With the wiki draft would be easy to translate into a proper .tex file.
- The usual typographic errors get smoothed out much more quickly because a Wiki would permit more revisions per section than the conventional model.
- Deeper inconsistencies are also sorted out much more quickly because they can be addressed as soon as they come up, rather than waiting for someone to write up an entire section based on an incorrect assumption.
- There is no waiting-time between drafts. If you have time to work on the paper, you can log on to the wiki and write-and-revise the most updated version.
- You can set optional e-mail alerts to passively notify other members that you’ve added something new, but otherwise you don’t have to bother the entire collaboration when you do fix up grammar and style.
- As always, wikis save changes, not drafts. So you can always access any previous version of the paper, no matter how many changes have been made.
Outside of paper-writing, a blog/forum-enabled wiki would allow larger collaborations to post questions and comments during the project.
There’s yet another aspect of collaboration-based wikis. Sections of such a wiki could be made public to promote the project. This is especially useful for software, since wikis are an excellent medium for troubleshooting. Excellent examples of these are the projects using HepForge and MARMOSET. Very large collaborations are already making extensive use of wikis, such as the CERN Twiki. (You don’t get much bigger than that.)
Update (8 Oct): It’s not quite what I was describing, but Mukund Ragamani has a public research blog.
Research group wiki (restricted authors and readers)
This differs slightly from the `collaboration’ wiki above in its scope and purpose. This manifestation of a wiki is meant to be associated with a particular research group, such as an experimental lab or a`particle phenomenology group.’
As an undergraduate I worked in a condensed matter experimental group that grew and characterized novel crystals. One of the problems the principal investigator was faced with was how to pass `working knowledge’ down from graduating students to new postgrads. Anyone who has spent some time in an experimental group knows that there is are a lot of skills that end up being taught/learned at the lab bench — anything from the most efficient crystal growing recipe (often found empirically), to how to kludge solutions to common problems, to suggestions about which restaurants are good for lab outings. Often students graduate before they can pass on all of their acquired practical knowledge to the student replacing them, forcing the latter to have to relearn a lot through the school of trial-and-error.
The goal of a `research group wiki’ is to preserve a corpus of specialized knowledge relevant to the group. This information is meant to be continuously revised and augmented by members of the group, but ultimately it’s meant to pass down information down generations of graduate students. In this sense its a bit more pedagogical than a `collaboration wiki.’
A manifestation for a theoretical group would probably include TeX’d up notes, references to useful review articles, contact information for past students (for maintaining a network of researchers), etc. Especially useful pages might be worked out example calculations using a novel technique, pieces of computer code, etc. This could also include career advice on topics such as postdoc fellowships.
There are two added benefits for the principal investigator. First there is the benefit of being able to go back and browse the history of the wiki and see the development of research ideas and the accumulation of a set of research tools (even if they’re mathematical). Secondly, a very large research group wiki would be full of material for furture summer school lectures, review articles, or even textbooks.
((Another note: because of the ability to see historical revisions, this sort of wiki may also be of interest to science historians in the more distant future.))
Again, a blog/forum interface could be added to assist in communication within a large research group. Students could post questions to one another while they were far away (e.g. away at a conference) and the solution would be saved for future students to search for if they have the same question.
Department wiki (restricted authors, many readers)
I mentioned that every person should have a professional webpage. Now I claim that further than that, that it needs to look good. Looking good means more than just pretty layout, it means presenting a unified format that makes it easy to access important information (contact information, CV, etc.) while also visually synchronizing with other pages from the department.
This is a minor point, but it’s about professionalism. There are some really good departments out there with really nasty webpages. Sometimes the main department page is unintuitive, or can only be read properly in a certain web browser, or certain personnel pages may look completely different from the rest of the department pages. While such a department may still have a fantastic research group, its website presents a sense of amateurism. (This can make a difference if you’re trying to attract graduate students.)
Here’s the common scenario from the pre-Web 2.0 era (e.g. 5 years ago). A department hires a fancy web designer to make a spiffy website, which the web designer does. The new department website is great for about two months, at which point it needs to be updated. New pages need to be added, old pages need to be edited, and its all up to a department admin who isn’t as web saavy as the fancy web designer. The html pages end up being edited using word processing software and the results are atrocious. Broken links, random font sizes, incompatibility with certain web browsers — piece by piece the website begins to show signs of wear-and-tear. Eventually the department has to either re-hire a fancy web designer, or kludge something together.
Here wikis can help. As I mentioned before, wiki separates content and presentation. The operative web technology is CSS (cascading style sheets) which allow a coherent set of visual elements to be designed and used for every page on a website. Of course, any decent web designer would already implement CSS in their site design. But wikis go a step further more constraining since they force a separation of content and presentation. The format demands that it be easy to put up a new page, or a new section, or modify the navigation links without touching the visual design and presentation of the site.
The department could still hire a fancy web designer to do their style sheets and graphics, but at the end of the day a wiki-based site would be naturally future-proofed by allowing administrators with only minimal web programming skills to easily update and extend the site content without the risk of accidentally messing up the design.
Community Wikis (many authors and readers)
As mentioned in Part II of my `Rise of the Wiki’ series, graduate student wikis can be used to organize pedagogical information such as review articles, lecture notes, and other educational resources. The example of choice, of course, is the string wiki.
Similar community-wide wikis could be used to support other focused communities. Some thoughts and examples:
- A university-specific graduate student resources with some passed-down advice from previous generations of students. For example, check out Berkeley’s BadGrads. It’s not what it sounds like — it stands for `Berkeley Astronomy Department’ and contains useful information about the city, department, and research.
- I’ve been calling for this for a while, but physics undergraduates should organize a Physics GRE wiki with `correct’ solutions to sample problems. (The Physics GRE is a test of speed; the `correct’ solution not only has the right answer, but arrives at it in less than two minutes.) There are a few sites that have solution sets, but they’re far from ideal. Such a wiki could be bolstered by references to useful textbooks.
- The various theoretical physics rumor mills could, in principle, benefit from a wiki interface since anyone can e-mail in rumors. However, I wonder if this could lead to abuse and vandalism. Some links to some rumor mills: US, Postdoc, UK/Ireland.
- Going back to the pedagogical wikis, one could consider including an Amazon-like rating interface to highlight useful/timely materials.
Wikipedia and Wikibooks (many authors and readers)
There’s more going on at the Wikimedia Foundation than just Wikipedia. A project called Wikibooks is an experiment to write textbooks in a collaborative wiki environment. With a large enough community contributing and editing a particular project, textbooks could be a natural outgrowth of scientific progress. Every generation of postgraduate student would revise the project to emphasize their own pedagogy (or pedagogies) while highlighting contemporary applications.
In conjunction with the personal and research wikis discussed above, it could be very easy keep such Wiki-texts up to date with the forefront of the field, thus reducing the time lag between the popularization of a subject and the publication of the first `standard’ textbooks on it. (Are there any textbooks on braneworld phenomenology yet?)
One could also expect that students’ learning demands would shape each wiki-text. For example, advanced students could write in worked-examples that they found helpful as model calculations or that otherwise highlight important points. Students could request clarification of certain portions of the text, with faculty and postdocs revising paragraphs that may be confusing on a first read. Instead of students ranting or raving about a textbook on Amazon.com, they would provide feedback that would lead to actual improvements in the text.
The not-so-distant Future
A few non-trivial features that could be useful:
- RSS. (See a previous post on RSS for an introduction.) Wikis make it really easy to update pages. Integrating with RSS would allow readers to keep up with major updates. (This blurs the line just a bit between wikis and blogs.)
- Forum\Blog integration. The one glaringly kludge-like aspect of Wikipedia is that there isn’t a natural structure for users to discuss their revisions. The `discussion’ pages are just regular wiki pages that users edit to include their questions and comments. Integration with a forum or a blog would help organize the `meta’ content of a wiki.
- Applets. As webpages, it’s easy to include web applets in a wiki. What would be really nice, however, would be to have applets that interact with the wiki contents. For example, automatic updates that record arXiv or SPIRES statistics, or an applet that updates all relevant numerical values in the wiki when the particle data book is updated. I could imagine a very neat time-lapse animated plot of the CKM unitarity triangles being constrained this way.
- Database integration. Wikis are essentially databases `under the hood,’ but there’s something to be gained by explicitly allowing `raw’ database manipulation to really own the information in the wiki. For example, one could tag pieces of information in the wiki using XML and write up a small program to spit out BiBTeX bibliographies from one’s `personal research wiki.’
Filed under: Science 2.0 | 4 Comments