Why the Web Isn't Ready for Chemistry

Posted by Rich Apodaca Mon, 05 Mar 2007 09:55:00 GMT

Wouldn't it be wonderful if chemical structure searching were as easy as using Google? Draw your molecule, press a button and get the good stuff first. That day may well arrive, but without the creation of some key technologies, the wait will be very long. This article describes an unsuccessful attempt to bring the chemically-aware Web closer to reality.

Background

Recently, I introduced a small Web application called InChIMatic. It lets you draw a structure and search for it though one of a number of popular search engines.

InChIMatic turns a molecular query into text, which is then searched. This magic is made possible through the IUPAC International Chemical Identifier (InChI). InChI has enormous potential for enabling chemical Web searches, but several barriers must be overcome first.

For example, if you run even the most trivial of queries with InChIMatic, you'll quickly see that search engines have only indexed a small number of InChIs. One reason is that InChIs are not yet widely-used by Web authors. But the deeper problem is that many pages containing InChIs are not indexed by search engines. For example, PubChem's vast collection of InChIs is apparently invisible to Google.

Compounding the problems of using InChIs to index chemical content on the Web is the lack of a standard, unobtrusive method for embedding the identifier into Web pages. Understandably, no author wants to invest valuable time and effort on an indexing system that doesn't work with their content and page layout. This problem is the subject of the current article.

Materials and Methods

The InChIMatic article contained a test for how well Google and "invisible" InChIs might work together. If you mouse over the word "1-bromonaphthalene" in the first paragraph of that article, you'll see a small popup window containing the InChI. I accomplished this effect with the following HTML:

<span title="InChI=1/C10H7Br/c11-10-7-3-5-8-4-1-2-6-9(8)10/h1-7H">
  1-bromonaphthalene
</span>

My goal wasn't the popup effect. Instead, I wanted to test the title attribute as an unobtrusive vector for getting InChIs indexed by Google. This excellent idea was a suggestion made by Oliver Koepler in response to Egon Willighagen's article on invisible InChIs.

The idea is simple: InChIs are to be read by machines, not humans. InChIs consist of long strings of text that contain no widely-recognized wrappable characters. As a result, displaying InChIs in Web pages can break page layouts. Even if a wrapping mechanism is used, such as with the overflow attribute, I find InChIs unpleasant to look at and just plain distracting. There's no good reason why any chemist should have to look at them.

Chemists themselves are, understandably, reluctant to invest in ad hoc methods to index their molecular content - they need a real solution. It needs to be simple, it needs to be robust, it needs to be easy to apply retroactively, and it needs to be ready today.

Results

After about two days, Google had indexed the article containing the hidden InChI for 1-bromonaphthalene. Using InchIMatic, I searched Google for the InChI, but only found the same NMRShiftDB item returned in previous queries.

A few days later, a new Depth-First link appeared in Google. It pointed to the main XML Atom feed for Depth-First. This is a step in the right direction, but a far cry from the solution chemists need.

None of the other major search engines supported by InChIMatic returned a link to the Depth-First article containing the hidden InChI. The only new result was retrieved by Search.com. Like Google's result, this new link pointed to Depth-First's main XML feed.

Conclusions

Google doesn't index the contents of the title attribute and may never do so. This should not be surprising. Google has made a fortune in part by staying one step ahead of Search Engine Optimization (SEO) tricksters. By ignoring the contents of the title attribute, Google and other search engines eliminate a real threat that could corrupt the search results that drive their business.

What about other methods for concealing InChIs? One study suggests that none of them will work, either. A two-year old experiment on SEO techniques compared ten different methods to conceal a text string from human viewers. Methods ranged from applying the display:none attribute, to using matched font and background color, to concealing the text in a hidden frame. Although some of these methods may have initially been successful in getting content into Google, none of them work now.

KinasePro recently described a failed attempt to get Google to index a SMILES string hidden in the alt attribute of the img element. Although Technorati did index this content, a Technorati search for the 1-bromonaphthalene InChI returned no hits. A Technorati search for the article containing the hidden InChI did work, suggesting that Technorati also ignores the title attribute.

Why it Matters

Google and other search engines are in a perpetual state of war with SEO tricksters, and rightly so. At stake are search results that make up some of most valuable intellectual property in the world. Any attempt to make InChIs appear invisible to humans is likely to be interpreted by major search engines as spam and treated accordingly. It seems very unlikely that this stance will ever change, regardless of how legitimate the motivation might be.

This leaves us with the fundamental problem of how to build a workable, Web-based chemical indexing system. The CAS registry system has served chemistry as the de facto standard for decades, but for a variety of reasons it is unworkable as an open technology for the Web. The more modern approach of combining InChI and standard search engines has major limitations, as outlined in this article.

If anything in cheminformatics is broken, it's the indexing and retrieval of molecular information on the Web. For those interested in solving a tough problem that really matters, this is a golden opportunity.

Googling for Molecules: New and Improved InChIMatic

Posted by Rich Apodaca Wed, 28 Feb 2007 09:59:00 GMT

InChIMatic, as described previously, is a new service that lets you perform exact structure searches on the Web using Google. A new version offers searching via several other search engines and features a streamlined interface. The screenshot below shows the the current search engine options with 1-bromonaphthalene in the editor window.

There are noticeable differences in the abilities of search engines other than Google to find InChIs. Google seems to offer the most complete coverage. For example, all search engines I've tried have returned either a subset or recapitulation of Google's results.

One of the most striking things about InChIMatic is how specific the search results are. Every molecule that has produced results for me has been a direct hit. Also notable is how few InChIs are currently indexed by Google and other search engines. Tackling that problem will require a convenient and unobtrusive way to get InChIs into Web pages and to get those pages indexed by search engines. But more on that later.

InChI Spam

Posted by Rich Apodaca Wed, 28 Feb 2007 09:27:00 GMT

Do you remember when getting email - any email - was exciting? For me, that time was 1995 and I had just found the Internet. Of course, I remember looking forward to messages from people I knew. But I also remember being blown away by the idea that I could write to anyone with an email account, anywhere in the world for essentially free - and that they could do the same. Back then, it was fun to get email, no matter what the source.

Today, spam is something that I, like millions of others, deal with on a daily basis. And it's not limited to email. Anyone who runs a blog knows about comment spam and how difficult it can be to eradicate it. Even trackback is being used as a medium for blog spam. Of course, keyword Spam on the Web has been a constant problem for search engines - eliminating it has in part led to more than a few fortunes earned at companies like Google.

Recently, I introduced a small Web application called InChIMatic. It lets you conveniently do exact-structure molecular queries thorough popular search engines like Google. Draw your structure, click "Search" and find your matches.

There aren't a lot of InChIs visible to search engines now, as an InChIMatic query for even the most trivial molecule will reveal. Regardless of you views on InChI as a technology for bringing chemistry to the Web, it seems very likely that the number of InChIs visible to search engines will increase significantly over the next few years. And with this increase may come sites dedicated to nothing other than publishing a lot of irrelevant InChIs in the hope of attracting accidental advertising click-throughs.

Right now, searching the Web by InChIs offers a very high signal-to-noise ratio experience - not unlike email in 1995. The shysters haven't yet discovered it and nobody is counting on the technology for mission-critical work. But if and when the idea of indexing chemical content on the Web through InChIs begins to catch on, filtering tools will become essential. If this scenario seems implausible, think back to your first experience with email and how concerned you were about spam then.

Photo Credit: cobalt123

Google for Molecules with InChIMatic

Posted by Rich Apodaca Mon, 19 Feb 2007 10:18:00 GMT

InChIMatic is a simple Web application that uses Google to perform exact structure searches on the Web. After drawing your structure in the editor window, click the "InChI!" button to get a link. This link takes you to a Google query that displays matches for your molecule. You'll need both Java and JavaScript enabled in your browser to use InChIMatic.

The Technical Details

The technology at the heart of InChIMatic is the IUPAC International Chemical Identifier (InChI). An InChI is an alphanumeric string that uniquely identifies a molecular structure. By converting molecular structures to text, InChI makes it easy to use standard Internet tools to do exact structure searches.

The earliest reference in the peer-reviewed literature to using Google for searching InChIs is contained in a 2005 paper. More recently, a service called QueryChem has taken this idea one step further by using the Google API to perform substructure searches based on InChI.

InChIMatic works differently. Unlike a raw Google search, InChIMatic builds a Google query link for you. Unlike QueryChem, InChIMatic doesn't use the Google API and so has none of its restrictions. This does result in a limitation: InChIMatic can only currently be used to for exact structure queries.

The InChIMatic Web application has been discussed in greater technical detail in a previous article. The rapid Web application development framework Ruby on Rails made building InChIMatic a snap. InChIMatic is served by the Ruby application container Mongrel, which is hosted on a Linux server running Apache. Rino provided the Ruby interface to the IUPAC/NIST InChI toolkit. The 2-D structure editor is Java Molecular Editor (JME) by Peter Ertl, which is used with his kind permission.

Open Source (OSI) LogoAside from JME, all components of InChIMatic, from the operating system it runs on to the InChI system itself, are Open Source software.

Using InChI to Raise the Visibility of Your Content

InChIMatic returns many Google results for common molecules. But less common, known molecules return no hits at all. Three factors are responsible: (1) Google doesn't index all InChIs on the Internet; (2) few content providers currently use InChI; and (3) there is no standard and convenient mechanism to embed InChIs into Web pages for indexing by Google.

For these reasons, I consider InChI to be bleeding edge technology. Some will find it useful, most will not. Unfortunately, this state of affairs will persist until problems (1) and (3) are solved.

Nevertheless, if you're technically adventurous, InChIMatic offers a relatively painless way to begin incorporating InChIs into your content and verifying that they get indexed. There's no software to download, install, or upgrade. Forget about operating system incompatibilities (hopefully!). Just point your Java-enabled browser to inchimatic.com.

Although there's no standard method to encode InChIs in Web pages, some interesting ideas have been put forward. Egon Willighagen has proposed a system based on RDFa. Future iterations of InChIMatic may include support for generating scripts and/or markup for including InChIs into blogs and other online content.

Conclusions

InChI is a complex new technology in need of easy-to-use tools. InChIMatic is one such tool that makes it possible to perform exact structure queries using Google.

One of the exciting things about Web applications is how quickly they can evolve. If in trying out InChIMatic you find something you'd like changed or added, please feel free to write me.

An Object-Oriented Framework for Molecular Representation: Getting Started with Octet

Posted by Rich Apodaca Tue, 30 Jan 2007 14:45:00 GMT

If applications are hard to design and toolkits are harder, then frameworks are hardest of all. A framework designer gambles that one architecture will work for all applications in the domain. Any substantive change to the framework's design would reduce its benefits considerably, since the framework's main contribution to an application is the architecture it defines. Therefore it's imperative to design the framework to be as flexible and extensible as possible.

-Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides- Design Patterns

One of the most important considerations when building an application is the choice of framework. As the quote from the Gang of Four implies, there's much more to frameworks than just a collection of re-usable code. At their best, frameworks provide a foundation for thinking about a problem domain and a language for communicating with other developers about it. In this article, I'll introduce Octet, an object-oriented framework for molecular representation.

The Molecular Representation Problem

Isn't molecular representation a solved problem? After all, don't SMILES, Molfile, InChI, and CML adequately represent any molecule the average software developer is likely to see?

As previously discussed, molecular representation technologies have stagnated while the molecules chemists themselves now routinely make and use have continued to become more and more "exotic." Developers are now faced with the thorny problem that a variety of common structural motifs in chemistry can't be adequately represented with industry-standard cheminformatics tools.

This point is so important, I'll repeat it: cheminformatics has fallen behind chemistry in the kinds of molecules it can work with. Quick fixes only allow the problem to fester; what's needed is a comprehensive solution. This is Octet's problem domain.

Every framework is bounded by a specific problem domain. Although the size of the domain can vary, a framework provides a comprehensive solution within it. For complex and poorly standardized domains (such as molecular representation), a good framework can greatly accelerate application development.

A good frameworks stays within its problem domain. One of the most important reasons is to prevent featuritis, the root of much software evil. Keeping a framework focused on its core mission makes it much more likely that it can remain documented, tested, extensible, and efficient.

By intention, a variety of features fall outside Octet's problem domain and so will never be directly supported. For example, rendering 2-D structure diagrams is a common problem in cheminformatics that has nothing to do with solving the molecular representation problem. Similarly, reading and writing SMILES strings and Molfiles are supported by many toolkits, but not by Octet directly. After all, it's the inherent limitations of these languages that Octet is trying to overcome.

Higher-level functionality such as legacy language support and 2-D rendering, although not part of Octet itself, can be developed with Octet as a foundation. For example, two Octet add-on frameworks specifically address these problems. They are called Rosetta and Structure, respectively.

About This Series

This article is the first in a series discussing Octet. Future articles will describe in detail Octet's design, implementation, and use. Although Octet has come a long way, it's far from finished. My motivation for writing these articles is to hear what you have to say about Octet, so please feel free to contact me.

Although Octet is written in Java, code examples discussed here will be written in Ruby. I've taken the same approach in discussing the Chemistry Development Kit (CDK) and Structure-CDK. Ruby's brevity and comfortable syntax make it ideal for both writing and discussing code.

Ruby Java Bridge (RJB) is the magic technology that makes this possible. Previous articles have discussed the installation and use of RJB on Windows and Linux.

A Simple Test

Assuming you've installed Ruby, RubyGems and Ruby Java Bridge, you can perform a simple demonstration of Octet in Ruby:

require 'rubygems'
require_gem 'rjb'
require 'rjb'

BasicMoleculeBuilder = Rjb::import('net.sf.octet.builder.BasicMoleculeBuilder')
RepresentationKit = Rjb::import('net.sf.octet.util.RepresentationKit')
MoleculeKit = Rjb::import('net.sf.octet.util.MoleculeKit')
System = Rjb::import('java.lang.System')

builder = BasicMoleculeBuilder.new

RepresentationKit.buildHexane(builder)

molecule = builder.releaseMolecule

MoleculeKit.printMolecule(molecule, System.out)
The above code generates an Octet representation for n-hexane, and prints the representation to the console. To run this example, save the above code to a file called test.rb in your working directory. Then add octet-0.8.2.jar, which can be found in the Octet-0.8.2 source distribution, to the same directory. The test can then be run with the following sequence of commands:
$ export CLASSPATH=./octet-0.8.2.jar
$ ruby test.rb
**Molecule Properties**

Atom Count: 6, Bonding System Count: 5

Atoms:
atom: C[0] (2nu 0e, 0or, 0.0fc, 1bs, 1n, 4.0val, 3ih )
atom: C[1] (2nu 0e, 0or, 0.0fc, 2bs, 2n, 4.0val, 2ih )
atom: C[2] (2nu 0e, 0or, 0.0fc, 2bs, 2n, 4.0val, 2ih )
atom: C[3] (2nu 0e, 0or, 0.0fc, 2bs, 2n, 4.0val, 2ih )
atom: C[4] (2nu 0e, 0or, 0.0fc, 2bs, 2n, 4.0val, 2ih )
atom: C[5] (2nu 0e, 0or, 0.0fc, 1bs, 1n, 4.0val, 3ih )

No non-natural isotopic distributions specified.

No Orbitals specified.

Bonding Systems:
bonding system:  ( 2be, 0abe, 2a, 1ap ) [ (0, 1) ]
bonding system:  ( 2be, 0abe, 2a, 1ap ) [ (1, 2) ]
bonding system:  ( 2be, 0abe, 2a, 1ap ) [ (2, 3) ]
bonding system:  ( 2be, 0abe, 2a, 1ap ) [ (3, 4) ]
bonding system:  ( 2be, 0abe, 2a, 1ap ) [ (4, 5) ]

Atom Pairs:
atom pair: (0, 1) (1.0 bo)
atom pair: (1, 2) (1.0 bo)
atom pair: (2, 3) (1.0 bo)
atom pair: (3, 4) (1.0 bo)
atom pair: (4, 5) (1.0 bo)

No Atomic Configurations specified.
No Conformation specified.

As you can see, Octet shares the same concepts and vocabulary as FlexMol. We'll drill down into the meaning of the output in later articles. The important thing to remember is that we can print out a report like the one above for any Molecule, no matter how complex.

Conclusions

Octet is an object-oriented framework designed to solve the molecular representation problem and serve as a solid foundation for a variety of cheminformatics applications. Of course, there's much more to Octet than the simple example shown here. Future articles will describe in greater detail the design and use of Octet through illustrative examples.

Older posts: 1 ... 3 4 5 6 7 ... 9