It turned out that planets do still exist, so I started a small corner on Wikidata: Q121134938, and a number of existing blog planets:

The software used to run these planets is ancient, though. We need a new generation of software, replacing things like Planet. And I want something people can easily host on GitHub or GitLab Pages or the likes.

I created a minimal shape expression but the Wikidata items for the planets still lack a lot of information that can be added. First, we can think of them as venues, perhaps, where people “publish” their work. Second, we can annotate the blog planets with ‘main subject’ for the topics the cover. Or we can list the people that are “author” on the planet; most planets are very transparent about which blogs they aggregate.

Love to see where this is going. Who knows? Maybe we will see Postgenomic (see doi:10.1186/1471-2105-8-487) and Chemical blogspace resurface :)

On the bright side, I also noted an updated webpage for SF uptime/problem tracker, where it is also reported that stats are currently down for upgrade. There also has an RSS feed, which I recommend as a good monitoring tool for SF site problems.

I heard a talk by the RSC at the ACS, saying that their RSS feeds contain InChIs now! Just thought I’d throw that out there :-)

The RSC Project Prospect is ahead of other publishers, for over a year already . Adding InChIs to RSS feeds are a cheap way of adding machine-readable chemistry to ones publishing pipeline; adding CML would allow much more detail (see this overview of CMLRSS information in my blog).

But, importantly, it allows third-parties to efficiently set up DOI-InChI tables. Cheap (Asian?) workers become rather expensive, when compared to machine mining to create such databases. Sure, the authoring becomes somewhat more expensive, but who will argue that scientists might be a bit more precise in what they publish. I, for sure, would love to see authors focus on adding InChIs to experimental sections, then that they focus on getting EndNote to put the comma, bold and upper casing in the right place, to meet journal standards.

Another publisher who takes its job seriously is Beilstein. Stephan recently showed me some of the things they are up too, like information rich figures (yes, you’ll have access to the source, and identify the molecular structures in reaction schema). He also showed me to the RDF now by default available for all their articles. For example, for DOI:10.1186/1860-5397-3-50, the RDF is available here. It’s indicated in the HTML with:

<link rel='alternate' type='text/rdf' title='RDF' href='http://www.beilstein-journals.org/bjoc/content/rdf/1860-5397-3-50.rdf'/>

There is, actually, also a lot of citation information available in the <meta> tags in the HTML, but apparently not the right stuff yet to have Zotero pick it up nicely (not sure what this Firefox plugin is actually looking for). No chemistry in the RDF it seems, but there is BIBO , FOAF and Dublin Core.

Main suggestion to Stephan, right now, would be to include InChIs in the RDF and RSS feed.

Disclaimer: Colin, behind Project Prospect, visit our group when I was still in Cologne; Stephan contributed code bits to the CDK project, e.g. this this Matrix class.

Oh, Nature is, of course, also a publisher who actively gets into electronic publishing age.

Nick’s RSS feed does not put the chemistry inline, but does link to the raw CML file:

<entry>
  <title>No title supplied</title>
  <link rel="enclosure" href="http://wwmm.ch.cam.ac.uk/crystaleye/summary//acs/inocaj/2008/3/data/ic702497x/ic702497xsup1_THP4-SINC-publ/ic702497xsup1_THP4-SINC-publ.complete.cml.xml" hreflang="en" />
  <!-- much more, that I skipped for brevity -->
</entry>

The example shown by Peter was nicely chosen: something is wrong with that example. It uncovers a bug in the pipeline, that could have been uncovered by a simple agent monitoring the RSS feed. That is why this technology is important! It allows pipelining of information between services.

Anyway, before you read on, check the structure in the example yourself (Bis(pyrimidine-2-carboxylato-K2N,O)copper(II)).

Done? Checked it? You saw the problem, right? Good.

I have scanned the CIF source, but that does not seem to contain the problem. It nicely shows a general limitation of commonly used chemoinformatics tools: the lack of proper atom typing (a problem I have been looking into for the Chemistry Development Kit; see Atom Typing in the CDK and Evidence of Aromaticity .).

You will have noted that the 2D diagram in Peter’s blog is charged. I checked the complete CML source code for the CrystelEye entry, and that contains the charges on the two oxygens bound to the cupper too. However, the copper is not charged. That leads to a rather unlike situation; that is, that crystal structures will about attract the whole laboratory to itself in a blink of an eye: there is nothing to balance the double-negative charge! It is conveniently summarized in this bit of the CML:

<formula formalCharge="-2" concise="C 10 H 6 Cu 1 N 4 O 4 -2">
  <atomArray elementType="C H Cu N O" count="10.0 6.0 1.0 4.0 4.0"/>
</formula>

Now, I also checked the raw CML; that seems to be unaffected too. So, the bug must be somewhere in the software that converts the raw CML into complete CML. And, before the InChI calculation, because that one is wrong too. A agent scanning the RSS feed, would have detected this. Someone interested in writing up a grant proposal on this?

BTW, the system is not awfully wrong: the negative charge on the acidic carboxyl groups is to be expected. But if the bond between the oxygen and the carbon would have been coordinating, not covalent, and the copper would have been +2, then it was fine. Because many chemoinformatics tools do not have really support for dative bonds, a covalent bond could be drawn, but then the oxygens should be uncharged… right, not? :)

Oh, and surely, one can do much, much more with those feeds. I blogged about that earlier in Automatic Classification of thousands of Crystal Structures .

The feed for Chemical Biology shows 79 feed items and the first one was a Environ. Sci. Technol. paper. The first of the 108 papers listed in the feed for Molecular Pharmaceutics is a perp from J.Phys.Chem.C.

Akregator is the RSS client that I use, and I noticed the exact same problem ES noted: every now and then, twice, three times a month, the RSS feeds for one journal give the content of another journal. For example, I get the TOC of Chemical Reviews in the RSS feed of the JCIM. Things like that.

Now, because Akregator has absolute nothing to do with Google, it cannot be Google who is messing up the RSS feeds. Because ES is having the same issues I have, it cannot be Akregator either. Ergo, it is the RSS feed system of the ACS itself that is messed up.

That urged me to finally clean up my InChI extension for the Postgenomic.com software. One important step was to create a PHP page with only one InChI, such as this one. That would solve the something broken links in the CMLRSS feed, because of characters in InChIs that Apache cannot handle as the PHP page expects. Once that was done, I also pimped up the CMLRSS feed itself: I added a human-friendly name, the title of the blog item discussing the molecule, and the picture Cb downloads from PubChem:

Of course the feed is still CML enabled.

Several chemical applications have been developed since. One was developed by Kermit who wrote an aggregator for mass spectrometry journal articles. And Mitch has set up a similar feature for ACS journals.

Now, what I am really waiting for, are the first applications that deal with molecular structures, and a pipe that alerts me about publications in which molecules are discussed matching a certain MQL molecular query for an interesting substructure.

In a comment, Henry Rzepa proposed inclusion of CML, and refers to earlier work on CMLRSS where Chemical Markup Language is embedded in RSS news feeds for which I wrote readers for Jmol and JChemPaint (DOI:10.1021/ci034244p).

As readers of my blog know, the Bioclipse project has been working hard on an integrated (bio)chemistry workbench, and the latest release includes a CMLRSS reader plugin too, which supports CML embedded in Atom 0.3/1.0 and RSS 1.0/2.0 feeds. Now, adding support for other embedded namespaces is trivial, and this morning I hacked in support for OTMI:

This screenshot show the original OTMI example with the Atom 1.0 entry now wrapped in an Atom 1.0 <feed> element. There is no nice OTMI icon for the OTMI content in the Atom 1.0 entry, neither did I make a ‘view’ yet showing the actual vector’s or the snippet’s, but that’s a piece of cake too.

Now, the nice thing about this is that the Bioclipse code for the Atom and RSS feeds, just greps through the feed entry and show whatever CML or OTMI content is present. When Nature decides to include CML in these OTMI files too, I will not have to update the current code.