Scott Aaronson uses an analogy to the game industry to describe the predicament academics are in:

I have an ingenious idea for a company. My company will be in the business of selling computer games.

But, unlike other computer game companies, mine will never have to hire a single programmer, game designer, or graphic artist. Instead I’ll simply find people who know how to make games, and ask them to donate their games to me. Naturally, anyone generous enough to donate a game will immediately relinquish all further rights to it. From then on, I alone will be the copyright-holder, distributor, and collector of royalties.

This is not to say, however, that I’ll provide no “value-added.” My company will be the one that packages the games in 25-cent cardboard boxes, then resells the boxes for up to $300 apiece.

But why would developers donate their games to me? Because they’ll need my seal of approval. I’ll convince developers that, if a game isn’t distributed by my company, then the game doesn’t “count”—indeed, barely even exists—and all their labor on it has been in vain.

As crazy as it sounds, this is exactly the situation with academic publishers. The ‘status quo’ is such that young researchers must publish on established journals (to gain the “seal of approval”). For older researchers, switching to open access publishing doesn’t pay off either: it’d show they don’t believe in the value the journals bring, and they are often editors of those (!).

And this is how the current academic publishing industry survives without adding much value. Survival is not the right word, because the leading firms still carry themselves around with arrogance. At the 2010 Semantic Web conference in Shanghai Jay Katzen, a keynote speaker from Elsevier, announced a big project on using the data on papers to create widgets. The API would allow people to do mashups with scientific data, that could be displayed on the publisher’s page. It was sold as “a new paradigm in the way research information is discovered, used, shared and re-used to accelerate science.” The reaction from the audience was instantaneous: “are you telling us that, not happy with monetizing the data and content we freely give you, you want us to build applications using that content for you to sell?”. The answer was honest: “… huh… yes.”

Today, many journal articles are online. In fact, the papers are often on the author’s homepage, and a simple query on google scholar or MS research search will find them. It is hard to imagine what value a publisher adds here.

However, the alternative is not clear. Open access publishing finds it difficult to obtain sustainable sources of financing. PLoS, the Public Library of Science, is financially sustainable, but ArXiv is struggling.

“Now it’s up to the rest of us to supply the anger.” Says Scott. Now more than 800 researchers have declared a boycott against Elsevier, up from 500 yesterday afternoon. Looks like the anger is there.

(An apology for the lack of posting. Dario has moved on to a position as senior researcher at Wikimedia, and I will be working on my startup full-time in a month. Often, I’ve seen blogpost-worthy issues, but I just didn’t have the mental bandwidth to follow up).

Donald Knuth announced he would make an earthshaking announcement at TUG 2010. The breaking news is the plan to release the next-generation TeX engine. Read the comments and a brief summary of the announcement in perfect Stevenote style from Slashdot.

Using HTML5 features, this is the kind of obvious tool that makes symbol lookup faster than doing it by hand.

Just draw the symbol in the box and up comes the LaTeX code, and the package name that contains it.

Project SOAP (Study of Open Access Publishing) is a two-year project, funded by the European Commission under FP7. The project is currently running a survey to understand the perception of Open Access publishing in the academic/research community. You can participate in the survey by following this link. Participants sharing their email address for further collaboration with the project automatically enter a prize draw for an Apple iPad.

“Incrementing productivity” is oftentimes framed in terms of incentives. The simpler incentives are, of course, monetary incentives. Academia is in this respect not so different from the business world – or so think many university managers and administrators. Some well endowed universities pay a premium to productive researchers: for instance, €3,000 for an article in an A+ journal, or maybe a lighter teaching load. The intrinsic value of discovery, and the thrills of fame, are no longer or not only the principal movers for scientific production. Not everyone agrees.

Brian Martin, a social scientist at Wollolong, Australia, suggests to explore “less traveled paths”, starting from the observation that research is not the preserve of a few superproductive superstars, but of a more distributed system. If monetary incentives can indeed motivate a superstar, it is also a fact that they can discourage those who do not receive the incentives. Below a certain threshold, the less productive researcher can be so de-motivated that she does not invest anymore in innovating, considering that she is not really up to the job. Thus, in order to uncover the research potential below the superstar level, other paths ought to be followed. To enlist them: preferring regular, day-to-day writing to binge writing, using creativity improving techniques, accepting that chance plays a role and even considering oneself as a lucky researcher, pursuing individual happiness, doing physical exercise, trusting the wisdom of the crowds and encouraging group work. Martin relies on recent results of the cognitive sciences about creativity and optimal working conditions.

Consider, as an example, the first path. Writing is a necessity in scientific production, but the prototypical production sequence puts writing at the end of the “idea-planning-research-result-writing” process, as a mere expression or documentation of the work done. The alternate path consists in considering writing a s a “way of thinking”, which should start early in the research project. Martin quotes work from Robert Boice, showing that the scientific output of junior faculties with a habit of writing 15-30 minutes per day can be four to nine times higher than that of binge writers.

Research Productivity: some paths less traveled. Australian Universities’ Review, vol 51, 1, 2009, 14-20.

[ CC-licensed image courtesy of milopeng]

Imagine a world where real-time search is the norm. You will get just the information you seek landing on your lap the exact minute it becomes available, without you having to explicitly search for it. Will this change the way you do science? SciSurfer thinks it will.

The release cycle of scientific knowledge is slow. It may take up to 2 years for a paper to get accepted in a journal. The publishing process in itself will add a buffer of a few months (arguably because of the time cost of having a paper edition, even though most people will never use it). So, for some of us, it doesn’t feel like we are missing much if we do not get the latest updates on our field the very same minute they are published. Just going to conferences yearly feels like more than enough. But there is a portion of the academia that needs constant updates on their field, as close to real-time as possible. If you are in the life sciences, getting the latest paper about a molecule or a gene you work on before your competitor does may make or break your career.

For those academics, sciSurfer may be a very valuable tool. The basic idea of sciSurfer is to integrate all journal feeds and search over them. Note that they do not archive RSS, so only the latest articles are available. This is a different way to think about search, closer to twitter’s than to Google’s.

In use

If you are used to RSS feed readers, the interface will look familiar. Left side there’s a list of journals and searches. Every time there’s a new unread item the containing ‘folder’ turns bold. On the right side there’s a list of articles (title, authors, and abstract). The journal it comes from is shown in green. The interface resembles Google reader (in fact, sciSurfer is built on app engine, so it may share code with reader).

What is the advantage of scisurfer over simply subscribing to the RSS feed of the journals? Search. Scisurfer does searches over all the journals they are indexing. This is pretty impressive, because I don’t know of any search engine that works on RSS feeds. Using an RSS reader, the equivalent to scisurfer would be to subscribe to the RSS of all journals, and apply searches over those. This is beyond the capabilities of most destop RSS readers. Implementing search by author, abstract, etc is also beyond the feature set of a normal RSS reader. In fact, it’s not that easy to deal with author names. We all have had the experience of getting papers by people with the same lastname and initials as our intended query term that are NOT the person we are looking for. Thomson Reuters has a solution: researcher ID. Researcher ID is based on the simple idea that each individual would get a unique identification (ID) number acting as a digital “calling card” that the researcher can place anywhere, such as a personal home page, a CV, or a university page. It has been out for more than two years now, so it’s still too early to say whether it has been adopted successfully.

Apart from the reader, there are two other tools, news and journals. Searching journals by name integrates the RSS feeds of otherwise disperse journals. Still, I haven’t found a good use for this tool.

Navigating trends

The main use I can think of for sciSurfer is monitoring Trending topics. We are getting used to explosions in popularity thanks to twitter and Facebook updates. Good twitter clients show you ‘what’s hot’ together with an explanation on why. Even Mendeley is getting status updates these days, making it look more and more like ‘facebook for scientists’.

There are several things to like about sciSurfer.  It integrates with your Google account, so it’s one less login to remember. The devs show that they are on top of things and the result is a fast turnaround when I requested changes. They are very open about feature requests. In my experience, when a journal was not in sciSurfer’s list, the devs added it within hours.

But by far the best result of using sciSurfer is that it makes you aware of what is going on in your field in a way that feels different and pleasant. The most similar feeling that I got online is when I found a neat Phd. student tagging articles in citeUlike that are relevant for me (it’s like finding a gold mine).

Mendeley uses a similar real-time approach in their statistics. For example, they show what are the most read papers per discipline at a given point in time.

I’m not sure one can do searches according to popularity just yet on any of these tools, implementing a real-time soft peer review.

How does sciSurfer plan to make money? The free tool is limited to ten saved searches. They will charge for extra functionality. There’s an iPhone version coming, which may well be another source of funds.

Conclusion

As the number of publications grows, it becomes more and more difficult to follow the latest scientific trends. The approach that sciSurfer takes is that if you know your keywords then it should be trivial to filter the fire hose of information, by doing a trivial keyword match. While keyword match could go a long way, I’m skeptical that the future of search lies in dumb matching. The way I currently filter information is very social, that is, I’m surrounded by people I respect and I ‘feel’ what they believe is good research. If I’m like most researchers, then social filtering would be a natural fit. However, I rarely get value from social networks online (science-wise; no matter how hard social networks try to capture my attention!). It may well be that to form a reputation, scientists need to do far more than posting interesting updates in their microblogging feeds. And for us to follow their recommendations…

Citation copy-editing is one of those deceptively small burdens that have a way of taking over the working day. If left untended, the task of tidying up casually scribbled references can snowball to crisis proportions as a submission deadline approaches. Similarly, when a submission to one publisher is unsuccessful, significant effort may be required to recast its citations in the format required by another. Collaboration outside of one’s own field can bring with it an unwelcome tangle of fresh style-guide quandaries to ponder and fight through. These are things that the machines, if they want to make themselves useful, should be doing for us.

There is plenty of collective experience in this line, and as fate would have it, there are also plenty of collective solutions. In the TeX/LaTeX world, authors and their editors can today choose between BibTeX and BibLaTeX — both of them excellent utilities — with the several variants of the former supported by no fewer than four separate versions of the BibTeX program. [1] Users of WYSIWYG word processors can look to the bibliographic support built into Word or Open Office, or they can turn to an external solution such as EndNote ™, ProCite ™, Reference Manager ™, or more recently Zotero or Mendeley. Migrating data between these environments is a process fraught with uncertainty, but it is sometimes unavoidable when you need this kind of output, and it can only be produced on that kind of system …

… with so many solutions to choose from, it’s hard to go right. [2]

The citeproc-js citation processor is a Javascript implementation of the Citation Style Language (CSL), an XML schema for describing citation styles that aspires to strike this problem at its root. CSL is a general, open standard that enables fully modular control over bibliographic formatting. This means that CSL is capable of accurately describing styles used in many disciplines, from the sciences, through the humanities to law. It also means that a CSL style description can be used with any other application that understands the CSL language. And it means that the style description is separated to the extent possible from the target document; you can switch styles at any time, even after the writing process is complete. Generality, a comprehensive pooling of community resources, user-centric ease of use: all areas where, collectively, our current menagerie of productivity tools could do better.

CSL first saw wide application in the Zotero project. [3] Citeproc-js has been developed in the first instance for use in Zotero, [4] but it runs as a separate module via a (relatively) simple API, and with appropriate wrappers, it can be deployed pretty much anywhere. Potentially, any application that generates dynamic content — text processors, word processors, weblog environments, and dynamic websites — can use CSL and citeproc-js to provide publisher-correct citation and bibliography facilities without exceptional programming effort. [5]

Development of the CSL language has been spearheaded by Bruce D’Arcus. The citeproc-js processor adheres to version 1.0 of the CSL specification, [6] which has been engineered and documented during the past year primarily by Bruce and Rintze Zelle, with incidental contributions by myself and others. It will debut, together with the new processor, in Zotero 2.1, which should begin to emerge, if all goes well, during this calendar year.

Meanwhile, the processor itself is complete, documented, and more or less ready to go. [7] Here is a short run-down of some of the highlights:

Disambiguation

In author-date citation styles, works by the same author must be distinguished from one another in some way. The current Zotero processor performs name and cite disambiguation as required by the Chicago Manual of Style. There are in fact at least six other disambiguation methods in general use. CSL 1.0 and the new processor will support all of them.

Sorting

The AGU journals, in particular, impose extremely demanding sorting rules in the bibliography. [8] CSL 1.0 and the new processor support multiple sort keys with arbitrary sort order for each key. A wide variety of sorting schemes can be implemented, including the AGU sort.

Parallel citation support

Many legal styles, including the Bluebook style common in American law journals, require that law cases appearing in multiple reporters be cited to each reporter, with the case name in front, and the court and year of decision at the end. [9] The new processor supports this behavior.

On-the-fly document updates

The API of the new processor supports targeted context-sensitive updates of citations in a document that are affected by an insertion, deletion or edit, for efficient transactions with a word-processor or weblog plugin.

Localization of dates

CSL version 0.8 currently supports the use of localized terms for style-supplied labels and the like. CSL 1.0 will add sophisticated localization of dates; both the language of month names and the ordering and formatting of elements will adjust appropriately when the language of a citation style is changed.

Sophisticated names handling

A great deal of work has gone into enhancing the handling of names in CSL 1.0. European conventions on the handling of particles such as “von”, “van”, “di” and the like can be accounted for appropriately both in the sorting and in the rendering of individual names.

In-field formatting

For scientific publishing, the new processor recognizes a limited subset of HTML as markup within titles, enabling superscript, subscript, small capitals, italics, boldface. The processor also implements the flip-flopping of italic and boldface, and of quotation marks, to avoid ambiguity in rendered citations. The HTML used in markup is transformed by the processor into the selected output format (HTML, RTF, LaTeX, or whatever) during rendering.

Multi-lingual citation support

The new processor implements experimental support for multi-lingual citations, providing a flexible mechanism for the transliteration of names and titles, for the supplementary translation of titles, and for the use of alternative sort strings needed for Asian languages.

As it leaves my laptop, citeproc-js is just a bare Javascript module with some test suite wrappers to check that it actually performs as advertised. But with the widening availability and increasing efficiency of Javascript runtime tools, I do hope that it has some prospect of escaping from its cage and wreaking order on the world of bibliography management. If you’re an integrator or site administrator, the fine citeproc-js manual is your first point of reference. If you’re an end user, keep an eye out for the CSL mark, coming soon (maybe) to an application near you!

Springer announced last week the launch of LaTeXSearch.com, a free online service allowing users to search a huge database of LaTeX snippets from Springer journals and publications. This follows the launch of a similar service, a few months ago exposing Springer’s database of scientific images (which suggests a precise strategy on how to build Web services on top of content in their publication database).

LaTeXSearch does what it promises, using similarity algorithms “to normalize and compare LaTeX strings so that, if similar equations are written slightly differently, the outputs are normalized and matched, granting you the broadest possible results set”. The only glitch is that snippets are not cached but generated on the fly, with the annoying result that it can take quite some time to display the rendered version of LaTeX formulas in search results.

Peter Sefton wrote a series of posts on wave. He has published on Scholarly HTML so I read attentively what he has to say. What follows is some highlights of his posts, and my thinking about where things are going. There are at least four things that bother me about wave –as it is today:

1- It’s not really HTML

I thought that waves being XML documents would be a good thing because it’d separate content and formatting. But it seems that they made some strange decisions about how to represent formatting with “very tenuous relationship to HTML”. For example

While there is talk of ‘XML documents’ in the whitepapers etc, a wave document in the current implementation is apparently a series of lines of text. All formatting and what you might think of as structure, such as whether something is a heading or not, is considered an annotation.

This is important right now because the only way to get the resulting doc is to dump the html to a file, or ‘copy-paste’. So, in a way, losing formatting like this would completely incapacitate wave for serious paper writing. I have had some success just copy-pasting and keeping most formatting, but I cannot risk to write a long paper and lose all formatting. Which won’t happen, because…

2- It doesn’t work too well for long, structured documents

Having a large blip for the entire paper with many people editing it seems to perform poorly. And having each person write their own blip-per-paragraph is not very pretty. It’s in fact distracting. I don’t discard wave’s usability to go through the roof once people start making things with it (robots). But it all depends on how well the API is designed. For example, following the mailing list, it seems that there’s no easy way to reorder blips programatically. This sounds like bad design to me.

3- It doesn’t integrate well with citation tools

It may be a matter of time before all the bibliographic tools we like get integrated. For example, Igor does offer some basic integration but this is far from satisfactory.

4-Formatting is simplistic

Wave has no table support. Figures are also not what you would expect, even for a notetaker. Captions are not implemented, nor footnotes. finally, LaTeXy is not the most convenient way to get equations done, I’m afraid, and it doesn’t go both ways.

Clearly, the content/form separation in wave is not designed for academic collaboration, and it shows. The questions is whether we can make this happen by writing robots[1]. Whether wave is the open platform that would make academic writing 2.0 happen.

Wave is just a tool. Why does this matter so much?

You may think that thinking too much about tools is counterproductive. But the way things are, it looks like tools are more and more important. Right now, we are stuck with the paper metaphor. Authors can produce pdfs, and publishers too. A publisher may make a prettier one, but that adds little value. We are equaled in terms of tools. However, publishers such as Elsevier want to get away from the paper metaphor (which is a good thing). As a consequence, authors will not be able to produce HTML as rich as the publisher’s. Here, the difference in tools matter.

In this case, Wave does look like an easy way to craft an interactive experience with little effort. So, even if you discard wave’s usefulness as a collaboration tool, it has quite a lot of value.

But it could very well be that wave doesn’t fulfill its promise. Microsoft Office 2010 offers similar functionality (close to real time edits). And of course, word has unparalleled features such as track changes, integration with endNote, etc. It could be that people adopt this new way of collaborative writing in real time without using wave. What worries me is that openOffice looks seriously left behind now. If it looks like a half-assed implementation of word 2003 features now, imagine when real-time hits mainstream. You need a serious server infrastructure to support that, which is possible for Google or MS, but not for a –smallish- open source foundation. I hope they find a way to jump in the train before it’s too late. Wave has a lot potential, because it is open. If openOffice could support that wave protocol, it could be a big achievement for open source.

If you have had any experience drafting a long doc in wave, please post it in the comments.

[1] For more on this, see my Wave intro for RuPy 2009.

Call for participation for a workshop at CSCW 2010
[submission deadline: November 20, 2009]

The confluence of two major trends in scientific research is leading to an upheaval in standard scientific practice and collaborative technologies. A new generation of scientists, working in large-scale collaborations, is repurposing social software for use in collaborative science. Existing social tools such as chat, IM, and FriendFind are being adopted and modified for use as group problem-solving facilities. At the same time, exponentially greater and more complex datasets are being generated at a rate that is challenging the limits of current hardware, software, and human cognitive capability. A concerted effort to create software that will support new scientific practices and handle this data tsunami is redefining the collaboratory and represents a new frontier for computer supported cooperative work.

This follow-on event to a similarly themed workshop at CHI 2009 is intended to foster community among researchers and practitioners from multiple disciplines interested in the changing dynamics of scientific collaborations.

We encourage papers on the following topics, especially those with a focus on changing practices in these areas:

• Collaborative scientific applications concerning data gathering,
  analysis, sharing, and visualization
• Case studies concerning data gathering, analysis, sharing and visualization
• Socio-technical research on scientific collaborations
• Social networks of scientists
• Repurposing social software for science
• Participatory design and/or rapid prototyping for scientific software
• Distributed data gathering and analysis
• Time-critical scientific applications
• Studies of generational differences in how science is done
• Cross-functional applications and comparisons of a scientific to
  a non-scientific field

For more information, please see the workshop web site:
http://www.sci.utah.edu/cscw2010/

Organizers:

• Cecilia Aragon, Lawrence Berkeley National Lab, CRAragon@lbl.gov
• Jeffrey Heer, Stanford University, jheer@cs.stanford.edu
• Charlotte Lee, University of Washington, cplee@u.washington.edu
• Claudio Silva, University of Utah, csilva@sci.utah.edu