Skip to main content

Data Integration - The Ontogeny of Chemical Data

It is great to be able to perform confederated queries across data sources, really great. The greatness of this leads to the development of common representational and access standards (things like MIABE, InChI, and PSIQUIC, as examples that we are involved in ourselves). This ability to take data out of silos and share has arguably been one of the defining elements of science in the last ten years, and the generalisation of this data sharing and representation via semantic web technologies may become one of the defining features of the next decade. One of the issues though is that of data provenance, and primacy, and this is an issue that we have started to think about, and plan for in our own data integration efforts.

Data enters the 'system' somewhere in a 'database'; and these bundles are then 'licensed' to the community. The licenses may be silent, ambiguous, as clear-as-a-bell, shockingly unacceptable, or whatever - and there is a clear need for standardisation of licenses, or at the very least the requirement that license terms are freely available on the resource web site.

There are arguably two basic types of chemical databases at the moment - primary and secondary - primary databases are the first point of entry of that on the internet, or to the user community, and the groups responsible for these typically focus on data novelty (providing something that others don't) and also typically care about curation and indexing of the data. The current funding system does a pretty good job minimising overlap between funded primary databases. Primary data can be a one-off effort, a passive archive, or regularly updated with new content and curated; and there are many other nuances to consider. These primary databases tend to have a theme - spectroscopic data, or bioactivity data, or synthesis, etc., and be relatively small. Together they are the substrate for the secondary databases. There are arguably (again this is all just top of the head thinking) two types of integration that people typically do - 'vertical' and 'horizontal' - by 'vertical' I mean bundling all the chemical objects together, or bundling all the non-redundant proteins together, or bundling all protein structures and protein models together, and by 'horizontal' I mean integrating across different object classes, e.g. protein structures and small molecule ligands, or genes and protein structures, etc. The 'vertical secondary' databases typically add little new data, but confederate primary data content, reduce redundancy, provide cross-references, etc. but they often add significant value in terms of new descriptors, services, etc. It is also often a lot easier to curate data when integrated across other resources. Secondary databases may be physical (in that copies are made of the primary databases and all loaded together) or virtual (they query the primary resources through an API).

Secondary (vertical) databases do a great job of integration across these disparate resources, allowing queries across unlinked primary databases, and this is a required task for the more challenging horizontal integration. This horizontal data integration is probably where the majority of impact and insights from data are going to come from - for example there are great opportunities to integrate drug pharmacokinetic and pharmacodynamic data with human genetic variation data, to look for opportunities to deliver currently oral drugs topically, or to mine patent/marketing exclusivity expiries and look for arbitrage opportunities between diseases/healthcare systems, for the more entrepreneurial.

So some examples of primary and secondary chemistry databases - we like to think of ChEMBL as a primary database (more specifically the literature and deposited data, this makes up the majority of the data we have). We think of ChemSpider as a secondary database, and some databases like PubChem are arguably a mix of primary (for the NIH bioactivity data) and secondary (for compound catalogues and from other databases).

Is this view of chemical databases useful at all? Maybe not. But it maybe poses a couple of questions.
  • What are the optimal mechanisms for curation and error correction of data? Is it performed at the secondary or primary levels?
  • What are the primary and secondary resources - is it worth providing tracking of data provenance ? Should there be a standard format for the manifest of secondary resources? 
  • Secondary resources need to have effective update and correction capabilities driven by updates in their underlying primary resources (this is quite a poor area at the moment it seems - loaded once, a few years ago, doesn't mean that a secondary resource contains the best view of the primary data)?
  • How is licensing addressed in secondary resources? - I've found quite a few examples of where I can't download a dataset from it's primary website, yet it is contained in a secondary resource, nominally freely available.
  • Where should funding focus go - to standardising access and indexing of primary resources, or into consolidating data into secondary resources.
We have a couple of spreadsheets of various chemical database resources, licenses, a classification as primary/secondary, etc. - restricted of course to the sort of things we are interested in ;). If there's interest (post a comment to this post, or mail me), we have a web meeting to present this preliminary work. Some of these things are related to the activities of the Open PHACTS, project, so it will be interesting to see how they are addressing some of these.


Popular posts from this blog

UniChem 2.0

UniChem new beta interface and web services We are excited to announce that our UniChem beta site will become the default one on the 11th of May. The new system will allow us to better maintain UniChem and to bring new functionality in a more sustainable way. The current interface and web services will still be reachable for a period of time at . In addition to it, the most popular legacy REST endpoints will also remain implemented in the new web services: Some downtime is expected during the swap.  What's new? UniChem’s current API and web application is implemented with a framework version that’s not maintained and the cost of updating it surpasses the cost of rebuilding it. In order to improve stability, security, and support the implementation and fast delivery of new features, we have decided to revamp our user-facing systems using the latest version of widely used and maintained frameworks, i

A python client for accessing ChEMBL web services

Motivation The CheMBL Web Services provide simple reliable programmatic access to the data stored in ChEMBL database. RESTful API approaches are quite easy to master in most languages but still require writing a few lines of code. Additionally, it can be a challenging task to write a nontrivial application using REST without any examples. These factors were the motivation for us to write a small client library for accessing web services from Python. Why Python? We choose this language because Python has become extremely popular (and still growing in use) in scientific applications; there are several Open Source chemical toolkits available in this language, and so the wealth of ChEMBL resources and functionality of those toolkits can be easily combined. Moreover, Python is a very web-friendly language and we wanted to show how easy complex resource acquisition can be expressed in Python. Reinventing the wheel? There are already some libraries providing access to ChEMBL d

ChEMBL 30 released

  We are pleased to announce the release of ChEMBL 30. This version of the database, prepared on 22/02/2022 contains: 2,786,911 compound records 2,157,379 compounds (of which 2,136,187 have mol files) 19,286,751 activities 1,458,215 assays 14,855 targets 84,092 documents Data can be downloaded from the ChEMBL FTP site: Please see ChEMBL_30 release notes for full details of all changes in this release: New Deposited Datasets EUbOPEN Chemogenomic Library (src_id = 55, ChEMBL Document ID CHEMBL4689842):   The EUbOPEN consortium is an Innovative Medicines Initiative (IMI) funded project to enable and unlock biology in the open. The aims of the project are to assemble an open access chemogenomic library comprising about 5,000 well annotated compounds covering roughly 1,000 different proteins, to synthesize at least

LSH-based similarity search in MongoDB is faster than postgres cartridge.

TL;DR: In his excellent blog post , Matt Swain described the implementation of compound similarity searches in MongoDB . Unfortunately, Matt's approach had suboptimal ( polynomial ) time complexity with respect to decreasing similarity thresholds, which renders unsuitable for production environments. In this article, we improve on the method by enhancing it with Locality Sensitive Hashing algorithm, which significantly reduces query time and outperforms RDKit PostgreSQL cartridge . myChEMBL 21 - NoSQL edition    Given that NoSQL technologies applied to computational chemistry and cheminformatics are gaining traction and popularity, we decided to include a taster in future myChEMBL releases. Two especially appealing technologies are Neo4j and MongoDB . The former is a graph database and the latter is a BSON document storage. We would like to provide IPython notebook -based tutorials explaining how to use this software to deal with common cheminformatics p

Multi-task neural network on ChEMBL with PyTorch 1.0 and RDKit

  Update: KNIME protocol with the model available thanks to Greg Landrum. Update: New code to train the model and ONNX exported trained models available in github . The use and application of multi-task neural networks is growing rapidly in cheminformatics and drug discovery. Examples can be found in the following publications: - Deep Learning as an Opportunity in VirtualScreening - Massively Multitask Networks for Drug Discovery - Beyond the hype: deep neural networks outperform established methods using a ChEMBL bioactivity benchmark set But what is a multi-task neural network? In short, it's a kind of neural network architecture that can optimise multiple classification/regression problems at the same time while taking advantage of their shared description. This blogpost gives a great overview of their architecture. All networks in references above implement the hard parameter sharing approach. So, having a set of activities relating targets and molecules we can tra