أدت الزيادات في بيانات البحث وظهور العلوم المدفوعة بالبيانات إلى دفع المجتمع البحثي للبحث عن حلول لإدارة وأتمتة العمليات الحاسوبية المعقدة لضمان الكفاءة، وإمكانية التكرار، وقابلية التوسع، والتعاون، وشفافية الجودة المضمونة. سير العمل الحاسوبية هي نوع خاص من البرمجيات تستهدف بشكل خاص التعامل مع خطوط بيانات متعددة الخطوات، وتحليلات البيانات، وعمليات معالجة البيانات الأخرى، خاصة من خلال الاستخدام الفعال للموارد الحاسوبية لتحويل مدخلات البيانات إلى مخرجات مرغوبة.
مرافق القيادة الحاسوبية في أوك ريدج، مختبر أوك ريدج الوطني، أوك ريدج، تينيسي، الولايات المتحدة الأمريكية. قسم علوم الحاسوب، جامعة مانشستر، مانشستر، المملكة المتحدة. LAMSADE، PSL، جامعة باريس دوفين، باريس، فرنسا. قسم رياضيات الأنظمة المعقدة، قسم الحوسبة المرئية والمركزة على البيانات، مجموعة المعلوماتية الحيوية في الطب، معهد زوز (ZIB)، برلين، ألمانيا. علوم الأرض، مركز برشلونة للحوسبة الفائقة، برشلونة، إسبانيا. أرشيف الجينوم البشري الألماني (GHGA، W620)، مركز أبحاث السرطان الألماني (DKFZ)، هايدلبرغ، ألمانيا. مجموعة هندسة الأنطولوجيا، جامعة بوليتكنيك مدريد، مدريد، إسبانيا. BioCommons الأسترالية، جامعة ملبورن، ملبورن، فيكتوريا، أستراليا. علم الأمراض السريرية، مركز أبحاث السرطان بجامعة ملبورن (UMCCR)، باركفيل، فيكتوريا، أستراليا. المعلوماتية الحيوية وعلم الأورام الحاسوبية (الخوارزميات المعلوماتية الحيوية في علم الأورام)، معهد الذكاء الاصطناعي في الطب (IKIM)، جامعة الطب في إيسن، جامعة دويسبورغ-إيسن، إيسن، ألمانيا. قسم إدارة البيانات، مركز المناخ الألماني (Deutsches Klimarechenzentrum GmbH)، هامبورغ، ألمانيا. مركز أبحاث الحوسبة، مختبرات سانديا الوطنية، ألبوكيركي، نيو مكسيكو، الولايات المتحدة الأمريكية. سوبر كمبيوتر سيلفردرافت، بويز، أيداهو، الولايات المتحدة الأمريكية. معهد المعلوماتية، جامعة أمستردام، أمستردام، هولندا. معهد إيرلهام، نورويتش، المملكة المتحدة. مركز علوم المعلومات الجغرافية والأنظمة، قسم الجغرافيا وعلوم المعلومات الجغرافية، جامعة جورج ميسون، فيرفاكس، فيرجينيا، الولايات المتحدة الأمريكية. مجموعة المعلوماتية الحيوية، جامعة ريجا سترادينس، ريجا، لاتفيا. مدرسة الطب السريري، جامعة نيو ساوث ويلز، كنسينغتون، نيو ساوث ويلز، أستراليا. معهد أونتاريو لأبحاث السرطان، تورونتو، أونتاريو، كندا. البريد الإلكتروني: wilkinsonsr@ornl.gov

سير العمل الحاسوبية هي برمجيات تتميز بخصيصتين بارزتين: (i) التركيب (عدد المكونات، الترتيب، الهيكل) لعدة مكونات تشمل برمجيات أخرى، وسير العمل، وقطع الشيفرة، والأدوات، والخدمات؛ و(ii) التجريد الصريح من آليات التشغيل في شكل ما من لغة سير العمل عالية المستوى التي تحدد بدقة تدفق البيانات بين المكونات، معتمدة على نظام إدارة مخصص يهتم بمعالجة البيانات وتنفيذ الشيفرة. توضح البيانات الوصفية التبعيات والمتطلبات الحاسوبية، بما في ذلك تلك الخاصة بالبيئة الحاسوبية. .

في أبسط نهاية طيف التعقيد، قد تتكون لغة سير العمل من نص (مثل Bash، Python، R) أو مراحل معدودة في دفتر أبحاث إلكتروني (مثل Jupyter، RStudio، Apache Zeppelin، إلخ) مع مجموعة من التعليمات التي تستخدم المدخلات والمخرجات لتمرير النتائج معًا. في الطرف الآخر، قد تستخدم سير العمل نظام إدارة سير العمل (WMS) مثل Nextflow , Galaxy , Snakemake , أو Parsl . يمكن أن يوفر استخدام WMS عددًا من الفوائد بما في ذلك التجريد، والتوسع، والأتمتة، وإمكانية التكرار , وبيانات الأصل . عادةً ما يسهل WMS كامل الميزات معالجة الأخطاء وإعادة التشغيل، وتخزين البيانات تلقائيًا، وتسجيل البيانات الأصلية، والتعامل مع مجموعات البيانات الكبيرة والحسابات المعقدة، وتخصيص المهام والموارد، وتنفيذ المهام الموزعة للتوسع عبر محطات العمل المحلية، أو موارد السحابة، أو مجموعات الحوسبة عالية الأداء. تساعد أنظمة WMS والمكونات البرمجية الحاوية المودولية (مثل Docker، Singularity) في قابلية النقل وإمكانية التكرار، لكنها تواجه أيضًا تحديات (مثل مشكلات الأمان عند نشرها في المجموعات، ومنحنى التعلم الحاد، إلخ). في الممارسة العملية، يستخدم الباحثون مزيجًا من التقنيات من جميع أنحاء الطيف، مثل ربط النصوص من WMS التي يتم إطلاقها بدورها من دفتر ملاحظات.

سير العمل هي كائنات رقمية معقدة تحتوي على علاقات داخلية وبين كائنات تربط سير العمل بالكامل، وتعريفه، ونطاقه. للمساعدة في توضيح مناقشتنا حول FAIR، نقدم بعض التعريفات مع توضيح في الشكل 1.

سير العمل هو المواصفة الرسمية لتدفق البيانات والتحكم في التنفيذ بين المكونات القابلة للتنفيذ، ومجموعات البيانات المتوقعة، وملفات المعلمات. يمكن أن يتكون تعقيده، ويمكن تجريد العملية العامة بعيدًا عن تنفيذها. تشغيل سير العمل هو تجسيد لسير العمل مع المدخلات (ملفات المعلمات، مجموعات البيانات المدخلة) والمخرجات (بيانات المخرجات، سجل تنفيذ البيانات الأصلية وسلالة منتجات البيانات).

يمكن أن تكون مكون سير العمل قابلة للتنفيذ وبيانات. تشمل القابلة للتنفيذ النصوص، والشيفرة، والأدوات، والحاويات، أو سير العمل نفسها التي يتم تنفيذها عن بُعد أو محليًا، وداخلية أو طرف ثالث؛ يمكن أن تكون مكون البيانات مثالاً لمجموعة بيانات مرجعية. بالنسبة لمواصفة سير العمل، تشمل البيانات البيانات الوصفية (مثل وصفها)، والصور الرسومية، ومجموعات البيانات التجريبية والمعيارية، والقيم الافتراضية للمعلمات، وما إلى ذلك. بالنسبة لتشغيل سير العمل، تمتد البيانات إلى مجموعات البيانات المدخلة والمخرجة الفعلية، وملفات المعلمات، وسجل الأصل الذي يوضح تشغيل الشيفرة وسلالة منتجات البيانات.

نظام إدارة سير العمل يتعامل مع تدفق البيانات و/أو التحكم في التنفيذ ويقوم بالعمل الشاق للتعامل مع البيانات والحسابات. يقوم نظام إدارة سير العمل بتجريد سير العمل من البنية التحتية الرقمية الأساسية، مما يدعم قابلية التوسع، والنقل، والاختلافات في بنى الأجهزة.

تسارعت استخدامات سير العمل في السنوات القليلة الماضية. وجود أكثر من 350 نظام إدارة سير عمل مختلف بمستويات نضج متفاوتة يدل على تزايد شعبية سير العمل (https://s.apache. org/existing-workflow-systems). تساعد سير العمل في تقليل عبء الجهد البشري اليدوي من خلال أتمتة المهام المتكررة والتي تستغرق وقتًا طويلاً. تتيح هذه الأتمتة الكفاءة من حيث تخصيص الموارد من خلال السماح للبشر بالعودة إلى المهام التي تتطلب البشر فقط والسماح للمهام الحاسوبية بالاستفادة من الفرص للتحسينات التلقائية. كما تقوم سير العمل بأتمتة العمليات الحرجة التي تتطلب التوحيد وزيادة القابلية للتكرار، مما يحسن الكفاءة من خلال إزالة البشر من العملية التحليلية، وفي بعض الأحيان يتخلص من الحاجة إلى الإدارة اليدوية لتدفق البيانات عبر مجموعة من خطوات المعالجة، ويقلل من الحاجة إلى التحليلات المتكررة بسبب الأخطاء البشرية و/أو التحيز. علاوة على ذلك، تضمن الأتمتة إمكانية تكرار التجارب الحاسوبية. كما توفر سير العمل سجلًا موثقًا للعمليات الحاسوبية، مما يساعد في فهم ومراجعة وتدقيق تلك العمليات. نظرًا لأن النشاط العلمي غالبًا ما يتضمن استكشاف تباين التحليل، فإن تعديل سير العمل لفهم التأثيرات والتغييرات على منتجات البيانات يكون أسهل عندما يتم وصف تلك السير بوضوح وقابلية للمقارنة. يمكن للباحثين إعادة استخدام سير العمل لإعادة تحليلها والتكيف مع دمج طرق وأدوات أو مصادر بيانات جديدة. يدعم مشاركة وإعادة استخدام سير العمل التعاون بين الفرق ويعمل على توحيد العمليات وطرق التحليل. .

تهدف مبادئ قابلية الاكتشاف، والوصول، والتشغيل البيني، وإعادة الاستخدام (FAIR) إلى تعظيم قيمة وتأثير الكائنات الرقمية العلمية. لا يمكن إعادة استخدام هذه الكائنات إذا لم يكن بالإمكان العثور عليها أو الوصول إليها أو فهمها؛ ولا يمكن دمجها إذا لم تكن قابلة للتشغيل البيني. تركز إرشادات FAIR للبيانات العلمية على جعل البيانات قابلة للاكتشاف من خلال توفير البيانات الوصفية، وتعيين معرفات فريدة ودائمة، وضمان الوصول من خلال آليات الوصول المفتوح أو الوصول المقيد، وتعزيز التشغيل البيني من خلال تنسيقات موحدة ومخططات بيانات وصفية، وتمكين إعادة الاستخدام من خلال تراخيص واضحة ووثائق. توصي مبادئ FAIR لبرامج البحث (FAIR4RS) بجعل البرمجيات قابلة للاكتشاف من خلال المستودعات والسجلات، وضمان الوصول من خلال الترخيص المفتوح والوثائق، وتعزيز التشغيل البيني من خلال التوحيد والتوافق مع أدوات أخرى، وتمكين إعادة الاستخدام من خلال إصدار النسخ ووثائق واضحة للوظائف والاعتمادات. لقد كان لهذه المبادئ تأثير كبير على السياسات والنشر، وقد تم تبنيها من قبل القطاعين العام والخاص بالإضافة إلى ظهور صناعة من المشاريع، وبرامج البحث، والأعمال التجارية. .

تعرف FAIR4RS برامج البحث بأنها “ملفات كود المصدر، والخوارزميات، والبرامج النصية، وسير العمل الحاسوبية، والبرامج التنفيذية التي تم إنشاؤها خلال عملية البحث أو لغرض بحثي”. تعتبر سير العمل نوعًا محددًا من البرمجيات حيث يجب أن يكون إعادة الاستخدام والتعديل جزءًا من تركيبها المعياري من الكود وسير العمل الفرعية مع تدفق بيانات وتحكم محدد بوضوح. يمكن تنظيم تركيب سير العمل على مستويات من الدقة (مثل الوظائف، والمهام، والمراحل، والأنابيب)، على سبيل المثال مشابهة للمكتبات في مجموعة البرمجيات. قد يكون تنفيذ سلسلة من الأكواد الحاسوبية صعبًا للتوحيد والمشاركة عبر بيئات البحث المختلفة، ولكل منها مجموعة من الاعتمادات والمتطلبات الخاصة بها، مما قد يعقد عملية ضمان شمولية FAIR. . تساعد أتمتة التجارب العلمية باستخدام سير العمل في التخفيف من هذه المشكلة. تتمثل إحدى الخصائص الرئيسية في فصل مواصفات سير العمل عن تنفيذه؛ وصف العملية هو شكل من أشكال طريقة وصف البيانات. . عادةً ما يتم تصميم سير العمل التي تهتم بشكل أساسي بمعالجة وإنشاء البيانات لتكون مرتبطة ارتباطًا وثيقًا ببياناتها، بما في ذلك بيانات الاختبار وتاريخ سلالة البيانات لمنتجات البيانات. لذلك، تلعب سير العمل دورًا مهمًا في ضمان أن منتجات البيانات التي تستخدمها وتنتجها هي FAIR.

استنادًا إلى الأعمال السابقة , قامت مجموعة العمل الخاصة بسير العمل الحاسوبية FAIR (WCI-FW) بوضع خطة لتطبيق مبادئ FAIR على سير العمل الحاسوبية بشكل منهجي. WCI-FW هي مجموعة مفتوحة ومتنوعة ومتعددة التخصصات من محترفي أنظمة سير العمل ومستخدمي ومؤلفي سير العمل الذين يجتمعون عبر الإنترنت كل أسبوعين. تتكون المجموعة من خبراء من 40 منظمة من 13 دولة متخصصة في مجالات متنوعة، بما في ذلك المعلوماتية الحيوية، وعلوم المناخ، وعلوم البيانات، وعلوم الأرض، وهندسة البرمجيات، وإدارة سير العمل. سمحت هذه التنوع في الخلفيات والخبرات لنا بالاقتراب من المهمة من زوايا متعددة، مما يضمن أن تكون مبادئ FAIR لسير العمل الحاسوبية عملية ومقبولة على نطاق واسع لتعزيز إعادة الاستخدام والموثوقية وتأثير سير العمل الحاسوبية عبر مجالات البحث المتنوعة.

ناقشت مجموعة WCI-FW لعدة أشهر ما إذا كان يجب تحديد مجموعة جديدة ومخصصة من المبادئ لسير العمل الحاسوبية أو تطبيق المبادئ المعمول بها للبيانات والبرمجيات. توصلنا إلى استنتاج أننا سنطبق مباشرة المبادئ الخاصة بالبيانات والبرمجيات FAIR بعد أن أدركنا أن (أ) كنا نطور بشكل طبيعي تباينات لهذه المبادئ المعمول بها لأن (ب) سير العمل هي شكل هجين من البرمجيات، مرتبطة ارتباطًا وثيقًا بالبيانات وتمتلك حتى خصائص شبيهة بالبيانات. . من خلال البناء على الإطار المعمول به FAIR، حافظنا على التناسق وسمحنا للممارسات الخاصة بسير العمل بالاندماج بسلاسة مع الممارسات الحالية للبيانات والبرمجيات.

ظهرت عدة أسئلة محورية خلال مناقشات مجموعتنا:

الجدول 1 يلخص نتائجنا مع مزيد من المناقشة أدناه. باختصار، تعني القابلية للاكتشاف أن سير العمل والبيانات الوصفية المرتبطة به سهلة لكل من البشر والآلات للعثور عليها. تعني القابلية للوصول أن سير العمل وبياناته الوصفية يمكن استرجاعها عبر بروتوكولات موحدة. تعني القابلية للتشغيل المتداخل أن سير العمل يتفاعل مع سير العمل الآخر، وأن مكونات سير العمل تتفاعل، من خلال تبادل البيانات و/أو البيانات الوصفية، و/أو من خلال التفاعل عبر واجهات برمجة التطبيقات، كما هو موصوف بواسطة المعايير. أخيرًا، تعني القابلية لإعادة الاستخدام أن سير العمل قابل للاستخدام (يمكن تنفيذه) وقابل لإعادة الاستخدام (يمكن فهمه، وتعديله، والبناء عليه، أو دمجه في سير عمل آخر).

قابلية الاكتشاف. تنطبق مبادئ البيانات والبرمجيات عمومًا على سير العمل، ولكن مع اعتبارات جديدة/إضافية حول تفسيرنا لمكون معين وتعزيز البيانات الوصفية المرتبطة بإصدارات سير العمل. تخضع سير العمل لتحسين مستمر وتعديل مستقل، مما يؤدي غالبًا إلى وجود إصدارات متعددة وتعديلات ونسخ، حيث يتم توسيع سير العمل وتداخله وإعادة استخدامه كأجزاء فرعية. يقوم الباحثون بتعديل سير العمل لأغراض محددة، وضبط المكونات، وتقديم طرق بديلة عبر منصات مختلفة؛ يتم نسخ المكونات ولصقها وتعديلها.

تعتبر المعرفات مهمة لأنه على عكس البرمجيات، غالبًا ما يهمل المؤلفون “تسمية” سير العمل الخاصة بهم (على الرغم من أنهم يقومون بتسمية أنظمة إدارة سير العمل الخاصة بهم). تؤسس المعرفات سلالة واضحة لكل سير عمل وأصل المكونات والتغييرات، مما يمكّن الباحثين من فهم هيكل سير العمل وتطوره، ومقارنة النسخ، وربط سير العمل ببعضها البعض، والبناء بثقة على الأعمال السابقة. تحدد المعرفات المستمرة وتُشير إلى إصدارات محددة لضمان التعرف الدقيق وقابلية التتبع ودعم اقتباس المطور ونسب سير العمل المصدر (F1). تعترف المعرفات الفريدة للإصدارات المختلفة من سير العمل بطبيعتها الديناميكية في البحث (F1.2). تدعم المعرفات الفريدة لمكونات سير العمل وإصداراته (سواء كانت ملفًا، أو خطوة حسابية، أو سير عمل فرعي) قابلية التتبع وتسهّل إعادة الاستخدام، وإعادة الإنتاج، وقابلية النقل عبر إصدارات سير العمل المختلفة (F1.1).

يجب أن تستخدم البيانات الوصفية الغنية لعمليات العمل العامة ومكوناتها (بما في ذلك المدخلات والمخرجات) لغة رسمية وميسرة لتمثيل المعرفة، مثلschema.org (https://schema.org) وبيانات التعريف الموحدة مثل Bioschemasschema.orgملف تعريف لعمليات الحوسبة (https:// bioschemas.org/types/ComputationalWorkflow/التي تُستخدم لمكونات سير العمل في ملف تعريف تشغيل سير العمل وكود ميتا (https://w3id.org/codemeta/v3.0“). تشمل أشكال البيانات الوصفية الأخرى لعمليات العمل لغات “روزيطا” القياسية (مثل CWL ، WDL ) التي تستخلص من لغة سير العمل الأصلية من أجل زيادة القابلية للنقل والمقارنة. تُستخدم هذه البيانات الوصفية للتسجيل والبحث في سجلات سير العمل المخصصة والموثوقة مثل WorkflowHub ودوكستور (F4) .

الوصول. تنطبق مبادئ البيانات والبرمجيات بشكل عام ولكن مع اعتبارات جديدة حول ما يعنيه أن يكون سير العمل متاحًا. قد يكون سير العمل مقيدًا بالتنفيذ في منشأة واحدة، وهو حالة شائعة في إعدادات الحوسبة عالية الأداء المحسّنة للغاية، وقد يكون الوصول إلى تلك المنشأة مقيدًا (A1.2). يتطلب تسجيل الدخول الموحد لمكونات سير العمل وجود بنية تحتية متناسقة للمصادقة والتفويض (AAI) تنتشر عبر المهام المختلفة، إذا كانت مستضافة من قبل مزودي خدمات مختلفين. “A2. البيانات الوصفية متاحة، حتى عندما لم يعد سير العمل متاحًا” يتطلب مزيدًا من التفسير نظرًا للطبيعة المزدوجة لسير العمل كوصف عملية (بيانات) وتنفيذ عملية (برمجيات)، ويجب أن نفهم ما يعنيه “لم يعد متاحًا”. كقطعة من البرمجيات، قد تصبح منصة تنفيذ سير العمل أو البنية التحتية التي تعمل عليها قديمة و/أو غير متاحة. الاعتماد على كود المكونات والخدمات يجعل سير العمل عرضة لـ “تآكل البرمجيات”، وليس دائمًا من الممكن حاوية جميع الأكواد والحفاظ عليها بالكامل، مثلما يحدث عندما تكون أدوات طرف ثالث تُنفذ عن بُعد أو استدعاءات لمجموعات بيانات عبر الإنترنت. .

كنموذج لوصف العملية، يلتقط سير العمل كلاً من الخطوات وتدفق البيانات لوصفة لطريقة، والتي هي شكل من أشكال “البيانات الوصفية”. وبالتالي، يجب الحفاظ على وصف سير العمل ومكوناته، وإذا كان ذلك ذا صلة، مكونات تشغيل سير العمل، وأرشفتها في سجل أو مستودع طويل الأمد، حتى إذا لم يعد سير العمل قابلاً للتنفيذ، سيظل قابلاً للقراءة. إذا قمنا بتفسير ملف وصف سير العمل كبيانات، فإن مبادئ البيانات تقضي بأنه يجب أن تكون البيانات الوصفية لذلك الملف قابلة للاسترجاع. ومع ذلك، بالنسبة لسير العمل، فإن ملف البيانات هذا هو جوهر سير العمل. نحن نعتبر وصف سير العمل شكلاً من أشكال البيانات الوصفية للبرمجيات، وبالتالي، يجب أن يكون دائماً متاحاً. قد يظل سير العمل المرتبط بنشر ما

تم فحصه كطريقة، ويمكن فحص أصله؛ يجب أن تكون الوصف كافيًا ليتم ترجمته لنظام سير عمل آخر. بخلاف النقل اليدوي أو المدعوم بالذكاء الاصطناعي للكود، يمكن أن يحدث هذا أيضًا عبر لغات سير العمل “روستّا” مثل CWL وWDL (كما تم القيام به في MGnify). وبواسطة تصدير CWL من Snakemake).

التشغيل البيني. تتداخل مبادئ البيانات والبرمجيات مع مبادئ القابلية لإعادة الاستخدام، بينما نفصل متطلبات FAIR لعملية العمل، ومكوناتها (سواء كانت قابلة للتنفيذ أو بيانات)، وتشغيل مُثبّت ومُنفّذ لعملية العمل. على سبيل المثال، ينطبق المبدأ Il على وصف الهيكل الثابت لعملية العمل في المواصفة والتقاط الجوانب الديناميكية للتشغيل مثل تفاصيل التنفيذ والمخرجات الوسيطة. تلعب مواصفة عملية العمل دورًا في البيانات في I1 وI2 وI4 من خلال تكييف مبادئ البيانات، بالإضافة إلى دور البيانات الوصفية للبرمجيات، مما يدمج مبادئ البرمجيات.

نقوم بتكييف مبادئ البرمجيات لـ I3 و I4 للإشارة بشكل صريح إلى الوصف القياسي للمجال للمدخلات والمخرجات لمكونات سير العمل القابلة للتنفيذ. كعناصر بيانات في سير العمل، يجب أن تلتزم مجموعات البيانات المدخلة والمخرجة المتوقعة، والمعايير، والمعلمات، وملفات البيانات والمعلمات الفعلية من تشغيل سير العمل، أيضًا بالمعايير المجتمعية (مبدأ البيانات R1.3)، كما يجب أن تلتزم البيانات الوسيطة المستمدة خلال التنفيذ. تشجع المبادئ على قابلية نقل سير العمل عبر أنواع مختلفة من البيئات الحاسوبية (على سبيل المثال، من خلال الحاويات أو إدارة الحزم المستقلة عن نظام التشغيل). ومن المثالي أيضًا أن يكون هناك ترجمة سهلة من لغة/نظام إدارة إلى آخر، أو على الأقل التوافق والتكامل السلس (في حالة العمليات الفرعية).

تشجع تنسيقات اللغة القياسية مثل CWL على التوافق وتوفر إمكانية مقارنة وتبادل سير العمل بين لغات مختلفة من خلال توثيق المكونات والمدخلات والمخرجات. نحن نضيف بشكل صريح أصل تشغيل سير العمل إلى التوافق حيث أن خطوات التنفيذ الموثقة وآثار سلالة البيانات هي مكونات مهمة يجب أن تكون قابلة للتشغيل البيني وقابلة للتنفيذ بواسطة الآلات. .

إعادة الاستخدام. يُعتبر إعادة استخدام سير العمل كطريقة قابلة للتنفيذ مع تعديلات على معاييره وملفات الإدخال استخدامًا متوقعًا ومترقبًا لسير العمل، مرتبطًا بجودة توثيقه وإمكانية الوصول إلى البنية التحتية الحاسوبية القادرة على تنفيذه.

بينما ناقشنا سابقًا قابلية الاكتشاف، أشرنا أيضًا إلى قابلية إعادة استخدام سير العمل كتركيبات معقدة تهدف إلى التعديل والبناء عليها ودمجها في سير عمل أخرى، بالإضافة إلى قابليتها لإعادة الاستخدام كتنفيذات قابلة للتشغيل مع مجموعات بيانات وملفات معلمات معدلة. تم تعديل مبادئ البيانات والبرمجيات لتسليط الضوء على الطبيعة المركبة لعمليات العمل (كلا من المكونات القابلة للتنفيذ ومكونات البيانات) من أجل الترخيص. تتكون سير العمل من العديد من الأجزاء، وقد تكون من مؤلفين مختلفين لديهم نوايا مختلفة بشأن كيفية استخدام أعمالهم؛ يجب أن تكون هذه النوايا واضحة من خلال تضمين تراخيص تغطي جميع أجزاء سير العمل والأجزاء الفرعية من سير العمل التي يمكن إعادة استخدامها كسير عمل فرعية. .

تاريخ أصل سير العمل – مؤلفوه، غرضه، سير العمل التي قد يكون أحد أشكالها، الروابط إلى سير العمل الفرعية الأخرى، وما إلى ذلك، مدرجة في R1.3 مستمدة من كل من بيانات ومبادئ البرمجيات R1.2. إن أصل منتجات البيانات التي تتعقبها مجموعة أصل تشغيل سير العمل مرتبط بالبيانات.
المبادئ R1.2 حيث يتم ربط البيانات (في هذه الحالة منتجات سير العمل) بأصل مفصل يجب أن يكون نظام سير العمل قادرًا على توفيره. إحدى فوائد استخدام أنظمة سير العمل المتكاملة هي التقاط الأصل (البيانات الوصفية) القابلة للتفسير بواسطة الكمبيوتر لتتبع تاريخ وأصل خطوات معالجة البيانات. تتوقع R1 و R3 أن تكون مجموعات البيانات المدخلة والمخرجة موصوفة بدقة مع بيانات مدخلة نموذجية وبيانات مخرجة متوقعة لكل خطوة تتوافق مع معايير هيكل البيانات وتنسيق الملفات. ومعايير الذهب للمقارنة .

هنا، نقدم أمثلة ملموسة مع أوصاف مفصلة لتطبيق مبادئ FAIR على كل من مواصفات سير العمل وتشغيلات سير العمل. في كل حالة، نروي من خلال مبادئ FAIR بشكل متسلسل. نوصي القارئ بمتابعة الجدول 1 كدليل.

مثال على مواصفات سير العمل. يقوم سير عمل إعداد ديناميكا الجزيئات للبروتين بإعداد محاكاة ديناميكية جزيئية للبروتين تعيد هيكل البروتين ومسارات ثلاثية الأبعاد محاكاة. . إنه مسجل في WorkflowHub (https://doi.org/10.48546/workflowhub.workflow.29.3)، حيث تم تعيين معرف كائن رقمي (DOI) له وهو فريد عالميًا (F1). يمكن تحديد إصدارات مختلفة من هذا سير العمل باستخدام معرفات كائن رقمي فريدة (F1.2). يتم وصف سير العمل باستخدام بيانات وصفية (غنية) (F2) تتضمن معرف سير العمل وإصداره الفريد (F3). يتم تسجيل سير العمل والبيانات الوصفية المرتبطة به (F4). علاوة على ذلك، تحتوي مكونات سير العمل على معرفات دائمة فردية خاصة بها حيث يتكون سير العمل من كتل بناء فرعية من مكتبة BioBB (https://workflowhub.eu/projects/11) (F1.2). يمكن استرجاع مكونات سير العمل وتنزيلها باستخدام بروتوكول HTTPS موحد (A1، A1.1، A1.2). البيانات الوصفية المرتبطة بسير العمل ومكوناته مستقلة عن مستودع كود GitHub ويمكن الوصول إليها على WorkflowHub حتى إذا أصبح سير العمل (أو مكوناته) غير متاحة (A2).

تم كتابة إعداد بروتين MD باستخدام CWL الذي يتبع نموذجًا رسميًا وتقريريًا لتنفيذ سير العمل (I1). لا يتضمن سير العمل جميع مبادئ الممارسات الجيدة لتحقيق I2 و I3. يمتد هذا إلى بيانات التعريف الخاصة بسير العمل، التي لا تستخدم أنطولوجيا محددة المجال. يتضمن سير العمل وبيانات التعريف الخاصة به مراجع مؤهلة لأشياء ومكونات أخرى (I4). ومع ذلك، فإن معيار CWL نفسه يسمح ببيانات التعريف ومفردات سير العمل (مثل Bioschemas، EDAM). التي تتماشى مع مبادئ FAIR (I2)، تمكّن مكونات سير العمل من قراءة وكتابة وتبادل البيانات باستخدام تنسيق يتوافق مع المعايير الخاصة بالمجال (I3)، وتخصص مراجع مؤهلة لمكونات سير العمل والمدخلات والمخرجات.

تم إصدار سير العمل بموجب ترخيص البرمجيات Apache License 2.0 (R1.1) ويشير RO-Crate الخاص بـ WorkflowHub إلى أن كود CWL المدمج مؤرشف من مستودع كود المصدر المقابل على GitHub.https://github.com/bioexcel/biobb-wf-md-setup-protein-cwl). تحتوي مكونات BioBB لبنات البناء الخاصة بسير العمل على تراخيص واضحة ومتاحة (R1.2). يرتبط سير العمل بمعلومات مفصلة عن أصله وتطوره، مقدمة ككائن RO-Crate قابل للتنزيل (R1.3).

تشغيل مثال سير العمل. هنا، نوضح تطبيق مبادئ FAIR على تشغيل سير العمل. تذكر من تعريفاتنا السابقة أن تشغيل سير العمل هو تجسيد لسير العمل مع المدخلات (ملفات المعلمات، مجموعات البيانات المدخلة) والمخرجات (بيانات المخرجات، سجل تنفيذ النسب وسلسلة بيانات المنتجات). في هذا المثال، يتم تجسيد تشغيل سير العمل من مواصفة سير عمل توقع الأنسجة/الأورام لعلم الأمراض الرقمي، ويتم تمثيله باستخدام RO-Crate. .

تم تعيين رقم DOI فريد عالميًا لتشغيل سير العمل (F1)، كما تم تعيين مكونات تشغيل سير العمل (مثل الخطوات، المدخلات، المخرجات) مع معرّفات مميزة خاصة بها (F1.1). يتم وصف تشغيل سير العمل باستخدام بيانات وصفية غنية (F2) تتضمن معرّف تشغيل سير العمل وإصداره الفريد (F3). لم يتم تسجيل مواصفة سير العمل المقابلة، لكنها متاحة للجمهور عبر GitHub.https://github.com/crs4/تم تسجيل تشغيل سير العمل على Zenodo، وهو مورد FAIR قابل للبحث (F4).

يتم استضافة تشغيل سير العمل ومكوناته أيضًا على زينودو، مما يعني أنه يمكن استرجاعها وتنزيلها باستخدام بروتوكول HTTPS، الذي هو موحد (A1) ومفتوح ومجاني وقابل للتنفيذ عالميًا (A1.1)، وقادر على دعم إجراءات المصادقة والتفويض (A1.2). البيانات الوصفية المرتبطة بتشغيل سير العمل ومكوناته مستقلة عن تشغيل سير العمل والمكونات نفسها، وهي متاحة على زينودو حتى إذا أصبح تشغيل سير العمل ومكوناته غير متاحة (A2).

تذكر من الشكل 1 أن أصل التنفيذ هو نتاج تشغيل سير العمل. هنا، يتم توليد الأصل من تشغيل سير عمل التنبؤ بالأنسجة/الأورام الرقمية باستخدام CWLProv. في شكل حزمة RO ثم تم تحويلها إلى صندوق RO الذي يتبع ملف تعريف صندوق Provenance Run (https://www.researchob-ject.org/workflow-run-crate/profiles/0.1/provenance_run_crate). تمثل جميع هذه الطرق معلومات تشغيل سير العمل من خلال استخدام معايير ولغة راسخة (I1). يسمح كل من CWLProv و RO-Crate بمفردات تتماشى مع مبادئ FAIR (I2). يتم إنشاء أصل تشغيل سير العمل باستخدام CWLProv وتوثيقه كملف تعريف Provenance Run Crate يظهر تبادل البيانات بين مكونات سير العمل. ومع ذلك، لا يتضمن أصل تشغيل سير العمل معايير محددة للمجال للبيانات الوصفية التي يجب الوفاء بها (مما يعني أنه لا يلبي I3). يتضمن أصل تشغيل سير العمل مراجع مؤهلة لأشياء أخرى ومكونات سير العمل (I4).

يتم وصف تشغيل سير العمل بالعديد من السمات الدقيقة والملائمة (R1)، ويتم إصداره بموجب ترخيص MIT الواضح والمتاح (R1.1). أحد مكونات تشغيل سير العمل، Slaid، هو مكتبة لتطبيق نماذج التعلم العميق من مشروع DeepHealth.https://deephealth-project.eu/) على صور الشرائح الكاملة (WSI) التي تم إصدارها أيضًا بشكل مستقل بموجب ترخيص MIT (R1.2). يحتوي تشغيل سير العمل على معلومات مفصلة حول الأصلية المتعلقة بالتنفيذ، مقدمة ككائن RO-Crate قابل للتنزيل (R1.3). يقوم تشغيل سير العمل بمعالجة صور علم الأمراض الرقمية بالتنسيقات المدعومة من OpenSlide (R3)، وهو مكتبة برمجيات شائعة تمثل معيارًا مجتمعيًا لصور علم الأمراض الرقمية. .

تركز مبادئ FAIR في الجدول 1 على سير العمل كأصول بحثية أكاديمية يمكن العثور عليها والوصول إليها والتشغيل البيني وإعادة استخدامها. لا تمتد هذه المبادئ إلى جودة سير العمل (FAIR+Q) أو مدى إمكانية إعادة إنتاج سير العمل (FAIR+R)، وهي تشير فقط إلى قابلية نقلها واستدامتها. تكمل إرشادات البيانات المفتوحة، الشيفرة المفتوحة، والبنية التحتية المفتوحة (O3) مبادئ FAIR من خلال توفير خارطة طريق قابلة للتنفيذ نحو الاستدامة. ومع ذلك، يجب ملاحظة أن FAIR لا تتطلب الانفتاح؛ يمكن للمؤلفين والشركات حتى اختيار عدم نشر سير العمل أو البيانات الوصفية الخاصة بهم على الإطلاق، ولكن لا يزال بإمكانهم استخدام مبادئ “FAIR الداخلية”. لمصالحهم الخاصة.

تتكون سير العمل من مكونات قابلة للتنفيذ تحتاج إلى التحقق منها واختبارها بواجهات نظيفة، وأذونات وصول مرنة إذا تم تنفيذها عن بُعد، ورخص متوافقة. العمل على مكتبات سير العمل القياسية. وكتل البناء التي تتوافق بين اللغات جاهزية سير العمل للأدوات اختبار الوحدة العادل مثل pytest-workflow لـ WDL (https://github.com/LUMC/pytest-workflow), مراقبة الاختبارات مثل LifeMonitor(https://crs4.github.io/life_monitor/)، وقياس الأداء مثل OpenEBench (https://openebench. bsc.es/هي خطوات نحو إنشاء ممارسات عمل مهنية عادلة يجب أن تشمل مراجعة الأقران، والتنسيق، وربما حتى الشهادة.

يجب علينا أيضًا أن نأخذ في الاعتبار علاقة FAIR بالخدمات الأخرى في نظام خدمات سير العمل. تلعب تقنيات الحاويات مثل Docker وSingularity دورًا في التوافقية وإعادة الاستخدام وقابلية التكرار لسير العمل الحاسوبي من خلال توفير بيئات خفيفة الوزن وقابلة للنقل ومحتواة ذاتيًا تتضمن جميع الاعتمادات البرمجية والمكتبات المطلوبة لتشغيل سير العمل. تماشيًا مع مبادئ FAIR، يمكن إصدار الحاويات ومشاركتها من خلال سجلات مثل Docker Hub وNexus Repository أو Github Container registry، ولكن هذه السجلات ليست FAIR حقًا لأن الإصدارات القديمة قد لا يتم الاحتفاظ بها. يجب تخزين سير العمل FAIR في مستودعات خاضعة للتحكم في الإصدارات مثل GitHub وGitLab وفهرستها من خلال سجلات مثل Dockstore. و WorkflowHub . تدعم سجلات سير العمل مثل Dockstore وWorkflowHub إمكانية البحث والوصول بحيث يمكن مشاركة سير العمل ونشره وإعادة استخدامه بالإضافة إلى تنزيله أو تشغيله باستخدام مرافق البنية التحتية المخصصة مثل Galaxy Europe. كلاهما يدعمان مكونات بيانات الإدخال والاختبار كمواصفات لسير العمل ولكن لا يحتفظان بمكونات النتائج لتشغيل سير العمل – الأصول والروابط إلى مجموعات البيانات التي هي المنتجات الناتجة. من المتوقع أن يتم إدارة ذلك بواسطة مستودعات البيانات مثل Zenodo وFigshare التي تحتاج بدورها إلى دعم مبادئ البيانات FAIR. ومع ذلك، فإن هذا النهج القائم على الحاويات يظهر على الأرجح قيودًا عملية عند تطبيقه على سير العمل المنفذ في بيئات الحوسبة عالية الأداء الكبيرة جدًا، والتي يتم صيانتها بدقة ورعايتها وتعمل على حافة الاستقرار الحسابي والتقني. في مثل هذه الحالات، قد تكون قابلية إعادة إنتاج سير العمل دائمًا قضية.

تعتبر سير العمل كائنات متعددة الأجزاء، حيث تكون مكونات بياناتها مهمة بقدر خطواتها القابلة للتنفيذ؛ يجب أن تكون جميع هذه الكائنات الرقمية FAIR أيضًا. جهود المجتمع مثل RO-Crate اقترح الوسائل لتغليف سير العمل وجميع مكوناته مع التقاط السياق الذي يتم استخدامه فيه (مثل: التنفيذات، المراجع، الرسومات، إلخ). ملف تعريف سير عمل RO-Crate (https://about.workflowhub.eu/Workflow-RO-Crate/) يتضمن إشارات إلى مكونات تحتاج أيضًا إلى أن تكون FAIR. من خلال وجود سير العمل كتركيبة من مخرجات البحث FAIR، يتم التحقق من FAIRness لكل مورد محتوى، حيث يعتمد تنفيذ سير العمل على توفر هذه الموارد. تقوم خدمات مثل WorkflowHub (سجل)، LifeMonitor (مراقبة الاختبارات)، وGalaxy (منصة سير العمل) بتنفيذ RO-Crate لتمثيل وتبادل سير العمل بشكل شامل بالإضافة إلى خطوة لمشاركة البيانات الوصفية والمعرفات الدائمة لتنفيذ مبادئ FAIR المذكورة في الجدول 1.

نظرًا لأن سير العمل عادةً ما يعمل على مجموعات البيانات وينتجها، فإنها في وضع جيد لجعل تلك المنتجات البيانات FAIR؛ حيث توفر وصف العملية وجمع السجلات الآلية للبيانات، ويمكن لنظام إدارة العمل الكامل أن يقوم بأتمتة العمليات لتوليد بيانات FAIR. ومع ذلك، يجب أن تكون سير العمل مصممة بشكل جيد لتكون “واعية لـ FAIR”: إنتاج واستهلاك البيانات بتنسيقات موحدة، وتعيين التراخيص، والتعامل مع المعرفات، وإنتاج البيانات الوصفية، وإصدار البيانات، وما إلى ذلك. استخدام سير العمل كأدوات آلية لـ “بيانات FAIR من التصميم” يمكن أن يشجع المدخلات ويجعل المخرجات قابلة للتنفيذ آليًا وأكثر ملاءمة للاستخدام في سير عمل أخرى، على سبيل المثال تلك التي تمتد عبر مرافق حوسبة جغرافية متميزة. .

تعتبر سير العمل الحاسوبية أدوات رئيسية للتقدم في البحث العلمي، حيث يمكن أن تحدث ثورة في كيفية إدارة البيانات وتحليلها ومشاركتها. لا تعمل سير العمل فقط كبرمجيات يمكن استخدامها من قبل الخبراء وغير المبرمجين على حد سواء؛ بل تعمل أيضًا كتوثيق للعمليات العلمية، حيث تتضمن ليس فقط البيانات والبرمجيات المستخدمة ولكن أيضًا السياق والظروف التي تم فيها تحقيق الاكتشافات. من المتوقع أن يعزز هذا التوثيق الشامل مصداقية نتائج البحث، كما سيسهل تكرار النتائج العلمية والتحقق منها عبر بيئات متنوعة ومن قبل فرق بحث مختلفة.

تطبق مبادئ بيانات FAIR وبرمجيات FAIR على سير العمل، حيث تجمع بين البيانات المنظمة والمُوَصَفَة بشكل جيد مع البرمجيات المحمولة والمُوَثَّقة بشكل جيد، مما يخلق إطارًا قويًا لتعزيز المعرفة العلمية. علاوة على ذلك، ستتطلب الجيل القادم من سير العمل – التجميع التلقائي المدعوم، وسير العمل التوليدي، وإعادة التكوين الديناميكي، وما إلى ذلك – بيانات وصفية غنية وقابلة للتنفيذ بواسطة الآلات.

يتطلب تطبيق FAIR تفسيرًا، ومع ذلك، يجب مراعاة التجريد والخصائص التركيبية لسير العمل. لا تزال التحديات المعتادة لتنفيذ FAIR موجودة: الحوافز، والموارد، والتقييم، وخدمات الدعم، وما إلى ذلك. حتى عندما تظهر الفرص لإثراء البيانات الوصفية عند تسجيل سير العمل في WorkflowHub، على سبيل المثال، لا يدير أفضل القيمين جميع المبادئ، وغالبًا ما يسلك معظمهم الطريق الأسهل. سيتطلب تنفيذ سير العمل FAIR “قرية” من الخدمات، بما في ذلك خدمات البيانات والدعم من أنظمة إدارة سير العمل، وسير العمل المصممة بشكل جيد التي تدرك بيانات FAIR ستحتاج إلى أمثلة معيارية، وتدريب، واحتراف.

تاريخ الاستلام: 8 أكتوبر 2024؛ تاريخ القبول: 10 يناير 2025؛
تم النشر عبر الإنترنت: 24 فبراير 2025

استخدمت هذه البحث موارد من: منشأة القيادة الحاسوبية في أوك ريدج في مختبر أوك ريدج الوطني، المدعومة من مكتب العلوم التابع لوزارة الطاقة الأمريكية بموجب العقد رقم DE-AC05-00OR22725 (SRW)؛ مختبرات سانديا الوطنية، مختبر متعدد المهام مُدار ومُشغل
من قبل حلول التكنولوجيا والهندسة الوطنية في سانديا، LLC (NTESS)، وهي شركة مملوكة بالكامل لشركة هانيويل الدولية، لصالح إدارة الأمن النووي الوطنية التابعة لوزارة الطاقة الأمريكية (DOE/NNSA) بموجب العقد DE-NA0003525 (LP)؛ برنامج الاتحاد الأوروبي هورايزون أوروبا بموجب اتفاقيات المنح HORIZON-INFRA-2021-EOSC-01 101057388 (EuroScienceGateway)، HORIZON-INFRA-2023-EOSC-01-02 101129744 (EVERSE؛ SS)، HORIZON-INFRA-2021-EOSC-01-05 101057344 ومن قبل أبحاث المملكة المتحدة والابتكار (UKRI) بموجب منح ضمان تمويل هورايزون أوروبا من الحكومة البريطانية 10038963 (EuroScienceGateway؛ CG، S-SR)، 10038992 (FAIR-IMPACT؛ NJ)؛ الأسترالية BioCommons، التي تم تمكينها بواسطة NCRIS عبر تمويل Bioplatforms Australia (JG)؛ مؤسسة الأبحاث الألمانية (DFG، مؤسسة الأبحاث الألمانية) كجزء من GHGA – أرشيف الجينوم-الظاهرة البشري الألماني (www.ghga.de, رقم المنحة 441914366 (NFDI 1/1))؛ الوكالة الوطنية للبحث بموجب برنامج فرنسا 2030، مع الإشارة إلى ANR-22-PESN0007 (KB). تم تأليف هذه المخطوطة بواسطة UT-Battelle، LLC، بموجب العقد DE-AC0500OR22725 مع وزارة الطاقة الأمريكية (DOE). هذا العمل المكتوب مؤلف من قبل موظف في NTESS. الموظف، وليس NTESS، يمتلك الحق والملكية والمصلحة في العمل المكتوب وهو مسؤول عن محتوياته. أي آراء أو وجهات نظر ذات طابع شخصي قد يتم التعبير عنها في العمل المكتوب لا تمثل بالضرورة وجهات نظر الحكومة الأمريكية. تحتفظ الحكومة الأمريكية ويدرك الناشر، بقبول المقال للنشر، أن الحكومة الأمريكية تحتفظ بترخيص غير حصري، مدفوع، غير قابل للإلغاء، عالمي لنشر أو إعادة إنتاج الشكل المنشور لهذه المخطوطة، أو السماح للآخرين بذلك، لأغراض الحكومة الأمريكية. ستوفر وزارة الطاقة الوصول العام إلى نتائج هذه الأبحاث المدعومة من الحكومة الفيدرالية وفقًا لخطة الوصول العام لوزارة الطاقة (https://www.energy.gov/doe-public-access-plan).

S.R.W. و C.G. هما المؤلفان الرئيسيان للمخطوطة. جميع المؤلفين الآخرين مدرجون أبجديًا وساهموا في المخطوطة من خلال المشاركة في اجتماعات WCI-FW ومن خلال تحرير أو التعليق على نص المخطوطة.

يعلن المؤلفون عدم وجود مصالح متنافسة.

يجب توجيه المراسلات والطلبات للحصول على المواد إلى S.R.W.
معلومات إعادة الطبع والتصاريح متاحة على www.nature.com/reprints.
ملاحظة الناشر تظل Springer Nature محايدة فيما يتعلق بالمطالبات القضائية في الخرائط المنشورة والانتماءات المؤسسية.

الوصول المفتوح هذه المقالة مرخصة بموجب ترخيص المشاع الإبداعي للاستخدام غير التجاري، والذي يسمح بأي استخدام غير تجاري، ومشاركة، وتوزيع وإعادة إنتاج في أي وسيلة أو صيغة، طالما أنك تعطي الائتمان المناسب للمؤلفين الأصليين والمصدر، وتوفر رابطًا إلى ترخيص المشاع الإبداعي، وتوضح إذا قمت بتعديل المادة المرخصة. ليس لديك إذن بموجب هذا الترخيص لمشاركة المواد المعدلة المشتقة من هذه المقالة أو أجزاء منها. الصور أو المواد الأخرى من طرف ثالث في هذه المقالة مشمولة في ترخيص المشاع الإبداعي للمقالة، ما لم يُشار إلى خلاف ذلك في سطر ائتمان للمادة. إذا لم تكن المادة مشمولة في ترخيص المشاع الإبداعي للمقالة واستخدامك المقصود غير مسموح به بموجب اللوائح القانونية أو يتجاوز الاستخدام المسموح به، ستحتاج إلى الحصول على إذن مباشرة من صاحب حقوق الطبع والنشر. لعرض نسخة من هذا الترخيص، قم بزيارة http://creativecommons.org/licenses/by-nc-nd/4.0/.
© UT-Battelle، LLC والمؤلفون 2025

Scale-ups in research data and the rise of data-driven science have spurred the research community to find solutions for managing and automating complex computational processes in order to ensure efficiency, reproducibility, scalability, collaboration, and quality-assured transparency. Computational workflows are a special kind of software specifically targeted at handling multi-step, multi-code data pipelines, data analyses, and other data-handling operations, especially through the efficient use of computational resources to transform data inputs into desired outputs.
Oak Ridge Leadership Computing Facility, Oak Ridge National Laboratory, Oak Ridge, Tennessee, USA. Department of Computer Science, University of Manchester, Manchester, UK. LAMSADE, PSL, Paris Dauphine University, Paris, France. Mathematics of Complex Systems division, Visual and Data-Centric Computing department, Bioinformatics in Medicine group, Zuse Institute Berlin (ZIB), Berlin, Germany. Earth Sciences, Barcelona Supercomputing Center, Barcelona, Spain. German Human Genome-Phenome Archive (GHGA, W620), German Cancer Research Center (DKFZ), Heidelberg, Germany. Ontology Engineering Group, Universidad Politécnica de Madrid, Madrid, Spain. Australian BioCommons, University of Melbourne, Melbourne, Victoria, Australia. Clinical Pathology, University of Melbourne Centre for Cancer Research (UMCCR), Parkville, Victoria, Australia. Bioinformatics and computational oncology (Bioinformatische Algorithmen in der Onkologie), Institute for AI in Medicine (IKIM), University Medicine Essen, University of Duisburg-Essen, Essen, Germany. Data Management Department, Deutsches Klimarechenzentrum GmbH, Hamburg, Germany. Center for Computing Research, Sandia National Laboratories, Albuquerque, New Mexico, USA. Silverdraft Supercomputing, Boise, Idaho, USA. Informatics Institute, University of Amsterdam, Amsterdam, The Netherlands. Earlham Institute, Norwich, UK. Center for Spatial Information Science and Systems, Department of Geography and Geoinformation Science, George Mason University, Fairfax, Virginia, USA. Bioinformatics Group, Riga Stradins University, Riga, Latvia. School of Clinical Medicine, University of New South Wales, Kensington, New South Wales, Australia. Ontario Institute for Cancer Research, Toronto, Ontario, Canada. e-mail: wilkinsonsr@ornl.gov

Computational workflows are software with two prominent characteristics: (i) the composition (component number, order, structure) of multiple components that include other software, workflows, code snippets, tools, and services; and (ii) the explicit abstraction from the run mechanics in some form of high-level workflow language that precisely specifies the flow of data between the components, relying on a dedicated management system concerned with data handling and code execution. Metadata details the dependencies and computational requirements, including those of the computational environment .

At the simplest end of the complexity spectrum, the workflow language might consist of a script (e.g. Bash, Python, R) or enumerated stages in an electronic research notebook (e.g. Jupyter, RStudio, Apache Zeppelin, etc.) with a set of instructions that use inputs and outputs to pipe the results together. At the other end, workflows might employ a workflow management system (WMS) such as Nextflow , Galaxy , Snakemake , or Parsl . Using a WMS can provide a number of benefits including abstraction, scaling, automation, reproducibility , and provenance . A fully featured WMS typically facilitates error handling and restarting, automatic data staging, provenance recording, handling of large datasets and complex computations, task and resource allocation, and distributed task execution to scale over local workstations, cloud resources, or high-performance computing clusters. WMSes and modular containerized software components (e.g. Docker, Singularity) aid portability and reproducibility, but they also face challenges (e.g., security issues when deployed in clusters, steep l earning curve, etc.). In practice, researchers use mixtures of techniques from across the spectrum, such as chaining scripts from a WMS that in turn is launched from a notebook.

Workflows are complex digital objects with intra- and inter-object relationships that connect the entire workflow, its definition, and its scope. To help clarify our FAIR discussion, we present some definitions along with an illustration in Fig. 1.

A workflow is the formal specification of the data flow and execution control between executable components, the expected datasets, and parameter files. Its complexity can be composed, and its overall process can be abstracted away from its execution. A workflow run is the instantiation of the workflow with inputs (parameters files, input datasets) and outputs (output data, the provenance execution log and lineage of data products).

A workflow component can be an executable and data. Executables include scripts, code, tools, containers, or workflows themselves remotely or locally executed, and native or third party; an example data component could be a reference dataset. For a workflow specification, data include metadata (e.g., its description), graphical images, test and benchmark datasets, parameter defaults, and so on. For a workflow run, data extends to the actual input and output datasets, the parameter files, and the provenance record detailing the code run and data product lineage.

A workflow management system handles the data flow and/or execution control and performs the heavy lifting for computational and data handling. A workflow management system abstracts the workflow from the underlying digital infrastructure, supporting scalability, portability, and differences in hardware architectures.

The use of workflows has accelerated in the past few years. The existence of more than 350 different workflow management systems of varying maturity evidences the increasing popularity of workflows (https://s.apache. org/existing-workflow-systems). Workflows help reduce the burden of manual human effort by automating repetitive and time-consuming tasks. This automation enables efficiency in terms of resource allocation both by allowing humans to return to human-only tasks and by allowing the computational tasks to take advantage of opportunities for automatic optimizations. Workflows also automate critical processes that require standardization and increased reproducibility, improving efficiency by removing humans from the analytical process, at times dispensing with the need for manual management of data flow through a set of processing steps, and reducing the need for repeat analyses due to human error and/or bias. Moreover, automation ensures that computational experiments can be replicated. Workflows also provide a documented record of the computational processes, which helps in understanding, reviewing, and auditing those processes. As scientific activity often includes the exploration of analysis variance, modifying workflows to understand effects and changes on data products is simpler when those workflows are clearly described and comparable. Researchers can reuse workflows to re-analyze and adapt to incorporate new methods, tools, or data sources. Sharing and reusing workflows supports team collaboration and standardizes processes and analysis methods .

The Findable, Accessible, Interoperable, and Reusable (FAIR) principles aim to maximize the value and impact of scientific digital objects. Such objects cannot be reused if they cannot be found, accessed, or understood; they cannot be combined if they are not interoperable. The FAIR guidelines for scientific data emphasize making data findable through metadata provision, unique and persistent identifier assignment, ensuring accessibility through open access or controlled access mechanisms, promoting interoperability through standardized formats and metadata schemas, and enabling reusability through clear licensing and documentation. The FAIR principles for research software (FAIR4RS) recommend making software findable through repositories and registries, ensuring accessibility through open licensing and documentation, promoting interoperability through standardization and compatibility with other tools, and enabling reusability through versioning and clear documentation of functionality and dependencies. These principles have made a significant impact on policy and publishing, and they have been taken up by the public and private sector as well as spawning an industry of projects, research programs, and commercial businesses .

FAIR4RS defines research software as “source code files, algorithms, scripts, computational workflows, and executables that were created during the research process or for a research purpose”. Workflows are a specific kind of software where reuse and modification should be inherent in their modularized composition of code and sub-workflows with an explicitly defined control and data flow. Workflow composition can be organized along levels of granularity (e.g. functions, tasks, stages, pipelines), for example similar to libraries in a software stack. The execution of a series of computational code can be difficult to standardize and share across different research environments, and each has its own set of dependencies and requirements, which can complicate the process of ensuring comprehensive FAIRness . Automating scientific experiments using workflows helps mitigate this issue. A key characteristic is the separation of the workflow specification from its execution; the description of the process is a form of data-describing method . Workflows that are chiefly concerned with the processing and creation of data are typically designed to be tightly coupled with their data, including test data and the provenance lineage history of data products. Therefore, workflows have an important role to play in ensuring that the data products they use and produce are FAIR.

Building on earlier work , the WCI FAIR Computational Workflows Working Group (WCI-FW) set out to systematically apply the FAIR principles to computational workflows. WCI-FW is an open, diverse, and interdisciplinary collective of workflow system professionals and workflow users and authors who meet bi-weekly online. The group comprises experts from 40 organizations from 13 countries specialized in various fields, including bioinformatics, climate science, data science, earth science, software engineering, and workflow management. This diversity of backgrounds and expertise allowed us to approach the task from multiple perspectives, ensuring that the FAIR principles for computational workflows are both practical and widely accepted to enhance the reusability, reliability, and impact of computational workflows across diverse research domains.

The WCI-FW debated for many months whether to define a new, tailored set of principles for computational workflows or to apply the established principles for data and software. We concluded that we would directly apply the principles for FAIR data and software after recognizing that (a) we were naturally developing variations of these established principles because (b) workflows are a hybrid form of software, closely bound to data and even possessing data-like properties . By building on the established FAIR framework, we have maintained consistency and enabled practices for workflows to integrate seamlessly with existing practices for data and software.

Several pivotal questions surfaced in the course of our group discussions:

Table 1 summarizes our results with further discussion below. In a nutshell, Findability means that a workflow and its associated metadata are easy for both humans and machines to find. Accessibility means that a workflow and its metadata are retrievable via standardized protocols. Interoperability means that a workflow interoperates with other workflows, and workflow components interoperate, by exchanging data and/or metadata, and/or through interaction via APIs, described by standards. Finally, Reusability means that a workflow is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other workflows).

Findability. The data and software principles generally apply to workflows, but with novel/additional considerations on our interpretation of a component and a strengthening of metadata associated with workflow versions. Workflows are subject to continuous refinement and independent modification, often resulting in multiple versions, adaptations, and variants, with workflows extended, nested, and reused as sub-workflows. Researchers modify workflows for specific purposes, adjust components, and provide alternative methods across various platforms; components are copied, pasted, and modified.

Identifiers are important because unlike software, authors often neglect to “name” their workflows (although they do name their workflow management systems). Identifiers establish a clear lineage of each workflow and component’s origin and changes, enabling researchers to understand the workflow structure and evolution, compare iterations, relate workflows to each other, and confidently build upon previous work. Persistent identifiers identify and reference specific versions to ensure accurate identification and traceability and to support developer citation and source workflow attribution (F1). Unique identifiers to different versions of workflows recognize their dynamic nature in research (F1.2). Unique identifiers for a workflow’s components and versions (whether a file, computational step, or sub-workflow) support traceability and facilitate reuse, reproducibility, and portability across different workflow versions (F1.1).

Rich metadata for the overall workflows and their components (including inputs and outputs) (F2, F3) should use a formal, accessible language for knowledge representation, such as schema.org (https://schema.org), and standardized metadata such as the Bioschemas schema.org profile for Computational Workflows (https:// bioschemas.org/types/ComputationalWorkflow/), used for workflow components in Workflow Run Crate profile and CodeMeta (https://w3id.org/codemeta/v3.0). Other metadata forms for workflows include canonical “Rosetta” languages (e.g. CWL , WDL ) that abstract from the native workflow language for greater portability and comparability. Such metadata are used for registration and search in dedicated and trusted workflow registries such as WorkflowHub and Dockstore (F4) .

Accessibility. The data and software principles generally apply but with new considerations on what it means for a workflow to be available. The workflow may be restricted to execution at one facility, which is a common case in highly optimized HPC settings, and access to that facility may be restricted (A1.2). Single sign-on for workflow components requires harmonized Authentication and Authorization Infrastructure (AAI) propagation through the different tasks, if they are hosted by different service providers. “A2. Metadata are accessible, even when the workflow is no longer available” requires further interpretation given a workflow’s dual nature as process description (data) and process execution (software), and we must understand what “no longer available” means. As a piece of software, a workflow execution platform or the infrastructure that it operates on may become deprecated and/or unavailable. Dependency on the component code and services makes a workflow vulnerable to “software rot”, and it is not always possible to completely containerize and preserve all code, such as when they are remotely executed third party tools or call-outs to online datasets .

As a process description, the workflow captures both the steps and data flow of a recipe for a method, which is a form of the “metadata”. Thus at least the workflow and its components descriptions, and if relevant the workflow run components, should be preserved and archived in a long-term registry or repository, so that if the workflow is no longer executable, it will still be readable. If we interpret a workflow description file as data, the data principles decree that at least the metadata for that file should still be retrievable. For a workflow, however, that data file is the essence of the workflow. We interpret the workflow description to be a form of metadata of the software and therefore, it must always be accessible. A workflow associated with a publication may still be

examined as a method, and its provenance may be inspected; the description should be enough to be translated for another workflow system. Apart from manual or AI-assisted porting of code, this can also happen via “Rosetta” workflow languages like CWL and WDL (as e.g. done in MGnify and by Snakemake’s CWL export).

Interoperability. The data and software principles combine and blur with principles from Reusability, as we tease apart the FAIR requirements for a workflow, its components (both executable and data), and an instantiated and executed run of the workflow. For example, principle Il applies to describing the static workflow structure of the specification and capturing dynamic aspects of the run such as execution details and intermediate outputs. The workflow specification plays a role in data in I1, I2, and I4 adapting data principles, as well as the role of metadata of the software, co-opting software principles.

We adapt software principles for I3 and I4 to explicitly refer to the domain standard description of input and outputs of the workflow executable components. As data components of a workflow, the expected input and output datasets, benchmarks and parameters, and the actual datasets and parameter files from a workflow run, should also adhere to community standards (data principle R1.3), as should intermediate data derived during the execution. The principles encourage workflow portability across different types of computational environments (e.g., via containerization or OS-agnostic package management) and, ideally, easy translation from one language/management system to another or at least compatibility and seamless integration (in case of sub-workflows).

Standard language formats like CWL encourage interoperability and offer the potential for workflow comparisons and exchange between different languages through documentation of components, inputs, and outputs. We explicitly add workflow run provenance to interoperability as documented execution steps and data lineage traces are important components that should also be interoperable and machine-actionable .

Reusability. Reusability of the workflow as an executable method with modifications to its parameters and input files is an expected and anticipated use of the workflow, tied up in the quality of its documentation and the accessibility of computational infrastructure capable of executing it.

While previously discussing findability, we also highlighted the reusability of workflows as complex compositions intended to be modified, built upon, and incorporated into other workflows, as well as their reusability as runnable executions with modified datasets and parameter files . The data and software principles are adapted to emphasize the composite nature of workflows (both executable and data components) for licensing . Workflows are composed of many parts, potentially from different authors with different intents for how their artifacts may be used; these intents must be clearly stated by the inclusion of licenses that cover all parts of the workflow and sub-parts of the workflows that can be reused as sub-workflows .

The provenance history of the workflow – its authors, purpose, workflows of which it may be a variant, links to other sub-workflows and so on, are included in R1.3 drawing from both data and software principles R1.2. The provenance of data products tracked by the workflow run provenance collection is related to the data
principles R1.2 where data (in this case the products of the workflow) are associated with detailed provenance that a workflow system should be able to provide. A benefit of using fully fledged workflow systems is the capture of computer-interpretable provenance (meta)data to track the history and origin of data processing steps. R1 and R3 expect that input and output datasets are thoroughly described with example input and expected output data for each step that adhere to data structure and file format standards and gold standards for benchmarking .

Here, we provide concrete examples with detailed descriptions for applying the FAIR principles to both workflow specifications and workflow runs. For each case, we narrate through the FAIR principles sequentially. We recommend the reader to follow along with Table 1 as a guide.

Example workflow specification. The Protein MD Setup workflow sets up a protein molecular dynamic simulation that returns a protein structure and simulated 3D trajectories . It is registered in WorkflowHub (https://doi.org/10.48546/workflowhub.workflow.29.3), where it has been assigned a Digital Object Identifier (DOI) which is globally unique (F1). Different versions of this workflow can be identified using unique digital object identifiers (F1.2). The workflow is described using (rich) metadata (F2) that includes the identifier of the workflow and its unique version (F3). The workflow and associated metadata are registered (F4). Moreover, components of the workflow have their own individual persistent identifiers as the workflow is composed of sub-workflow BioBB building blocks from the BioBB Library (https://workflowhub.eu/projects/11) (F1.2). The workflow and its components can be retrieved and downloaded using a standardized HTTPS protocol (A1, A1.1, A1.2). The metadata associated with the workflow and its components is independent from the GitHub code repository and are accessible on WorkflowHub even if the workflow (or its components) become inaccessible (A2).

The Protein MD Setup is written using CWL which follows a formal and declarative paradigm for workflow implementation (I1). The workflow does not include all the best-practice principles to fulfill I2 and I3. This extends to the workflow metadata, which does not use a domain-specific ontology. The workflow and its metadata include qualified references to other objects and components (I4). However, CWL standard itself allows metadata and workflow vocabularies (e.g. Bioschemas, EDAM ) that are consistent with FAIR principles (I2), enables the components of the workflows to read, write, and exchange data using format that meets domain-specific standards (I3), and assigns qualified references to workflow components, inputs, and outputs.

The workflow is released under Apache License 2.0 software license (R1.1) and WorkflowHub’s RO-Crate references that the embedded CWL code is archived from the corresponding GitHub source code repository (https://github.com/bioexcel/biobb-wf-md-setup-protein-cwl). The component BioBB building blocks of the workflow have their own clear and accessible licenses (R1.2). The workflow is associated with detailed provenance about its development, provided as a downloadable RO-Crate object (R1.3).

Example workflow run. Here, we demonstrate the application of the FAIR principles to a workflow run. Recall from our previous definitions that a workflow run is the instantiation of a workflow with inputs (parameters files, input datasets) and outputs (output data, the provenance execution log and lineage of data products). In this example, the workflow run is instantiated from a tissue/tumor prediction workflow specification for digital pathology, and it is represented using RO-Crate .

The workflow run has been assigned a globally unique DOI (F1), and components of the workflow run (e.g. steps, inputs, outputs) are also assigned their own distinct identifiers (F1.1). The workflow run is described using rich metadata (F2) that includes the identifier of the workflow run and its unique version (F3). The corresponding workflow specification is not registered, but it is publicly available via GitHub (https://github.com/crs4/ deephealth-pipelines), and the workflow run is registered on Zenodo, which is a searchable FAIR resource (F4).

The workflow run and its components are also hosted on Zenodo, which means that they can be retrieved and downloaded using the HTTPS protocol, which is standardized (A1), open and free and universally implementable (A1.1), and able to support authentication and authorization procedures (A1.2). The metadata associated with the workflow run and its components are independent from the workflow run and components themselves, and they are accessible on Zenodo even if the workflow run and its components become inaccessible (A2).

Recall from Fig. 1 that execution provenance is a product of a workflow run. Here, provenance from the digital pathology tissue/tumor prediction workflow run is generated using CWLProv in the form of RO-Bundle and then converted to an RO-Crate that follows the Provenance Run Crate profile (https://www.researchob-ject.org/workflow-run-crate/profiles/0.1/provenance_run_crate). All of these methods represent workflow run information by utilizing well-established standards and language (I1). CWLProv and RO-Crate allow vocabularies that are consistent with the FAIR principles (I2). The workflow run provenance is generated using CWLProv and documented as a Provenance Run Crate profile showing the exchange of data between components of the workflow. The workflow run does not, however, include domain-specific standards for metadata to fulfill (which means it does not satisfy I3). The workflow run provenance does include qualified references to other objects and the workflow’s components (I4).

The workflow run is described with many accurate and relevant attributes (R1), and it is released under the clear and accessible MIT License (R1.1). One of the workflow run’s components, Slaid, is a library for applying DL models from the DeepHealth project (https://deephealth-project.eu/) on whole slide images (WSI) that is also released independently under the MIT License (R1.2). The workflow run contains detailed provenance about the execution, provided as a downloadable RO-Crate object (R1.3). The workflow run processes digital pathology images in the formats supported by OpenSlide (R3), which is a widespread software library that represents a community standard for digital pathology images .

The FAIR principles in Table 1 focus on the workflows as scholarly research assets to be found, accessed, interoperated, and reused. They do not extend to the quality of the workflows (FAIR+Q) or the extent of the reproducibility of the workflows (FAIR+R), and they only hint at their portability and sustainability. The Open Data, Open Code, Open Infrastructure (O3) guidelines complement FAIR by providing an actionable road map toward sustainability . Note, however, that FAIR does not require openness; authors and companies may even choose not to publish their workflows or metadata at all, but still use “inner FAIR” principles for their own benefits.

Workflows are composites of executable components that need to be validated and tested with clean interfaces, permissive access permissions if remotely executed, and compatible licenses. Work on canonical workflow libraries and building blocks that are interoperable between languages , workflow readiness of tools , FAIR unit testing like pytest-workflow for WDL (https://github.com/LUMC/pytest-workflow), test monitoring like LifeMonitor(https://crs4.github.io/life_monitor/), and benchmarking like OpenEBench (https://openebench. bsc.es/) are steps towards creating FAIR workflow professional practices that should include peer review, curation, and perhaps even certification.

We should also consider the relationship of FAIR to other services in a workflow’s service ecosystem. Container technologies such as Docker and Singularity play a role in the interoperability, reusability, and reproducibility of computational workflows by providing lightweight, portable, and self-contained environments that include all of the software dependencies and libraries required to run a workflow. In alignment with the FAIR principles, containers can be versioned and shared through registries like Docker Hub, Nexus Repository, or Github Container registry, but these registries are not truly FAIR because old versions may not be preserved. FAIR workflows should be stored in version-controlled repositories like GitHub and GitLab and indexed by registries like Dockstore and WorkflowHub . Workflow registries like Dockstore and WorkflowHub support findability and accessibility so workflows can be shared, published, and reused as well as downloaded or launched using dedicated infrastructure facilities such as Galaxy Europe. Both support example input and test data components for a workflow specification but do not retain the result components of a workflow run – the provenance and links to datasets that are the resulting products. That is expected to be managed by data repositories like Zenodo and Figshare that in turn need to support FAIR data principles. However, this container approach most probably shows practical limitations when applied to workflows executed on very large-scale, meticulously maintained and pampered HPC environments running on the verge of computational and technical stability. For such cases, reproducibility of workflows might always be an issue.

Workflows are multi-part objects whose data components are as important as their executable steps; all these digital objects should be FAIR too. Community efforts like RO-Crate propose the means to encapsulate workflows and all their components while capturing the context in which they are used (e.g., executions, bibliography, sketches, etc.). An RO-Crate Workflow profile (https://about.workflowhub.eu/Workflow-RO-Crate/) includes references to components which also need to be FAIR. By having workflows as composition of FAIR research outputs, the FAIRness of each contained resource is validated, since the execution of the workflow relies on these resources being available. Services like WorkflowHub (registry), LifeMonitor (test monitoring), and Galaxy (workflow platform) implement RO-Crate for comprehensive workflow representation and exchange as well as a step to sharing metadata and persistent identifiers to implement the FAIR principles of Table 1.

As workflows typically operate on and produce datasets, they are well placed to make those data products FAIR; they provide the process description and automated data provenance collection, and a fully fledged WMS can automate processes for generating FAIR data. Nevertheless, workflows have to be well designed to be “FAIR aware”: producing and consuming data in standardized formats, assigning license, handling identifiers, and metadata production, data versioning, etc . Using workflows as automated instruments for “FAIR data by design” can encourage inputs and make outputs to be machine-actionable and more suitable for use in other workflows, for example those that span geographically distinct computing facilities .

Computational workflows are key instruments for the advancement in scientific research, potentially revolutionizing how data is managed, analyzed, and shared. Workflows not only serve as software that can be used by experts and non-coders alike; they also serve as documentation of scientific processes, encapsulating not only the data and software used but also the context and conditions under which discoveries were made. It is expected that this comprehensive documentation will not only enhance the credibility of research findings but will also facilitate the replication and validation of scientific results across diverse settings and by different research teams.

FAIR data and FAIR software principles both apply to workflows, combining structured, well-described data with portable, well-documented software creating a powerful framework for advancing scientific knowledge. Moreover, the next generation of workflows – assisted auto-assembly, generative workflows, dynamic reconfiguration, and so on – will require rich, machine-actionable metadata.

FAIR application requires interpretation, however, to consider the abstraction and the compositional properties of workflows. The usual challenges for FAIR implementation are still present: incentives, resources, assessment, support services, and so on. Even when opportunities arise for metadata enrichment when registering workflows in WorkflowHub, for example, the best curators do not manage all the principles, and most take the simplest route. FAIR workflow implementation will “take a village” of services, including data services and support from workflow management systems, and well-designed workflows that are FAIR data-aware will require golden standard examples, training, and professionalization.

Received: 8 October 2024; Accepted: 10 January 2025;
Published online: 24 February 2025

This research used resources of: the Oak Ridge Leadership Computing Facility at the Oak Ridge National Laboratory, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725 (SRW); Sandia National Laboratories, a multi-mission laboratory managed and operated
by National Technology & Engineering Solutions of Sandia, LLC (NTESS), a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration (DOE/NNSA) under contract DE-NA0003525 (LP); the European Union programme Horizon Europe under grant agreements HORIZON-INFRA-2021-EOSC-01 101057388 (EuroScienceGateway), HORIZON-INFRA-2023-EOSC-01-02 101129744 (EVERSE; SS), HORIZON-INFRA-2021-EOSC-01-05 101057344 and by UK Research and Innovation (UKRI) under the UK government’s Horizon Europe funding guarantee grants 10038963 (EuroScienceGateway; CG, S-SR), 10038992 (FAIR-IMPACT; NJ); Australian BioCommons, which is enabled by NCRIS via Bioplatforms Australia funding (JG); Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) as part of GHGA – The German Human Genome-Phenome Archive (www.ghga.de, Grant Number 441914366 (NFDI 1/1)); the National Research Agency under the France 2030 program, with reference to ANR-22-PESN0007 (KB). This manuscript has been authored by UT-Battelle, LLC, under contract DE-AC0500OR22725 with the US Department of Energy (DOE). This written work is authored by an employee of NTESS. The employee, not NTESS, owns the right, title and interest in and to the written work and is responsible for its contents. Any subjective views or opinions that might be expressed in the written work do not necessarily represent the views of the U.S. Government. The US government retains and the publisher, by accepting the article for publication, acknowledges that the US government retains a nonexclusive, paid-up, irrevocable, worldwide license to publish or reproduce the published form of this manuscript, or allow others to do so, for US government purposes. DOE will provide public access to these results of federally sponsored research in accordance with the DOE Public Access Plan (https://www.energy.gov/doe-public-access-plan).

S.R.W. and C.G. are the primary authors of the manuscript. All other authors are listed alphabetically and contributed to the manuscript by participating in the WCI-FW meetings and by editing or commenting on the manuscript text.

The authors declare no competing interests.

Correspondence and requests for materials should be addressed to S.R.W.
Reprints and permissions information is available at www.nature.com/reprints.
Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Open Access This article is licensed under a Creative Commons Attribution-NonCommercialNoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/.
© UT-Battelle, LLC and the Authors 2025