User:Shawndouglas/sandbox/sublevel12

Sandbox begins below

Title: What are the potential implications of the FAIR data principles to laboratory informatics applications?

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: May 2024

Introduction

This brief topical article will examine

The "FAIR-ification" of research objects and software

First discussed during a 2014 FORCE-11 workshop dedicated to "overcoming data discovery and reuse obstacles," the FAIR Guiding Principles were published by Wilkinson et al. in 2016 as a stakeholder collaboration driven to see research "objects" (i.e., research data and information of all shapes and formats) become more universally findable, accessible, interoperable and reusable (FAIR) by both machines and people. The authors released the FAIR principles while recognizing that "one of the grand challenges of data-intensive science ... is to improve knowledge discovery through assisting both humans and their computational agents in the discovery of, access to, and integration and analysis of task-appropriate scientific data and other scholarly digital objects."

Since 2016, other research stakeholders have taken to publishing their thoughts about how the FAIR principles apply to their fields of study and practice, including in ways beyond what perhaps was originally imagined by Wilkinson et al.. For example, multiple authors have examined whether or not the software used in scientific endeavors itself can be considered a research object worth being developed and managed in tandem with the FAIR data principles. Researchers quickly recognized that any planning around updating processes and systems to make research objects more FAIR would have to be tailored to specific research contexts, recognize that digital research objects go beyond data and information, and recognize "the specific nature of software" and not consider it "just data." The end result has been applying the core concepts of FAIR but differently from data, with the added context of research software being more than just data, requiring more nuance and a different type of planning from applying FAIR to digital data and information.

A 2019 survey by Europe's FAIRsFAIR found that researchers seeking and re-using relevant research software on the internet faced multiple challenges, including understanding and/or maintaining the necessary software environment and its dependencies, finding sufficient documentation, struggling with accessibility and licensing issues, having the time and skills to install and/or use the software, finding quality control of the source code lacking, and having an insufficient (or non-existent) software sustainability and management plan. These challenges highlight the importance of software to researchers and other stakeholders, and the roll FAIR has in better ensuring such software is findable, interoperable, and reusable, which in turn better ensures researchers' software-driven research is repeatable (by the same research team, with the same experimental setup), reproducible (by a different research team, with the same experimental setup), and replicable (by a different research team, with a different experimental setup).

At this point, the topic of what "research software" represents must be addressed further, and, unsurprisingly, it's not straightforward. Ask 20 researchers what "research software" is, and you may get 20 different opinions. Some definitions can be more objectively viewed as too narrow, while others may be viewed as too broad, with some level of controversy inherent in any mutual discussion. In 2021, as part of the FAIRsFAIR initiative, Gruenpeter et al. made a good-faith effort to define "research software" with the feedback of multiple stakeholders. Their efforts resulted in this definition:

Research software includes source code files, algorithms, scripts, computational workflows, and executables that were created during the research process, or for a research purpose. Software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for research but were not created during, or with a clear research intent, should be considered "software [used] in research" and not research software. This differentiation may vary between disciplines. The minimal requirement for achieving computational reproducibility is that all the computational components (i.e., research software, software used in research, documentation, and hardware) used during the research are identified, described, and made accessible to the extent that is possible.

Note that while the definition primarily recognizes software created during the research process, software created (whether by the research group, other open-source software developers outside the organization, or even commercial software developers) "for a research purpose" outside the actual research process is also recognized as research software. This notably can lead to disagreement about whether a proprietary, commercial spreadsheet or laboratory information management system (LIMS) offering that conducts analyses and visualizations of research data can genuinely be called research software, or simply classified as software used in research. van Nieuwpoort and Katz further elaborated on this concept, at least indirectly, by formally defining the roles of research software in 2023. Their definition of the various roles of research software—without using terms such as "open-source," "commercial," or "proprietary"—essentially further defined what research software is:

• Research software is a component of our instruments.
• Research software is the instrument.
• Research software analyzes research data.
• Research software presents research results.
• Research software assembles or integrates existing components into a working whole.
• Research software is infrastructure or an underlying tool.
• Research software facilitates distinctively research-oriented collaboration.

When considering these definitions of research software and their adoption by other entities, it would appear that at least in part some laboratory informatics software—whether open-source or commercially proprietary—fills these roles in academic, military, and industry research laboratories of many types. In particular, electronic laboratory notebooks (ELNs) like open-source Jupyter Notebook or proprietary ELNs from commercial software developers fill the role of analyzing and visualizing research data, including developing molecular models for new promising research routes. Even more advanced LIMS solutions that go beyond simply collating, auditing, securing, and reporting analytical results could conceivably fall under the umbrella of research software, particularly if many of the analytical, integration, and collaboration tools required in modern research facilities are included in the LIMS.

Ultimately, assuming that some laboratory informatics software can be considered research software and not just "software used in research," it's tough not to arrive at some deeper implications of research organizations' increasing need for FAIR data objects and software, particularly for laboratory informatics software and the developers of it.

Implications of the FAIR concept to laboratory informatics software

Since the environment and incentives around building academic research software are very different to those of industry, the workflows around the former are, in general, not guided by the same engineering practices that are valued in the latter. That is to say: there is a difference between what is important in writing software for research, and for a user-focused, software product. Academic research software prioritizes scientific correctness and flexibility to experiment above all else in pursuit of the researchers’ end product: published papers. Industry software, on the other hand, prioritizes maintainability, robustness, and testing as the software (generally speaking) is the product. However, the two tracks share many common goals as well, such as catering to “users,” emphasizing performance and reproducibility, but most importantly both ventures are collaborative. Arguably then, both sets of principles are needed to write and maintain high-quality research software.

• Non-relational Resource Description Framework (RDF) knowledge graph databases used in well-designed laboratory informatics software help make research objects more FAIR.

- https://labbit.com/resources/rdf-knowledge-graph-databases-a-better-choice-for-life-science-lab-software and https://21624527.fs1.hubspotusercontent-na1.net/hubfs/21624527/Resources/RDF%20Knowledge%20Graph%20Databases%20White%20Paper.pdf

- https://biss.pensoft.net/article/37412/

- https://link.springer.com/article/10.1007/s40192-024-00348-4

- https://www.nature.com/articles/s41597-022-01352-z

- https://www.degruyter.com/document/doi/10.1515/jib-2018-0023/html

- https://arxiv.org/abs/2404.12935

• The application of research software engineering practices to the development of laboratory informatics software has the potential to help better support research laboratories using that software.

- https://www.rse-community.kit.edu/index.php

- https://www.rcac.purdue.edu/rse

- https://www.fairsfair.eu/sites/default/files/FAIR%20%2B%20software.pdf

Resources

• LIMS and FAIR: Journal:A roadmap for LIMS at NIST Material Measurement Laboratory
• ELNs and FAIR: Structure-based knowledge acquisition from electronic lab notebooks for research data provenance documentation
• Biomedical software and FAIR: https://www.nature.com/articles/s41597-023-02463-x
• Making software workflows FAIR: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10538699/
• AWS and FAIR for healthcare and life sciences: https://aws.amazon.com/blogs/industries/implement-fair-scientific-data-principles-when-building-hcls-data-lakes/
• APIs and FAIR data: https://www.labguru.com/blog/fair-data-principles-and-apis
• Bioinformatics LIMS and FAIR: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8425304/
• Labbit: https://labbit.com/fair-data-lims

• Extending FAIR to data graphics: https://www.nature.com/articles/s41597-022-01352-z

• https://riojournal.com/article/96075/ Importance of metadata for FAIR data objects
• Deep talk about metadata: Journal:Shared metadata for data-centric materials science
• More metadata, for findability: "While descriptive metadata may not be available, support for generalized CRUD operations requires essential structural and administrative metadata to be captured, stored, and made available for requestors. Metadata capture must be highly automated and reliable, both in terms of technical reliability and ensured metadata quality." Journal:Making data and workflows findable for machines
• More metadat, for reusability: "make recommendations for assigning identifiers and metadata that supports sample tracking, integration, and reuse. Our goal is to provide a practical approach to sample management, geared towards ecosystem scientists who contribute and reuse sample data." Journal:Sample identifiers and metadata to support data management and reuse in multidisciplinary ecosystem sciences

• "The principles should be considered during development of informatics systems to further promote data discovery and reuse. In Table 1, we have correlated the various BRICS functional components to the FAIR principles to illustrate the extent to which each of the components contributes towards the principles." Journal:Development of an informatics system for accelerating biomedical research

Restricted or personal information while still being FAIR

• Journal:FAIR Health Informatics: A health informatics framework for verifiable and explainable data analysis
• Journal:Restricted data management: The current practice and the future

• Linking databases of data that haven't seen proper "FAIR-ification" and metadata handling won't be as useful.
• Further discussion on data quality in the scope of FAIR: Journal:Towards a contextual approach to data quality