User-Created Compound Monographs on Chempedia.net: Open Sourcing the Collation and Indexing of Chemical Information

Rich Apodaca — Thu, 17 Apr 2008 17:50:00 +0000

Printed encyclopedias of chemical information like the Merck Index suffer from the problem of becoming obsolete on publication. When new compounds are discovered, or when the information about a compound changes, those changes can take many months or years to appear in print form due to the high cost of publication. It doesn't have to be that way. This article introduces a new feature to the free online chemical encyclopedia Chempedia that lets working scientists update is contents via Wikipedia.

About Chempedia.net

A recent article introduced Chempdia, the free online chemical encyclopedia. This service is built on two of the largest free and open repositories of chemical information in existence: Wikipedia and PubChem. PubChem supplies low-level chemical information such as connection tables, and Wikipedia supplies free-text descriptions of the properties and uses of certain molecules.

Which Molecules?

Currently, Chempedia.net only includes compound monographs for about 1,000 of its over 300,000 molecules. These monographs were located by a manual process in which the titles for all Wikipedia articles were downloaded in alphabetized form; this process clustered titles that represented IUPAC nomenclature due to its use of leading numbers and symbols. IUPAC nomenclature titles were extracted, and then a script was written to extract the chemical information from these titles and combine it with that from PubChem.

This method, although useful for getting a service running, is clearly flawed. The biggest problem is in how to discover new compound monographs.

Why Not Put Users in Control?

Chempedia users themselves are in the best position to know when an existing Wikipedia compound monograph should appear in Chempedia but doesn't, when an existing monograph needs to be updated, or when a new monograph is written and needs to be linked.

How can the process be automated?

As a partial answer to this question, users now have the ability to notify Chempedia of any changes to a Wikipedia compound monograph, and to have those changes immediately reflected in the next viewing of a Chempedia compound monograph.

An Example

As an example, let's take anandamide, a compound I've had some experience with during my time as a medicinal chemist. Although the Chempedia entry for ananandamide exists, there is (or as of today - was) no link to the Wikipedia compound monograph. Let's create one.

At the top of Chempedia's main menu, you'll see a link titled 'Update'. Choosing this link leads to a form that will ask for two pieces of information: (1) the title of the Wikipedia article to which you want Chempedia to link - in this case 'anandamide'; and (2) reCaptcha text to keep robots from making mischief.

Submitting this information is all that's needed to create a new or updated link from Chempedia to Wikipedia. Chempedia handles the rest.

Conclusions

Wikipedia is a vast source of free, high-quality, semi-structured chemical information just waiting to have good chemically-aware interfaces applied to it. Chempedia.net is an attempt to do just that, but it's a bit more as well. Although it may appear that Chempedia is the major beneficiary in this relationship, Wikipedia also benefits. When chemists have a tool that allows them to query and visualize Wikipedia using their native language (the chemical structure) they're in a better position to both use and contribute to Wikipedia itself - something I've started to do.

This positive feedback effect is the real value of exposing Web services. The question is: who in cheminformatics is willing and able to take the risk to discover this simple principle and its benefits?

Six Reasons I Like reCAPTCHA, or How to Build a Web Service Worth Talking About

Rich Apodaca — Tue, 18 Sep 2007 08:33:00 +0000

Having spent a great deal of time with reCAPTCHA over the last few weeks, I've come to appreciate both the clever idea and spot-on execution. Aside from being an excellent product, reCAPTCHA also offers clues to building Web services that people will not just use, but also tell their friends about. Here, in no particular order, are six things about reCAPTCHA that I hope all of my future Web services achieve:

It solves a nasty, boring, and widespread problem elegantly. The nastier and more boring a problem is, the more likely that a solution that actually works will be praised by all who use it. Boring and difficult problems create a natural scarcity of good solutions and people willing to work on them. Seek these kinds of problems out; they are a high-probability path to success.
It never goes down. Having used reCAPTCHA pretty much continuously over the last three weeks on my current project as well as on this blog, it's never been unavailable. As much as anything on the Web can be trusted to be there tomorrow, reCAPTCHA seems like a safe bet.
The business model is obvious. reCAPTCHA "pays" for itself by helping to digitize old books. This is a valuable service in itself that could be monetized in some very interesting ways. Because reCAPTCHA does something valuable beyond just fighting spam, it's very likely that I can rely on the service being around for a long time.
It solves problems from two different groups of users at the same time. Consider the giants of the Web: Yahoo, Google, YouTube, Facebook, eBay. What every one of them has in common is that along the way they have discovered how to solve problems from two different groups of users simultaneously. The same is true for reCAPTCHA. Come to think of it, every unsuccessful Web venture I can think of failed to solve two problems simultaneously (most didn't even really solve one). This shouldn't be surprising, but for some reason it is. Could this dual-problem thing be the golden rule of Web development?
The Ruby Library Rocks. Although short on examples, the Ruby Library for reCAPTCHA does what it needs to do and gets out of my way. Of course, the actual language is unimportant. What matters is that solid libraries in popular programming languages exist. The number of people willing to experiment with a new Web service is low to begin with - forcing them to develop their library beforehand is pointless.
No Limit on Usage. This is where a lot of Web services simply don't get it. I won't name names, but they know who they are. reCAPTCHA allows essentially unlimited use of their service - it's just part of the design. reCAPTCHA does make the reasonable request to "be contacted beforehand if you expect your site to constantly need more than 100,000 reCAPTCHAs solved per day." No access limit means developers can build scalable Web applications based on reCAPTCHA with confidence.

In the end, building a successful Web service that people will gladly tell their friends isn't complicated. It's just a matter of building value and trust.

One more thing. I'm currently using reCAPTCHA on this site in the comments section. There are probably still some browser-specific kinks to work out. If you're so inclined, I would be grateful for a short comment describing your experience, along with your browser and OS.