Datasets API (building on brainstormed dreamed example)

[jaimergp]

Description

This PR will establish the needed Dataset objects (and supporting abstractions) as brainstormed in the included examples/api-brainstorming/kinoml_example.py (see diff). This was only conceived as a draft, so we'll need to iterate on it and provide the actual implementations to match that as close as possible.

Datasets to include

• [x] PKIS2 (KinomeScan)
• [x] ChEMBL 27
• [ ] DREAM Challenge
• [ ] KIBA

Implementation progress

• [ ] To be added

Questions

• [ ] Where can we find the Dream dataset, @AndreaVolkamer?
• [ ] Do we really need Filter objects? We could implemente numpy-like slicing mechanisms to say dataset_provider[dataset_provider['protein']['n_residues'] < 100], although I don't know how complex this would be. Maybe in a future release (we would need to inherit from pandas or provide views to our wrapper dataframes within the dataset).
• [x] Implementing Log-likelihood functions

Implement modular log-likelihoods coming from different data sources.

Comes from #13

Key aspects:

• Loss function is the sum of the modular log-likelihood per dataset source or measurement class
• We will predict dG/KT, but we can discretize in inactives / actives later if needed.
• Unknowns. These could be nuisance parameters in the future, but for now:
  • [substrate]: we could estimate by cross-validation, use relative pIC50s, or add that as a nuisance parameter in the future
  • uncertainties: estimate per dataset (like Kramer's paper) or measurement class
• We will start by taking the intersection of ChEMBL/KinomeScan.
• Featurization does not need to be too advanced now. The idea here is to implement the framework only and see how it looks in the API.

Todos

• [ ] Implement a draft notebook that covers the toy problem: "Let's assume there's a subset of Chembl also present in KinomeScan. We can train on one, predict on the other one, on both, and/or all combinations. What's the error on our reported estimates? What's the accuracy / sensitivity?"
• [ ] Add new attributes to relevant objects
• [x] Evaluate the need for DatasetCollection or MetaDataset object

Structural featurizers

• Docking pipelines by @schallerdavid (this original PR)
• Homology modelling by @glass-w (#26)
• Dunbrack featurizers by @jiayeguo (#29)

I have merged all PRs here and will work on getting them in shape for the library.

To do

• [ ] Structural object model based on MDA
• [ ] Docking
  • [ ] Librarize code that needs so
  • [ ] Ensure / add tests
  • [ ] Ensure / add docs
• [ ] Homology modeling
  • [ ] Librarize code that needs so
  • [ ] Ensure / add tests
  • [ ] Ensure / add docs
• [ ] Dunbrack featurizer
  • [ ] Librarize code that needs so
  • [ ] Ensure / add tests
  • [ ] Ensure / add docs

[codecov-io]

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@58b7590). Click here to learn what that means. The diff coverage is n/a.

[jaimergp]

Wooohoo it's green!

[jaimergp]

Well, green no more... :)

@t-kimber, one of the reasons we have failing tests is that.. we are now testing the featurizers :) However, our test examples no longer apply because once we enter the OpenForceField territory, the SMILES get canonicalized so what initially was C internally becomes [H][C]([H])([H])[H].

So, of course, Morgan fingerprints are different due to the oxygen atoms, OHE matrices deal with more stuff, etc. Can we adapt the pytest.mark.parametrize data points in kinoml/tests/features/test_ligand.py so it provides the right solutions?

You can the OFFTK SMILES representation with kinoml.core.ligands.Ligand.from_smiles("C").to_smiles() (change "C" to whatever you need).

[jaimergp]

Where can we find the Dream dataset, @AndreaVolkamer?

[jaimergp]

Tests run again now, and fail as expected :)

[jaimergp]

This is in good shape now, or at least good enough to merge. There's plenty of things to fix and improve, but from now on we'll address those in issues + smaller PRs.