chem-bla-ics

CDK 1.5.0: the changes, the authors, and the reviewers

2012-01-16T22:40:00.002+01:00

Yeah, I did it. I made the first new development release (1.5.0) for the CDK after the fork of the stable 1.4.x series. It had to happen after the removal of IMolecule and IMoleculeSet. Well, in fact, while the list just lists all the patches specific for the current master branch, it is still fairly long. Then again, quite a few of my 'commits' are probably just merges.

Just to make clear, this is a development release, and until we freeze this branch, we expect, and actually intentionally add, API changes. Of course, we intent those to improve things, and please shout out your wishes.

First of all, this release removed IMolecule and IMoleculeSet. That was a big effort, explaining why Rajarshi and I have so many commits in this release. This release also adds the LINGO fingerprint type and a atomic signature-based fingerprint. It removes the nonotify module, as the silent module should be used instead. IChemObjectIO now extends Closeable, making it more Java7-friendly. Also noteworthy is the API for raw fingerprints, which are not of fixed length, but have key and counts. On the implementation side, the QueryAtomContainer now uses local, custom implementations of IAtom and IBond, making the module independent from the data module, freeing the rest of the library for more code clean up.

Mind you, this release shows an increased number of failing unit tests on Nightly.

The changes

This commit puts a single comment line for the molecule @param in placeAliphaticHeavyChain() method. 61377fb

Fixed JUnit version 41075f3

Upgraded PMD to 4.3 79e4532

Upgraded JUnit to 4.10 67a1f23

Updated the @TestMethod to match the unit test method renames that recently happened 0ad0fd0

Fixed comparison, to use the proper double assertEquals method 1ecc22b

Renamed the overriding methods to match the method rename of the methods in AbstractChemModelTest they are overriding. This is why one should use @Override. 1d34aac

Switched order of IRing and IAtomContainer matching, to fix construction if IRing classes 4741983

Removed IMolecule 2fc6b61

Replaced more IMolecule by IAtomContainer, fixing more unit test regressions 611aaca

A set of casting fixes to reduce the number of unit test regressions 2599bc2

Proper typing of the DefaultIteratingChemObjectReader, so that other classes can safely extend it (thanx to Nina) de67121

Removed some more usages of Molecule b84587f

Updated casting to remove usage of Molecule 04b1542

Typed the iterator, removing the need for casting when used 6e6cf8e

Two s/IMolecule/IAtomContainer/ patches to fix a few unit test regressions f6ed3d7

More Molecule use removed 0a04d3f

Update some return types to not use Molecule 1d8ee25

Removed field declarations of Molecule 88a2935

Removes instanceof and .class usage of Molecule 436dba5

Another batch of s/IMolecule/IAtomContainer/ 5da1d1b

Made SmilesParser independent from IMolecule 6bf4aa2

Got rid of debug and silent Molecule implementations and respective tests 9f05e5c

Refactored classes extendign Molecule to use AtomContainer 2ccbe95

Removed the last traces of the IMoleculeSet interface a8c03af

Got rid of MoleculeSet from the debug module 50aa11f

Got rid of MoleculeSet from the silent module 2250763

Updated IPolymer to extend IAtomContainer rather than IMolecule 5b7ad0f

cleaned up a bunch of MoleculeSet usages 150fee9

Updated various reaction classes to remove all usage of Molecule* 0a98a7f

Updated IReactionMechanism to use IAtomContainerSet. Also fixed some castings. 738eece

Convert IMolecule* to IAtomContainer* across many more classes c9847d2

Some IMolecule/IAtomContainer fixes, to get things to compile here c950448

Convert IMolecule* to IAtomContainer* across some charges and test classes f74a3ad

Removed the nonotify module (replaced by silent) 51af326

A bit more IMolecule removal d8d6eee

Fixed castings, to solve failing unit tests d273aa4

A quick fix. This class will soon be removed, so no peer review needed. 9e97f2d

Fixed a casting 3c1086a

Removed methods, to get the number of unit test fails down; this two classes will be remove completely, so skipping peer review 1bbfe5a

More modifications to use AtomContainer rather than Molecule f4647d8

Moved TetrahedralChirality from data to core. 46e3ddc

Replace IMolecule* with IAtomContainer* 27c6f7d

Updated io classes to use IAtomContainer* 68f2a65

Converted template handler to use atomcontainerset f0cf950

Refactored the setters from IReaction to use IAtomContainer* 04cbb29

Refactored the last getter from IReaction to use IAtomContainer* 91f8083

Made sure that we use IAtomContainerSet rather than casting back to Molecule* 104ecd1

Modified IReaction and related classes to migrate from IMoleculeSet to IAtomContainerSet 19b7673

Replaced IMolecule* with IAtomContainer* 7f6617d

Replaced IMolecule with IAtomContainer for some IReaction methods 3d3037f

Replaced use of addMolecule() with addAtomContainer() 2c1b31a

Replaced use of getMoleculeCount() with getAtomContainerCount() b27ee12

Replace use of IMoleculeSet by IAtomContainerSet in ConnectivityChecker.partitionIntoMolecules() 42861a9

Replaced IMoleculeSet with IAtomContainerSet, fixing a compile issue 2ac19f1

Patched bpol descriptor with cheminf ID a4db4a2

Make IChemObjectIO extend Closeable as suggested at http://sourceforge.net/tracker/?func=detail&atid=370024&aid=3437936&group_id=20024 a250cb3

Makes the smiles module independent from the data module a7920c1

More use of interfaces rather than implementations for the smiles module c3040e8

Removed non-existing dependency 3eaeaa7

Work with AtomContainers (fixes #2788763) c72d442

Allow IChemModels to contain IAtomContainerSets (addresses #2784940) 4cc5ff8

Replaces junit.framework.Assert from JUnit3 with org.junit.Assert from JUnit4 (fixing #2831081) 6ff1f78

Fix to permutation unit tests 45a7599

Split AtomContainerPermutorTest into one for the Atom and Bond permutors 40fe774

Unit tests for the Permutor class and fix to permutor. 88ceb38

ISBN number for the reference 217977c

Re-write of the atom container permutation classes. An extra class 'Permutor' is now the base class for permutations, and contains some more functionality than before. acd8e9b

Re-write of the atom container permutation classes 04adfca

Removed commented out code 16efbc0

Removed needless explicitly qualified vecmath types c1a69a4

Convenience method for getting an atom container directly from a formula string a1894f2

Handle a CDKException thrown by the Parser by throwing an IllegalArgumentException in the constructor face5c5

Removed hardcoded String use of InvPair constants in favor of their actual constants 4777958

Compile fix: get a builder from the input parameter 98f16f8

Removed dependency of io on data again df6ea2e

Corrected spelling from CanonicalLable to CanonicalLabel c0e59c8

Updated test case to note that SMARTS lexical errors now throw illegal argument exception dc60bc3

Added missing dependency fb4ba45

failing test for Tanimoto on "raw fingerprints" b42fbae

Implemented missing method, copied from Fingerprinter 2731d6f

Updated SMARTS parser JJT file, to drop the use of CDKException when a invalid SMARTS is provided. 1ef89fb

fix bug #3305550 - moved SMARTSQuery to where used dfb3e86

changed from no-op logger call to syserr 4c5beba

spelling ac6a9eb

Updated Copyright dates 51f2db8

Added another missing dependency 416a4cc

Added missing dependency 6fc4803

Split out unit tests only for fixed-length fingerprints 37e81e8

Added a signature-based fingerprinter 688da8b

MDL reader deals with query bond types, plus tests c95541f

QueryAtomContainer to allowe atoms and bonds 6a8f4c0

Another MOL file with query bond types b6bf3b5

CTFile query bond class b0227ba

MOL file with query bond types 3546ba4

Use DefaultChemObjectBuilder directly, not using getBuilder() method d0dc1ef

Added constructor for QueryChemObject to prevent nullpointers on flags property 6a75767

Cleaning up testing of the isomorphism module, e.g. classes in the proper test module bc1e3e6

Minor clean up: use interfaces, depend on Query implementaions, and now compiles without dependency on the data module 6913b9d

Reworked QueryAtomContainer to not depend on the data module either a5439dc

Use interfaces instead of implementations 076a870

More QueryBond 0e14c77

Extend QueryAtom instead of Atom 0ee08a6

Extend the new QueryChemObject b0a97a6

A shared IChemObject implementation for QueryAtom and QueryBond b98f650

Added constructors for QueryAtom 3708c8d

Cleaned up the code a bit 1654e94

Added an abstract QueryAtom class ae347ce

Match the IBond interface, as I get a compile error here otherwise 43cb829

Query bonds b7e8e3a

Placed the LingoFingerprinterTest in the rest module, and added missing dependency 16e456d

Fixed wrong module assignment 81db713

moved lingo fps to smiles module 1eb9590

Replaced the NotImplemented exception with UnsupportedOperation 6071796

Updated Javadocs 15be38b

Updated issues in Javadocs, copyright and method names dee515e

Added similarity method for Lingo's 133f314

Updated Tanimoto similarity to handle feature,count type fingerprints f487c30

Added implementation of LINGO 72bbae3

Added copyright and ref 9707f66

Added implementation of LINGO 572018f

Updated fingerprinter interface to support access to raw fingerprint of the form Map. Updated implementing classes b0f4050

Replaced the broken links with new ones (fixes #3108471) dc504db

The authors

89 Egon Willighagen

37 Rajarshi Guha

9 Mark Rijnbeek

8 Gilleain Torrance

4 Jonathan Alvarsson

1 Daniel Szisz

1 John May

1 Ola Spjuth

1 Christoph Steinbeck

The reviewers

66 Rajarshi Guha
30 Egon Willighagen
4 Gilleain Torrance
1 Jonathan Alvarsson
1 Nina Jeliazkova

Groovy Cheminformatics 4th edition

2012-01-15T11:06:00.002+01:00

Six month was not quite the amount of time I anticipated between the third and fourth edition, but I finally managed to upload edition 1.4.7-0 of my Groovy Cheminformatics book. The first three editions sold 37 copies, including two for myself. Enough to feel supported and to continue working on it.

So, this new edition is again thicker, summing up to 152 pages now, which is 28 pages more than the 3rd edition. Indeed, the table of contents is more than half a page longer in itself, though, just barely, still fitting on four pages. In fact, I had to remove one (new) subsection title, because it would take otherwise two further pages.

The new content is again a mix of sections and chapters. While writing new chapters, I find myself realizing I need to cover more basics. Those get typically added as new sections. I did not get many feature requests, except for one email pointing me the text promised how to interpret and handle failing atom type perception, which explains one of the new sections. The full list of new content is:

Section 2.1.4: explaining the three flavors of atomic coordinates
Extended Section 2.2: added detail about electron counts of bonds (partly in reply to this post by Rich)
Chapter 5 "Protein and DNA": four pages, mostly about PDB files, and the matching CDK data structure
Chapter 6 "IChemObjectBuilders": four pages explaining the four alternative builders CDK 1.4.7 has
Section 7.8: a new section with recipes on how to post-process read input, discussing MDL molfiles only now. It talks about what information is present in the file format, and what steps must be untertaken to add missing information
Section 8.2.4 "No atom type perceived?!"
Section 11.4: describes how to depict aromatic rings
Section 11.5: describes how to change the background color of depictions
Section 13.4: explains how to calculate the Van der Waals volume of molecules
Section 18.1.3: discussing the API improvement in the iterating readers
Appendix C: a list of all descriptors provided by the CDK
Appendix D: a list of file formats known by the CDK, indicating which has readers and writers

On top of that, I improved other bits of the book too, such as the resolution of the depictions of molecules, as well as those of various diagrams. Also the number of scripts has seriously gone up, from 94 to 134!

Appendix C is a prelude to a chapter I am already writing, but did not get finished yet: a chapter about descriptor calculation. But since I just started a new post-doc position, it may take another six months for that chapter to make it into print.

The paperbak is available from Lulu.com, an on-demand publisher, as well as this ebook version.

CDK-JChemPaint #10: background color

2012-01-08T13:56:00.001+01:00

I found in the Groovy JChemPaint repository a script I had not blogged about yet, explaining how to change the default background color. It's fairly simple, and just uses parameters. Starting from the common pattern to set up a renderer, you set the background parameter:

backgroundColor = Color.lightGray;
model = renderer.getRenderer2DModel()
model.set(
BasicSceneGenerator.BackgroundColor.class,
backgroundColor
)
The full script can be found here. The resulting output looks like that given below.

CDK 1.4.7: the changes, the authors, and the reviewers

2011-12-31T12:38:00.001+01:00

In preparation of the next (4th) edition of my Groovy Cheminformatics book on cheminformatics with the CDK, I found a show stopper bug, fixed it, sent in the patch, and Rajarshi quickly reviewed and applied it to the cdk-1.4.x branch. This particularly bug was a null pointer exception that was fixed not so long ago in the log4j implementation, but turned out to be present in the logger to STDOUT too.

This releases also fixes the reading of aliased atoms in MDL V2000 molfiles, thanx to another bug fix patch from John May (thanx!), and formally deprecates the nonotify implementation, which has already been removed from the master branch. The silent module should be used instead, which has the same functionality but has cleaner code and faster.

However, one important change you should take notice of, is an API change in the IIteratingChemObjectReader class. The change is minor, but useful. The interface is now typed, and implementing classes implement IIteratingChemObjectReader<IChemModel> (IteratingPCSubstancesXMLReader) or IIteratingChemObjectReader<IAtomContainer> (IteratingMDLReader, IteratingPCCompoundASNReader, IteratingPCCompoundXMLReader, IteratingSMILESReader). This means, that this iterator's next() method now returns an IChemModel or an IAtomContainer, and that casting in the using code is no longer needed.

The changes

Another hot fix: use @link with the full qualified class name, and removed the import, to fix a dependency issue 0e71cba
Added a @deprecated tag on the nonotify data classes, pointing to the silent implementation d283686
Fixed dependencies 5ef20b1
Extend the abstract suite, so to run the test for the null pointer exception 269c84c
Work with the interface 106e5ec
Check for a null input fb35047
Removed unneeded deps on CMLXOM for JNI-InChI (thanx to Dmitry Katsubo). 8524891
Added missing imports of IAtomContainer, needed by the last two patches, but which were not needed in master because we did all that IMolecule/IAtomContainer refactoring already 856f83c
Proper typing of the DefaultIteratingChemObjectReader, so that other classes can safely extend it (thanx to Nina) 6de90d3
Typed the iterator, removing the need for casting when used 44b7e76
Added John May as author 1142dc6
Also check that there are two such R1 atoms 962b7d2
Added modifications and unit test for alias atom naming patch bd4b094
Corrected alias atom naming in MDLV2000Reader and added test 23132a0

The authors

13 Egon Willighagen
2 John May

The reviewers

6 Rajarshi Guha
2 Egon Willighagen
1 Nina Jeliazkova

CDK 1.4.6: the changes, the authors, and the reviewers

2011-12-31T11:04:00.000+01:00

OK, I forgot to write those up again :(

Release 1.4.6 of about a month ago, fixes a few bugs, including broken JavaDoc, atom type perception when SMILES are parsed while keeping the lower case formalism as aromaticity indicators (I will not discuss the pros and cons of that here), and the Chi index descriptors for sulphurs. This release also introduces a new fingerprint, based on an extensive list of biologically-relevant substructures identified by Klekota and Roth in 2008 (doi:10.1093/bioinformatics/btn479). This functionality was backported by Jonathan from the PaDeL software by Yap Chun Wei. The rest is a bunch of small code and dependency clean ups as well as new unit tests.

The changes

Added missing unit tests 9119aa2
Added get-methods for information needed for extensions 4525cbe
A few missing unit tests in the 'qsar' module 2356a10
Added further methods needed for CDK-JChemPaint 804a6f5
Added missing JavaDoc. e316210
No longer complain about missing testing for abstract classes 284ff84
Typo: there → their 640b6e6
Added unit testing 05216f0
Throw a descriptive exception when 2D coordinates are missing (fixes #3355921) cdc4cbd
Fixed the cheminf.bibx well-formedness (fixes #3435367) 7bc0772
Added missing @cdk.githash. fdd3d22
Updaetd chi index util to correctly evaluate deltav for sulphurs. Fixes bug 3434741. Added unit test 8225175
Use interfaces instead of implementations 434c9b1
Use interfaces instead of implementations 76dcdf7
Use interfaces instead of implementations 5bef796
Use interfaces instead of implementations b6ed6a7
Moved the pi-contact descriptor (atom-pair) to qsarmolecular, removing the depedency of qsar on reaction d902312
Added a missing dependency; it now finds PDBPolymer f03eb3c
Fixed test method names f6562cb
Added a missing test a853c91
Fixed TestClass annotation d37961d
Added tests for the isomorphism module to the proper suite 657c3a7
fixed dependency for fingerprint tests 135edeb
added test for getSubstructure d1eb951
lookup SMARTS at index in Substructurefingerprint 65602db
Wrote test for KlekotaRothFingerprinter 2b1288b
adapted to CDK 84aefixesd70
Import from the source code of PaDEL-descriptor (doi:10.1002/jcc.21707) 291def4
Fix to use interfaces as argument instead of classes 5e828f5
Perceive atom types also when aromaticity from the SMILES is kept 2e76ff6
Added unit test to make sure atom types are also perceived when aromaticity from SMILES is kept b315ee6

The authors

25 Egon Willighagen

5 Jonathan Alvarsson

2 Rajarshi Guha

1 Nina Jeliazkova

1 Yap Chun Wei

The reviewers

13 Rajarshi Guha

8 Egon Willighagen

1 Nina Jeliazkova

A Google+ page for the CDK

2011-12-19T12:41:00.001+01:00

A week or two ago I created a Google+ page for the CDK, which can be found here and it looks like:

I will use this page to post interesting stories around the CDK. It is not supposed to replace the Planet CDK, which aggregates blog posts from CDK developers and users, but for other, perhaps shorter posts. For example, as can be seen in the above screenshot, I have started to use it as a CDK Literature replacement, which originally was a series of articles in CDK News (the archives), and later hosted in my blog (see CDK Literature #5 for links to the other four).

But, I will (re)share anything I find useful for the CDK community.

Open Source cancer research (must see video)

2011-12-16T09:31:00.001+01:00

Four years ago I wrote up a passionate post about the importance of ODOSOS, and about a year ago written about how research can be open sourced, and how the Open Source Chemistry Development Kit (CDK) fits in. I am proud that the CDK is enabling so many researchers to do novel research! Google Scholar reports over 200 documents and Web of Science gets to over 150 for just the first CDK paper (see also GS vs WoS). That's serious impact. We're far from being fully comparable with existing commercial tools, which have a 40 year head start. But with important functionality still missing (e.g. E/Z stereochemistry), and about 150 open bug reports which needs looking into, we surely can need funding and help!

Anyway, this Monday we had the last of this years Stockholm Open Science meetings, and Carl Bärstad joined, whom is organizing TEDx talks here in Stockholm, and he pointed me to this must see video on open source cancer research:

I can highly recommend watching it, as it is both very insightful about cancer (it's the third mechanism I know now how cells remember state, after DNA methylation, microRNAs, and now plain, boring protein; I wonder when metabolite-sized molecules show up as cell-division surviving state preservatives; they will).

But, it also puts Open Science ideas to practice in drug discovery. Yeah, the even give the structure (and SMILES) of JQ1 (see PubChem):

Now, the cancer the started of with, is pancreatic cancer, which is what my mother died of 3 years ago, which provides a third reason for me to love this video!

Update: I have uploaded JQ1 and the charged variant on ChemSpider to Ambit2 as dataset 976496, which means that you can look up toxicity predictions with ToxPredict for JQ1 on this page. This is what ToxPredict looks like, just before I hit Run all:

Google Scholar versus Web of Science

2011-12-14T12:59:00.002+01:00

Web of Science (WoS) is the de facto standard for citation information. It's citation counts are used for many purposes, among which to decide I am a good scientist. Web of Science, however, really expensive, and Joe the Plumber does not have access. No wonder, he doesn't know which scientist to trust (...).

Recently, Google made their Scholar product open to all, allowing you to list your publications (about my list), which Google with augment with citation counts. If you search the web, you'll find much being said about the two, in particular compared with each other. One aspect is the accurateness of the citation counts, as people are afraid gaming, and random noise found on the web. Others would (counter)argue that Google captures a wider range of literature.

So, I was wondering how this would reflect on my impact. I know that WoS is not errorless either, and I have been making various support requests over the years (my WoS records still have errors). So, do they complement overlap? Are citation counts comparable. In fact, this turns out to be true:

I would be drooling if I got this kind of regression in my nanoQSAR studies! :) There is a very strong regression, indeed. One of the advantages of Google Scholar is does not select an elite group of journals (of course, they have to, because there data analysis process involves much more human curation), while Scholar captures newer Open Access journals, like the J. Cheminformatics, too. While I may be a bit of a non-typical scientist (some even argue I am not even doing science...), the overall outcome is that Google Scholar is actually more accurate about my impact than Web of Science is right now.

What data is behind this scatter plot?

2011-12-13T10:50:00.000+01:00

Open Science and Non-Commercial licenses (a personal reflection to the Oscar/RSC controversy)

2011-12-08T07:55:00.001+01:00

Peter has started a new line of discussion in his blog, referring to a correspondence with representatives from RSC last year, about an annotated literature corpus to (re)train the Oscar3/4 text miner. There are very many sides, and after I reread this post for a second time, I was still not 100% happy about all words: I can only try to express the complexity of the matter and how it started, but do hope to be clear that non-commercial licenses are not useful in Open Science.

I have taken part in parts of the correspondence Peter refers to, and I would not have written up things as Peter wrote up his impression of the outcome of that discussion, and at some point I seem to no longer have been included in the email correspondence, as I at least did not know the final outcome (see below), and cannot fully comment on the accuracy of Peter's coverage of that correspondence, but my impression on the outcome, as limited as it was, is not that far away from what Peter wrote up: Oscar4 needs training (doi:10.1186/1758-2946-3-41), and the RSC was unwilling to contribute the full text training corpus to the project without a non-commercial (NC) clause (and I explain below why I think this is bad). Oscar without a training corpus is useless; Oscar with a NC-licences training course is not Open Source (see below). As detailed below, the corpus at sentence level is NC-free licensed, and a lot of training can be done that way. Sufficient?

Peter wrote:

"I pointed out very clearly that CC-NC would mean we couldn’t redistribute the corpus as a training resource (and that this was essential since others would wish to recalibrate OSCAR). Yes, they understood the implications. No they wouldn’t change. They realised the problems it would cause downstream. So we cannot redistribute the corpus with OSCAR3. The science of textmining suffers again."
I do not know if it is factually correct that the RSC would not change (below we read they attempted), or whether the organisation really understood the problems. But, it certainly is a fact that we cannot redistribute Oscar4 as an Open Science project with a NC-licensed clause.

And, I want to add and stress here, that blog posts sometimes are just like press releases: things have the highest impact if written down in a black-and-white fashion; and getting things factually wrong happens to all of us now and then.

One of the outcomes I learned about this week, is that the RSC released the corpus in some form without the NC-clause. The full text paper corpus remained the NC clause of the CC license, but there is also a version where all sentences are released, and this has a CC license without the NC clause. I think this is not optimal, but still very much appreciate the gesture the RSC is making here, and would to kindly thank them for that! And do I want to make that clear too (thanx to Cameron for phrasing it so well in his comment), it is the principle freedom for the RSC to decide what they want to do, and I fully respect that.

Well, with that out of the way, and I wanted to say something about it, having been involved in the discussion, and feeling a bit in between Peter and the RSC here, appreciating both their view points, and having a third one myself, let's focus on this non-commercial clause a bit more.

Of we enlarge our scope a bit, away from written material, to Open Science, it is clear that the non-commercial clause is bad. In the Open Source world, organisations like the Debian project clearly state that non-commercial clauses violate basic freedoms. From an Open Standard point of perspective, this is pretty much the same. The reason, whether you like it or not, we live in a commercial world. Society expects us to me commercial, and any serious business is legally required to make making profit a company goal. Now, this effectively means that any science made available as non-commercial is not Open: you are effectively not giving people the freedom they need to advance science.

In short, a CC license with the NC clause is in fact quite like "yes, we love to be Open, but we are too scared". Now really, I understand this scare. I am a scientist, post-hopping around Europe, not tenured, and not being an experimental scientist, unlikely to become one. Don't tell me about risk and scare of making things Open. Yet, I did, and it payed of (not enough yet; still looking for a fixed academic position, as I already indicated). But in the more than 15 years I have been working now in Open Science, I have yet to find a compelling (or any) argument to back up this fear: the perceived risk of the NC clause has so far not proved any different than a fear of ghosts.

On the other hand, if I would not have been involved in Open Science, I would not have worked for the top European institutes I have been working in the past ten years.

So, what are the arguments for using the NC clause? The fear I understand, but arguments I do not see that support that a NC clause is useful in an Open Science setting.

Further reading:

CDK-JChemPaint #9: implicit hydrogens and isotopes

2011-12-03T10:38:00.001+01:00

Next in this series (after #1, #2, #3, #4, #5, #6, #7, #8), I'll show how to add implicit hydrogens to a drawing. I actually think the BasicAtomGenerator should cover implicit hydrogens, and the ExtendedAtomGenerator anything that requires more CDK modules than just the interfaces, like isotopes. But I discovered that implicit hydrogens currently also requires the ExtendedAtomContainer too late. In fact, there are other things I like to see changed, but I do not have the resources for that right now. So, you will need the CDK-JChemPaint jar (which is not the JChemPaint code!).

In fact, besides these points, it basically just comes down to replacing the BasicAtomGenerator with the ExtendedAtomGenerator. Except a bug I found. I'll fix that in the next release, but right now, the extended atom generator requires the AtomNumberGenerator to be loaded as well, and thus we also must turn atom numbering off. Therefore, we basically get this code snippet (here's the full code):

// generators make the image elements
List<IGenerator> generators = new ArrayList<IGenerator>();
generators.add(new BasicSceneGenerator());
generators.add(new BasicBondGenerator());
generators.add(new AtomNumberGenerator());
generators.add(new ExtendedAtomGenerator());

// the renderer needs to have a toolkit-specific font manager
AtomContainerRenderer renderer =
new AtomContainerRenderer(generators, new AWTFontManager());

// disable atom number rendering
model = renderer.getRenderer2DModel()
model.set(WillDrawAtomNumbers.class, Boolean.FALSE)

As said, this code will be simpler in the next CDK-JChemPaint release. The results looks like:

As you can see by the amount of whitespace around the carbon, the scaling issue has not been resolved yet :(

Drawing isotope information works pretty much in the same way. In fact, we do not even have to change the rendering code, and the ExtendedAtomContainer automatically adds the isotope information (and no, indeed, not in the expected superscript fashion; so, another thing to fix):

But alas, there are always things to fix. I'm personally not aesthetically pleased with the kerning of just CH₄ either.

CDK-JChemPaint #8: rendering of aromatic rings

2011-12-01T10:50:00.001+01:00

CDK can render aromatic rings in two ways: with localized double bonds and with a circle reflecting the delocalized nature of the π electrons. Or, graphically:

The following two code snippets are part of full scripts available from my Groovy-JChemPaint repository, and these two drawings are created with CDK 1.4.6.

To draw aromatic rings with localized double bonds, use this code:

List<IGenerator> generators = new ArrayList<IGenerator>();
generators.add(new BasicSceneGenerator());
generators.add(new BasicBondGenerator());
generators.add(new BasicAtomGenerator());

However, if you like the right aromatic ring style more, you replace the BasicBondGenerator by the RingGenerator, and use this set of IGenerators:

List<IGenerator> generators = new ArrayList<IGenerator>();
generators.add(new BasicSceneGenerator());
generators.add(new RingGenerator());
generators.add(new BasicAtomGenerator());

That's it. Here's the full script.

Keeping it cool... tracking CPU temperatures on Debian GNU/Linux with a 3.1 kernel

2011-11-23T15:17:00.001+01:00

My laptop is getting old (almost 12 months now), and is starting to see the first symptoms of age. Probably just dust piling up, but I have been experiencing CPU overheating. A week or too I found a nice one-liner to keep an eye on the CPU temperature, but a kernel upgrade to 3.1 broke that. Here is a script that works on my Linux laptop:

( cd /sys/class/thermal && while :; do line="`date`:`cat */temp | cut -c1-2 | awk '{ printf(\" %03d\", $1) }'`"; echo "$line"; sleep 5; done ) | tee LOG

The simplest way to make CDK commits

2011-11-09T10:24:00.000+01:00

Every now and then I people who show interested on working on the CDK. I reply to them what is involved, and I rarely here back from them. I know this is common for most open source projects (see also Community development), and for the CDK this is likely caused the cumbersome process of getting a full development environment set up. Over the next months, I will make an effort to extend my Groovy Cheminformatics book to include detail after detail on how to do this. But what would also be welcome is a VM (OVF) image that has everything set up and well.

Anyway, but the road to CDK commit fame does nowadays not require a full-fledged development environment. Instead, we have GitHub. Their web interfaces makes a lot of things easy, including source code peer review.

But in this post I would like to show how easy it is to fix small things in the CDK, by using the GitHub GUI. Of course, this post can be used for any project hosted on GitHub.

Step 1
Get a free GitHub account. (And log in.)

Step 2
Find a problem in the CDK. Start with something dead easy, like JavaDoc errors. For example, check the Nightly report for OpenJavaDocCheck errors here. These pages will return a lot of errors about missing documentation, but skip those. Do something really simple, like reports like this one:

There is no period to end the first sentence: 'Sums up the columns in a 2D int matrix'

JavaDoc has a special purpose with the first sentence in any JavaDoc: it serves as a summary. The detect the first sentence, it must properly end with a period.

That patch cannot get any easier. It just requires a missing period to be added.

Step 3

Identify the source file that contains the error. This has the added value in that you automatically learn your way around in the directory/folder hierarchy of the CDK project source. The above error refers to this class:

org.openscience.cdk.graph.PathTools

Now, all functional CDK code (that is, everything but the unit test suite) can be found in the source distribution under src/main, but we need the GitHub URL for that, and that is here (note that the linked OpenJavaDocCheck report is for the stable cdk-1.4.x branch, so our GitHub page for the PathTools source too):

https://github.com/cdk/cdk/blob/cdk-1.4.x/src/main/org/openscience/cdk/graph/PathTools.java

Check this URL carefully, and note where it keeps the branch name, the src/main folder, and the path to the PathTools.java source. That makes finding other source code pages later easier. This particular page looks like:

Step 4

Now, this source code page has (when logged in) a 'Edit this file' icon right of the file name line. Click this icon, and GitHub will present you with a basic, in-browser editor:

I already scrolled down a bit, to the line with the missing period from this example. Make the modification, and scroll down to the lower part of the page, and read step 5.

Step 5

With the small fix done, it is time to make the actual commit. Below the editor there is a text field to enter a commit message (important: describe what you did, even if this takes more time than the fix itself! Reason: when browsing commits in changelogs, you only see those messages!):

If you have multiple JavaDoc fixes, put them in one commit. But, preferably do not mix them with other fixes, as to keep the commit message as well as the peer-review simple. That speeds up the reviewing process, and makes it easier for me and Rajarshi to apply to the main source tree, but more about that in the next steps.

Of course, this online editing can also be used for fixing PMD warnings, as reported by this Nightly report. However, keep in mind that you cannot recompile the code this way, and for code changes, this online approach is discouraged.

When done, press 'Propose File Change' (Rajarshi and I see a 'Commit Changes' button instead). After a new page is opened, the commit has been created, and it is time to inform us of your commit. This is done via a so-called 'pull request', as outlined in the next step.

Step 6

The last step in the process is to send out a pull request. A page to do this is normally the immediate result from hitting that 'Propose File Change' button, and should look something like the following (note that I could not make a screenshot based on the running CDK example, because I have commit rights, and the patch goes directly into the repository; I discovered that in this patch :):

So, while for another GitHub project (Total-Impact is worth checking out), this page should look similar. The top grey bar show the project name and the 'Send a pull request', confirming that this page does what we are expecting. In the blue box a comment is given on where your commit is stored, which is in your own fork of the CDK for your own GitHub account, in a branch called patch-x.

Below that blue box, reference is made to your newly-made commit, and a bit further below two text fields, a single line text box for a message 'subject' prefilled with the commit message, and a text box where you can leave a message to accompany the pull request. This message is used to put the pull request in perspective, and can be used to introduce yourself briefly, refer to a set of patches, or whatever. This message will not end up in the git repository. The more requests you make, the smaller this message will get. "Yeah, another JavaDoc fix."

Hit the green 'Send pull request' button, and you're done.

Online SEURAT workshop: Omics data analysis for Toxicology

2011-11-05T13:24:00.003+01:00

Another online meeting announcement (previously on Open Data and LarKC). BTW, DAWG is short for Data Analysis Working Group:

Omics data analysis for Toxicology

Tuesday November 15th 2011, 15:00 CEST, 6:00 PDT

(organized by ToxBank & SEURAT-1 DAWG)

Storing in the ToxBank data warehouse and sharing it among SEURAT-1 is not the only goal of a omics data integration effort. Combing omics data sets available from the data warehouse will provide knowledge not visible from a single data set. The ToxBank platform aims at making these kinds of omics analysis possible.

We invited Prof. Roland Grafström to present the omics data analysis work in cancer genomics for a seminar to speak on their recent work in the field. Prof. Grafström is partner in the ToxBank project and is associated with the Karolinska Institutet medical university in Sweden, and the governmental research institute VTT in Finland.

The presentation will highlight the interpretation of gene expression data from the application of a combination of bioinformatics tools, including the Ingenuity Pathway Analysis software and the Gene Ontology. Basic concepts and terminologies will be dealt with including for integration of omics data, in vitro to in vivo extrapolations, as well as retrieval and validation of biomarker genes in large data sets. Work aimed at tumor biomarker discovery in head and neck cancer will be presented, but the results will discussed in the context of the work planned in the SEURAT cluster.

The meeting will be held online and will be organized via GoToMeeting. There are only 25 seats, so registration is important, as we will fill seats on a first-come basis. However, one ‘seat’ can host multiple scientists behind a single computer, if needed.

Registration

Please send an email to Egon Willighagen (egon.willighagen@ki.se) listing your name, SEURAT-1 project, and email address. Details on how to log in will be send to that address shortly before the meeting.

Going to Maastricht to work on Open PHACTS

2011-11-02T21:42:00.000+01:00

Some two months ago we decided to go back to the Netherlands, after having lived for more than three years here in Sweden. We have had a great time in our three houses, but feel a need to settle down, closer to family.

A week later I was contacted by Chris Evelo contacted me for a position to work on Open PHACTS. Chris and I only met for the first time in March, when I visited the group when I had a conference in Maastricht. His bioinformatics group is very much into Open Science and with a good track record in metabolism and transcriptomics analyses (something we do here at KI too), and Open PHACTS is an interesting EU project into the application of semantic web technologies to the life sciences, something I have worked a lot on in the past two years.

In the next two months here at KI, I'll be working hard on finishing my work for the other great EU project, ToxBank, on which I am working now. I personally see clearly how these projects complement each other, but no clue if such can be given shape at a EU level, where there is intention and consortium agreements :)

And, of course, I got a bit of funding rewarded here at KI, that I will use next year for two or three visits back to Stockholm, because there is some low-hanging fruit that remains to be picked.

All in all, I am very much looking forward to my next post-doc position and definitely my last. What's after that, I won't have to care about in at least the next two years :)

CDK 1.4.5: the changes, the authors, and the reviewers

2011-11-01T09:44:00.000+01:00

CDK 1.4.5 just got uploaded to SourceForge, about a month after the 1.4.4, though mere minutes after the 1.4.4 release notes. CDK 1.4.5 is the fifth bug fix release of the 1.4 series and brings another few bug fixes.

The changes include fixes to the JavaDoc generation, now outputting proper citations of PhD thesis and books, a fix in the SDFWriter to inherit the IO options from the underlying (used) MDLV2000Writer, restored atom type perception in SMILES parsing if aromaticity is not actively perceived (in line with earlier 1.4.x behavior that unfortunately got broken due to another fix), a fix in the MDLV2000Reader to deal with pseudo atoms with numbers greater than 9 (thanx to John May!), a fix in the sorting of IAtomContainers, and a fix for the elusive bug in the AWTRenderer causing thin bonds (e.g. due to zooming) to become grey.

The changes

Use a minimal stroke width in the AWT output (fixes #3295256) 1387b7b
Changed how data files are copied: copy those specified in the src/META-INF/*.datafiles (fixes #3430342) 68536e1
Perceive atom types also when aromaticity from the SMILES is kept 2413197
Added unit test to make sure atom types are also perceived when aromaticity from SMILES is kept d6b8c8e
Removed broken link and fixed syntax of @cdk.cites. 22c59fc
The SDFWriter now accepts all MDLV2000Writer's IOSettings too (fixes #3392485) aa6ca5f
Unit test for bug #3392485: SDFWriter not accepting MDLV2000Writer IO settings ab54ed5
Fixed @TestClass annotation to point to the correct class a7cbe48
Updated unit test to be independent of atom index and just match the coordinates 8d3eed0
Fixed bugged when reading MDL V2000 files. If the atom number of a pseudo atom was greater then 9 it would not be read correctly fd90ed5
Depend on standard to, to have access to AtomContainerComparator 76db769
Create IMolecule's instead of IAtomContainer's because IMoleculeSet can only contain the former; fixed the exception currently thrown by e.g. MoleculeSetTest 1aae7fa
Fixed sorting with null IAtomContainers (based on a suggestion by Mark in the bug report #3093241) 1bf194b
Missing unit test for AtomContainerSet.sort(Comparator) 0585bcd
Added a unit test to check that molecular descriptors do not throw Exceptions when disconnected structures are passed 853ca50
Added support for book and phdthesis reference types 277dd03

The authors

17  Egon Willighagen
 1  John May

The reviewers

10  Rajarshi Guha

CDK 1.4.4: the changes, the authors, and the reviewers

2011-11-01T08:56:00.000+01:00

CDK 1.4.5 just got uploaded to SourceForge, and when I looked up the link to the notes for 1.4.4 I noted I had not released those notes yet. So, here are those first.

CDK 1.4.4 is the fourth bug fix release of the 1.4 series and brings another few bug fixes. The changes include new cobalt atom types, a fix to ensure that all molecular descriptors are properly recognized by the build system, and a fix for the Log4J-based LoggingTool, to properly handle nulls. So, not so many changes, which probably explains why I forgot to blog about it earlier.

The changes

Co final abf6b33
Fixed adding all descriptors to the qsar-descriptors.set file by using the correct number of chars to skip (@cdk.set length is 8 not 11). a75eece
Provide debug info on the classpath in which will be searched 88070ac
Check for a null input 5cd07d0
Unit test for a NullPointerException in the LoggingTool caused by a null message in an Exception. The error only shows up when debugging is turned on. 1e07adc
Split up to test the LoggingTool also with debugging turned on; so far, only with debugging turned of was tested 58bb243

The authors

 7  Egon Willighagen
 1  Gilleain Torrance

The reviewers

3  Rajarshi Guha 
1  Egon Willighagen

Oscar4 paper: text mining in Bioclipse (and everywhere else, of course)

2011-11-01T05:45:00.003+01:00

The Oscar4 paper (CC-BY, just like the screenshots of the paper below) was out already some days now, but the formatting has finished:

I spotted a rogue 'http://' in the code example b) in Appendix B:

I'll see what I can do about that, but the API might evolve a bit anyway.

That leaves me to mention that Bioclipse has an Oscar extension (Bioclipse has a lot of functionality nowadays, in fact), and that I blogged several times on Oscar4 when I was working with the other authors on the refactoring last year.

"Post-doc with experience in CDK programming wanted"

2011-10-25T09:36:00.003+01:00

SMARTCyp (see papers below) is an integrated computational approach that mixes cheminformatics with molecular modeling approaches to predict the metabolic fate of molecules. This fate is important to various biological aspects of small molecules, and the metabolism can active a prodrug into a drug, make a toxic compound non-toxic, and a non-toxic compound risky.

The tool has been well received by the community, complementing other approaches. Now, the reason why I blog about these papers now, is that the tool uses the CDK for the cheminformatics parts, which I find really cool. In fact, the project has resulted in good feedback on the CDK. In fact, the project received further funding creating a short-term open position to continue research on enzymatic reactivity of molecules in the cytochrome P450 family, as outlined below.

So, this peer-review is a bit more on the impact of the CDK and SMARTCyp on the academic landscape, than on the content.of the paper.

Patrik Rydberg wrote on the CDK LinkedIn group and the CDK user mailing list about an open post-doc position where CDK expertise is welcomed:

I'm seeking candidates for a post-doc position in applied cheminformatics at the University of Copenhagen. We are working on drug metabolism prediction models, and our results are as far as possible made into open source software based on the CDK. The group has previously developed the SMARTCyp site-of-metabolism prediction software which is based on CDK, and this project aims to extend the scope of our cytochrome P450 project.

Employer: department of medicinal chemistry, faculty of pharmaceutical sciences, University of Copenhagen
Location: Copenhagen, Denmark
Position: post-doc
Duration: 7 months, starting january 2012
Project: drug metabolism by cytochromes P450

Experiences required:
Machine learning methods
Cheminformatics
java programming

Bonus for experience in java programming using the Chemistry Development Kit (CDK), experience in development of ligand based virtual screening methods, and experience of work on the cytochrome P450 enzyme family.

The SMARTCyp paper can be found linked to below, with the details of how the CDK and SMARTCyp interoperate and make P450 predictions.

Rydberg, P., Gloriam, D., & Olsen, L. (2010). The SMARTCyp cytochrome P450 metabolism prediction server Bioinformatics, 26 (23), 2988-2989 DOI: 10.1093/bioinformatics/btq584

Rydberg, P., Gloriam, D., Zaretzki, J., Breneman, C., & Olsen, L. (2010). SMARTCyp: A 2D Method for Prediction of Cytochrome P450-Mediated Drug Metabolism ACS Medicinal Chemistry Letters, 1 (3), 96-100 DOI: 10.1021/ml100016x

ChEMBL-RDF: Uploading data to Kasabi with pytassium

2011-10-22T13:09:00.000+01:00

I reported earlier how to I uploaded the ChemPedia (RIP) data onto Kasabi. But for ChEMBL-RDF I have used the pytassium tool, not just because it has a cool name :) I discovered yesterday, however, that I did not write down in this lab notebook, what steps I needed to take to reproduce it. And I just wanted to uploaded new triples to the ChEMBL-RDF data set on Kasabi.

The new triples I wanted to upload, link the new public CHEMBL identifiers (like CHEMBL25 for aspirin) to the internal ChEMBL database identifier I used for ChEMBL 09 for the URIs. So, I am adding a lot of triples like:

<http://data.kasabi.com/dataset/chembl-rdf/09/molecule/m517180> <http://www.w3.org/2002/07/owl#sameAs>
<http://data.kasabi.com/dataset/chembl-rdf/09/chemblid/CHEMBL1>

And the pytassium code I use to upload this to Kasabi looks like:

import pytassium
import time

dataset = pytassium.Dataset('chembl-rdf','XXX')

# Store the contents of a turtle file
dataset.store_file('chemblids.nt', media_type='text/plain')

So, that omission in my log book has been corrected now.

CDK & File Formats #1: MDL molfiles and bond order 4

2011-10-20T14:31:00.001+01:00

I just had a conference call on one of the translational cheminformatics projects I am involved in: Bioclipse-OpenTox. A paper about this project has been submitted, and we are writing up a more practice oriented book chapter (almost done). In writing up a use case, we ran into a recurrent problem: proper cheminformatics handling of input files. Ola suggested to start writing more extensive documentation on what users of the CDK are supposed to do when reading a file. So, here I start a new series.

Introduction
But before I start writing up how to work with MDL molfiles in the CDK, I like to stress three key design principles in the CDK:

there is no single solution to everything (aka there are multiple solutions to the same problem)
algorithms must be modular (the LEGO building block approach)
the user is responsible for using the right blocks at the right time

These principles have a profound effect on the usability of the CDK. And here I must stress the point I made recently on usability: what happens if you neglect less abundant personas. Well, in this case, the abundancy is actually somewhat different. But, CDK libraries target a few personas: one of these is the scientist that uses cheminformatics as a mere tool, who doesn't know graph theory, let alone file formats; this personas works in the field of translational cheminformatics. Let's call him Tony. The other personas has a more extensive education in cheminformatics (e.g. former Gasteiger lab, Sheffield, former CAOS/CAMM (like me), etc) or are actively involved in cheminformatics research (like that of Christoph, and many, many more). This personas we will call Carry.

The CDK, with its limited resources, must target both Tony as well as Carry; both have widely different needs, and somewhere, in our free hours, we must work on solutions for both personas. Carry and Tony are, of course, exaggerations, and all readers (and me too) are linear combinations of these personas. In fact, you can even be a Carry in some parts of the CDK, while being a Tony in others. The CDK has so much functionality nowadays, that even I have unexplored corners.

And, practically, the building block approach is important to Carry (she might want to plug in her own aromaticity model), but a killer for Tony.

Missing information

A prominent, recurrent problem for the first personas, is to deal with missing information. And input files have missing information. Some formats are more explicit than others. This series will focus on these aspects, and discuss how the CDK can be used to add that missing information.

Another important aspect is that the CDK data model cannot hold all information. For example, I have no clue how the CDK should read MDL files with a muonium (browse the cdk-devel mailing list archives of this month). Here too, this is not always clear to Tony, who does not have the time to read file format specifications, nor CDK interfaces. He just wants the CDK to do its thing which it is supposed to be good at.

MDL formats
So, here we are. We have a MDL .mol file. They are pretty much the community standard, and even pretty Open too. You can now find the specs in the ctfile.pdf, readily available on the web. Actually, they are no longer called MDL formats, but Symyx formats, umm, Accelrys formats. These formats define a number of file formats, including the aforementioned Accelrys molfile, the Symyx SD file, but also query formats, used to store queries against their database software.

Like any file format, they support a number of features. For example, MDL files cannot represent a bond order 4, a quadruple bond. Organic chemistry doesn't need them. Moreover, hydrogens are often implicit, as they can easily be added later, and both memory and disk space is expensive (think 80-ies). Stereochemistry is wedge-bond-based and others.

Well, more recent MDL formats have become more powerful. The V3000 format can do much more then the V2000 format, or even the pre-V2000 format.

Now, the trigger for the start of this series is the bond order 4 in MDL files. Strictly speaking this is not part of the molfile format, nor of the SD file format; instead, it's part of the query format. However, the community ignored that part of the specification, and the molfiles and SD files are commonly using this query type to represent aromatic bonds. Well, or bonds that can be both single or double.

Now, the CDK does not have a structure to represent a single OR a double bond order. The CDK only has SINGLE, DOUBLE, TRIPLE, and QUADRUPLE (see IBond.Order). Moreover, it has a separate mechanism to indicate if a bond is aromatic. A flag is used for that. This allows the CDK to store both kekule-ized bond order localization and aromaticity perception information separately.

So, if a MDL molfile (or SD file) is read with the CDK in RELAXED mode with the MDLV2000Reader, order 4 bonds are read as SINGLE bonds with a flag indicating it is aromatic. If only the CDK had IBond.Order.UNKNOWN. This is scheduled for master. Mind you, this is a complicated patch, because a lot of algorithm introspect the bond order information, which will have to be updated to handle UNKNOWN bond orders.

This is a nasty co-incidence (interaction effect) killing Tony's use case: the MDL molfiles in the wild have information that the CDK cannot represent, sadly. Now, if users would have been paying for CDK releases, we could have assigned a developer on it. We have the mechanisms in place to buy a copy of the CDK, so that's not really an excuse (price negotiable; maybe 4999 SEK, but you are welcome to buy a campus-wide CDK version for more). If enough people / companies would do this, we could hire a developer to implement this particular use case. This would be a great way to support the project!

Anyway, the purpose of this series is not to rant about these things, but to describe how file formats might be read with the CDK. Here's a recipe with inline comments (in the Groovy syntax):

reader = new MDLV2000Reader(
new File("data/azulene4.mol").newReader(),
Mode.RELAXED
);
azulene = reader.read(new Molecule());

// perceive atom types
AtomContainerManipulator
.percieveAtomTypesAndConfigureAtoms(
azulene
)

// add missing hydrogens
adder = CDKHydrogenAdder.getInstance(
DefaultChemObjectBuilder.getInstance()
);
adder.addImplicitHydrogens(azulene);
AtomContainerManipulator
.convertImplicitToExplicitHydrogens(
azulene
);

// if bond order 4 was present,
// deduce bond orders
dbst = new DeduceBondSystemTool();
azulene = dbst.fixAromaticBondOrders(azulene);

Carry would know this. In fact, Carry would probably have some comments on this recipe. Well, Carry can leave those in the comments of this post.

The Blue Obelisk Shoulders for Translational Cheminformatics

2011-10-18T09:42:00.000+01:00

I guess reader of my blog already heard about it via other channels (e.g. via Noel's blog post), but our second Blue Obelisk paper is out. In the past five-ish years since Peter instantiated this initiative, it has created a solid set of shoulder on which to developed Open Source-based cheminformatics solutions. I created the following diagram for the paper, showing how various Blue Obelisk projects interoperate (image is CC-BY, from the paper):

It shows a number of Open Standards (diamonds), one Open Data set (rectangles), and Open Source projects (ovals). What does diagram is not showing, is the huge amount of further Open Source cheminformatics projects around, that use one or more of the components listed here, but which do not link themselves to the Blue Obelisk directly. And there are many indeed, both proprietary and Open.

I am proud of this diagram: it really shows that the interoperability we set out in the first paper worked out very well! This makes the Blue Obelisk an excellent set of shoulders to do translational cheminformatics.

Translational cheminformatics?? Well, I have been looking for a while for a good term for my research regarding all that hacking on the CDK, Bioclipse, etc. Now, that's the translation of my core molecular chemometrics research to other scientific fields, like metabolomics, toxicology, etc.

Guha, R., Howard, M., Hutchison, G., Murray-Rust, P., Rzepa, H., Steinbeck, C., Wegner, J., & Willighagen, E. (2006). The Blue Obelisk - Interoperability in Chemical Informatics Journal of Chemical Information and Modeling, 46 (3), 991-998 DOI: 10.1021/ci050400b

O'Boyle NM, Guha R, Willighagen EL, Adams SE, Alvarsson J, Bradley JC, Filippov IV, Hanson RM, Hanwell MD, Hutchison GR, James CA, Jeliazkova N, Lang AS, Langner KM, Lonie DC, Lowe DM, Pansanel J, Pavlov D, Spjuth O, Steinbeck C, Tenderholt AL, Theisen KJ, & Murray-Rust P (2011). Open Data, Open Source and Open Standards in chemistry: The Blue Obelisk five years on. Journal of cheminformatics, 3 (1), 37 PMID: 21999342 DOI: 10.1186/1758-2946-3-37

Tricks I learned today #2: importing ontologies into a Semantic MediaWiki

2011-10-12T18:55:00.002+01:00

I learned a second trick today (see also this first); this one is about the Semantic MediaWiki (SMW). I was using a trick I learned from RDFIO before, setting Equivalent and Original URIs (though the difference between those, I lost). But I ran into the problem that these equivalent URIs cannot contain hashes (#), or not always it seems.

After some googling, I did not find an answer, and turned to the SMW IRC channel. Saruman was helping out and pointed me to the Equivalant URI wiki page. I had looked at that earlier, but now turned to the Import vocabulary page. While this was not what Saruman wanted me to look at, it did turn out a nice workaround. The wiki page shows how to import external ontologies. This trick requires you to craft a wiki page with a special name, starting with MediaWiki:Smw_import_ followed by a namespace. It exemplifies this with the FOAF ontology, which is in fact an ontology I was also using equivalent URIs for.

So, I created a new MediaWiki:Smw_import_foaf page, with this content:

  http://xmlns.com/foaf/0.1/|
  [http://www.foaf-project.org/ Friend Of A Friend]
    name|Type:String
    homepage|Type:URL
    depiction|Type:URL
    phone|Type:String
    knows|Type:Page
    member|Type:Page

And another page, MediaWiki:Smw_import_rdfs, with this:

  http://www.w3.org/2000/01/rdf-schema#|
  [http://www.w3.org/TR/rdf-schema/ RDF Schema]
    seeAlso|Type:URL

Then, in a Property page, which I want to make equivalent with a property in FOAF or RDF Schema, I can now simply use [[imported from::foaf:homepage]] or [[imported from::rdfs:seeAlso]], in Property:Has_homepage and Property:See_also respectively.

That's a neat trick, /me thinks!

Tricks I learned today #1: as.integer() on factor levels

2011-10-12T16:28:00.000+01:00

I normally work with full numerical data, not categorical data. R, when using read.csv() seems to recognize such categories and marks the column as to have factor levels. This is useful indeed. However, I wanted to make a PCA biplot on this data, so was looking for ways to convert this to class numbers. After some googling we, Anna and me, ran into as.integer() which can be used on the factor levels. So, today I learned this trick:

> a = as.factor(c("A", "B", "A", "C"))

> b = as.integer(factor(a))

Well, probably basic to many, it was new to me :)

Now, wondering if it is equally easy to convert it into a multi-column matrix where each column indicates class membership (thus, resulting in three columns for the above...). That's another trick I need to learn...