Depth-First: Tag web

Chemistry, The Web, and Netflix

Rich Apodaca — Wed, 11 Jun 2008 21:03:00 -0400

If you've ever rented movies from Netflix, you've probably noticed the information box that pops up when you hover over a movie image. If you just want a quick peek at what a movie is all about, this simple feature can save a great deal of time and effort in mousing around, clicking, and general navigation annoyance. It turns out that chemical compounds have a lot in common with movies in that they both can be referred to through one or more identifiers and they both have a lot of interesting metadata linked to them. This article shows that what works for Netflix can also work for chemistry.

The Problem

Interpreting IUPAC nomenclature and references to compound numbers is a major chore when working with chemistry experimental sections. When paper documents are used, this typically involves flipping pages back and forth many times between the narrative and the experimental section. With Web documents, this is usually either impossible or very inconvenient, and so the PDF is printed to paper.

A Demonstration

The following text is an edited and re-formatted passage taken from the experimental section of a paper published in Beilstein Journal of Organic Chemistry. If you hover over any hyperlink for half a second or more, a balloon will pop up showing you the chemical structure of the substance being referred to. Mousing away from the link hides the balloon.

1-[(1R)-1-(2- {[tert-Butyl(dimethyl)silyl]oxy}ethylhexyl] -2-piperidinone (34)

5-Bromopentanoyl chloride (1.84 g, 9.25 mmol) was added to a stirred solution of primary amine 32 (2.00 g, 7.71 mmol) in dry 1,2-dichloroethane (30 cm³), followed by anhydrous NaHCO₃ (0.78 g, 9.25 mmol). The reaction mixture was left to stir at room temperature for 16 h. The resulting mixture was filtered through a pad of celite, which was then washed with CH₂Cl₂. The combined filtrate and washings were then evaporated in vacuo to yield a crude orange oil (4.06 g), which was purified by column chromatography on silica gel with hexane-EtOAc (7:3) as eluent to give the 5-bromo-N-[(1R)-1- (2-{[tert-butyl(dimethyl)silyl]oxy}ethyl)hexyl pentanamide 33 as an orange oil (2.92 g, 89%).

A portion of the bromoamide 33 (0.20 g, 0.47 mmol) was dissolved in dry THF (3 cm³) containing a suspension of potassium tert-butoxide (587 mg, 0.52 mmol), and the mixture was stirred at room temperature for 25 min before being diluted with EtOAc (10 cm³). The mixture was then washed with saturated aqueous sodium chloride solution (5 x 2 cm³). The combined organic extracts were dried (MgSO₄), filtered and evaporated in vacuo to yield a crude yellow oil (0.16 g), which was purified by column chromatography on silica gel with hexane-EtOAc (85:15) as eluent to give 1-[(1R)-1-(2-{[tert- butyl(dimethyl)silyl]oxy}ethylhexyl]-2-piperidinone 34 as a pale yellow oil (0.13 g, 81%).
-Michael, Accone, Koning, and Westhuyzen, Beilstein J. Org. Chem. 2008, 4, 5

This demo has been tested on Internet Explorer 6/7, Firefox 2, and Safari 3.

Technologies

Although this demonstration is built on numerous Web technologies, two are at the top of the stack: the vector graphics rendering engine of ChemWriter and the open source Javascript library Balloon.js.

Chemical structures are displayed as lightweight Adobe Flash SWF files, as described in a previous Depth-First article. Software based on ChemWriter converts a molecular connection table into vector graphics commands for the Flash runtime with the help of the open source Transform SWF library.

Playing to the Web's Strengths

The Web is a new medium with a completely different set of rules compared to print media. One of its biggest strengths is interactivity: the ability to see something of interest and to immediately be able to find out more about it. One of its biggest weaknesses, even today, is technology standards. It's not enough to create interactivity; that interactivity must also fit within the technical constraints imposed by a medium that is still a work in progress.

As journal publishers and others grapple with how to approach the inevitable transition to purely Web-based scientific communication, it's important to keep both the strengths and limitations of the Web in mind. To date, nearly all attempts to create Web-based versions of chemistry journals have simply tried to duplicate the form of the print medium. This has resulted, if anything, on an even greater reliance on paper, resulting in valuable information being used well below its full potential.

Conclusions

This article has demonstrated a simple labor-saving technique in which chemical structures can be visualized by hovering the cursor over specially-designated chemical identifiers. There's quite a bit more that can be done with chemical vector graphics, chemical information, and Web technologies commonly used in consumer services like Netflix. Future articles will discuss some possibilities.

The Daily Molecule: The Wonders of Chemistry - One Molecule at a Time

Rich Apodaca — Wed, 14 May 2008 11:58:00 -0400

Chemistry is a big field judged by any standard, including the proliferation of American Chemical Society (ACS) divisions. Each subdiscipline in chemistry is in turn so big, that once a chemist becomes 'differentiated' it's easy to lose touch even with neighboring subdisciplines. It doesn't have to be that way. This article introduces a new service, The Daily Molecule designed to make it just a little bit easier (and hopefully fun) to stay in the chemical loop.

What Is It?

The idea is simple: every weekday, a new molecule will be featured on The Daily Molecule with a short write-up and some leading references. Although molecules in the news will get first priority, any molecule is fair game.

The material for The Daily Molecule will be drawn from Chempedia, which in turn gets some of its content from Wikipedia. In other words, the entries on the Daily Molecule will be largeley written by my fellow chemists.

The process of creating a Daily Molecule entry is not time-consuming, but much of what is being done manually now could be automated in the future. The technology platform lends itself well to many forms of chemistry-specific modification (see below).

I hesitate to use the term 'blog' to describe The Daily Molecule, but the description may be helpful to an extent.

The Daily Molecule is unlike a blog in that most content will be generated by others, selected by some criteria, reformatted for consistency, and published. In that sense, The Daily Molecule is a something like a mini scientific journal, but it turns the process of acquiring content on its head.

If chemistry ever evolves beyond the current model of publication, which seems inevitable at this point, the journals of the future may resemble The Daily Molecule in one or more ways.

Technology

The software running The Daily Molecule is a modified version of SimpleLog, a Web application based on Ruby on Rails. Unlike most blogging engines, SimpleLog focuses on implementing only the most basic publication features, and doing them to perfection. If you know a little Ruby and can work with Rails, you can do a lot with SimpleLog.

One of the first items of business will be to implement reCAPTCHA support and activate comments on articles.

Some ideas for chemically-enabling The Daily Molecule include a graphical abstract sidebar and (sub)structure search. Currently, the 2D chemical structure images posted to The Daily Molecule have complete connection tables embedded as metadata, a feature with some interesting possibilities.

The Molecule of the Day/Week/Month

The basic idea behind The Daily Molecule is not new. Many other services have sprung up over the last ten years that operate, at least on the surface, similarly. Some examples:

Molecule of the Day
ACS Molecule of the Week
Drugs and Poisons
Saturday Night Synthesis
The Molecule of the Month (may be the oldest continuously-operated MOTM site in existence)
3dchem.com Molecule of the Month
Protein Spotlight
PDB Molecule of the Month
Prous Molecule of the Month

Quite a few others don't appear on this list.

The different idea behind the The Daily Molecule is that chemical content already exists in on the Web in machine-readable format with licenses that permit its re-use; all that's needed is a way to aggregate, format, and package that information in a form suitable for once-daily scanning and cheminformatics manipulation.

Conclusions

Like no other medium, the Web blurs artificial distinctions: between work and play; between private and public; between on-topic and off-topic; between fame and obscurity; between mine and yours; between big and small; and between profit and non-profit. Chemistry may be late to the party, but is not immune to its call.

Streamlining Cheminformatics on the Web: Let InChI Do the Heavy Lifting and Get Some REST

Rich Apodaca — Mon, 01 Oct 2007 10:53:00 -0400

A recent Depth-First article discussed the advantages of minimal Web APIs in Cheminformatics. Recently, Antony Williams unveiled some simplified ChemSpider URL schemes, mainly from the perspective of enabling Google indexing. However, it's possible to take this scheme much, much further. Here I present a proposal for radically simplifying (and unifying) the development of cheminformatics Web APIs and the software that interacts with them.

The New ChemSpider URLs

ChemSpider now has several new kinds of URLs. For the purposes of this article, the most interesting of these are of the format:

These URLs may seem unremarkable, but there's much more than meets the eye. They let anonymous developers query ChemSpider about specific substances - without needing to know much at all about how ChemSpider itself works. Goodbye API. Goodbye API support. Goodbye API documentation. Goodbye angle brackets. Hello to getting stuff done. It's all very RESTful. Well, at least it could be that way with some minor modification.

Some Recommendations

ChemSpider hasn't quite reached that place where the API just disappears. The problem is that the ChemSpider URLs listed above point to query results pages, not compound summary pages. Were these URLs to redirect to a summary page, we could construct the following URLs to extract ChemSpider resources (I've replaced the '=' sign with a '/' for simplicity):

.../InChIKey/DEIYFTQMQPDXOT-RERXVCSDCZ Get all resources for the molecule identified by the given InChIKey - i.e., "Compound summary page"
.../InChIKey/DEIYFTQMQPDXOT-RERXVCSDCZ/molfile.mol Get the molfile for the molecule identified by the given InChIKey
.../InChIKey/DEIYFTQMQPDXOT-RERXVCSDCZ/small_image.png Get the small image for the molecule indentified by the given InChIKey.
.../InChIKey/DEIYFTQMQPDXOT-RERXVCSDCZ/large_image.png Get the large image for the molecule identified by the given InChIKey.
.../InChIKey/DEIYFTQMQPDXOT-RERXVCSDCZ/citations.xml Get the list of citations for the molecule identified by the given InchIKey, in XML format.

Jane, a developer building Web applications on top of this new ChemSpider API, would immediately notice that things just work. Let's say her online database stores IC₅₀s at the dopamine D₂ receptor. On the summary page for each molecule, she wants to link out to the ChemSpider compound summary page, if available. She would simply construct the InChIKey on her server, build the needed ChemSpider URL and GET it. An HTTP 404 would indicate no molecule with that Key exists on ChemSpider and so no link would be shown. An HTTP 200 would indicate ChemSpider has the molecule, and so the link would appear.

Conclusions

It would be interesting enough if ChemSpider adopted a system like that described here. But the real power of this approach would emerge if multiple Web services were to adopt it. By following a simple set of conventions, these services would enable third party developers to elegantly mashup all manner of cheminformatics resources into applications unimaginable today.

Technically, there's nothing that prevents this system from being implemented on every free chemistry database in existence today. However, doing so would transfer a significant degree of control from service operators to third-party developers. Not all providers will be comfortable with that idea.

Cheminformatics Web service providers need to carefully consider whether they're trying to develop a platform or an integrated service. As history has shown, the strategies, and upside potential, for each approach can differ dramatically.

Free Chemistry Databases on the Web: Creating a Comprehensive Guide

Rich Apodaca — Mon, 07 May 2007 09:32:00 -0400

One of Depth-First's more popular articles is a summary of free databases titled Thirty-Two Free Chemistry Databases. Clearly there is a need to link the producers of free chemical databases (developers) with the potential users of these services (chemists). Chemistry is slowly emerging from a decades-long period of over-reliance on a single supplier of information. As new players enter, they'll need some way to have their message heard.

The Problem

As evidence of this need, I'm getting more requests to list additional services on the Thirty-Two Databases article - or to provide an updated review of a service already there. This is wonderful!

One approach would be for me to simply research and write an updated article reviewing the new additions myself. The problem is that thirty-two is already a very large number to deal with. My guess is that there must now be well over sixty or seventy free chemistry databases. That's far too many for one person to research properly on their own.

On the other hand, the Web is all about collaboration, so why no try to use it that way?

An Idea

Here's the idea: if you run a free database or other online chemistry service and would like to promote it, post a comment to this article containing a link and brief description of what makes your service different/useful. If you've used a free chemistry database, feel free to provide your thoughts on it. If there's a free database you wish existed but doesn't yet, feel free to write about that. Unlike the other articles on this site for which comments are closed after two weeks, this article's comments will remain open indefinitely.

After some period of time, I'll use these comments to write a new article highlighting the new material.

Notice the use of the word "free". A free database can be used by any member of the general public without fees or a lengthy registration process. This includes both free speech and free beer services. There are more restrictive definitions that could be applied, but let's not worry about those just yet. Free beer is better than no beer at all.

Links can either be in HTML or Markdown. Here's one example of each:

<a href="http://megamolecules.com">MegaMolecules</a> (HTML)

[MegaMolecules](http://megamolecules.com) (Markdown)

The Outcome

I have no idea what kind of response this experiment will generate. But if past experience is any guide, large numbers of chemists are keenly interested in free chemistry databases. All they need is a link.

Image Credit: Kate and Dave Hugh

Update: Four Free 2-D Structure Editors for Web Applications

Rich Apodaca — Sun, 22 Apr 2007 11:26:00 -0400

A previous article discussing the deployment of four free 2D structure editors has been fixed. The sample pages demonstrating how to obtain a molfile from each have also been restored.

A 2D Chemical Structure Editor for the Web: Embracing Constraints in Firefly

Rich Apodaca — Wed, 18 Apr 2007 10:09:00 -0400

A previous article outlined the major concepts behind Firefly, a new 2D structure editor for the Web. Structure editors are unique in that they require solutions to problems in so many different areas: graphical user interface design; chemical structure aesthetics; 2D graphics and geometry; molecular representation; and graph theory, to name a few.

These are important considerations, but they pale in comparison to the biggest design challenge: Firefly must be deployed and run in a heterogeneous network environment. This one constraint frames all of the basic design questions involving platform, programming language, footprint, and mode of deployment. And this is a Good Thing.

Platform, Programming Language, and Deployment

Considering the diverse array of hardware and operating systems on the Internet, it's amazing that anything works at all. Although standards save the day in most cases, there is no all-purpose solution when it comes to interactive Web technologies. Today, there are essentially three options for Firefly:

Flash To my knowledge, no 2D structure editor has ever been implemented in Flash. (This alone sounds like a good reason to try it sometime.) As a platform, Flash has a lot going for it, including a large installed base, and the abstraction layer OpenLaszlo. On the down side, Flash support on platforms such as Linux has not been what it could be. As Flash continues to mature, this problem may become less important.
Ajax Essentially nothing more than HTML and JavaScript - and no plug-ins of any kind. At least two editors have been written in Ajax: WebME and PubChem's editor. Ajax works in a lot of situations, but in my opinion it still isn't up to the job of creating a responsive, interactive structure editor.
Java Applet A massive installed base, support for just about every kind of hardware in use, a robust object-oriented language with a powerful 2D graphics and GUI libraries, and it's even Open Source. Although Flash and Ajax have their advantages, Java is the best option for the foreseeable future. There are several Java structure editors to choose from, and for good reason. (Future articles will discuss what makes Firefly different.)

What about a Java application? Unfortunately, not even a user's ability to install software on their own machines can be taken for granted in the context in which Firefly will be running. For example, many companies enforce prohibitions against employee-installation of non-approved software. Machines found in libraries or other public places may face similar limitations. Given these real possibilties, an applet is the only option that makes sense.

As to the version of Java that Firefly is built on, JDK 1.4.2 seems to have become the unwritten standard. It's mature enough the have most of what Java has today, but is old enough to be on most machines. Even with this compromise, Firefly will have an impressive array of functionality to work with: Java2D, Swing, and many performance optimizations relative to earlier Java versions.

Footprint

High-speed Internet access is ubiquitous. Bandwidth is now a commodity. Memory is practically free and processors - don't get me started on processors these days. But developers who take massive bandwidth and staggering processor power for granted are setting themselves and their users up for many unpleasant interactions. Firefly must be lightweight, responsive, and fast to deploy under any network load and on 80% of the hardware on the Web. Limiting its footprint to 150K will increase the chances of success.

With such a small footprint, none of the currently-available open source Java cheminformatics libraries (e.g. CDK, JOELib, Octet) will be of much use. They are simply too big. Even the smallest of them (Octet) weighs in at about 300K. Of course, it's possible to strip out unnecessary features from these libraries. But even then, a great deal of unused functionality would remain. This is the unavoidable downside of general-purpose libraries. By developing a small cheminformatics library specifically designed to power a 2D structure editor, Firefly should be able to meet the 150K target.

Is 150K a realistic goal? My previous experience in developing Structure and Structure-CDK taught me that with Java2D, very lightweight structure-rendering code is well within reach. For example, the Structure-CDK jarfile is an unoptimized 39K. (But even Structure-CDK faces the same problem as other general-purpose libraries - it's much bigger than it needs to be. In other words, some Structure-CDK concepts may be applicable to Firefly, but the code itself must be completely re-written.)

When combined with the fact that a lot of cheminformatics functionality, such as structure clean-up, can be offloaded to a server, 150K begins to look like a very reasonable target.

As a final encouragement, consider that everything Java Molecular Editor does, including SMILES canonicalization, is contained in a jarfile no larger than 40K.

Wrap-Up

As you can see, even before a single line of code was written, Firefly's design was constrained in some very important ways. Identifying and embracing these constraints doesn't ensure success, but it greatly increases its chances. In articles to follow, I'll show how Firefly was designed to thrive within these constraints.

Image Credit: frogmuseum2

Roll Your Own Chemical Database With Free Components

Rich Apodaca — Fri, 13 Apr 2007 10:27:00 -0400

Are you thinking of building a free chemical database but would rather not rent and maintain a bunch of proprietary software components? Norbert Haider has thought a lot about this problem and offers some helpful resources to get you started:

Creating a web-based, searchable molecular structure database using free software Step-by step case study
How to create a web-based molecular structure database with free software A presentation
checkmol/matchmol Open source command-line utility for 2D (sub)structure matching
mol2ps Command-line utility for converting molfiles into Postscript files

Haider's system can be deployed on commodity hardware running open source operating systems. In other words, the cost of setting up a system like the one he describes is practically zero.

Creating and open sourcing your own custom components is one way to go. Building on top of existing open source tools like CDK, Open Babel, Octet and JOELib is another.

Haider's work raises an interesting question. Has anyone assembled a complete, ready to install general purpose chemical database package built from open source components? It for no other reason, such an exercise would give an excellent idea of what the dogfood tastes like.

Eleven Qualities of The Perfect Line Notation for the Web

Rich Apodaca — Wed, 14 Mar 2007 10:18:00 -0400

If you had to design the perfect line notation for the Web, what would it look like? This is hardly an academic exercise given the central role played by line notations in information systems. For a variety of reasons, existing line notations may not be the right match for the Web. This article explores this question and outlines the main qualities needed by a Web-friendly line notation.

A Few Lines About Line Notations

A line notation is any system that converts a molecular structure into a single line of text. Chemists have been using line notations for over 140 years - long before the advent of computers. Because of their versatility, line notations are frequently used in situations they were not designed for. When this happens, limitations become apparent, resulting in renewed efforts to build a better system.

As noted previously, the invention of new line notations is a field whose popularity ebbs and flows over time. Currently, the three most important line notations are:

IUPAC Nomenclature
Simplified Molecular Input Line Entry System (SMILES)
IUPAC International Chemical Identifier (InChI)

Each of these systems has its own unique characteristics. IUPAC nomenclature is the oldest and most widely-used line notation. It appears in numerous contexts, including Web pages, peer-reviewed journals, reports, patents, MSDS sheets, catalogs, and reagent bottles. By comparison, SMILES is a distant second in popularity. It's main role has been to facilitate machine entry of structural information by humans, like this. InChI is the newest of the bunch. It serves both as a line notation and as a unique identifier requiring no central authority.

The Perfect Line Notation for the Web

The emergence of the Web as a standard information delivery platform has refocused the attention of many developers on the line notation problem. With this idea in mind, here are some guesses about the qualities of the ideal Web-friendly line notation.

Readily Encodable and Decodable by Humans. There's something unnerving about a line notation that can't easily be deciphered by humans. Is this really the right string? Did I copy it completely? This problem surfaces with every line notation, but some fare better than others. IUPAC nomenclature, for example, is one of the first things taught in many beginning organic chemistry classes. It's complicated, but still understandable by non-experts.
Readily Encodable and Decodable by Machines. It may be relatively simple for humans to read and write IUPAC nomenclature, but not so for machines. Software that reads and writes SMILES, on the other hand, is by comparison easy to write. This explains the abundance of software packages that handle SMILES and the scarcity of those that handle IUPAC nomenclature.
Uses URI-Safe Characters Only. A URI uniquely identifies every document on the Internet. Why can't a line notation be used in combination with a URI to uniquely identify every molecule? One reason is that every line notation currently in use contains characters unsafe for use in URIs. Any line notation designed for use on the Web needs to avoid these characters in its syntax. Update: InChI doesn't use unsafe characters, but it does use the reserved characters "=", "?", and "/". These characters may therefore need to be escaped, depending on the context.
Encodes All Molecules. Buried within every line notation is an opinion on what chemistry is really about. To operate on the Web, these opinions need to be as closely aligned as possible with those of chemists themselves. Several Depth-First articles have discussed the limitations of existing line notations as molecular languages.
Compact. Nobody wants to look at or manipulate a line of text that's longer than it needs to be. Of course, the more expressive a line notation is, the more verbose it will be. In other words, qualities 4 and 5 will always be in conflict.
Canonicalizable. A line notation supports canonicalization when it specifies rules that can be guaranteed to always generate the same line notation for a given molecule. This feature enables many labor-saving assumptions. For example, a canonical representation makes a great identifier in a database, reducing the cost of storing and retrieving structural information.
Explicit Hydrogen Atom Encoding. SMILES makes few requirements regarding hydrogen atom encoding. As a result, each software implementation is left to its own devices. The resulting confusion is the price paid for the convenience (Quality 1) of a compact notation (Quality 5).
Hierarchical Structure. One of InChI's innovations was the introduction of a hierarchical encoding system. This system, also referred to as InChI "layers", enables a molecule to be viewed at several levels of resolution: as a molecular formula; as a network of atoms; as a network of atoms containing hydrogen atoms; as an atomic network with stereochemistry; and so on. I'm unaware of any reports in which this feature has been exploited in a practical way, although they aren't difficult to imagine.
Flat Structure. By grouping structural features into layers (Quality 8), InChI introduces a lot of complexity that is absent in SMILES and even IUPAC nomenclature. This complexity, in part, makes it difficult for both humans and machines to properly encode InChIs (Qualities 1 and 2). Given this complexity, and the fact that the utility of hierarchical encoding has yet to be conclusively demonstrated, it may be better to avoid it.
Open Source Software Implementation. No encoding standard in today's world stands a chance of gaining acceptance without an open source reference implementation. InChI broke new ground in this area and should serve as a model for any system that follows.
Unencumbered by Patents. The success of molfile and SMILES as de facto standards derives partly from the decision made by their authors to refrain from patenting their languages. As a result, developers are motivated build their own implementations, rather than invent yet another language.

Conclusions

A robust and modern line notation system is a key technology for chemically enabling the Web. Existing line notations, although useful in many contexts, were not designed with this particular role in mind. The time has come to consider whether a new line notation system, designed specifically with the Web and modern chemistry in mind, might offer a better solution.

Photo credit: Wenwen - Flickr

Web 2.0 and Chemistry

Rich Apodaca — Mon, 12 Mar 2007 10:23:00 -0400

Chemistry on the World Wide Web is picking up speed like a runaway train. A remarkable number of groups are devoting considerable time, effort, and money to a wide variety of chemical web applications.

-Stu Borman, Chemical & Engineering News, September 16, 1996

Whatever happened to chemistry and the Web? Stu Borman's article is a wonderful read, if for no other reason than to illustrate what makes technology predictions so tricky. Borman cites these developments, among others, as evidence of the rise of chemistry on the Web circa 1996:

An AltaVista search for the word "chemistry" returned 400,000 documents. (Remember AltaVista? Google now lists over 115 million documents containing the word "chemistry").
Popular Web browsers such as Navigator 3.0 and Explorer 3.0 support Greek characters, an important characteristic of chemical information. (Support for chemistry in Web browsers has barely improved in the meantime.)
A Java browser for Chemical Markup Language (CML) was soon to be released. (CML is still in use and supported by many software packages, although it has not been widely adopted. For example, the builders of PubChem opted for a custom XML format over CML.)
Virtual Reality Markup Language (VRML) could be used display molecules in three-dimensions. (This article gives a brief overview of the rise and fall of VRML.)
Chemscape Chime, a Navigator plugin that interprets chemical information, could be freely downloaded. (~~MDL has apparently since discontinued free distribution of Chime.~~ The free as in beer plugin is rarely seen in use on the public Web.)
Chemically oriented Java applets such as "WebSketch" are proliferating. (Java has had a difficult time making it as a browser technology. Security has had little to do with it, though.)

Stu Borman's article serves as a clear reminder that chemistry on the Web is almost as awkward today as it was at the dawn of the Internet age. The problem isn't lack of content; it's the lack of robust, widely-adopted, open standards that take the peculiarities of chemical information into account, and the free software to support them. Coming to terms with past failures in this area is one way to increase the chances of future success.

Yet Another Free Chemistry Database: FooDB

Rich Apodaca — Tue, 06 Mar 2007 11:09:00 -0500

FooDB contains over 1,900 structures used as food additives in the United States. The data in FooDB are provided by the FDA EAFUS site. You can search by CAS number, IUPAC name, or molecular formula. And in what is likely to be a trend to watch closely, FooDB is powered by the Web application framework Ruby on Rails.

FooDB is not alone: the number of free chemistry databases on the Web just keeps growing. How this trend ultimately plays out is anybody's guess.

One thing is clear: the point is rapidly approaching at which database aggregation technologies will start to matter. No chemist wants to search through over thirty databases to find the information they need on a molecule. They want it delivered in one quick, intuitive, user-friendly package. Here's another example of something that's broken in cheminformatics. Like all broken things, it's the source of great frustration for users and great opportunity for developers.