pychembldbで結合試験系の全てのアッセイ名を出力する

こんな感じで

from pychembldb import *
for a in chembldb.query(Assay).filter(AssayType.assay_desc == "Binding").distinct():
   a.description

創薬にredmineを持ち込むという無理ゲーに突っ込むか否か

去年辺りから色々思うところがあって、ここのところまとめていくつか社外発表したし、原稿も書いたしでそろそろアレかなぁと思っていて腑抜けみたいなみたいなノリで過ごしてたのだけど、先週、他業種の方々と色々と話をする機会があって、結局のところ自分は無理ゲーを言い訳にしてなすべきことをなしてないだけじゃないか!と自省したので、創薬にredmine的なものを持ち込むところまでは頑張るか頑張るまいかと悩み始めたのであった。

-> ハードモード(残機1)でもう一回
-> 次のステージへ
-> 違うワールドに進む

というあたりで悶々していた一週間だった。そんなわけでちょっと創薬系のエントリ連投というアクセス数を確実に減少させる悪手を繰り返していた。

自分の技術力がそれなりにあがったのと、ライブラリとか充実してきてて、チーム組まなくても独りでそこまでは到達しそうかなぁという感触がつかめたというのが1つ、いきなりredmine的なものを持ち込もうとしても上手くいくチャンスがゼロなので、仕事をやり慣れている今の職場で見ておいてもいいかなというのがもう一つ。それからAstraZenecaが似たようなことをやっていてDjangoで構築しているらしいので、PythonistaとしてFlaskでやり遂げなければならないという謎の使命感に燃えたという事情もあってredmineの導入と動き出すところくらいまではコミットしようかなと。

「一見した創薬知識の総量が多い少ないなんて気休めにもならねぇ」「活性の解釈なんてたゆたってて当たり前、それが創薬プロジェクト」「だが、、、それでも」「100%成功させる気でやる」「それがフルスタック創薬インフォマティストの気概ってもんさ」

イマココ

注)今月かまってくれた皆様には非常に感謝しております。

chemit diff == MMP

かなり前に創薬プロジェクト版Git(Chemit)というCLIなアプリを思いついたのだけど、化合物データベースへのSQLAlchemyラッパー用意したり、色々ツールを揃えたおかげで簡単に実装できるようになってたので、近いうちに作っとこうかなぁーと

で、chemit diffはMCSとか買いてたけど、これはMMPの間違いだった。

ProductName Redmineによるタスクマネジメント実践技法
小川 明彦
翔泳社 / 3444円 ( 2010-10-13 )


アッセイ結果から生データへのトラッキングというかトレーサビリティには気をつかうのに、合成化合物から合成案(何を目的とした合成なのか)までのトレーサビリティには注意を払わないのは如何なものかと。

というわけで、今は「この化合物は一体何を意図して作られたんだ?!」というような疑問がフツフツと湧くようなシステムを作っている。

MMPを構造ベースで解釈する試みはコンテキストが入りまくって一般性は得られないよね

VAMMPIREという

  1. PDBの複合体構造からリガンドを引っ張ってきて
  2. ChEMBLからMMPをサーチして
  3. ドッキングモデルを構築してWebGLで表示する

っていうDatabaseの論文をみつけたのだけど、コンテキストが入りまくりなのはどうなのかなぁ?タンパク質-リガンド相互作用を骨格の多様性で積分したら普通ゼロになるよね?実用性に疑問符がと思ったが、

ふと、あーFMOの題材としてはいいんじゃないのかなぁと閃いた。置換基変換のペアとKi差や活性差の値が出ているからFMOのエネルギー比較して色々遊べるかな。

vammpire

Open Source Software in Life Science Research

仮設駆動デザインを強く主導しているっぽいAZの論文読んでて、そういえばDjango製であるところのDesign Trackerの論文って見たことないなぁと思って探してたら、すでに購読しているBlogの著者が開発者だった。しかもOpenEyeにジョインしているのか。

というわけでこの本超読みたい。

The book is divided into four parts. Part one looks at laboratory data management and chemical informatics, covering software such as Bioclipse, OpenTox, ImageJ and KNIME. In part two, the focus turns to genomics and bioinformatics tools, with chapters examining GenomicsTools and EBI Atlas software, as well as the practicalities of setting up an ‘omics’ platform and managing large volumes of data. Chapters in part three examine information and knowledge management, covering a range of topics including software for web-based collaboration, open source search and visualisation technologies for scientific business applications, and specific software such as DesignTracker and Utopia Documents. Part four looks at semantic technologies such as Semantic MediaWiki, TripleMap and Chem2Bio2RDF, before part five examines clinical analytics, and validation and regulatory compliance of free/open source software. Finally, the book concludes by looking at future perspectives and the economics and free/open source software in industry. - See more at: http://www.woodheadpublishing.com/en/book.aspx?bookID=2830#sthash.n8wZvfrs.dpufOpen source software in life science research

特にDjangoを採用した経緯がちょっと知りたかったりする。日本の製薬企業の研究所の規模程度だったらFlaskで十分な気もする(maxでも3000userくらい捌けばいいんでしょ?)が。

でもやっぱDjangoはあつかえるようにしておいたほうがいいのかなぁー、悩む。

次々回のShizuoka.pyで誰か入門Djangoとかやってくれないかなぁ。

pychembldbでつくるChEMBLウェブサービス

Flaskpychembldbを使えばChEMBLウェブサービスみたいなのは簡単に作れるよと、朝の30分くらいを使ってちょっとやってみた。

pychembldbはSQLAlchemyのラッパーなので、Flaskのほうではルーティングを設定して、ハンドラ関数用意すればいいだけ。特にFlaskはJSON化する関数が用意されているのでJSONで返すのはラク。

@app.route("/chemblws/compounds/<chembl_id>")
def compound_by_ChEMBLID(chembl_id):
    compound = chembldb.query(Molecule).filter_by(chembl_id=chembl_id).one()
    result = {...}
    return jsonify(result)

という感じでDictionaryを用意してxmlかjsonに変換して返せばいいので、とりあえずChEMBLIDを与えると対応する化合物情報を返すAPIを実装してExamplesに用意してみた。

自前でサービスを用意することのメリットは

  • 外部に情報が流れない
  • レスポンスが速い
  • 沢山投げても怒られない

ということの他に

  • 自分たちの用途に合わせて 拡張できる
  • データベースのスキーマをきちんと理解できる

という部分もあるかなと思います。例えばChEMBLウェブサービスにはジャーナルのdoiから構造リストを返すというAPIは存在しないけど、project毎にジャーナルをまとめていたりするときにはそういうAPIが用意されていると便利かもしれませんよね?

最初、ウェブサービスが返す情報は固定なのかなと思い、決め打ちで用意したのだけど、CHEMBL1CHEMBL2で返ってくるjsonのキーが違うので、valueが存在するのものをすべて返しているのかな。

もう少しちゃんと出来たらきちんとテストを書こう。

CHEMBL1

{
    "compound": {
        "acdLogd": 7.67, 
        "acdLogp": 7.67, 
        "alogp": 3.63, 
        "chemblId": "CHEMBL1", 
        "knownDrug": "No", 
        "medChemFriendly": "Yes", 
        "molecularFormula": "C32H32O8", 
        "molecularWeight": 544.59, 
        "numRo5Violations": 1, 
        "passesRuleOfThree": "No", 
        "rotatableBonds": 2, 
        "smiles": "COc1ccc2[C@@H]3[C@H](COc2c1)C(C)(C)OC4=C3C(=O)C(=O)C5=C4OC(C)(C)[C@@H]6COc7cc(OC)ccc7[C@H]56", 
        "stdInChiKey": "GHBOEFUAGSHXPO-XZOTUCIWSA-N"
    }
}

CHEMBL2

{
    "compound": {
        "acdBasicPka": 6.52, 
        "acdLogd": 2.09, 
        "acdLogp": 2.14, 
        "alogp": 2.11, 
        "chemblId": "CHEMBL2", 
        "knownDrug": "Yes", 
        "medChemFriendly": "Yes", 
        "molecularFormula": "C19H21N5O4", 
        "molecularWeight": 383.4, 
        "numRo5Violations": 0, 
        "passesRuleOfThree": "No", 
        "preferredCompoundName": "PRAZOSIN", 
        "rotatableBonds": 4, 
        "smiles": "COc1cc2nc(nc(N)c2cc1OC)N3CCN(CC3)C(=O)c4occc4", 
        "species": "NEUTRAL", 
        "stdInChiKey": "IENZQIKPVFGBNW-UHFFFAOYSA-N", 
        "synonyms": "CP-12299,Minipress,Minizide,PRAZOSIN,Prazosin"
    }
}

DMTAがいいのかそれともTADMがいいのか?

PDCAに対応するものとして創薬の文脈の中ではDMTA(Design-Make-Test-Analysis)が語られるわけだが、昨日ケミストの方にTADMでサイクルを回すのはどう思うか?と聞かれ、直感的に「それは逃げなんじゃないかなぁ、結局ランダムスクリーニングを肯定することになるじゃん」と否定的に答えてしまったのだけど、後から考えてみると根拠があまりないわなと、もう少し深く考えてみた。

DMTA(PDCA)は仮説駆動サイクルですね、これはまぁ自明。じゃぁ、CAPD(TADM)っていうのはなんなんだ?って考えてみるにこれはテスト駆動サイクルかなと思っていたのだけど、CAPDサイクルでググッてみるに、どちらかと言うと探索駆動サイクルの意味合いが強そうだ。昨日はすっかり忘れていたが、これはちょっと前に考えたことがあった

創薬系においては、そもそもテストにあたるもの(アッセイ系)を構築するのに非常にコストがかかる。同様にDoに対応するMakeにも人件費が大いにかかるため、ランダムな合成というのはリスキーだ。さらに探索という側面がある。そのため、仮説なしに合成する(これをケミストは情報取りのための合成としばしば呼ぶわけだが)、ランダムな合成をして有意義な情報が取れたことが経験上ほとんどない。

という事情もあって、昨日の質問に(半ば短絡的に)否定的な返答をしたのだと思う。

でも実際にはlead optimizationはまず間違いなくDMTAをまわすべきだけど、lead generation (finding)にはTADMサイクルをまわすべきなのだと思う。そのためには探索手法(なにを探索したいのかそのためにはどういう測定系が必要か?さらにはどういう化合物セットを揃える必要があるか?)に精通した人間(またはチーム)が必要なんだろうなぁと。残念なことに僕はそういう探索特化型のメディシナルケミストと一緒に仕事をしたことがないという背景が否定的な結論を導いたのかなと思っている。

そういうヒトと一緒に仕事を出来ればハッピーだろうなぁと思いますね。

というわけで色々考えていたら、DMTAサイクルをまわす能力よりもTADMをまわす能力のほうがずっとレアかなと。昨日の主張はちょっと短絡的だったなと反省した。

長距離索敵陣形

ProductName 進撃の巨人(5) (講談社コミックス)
諫山 創
講談社 / 450円 ( 2011-08-09 )


gWTで何をやりたいのかっていう発表をしてきた。

今週、来週と発表が続いでいるのだけど、今日は(自分の中で)アツいgWTを製薬コミュニティの中で紹介してきて、そういう手法を使って何をやりたいのかっていう話をしてきたが有意義なレスポンスをいただけて非常に良かった。特にアルゴリズム系に興味あるヒトと繋がれたのと、同じような仕事のやり方をしている人とも話が出来たので、ユーザー会に出た価値があったかなと。

というより、初めて挨拶させていただいた複数の方から「ブログ見てるで」ということを言われて話を合わせやすかったので、ブログいいよなと再認識した。

それから、WizePairZの論文のAuthorにおもろかったでと言われたのだけど、そのときは著者だと認識できてなくて後からその方が発表中にAuthorだと気づいて、「おー!論文いつも楽しく読んでますよー」と念をとばしてみた(が当方変化型なので放出レベルは低いかも)。ちなみに来週はMMP絡みの話をするというか、activity cliffをプロジェクトのインシデントしてダブラズモラサズMECE精神で機械に自動的に拾わせるという話をするのだけど、また有意義な議論が出来ればいいなぁと。

python-pptxで表をつくってみた

python-pptxがテーブル対応していたので早速使ってみた。これはヤヴァイ、スクリプトで自動化したら快適になりそうな予感がする。

が、いまのとこ6行以上を指定するとファイルが出力できない模様。

test_table

from pptx import Presentation
from pptx.util import Inches
from pychembldb import *

prs = Presentation()
title_only_slidelayout = prs.slidelayouts[5]
slide = prs.slides.add_slide(title_only_slidelayout)
shapes = slide.shapes

shapes.title.text = "10.1016/S0960-894X(01)80693-4"

rows = 6
cols = 6
left = Inches(0.5)
top = Inches(1.5)
width = Inches(8.0)
height = Inches(0.8)

tbl = shapes.add_table(rows, cols, left, top, width, height)

tbl.columns[0].width = Inches(2.0)

tbl.cell(0, 0).text = 'inchi_key'
tbl.cell(0, 1).text = 'activity'
tbl.cell(0, 2).text = 'HBD'
tbl.cell(0, 3).text = 'HBA'
tbl.cell(0, 4).text = 'PSA'
tbl.cell(0, 5).text = 'MWT'

for journal in chembldb.query(Doc).filter_by(doi="10.1016/S0960-894X(01)80693-4"):
    for assay in journal.assays[:1]:
        for i, activity in enumerate(assay.activities[:5], 1):
            tbl.cell(i, 0).text = activity.compound.molecule.structure.standard_inchi_key
            tbl.cell(i, 1).text = str(activity.published_value)
            tbl.cell(i, 2).text = str(activity.compound.molecule.property.hbd)
            tbl.cell(i, 3).text = str(activity.compound.molecule.property.hba)
            tbl.cell(i, 4).text = str(activity.compound.molecule.property.psa)
            tbl.cell(i, 5).text = str(activity.compound.molecule.property.mw_freebase)

prs.save('test.pptx')

追記 130605

というわけでSHizuoka.py #2も楽しいよと、ちょいと宣伝しておきます。

chembl_15をサポートしてバージョンもあげた(pychembldb)

先週バージョンが上がってスキーマもかなり変更されたchembl_15に対応させました。

ChEMBLはバージョンアップでおもに結合サイトまわりが強化されているみたいです。binding_siteとかpredicted_binding_domainみたいなデータが入っているのはドッキングシミュレーションを強く意識した作りになっているんでしょう。とはいえ、いい感じのOSSなドッキングシミュレーションソフトウェアがないから、遊びにくいかも。

スキーマに関して言えば、多対多はすっきりとした感じに変更されてたのでmapper書きやすくなっててよかったが、ちょいとハマったところをメモっておく

  • target_dictionaryとpredicted_binding_domainsがone-to-manyになってなくてactivityに紐付いてる
  • information_source doesn't exist in products table
  • USAN_STEMがautoでマップできないのでとりあえずコメントしてある

あとはテストケース書くのがめんどくさかったので自動生成するようにした。今回はクラスもある程度自動生成した(utils)。

doctest書かないといけないなぁと思った。