CDK-Taverna workflow

We are glad to announce that our article about CDK-Taverna, an open workflow solution for cheminformatics, is now online on BMC Bioinformatics. CDK-Taverna, which lives at http://www.cdk-taverna.de/, features more than 160 workers for various tasks in molecular informatics.

The workflow paradigm allows scientists to flexibly create generic workflows using different kinds of data sources, filters and algorithms, which can later be adapted to changing needs. In order to achieve this, library methods are encapsulated in Lego(TM)-like building blocks which can be manipulated with a mouse or any pointing device in a graphical environment, relieving the scientist from the need to learn a programming language. Building blocks, so-called workers, are connected by data pipelines to enable data flow between them, which is why pipelining is often used interchangeably for workflow.

With ChEBI release 55 we have introduced the new submission tool which now allows our submitter to create ChEBI datasets themselves which a) gives our users more control over what they want to see in ChEBI and b) saves our curators some duplicate work.

In preparation for a release, here is what the ChEBI team does.

• Create automatic cross-references to PubChem, UniProt, IntEnz, BRENDA, SABIO-RK, ArrayExpress, IntAct, Patents etc…These are all run a week before the release and are based on ChEBI identifier matching or text matching.
• Annotation of entity of the month
• Submissions deposited directly into the database by users are processed by our annotators.

On the release day:

• Data is exported overnight into multiple formats, OBO format, SDF, Oracle data dumps and PostgreSQL/MySQL dumps.
• Public web site updated with the entity of the month.
• Statistics generated and stored.
• Sitemaps are generated to be used by search engines like Google for indexing.
• Finally data is deposited into PubChem and the EB-eye search engine is updated.

Berlin Dahlem-Dorf tube station

I’m attending the 3rd International Biocuration Conference in Berlin, which looks like a pretty successful meeting in terms of numbers of participants. Seems like somewhere between 100 and 200 participants. It looks like the time for recognition for biocuration and curated biological resource has come. The International Society for Biocuration has been inaugurated yesterday. People from publishing companies such as Nature are attending.

Janet Thornton, director of EBI, gave the opening keynote yesterday evening, rehearsing some of the history of biocuration and looking into the future of securing funding for biocuration through the Elixir project.

I’m now listening to Philip Bourne talking about “Changes in Scholarly Communication and the Potential Impact on Biocuration”. He talks, beyond a lot of other things, about the author embedding semantic information into the orginal manuscript and introduces part of his own work with Microsoft on a plug-in for word to do this enrichment.

There is nothing overly particular about this meeting but it strenghens my feeling that we are at the point where finally the idea of preserving the information in the first place, in the scientific document, has come. Both Dietrich’s semantic enrichment conference as well as this one was well attended by publishers – Elsevier and Nature where at both. This scientific document can then become both a scientific article as well as one or many database entries.

Another notion that has come up a couple of times is the question of reward for authors to make and submit semantically rich documents. One of the ideas is fast-tracking those documents – publishing them faster.

ChEBI – An open ontology for Chemical Entities of Biological Interest

Paula de Matos (1), Kirill Degtyarenko (2), Marcus Ennis (1), Janna
Hastings (1), Inma Spiteri (1) and Christoph Steinbeck (1)

(1) European Bioinformatics Institute, Hinxton, Cambridge, UK
(2) European Patent Office, The Hague, The Netherlands

Chemical Entities of Biological Interest (ChEBI) is a freely available, manually annotated resource providing data such as chemical nomenclature, an ontology and chemical structures. The ChEBI ontology imposes meaning onto the data according to four subontologies: molecular structure, application, biological role and subatomic particle. As a cheminformatics resource it provides chemical substructure and similarity searching using the Chemistry Development Kit (CDK). ChEBI annotates structures with various properties such as charge and mass and names including brand names and International Nonproprietary Name (INN). This extended coverage is complemented by manually annotated names appearing in Patents and Patent identifiers. In addition names can now appear in French, German, Latin and Spanish. Acting as a chemoinformatics portal to other bioinformatics resources, ChEBI has introduced automatically generated links to resources such as UniProtKB, IntAct, ArrayExpress, SABIO-RK or PubChem. ChEBI lives at http://www.ebi.ac.uk/chebi/, where it is also available for download in
a variety of formats and accessible via webservices.

I have just been assigned the task to review the recent Iterator/Iterable patch for CDK and will protocol my task for reference reasons.The patch was published on the CDK patch tracker.

The executive summary of the reviewing task goes like:

1. browse the code
2. mark up code you think is buggy
3. note missing unit tests
4. note missing JavaDoc
5. warn for subjected PMD warnings
6. optionally note other problems
7. optionally any other comment you have

So, let’s see how it went:

Browse the Code

I got the gzipped archive with Egon’s patch and looked at the code. A large part of the changes involve

removing       public Iterator<IIsotope> isotopes() {
and adding    public Iterable<IIsotope> isotopes() {

to enable things like

double overallCharge = 0.0
for (IAtom atom : molecule.atoms()) {
overallCharge += atom.getCharge();
}

In order to implement Iterable, one needs to have methods returning an Iterator, so a lot of code essentially implements those.

Remove:       public java.util.Iterator atoms() {
and add:      public Iterable<IAtom> atoms() {
logger.debug("Getting atoms iterator");
return super.atoms();
}

And then there is code actually using those iterators and all of these instances had to be adapted too (I’m just giving the patch syntax):

for(IReactionScheme rm : scheme.reactionSchemes()){
-                       for(Iterator<IAtomContainer> iter = getAllMolecules(rm, molSet).atomContainers(); iter.hasNext(); ){
-                       IAtomContainer ac = iter.next();
-                       boolean contain = false;
-                       for(Iterator<IAtomContainer> it2 = molSet.molecules();it2.hasNext();){
-                               if(it2.next().equals(ac)){
-                               contain = true;
-                               break;
-                       }
-                       }
-                       if(!contain)
-                               molSet.addMolecule((IMolecule)(ac));
-                       }
+                for (IAtomContainer ac : getAllMolecules(rm, molSet).atomContainers()) {
+                    boolean contain = false;
+                    for (IAtomContainer atomContainer : molSet.molecules()) {
+                        if (atomContainer.equals(ac)) {
+                            contain = true;
+                            break;
+                        }
+                    }
+                    if (!contain)
+                        molSet.addMolecule((IMolecule) (ac));
+                }


Overall, the patch affected 288 classes including test classes, with almost 2000 lines of code changed.

Mark up code you think is buggy

Impossible to do for me for such a large bunch of changes, so one must rely here on the unit tests to work.

Note missing unit tests

Egon had posted some notes about comparing failing and passing between unit tests earlier but we also need an automatic check for unit test coverage. And yes, of course, there are limits to what such an automated coverage tool can do.

With regard for failing unit tests, the “iterable” branch did have anymore failures and errors than the head branch.

Note missing JavaDoc

We’ve go DocCheck results on our CDK nightly pages but nothing tells you whether a patched method is missing neccessary JavaDoc. Presumably, we could “grep” the patches class names into a DocCheck input file and get customized info about it.

Warn for subjected PMD warnings

PMD is a tool for checking code with respect to adherence to certain coding standards.Again, the CDK nightly page contains all PMD reports on the CDK code, generated in nightly runs. The same can be achieved for each branch with a “ant -f pmd.xml”  on your local copy of the branch.

Optionally note other problems

I love optional things and tend to let them be optional

Optionally any other comment you have

Dto.

So, overall I would like to conclude that according to the best of my knowledge, the Iterable patch should be safe and can be applied to the HEAD branch.

In GIT the source code is distributed – there is no concept of a central source repository. Developers commit their chances to their local GIT systems, with all the advantages of versioning and source code history. Other developers pull code from you if they think that the changes you’ve advertised via your favourite communication channels are interesting. In theory, this allows for a very democratic and evolutionary code development. In addition to being distributed, GIT seems to be very fast when it comes to merging. Linus reports that he does hundreds of full merges per day and nothing take longer than 5 secs.

In practice, as Linus points out in his talk, there will always be one or very few repositories that people pull from – for the Linux kernel it will be Linus’s machine. In CDK it will very likely be Egon’s. Sorry Egon, you’ve got to be online all day

The last sentence already brings me to the point. I wonder if we should give GIT a try for CDK development. The advantages do sound enormous. Ok, there are disadvantage too, such as loosing the central web browsing of the SVN repository on SF. There may be ways around this, as Egon decribed here, but this seems like not using the real thing.

This is a brief impression dump after watching Linus’ talk today and I’m happy to hear your opinions

While the details discussed there are not particularly surprising to the educated chemist, the value of the material lies in that it is a quite complete collection of cases to take into consideration. It would be a nice document to base the next JCP-rendering-engine-related summer of code on (Not sure how far Egon and Niels got last time) and there are certainly some things which could very quickly improve the quality of output from CDK SDG, the simplest example being a horizontal alignment of the molecules longest axis.

And if you think, yes, this would be a nice project for me to help those Blue Obelisk projects, please let me know

… Both the comments of interested peers as well as those of the official peer reviewers (who may opt to be anonymous) immediately become publicly available together with the discussion paper. The forum is ISSN-registered and all comments are individually citable. If accepted, the final paper and whole discussion leading to its publication becomes openly and permanently accessible.
Poeschl points out a number of advantages of this collaborative peer review process. a) The discussion papers allow for very rapid publication of results. b) There is a motivation for peer reviewers to provide high quality reviews, since those are openly accessible for the whole scientific community. c) For the reader, the review discussion maybe as enlightening as the article itself. d) The open review process may deter those authors submitting suboptimal manuscript in the hope to take advantage of reviewers work capacity.
Ulrich Poeschl states that the above leads to a lower need for corrections and a lower rejection rate.