Striving for Perfect Representation of Chemical Structures – is this possible?

It probably goes without saying that at ChEMBL, we have a desire to make all our data as accurate and useful as possible. With this in mind we have spent many hours over the last few years trying to curate, in particular, the structures of marketed drugs and clinical candidates. We aren’t alone in this and more than 5 years ago people were coming across the same problems as highlighted in this blog post by ChemConnector on Fluvastatin

Our drug curation is an ongoing and probably a never-ending task but to be honest it has proved a lot more difficult than we expected. This is for several reasons:

Firstly, where to go to find the definitive structure of a molecule? One would have thought this would be easy but even the sources such as INN and USAN don’t always agree. For example for Telavancin the USAN_data_sheet shows a difference in the nitrogen and carbon counts in the structure images compared with the images in the INN document (although the molecular formula are the same in both documents).

Secondly, while molfiles are our definitive structures and we use standard InChIs to determine uniqueness we see many examples where, as we convert between formats (molfiles, smiles, InChIs) we introduce inconsistencies. This is of course a well-known problem. There are ongoing discussions and initiatives to develop open structure formats and extend InChIs to deal with some of these cases but my sense is this is a long way off.

Lastly, and what seems like an insurmountable problem, we are constrained by the method we use to represent chemical structures. We, at ChEMBL, like many people, use version 2000 molfiles (ref 1). There is no doubt that using v3000 molfiles would solve a number of these problems but it would be very time consuming and costly to do the conversion and therefore probably only feasible for a limited number of ChEMBL structures such as the drug molecules. We are considering this as a long term goal but it would need a wider community buy in to make it worthwhile.  However, we also suspect that many of our users also only use the older molfile version so providing the v3000 format wouldn’t help them. We would be interested in your feedback on which format you use though. Most of the resources we exchange data with (e.g. PubChem, BindingDB) also use v2000 molfiles. There is no doubt that different resources find their own way to cope with the limitations of the file formats and we do too. For example, it would be possible to use non-standard extensions of the datafields in the sd file to indicate this but it would lack real chemical awareness. Also, how one group chooses to use this won’t necessarily be consistent with another group so we are no further forward.

As a consequence of our curation efforts, we have come across an increasing number of challenging molecules for which it would be useful to get the views of our users as to the best way to deal with these. It should also be said here that we are only talking about apparently “simple” rule of 5 compliant organic molecules and several years ago we stopped trying to curate organometallic compounds. We don’t show the structures of these in ChEMBL. The drug cisplatin being a case in point. The v2000 molfile has no way of coding coordination bonds and the standard InChI (ref 2) that we use to define a unique chemical structure can’t distinguish between cis and trans-platin.

Back to the organic molecules though and a few of our dilemmas:

Milnacipran is my favourite and an apparently relatively simple example.  It is a mixture of the 1S,2R and 1R,2S enantiomers (USAN). However, v2000 molfiles don’t deal with relative stereochemistry so we have 3 options:

(1) Show one enantiomer:

(2) Show it as a racemic mixture i.e. no stereochemistry:

(3) Show it as a molfile comprised of two molecules:

Arguably option 3 is the only correct way to do this. However other data providers such as FDA and Drugbank use option 1. In the ChEMBL database we use option 2 so that we can distinguish milnacipran from levomilnacipran USAN (specifically the 1S, 2R isomer) or dextromilnacipran (1R, 2S). Option 1 wouldn’t enable us to distinguish these either in the molfile or the standard InChI.

My logic here for not using option 3 is in thinking about the use people are making of ChEMBL. ChEMBL is not a registration system where option 3 might indeed be needed but it is being used as a source of bioactivity data that can be used for identifying tool compounds, building QSAR models for specific targets etc. Hence wouldn’t users taking our 1.8 million compounds just discard any mixtures such as option 3 would give before starting their analysis given that calculating physicochemical properties etc on mixtures makes little sense?

OK so suppose you disagree and think option 3 is the right thing to do, what would you want us to do for itraconazole? This is described in DailyMed (ref 3) as a “1:1:1:1 racemic mixture of four diastereoisomers (two enantiomeric pairs)”.

Option 3 would give us a mixture of 4 molecules in our v2000 molfile. For example:

Again, we have chosen option 2 as the least bad option i.e just showing it as a racemic mixture.

It seemed as if we had identified a workable and at least internally consistent way of dealing with these structures – until we took a look at the following two examples alpha prodine and beta prodine:

Here we have alphaprodine being a mixture of the (RS,SR) enantiomers:

and betaprodine the (SS,RR) enantiomers:

Hence our use of option 2 fails to distinguish between them! This matters as the two enantiomeric pairs have different biological properties e.g. different analgesic activity (ref 4)

The other example is Met(h)iomeprazine and levomet(h)iomeprazine where the former is a mixture of two enantiomers and the latter one enantiomer or the other (but it isn’t apparently known which - according to INN).

For this example, we have chosen option 2 for metiomeprazine but for levometiomeprazine we show just one of the possible enantiomers.

In summary, no existing solutions are ideal and not everyone agrees on how to do this. In ChEMBL itself we are trying to be consistent within the constraints of the v2000 molfile format but it’s not all done yet. There is however a glimmer of light in this confusion in that our UniChem connectivity match (ref 5) enables matching of these cases across databases. For example using the non stereospecific representation of milnacipran enables matching to this as well as the specific levo- and dextro- milnacipran enantiomers (as well as their salts). Details here.

So, ChEMBL users out there, we’d be interested in what you think. Do you prefer option 1, 2 or 3 or for your use cases or does it make no difference? We can’t promise an instant change but we are interested in what you think. Before you ask we know we have some inconsistencies in ChEMBL for these molecules but we are undecided on what to do and of course time spent on this is less time on other things. If you want to vote on your preferred option you can do so here.

As always if you think we have something wrong in ChEMBL please email chembl-help@ebi.ac.uk and we will endeavour to correct it.

References
(1) A. Dalby, J.G. Nourse, W. D. Hounshell, A.K.I. Gushurst, D. L. Grier, B.A. Leland and J. Laufer, Description of Several Chemical Structure File Formats Used by Computer Programs Developed at Molecular Design Limited, Chem. Inf. Comput. Sci. 1992, 32, 244-255

(2) InChI - the worldwide chemical structure identifier standard, S Heller, A McNaught, D. Tchekhovskoi and S. Stein, J. Cheminf. 2013, 5

(3) Dailymed entry for Itraconazole https://dailymed.nlm.nih.gov/dailymed/drugInfo.cfm?setid=1e243ffb-31be-39a7-4946-83ce7b839e0a

(4) A.H Becket, A.F. Casy and G Kirk – Alpha and Beta Prodine Type Compounds, J. Med. and Pharmaceut. Chem., 1959,1,1-58

(5) J. Chambers, M. Davies, A. Gaulton, G. Papadatos, A. Hersey and J. P. Overington, UniChem: extension of InChI-based compound mapping to salt, connectivity and stereochemistry layers, J. Cheminformatics 2014, 6:43

Schema changes coming in ChEMBL_24

Since ChEMBL was first released in 2009, the diversity of data sources and data types in the database has increased significantly. Increasingly, we are dealing with more complex assays such as measurement of drug pharmacokinetic parameters or toxicology data sets such as clinical biochemistry and tissue histopathology data. There are a number of problems handling these kinds of assays with the current data model/database schema. For example, since parameters such as compound doses or time points could not be recorded against individual activity measurements (only the whole assay) such experiments were typically split so that a separate assay was created for each compound or time point measured. This is obviously far from ideal. Another issue is that such experiments frequently measure or derive multiple endpoints from a particular assay (e.g., AUC, Cmax, tmax, t1/2 for a pharmacokinetic study) or produce large amounts of raw data that may need to be associated with summary-level information (e.g., toxicity measurements for individual animals).

For these reasons, we have introduced additional tables to the ChEMBL schema, as well as making some minor adjustments to existing ones (see diagram above for more details).

A full copy of the ChEMBL_24 schema is available here.

Changes To Existing Tables

ACTIVITIES:
PUBLISHED_TYPE, PUBLISHED_RELATION, PUBLISHED_VALUE, PUBLISHED_UNITS column have been renamed to TYPE, RELATION, VALUE, UNITS. This is to reflect the changing nature of the ChEMBL data (as we receive increasing numbers of deposited data sets in addition to extracting 'published' data) and also to keep consistency with other new tables. However, the existing columns will also be retained for one release and then removed in ChEMBL_25. Therefore ChEMBL_24 will contain both PUBLISHED_TYPE and TYPE columns (for example), which will be populated with identical data. The STANDARD_TYPE/RELATION/VALUE/UNITS columns are not affected.
Several other new columns have been added to ACTIVITIES:

• TEXT_VALUE (used for non-numeric/qualitative measurements, which were previously stored in ACTIVITY_COMMENT)
• STANDARD_TEXT_VALUE (standardised version of TEXT_VALUE)
• UPPER_VALUE (used with VALUE column to capture measurements that are ranges)
• STANDARD_UPPER_VALUE (standardised version of UPPER_VALUE)
• TOID (Test Occasion Identifier, used to group together related activity measurements)
• SRC_ID (Indicates the source of the bioactivity data, link to SOURCE table)

ASSAY_PARAMETERS:
The format of the ASSAY_PARAMETERS table has been changed to make it consistent with the ACTIVITIES table and allow standardisation of assay parameter data (e.g., conversion of units). The previous columns of PARAMETER_TYPE and PARAMETER_VALUE have been replaced with:

• TYPE (equivalent to the previous PARAMETER_TYPE column)
• RELATION
• VALUE (which will store numeric parameter values)
• UNITS
• TEXT_VALUE (which will store non-numeric/qualitative parameter values)

There will also be an equivalent set of STANDARD columns, storing standardised parameter values (e.g., TIME in hr rather than minutes, concentrations in nM rather than M) and these should generally be used for querying.

• STANDARD_TYPE 
• STANDARD_RELATION
• STANDARD_VALUE 
• STANDARD_UNITS
• STANDARD_TEXT_VALUE 

This change means that parameters that were previously split across multiple rows will now be grouped together. For example, previously 'DOSE' and 'DOSE_UNITS' would have been recorded as two separate parameters with no explicit link. Now, since the UNITS column has been added, these will be merged to just a single parameter called 'DOSE'.

PARAMETER_TYPE:
Table has been removed. Parameter types that have standardisation rules will be recorded in the ACTIVITY_STDS_LOOKUP table, as for activity types.

New Tables

ACTIVITY_PROPERTIES:
As mentioned previously, it was not possible in the old ChEMBL schema to record experimental parameters associated with an individual activity measurement rather than the whole assay. We have therefore created an ACTIVITY_PROPERTIES table to store this information. The format of this table is very similar to the ACTIVITIES and ASSAY_PARAMETERS tables and it can be joined to the ACTIVITIES table using the ACTIVITY_ID. There is an additional column called RESULT_FLAG that allows users to distinguish between true parameters/independent variables (RESULT_FLAG = 0) and measured properties/dependent variables e.g., 'HILL_SLOPE' or 'MAX_EFFECT' (RESULT_FLAG = 1), the latter also being included in this table where they are important in interpreting activity values.

ACTIVITY_SUPP:
The ACTIVITY_SUPP table is provided to store supplementary activity data that may not be appropriate to include in the main ACTIVITIES table. For example, in cases where IC50 data are included in the ACTIVITIES table, the supplementary table may be used to store the associated % inhibition values. Similarly, where summary-level toxicology results are stored in the ACTIVITIES table, results for individual animals may be included in ACTIVITY_SUPP. This does not mean that all raw data should be captured in ChEMBL in future, but in cases where this is deemed important to users, there is now a facility to do this.
The format of the ACTIVITY_SUPP table is again similar to ACTIVITIES, ASSAY_PARAMETERS and ACTIVITY_PROPERTIES. The table also contains an RGID (Record Grouping ID) column, which is used to group together multiple related supplementary measurements, and an SMID column which is used to link to the ACTIVITIES table (via the new ACTIVITY_SMID and ACTIVITY_SUPP_MAP tables).

Data Deposition

In order to facilitate data deposition, changes have been made to the ChEMBL loading process and the data deposition format. More details of the required deposition format will be made available soon (and we also hope to provide a submission portal in future), but in the meantime if you wish to submit data to us, please contact us and we'll be happy to talk you through the process.

The improvements we've made allow us to update existing data sets (for example, where a depositor has additional activity measurements from a previously deposited assay and wants to add these to the database). They also allow a depositor to reference an existing set of compounds/assays and deposit data against them (for example, a different institution may deposit a set of assays/activities for compounds in the MMV Pathogen Box dataset).  There are a few schema changes associated with these improvements (and there are also a few business rules/assumptions that will change).  Firstly, key tables in ChEMBL now include a depositor defined ID:

• RIDX - Reference identifier stored in the DOCS table
• CIDX - Compound identifier stored in the COMPOUND_RECORDS table
• AIDX - Assay identifier stored in the ASSAYS table

These IDs are used by data depositors to refer to their references/compounds/assays and should be stable between depositions e.g., if a CIDX such as 'CPD0001' appears in two datasets from the same depositor, it must refer to the same compound. In practice, these fields are mainly used for loading/maintaining data but may be used in queries if a user or depositor wants to retrieve data based on an externally assigned identifier such as a compound research code.

• SRC_ID field has also been added to the DOCS and ACTIVITIES tables

This means that the DOCS table could become more redundant - if the same reference was provided by two different data sources, two separate documents would be created. In practice, this is not likely to happen very frequently.

An additional and important consequence of these changes is that is no longer necessarily the case that a given activity measurement, the assay it was measured in, and the compound that the activity was measured for will link to the same SRC_ID or DOC_ID. Queries should therefore take into account the SRC_ID and DOC_ID on all three tables (COMPOUND_RECORDS, ACTIVITIES and ASSAYS) when retrieving data. Please notes that in ChEMBL_24 there are no examples of this situation, but it is likely to occur in future releases.

Other Changes

A number of other minor schema changes have been made:

• COMPOUND_PROPERTIES.NUM_ALERTS removed (for full set of structural alerts see COMPOUND_STRUCTURAL_ALERTS table)
• MOLECULE_DICTIONARY.WITHDRAWN_CLASS added (high-level categories for WITHDRAWN_REASON e.g., Cardiotoxicity, Hepatotoxicity)
• PRODUCT_PATENTS.SUBMISSION_DATE added (from FDA Orange Book)

Data Changes

In addition to the schema changes outlined above, we have performed some software and data set updates that will affect some of the records in ChEMBL.

InChI version upgraded:
We have upgraded the version of Standard InChI used in ChEMBL to v1.05. This means the STANDARD_INCHI and STANDARD_INCHI_KEY in the COMPOUND_RECORDS table have changed for a very small number of compounds (16). Details of affected compounds will be provided with the release.

Compound properties now calculated with RDKit:
Fields in the COMPOUND_PROPERTIES table (with the exception of ACD_MOST_APKA, ACD_MOST_BPKA, ACD_LOGP and ACD_LOGD) are now calculated with RDKit, rather than BIOVIA Pipeline Pilot. Therefore some values may be slightly different from those in previous releases.

Reformatting of data sets:
Some previous data sets (Open TG-GATEs, DrugMatrix and Curated Drug Pharmacokinetic Data) have been re-formatted to take advantage of the new ACTIVITY_PROPERTIES and ACTIVITY_SUPP tables. This results in a smaller number of assays than before and as a result, assay and document CHEMBL_IDs for these data sets have changed. Please note that we may need to re-format some other legacy data in future releases, for example to re-group assays that have previously been split to accommodate different doses/time points, or to migrate results captured in the ACTIVITY_COMMENT field to the STANDARD_TEXT_VALUE field.

While we've described a lot of improvements here, most of these changes will not break existing code/queries (unless you're using the NUM_ALERTS property or querying the ASSAY_PARAMETERS table) for this release. However, it's worth taking note of the changes in the underlying data model (particularly if you are using the tox data sets or querying for particular sources) and checking that any assumptions still hold true.

If you need any more information about any of these changes please feel free to contact us and we'll do our best to help!

Join the ChEMBL Team!

We are looking for talented individuals to help us maintain and develop the ChEMBL and SureChEMBL resources and currently have a number of open positions within the team. If you are looking for an exciting new role and would like to work with us on the beautiful Wellcome Genome Campus, here are details of the positions:

Data Integration Scientist

We are looking for a Scientist with a passion for data integration to manage the incorporation of drug discovery data into the ChEMBL database.

Responsibilities will include:

• Responsibility for the handling, processing and integration of data into the ChEMBL database.

• Facilitating the deposition of datasets directly into ChEMBL through working with external collaborators.

• Applying text- & data-mining techniques for the development of effective large-scale curation strategies.

• Developing methods for the application and maintenance of ontologies in ChEMBL.

• Working with other teams to facilitate the integration of data between different EBI resources.

Essential requirements include:

• A BSc (or equivalent) in a life-science subject (e.g. biological or biomedical sciences).

• 3+ years of postgraduate experience in scientific application development, database development or text- & data-mining, with a demonstrable track record of achievement.

• Proficient in at least one programming/scripting language (Python knowledge is highly desirable).

• Good knowledge of relational databases, data modelling, SQL and PL/SQL, and RESTful web-services.

• Experience in integrating diverse data sets.

For full details and to apply for the position, please visit the EMBL website:
https://www.embl.de/jobs/searchjobs/index.php?ref=EBI_01173&newlang=1&loc%5B%5D=2

Software Engineer - Dev Ops

We are seeking a talented Software Engineer/Dev Ops Developer to work on SureChEMBL, one of the largest live resources of chemistry extracted from patent data.

Responsibilities will include:

• Maintaining and improving the SureChEMBL system;

• Building new monitoring tools and dashboards;

• Developing new functionalities in collaboration with colleagues and collaborators;

• Profiling and scaling the cloud-based IaaS patent processing pipeline;

• Optimizing the application stack for maximum speed and scalability;

Essential requirements include:

• A minimum of 3 years of professional development experience;

• Strong core Java Enterprise Edition development skills and understanding of Java design principles;

• Experience of defining and creating Continuous Integration and Development environments using technologies such as Jenkins, Maven, Artifactory;

• A solid understanding of the Open Stack platform;

• Experience with distributed queue messaging (e.g. Amazon SQS, RabbitMQ)

• Experience with relational databases (mySQL, PostgreSQL);

• A solid foundation in computer science, with strong competencies in concurrency, shell scripting, and software design;

For full details and to apply for the position, please visit the EMBL website:
https://www.embl.de/jobs/searchjobs/index.php?ref=EBI_01163&newlang=1&loc%5B%5D=2

Software Engineer - Web Developer

We require a passionate Web Developer who can design and develop robust solutions that deliver ChEMBL data to our extensive user community.

Responsibilities will include:

• Developing web-based solutions to better deliver ChEMBL resources to users

• Maintaining and further developing the infrastructure that supports interfaces on chemogenomics data

• Working with other members of the team, collaborators and users to develop and deliver new and innovative ways to analyse and visualise ChEMBL data

• Integrating chemogenomics data with that from other relevant resources at the EBI and beyond

• Keeping up-to-date with relevant developments in the field of web development

Essential requirements include:

• A BSc (or equivalent) in a technical subject (e.g. life science, computing or mathematics)

• 3+ years postgraduate experience in front-end software development with a demonstrable track record of delivery

• Sound programming skills, including experience of Unix and Python

• Experience in building and using web services and good knowledge of current web technologies;

• Knowledge of search technologies e.g. Solr/Elastic

• Knowledge of relational databases, SQL PL/SQL and NoSQL approaches

• Evidence of good practice in software engineering to deliver clean, extensible and robust code through rapid development cycles with documentation and version control

For full details and to apply for the position, please visit the EMBL website:
https://www.embl.de/jobs/searchjobs/index.php?ref=EBI_01174&newlang=1&loc%5B%5D=2

Have you heard of CORBEL?

Briefly, CORBEL is an initiative of thirteen biological and medical research infrastructures, which together create a platform for harmonised user access to biological and medical technologies, biological samples and data services required by cutting-edge biomedical research.

Do you know that ChEMBL, through ELIXIR, participates to the project and provides its expertise in, among other things, identification of existing bioactivities for compounds of interest, profiling of chemotypes, target identification, data storage and distribution? But of course, CORBEL gives you access to different services working in many different biomedical areas. You want to screen the compounds you have identified and then use Electron Microscopy to observe their effect on a cell type of your interest, there are services for you! This is just an example of how CORBEL can contribute to boost your research projects(s), don’t forget we are  37 partners!  

As part of the WP4, Community Driven Cross-Infrastructure joint research – Bioscience, we were recently in Berlin to attend a Service Operator meeting and to meet the CORBEL users that requested our contribution to their project. That was a great opportunity to talk with them about their work and how ChEMBL could help them to achieve great things!

To keep it short, let’s just add that CORBEL has just launched a 2^nd Open Call. To get an idea of what that might look like please have a look at the 1^st Open Call selected projects. That might be the opportunity for you to submit your project and, if you request our help, for us to assist you in your work!

Stay stunned and feel free to contact us for more details: http://www.corbel-project.eu/open-call/technologies-services/chemical-biology-databases.html

CORBEL: http://www.corbel-project.eu

ELIXIR: https://www.elixir-europe.org

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 654248

ChEMBL tissues: Increasing depth, breadth and accuracy of annotations

Our current tissue annotation efforts have been on increasing the breadth and depth of the tissue effort first started in ChEMBL 22. The figure above represents the increased depth and coverage from that initial point till now. 

We continue to use a suite of tissue ontologies namely: Uberon, Experimental Factor Ontology (http://www.ebi.ac.uk/ols/ontologies/efo), CALOHA (ftp://ftp.nextprot.org/pub/current_release/controlled_vocabularies/caloha.obo) and Brenda Tissue Ontology ((http://www.ebi.ac.uk/ols/ontologies/bto)  to identify assays where the tissue is the assay system. We have increased the detail of information we capture to reflect the more granular tissues mentioned in the assays such as 'Popliteal lymph node' and 'Substantia nigra' pars compacta where previously the higher level term ‘lymph node’ and ‘Substantia nigra’ might have been captured.

Plasma based assays

We have recently focused annotation efforts on plasma based assays  in response to end user interest in this assays as well as acknowledging the general prevalence of plasma as an assay system for many functional/ADME assays.

Assays with multiple tissue types

We have also increased tissue curation of bioassays whose measurements are recorded across multiple tissues in a single assay e.g ‘Kidney/Liver’, ‘Heart/Liver’. In these cases, bespoke entries are created in the Tissue Dictionary, representing the tissue combination.

 

Ongoing improvements to tissue curation

·      These newly created tissue targets and assays annotated with these will be available in the next ChEMBL release (ChEMBL 24).

·      Our future web interface tissue search functionality will also make use of hierarchies inherent in the tissue ontologies to retrieve the more granular tissue terms on searching with a higher level term. An example would be that a tissue search for a high level term would include child terms of the higher level term e.g  A search for assays annotated with the tissue ‘compound eye’ UBERON:0000018 should also ideally retrieve assays annotated with direct children of this higher level term e.g ommatidium (UBERON:0000971).

·      The nature of ontological terms is such that species differences may not always be abundantly clear where single tissue term is used across different taxonomic groups to describe tissues that perform the same function in the different species but have clear anatomical differences. An example being the term eye which refers to the ‘compound eye’ UBERON:0000018 found in insects vs ‘camera type eye’ UBERON:0000019 as found in humans. We plan to use taxonomic constraint information to disambiguate cases like these and improve the correctness of mappings.

For queries and questions on tissue annotation-related matters please contact our help desk chembl-help@ebi.ac.uk

Targets in ChEMBL through the years

Evolution of targets over time

While ChEMBL was first released in 2009, the data on which it is built originate from publications extending back to 1975. Despite relatively sparse coverage from the early years in comparison to now, it is interesting to see how the publically available data for targets has grown over time. This interactive plot aims to present key data for each of ChEMBL’s targets over the years, in a style inspired by the late Hans Rosling’s TED talk on global development (if you haven't already seen it, I recommend that you watch it now!)

As shown above, dragging the slider at the bottom of the plot updates the year to reflect the data available up until that point.  The following values are shown:

• Y-axis: The cumulative sum of compounds with a pChEMBL value for the target
• X-axis: The maximum pChEMBL value or LLE (depending on radio button selection) achieved to date for target
• Point Size: The maximum phase achieved for the target
• Colour: Protein classification

Hovering the mouse over a datapoint will reveal the target's name, however as the number of points increases, it may become difficult to make sense of the data. In addition to the controls at the top of the plot, which allow you to zoom and pan the data, it is possible to filter the data by protein classification. For example, single clicking on "Enzyme" will toggle these points on and off, double clicking will turn all other points, allowing you to isolate the data for enzymes.

Use the plot to explore the target data in ChEMBL, feel free to share any interesting observations in the comments.

The plot was created using Dash and Plotly. You can view a larger version of the plot here, or download the source code here.