gP2S ist eine Webanwendung zur Verfolgung von KryoEM-Experimenten. Die Hauptfunktionen werden ebenso beschrieben wie die Schritte, die zum Installieren und Konfigurieren der Anwendung erforderlich sind. Nach der Konfiguration ermöglicht die Anwendung die genaue Aufzeichnung von Metadaten, die mit negativen Flecken und KryoEM-Experimenten verbunden sind.
Die kryogene Elektronenmikroskopie (kryoEM) ist zu einem integralen Bestandteil vieler Projekte zur Entdeckung von Medikamenten geworden, da die Kristallographie des Proteinziels nicht immer erreichbar ist und kryoEM ein alternatives Mittel zur Unterstützung des strukturbasierten Ligandendesigns bietet. Bei einer Vielzahl unterschiedlicher Projekte und innerhalb jedes Projekts mit einer potenziell großen Anzahl von Liganden-Protein-Kostrukturen wird die genaue Aufzeichnung schnell zu einer Herausforderung. Viele experimentelle Parameter werden für jedes Ziel optimiert, einschließlich in der Probenvorbereitungs-, Rastervorbereitungs- und Mikroskopiephase. Daher kann eine genaue Aufzeichnung von entscheidender Bedeutung sein, um eine langfristige Reproduzierbarkeit zu ermöglichen und eine effiziente Teamarbeit zu ermöglichen, insbesondere wenn Schritte des cryoEM-Workflows von verschiedenen Operatoren ausgeführt werden. Um diese Herausforderung zu bewältigen, haben wir ein webbasiertes Informationsmanagementsystem für kryoEM entwickelt, das gP2S genannt wird.
Die Anwendung verfolgt jedes Experiment, von der Probe bis zum endgültigen atomaren Modell, im Kontext von Projekten, deren Liste in der Anwendung oder extern in einem separaten System verwaltet wird. Benutzerdefinierte kontrollierte Vokabeln von Verbrauchsmaterialien, Geräten, Protokollen und Software helfen dabei, jeden Schritt des kryoEM-Workflows strukturiert zu beschreiben. gP2S ist weithin konfigurierbar und kann je nach den Bedürfnissen des Teams als eigenständiges Produkt oder Als Teil eines breiteren Ökosystems wissenschaftlicher Anwendungen existieren, die über REST-APIs mit Projektmanagement-Tools, Anwendungen, die die Produktion von Proteinen oder kleinen Molekülligaden verfolgen, oder Anwendungen, die die Datenerfassung und -speicherung automatisieren, integriert werden. Benutzer können Details zu jedem Raster und jeder Mikroskopiesitzung registrieren, einschließlich wichtiger experimenteller Metadaten und Parameterwerte, und die Abstammung jedes experimentellen Artefakts (Beispiel, Raster, Mikroskopiesitzung, Karte usw.) wird aufgezeichnet. gP2S dient als cryoEM experimenteller Workflow-Organizer, der eine genaue Aufzeichnung für Teams ermöglicht und unter einer Open-Source-Lizenz verfügbar ist.
Informationsmanagement in cryoEM-Einrichtungen
Seit 2014 ist die Zahl der kryogenen Elektronenmikroskopie (kryoEM)1-Anlagen explosionsartig gestiegen, mit mindestens 300 High-End-Systemen, die weltweit installiert sind2, auch bei einer Reihe von Pharmaunternehmen, was eine wachsende Rolle für KryoEM bei der Arzneimittelentdeckung widerspiegelt3. Die Aufgaben dieser Einrichtungen und ihre Anforderungen an die Datenverfolgung und -verwaltung unterscheiden sich4. Einige, zum Beispiel nationale KryoEM-Zentren, werden mit dem Empfang von EM-Rastern, dem Sammeln von Datensätzen und der Rückgabe von Daten an die Benutzer zur Strukturbestimmung beauftragt, vielleicht nach einer automatisierten Bildverarbeitung. In solchen Einrichtungen ist die Verfolgung der Herkunft des Netzes, seine Zuordnung zu einem Benutzervorschlag oder Zuschuss und die Abstammung von Gitter zu Datensatz von entscheidender Bedeutung, aber andere Faktoren, wie die Methode zur Reinigung der Proteinprobe oder der eventuelle Strukturermittlungsprozess, sind weniger oder gar nicht relevant. In anderen Einrichtungen, wie z. B. lokalen akademischen Einrichtungen, ist jeder Endbenutzer für die Vorbereitung seiner eigenen Proben und Raster, die Durchführung der Mikroskopie, die Verwaltung der Rohdaten und deren Verarbeitung und Veröffentlichung der Ergebnisse verantwortlich. Eine solche Einrichtung muss nicht genau nachverfolgt werden, da diese Rolle vom Endbenutzer oder seinem Hauptermittler erfüllt wird.
In unserer cryoEM-Anlage wird die Handhabung und Optimierung von Proben, Rastern, Datenerfassungs- und Verarbeitungsprotokollen und Ergebnissen (Karten, Modelle) in vielen Projekten auf eine kleine Gruppe von Praktikern zentralisiert. Dies stellt das experimentelle (Meta-)Datenmanagement vor Herausforderungen. Die experimentelle Abstammung von Strukturen, vom Atommodell bis hin zur genauen Identität von Proteinen und Liganden, über Rastervorbereitungsparameter und Datenerfassungsprotokolle, muss genau erfasst und aufbewahrt werden. Diese Metadaten müssen einer Reihe von menschlichen Operatoren zur Verfügung gestellt werden. Beispielsweise muss eine Person, die Bildverarbeitung macht, möglicherweise wissen, welches Konstrukt eines Proteins verwendet wurde und welche bildgebenden Parameter es gab, obwohl sie weder das Protein gereinigt noch die KryoEM-Daten selbst gesammelt hat; Informatiksysteme wie automatisierte Datenmanagement-Daemons müssen das Projekt identifizieren, für das ein Mikroskop derzeit Daten sammelt, um Verzeichnisnamen korrekt und systematisch zuzuweisen.
Zur Unterstützung von kryoEM-Einrichtungen stehen mehrere Informationsmanagementsysteme zur Verfügung. Am vollständigsten ist vielleicht EMEN25, das Funktionen eines elektronischen Labor-Notebooks, eines Informationsmanagementsystems und einiger Elemente eines Geschäftsprozessverwaltungstools kombiniert. ISPyB6, das ursprünglich zur Unterstützung der Röntgenstrahllinien für die Kristallographie entwickelt wurde, unterstützt jetzt auch die KryoEM-Datenerfassung. Scipion7 ist ein reichhaltiger und leistungsstarker Wrapper um Bildverarbeitungspakete, der es Benutzern ermöglicht, Bildverarbeitungs-Workflows aufzuzeichnen und zu teilen, zum Beispiel über das öffentliche Repository EMPIAR8,9, und ist auch in ISPyB integriert, um die spontane KryoEM-Datenverarbeitung zu ermöglichen.
Hier beschreiben wir gP2S (für Genentech Protein to Structure), ein modernes und leichtes KryoEM-Informationsmanagementsystem, das entwickelt wurde, um den Workflow vom gereinigten Protein und kleinen Molekülligand bis zum endgültigen Atommodell zu unterstützen.
Übersicht über gP2S
gP2S ist ein benutzerfreundliches webbasiertes KryoEM-Informationsmanagementsystem, das eine genaue Aufzeichnung von KryoEM-Laboren und Multi-User-, Multi-Projekt-Einrichtungen ermöglicht. Die folgenden Entitäten, ihre Beziehungen und zugehörigen Metadaten werden nachverfolgt: Projekte, Ausrüstung, Verbrauchsmaterialien, Protokolle, Beispiele, Raster, Mikroskopiesitzungen, Bildverarbeitungssitzungen, Karten und Atommodelle. Benutzer können auch Freitextkommentare hinzufügen, optional einschließlich Dateianhänge, die eine umfassende Anmerkung jeder in gP2S registrierten Entität ermöglichen. Das Front-End wurde entwickelt, um die Verwendung mit Touchscreen-Geräten zu erleichtern und ausgiebig auf 12,9″ iPad Pros getestet, so dass es möglich ist, gP2S auf dem Labortisch bei der Vorbereitung von Proben und Rastern (Abbildung 1) sowie am Computer beim Bedienen des Mikroskops, der Verarbeitung von Bildern oder der Hinterlegung von Modellen zu verwenden. Jede Seite im Front-End zielt darauf ab, die manuelle Dateneingabe zu reduzieren, indem Parameter nach Möglichkeit auf sinnvolle Standardwerte voreingestellt werden.
Das Backend von gP2S verfügt über eine Reihe von REST-API-Endpunkten (REpresentational State Transfer Application Programming Interface), die es ermöglichen, gP2S in vorhandene Workflows und Skripts zu integrieren. Das Datenmodell wurde entwickelt, um die genaue Erfassung von negativen Flecken- und KryoEM-Workflows zu ermöglichen, einschließlich Verzweigungen, z. B. mit einer Probe, die in mehreren Rastern verwendet wird, Daten aus mehreren Mikroskopiesitzungen, die in einer einzigen Datenverarbeitungssitzung zusammengeführt werden, oder eine Datenverarbeitungssitzung, die mehrere Karten ergibt.
Systemarchitektur
gP2S ist eine klassische dreistufige Anwendung (Abbildung 2). In dieser modularen Architektur wird das System in drei separate Ebenen unterteilt, die jeweils für die Erfüllung unterschiedlicher Aufgaben verantwortlich sind und jede unabhängig von den anderen ersetzbar oder veränderbar ist. (1) Die Präsentationsschicht (oder das Frontend) ermöglicht den Benutzerzugriff über den Webbrowser (ausgiebig mit Chrome und Safari getestet), ermöglicht das Erstellen und Ändern von Workflowelementen (einschließlich Datenvalidierung) und zeigt experimentelle Daten als einzelne Entitäten, projektbasierte Listen und vollständige Workflowberichte an. (2) Die Service-Schicht (oder das Backend) dient als Zwischenschicht zwischen der Benutzeroberfläche und dem Speichersystem – sie enthält die Kerngeschäftslogik, macht die vom Frontend verwendete Service-API verfügbar, integriert sich in datenspeicher- und LDAP-System (Lightweight Directory Access Protocol) für die Benutzerauthentifizierung und bietet eine Grundlage für die zusätzliche Integration mit externen Systemen. (3) Die Persistenzschicht (Datenzugriff) ist für die Speicherung experimenteller Daten, Benutzerkommentare und Dateianhänge verantwortlich.
Schlüsseltechnologien und -rahmen
Um die Entwicklung, den Bau und die Wartung der gP2S-Anwendung zu erleichtern, wurden im Projekt mehrere Technologien und Frameworks eingesetzt. Die wichtigsten sind: Vue.js 2.4.210 für das Frontend und SpringBoot 1.311 mit eingebettetem Tomcat 8 Server für das Backend. Die Anwendung verwendet MySQL 5.7 und MongoDB 4.0.6 Datenbanken für Speicher und LDAP12 für die Authentifizierung. Standardmäßig werden alle diese Komponenten als eine Anwendung ausgeliefert und bereitgestellt.
Insgesamt verwendet die Anwendung Hunderte von verschiedenen Bibliotheken direkt oder indirekt. Die prominentesten sind in Tabelle 1aufgeführt.
Datenmodell
Im gP2S-Datenmodell lassen sich drei Arten von Entitäten unterscheiden(Abbildung 3):Workflow-Entitäten im Zusammenhang mit Daten, die während Vonexperimenten gesammelt wurden (z. B. Proben oder Mikroskopiesitzungen); Geräte und Protokollentitäten, die Daten beschreiben, die in allen Projekten gemeinsam sind (z. B. Mikroskope oder Verglasungsprotokolle); andere Entitäten, die unterstützende oder technische Rollen im System spielen (z. B. Kommentare oder Standardwerte).
Der Stamm der Workflowdatenstruktur ist die Projektentität. Jedes Projekt besteht aus einer Reihe von Proteinen und/oder Liganden, die Bausteine für die Erstellung von Sample-Entitäten sind. Jedes Sample kann verwendet werden, um mehrere Raster zu erstellen, die wiederum in Mikroskopiesitzungen (ein Raster pro Mikroskopiesitzung) verwendet werden. Letztere werden Verarbeitungssitzungen zugewiesen, die eine oder mehrere Karten ergeben können. Die letzte Entität in der Struktur ist das atomare Modell, das mit einer oder mehreren Karten erstellt wird. Folglich ist jede Workflow-bezogene Entität, vom Protein bis zum Modell, über ihre Vorfahren immer an ein bestimmtes Projekt gebunden. Bei einem solchen Entwurf werden Datenaggregate erstellt, die einfach entweder über das Frontend-Modul oder durch externe Systeme mithilfe der API verarbeitet werden können.
Zusätzlich zu den Workflowdaten gibt es Entitäten, die Geräte beschreiben, die in Experimenten oder Protokollen verwendet werden, die beim Vorbereiten von Rastern befolgt wurden. Das Definieren dieser Entitäten ist eine Voraussetzung für die Erstellung experimenteller Workflowentitäten wie Grids, Mikroskopie und Verarbeitungssitzungen.
Der letzte Typ der Datenentität, die zusammen als “Sonstige” bezeichnet wird, wird für technische Zwecke verwendet (z. B. Dateianhänge oder Standardwerte). Diese Kategorie enthält Kommentarentitäten, die mit beliebigen Workflow- oder Geräte-/Protokollentitäten verknüpft werden können.
Softwareverfügbarkeit
Die Open-Source-Version von gP2S ist unter einer Apache-Lizenzversion 2.026von https://github.com/arohou/gP2S verfügbar. Ein Docker-Image zum Ausführen von gP2S ist von https://hub.docker.com/r/arohou/gp2s verfügbar. Eine geschlossene GP2S-Niederlassung wird bei Roche & Genentech weiter entwickelt.
Ausführen der gP2S-Anwendung
Es gibt zwei Möglichkeiten, gP2S auszuführen: als Docker-Container oder als eigenständige Java-Anwendung. Die optimale Auswahl hängt von der Zielbereitstellungsumgebung ab. Wenn z. B. die Möglichkeit zum Anpassen oder Verbessern des Codes an die spezifischen Anforderungen der Benutzer gewünscht wird, muss zuerst die gesamte Anwendung neu erstellt werden. In diesem Fall kann empfohlen werden, gP2S als eigenständige Anwendung auszuführen.
Docker-Container
Die einfachste Möglichkeit, mit der arbeite mit der gP2S-Anwendung zu beginnen, besteht darin, sie als Docker-Dienst auszuführen. Zu diesem Zweck wurde ein dediziertes Docker-Image vorbereitet und im Docker Hub-Repository veröffentlicht (“https://hub.docker.com/r/arohou/gp2s”). Das Ausführen des gP2S-Abbilds hängt vom Zugriff auf MySQL- und MongoDB-Datenbanken sowie auf einen LDAP-Server ab. Für Nicht-Produktionsumgebungen wird empfohlen, alle diese Abhängigkeiten zusammen mit der gP2S-Anwendung als Docker-Anwendungen mit mehreren Containern auszuführen. Um dies nahtlos zu gestalten, wurde eine docker-compose-Datei (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) vorbereitet, die alle erforderlichen Konfigurationen der endgültigen Umgebung enthält, und wurde im gP2S GitHub-Repository (https://github.com/arohou/gP2S) bereitgestellt. Die folgenden docker-Images sind Abhängigkeiten: mysql27, mongodb28, apacheds29.
In der Standardkonfiguration werden alle gespeicherten Daten, sowohl Entitäten als auch Dateianlagen, beim Entfernen der Docker-Container gelöscht. Um die Daten zu erhalten, sollten entweder Docker-Volumes verwendet werden, oder die gP2S-Anwendung sollte mit dedizierten Datenbankinstanzen (MySQL und MongoDB) verbunden werden. Der ApacheDS LDAP-Servercontainer verfügt über einen vorkonfigurierten Admin-Benutzer (Kennwort: geheim). Diese Anmeldeinformationen sollten verwendet werden, um sich bei der gP2S-Anwendung anzumelden, wenn sie als Docker-Dienst ausgeführt wird. Für Produktionsumgebungen kann dieselbe Docker-Compose-Datei verwendet werden, um gP2S (und andere Container bei Bedarf) als Dienste auf einer Docker Swarm-Containerorchestrierungsplattform bereitzustellen.
Der vollständige Prozess der Ausführung von gP2S als Docker-Container, einschließlich aller Details zur richtigen Konfiguration, wird im gP2S GitHub-Repository beschrieben und behandelt die folgenden Themen:
• Ausführen der dockerisierten gP2S-Anwendung mit allen Abhängigkeiten.
• Zugriff auf die gP2S-Anwendung, Datenbank und LDAP.
• Aktualisierung des gP2S-Dienstes mit einer neuen Version.
• Entfernen der gP2S-Anwendung.
• Konfigurieren der Datenpersistenz.
• Verbinden der dockerisierten gP2S-Anwendung mit dedizierten Datenbanken oder einem LDAP-Server.
• Konfigurationsdetails
Eigenständige Java-Anwendung
Eine weitere Möglichkeit zum Ausführen der gP2S-Anwendung besteht darin, ein eigenständiges Java-Paket zu erstellen. Dieser Ansatz sollte gewählt werden, wenn das Ausführen von Docker-Containern nicht möglich ist. Das Erstellen der gP2S-Anwendung erfordert die Installation eines Java Development Kit Abversion 8 oder höher. Der gesamte Buildprozess wird vom Maven-Tool verwaltet, das in der Codebasis im GitHub-Repository bereitgestellt wird. Die Buildkonfiguration ist darauf vorbereitet, zuerst das Frontend-Teil zu erstellen, es dann in Back-End-Quellen zu kopieren und dann als endgültige Anwendung zu erstellen. Auf diese Weise müssen sie keine anderen Tools oder Bibliotheken installieren, um ein voll funktionsfähiges gP2S-Paket vorzubereiten. Standardmäßig ist das Ergebnis des Builds ein JAR-Paket (lokal gespeichert) und Docker-Image (in das Repository in der Maven pom.xml-Datei konfiguriert). Es ist wichtig, sich daran zu erinnern, dass Informationen, die zum Herstellen einer Verbindung mit externen Systemen (Datenbanken und LDAP-Server) erforderlich sind, in einer richtigen Konfigurationsdatei bereitgestellt werden müssen, bevor das Paket erstellt wird.
Nachdem das gP2S-JAR-Paket erstellt wurde, enthält es alle Abhängigkeiten und Konfigurationsinformationen, die zum Ausführen der Anwendung erforderlich sind, einschließlich des Tomcat-Anwendungsservers, auf dem das System gehostet wird. Wenn das Paket mit mehreren Konfigurationsdateien erstellt wurde, kann es in verschiedenen Modi ausgeführt werden, ohne neu zu erstellen.
Das gP2S GitHub-Repository enthält eine vollständige Beschreibung des Prozesses der Erstellung und Ausführung von gP2S als eigenständige Anwendung und behandelt die folgenden Themen:
• Erstellen von gP2S mit dem Maven-Tool
• Aufbau und Ausführung mit eingebetteten Datenbanken
• Erstellen und Ausführen mit Abhängigkeiten, die als Docker-Container bereitgestellt werden
• Aufbau und Betrieb mit dedizierten Datenbanken
• Konfigurieren der Authentifizierung
Bei ordnungsgemäßer und konsistenter Verwendung trägt gP2S dazu bei, eine ordnungsgemäße Aufzeichnung hochwertiger Metadaten zu erreichen, indem die Aufzeichnung kritischer experimenteller Metadaten mithilfe strukturierter Datenmodelle und definierter Vokabeln erzwungen wird, aber der Mehrwert davon wird erst dann voll realisiert, wenn ein hohes Maß an Compliance im Labor erreicht wird. Das obige Protokoll behandelt nicht, wie dies erreicht werden kann. Wir stellten fest, dass eine wirksame Durchsetzungstechnik darin bestand, dass Mikroskopbetreiber sich weigern, Daten über Netze zu sammeln, die nicht in gP2S registriert sind. Dies trieb die Compliance sehr schnell nach oben und legte den Grundstein für die Entstehung eines großen Korpus detaillierter und genauer experimenteller Details und des Firmengedächtnisses in den folgenden Monaten. Nach einigen Monaten der Nutzung wurde der Wert des Korpus der in gP2S gespeicherten Metadaten für die meisten Benutzer so offensichtlich, dass die Compliance ohne explizite Eingriffe hoch blieb.
Die vollständige Nutzung dieses kollektiven Speichers erfordert, dass die in gP2S gespeicherten Metadaten für externe Systeme zugänglich sind und leicht mit den experimentellen Daten (Mikrographen) und Ergebnissen (Karten und Modellen) verknüpft werden können. Das obige Protokoll beschreibt nicht, wie gP2S in andere Informatik- und Datenverarbeitungssysteme integriert werden kann. Am einfachsten sind mögliche Integrationen über die backend REST-API von gP2S, die keine Änderung von gP2S erfordern. Beispielsweise führt jeder Computer, der unsere Datenerfassungsdetektoren steuert, ein Skript aus, das regelmäßig den Endpunkt “getItemByMicroscope” von gP2S unter dem REST-Controller für die Mikroskopie-Sitzungsverwaltung abfragt, um zu überprüfen, ob eine Mikroskopiesitzung auf seinem Mikroskop läuft. Wenn dies der Fall ist, ruft das Skript aus gP2S den entsprechenden Datenspeicherverzeichnisnamen ab (wie auf der Seite Einstellungen konfiguriert, siehe oben), und erstellt ein Verzeichnis auf dem lokalen Datenspeichergerät unter diesem Namen. Dies gewährleistet eine systematische Benennung von Datenspeicherverzeichnissen und reduziert das Fehlerrisiko durch Tippfehler.
Obwohl sie in der Quelle der öffentlichen Version von gP2S auskommentiert wurden, sind weitere Integrationen mit gP2S, die Daten externer Systeme verbrauchen, ebenfalls möglich. In unserem Labor integriert unsere Bereitstellung von gP2S (i) ein Projektmanagementsystem, so dass jedes in gP2S konfigurierte Projekt mit einem unternehmensweiten Portfolioprojekt verknüpft werden kann und Metadaten aus dem Portfolio innerhalb von gP2S angezeigt werden können; ii) ein Proteinregistrierungssystem, so dass jedes dem gP2S zugesetzte Protein über einen lokal gespeicherten Identifikator mit einer vollständigen Reihe von Aufzeichnungen verbunden ist, die die Herkunft des Proteins beschreiben, Einzelheiten der einschlägigen Molekularbiologie, des Expressionssystems und der Reinigung enthalten; iii) ein System für das Management von kleinen Molekülen, das es gP2S ermöglicht, wichtige Informationen über jeden Liganden, wie z. B. seine chemische Struktur, anzuzeigen. Die zum Aktivieren dieser Integrationen erforderlichen Codeänderungen werden im Abschnitt “Integration” des README-BUILD.md Dokuments beschrieben, das im gP2S-Repository (https://github.com/arohou/gP2S) verfügbar ist.
Die aktuelle Version von gP2S hat Einschränkungen, darunter das zu vereinfachte Datenmodell und das Frontend für die Strukturabscheidung (Modell). Dies wurde absichtlich in einem “Barebones”-Zustand in der veröffentlichten Version von gP2S belassen, da eine vollwertige Strukturabscheidungs- und Validierungsfunktion derzeit zusammen mit der Unterstützung der Röntgenkristallographie entwickelt wird. Eine weitere Entwurfsentscheidung bestand darin, keine Berechtigungen oder Berechtigungssystem zu implementieren: Alle Benutzer in gP2S haben gleichen Zugriff auf seine Funktionen und Daten. Dies mag es zu einer schlechten Wahl für Einrichtungen machen, die Benutzergruppen mit konkurrierenden Interessen und Vertraulichkeitsanforderungen dienen, aber kein Anliegen für unsere Einrichtung war.
Die Entwicklung unserer internen Version von gP2S ist im Gange und es ist unsere Hoffnung, dass die hier beschriebene Open-Source-Version für andere kryoEM-Gruppen nützlich sein wird und dass einige Vorschläge oder Codeverbesserungen in der Zukunft beitragen können. Zukünftige hochwertige Entwicklungen könnten sich beispielsweise auf die Integration mit Laborgeräten (Vitrifizierungsroboter, Elektronenmikroskope), Software (z.B. zur Gewinnung von Bildverarbeitungsmetadaten) und externen öffentlichen Repositories (z. B. zur Erleichterung von Strukturablagerungen) konzentrieren.
Die systematische Erfassung hochwertiger Metadaten, die durch den routinemäßigen Einsatz von gP2S im Labor und in der KryoEM-Einrichtung ermöglicht werden, kann sich signifikant positiv auf die Fähigkeit auswirken, mehrere Projekte über einen Zeitraum von Jahren parallel zu verfolgen. Mit der Einrichtung von immer mehr gemeinsamen und zentralisierten KryoEM-Gruppen und -Einrichtungen gehen wir davon aus, dass der Bedarf an Informationsmanagementsystemen wie gP2S weiter steigen wird.
The authors have nothing to disclose.
Die Autoren danken allen anderen Mitgliedern des gP2S-Entwicklungsteams, die seit seiner Gründung an dem Projekt mitgearbeitet haben: Rafaa Udziela, Cezary Krzysanowski, Przemyslaw Stankowski, Jacek Ziemski, Piotr Suchcicki, Karolina Pajék, Ewout Vanden Eyden, Damian Mierzwiéski, Michaé Wojtkowski, Piotr Pikusa, Anna Surdacka, Kamil ‘uczak und Artur Kusak. Wir danken auch Raymond Ha und Claudio Ciferri für die Unterstützung bei der Zusammenstellung des Teams und der Gestaltung des Projekts.