gP2S هو تطبيق على شبكة الإنترنت لتتبع التجارب cryoEM. يتم وصف الميزات الرئيسية الخاصة به، وكذلك الخطوات المطلوبة لتثبيت وتكوين التطبيق. بمجرد تكوينه ، يسمح التطبيق لأحد بتسجيل البيانات الوصفية المرتبطة بدقة بالبقعة السلبية وتجارب cryoEM.
أصبح المجهر الإلكتروني المبرد (cryoEM) جزءا لا يتجزأ من العديد من مشاريع اكتشاف الأدوية لأن علم البلورات لهدف البروتين لا يمكن تحقيقه دائما ويوفر cryoEM وسيلة بديلة لدعم تصميم الليغند القائم على الهيكل. عند التعامل مع عدد كبير من المشاريع المتميزة ، وداخل كل مشروع عدد كبير من الهياكل المشتركة ليغاند البروتين ، وحفظ السجلات دقيقة يصبح بسرعة تحديا. يتم ضبط العديد من المعلمات التجريبية لكل هدف ، بما في ذلك في إعداد العينة ، وإعداد الشبكة ، ومراحل المجهر. لذلك، يمكن أن يكون حفظ السجلات الدقيقة أمرا بالغ الأهمية لتمكين إمكانية إعادة الإنتاج على المدى الطويل، وتسهيل العمل الجماعي الفعال، خاصة عندما يتم تنفيذ خطوات سير عمل cryoEM من قبل المشغلين المختلفين. للمساعدة في التعامل مع هذا التحدي، قمنا بتطوير نظام إدارة المعلومات على شبكة الإنترنت ل cryoEM، يسمى gP2S.
ويتتبع التطبيق كل تجربة، من عينة إلى نموذج ذري نهائي، في سياق المشاريع، التي يحتفظ بقائمة بها في التطبيق، أو خارجيا في نظام منفصل. تساعد المفردات التي يحددها المستخدم والمحددة من المواد الاستهلاكية والمعدات والبروتوكولات والبرامج في وصف كل خطوة من سير عمل cryoEM بطريقة منظمة. gP2S هو شكلي على نطاق واسع ، واعتمادا على احتياجات الفريق ، قد تكون موجودة كمنتج مستقل أو أن تكون جزءا من نظام بيئي أوسع من التطبيقات العلمية ، ودمج عن طريق واجهات برمجة التطبيقات REST مع أدوات إدارة المشاريع ، والتطبيقات تتبع إنتاج البروتينات أو من الجزيئات الصغيرة ligands ، أو التطبيقات أتمتة جمع البيانات وتخزينها. يمكن للمستخدمين تسجيل تفاصيل كل شبكة وجلسة المجهر بما في ذلك البيانات الوصفية التجريبية الرئيسية وقيم المعلمة ، ويتم تسجيل نسب كل قطعة أثرية تجريبية (عينة ، شبكة ، جلسة المجهر ، الخريطة ، إلخ). يعمل gP2S كمنظم سير عمل تجريبي cryoEM يتيح حفظ سجلات دقيقة للفرق ، وهو متاح بموجب ترخيص مفتوح المصدر.
إدارة المعلومات في مرافق cryoEM
بدءا من عام 2014 تقريبا ، ازداد عدد المجهر الإلكتروني المبرد (cryoEM)1 مرافق بشكل متفجر ، مع تركيب ما لا يقل عن 300 نظام عالي المستوى في جميع أنحاء العالم2، بما في ذلك عدد في شركات الأدوية ، مما يعكس دورا متزايدا ل cryoEM في اكتشاف الأدوية3. وتختلف بعثات هذه المرافق ومتطلباتها من أجل تتبع البيانات وإدارتها4. بعضها، على سبيل المثال مراكز cryoEM الوطنية، مكلفة بتلقي شبكات EM، وجمع مجموعات البيانات، وإعادة البيانات إلى المستخدمين لتحديد الهيكل، ربما بعد بعض المعالجة التلقائية للصور. وفي هذه المرافق، يعد تتبع مصدر الشبكة، وارتباطها باقتراح المستخدم أو المنحة، والنسب من الشبكة إلى مجموعة البيانات أمرا حاسما، ولكن هناك عوامل أخرى، مثل طريقة تنقية عينة البروتين أو عملية تحديد الهيكل في نهاية المطاف، أقل صلة أو لا تكون ذات صلة على الإطلاق. وفي مرافق أخرى، مثل المرافق الأكاديمية المحلية، يتحمل كل مستخدم النهائي مسؤولية إعداد عينات وشبكات خاصة به، وإجراء المجهر، وإدارة البيانات الأولية وتجهيزها ونشر النتائج. ولا توجد حاجة صارمة لتتبع البيانات الوصفية من جانب مرفق من هذا القبيل لأن هذا الدور يؤديه المستخدم النهائي أو المحقق الرئيسي.
في منشأة cryoEM لدينا ، يتم مركزية التعامل مع وتحسين العينات والشبكات وبروتوكولات جمع البيانات ومعالجتها ، والنتائج (الخرائط والنماذج) عبر العديد من المشاريع على مجموعة صغيرة من الممارسين. وهذا يطرح تحديات في إدارة البيانات التجريبية (الفوقية). يجب التقاط النسب التجريبي للهياكل ، من النموذج الذري على طول الطريق إلى الهوية الدقيقة للبروتينات والليجاند ، عبر معلمات إعداد الشبكة وبروتوكولات جمع البيانات ، بدقة والحفاظ عليها. ويجب إتاحة هذه البيانات الوصفية لعدد من المشغلين البشريين. فعلى سبيل المثال، قد يحتاج الشخص الذي يقوم بمعالجة الصور إلى معرفة أي بناء للبروتين قد استخدم وما هي معلمات التصوير، على الرغم من أنه لم ينقي البروتين ولم يجمع بيانات cryoEM بنفسه؛ تحتاج أنظمة المعلوماتية مثل برامج إدارة البيانات الآلية إلى تحديد المشروع الذي يقوم المجهر حاليا بجمع البيانات من أجل تعيين أسماء الدلائل بشكل صحيح ومنهجي.
تتوفر العديد من أنظمة إدارة المعلومات لدعم مرافق cryoEM. ولعل أكثرها اكتمالا هو EMEN25، الذي يجمع بين ميزات دفتر مختبر إلكتروني ، ونظام إدارة المعلومات ، وبعض عناصر أداة إدارة العمليات التجارية. تستخدم في العديد من السنكروترونات، ISPyB6،بنيت أصلا لدعم خطوط الأشعة السينية للبلورات، والآن يدعم أيضا جمع البيانات cryoEM. Scipion7 هو غلاف غني وقوي حول حزم معالجة الصور ، والذي يسمح للمستخدمين بتسجيل سير عمل معالجة الصور ومشاركتها ، على سبيل المثال عبر المستودع العام EMPIAR8،9، ويتم دمجه أيضا مع ISPyB لتمكين معالجة بيانات cryoEM على الطاير.
هنا نحن نصف gP2S (ل Genentech Protein to Structure) ، وهو نظام حديث وخفيف الوزن لإدارة المعلومات cryoEM تم بناؤه لدعم سير العمل من البروتين النقي والجزيئات الصغيرة إلى النموذج الذري النهائي.
نظرة عامة على gP2S
gP2S هو نظام إدارة معلومات cryoEM سهل الاستخدام على شبكة الإنترنت يسهل حفظ السجلات بدقة لمختبرات cryoEM والمرافق متعددة المستخدمين والمشاريع المتعددة. يتم تتبع الكيانات التالية وعلاقاتها والبيانات الوصفية المرتبطة بها: المشاريع والمعدات والمواد الاستهلاكية والبروتوكولات والعينات والشبكات وجلسات الفحص المجهري وجلسات معالجة الصور والخرائط والنماذج الذرية. يمكن للمستخدمين أيضا إضافة تعليقات النص الحر، بما في ذلك مرفقات الملفات اختياريا، مما يسمح بالتعليقات التوضيحية الغنية لأي كيان مسجل في gP2S. وقد تم تصميم الواجهة الأمامية لتسهيل الاستخدام مع أجهزة تعمل باللمس واختبارها على نطاق واسع على 12.9 “باد الايجابيات, مما يجعل من الممكن استخدام gP2S في مقاعد البدلاء مختبر أثناء إعداد العينات والشبكات (الشكل 1), وكذلك في الكمبيوتر عند تشغيل المجهر, معالجة الصور أو إيداع نماذج. تهدف كل صفحة في الواجهة الأمامية إلى تقليل إدخال البيانات اليدوية عن طريق إعداد المعلمات مسبقا إلى قيم افتراضية معقولة عندما يكون ذلك ممكنا.
الخلفية من gP2S ميزات عدد من REST API (REpresentational الدولة نقل واجهة برمجة التطبيقات) نقاط النهاية، مما يجعل من الممكن لدمج gP2S في سير العمل والبرامج النصية القائمة. تم تصميم نموذج البيانات للسماح بالتقاط دقيق للبقع السلبية وسير عمل cryoEM ، بما في ذلك التفريع ، على سبيل المثال مع عينة واحدة تستخدم على عدة شبكات ، أو دمج البيانات من عدة جلسات مجهرية في جلسة معالجة بيانات واحدة ، أو جلسة معالجة بيانات واحدة تسفر عن عدة خرائط.
بنية النظام
gP2S هو تطبيق كلاسيكي من ثلاث طبقات (الشكل 2). في هذه العمارة وحدات، يتم تقسيم النظام إلى ثلاث طبقات منفصلة، كل مسؤولة عن أداء واجبات متميزة، وكل قابلة للاستبدال أو قابل للتعديل بشكل مستقل عن الآخرين. (1) توفر طبقة العرض التقديمي (أو الواجهة الأمامية) وصول المستخدم عبر متصفح الويب (تم اختباره على نطاق واسع باستخدام Chrome و Safari) ، وتسمح بإنشاء وتعديل عناصر سير العمل (بما في ذلك التحقق من صحة البيانات) ، وتعرض البيانات التجريبية ككيانات فردية وقوائم قائمة على المشروع وتقارير سير العمل الكاملة. (2) طبقة الخدمة (أو الخلفية) بمثابة طبقة وسيطة بين واجهة المستخدم ونظام التخزين — أنه يحمل منطق الأعمال الأساسية ، ويعرض API الخدمة المستخدمة من قبل الواجهة الأمامية ، ويتكامل مع تخزين البيانات وLDAP (خفيفة الوزن دليل بروتوكول الوصول) نظام لمصادقة المستخدم ، ويوفر أساسا للتكامل إضافية مع النظم الخارجية. (3) طبقة الثبات (الوصول إلى البيانات) هي المسؤولة عن تخزين البيانات التجريبية وتعليقات المستخدمين ومرفقات الملفات.
التكنولوجيات والأطر الرئيسية
10- ولتيسير تطوير وبناء وصيانة تطبيق نظام gP2S، استخدمت عدة تكنولوجيات وأطر في المشروع. أهمها: Vue.js 2.4.210 للواجهة الأمامية و SpringBoot 1.311 مع خادم Tomcat 8 المضمن للواجهة الخلفية. يستخدم التطبيق الخلية 5.7 و MongoDB 4.0.6 قواعد البيانات للتخزين و LDAP12 للمصادقة. بشكل افتراضي، يتم شحن كافة أجزاء المكون هذه ونشرها كطبيق واحد.
في المجموع يستخدم التطبيق مئات المكتبات المختلفة إما بشكل مباشر أو غير مباشر. أبرزها مدرج في الجدول 1.
نموذج البيانات
يمكن تمييز ثلاثة أنواع من الكيانات في نموذج بيانات gP2S(الشكل 3):كيانات سير العمل المتعلقة بالبيانات التي تم جمعها أثناء التجارب (على سبيل المثال، العينات أو جلسات الفحص المجهري)؛ المعدات وكيانات البروتوكول التي تصف البيانات الشائعة في جميع المشاريع (مثل المجاهر أو بروتوكولات التزجيج)؛ الكيانات الأخرى التي تلعب أدوارا داعمة أو فنية في النظام (مثل التعليقات أو القيم الافتراضية).
جذر شجرة بيانات سير العمل هو كيان المشروع. كل مشروع يتكون من عدد من البروتينات و / أو Ligands التي هي لبنات البناء لإنشاء نماذج الكيانات. يمكن استخدام كل عينة لإنشاء شبكات متعددة والتي بدورها تستخدم في جلسات المجهر (شبكة واحدة لكل جلسة المجهر). يتم تعيين هذا الأخير إلى جلسات المعالجة التي يمكن أن تسفر عن واحد أو أكثر من الخرائط. آخر كيان في الشجرة هو النموذج الذري، الذي تم إنشاؤه باستخدام خريطة واحدة أو العديد من الخرائط. ونتيجة لذلك، فإن كل كيان مرتبط بسير العمل، من البروتين إلى النموذج، ملزم دائما بمشروع معين عبر أسلافه. هذا التصميم يخلق تجميع البيانات التي هي سهلة لمعالجة إما عن طريق وحدة الواجهة الأمامية أو من قبل أنظمة خارجية باستخدام API.
بالإضافة إلى بيانات سير العمل، هناك كيانات تصف المعدات المستخدمة في التجارب أو البروتوكولات التي تم اتباعها أثناء إعداد الشبكات. تعريف هذه الكيانات هو شرط أساسي لإنشاء كيانات سير العمل التجريبية مثل الشبكات، المجهر وجلسات المعالجة.
يستخدم آخر نوع من كيان البيانات، المسمى بشكل جماعي باسم “آخر”، لأغراض فنية (مثل مرفقات الملفات أو القيم الافتراضية). تتضمن هذه الفئة كيانات التعليق التي يمكن ربطها بأي كيان سير عمل أو معدات/بروتوكولات.
توفر البرامج
النسخة مفتوحة المصدر من gP2S متاحة بموجب إصدار ترخيص أباتشي 2.026، من https://github.com/arohou/gP2S. صورة Docker لتشغيل gP2S متوفرة من https://hub.docker.com/r/arohou/gp2s. فرع مغلق المصدر من gP2S قيد التطوير المستمر في روش وجينينتيك.
تشغيل تطبيق gP2S
هناك طريقتان لتشغيل gP2S: كحاوية docker أو كتطبيق Java مستقل. يعتمد الخيار الأمثل على بيئة النشر الهدف. على سبيل المثال، إذا كان المطلوب القدرة على تخصيص أو تحسين التعليمات البرمجية لتتناسب مع احتياجات محددة من المستخدمين، يجب إعادة بناء التطبيق بأكمله أولا. في هذه الحالة، قد يوصى بتشغيل gP2S كتطبيق مستقل.
حاوية دوكر
أسهل طريقة لبدء العمل مع تطبيق gP2S هو تشغيله كخدمة Docker. ولهذا الغرض، تم إعداد صورة دوكر مخصصة ونشرها في مستودع Docker Hub (“https://hub.docker.com/r/arohou/gp2s”). تشغيل الصورة gP2S يعتمد على الوصول إلى قواعد بيانات الخلية و MongoDB ، و إلى خادم LDAP. بالنسبة للبيئة غير الإنتاج، فمن المستحسن لتشغيل كافة هذه التبعيات ك تطبيقات Docker متعددة الحاويات مع تطبيق gP2S. لجعل هذا سلسا، تم إعداد ملف docker-compose (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) يتضمن جميع التكوينات اللازمة للبيئة النهائية وتوفيرها في مستودع gP2S GitHub (https://github.com/arohou/gP2S). الصور docker التالية هي التبعيات: الخلية27، mongodb28، apacheds29.
في التكوين الافتراضي، سيتم حذف كافة البيانات المخزنة، كل من الكيانات ومرفقات الملفات عند إزالة حاويات docker. من أجل الحفاظ على البيانات ، يجب استخدام وحدات تخزين docker ، أو يجب توصيل تطبيق gP2S بمثيلات قاعدة بيانات مخصصة (MySQL و MongoDB). حاوية خادم ApacheDS LDAP يأتي مع مستخدم مسؤول تم تكوينه مسبقا (كلمة المرور: secret). يجب استخدام بيانات الاعتماد هذه لتسجيل الدخول إلى تطبيق gP2S عند تشغيله كخدمة Docker. بالنسبة لبيئات الإنتاج، يمكن استخدام نفس ملف إنشاء docker لنشر gP2S (والحاويات الأخرى إذا لزم الأمر) كخدمات لمنصة تنسيق حاويات Docker Swarm.
يتم وصف العملية الكاملة لتشغيل gP2S كحاوية Docker ، بما في ذلك جميع التفاصيل المتعلقة بالتكوين المناسب في مستودع gP2S GitHub وتغطي الموضوعات التالية:
• تشغيل تطبيق gP2S dockerized مع جميع التبعيات.
• الوصول إلى تطبيق gP2S وقاعدة البيانات وLDAP.
• تحديث خدمة gP2S مع إصدار جديد.
• إزالة تطبيق gP2S.
• تكوين استمرار البيانات.
• توصيل تطبيق gP2S dockerized بقواعد بيانات مخصصة أو خادم LDAP.
• تفاصيل التكوين
تطبيق جافا مستقل
خيار آخر لتشغيل تطبيق gP2S هو بناء حزمة جافا مكتفية ذاتيا. يجب أن يتم اتباع هذا النهج إذا كان تشغيل حاويات Docker غير ممكن. بناء تطبيق gP2S يتطلب تثبيت جافا التنمية كيت الإصدار 8 أو أعلى. تتم إدارة عملية البناء بأكملها بواسطة أداة Maven ، والتي يتم توفيرها في قاعدة التعليمات البرمجية في مستودع GitHub. تكوين البنية هو على استعداد لبناء الجزء الأمامي أولا، ثم نسخه إلى مصادر الخلفية، ومن ثم بناء عليه كطبيق نهائي. بهذه الطريقة، ليست هناك حاجة لتثبيت أي أدوات أو مكتبات أخرى من أجل إعداد حزمة gP2S تعمل بشكل كامل. بشكل افتراضي، نتيجة البناء حزمة JAR (المخزنة محليا) وصورة Docker (دفع إلى المستودع المكون في ملف .xml مافن بوم). من المهم أن نتذكر أن المعلومات المطلوبة للاتصال بالأنظمة الخارجية (قواعد البيانات وخادم LDAP) يجب توفيرها في ملف تكوين مناسب قبل بناء الحزمة.
بمجرد إنشاء حزمة GP2S JAR، فإنه يحتوي على كافة التبعيات ومعلومات التكوين اللازمة لتشغيل التطبيق، بما في ذلك خادم تطبيق Tomcat الذي يستضيف النظام. إذا تم إنشاء الحزمة مع ملفات تكوين متعددة يمكن تشغيلها في أوضاع مختلفة دون إعادة إنشاء.
يتضمن مستودع gP2S GitHub وصفا كاملا لعملية بناء وتشغيل gP2S كتطبيق مستقل ويغطي الموضوعات التالية:
• بناء gP2S باستخدام أداة مافن
• بناء وتشغيل مع قواعد البيانات المضمنة
• بناء وتشغيل مع التبعيات المنتشرة كما حاويات دوكر
• بناء وتشغيل مع قواعد بيانات مخصصة
• تكوين المصادقة
عندما تستخدم بشكل صحيح وثابت، يساعد gP2S على تحقيق حفظ السجلات السليم للبيانات الوصفية عالية الجودة من خلال فرض تسجيل البيانات الوصفية التجريبية الحرجة باستخدام نماذج البيانات المنظمة والمفردات المحددة، ولكن القيمة المضافة لذلك تتحقق بالكامل فقط عندما يتم تحقيق مستوى عال من الامتثال في المختبر. البروتوكول أعلاه لا يغطي كيفية تحقيق ذلك. وجدنا أن تقنية الإنفاذ الفعالة هي أن يرفض مشغلو المجهر جمع البيانات عن الشبكات غير المسجلة في gP2S. وقد أدى ذلك إلى الامتثال بسرعة كبيرة و أرسى الأساس لظهور مجموعة كبيرة من التفاصيل التجريبية التفصيلية والدقيقة وذاكرة الشركات على مدى الأشهر التالية. بعد بضعة أشهر من الاستخدام، أصبحت قيمة مجموعة البيانات الوصفية المخزنة في gP2S واضحة جدا لمعظم المستخدمين بحيث ظل الامتثال مرتفعا دون تدخل صريح.
ويتطلب الاستفادة الكاملة من هذه الذاكرة الجماعية أن تكون البيانات الوصفية المخزنة في نظام gP2S في متناول النظم الخارجية وأن ترتبط بسهولة بالبيانات التجريبية (الصور الدقيقة) والنتائج (الخرائط والنماذج). لا يصف البروتوكول أعلاه كيفية دمج gP2S مع المعلوماتية الأخرى وأنظمة معالجة البيانات. الأكثر مباشرة هي عمليات التكامل المحتملة عبر واجهة برمجة التطبيقات REST الخلفية ل gP2S ، والتي لا تتطلب أي تعديل ل gP2S. على سبيل المثال، يقوم كل كمبيوتر يتحكم في كاشفات جمع البيانات لدينا بتشغيل برنامج نصي يستفسر دوريا عن نقطة النهاية ل gP2S “getItemByMicroscope” تحت وحدة تحكم إدارة جلسة الفحص المجهري REST، للتحقق مما إذا كانت جلسة الفحص المجهري جارية على مجهرها. إذا كان الأمر كذلك، البرنامج النصي باسترداد من gP2S اسم دليل تخزين البيانات المناسبة (كما تم تكوينه في صفحة الإعدادات، راجع أعلاه)، وإنشاء دليل على جهاز تخزين البيانات المحلية باستخدام هذا الاسم. وهذا يضمن التسمية المنهجية لدلائل تخزين البيانات ويقلل من خطر الخطأ بسبب الأخطاء المطبعية.
على الرغم من أنها قد علقت في مصدر النسخة العامة من gP2S، مزيد من التكامل التي تنطوي على gP2S تستهلك بيانات النظم الخارجية من الممكن أيضا. في مختبرنا ، يدمج نشر gP2S مع (1) نظام إدارة المشاريع ، بحيث يمكن ربط كل مشروع تم تكوينه في gP2S بمشروع محفظة على مستوى الشركة ، ويمكن عرض البيانات الوصفية من المحفظة ضمن gP2S ؛ ‘2’ نظام تسجيل البروتين، بحيث يرتبط كل بروتين يضاف إلى gP2S، عن طريق معرف مخزن محليا، بمجموعة كاملة من السجلات التي تفصل مصدر البروتين، وتشمل تفاصيل البيولوجيا الجزيئية ذات الصلة، ونظام التعبير والتنقية؛ ‘3’ نظام صغير لإدارة مركبات الجزيئات، يسمح لنظام GP2S بعرض المعلومات الرئيسية عن كل ليغند، مثل بنيته الكيميائية. يتم وصف تعديلات التعليمات البرمجية الضرورية لتمكين عمليات التكامل هذه في قسم “التكامل” من المستند README-BUILD.md المتوفر من مستودع gP2S (https://github.com/arohou/gP2S).
النسخة الحالية من gP2S له حدود، أولا من بينها نموذج البيانات التبسيط المفرط والواجهة الأمامية لترسب الهيكل (النموذجي). وقد ترك هذا عمدا في حالة “barebones” في النسخة الصادرة من gP2S لأن ترسب هيكل كامل وميزة التحقق من الصحة هي حاليا قيد التطوير جنبا إلى جنب مع دعم لبلورات الأشعة السينية. وكان قرار تصميم آخر عدم تنفيذ أي امتياز أو نظام إذن: جميع المستخدمين في gP2S لديهم حق الوصول على قدم المساواة إلى ميزاته والبيانات. قد يجعل هذا الخيار ضعيفا للمرافق التي تخدم مجموعات المستخدمين ذات المصالح المتنافسة ومتطلبات السرية ، ولكنه لم يكن مصدر قلق لمنشأتنا.
تطوير لدينا نسخة داخلية من gP2S مستمرة، ونأمل أن النسخة مفتوحة المصدر وصفها هنا سوف تكون مفيدة لمجموعات cryoEM أخرى، وأن البعض قد تسهم اقتراحات، أو تحسينات رمز في المستقبل. ويمكن أن تركز التطورات ذات القيمة العالية في المستقبل، على سبيل المثال، على التكامل مع معدات المختبرات (روبوتات التزجيج، المجاهر الإلكترونية)، والبرمجيات (مثل حصاد البيانات الوصفية لمعالجة الصور) والمستودعات العامة الخارجية (على سبيل المثال لتسهيل ترسبات الهياكل).
ويمكن أن يكون لجمع البيانات الوصفية عالية الجودة بشكل منهجي بفضل الاستخدام الروتيني ل gP2S في المختبر ومرفق cryoEM تأثير إيجابي كبير على القدرة على مقاضاة مشاريع متعددة بالتوازي على مدى سنوات. ومع إنشاء المزيد والمزيد من مجموعات ومرافق cryoEM المشتركة والمركزية، نتوقع أن تستمر الحاجة إلى أنظمة إدارة المعلومات مثل gP2S في النمو.
The authors have nothing to disclose.
يشكر المؤلفون جميع الأعضاء الآخرين في فريق تطوير gP2S الذين عملوا على المشروع منذ إنشائه: رافال أودزيلا، سيزاري كرزيانوفسكي، برزيميسلاف ستانكوفسكي، جاسيك زيمسكي، بيوتر سوشيسيكي، كارولينا باجاك، إيوت فاندن إيدن، داميان ميرزويينسكي، ميشال فويتكوفسكي، بيوتر بيكوسا، آنا سورداكا، كامل لوزاك، وأرتور كوساك. كما نشكر ريموند ها وكلاوديو سيفيري على المساعدة في تجميع الفريق وتشكيل المشروع.