dataesr/scientific-paragraphs-categorization huggingface dataset:
Comparative Genomics Assembled genomes of three PA7-related strains, i. e. , EML528, EML545 and EML548 used in this study have been deposited at DDBJ/EMBL/GenBank under the following accession numbers: LFXS00000000. 1 for EML528, LGJE00000000. 1 for EML545, and LFXR00000000. 1 for EML548  (Boukerb et al. , 2015). These genomes were aligned against the PAO1 and PA7 genome sequences using Mauve (v2. 3. 1; http://asap. genetics. wisc. edu/software/mauve/). The Magnifying Genome platform (MaGe, http://www. genoscope. fr/agc/mage/) was used to compare CDS contents and analyze some other features  (Vallenet et al. , 2013). Comparative analyses of lecA and lecB genomic regions among PAO1, PA7, and related strains were performed using ACT (Artemis Comparison Tool) at http://www. webact. org. RGP (regions of genomic plasticity) among these regions were detected by looking for synteny breaks due to an integration of DNA pieces above 900 bp.
Microcalorimetry Recombinant LecB PA7 was dissolved in a 20 mM TrisHCl, pH 7. 5, NaCl 150 mM, 100 µM CaCl 2 buffer. Carbohydrate ligands were dissolved in the same buffer, degassed, and loaded in the injection syringe. ITC was performed using ITC200 microcalorimeter (Malvern Instruments, UK). The LecB PA7 solution was placed in a 200 µL sample cell at 25 • C. Titration was performed with 20 injections of 2 µL carbohydrate ligands every 120 s. The experimental data were fitted on a theoretical titration curve using the "Origin" software (RITME Informatique, France), with H (enthalpy change), K a (association constant) and n (number of binding sites per monomer) as adjustable parameters. Free energy change ( G) and entropy contributions (T S) were derived from the equation G = H -T S = -RT ln K a (with T as the absolute temperature and R = 8.
Protein Crystallography Crystals of LecB PA7 complexed with Lewis a tetrasaccharide (Elicityl, Crolles, France) were obtained by the hanging drop vapor diffusion method using 2 µL of drops containing a 50:50 (v/v) mix of protein and reservoir solution at 19 • C. The protein at 10 mg/mL in 20 mM HEPES pH 7. 5 and 1 µM CaCl 2 was incubated with the ligand at 10 mM during 1 h at room temperature prior to co-crystallization. Crystal plates were obtained in 2 days from solution containing 14% PEG6000, 0. 2 M lithium chloride, and 0. 1 M sodium acetate pH 4. 6. Plates were transferred in a solution where PEG6000 concentration was increased to 26% for cryoprotection prior mounting in a cryoloop and flash-freezing in liquid nitrogen. Diffraction data were collected at 100 K at the European Synchrotron Radiation Facility (Grenoble, France) on beamline BM30A using a ADSC Q315 CCD detector.
Bacterial Aggregation Assays through Imaging Flow Cytometry Analysis Aggregation assays were performed according to  Boukerb et al. (2014)  but aggregates were visualized and analyzed by Amnis FlowSight R cytometry. Image acquisitions and analyses were performed with the ImageStream system (Amnis Corporation, Seattle, WA, USA) and the ImageStream Data Exploration and Analysis Software (IDEAS, Amnis). P. aeruginosa cells were exposed to 100 µM glucosylated, mannosylated, galactosylated, and fucosylated glycoclusters calix[4]arene ligands obtained from  Boukerb et al. (2014)  (Supplementary Figure  S1 ). Results were compared with those obtained from PBS and monovalent ligands. For each condition, the aggregation properties were analyzed over 20,000 cellular events. Kruskal-Wallis rank sum tests were used to determine conditions favoring the formation of the highest number of bacterial aggregates.
RESULTS Prevalence and Diversity Of lecA and lecB lecA and lecB databases were built by retrieving the P. aeruginosa sequences available at GenBank and at the Pseudomonas Genome database  (Winsor et al. , 2015)  and by performing lecA and lecB PCR screenings over a collection of environmental and clinical strains (Figure  1  and Supplementary Figure  S2 ). A total of 292 PCR products from 147 strains were sequenced (Supplementary Tables  S1, S2 ). DNA blot analyses were performed to verify PCR false-negative results (data not shown). Most strains showed PCR products of the expected size. Two strains (poe1196 and poe1293) yielded lecA PCR products of about 2 kb, and were found harboring an ISPsp4-like element which is part of the IS30 family (Supplementary Table  S1 ). This IS was inserted at lecA nucleotide position 288 (according to PA2570 numbering).
Comparison of Affinities between LecB PA7 and LecB PAO1 Purified LecB PA7 produced in E. coli were assayed on the Glycan Array v5. 2 from the Consortium for Functional Glycomics (n = 609 glycans). Only glycans with terminal fucose or mannose residues were recognized by the lectin. Stronger signals were obtained for biantennary glycans that present fucosylated epitopes at the top of two long chains, then to multiple branched glycans with several fucose residues such as Lewis y epitope (Supplementary Table  S6 ). Data previously obtained for LecB PAO1 (on 465 glycans, available on CFG web site) on epitopes containing only one terminal fucose or mannose residue were extracted and compared with those of LecB PA7 (Figure  3  and Supplementary Figure  S5 ). LecB PA7 recognized more efficiently fucose when present on position 2 of galactose as in blood group O/H, and on position 3 and 4 of Nacetylglucosamine (GlcNAc) as in Lewis x (Le x ) and Lewis a (Le a ) epitopes.
Some of these RGP matched DNA segments smaller than 5 kb but were confirmed, in some instances, to be targets for longer genetic elements e. g. , RGP90. The lecB loci genomic environments were not subjected to similar large scale rearrangements but rather to small ones (up to 16 kb). The α genomic region harboring lecA showed: (1) an inverted and distantly positioned DNA region between the PAO1-UW (3,028,630-3,077,236) and PA7 (4,096,626-4,144,187) and alike genomes (top arrowhead on Figure  5 ) including an additional 116 kb DNA segment among the EML545 genome that did not match other sequences in the databases; (2) RGP29 (see asterisk on Figure  5 ) in EML528 harboring the PAGI-2 genomic island (Supplementary Figure  S8A ); PAGI-2 was also observed in EML548 but at a distinct genomic position (2,254,558-2,359,617; Supplementary Figure  S8B);  (3) RGP94 shown to be colonized by a DNA segment of 49.
LecB cluster III strains yielded significantly higher numbers of aggregates when exposed to Calix-Fuc 4 and Calix-Glc 4 than monovalent sugars (Figure  7  and Supplementary Figure  S12 ). However, significant differences could not be obtained using Calix-Man 4 even though, in average, higher numbers were measured. Interestingly, for cluster II and III strains, glucosylated glycoclusters were found inducing aggregation, and sometimes at levels higher than those observed with fucosylated, mannosylated, or galactosylated glycoclusters (Supplementary Figure  S12 ). All these datasets are in line with a role of lectins in P. aeruginosa aggregation properties. However, other adhesins or cellular products appeared to be involved.
These assays were performed on P. aeruginosa strains of (A) LecB cluster I (PAO1, its isogenic mutants PAO1 lecA and PAO1 lecB, bpoe1643 and GR23), (B) cluster II (PA14, bpoe1392, bpoe1737 and bpoe1748), and (C) cluster III (PA7, EML528, EML545 and EML548) (according to Figure  1 ). Aggregation levels were recorded from 20,000 cellular events. All tests were at least triplicated. Letter codes indicate the statistical significance of the tests. A same letter code indicates the absence of significant difference between the data sets (p > 0. 05), and a distinct letter code indicates significant differences (p < 0. 05). Each black bar in a box shows the median value in terms of number of aggregates obtained for all the tests that were performed. measured for LecB PA7 when binding to sugars than LecB PAO1.
FUNDING This work was partly funded by  Anses  project " pyo-eau " # 2011/1/137  of the " Programme Environnement-Santé-Travail " (French Ministers in charge of ecological and environmental issues). We thank the  CNRS, Université Lyon 1, VetAgro Sup, Cluster "Infectiology" of the Rhône-Alpes region, and Labex IMU (Intelligence des Mondes Urbains) (France)  for having funded parts of this work. Parts of this work were also funded by the  French Fond Unique Interministériel  (managed by  Oseo and DGCIS) ,  FUI  anti-pyo,  Labex ARCANE  ( ANR-11-LABX-0003-01 ),  COST Action CM-1102 MultiGlycoNano , and the  Conseil Régional Rhône-Alpes. AB, AI, and BC acknowledge support from  GDR Pseudomonas.
The tip Triple Mutant Exhibits Shorter Roots at 11 d after Germination Since AtTIP genes are expressed in elongation zones, the lack of the most highly expressed isoforms could result in a deficiency in cell elongation. As we did not observe any difference in hypocotyl elongation between the different tip mutant lines compared with the wild type (data not shown), we decided to focus on root growth. No root growth phenotype was previously reported for tip1;1  (Schüssler et al. , 2008; Beebo et al. , 2009)  and tip1;2  (Schüssler et al. , 2008)  single mutants, suggesting a possible functional redundancy of AtTIP isoforms. However, if AtTIPs are important for root growth processes, coinciding mutations in several AtTIP isoforms might cause growth phenotypes. Seedlings of the single tip1;1, double tip1;2 tip2;1, and triple tip1;1 tip1;2 tip2;1 mutants were grown on vertical half-strength Murashige and Skoog plates containing 1.
In some seedlings of the tip1;2 tip2;1 and tip1;1 tip1;2 tip2;1 mutants, LRPs still remained in stage II, in contrast to the wild-type plants, where the earliest LRP stage found was V. These data strongly indicate an important role of AtTIPs in LRP development. The nonadditive response of the single, double, and triple mutant lines suggests a complex interplay of different AtTIP isoforms during this process. To verify that the delay in LRP development was due to the T-DNA or transposon insertion in AtTIP genes, we included another independent batch of single tip mutants in our analysis, tip1;1-2, tip1;2-2  (Schüssler et al. , 2008) , and tip2;1-2, which were used to obtain the triple tip mutant. The T-DNA or transposon insertions in these lines were verified by PCR on genomic DNA (Supplemental Fig.
Plant Material and Growth Conditions The Arabidopsis (Arabidopsis thaliana) tip1;1 mutant is a T-DNA insertion mutant from the Salk Institute collection  (Alonso et al. , 2003)  and was obtained from the Nottingham Arabidopsis Stock Centre (NASC) (seed stock N519003). The Arabidopsis tip1;2 and tip2;1 mutants were previously identified in the SLAT collection  (Tissier et al. , 1999)  using the Sequenced Insertion Site database, and seed stocks (N116827, N118785) were obtained from the NASC. The tip1;2 and tip2;1 mutants display a dSpm insertion within the first and second exons, respectively (Supplemental Fig. S1 ). RT-qPCR experiments showed that AtTIP1;2 and AtTIP2;1 mRNA levels were reduced to less than 3% in tip1;2 and tip2;1 mutants, respectively, compared with the level in wild-type plants (data not shown).
Accession Numbers Sequence data from this article can be found in the Arabidopsis Genome Initiative of GenBank/EMBL databases under the following accession numbers: AtTIP1;1, At2g36830; AtTIP1;2, At3g26520; AtTIP1;3, At4g01470; AtTIP2;1, At3g16240; AtTIP2;2, At4g17340; AtTIP2;3, At5g47450; AtTIP3;1, At1g73190; AtTIP3;2, At1g17810; AtTIP4;1, At2g25810; AtTIP5;1, At3g47440; ACT1, At2g37620; TUA4, At1g04820; UBQ10, At4g05320; and MAF5, At5g65080.
V iewers "know" how to visualize their target classes and will produce a list of V iews. Each V iew can then be displayed in one or more environment, such as the desktop or web application. opens a project and select a given protocol, fills its parameters and execute it. (B) Inputs selected by the user are validated and the P roject updates the protocol information and prepares the files required for execution. The protocol process is created by the P roject or by a jobs management system. (C) The protocol process loads its own database and starts executing the list of steps. The protocol progress is constantly monitored by the P roject. 64  Chapter 1.
The introduction of direct detection devices (DDDs) has made a fundamental difference in image acquisition quality, enhancing the resolution achieved by previous image-recording media, such as photographic films or charge-coupled devices. Moreover, computer power has increased significantly through the use of multi-core machines, clusters, graphics cards and even the use of cloud computing. All these combined developments have allowed more computationally intensive methods, larger datasets and more challenging biological questions to be posed. The evolution of cryo-EM has been intrinsically related to the development of scientific software for image processing. The number of programs available for the community have notably increased over the years. Nevertheless, software development for 3DEM has been focused in the scientific side neglecting in many cases good basic softwareengineering practices.
In this thesis I address essential software problems in the field including: interoperability, traceability, reproducibility, data management, automation and distributed computing. This work describes the design and implementation of a new software framework, Scipion, that models image processing in electron microscopy allowing the integration of several 3DEM software packages under a unified interface for both biologists and developers. The next section of this chapter summarizes the standard workflow used in single particles analysis. After that, I briefly introduce the problem of software interoperability in cryo-3DEM, followed by the problems of reproducibility and automation. Chapter 2 states the objectives of this work, while Chapter 3 presents a review of the relevant literature, classified in two groups:  (1)  the evolution of software packages in the 3DEM community and, (2) general workflow systems in bioinformatics and related fields.
One important aspect in the FSC definition is the assumption of the noise independence in the two maps. This condition is difficult to meet in practice and it is often compromised by refining a single dataset while evaluating the FSC with two volumes computed from half-subsets of the dataset. In 3DEM, the "resolution" is a somewhat arbitrarily chosen cut-off level of the SNR or FSC curve  [31] [32] [33] [34]. One of the main drawbacks of the FSC is that it does not explicitly test for the validity of the reconstructions and that some processing steps improve the nominal value of the resolution without improving the alignment parameters  [35]. Another common issue in currently used refinement procedures is their tendency to overfit the data  [36] , where some features emerge in the map due to the alignment of noise.
Ease of Use and Extensibility The proposed solution should also benefit software developers in the 3DEM community by providing an integrative framework with built-in tools. The system should be easy to extend to allow quickly incorporation of new algorithms emerging in the field. In that sense, the task of adding a new algorithm should be as easy as possible without the need of a deep understanding of the internal implementation. It is desired to provide scientific developers with an API to store/retrieve data without requiring knowledge about database or more complex mechanisms. Chapter 3.
The SPIDER scripting mechanism allowed the development of applications to deal with a large number of images, which also involved a complex set of mathematical operations. Moreover, users could design the processing path through the use of batch scripts, even without a strong background in scientific programming. In SPIDER, users can invoke any operation interactively at the command line prompt. Commands are two-letter codes (usually mnemotechnic, e. g. , "CP" for copying) that may be modified by an option separated by a blank (e. g. , "CP PDB" -import from protein data bank). The interactive mode is the standard way for dealing with a limited number of images while developing a processing scheme. However, a reconstruction often involves manipulation of larger datasets in a complex and partially repetitive sequence of operations.
Other operations on document files, such as sorting, are also available. Originally SPIDER contained all the code for the system, including calls to various graphics devices. With the arrival of graphical user interfaces (GUI) and standardization on the Motif/XWindow system, it became difficult to integrate interactive graphics into a command-oriented program such as SPIDER. This problem was addressed by the development of WEB, an independent "image viewer"  [53]. After that, SPIDER was exclusively used for operations which do not require, or benefit from, visual interaction, whereas WEB was used for those operations. Users typically launched SPIDER scripts from the command line while simultaneously analyzed the results in a WEB session. Both components used a common data format, so that files could be interchanged be- USCF Chimera  [74] , VMD  [75] , and PyMOL  [76] , among others.
SPIRE monitors executing processes and, after finishing, checks if expected outputs where generated and add them to an internal project database. The list of successfully executed batch files is displayed in the Project Viewer, as well as output files generated by each one. When a new project is started in SPIRE, a dialog allows to enter some information related to the project. The set of batch files used and its directory structure can be defined in some XML (eXtensible Markup Language) configuration files, which also control the arrangement of the GUI widgets. A series of batch files can be saved to a list and executed automatically, one after each other, until all are finished or an error halts the process. SPIRE also allows to edit a batch file in an automatically-generated GUI,.
State of the Art but only if the script contains a header following certain rules. Apart from the benefit of the generated GUI, the header constrain encourage the good practice of separating input/output variables from the processing commands in the batch file. SPIRE stores the output files into an internal project database, which is not synchronized with the system files on disk. In the project view, only the files in the database are shown, while the SPIRE's file browser allows one to see files on disk. SPIDER procedures usually produce two types of data: document files (text files with columns of values) and binary files (2D images, 3D volumes and Fourier transforms). In the SPIRE's Options section is possible to associate different viewers (external programs) for these type of files. Document files are commonly displayed in a text editor, while image files are sent to an image/volume viewer.
It also supported parallel processing on clusters, SMP supercomputers or sets of individual workstations. Despite the package had a tiered architecture, after many years of development (original in Objective-C, then C++ and later Python bindings) there was no clear organization to incorporate new features  [47]. The need of a complete re-factoring became clear during the collaboration with the PHENIX project  [81]. Many of the necessary features to take the next steps could not be incorporated into the original EMAN1 design  [47]. The EMAN2 refactoring was focused in providing extensibility, a complete Python interface, introspection capabilities for GUI integration, metadata management and built in unit-testing. All the command-line programs were ported from C++ to Python, a more flexible language.
Another huge re-factoring of the package was finished in 2013, which led to a new major release, Xmipp 3. 0  [54]. This version introduced notable improvements in terms of project management, core libraries, GUIs, image formats and standardization. In Xmipp 2. 4 there was no clear concept of a project. While there was a folder with a set of Python protocols for each type of execution, there was no formal relationship among the scripts. In Xmipp 3. 0, the processing pipeline was organized around projects, composed of protocol runs. A single database contained all the information related to a given project, but only the metadata, since image files were not stored in the database. The SQLite library [90] was used for the project database, avoiding the need to setup a dedicated server. Projects could easily be moved among computers by simply copying the project folder.
Previous to Xmipp 3. 0, the processing was protocol-oriented: the user launched scripts to perform the required operations. Communication between different protocols was achieved manually, which required that the user know what output files were needed as input for the next protocol. There was also no way to track workflows (that is, which protocols were executed and in which order). In Xmipp 3. 0, protocols were also implemented in Python, but they were divided into more atomic steps (e. g. , functions and program executions) stored in the database. With this approach, users could monitor the progress of a run, restart it from a specific point and validate that the expected results were obtained. Moreover, result files were standardized even more to facilitate inter-communication between protocols.
Appion Till the introduction of Scipion, Appion was the only platform that allows real integration among software packages  [45]. Appion is tightly connected with a previous project by the same group, Leginon  [92] , a system for automated data acquisition that tracks and records all microscope parameters associated with every acquired image into a MySQL database  [93]. This provides a straightforward method for comparing and contrasting datasets acquired during different microscope sessions. Similar to Leginon, Appion was implemented primarily in Python, providing interpackage compatibility through generic "wrappers" for numerous software tools used by the EM community. Functions from SPIDER, EMAN, Frealign, Imagic, FindEM, Xmipp and Matlab were all incorporated into the first Appion prototype.
One of the reasons to choose Python, a powerful and easy to learn language, was to quickly incorporate new tools into the pipeline. One of the cornerstones of the Appion system was the underlying database, which contained all the processing information and provided the links between disparate packages. The creation and maintenance of this database was based on the Sinedon library, which provided an automatically adaptive database structure, that also supported the Leginon and Project databases. The Appion database was relationally linked to these other databases such that information could be traced back from every point of processing. The Project database stored global data associated with the overall biological project, the Leginon database primarily stored information related to the raw data, and the Appion database stored all the parameters, inputs, and outputs from every processing step.
The Sinedon library was based on the concept of object-relational mapping (ORM), which refers to transferring objects from a programming language to a database system. With this library, new tables could be created on-the-fly from Python scripts, as well as launching different queries. Through Sinedon, Appion developers are not required to write SQL queries. The Appion database, which consists of nearly 100 tables and which is constantly being modified and extended as new procedures are added to the pipeline, does not require any manual maintenance. The underlying database is essential to streamline the reconstruction process and to integrate disparate software tools, as well as to track and manage the metadata generated in each step. The Python based wrapper scripts in Appion use the classes defined in appion/Data.