Depth-First: Tag collaboration

Building Chempedia: The Human Element

Rich Apodaca — Thu, 15 May 2008 14:50:00 -0400

The study of chemistry is an inherently social activity. From the papers we use and cite, to the conferences we attend, to the informal discussions we engage in daily, being a chemist means interacting with your fellow chemists. Yet strangely, most chemical information systems either totally ignore this central fact, or provide only the most meager of tools to harness it to its full potential. This article discusses how Chempedia currently integrates the social with the scientific, and what may be in store for the future.

Chempedia as a Tool for Scientific Collaboration

Like all chemical reference works, Chempedia is written by people with their own interests, skills, and ambitions. Unlike almost every other chemical reference work, Chempedia (through Wikipedia, on which it's based) offers intriguing possibilities to directly collaborate and learn from its contributors - or even become one of them.

How can Chempedia better facilitate scientific collaboration?

A Simple But Possibly Useful Feature

Yesterday, a new feature was added to Chempedia that makes it easier to understand the recent history of a Compound Monograph. The new feature shows the date that a Compound Monograph was last edited, and the Wikiepdia user who edited it:

Clicking on the link takes you to the Wikipedia users page, in this case the one for Meodipt. (Wikipedia users frequently use handles rather than their given names.) From Meodipt's page, we can see that s/he received degrees in chemistry and pharmacology and is currently studying law. Meodipt's interests include pharmacology, chemistry, law, and science. We can also see that Meodipt is maintaining a good-sized list of CAS numbers for drugs, grouped by indication.

We might be curious about what Meodipt found worth changing, and how s/he changed it. We could do so by first clicking the Chempedia edit link. In the Wikipedia box (framed by the red dotted lines), we would then click on the 'history' tab. Clicking on the 'last' link for the top entry shows us exactly what Meodipt changed on Pravadoline's compound monograph (also visible through this link).

Looking Ahead

Linking a real person to changes in a Compound Monograph could be enormously useful, if done properly. After all, bringing people with highly focussed interests together is the essence of scientific collaboration. The Chempedia/Wikipedia combination provides one way to do that.

As Chis Anderson puts it, "social networking should be a feature, not a destination." Scientists were social networking long before the Internet, the computer, and the telephone were invented; indeed scientists who fail to connect with their fellow scientists have a difficult time of prospering. When seen from this perspective, it's surprising that good 'social networking' features would not be viewed as a top priority in chemical information systems.

The Chempedia author credit system in its current form is rather simplistic and may not actually promote scientific collaboration at all. But it's not hard to imagine ways to make it far more effective. Future articles will discuss some of the possibilities.

What Makes Wikipedia Tick?

Rich Apodaca — Fri, 05 Oct 2007 10:28:00 -0400

Whatever your views on Wikipedia, it's clear that the volunteer online encyclopedia has left it's mark on society. But the most important things about Wikipedia have less to do with its contents and more to do with the people contributing and using the service. To understand how and why people collaborate on the Web, you have to understand Wikipedia.

An interview with three leading Wikipedia figures sheds some light on Wikipedia as a collaborative activity.

There is a myth about online collaboration that Open Source practitioners are very familiar with. It goes something like this: "I'll start building something and release it to the community. I'll get feedback from a lot of users, some of whom will fix bugs, write documentation, and build extensions. All of that feedback will create a better product."

Now, this does happen, of course. The reason I consider it a myth is that it happens so rarely that you might as well not count on it. Virtually all Open Source software is designed, written, documented, debugged, and promoted by a single developer with the help of a tiny fraction (say 2-10%) of the committed user base. Pick any good example of Open Source software that works and behind it you'll find a committed user base large enough to make 2-10% a number greater or equal to one. It's not clear this is necessarily a bad thing.

The interview with the Wikipedia leaders confirmed this view. When asked about the idea that lots of contributors makes a good article, Elisabeth Bauer, of the English Wikipedia, had this to say:

The best articles are typically written by a single or a few authors with expertise in the topic. In this respect, Wikipedia is not different from classical encyclopedias.

Her view was shared by Kizo Naoko, of the Japanese Wikipedia who added that short articles tend to remain short and of poor quality.

There doesn't seem to be anything complicated here. Wikipedia places a very low barrier to contribution. It has created a system where active contributors with specialized knowledge feel a sense of ownership over their contributions. Checks and balances insure that these contributors can monitor changes to their work, and correct errors. Finally, the subject matter is so broadly appealing (All of Human Knowledge) that 2-10% of the user base is a massive number.

It may not be complicated, but it's far from easy.

Collective Intelligence and the Dumbness of Crowds

Rich Apodaca — Thu, 18 Jan 2007 15:07:00 -0500

It's the sharp edges, gaps, and differences in individual knowledge that make the wisdom of crowds work, yet the trendy (and misinterpreted) vision of Web 2.0 is just the opposite--get us all collborating [sic] and communicating and conversing all together as one big happy collborating [sic], communicating, conversing thing until our individual differences become superficial.

-Kathy Sierra, The "Dumbness of Crowds"

"Web 2.0" has gotten a lot of people thinking about exciting new forms of collaboration made possible through the Internet. Services like Digg, YouTube, Flickr, and Wikipedia, and especially the way they harness the selfish impulses of individuals for the common good, are seen by many as just the start of even better things to come.

Given the astonishing advances in hardware made possible by Moore's law, and the relentless progress of Open Source software, starting one of these services on your own can be done for practically nothing. Of course, starting a Web 2.0 service and actually seeing it become a raging success are two very different things. What's the deciding factor?

It was while thinking about this question that I ran across a thought-provoking article on Kathy Sierra's Creating Passionate Users. Although mainly focused on software, Kathy's blog is essential reading for anyone trying to create remarkable products. The article that caught my eye was titled "The 'Dumbness of Crowds'". In it, Kathy makes some interesting distinctions between "Collective Intelligence" and "Dumbness of Crowds."

The distinction arises from the number of people involved, the nature of what they're building together, and the process by which differing views are reconciled. For example:

Collective Intelligence a bunch of people writing Amazon book reviews
Dumbness of Crowds a bunch of people using a Wiki to write a book
Collective Intelligence - Flickr's photo collection and tags
Dumbness of Crowds - a bunch of people trying to make a photo together

I could add my own observations:

Collective Intelligence an online RSS aggregator that combines blog feeds from multiple sources within the community
Dumbness of Crowds a publicly-writable Wiki that serves as your community's public face
Collective Intelligence ten users of an Open Source software library stress-testing it in their own work, fixing bugs, and requesting features
Dumbness of Crowds ten programmers trying to design an API
Collective Intelligence ten developers who each start their own project to build their own distinct application based on a piece of Open Source software
Dumbness of Crowds ten developers who set out to design a single application that does the work of ten

The distinction really revolves around the degree to which individual contributions are blindly averaged verses being allowed to retain their individuality. Committees rarely create great works. Even worse - sometimes consensus is fatal.

BioRails

Rich Apodaca — Wed, 06 Dec 2006 15:22:00 -0500

BioRails is an Open Source Biological Information Management System (BIMS) based on Ruby on Rails. The BioRails team expects the first release to be available sometime in December 2006. From the BioRails FAQ:

A BIMs is a Biological Information Management System. BIMS are used to support the process of discovery research. The objective of a BIMS is to to persist the biological results in a searchable database that will support both quality control of the data being generated and, when integrated with chemistry systems, support the process of compound progression decision-making.

BioRails has a great deal of potential, and it will be interesting to see the system up close when it is released. Many areas of science, particularly chemistry, have been slow to embrace the Web as the powerful application development platform that it is. BioRails and projects like it have the potential to change not only the way that scientific software is deployed, but the nature of scientific collaboration itself.