dataesr/scientific-paragraphs-categorization huggingface dataset:
RetroRules b,14 is a searchable database of reaction rules. Reaction rules are generic descriptions of (bio)chemical reactions encoded into the community standard SMARTS. The use of reaction rules allows estimating the outcomes of chemical transformation based on the generalization of reactions available in knowledge DBs such as BRENDA  37  , MetaCyC  38  , Rhea  39  , or MetaNetX  40. The degree of generalization is controlled by describing the surrounding environment of the reaction center up to a given diameter. To ensure the accuracy of the predicted transformations that will outcome from the reaction rules, the RetroRules dataset provided by the Galaxy RetroRules node has been validated by (i) checking that rules allow to reproduce the template reactions, and by (ii) checking that results obtained by decreasing diameters are supersets of results obtained with higher diameters.
Only the reaction rules that successfully passed the 2 checks are retained. The RetroRules dataset provided presently is tagged as rr02 and is freely downloadable from the RetroRules database c. The validation of this dataset has a success rate of 99. 3%. The node outputs a CSV file of reaction rules in SMARTS format. RetroPath2. 0 d is an open-source tool for building retrosynthesis networks by combining reaction rules and a retrosynthesis-based algorithm to link the desired target compound to a set of available precursors  10. Typically, the target compound, also named "source compound" is the compound of interest one wishes to produce, while the precursors are usually compounds that are natively present in a chassis strain. Starting from the source compound at the first iteration, the reaction rules matching the chemical structure of the source are applied and newly predicted chemicals are generated.
For each reaction a score is calculated based on the ability to retrieve enzyme sequences catalysing substrate to product transformations. Newly produced chemicals are scanned and kept for the next iteration if they are not within the set of available precursors. In that way, a new iteration is started using the previously collected chemicals as the new source set. The iterative process stops when either no new chemicals are discovered or the predefined b github. com/Galaxy-SynBioCAD/RetroRules_image, github. com/Galaxy-SynBioCAD/RetroRules c retrorules. org d github. com/Galaxy-SynBioCAD/RetroPath2_image, github. com/Galaxy-SynBioCAD/RetroPath2 number of steps is reached. The node takes as input three CSV files, one with a list of sink molecules using the standard InChI format, another with a single source (target) molecule in InChi format too, and a last file containing the reaction rules in SMARTS format.
The node takes as input a retrosynthesis network in the CSV file produced by RetroPath2. 0, and outputs the enumerated pathways (using IDs) as well as structure of involved chemicals (as SMILES) in CSV files as well. Pathways to SBML and Complete Reactions. The node Pathways to SBML f converts the output of RP2paths, as well as each individual pathway, to distinct SBML files. Those output pathways are "enriched" with additional information (see Method section) that cannot be easily stored as part of a normal SBML file and include structural information for chemical species (SMILES, InChI and InChIKey) and for each reaction a rule ID, a score based on enzyme availability produced by RetroPath2. 0, and the rule itself in SMARTS format. The tools also adhere to the MIRIAM annotation standard for the cross-references of chemical species to public databases  42.
The tool takes the CSV outputs of RP2paths as well as the output of RetroPath2. 0 and outputs a collection of SBML files compressed in a TAR file. The second node, called Complete Reactions g , adds the required cofactors to complete the reactions. Indeed, due to the nature of RetroPath2. 0 retrosynthesis algorithm, the reactions it produces are mono-component 10. To complete reactions, the node queries the MetaNetX database for the appropriate cofactors and adds them to the SBML files. The node takes for input either a single SBML file, or a collection compressed in a TAR. The node produces a collection of SBML files compressed in a TAR file. Thermodynamics h calculates the Gibbs free energy of reactions and heterologous pathways by considering every chemical species involved in each reaction.
This is done using the tool eQuilibrator  43  calculating the formation energy either using public database ID reference (when recognized with the tools internal database), or by deconstructing the chemical structure and calculating its formation energy using the component contribution method. Thereafter, the species involved in a reaction are combined (with consideration for stoichiometry) and the e github. com/Galaxy-SynBioCAD/rp2paths_image, github. com/Galaxy-SynBioCAD/rp2paths f github. com/Galaxy-SynBioCAD/rpReader_image, github. com/Galaxy-SynBioCAD/rpReader g github. com/Galaxy-SynBioCAD/rpCofactors_image, github. com/Galaxy-SynBioCAD/rpCofactors h github. com/Galaxy-SynBioCAD/rpThermo_image, github. com/Galaxy-SynBioCAD/rpThermo thermodynamic feasibility of the pathway is estimated by taking the sum of the reaction Gibbs free energy of each participating reaction.
The node takes as input pathways in SBML format and returns annotated pathways (with thermodynamics information for each reaction, see Methods section for further details) also in SBML format. FBA i (Flux Balance Analysis) is used to calculate target production fluxes of the designed pathways. To perform FBA on a heterologous pathway, this tool first merges a heterologous pathway with a user-specified GEM model. This enables FBA to consider whole-cell conditions for the theoretical production of the user's target molecule. The tool uses the CobraPy package to perform FBA  44. The following native CobraPy methods are supported including FBA and parsimonious FBA (pFBA). The tool also contains an in-house developed method to consider the potential burden that the production of a target molecule may have on the cell and the impact of the target itself.
This feature makes this tool especially useful in combination with RetroPath2. 0. Selenzyme performs a reaction similarity search in the reference reaction database Metanetx  40  and outputs the sequences annotated for the closest reactions. The tool provides several scores that can be combined in order to define an overall score. Scores are given for reaction similarity, conservation based on a multiple sequence alignment of the result, phylogenetic distance between source organism and host, and additional scores calculated from sequence properties. The Selenzyme node takes as input pathways in SBML format and returns annotated pathways i github. com/Galaxy-SynBioCAD/rpFBA_image, github. com/Galaxy-SynBioCAD/rpFBA j github. com/Galaxy-SynBioCAD/rpRanker_image, github. com/Galaxy-SynBioCAD/rpRanker k github.
DNA weaver p devises cloning strategies using either Golden Gate Assembly or Gibson Assembly to obtain plasmids for each combination of genetic parts selected by the OptDoE node. As both assembly methods have practical limitations, the algorithm first considers Golden Gate assembly using the type-2S enzymes BsmBI, BsaI, or BbsI (in this order) and defaults to Gibson Assembly, although this order of preference can be changed by the user. the resulting assembly strategies l github. com/Galaxy-SynBioCAD/rpSelenzyme_image, github. com/Galaxy-SynBioCAD/rpSelenzyme m github. com/Galaxy-SynBioCAD/rpSBMLtoSBOL_image, github. com/Galaxy-SynBioCAD/rpSBMLtoSBOL n github. com/Galaxy-SynBioCAD/PartsGenie_image, github. com/Galaxy-SynBioCAD/PartsGenie o github. com/pablocarb/doebase, github. com/Galaxy-SynBioCAD/rpOptBioDes_image, github.
com/Galaxy-SynBioCAD/rpOptBioDes p github. com/Galaxy-SynBioCAD/DNAWeaver_image, github. com/Galaxy-SynBioCAD/DNAWeaver produce "scarless" plasmids whose sequence is the direct concatenation of the sequences of the plasmid's parts. The node output is a spreadsheet featuring a list of all the primers required to extend the standard genetic parts with sequence homologies necessary for the assembly, and a list of all PCRs and fragment assembly operations required to obtain the desired plasmids. The assembly strategy is optimized to maximize primer reuse between constructs, and optimize assembly homologies, via the DNA Weaver framework  46. LCR Genie q,47 is a web-based tool for supporting the design of bridging oligos, which are required for annealing together individual synthetic DNA parts (designed by PartsGenie) into multi-gene plasmid assemblies, designed by OptDoE.
The LCR Genie node provides a wrapper for this functionality, taking in an SBOL document containing numerous combinatorial plasmid assemblies, and designing bridging oligos necessary for assembly via the ligase cycling reaction method. The LCR Genie node performs analogous functionality to the DNA weaver node (supporting multi-part assembly but by a different experimental method) and as such, its output format matches that of DNA weaver. Pathway Visualizer r provides users an interactive web interface for exploring predicted pathways and their associated annotations. The tool is based on HTML and JavaScript only, which draws it as a "dependency-free" tool easy to set up locally for the user. Possible user interactions are pathway highlighting, cofactor handling, and the viewing of information at the levels of pathways, reactions, and involved compounds.
Building workflows with nodes As described in the above section, the SynBioCAD-Galaxy portal contains a collection of tools that have simple standardized input and outputs. These "nodes" are well documented and intended to perform a single well-defined task. To create more complex tasks, these tools may be chained together. We present three exemplar workflows. q github. com/Galaxy-SynBioCAD/LCRGenie_image, github. com/Galaxy-SynBioCAD/LCRGenie r github. com/Galaxy-SynBioCAD/rpVisualiser_image, github. com/Galaxy-SynBioCAD/rpVisualiser s visbol. org Retrosynthesis and Pathway Enumeration. The workflow (Figure  1 ) generates theoretical possible pathways for the production of a target molecule in an organism of choice. Three key steps are performed in this workflow. First, using the RetroPath2.
These constructions are then used by OptDoE to generate a defined size library of plasmids, expressing at various levels the genes coding for the multiple enzymes present in the predicted pathways. The other genetic parts required by this software (origin of replications, promoters, terminators and markers) are either provided by a default list or a specific list of parts provided by the user which needs to refer to parts stored in SynBioHub. The Galaxy tool "OptDoE Parts Reference Generator" has been written for that purpose. This final library is generated in a SBOL format and can then be used as an input to other softwares or visualised using tools implementing the SBOL visual standard. The Genetic Design workflow ends with two different tools tackling the library construction problematic: LCR Genie that propose an assembly strategy using the Ligase Chain Reaction method and DNA weaver that calculate the optimal synthesis plan and the assembly protocol following either a Golden Gate or a Gibson Assembly method.
Just by focusing on tool categories found relevant to the present manuscript, one can cite proteomics, transcriptomics, metabolomics, flow cytometry analysis, and computational chemistry. Several communities are using Galaxy and many papers can be found online  50  for microbiome (267 items are found as of 07/04/2020), plants (258 items), diseases like cancer (312 items), and drug design and discovery (75 items). However, the library hardly contains references related to biotechnology (4 items) and even fewer to synthetic biology and metabolic engineering. The current offering in Galaxy-SynBioCAD focuses on providing tools for pathway design. However, as Galaxy-SynBioCAD is a community effort, we anticipate our tool set will grow. Regarding pathway design tools, many of the software products listed in the introduction could be considered to be added to the portal.
In particular, strain design including knockout genes to maximize targeted product fluxes, could easily be implemented via the FBA tools making use of Cobrapy (see section 2. 1). Additionally, there are already Galaxy workflows to take up and analyze metabolomics flow cytometry data in ToolShed  36  , and these workflows could directly be incorporated into the portal to deal with data generated in the 'Test' step of the DBTL cycle. As mentioned in the introduction several open source software products deposited in GitHub  [26] [27] [28] [29]  could cover the 'Build' step and eventually provide drivers to automated constructions. Regarding the 'Learn' step in DBTL, the OptDoE tool (cf. section 2. 1) could easily be adapted to propose new designs as it was done in Carbonell et al. , more complex approaches to be considered are methods that make use of machine learning as in Borkowski et al.
Literature Pathways matching algorithm An important requirement in this project is the need to compare two different metabolic pathways, and quantify the degree of similarity between the two. This is used when searching if a literature pathway can be found in a list of pathways produced by our workflows. To this end we wrote a matching algorithm that compares SBML files and calculates a similarity value using the following criteria: • Chemical species ○ Chemical structure (InChiKey) ○ Public database cross-references (MIRIAM) • Reactions ○ Substrates/Products similarity ○ EC number • Pathway ○ Length A more complete description of the algorithm may be found in Supplementary Information. In short, all the chemical species between two SBML pathways are first compared and the best matching ones are coupled ensuring 1:1 matches.
IT Architecture The Tools in Galaxy-SynBioCAD can be used in a stand-alone way or chained into workflows. The source code of each tool is open-source and available in GitHub repositories t. The IT architecture of SynBioCAD is based on the Docker u framework. Each component of this architecture is running with Docker, from web interface to network management. Each container is confined into its own network so that it is not reachable by any other component. To make communications possible between two containers, one of them is put into the other's network by choosing the most secure option. As an example, in order to enable communication between the Galaxy container and a RESTful tool, we have two options: (1) put the tool into the Galaxy container's network or (2) puts the Galaxy container into the tool's container.
Let's say we have several RESTful tools, the first option stores all tools into the Galaxy container's network that enables the communication between tools themselves; which also breaks the network confinement and decreases the global system's security level. The second option preserves the network confinement between tools while making possible communications between each tool and the Galaxy container. In the SynBioCAD framework, we choose the option that optimizes the security for all containers that need to communicate (reverse-proxy/Galaxy, Galaxy/database. ). The overall architecture is illustrated in Figure  6  details regarding Galaxy and tool services are detailed next and an example is provided for RetroPath2. 0. t github. com/Galaxy-SynBioCAD, github. com/brsynth u www. docker. com.
Galaxy Service The main brick is the Galaxy service which is the web interface for end-users and orchestrates tool executions. The Docker Galaxy system is based on the following bricks: (1) Install container runs once and downloads galaxy project sources from the web v. (2) Galaxy container downloads from the web the Galaxy project, and runs it within the galaxy image w. This step is timeconsuming for the first time due to Galaxy's initialization. (3) Database containers are used by Galaxy for users accounts and dynamic web pages. This service is dedicated to Galaxy service. About data storage, each container described above relies on Docker data volumes for storing persistent data. Concerning networking level, the database container is confined into its own network so that, by default, it is not reachable by any other container.
The Galaxy container is v github. com/galaxyproject/galaxy w github. com/brsynth/galaxy_image, github. com/brsynth/galaxy-dind_image confined into its own network so that, by default, it is not reachable by any other container. However, this service is also part of the database service network in order to communicate with it. All these bricks are orchestrated by the Docker Compose tool and embedded in a dockercompose file.
RetroPath2. 0 Service Example RetroPath2. 0 runs as a REST service and is deployed next to the Galaxy container. Its deployment is based on two containers. Install container runs once and downloads data (e. g. RetroRules) into the data volume. REST container is a RESTful container that embeds the tool (through the tool image) and waits for requests. Concerning data storage and networking level, RetroPath2. 0 follows the policy described above. All sources can be found on GitHub and are splitted into two different repositories: (1) Docker image embeds all packages needed for running the tool. In addition, RetroRules data is downloaded within the image and the KNIME Analytics portal is installed. (2) Galaxy wrapper contains the necessary code for displaying the tool web page and to trigger the tool algorithm.
Acknowledgements MdL and JLF acknowledge funding provided by the infrastructure IBISBA ( Horizon 2020  under grant agreement No  730976 ), TD and JLF funding provided by  BioRoBoost (Horizon 2020  under Grant agreement No  820699 ) and  PC, NS  and JLF funding from the  Biotechnology and Biological Sciences Research Council (BBSRC)  and the  Engineering and Physical Sciences Research Council (EPSRC)  under grant ' Centre for synthetic biology of fine and specialty chemicals (SYNBIOCHEM) ' ( BB/M017702/1 ). NS acknowledges further funding from the  BBSRC  under grant 'GeneORator: a novel and high-throughput method for the synthetic biology-based improvement of any enzyme' ( BB/S004955/1 ) and from the  University of Liverpool. PC also acknowledges support from the  Universitat Politècnica de València Talento Programme.
Article Variability in the analysis of a single neuroimaging dataset by many teams Data analysis workflows in many scientific domains have become increasingly complex and flexible. Here we assess the effect of this flexibility on the results of functional magnetic resonance imaging by asking 70 independent teams to analyse the same dataset, testing the same 9 ex-ante hypotheses  1. The flexibility of analytical approaches is exemplified by the fact that no two teams chose identical workflows to analyse the data. This flexibility resulted in sizeable variation in the results of hypothesis tests, even for teams whose statistical maps were highly correlated at intermediate stages of the analysis pipeline. Variation in reported results was related to several aspects of analysis methodology. Notably, a meta-analytical approach that aggregated information across teams yielded a significant consensus in activated regions.
Furthermore, prediction markets of researchers in the field revealed an overestimation of the likelihood of significant findings, even by researchers with direct knowledge of the dataset  [2] [3] [4] [5]. Our findings show that analytical flexibility can have substantial effects on scientific conclusions, and identify factors that may be related to variability in the analysis of functional magnetic resonance imaging. The results emphasize the importance of validating and sharing complex analysis workflows, and demonstrate the need for performing and reporting multiple analyses of the same data. Potential approaches that could be used to mitigate issues related to analytical variability are discussed. Data analysis workflows in many areas of science have a large number of analysis steps that involve many possible choices (that is, "researcher degrees of freedom"  6, 7  ).
Simulation studies show that variability in analytical choices can have substantial effects on results  8  , but its degree and effect in practice is unclear. Recent work in psychology addressed this through a "many analysts" approach  9  , in which the same dataset was analysed by a large number of groups, uncovering substantial variability in behavioural results across analysis teams. In the Neuroimaging Analysis Replication and Prediction Study (NARPS), we applied a similar approach to the domain of functional magnetic resonance imaging (fMRI), the analysis workflows of which are complex and highly variable. Our goal was to assess-with the highest possible ecological validity-the degree and effect of analytical flexibility on fMRI results in practice. In addition, we estimated the beliefs of researchers in the field regarding the degree of variability in analysis outcomes using prediction markets to test whether peers in the field could predict the results  [2] [3] [4] [5].
Variability of results across teams The first aim of NARPS was to assess the real-world variability of results across independent teams analysing the same dataset. The dataset included fMRI data from 108 individuals, each performing one of two versions of a task that was previously used to study decision-making under risk  10. The two versions were designed to address a debate on the effect of gain and loss distributions on neural activity in this task  [10] [11] [12]. A full description of the dataset is available in a Data Descriptor  1  ; the dataset is openly available at https://doi. org/10. 18112/openneuro. ds001734. v1. 0. 4. Seventy teams (69 of whom had previous fMRI publications) were provided with the raw data, and an optional preprocessed version of the dataset (with fMRIPrep  13  ).
The dataset, reports and collections were kept private until after the prediction markets were closed. Overall, the rates of reported significant findings varied across hypotheses (Fig. 1 , Extended Data Table  1 ). Only one hypothesis (hypothesis 5) showed a high rate of significant findings (84. 3%), whereas three other hypotheses showed consistent non-significant findings across teams (5. 7% significant findings). For the remaining five hypotheses, the results were variable, with 21. 4% to 37. 1% of teams reporting a significant result. The extent of the variation in results across teams was quantified by the fraction of teams that reported a result different from the majority of teams (that is, the absolute distance from consensus). On average across the 9 hypotheses, 20% of teams reported a result that differed from the majority of teams.
Factors related to analytical variability To examine the sources of the analytical variability in the reported binary results, we analysed the pipelines used by the teams as well as the unthresholded and thresholded statistical maps they provided. There were no two teams with identical analysis pipelines. After exclusions (Extended Data Table  3b ), thresholded maps of 65 teams and unthresholded (z-or t-statistic) maps of 64 teams were included in the analyses. Fully reproducible code for all analyses of the data reported here is available at https://doi. org/10. 5281/zenodo. 3709273.