gP2SはクライオEM実験の追跡のためのウェブアプリケーションです。主な機能と、アプリケーションのインストールと構成に必要な手順について説明します。設定が完了すると、アプリケーションは、陰性染色およびクライオEM実験に関連するメタデータを正確に記録することができます。
極低温電子顕微鏡(cryoEM)は、タンパク質標的の結晶学が必ずしも達成可能ではなく、cryoEMが構造ベースのリガンド設計をサポートする代替手段を提供するため、多くの創薬プロジェクトの不可欠な部分となっています。多数の異なるプロジェクトを扱う場合、そして各プロジェクト内で、潜在的に多数のリガンド-タンパク質の共構造を扱う場合、正確な記録を急速に保つことは困難になります。サンプル調製、グリッド調製、顕微鏡検査段階など、各ターゲットに対して多くの実験パラメータが調整されます。したがって、正確な記録保持は、長期的な再現性を可能にし、特にクライオEMワークフローのステップが異なるオペレータによって実行される場合に効率的なチームワークを促進するために非常に重要です。この課題に対処するために、我々はgP2Sと呼ばれるcryoEMのためのウェブベースの情報管理システムを開発しました。
アプリケーションは、サンプルから最終的なアトミック モデルまでの各実験をプロジェクトのコンテキストで追跡し、アプリケーション内で管理される一覧、または外部で別のシステムに保持されます。消耗品、装置、プロトコル、ソフトウェアのユーザー定義制御語彙は、cryoEMワークフローの各ステップを構造化された方法で記述するのに役立ちます。gP2S は、広く構成可能であり、チームのニーズに応じて、スタンドアロン製品として存在するか、プロジェクト管理ツールと REST API を介して統合する、タンパク質や小分子リガンドの生産を追跡するアプリケーション、またはデータ収集と保存を自動化するアプリケーションを使用して、科学アプリケーションのより広範なエコシステムの一部である可能性があります。主要な実験メタデータやパラメータ値を含む各グリッドおよび顕微鏡セッションの詳細を登録することができ、各実験アーティファクト(サンプル、グリッド、顕微鏡コピーセッション、マップなど)の系統が記録されます。gP2Sは、チームの正確な記録保持を可能にするcryoEM実験的ワークフローオーガナイザーとして機能し、オープンソースライセンスの下で利用可能です。
クライオエム施設での情報管理
2014年頃から、極低温電子顕微鏡(cryoEM)1施設の数は爆発的に増加しており、世界中に少なくとも300のハイエンドシステムが設置され、製薬会社を含む2つ以上のハイエンドシステムが、創薬におけるcryoEMの役割の増大を反映しています3。これらの施設の使命と、データ追跡と管理のためのそれらの要件は4.一部の人々は、例えば、全国のcryoEMセンターは、EMグリッドを受信し、データセットを収集し、おそらくいくつかの自動画像処理の後に、構造決定のためにユーザーにデータを返すことを担当しています。このような施設では、グリッドの証明、ユーザー提案または付与との関連付け、およびグリッドからデータセットへの系統を追跡することは非常に重要ですが、タンパク質サンプルの精製方法や最終的な構造決定プロセスなどの他の要因は、関連性が低いか、まったく関係ありません。地元の学術施設などの他の施設では、各エンドユーザーが独自のサンプルとグリッドを準備し、顕微鏡を行い、生データとその処理を管理し、結果を公開する責任があります。この役割はエンド ユーザーまたは主任調査員によって果たされるため、このような施設のメタデータ追跡には厳密な必要はありません。
当社のクライオエム機能では、サンプル、グリッド、データ収集および処理プロトコル、および結果(マップ、モデル)の取り扱いと最適化が、少数の開業医グループに多くのプロジェクトにわたって集中化されています。これは、実験的な(メタ)データ管理の課題を提示します。原子モデルからタンパク質やリガンドの正確な同一性に至るまで、構造の実験的系統は、グリッド調製パラメータおよびデータ収集プロトコルを介して正確に捕捉され、保存されなければならない。これらのメタデータは、多くの人間のオペレータが利用できるようにする必要があります。例えば、画像処理を行う人は、タンパク質を精製したり、cryoEMデータ自体を収集したりしていないにもかかわらず、タンパク質のどのコンストラクトが使用され、イメージングパラメータが何であるかを知る必要があるかもしれません。自動データ管理デーモンなどの情報システムは、ディレクトリ名を正しく体系的に割り当てるために、現在データを収集しているプロジェクトを特定する必要があります。
クライオエム機能をサポートするために、いくつかの情報管理システムが利用できます。EMEN2 5 は電子ラボ ノートブック、情報管理システム、およびビジネス プロセス管理ツールの一部の要素を組み合わせた EMEN25です。多くのシンクロトロンで使用されているISPyB6は、もともと結晶学用のX線ビームをサポートするために構築され、現在ではクライオEMデータ収集もサポートしています。Scipion7は、画像処理ワークフローを記録し、例えばパブリックリポジトリEMPIAR8、9を介して共有することができ、また、オンザフライクライオEMデータ処理を可能にするためにISPyBと統合されている画像処理パッケージの豊富で強力なラッパーです。
ここでは、精製タンパク質や小分子リガンドから最終原子モデルまでのワークフローをサポートするために構築された最新かつ軽量のクライオEM情報管理システムであるgP2S(ジェネンテックタンパク質から構造への)について説明します。
gP2S の概要
gP2Sは、クライオEMラボやマルチユーザー、マルチプロジェクト施設の正確な記録保持を容易にする、ユーザーフレンドリーなWebベースのクライオエム情報管理システムです。プロジェクト、機器、消耗品、プロトコル、サンプル、グリッド、顕微鏡セッション、画像処理セッション、マップ、およびアトミックモデルのエンティティ、それらの関係、および関連メタデータが追跡されます。また、ユーザーは、任意で、ファイルの添付ファイルを含むフリーテキストのコメントを追加することができ、gP2Sに登録された任意のエンティティの豊富な注釈を可能にします。フロントエンドはタッチスクリーンデバイスでの使用を容易にするように設計されており、12.9インチiPad Proで広範囲にテストされており、サンプルとグリッド(図1)を準備しながらラボベンチでgP2Sを使用できるようにし、顕微鏡、画像の処理、またはモデルの堆積時にコンピュータでgP2Sを使用することが可能です。フロントエンドの各ページは、可能な場合はパラメータを有効なデフォルト値に事前設定することで、手動でのデータ入力を減らすことを目的としています。
gP2S のバックエンドには、多くの REST API (REpresentational 状態転送アプリケーション プログラミング インターフェイス) エンドポイントが搭載されており、既存のワークフローやスクリプトに gP2S を統合することが可能です。データ モデルは、分岐を含む、分岐、複数の顕微鏡セッションからのデータを 1 つのデータ処理セッションにマージする、複数のマップを生成する 1 つのデータ処理セッションなど、負の汚れと cryoEM ワークフローを正確にキャプチャできるように設計されています。
システムアーキテクチャ
gP2S は、従来の 3 層アプリケーションです (図 2)。このモジュール式アーキテクチャでは、システムは 3 つの個別の層に分割され、それぞれが個別の業務を行う責任を負い、それぞれが他のシステムとは独立して交換可能または変更可能です。(1) プレゼンテーション層(またはフロントエンド)は、ウェブブラウザ(ChromeとSafariで広範囲にテスト)を介してユーザーアクセスを提供し、ワークフロー要素(データ検証を含む)を作成および変更し、実験データを個々のエンティティ、プロジェクトベースのリスト、および完全なワークフローレポートとして表示します。(2) サービス層 (またはバックエンド) は、ユーザー インターフェイスとストレージ システムの間の仲介レイヤとして機能します – コア ビジネス ロジックを保持し、フロントエンドで使用されるサービス API を公開し、ユーザー認証用のデータ ストレージおよび LDAP (ライトウェイト ディレクトリ アクセス プロトコル) システムと統合し、外部システムとの追加統合の基礎を提供します。(3) パーシスタンス層 (データアクセス) は、実験データ、ユーザーコメント、および添付ファイルの保存を担当します。
主要な技術とフレームワーク
gP2Sアプリケーションの開発、構築、メンテナンスを容易にするために、プロジェクトではいくつかの技術とフレームワークが使用されました。最も重要なものは、Vue.jsフロントエンド用2.4.210、 バックエンド用のTomcat 8サーバーが埋め込まれたSpringBoot 1.311 です。アプリケーションは、ストレージ用に MySQL 5.7 および MongoDB 4.0.6 データベースを使用し、認証に LDAP12 を使用します。既定では、これらのコンポーネント パーツはすべて 1 つのアプリケーションとして出荷およびデプロイされます。
合計で、アプリケーションは直接的または間接的に何百もの異なるライブラリを使用します。最も顕著なものは 、表1にリストされています。
データモデル
gP2S データモデルでは、3 つのタイプのエンティティを区別できます (図 3): 実験中に収集されたデータに関連するワークフロー エンティティ (サンプルセッションや顕微鏡検査セッションなど)。すべてのプロジェクトで共通のデータを記述する機器およびプロトコルエンティティ(例えば、顕微鏡またはガラス化プロトコル)。システムで支持的または技術的な役割を果たす他のエンティティ (コメントやデフォルト値など)。
ワークフロー データ ツリーのルートは、プロジェクト エンティティです。すべてのプロジェクトは、サンプルエンティティを作成するためのビルディングブロックであるタンパク質および/またはリガンドの数で構成されています。各サンプルは、複数のグリッドを作成するために使用することができ、その結果、顕微鏡セッション(顕微鏡観察セッションごとに1グリッド)で使用されます。後者は、1 つ以上のマップを生成できる処理セッションに割り当てられます。ツリーの最後のエンティティは、1 つまたは複数のマップを使用して作成されたアトミック モデルです。結果として、タンパク質からモデルまで、すべてのワークフロー関連エンティティは、常にその祖先を介して特定のプロジェクトにバインドされます。このような設計では、フロントエンド モジュールまたは API を使用した外部システムで処理しやすいデータ集計が作成されます。
ワークフロー データに加えて、実験で使用される機器や、グリッドの準備中に従ったプロトコルを記述するエンティティがあります。これらのエンティティを定義することは、グリッド、顕微鏡、および処理セッションなどの実験的なワークフローエンティティを作成するための前提条件です。
「Other」と総称される最後のタイプのデータエンティティは、技術的な目的(添付ファイルやデフォルト値など)に使用されます。このカテゴリには、ワークフローまたは機器/プロトコル エンティティにリンクできるコメント エンティティが含まれます。
ソフトウェアの可用性
gP2S のオープンソースバージョンは、apache ライセンス バージョン 2.026の https://github.com/arohou/gP2S から入手できます。gP2S を実行する Docker イメージは、https://hub.docker.com/r/arohou/gp2s から入手できます。gP2Sのクローズドソースブランチは、ロシュ&ジェネンテックで開発を続けています。
gP2S アプリケーションの実行
gP2S を実行する方法は、ドッカーコンテナーとして、またはスタンドアロン Java アプリケーションとして実行する方法の 2 つがあります。最適な選択は、ターゲットのデプロイメント環境によって異なります。たとえば、ユーザーの特定のニーズに合わせてコードをカスタマイズまたは拡張する機能が必要な場合は、アプリケーション全体を最初に再構築する必要があります。この場合、gP2S をスタンドアロンアプリケーションとして実行することをお勧めします。
ドッカーコンテナ
gP2S アプリケーションの操作を開始する最も簡単な方法は、それを Docker サービスとして実行することです。そのために、専用の Docker イメージが準備され、Docker Hub リポジトリ (「https://hub.docker.com/r/arohou/gp2s」) で公開されています。gP2S イメージの実行は、MySQL データベースと MongoDB データベース、および LDAP サーバーへのアクセスに依存します。非運用環境では、これらの依存関係をすべて、gP2S アプリケーションと共にマルチコンテナー Docker アプリケーションとして実行することをお勧めします。これをシームレスにするために、最終的な環境のすべての必要な構成を含む docker-compose ファイル (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) が gP2S GitHub リポジトリ (https://github.com/arohou/gP2S) で準備および提供されています。次のドッカーイメージは依存関係です: mysql27、 mongodb28、 apacheds29.
既定の構成では、docker コンテナーを削除すると、エンティティと添付ファイルの両方を格納されているすべてのデータが削除されます。データを保持するには、ドッカーボリュームを使用するか、gP2S アプリケーションを専用のデータベースインスタンス(MySQL および MongoDB)に接続する必要があります。ApacheDS LDAP サーバーコンテナには、事前に構成された管理者ユーザ (パスワード: シークレット) が付属しています。これらの資格情報は、Docker サービスとして実行される場合、gP2S アプリケーションにログインするために使用する必要があります。実稼働環境では、同じ docker-compose ファイルを使用して、サービスとして gP2S (および必要に応じて他のコンテナー) を Docker Swarm コンテナー オーケストレーション プラットフォームにデプロイできます。
適切な構成に関するすべての詳細を含む、gP2S を Docker コンテナーとして実行する完全なプロセスは、gP2S GitHub リポジトリで説明され、次のトピックをカバーしています。
• すべての依存関係を持つドッカー化 gP2S アプリケーションを実行する。
gP2S アプリケーション、データベース、および LDAP へのアクセス。
• gP2S サービスを新しいバージョンで更新する。
• gP2S アプリケーションを削除する。
• データ永続性の設定。
ドッカー化された gP2S アプリケーションを専用データベースまたは LDAP サーバーに接続する。
• 構成の詳細
スタンドアロン Java アプリケーション
gP2S アプリケーションを実行する別のオプションは、自己完結型 Java パッケージを作成することです。Docker コンテナーを実行できない場合は、この方法を使用する必要があります。gP2S アプリケーションをビルドするには、Java 開発キットバージョン 8 以上をインストールする必要があります。ビルドプロセス全体は、GitHub リポジトリのコードベースで提供される Maven ツールによって管理されます。ビルド構成は、最初にフロントエンドパーツをビルドし、次にそれをバックエンドソースにコピーしてから、最終的なアプリケーションとしてビルドする準備ができています。このように、完全に機能する gP2S パッケージを準備するために、他のツールやライブラリをインストールする必要はありません。デフォルトでは、ビルドの結果は JAR パッケージ (ローカルに格納) と Docker イメージ (Maven pom.xml ファイルで構成されたリポジトリにプッシュされます) です。外部システム (データベースと LDAP サーバー) に接続するために必要な情報は、パッケージを構築する前に適切な構成ファイルで指定する必要があることを覚えておくことが重要です。
gP2S JAR パッケージが作成されると、システムをホストする Tomcat アプリケーション・サーバーを含め、アプリケーションの実行に必要なすべての依存関係と構成情報が含まれます。パッケージが複数の構成ファイルでビルドされた場合は、再構築せずに異なるモードで実行できます。
gP2S GitHub リポジトリには、gP2S をスタンドアロン アプリケーションとして構築および実行するプロセスの詳細な説明が含まれており、次のトピックについて説明します。
• Maven ツールを使用した gP2S の構築
• 組み込みデータベースを使用した構築と実行
• Docker コンテナとしてデプロイされた依存関係を使用して構築および実行する
• 専用データベースを使用した構築と実行
• 認証の構成
gP2S を適切かつ一貫して使用すると、構造化データ モデルと定義済みボキャブラリを使用して重要な実験メタデータの記録を強制することで、高品質のメタデータを適切に記録することができますが、この付加価値は、ラボで高いレベルのコンプライアンスが達成された場合にのみ完全に実現されます。上記のプロトコルは、これを達成する方法をカバーしていません。効果的な施行技術は、顕微鏡オペレータがgP2Sに登録されていないグリッド上のデータを収集することを拒否することであることがわかりました。これは非常に迅速にコンプライアンスを推進し、詳細かつ正確な実験の詳細と企業の記憶の大規模な体の次の数ヶ月間の出現のための地面を築きました。数ヶ月の使用の後、gP2Sに格納されたメタデータのコーパスの価値は、明示的な介入なしにコンプライアンスが高いままであったことをほとんどのユーザーに明らかにしました。
この集合メモリを十分に活用するには、gP2Sに格納されたメタデータが外部システムからアクセス可能であり、実験データ(顕微鏡写真)と結果(マップとモデル)に簡単に関連付けられる必要があります。上記のプロトコルは、gP2Sを他の情報学およびデータ処理システムと統合する方法を説明していません。最も簡単なのは、gP2SのバックエンドREST APIを介した潜在的な統合であり、gP2Sの変更は必要ありません。たとえば、データ収集検出器を制御する各コンピュータは、顕微鏡セッション管理RESTコントローラの下でgP2Sのエンドポイント「getItemBy顕微鏡」を定期的に問い合わせ、顕微鏡観察セッションが顕微鏡上で進行中かどうかを確認するスクリプトを実行します。その場合、スクリプトは gP2S から適切なデータストレージディレクトリ名を取得し(上記の「設定」ページで構成)、この名前を使用してローカルデータストレージデバイス上にディレクトリを作成します。これにより、データストレージディレクトリの体系的な命名が保証され、誤字入力による誤りのリスクが軽減されます。
gP2Sの公開版のソースでコメント化されていますが、gP2Sが外部システムのデータを消費するさらなる統合も可能です。私たちの研究室では、gP2Sの展開は(i)プロジェクト管理システムと統合され、gP2Sで構成された各プロジェクトを会社全体のポートフォリオプロジェクトにリンクさせ、ポートフォリオからのメタデータをgP2S内に表示することができます。(ii) タンパク質登録システムは、gP2Sに添加された各タンパク質が、局所的に保存された識別子を介して、タンパク質の証明を詳述する完全な記録にリンクされるように、関連する分子生物学、発現系および精製の詳細を含む。(iii)低分子化合物管理システムは、gP2Sがその化学構造などの各リガンドに関する重要な情報を表示することを可能にする。これらの統合を有効にするために必要なコードの変更については、gP2S リポジトリ (https://github.com/arohou/gP2S) から入手できる README-BUILD.md ドキュメントの「統合」セクションで説明します。
gP2S の現行バージョンには制限があり、その中からは、過度に単純化されたデータ モデルと構造 (Model) のデポジションのフロントエンドが最初に挙げられており、その中から 1 つ目は制限があります。これは、本格的な構造の堆積および検証機能が現在X線結晶学のサポートと共に開発中であるため、gP2Sのリリース版では意図的に「ベアボーン」状態に置かれました。もう 1 つの設計上の決定は、特権やアクセス許可システムを実装しないことでした: gP2S のすべてのユーザーは、その機能とデータに対して同等のアクセス権を持っています。これは、競合する利益と機密性の要件を持つユーザーグループにサービスを提供する施設にとっては不十分な選択になるかもしれませんが、私たちの施設にとっては懸念事項ではありませんでした。
当社の社内版gP2Sの開発は進行中であり、ここで説明したオープンソース版が他のcryoEMグループに役立ち、将来提案やコードの改善に貢献する可能性があることを期待しています。今後の価値の高い開発は、例えば、ラボ機器(ガラス化ロボット、電子顕微鏡)、ソフトウェア(例えば画像処理メタデータを収穫する)、外部の公共リポジトリ(構造堆積を容易にする)との統合に焦点を当てることができる。
ラボやクライオエムの施設でgP2Sを日常的に使用することで可能になる高品質のメタデータの体系的な収集は、数年間にわたって複数のプロジェクトを並行して起訴する能力に大きなプラスの影響を与える可能性があります。ますます共有され、集中化されたクライオEMグループや施設が確立されるにつれて、gP2Sなどの情報管理システムの必要性は今後も高まり続けると予想しています。
The authors have nothing to disclose.
著者らは、プロジェクトの設立以来、プロジェクトに取り組んできたgP2S開発チームの他のすべてのメンバーに感謝します: ラファウ・ウッジエラ, セザリー・クシジャノフスキ、プシェミスワフ・スタンコフスキ、ヤチェク・イェムスキ、ピオトル・スチッキ、カロリーナ・パヨンク、エウト・ヴァンデン・アイデン、ダミアン・ミエルツヴィングスキ、ミハウ・ヴォイトコフスキ、ピオトル・ピクサ、アンナ・スルダッカ、カミル・ウチャク、アルトゥール・クサック。また、レイモンド・ハとクラウディオ・シフェリがチームを組み立て、プロジェクトを形作ってくれたことに感謝します。