dataesr/scientific-paragraphs-categorization huggingface dataset:
Materials & Methods In silico analysis of TMP TP901-1. The Genbank accession number for TP901-1 is NC_002747. The sequence of TMP TP901-1 , corresponding to the product of ORF45, was manipulated using DNASTAR software package (Version 7. 2, 2007; DNASTAR Inc. , Madison, WI). Repeat sequences in TMP TP901-1 were deduced by manually aligning Trp and Phe residues with 11 or 18 amino acid periodicity. Hydrophobic and predicted transmembrane domains were identified using TMHMM  35  , while protein transmembrane topology was characterised using TOPO2  36. The secondary structure of TMP TP901-1 was predicted using SABLE  37  and alignment of TMP amino acid sequences was performed using ClustalW  38. Bacterial strains, phages and growth conditions. Bacterial strains and phages used in this study are listed in Table  1.
Acknowledgements JM is in receipt of a  Technology Innovation Development Award (TIDA) (Ref. No. 14/TIDA/2287 ) funded by  Science Foundation Ireland (SFI). MA is funded by a  King Abdullah scholarship. DvS is supported by a  Principal Investigator award (Ref. No. 13/IA/1953 ) through  Science Foundation Ireland (SFI). The authors gratefully acknowledge  J. P. van Pijkeren  from the  University of Wisconsin-Madison  for supplying pJP005 for the recombineering mutagenesis.
Image Acquisition and Analysis Transmitted light images of spheroids were acquired using a routine microscope. Fluorescence images of 5μm spheroid cryosections were acquired using a DM5000 (Leica) epifluorescence microscope, fitted with a Roper COOLsnap ES CCD camera. Images were processed using the Metavue and ImageJ software packages. Before automated analysis, images with artefacts were manually corrected. Specifically, parts of other spheroids, due to the sectioning process, or staining background and debris were removed using the clearing function of Image J.
Acknowledgments We are very grateful to  Luc Sensébé  ( French Blood Institute, Toulouse ) and his lab members for access and support in using their "hypoxia" facilities. We thank  Paul Escande  for discussions on the simulation model, the members of our groups for discussions and interest in this project and the  TRI-Genotoul  and ITAV imaging facilities. The authors wish to acknowledge the expert assistance of  Elisabetta Andermarcher  in editing this manuscript. This work was supported by the  CNRS ,  Université Paul Sabatier ,  Région Midi-Pyrénées ,  ITMO Cancer AVIE-SAN (Alliance Nationale pour les Sciences de la Vie et de la Santé, National Alliance for Life Sciences & Health)  within the framework of the  Cancer Plan , and  Agence Nationale de la Recherche ANR  ( 12-BSV5-0008-01 ).
VCF files may contain information on tens of millions of variants, for thousands of individuals. Having to manage such significant volumes of data involves considerations of efficiency with regard to the following aspects: 1. Filtering features. Such data can be processed by applications like VCFtools  [8] , GATK  [9] , PyVCF  [10] , VariantAnnotation  [11]  or WhopGenome  [12]  to query, filter and extract expertized datasets for day-to-day research. However, these tools are limited to command line or programmatic application programming interfaces (APIs) targeted at experienced users, and are not suitable for nonbioinformaticians. 2. Storage performance. Working with flat files is not an optimal solution in cases where scientists need to establish comparisons across projects and/or take metadata into account.
The use of relational databases is still widely prevalent within the range of more integrated approaches. However, such solutions have limitations when managing big data  [13]. In computational environments with large amounts of heterogeneous data, the NoSQL database technology  [14, 15]  has emerged as an alternative to traditional relational database management systems. NoSQL refers to nonrelational database management systems designed for large-scale data storage and massively parallel data processing. During the past 5 years, a number of bioinformatics projects have been developed based on NoSQL databases such as HBase  [16, 17] , Hadoop  [18] [19] [20] , Persevere  [21] , Cassandra  [22]  and CouchDB  [23]. been developed for the graphical visualization of genomic variation datasets. Some of these have been integrated into data portals associated with specific projects (e.
g. OryzaGenome  [24] , SNP-Seek  [25] ) and are, therefore, only relevant to a particular community. Generic tools also exist (e. g. vcf. iobio  [26, 27] , JBrowse  [28] ) and may be built upon to create more versatile applications. The Gigwa application, the name of which stands for 'Genotype investigator for genome-wide analyses' , aims to take account of all of these aspects. It is a web-based, platform-independent solution that feeds a MongoDB [29] NoSQL database with VCF or HapMap files containing billions of genotypes, and provides a web interface to filter data in real time. In terms of visualization, the first version includes only an online density chart generator. However, Gigwa supplies the means to export filtered data in several popular formats, thus facilitating connectivity with many existing visualization engines.
Application description A single instance of the Gigwa application is able to display data from multiple databases, which can be chosen from a drop-down menu at the top of the page. A database may syndicate any source of genotyping data as long as the variant positions are provided on the same reference assembly. Gigwa supports work on a single project at a time (although a project may be divided into several runs, in which case new data connected to existing individuals are seen as additional samples). Project selection may be changed from within the action panel (Fig. 1 ) that sits to the right-hand side of the screen. This panel also enables the launch of searches, toggles the availability of browsing and exporting functions (because limiting the initial approach to the counting of results saves time), configures and launches the export, checks the progress of ongoing operations, and can terminate them if required.
Data export and visualization The Gigwa application offers seven standardized formats (VCF, Eigenstrat, GFF3, BED, HapMap, DARwin and PLINK) in which to export filtered results in compressed files. Export is individual-based. Thus, if the data selection includes several samples that belong to the same individual, only one genotype per variant is exported. If these genotypes are inconsistent, the one most frequently found is selected. If there is no most frequently found genotype, one is picked at random. Where data that originated from VCF files is being reexported in the same format, the application takes phased genotypes into account: a procedure was implemented to maintain phasing information (i. e. haplotype estimation) in the database and recalculate it at export time, even if intermediate positions had been filtered out.
Exports can be directed either to the client computer or to a temporary URL on a web server, thus making the dataset instantly shareable, for example, with Galaxy  [32]. Such links remain active for a week. In addition, when applied to the VCF format, this 'export to URL' feature provides the means for users to view selected variants in their genomic context in a running instance of the Integrative Genomics Viewer (IGV)  [33]. The current selection may also be directed to an online, interactive, density chart viewer. The variant distribution of each sequence may then be observed, with the ability to filter on variation type, and these figures can also be exported in various file formats (i. e. PNG, JPEG, PDF and SVG).
Technical insights Third-party software involved MongoDB [29] was chosen as the storage layer for several reasons: its complex query support, its scalability, its open-source nature and its proactive support community. The server application was developed in Java and takes advantage of several Spring Framework modules  [34]  (e. g. Spring Data). The client interface was designed using Java Server Pages (JSP) and jQuery  [35]. Some import and export procedures make use of the SAMtools HTSJDK API v1. 143  [36]. The density visualization tool was implemented using the HighCharts Javascript library  [37].
Data structure The data model for storing genotyping information, defined using Spring Data documents, is shared with the WIDDE application  [21]  and allows a single database to hold genotypes from multiple runs of multiple projects. This model is marker-oriented and mainly relies on two basic document types: VariantData, which embeds variant-level information (e. g. position, marker type); VariantRunData, which contains genotyping data along with possible metadata. A collection named taggedVariants is not tied to a model object because its documents only contain variant IDs. However, it serves an important purpose by providing dividers ('landmarks') that partition the entire collection of variants into evenly sized chunks. These chunks are then used when querying directly on the Varian-tRunData collection (i.
Querying strategy When the Search button is clicked, the values selected in the search-interface widgets are passed to the server application. They may then be used to count and/or browse matching variants. The first time a given combination of filters is invoked, the count procedure is launched to establish the number of variants that match the combination. This result is then cached in a dedicated collection so that whenever a user subsequently repeats the same search, the result will be available instantly. Once the count result has been displayed to the user, if the 'Enable browsing and exporting' box is checked, a second request is sent to the server, invoking the find procedure that eventually provides paginated, detailed variant information in the form of a comprehensive table. In general, serving such requests (count or find) may be divided into two consecutive steps: a simple, preliminary query of variant features (variant type, sequence, start position), which is applied to indexed fields and therefore executes quickly; the main aggregation query, which is split into several partial queries aimed at running in simultaneous threads on evenly sized variant chunks of the VariantRunData collection.
This technique not only improves performance, but also allows Gigwa to provide a progress indicator and the facility to terminate a run before it has finished. The method used for dividing the main query depends on whether or not a preliminary filter was executed beforehand. If it was, the application holds a subset of variant IDs as a consequence, which it uses to split the data using MongoDB's $in operator in each subquery. Otherwise, the contents of the taggedVariants collection are used, in conjunction with the $lte (less than or equal) and $gt (greater than) operators, to define the limits of each sub-query's chunk. MongoDB configurations gave response times showing high degrees of heterogeneity. In order to establish more distinction between them, these benchmarks were therefore executed 12 times.
Benchmark results In the case of the location-based filter benchmark (Fig. 4 ), the MySQL solution was the fastest, with response times that were negligible on the smallest dataset, and never more than 0. 05 s on the largest. In comparison, Gigwa queries were less responsive but still remained fairly fast, never taking more than 0. 3 s on the largest dataset. However, VCFtools proved so much slower than all the other alternatives benchmarked that we had to exclude its last record for the plot to remain readable. This difference can be explained by the fact that database engines typically take advantage of prebuilt indexes that lead directly to results, whereas VCFtools has to scan the entire file. Relational databases are usually the most efficient for this kind of simple query because their indexing mechanisms have been optimized over decades.
In the case of the MAF filter benchmark (Fig. 5 ), the fastest solution was VCFtools, followed by the two most compressed MongoDB databases (Gigwa-WT-zlib and Gigwa-WT-snappy), and then by the two least compressed MongoDB databases (Gigwa-MMapv1 and Gigwa-WT-none). The MySQL engine performed so poorly here that it was considered unnecessary to run the longest query on it. In practice, the type of analysis involved in this particular benchmark requires that all stored positions be scanned. VCFtools excels here because it is a C++ program working on flat files, which means that the time needed to access each record is negligible, whereas database engines need to obtain/deflate objects before manipulating them. In contrast to the situation seen in the first filter benchmark, a significant difference in performance emerged here between the various storage solutions offered by MongoDB.
Conclusions We developed Gigwa to manage large genomic variation data derived from NGS analyses or high-throughput genotyping. The application aims to provide a userfriendly web interface that makes real-time filtering of such data, based on variant features and individuals' genotypes, widely accessible. Gigwa can be deployed either in single-user mode or in multi-user mode, with credentials and permissions allowing fine-grained control of access to connected databases. We ran benchmarks on two kinds of queries -variantoriented and genotype-oriented -to compare Gigwa's performance with that of both VCFtools and a standard MySQL model. Each of these latter tools performed best in one benchmark but by far the worst in the other. Gigwa, when configured with the WiredTiger storage engine and either the snappy or zlib compression level, appeared as an excellent compromise, performing almost as well as the best solution in both benchmarks.
Future versions of Gigwa will include a RESTful API to allow external applications to interact with Gigwa and query data in a standardized manner, as well as additional visualization tools and a Docker  [40]  package aimed at distributing the tool as a solution capable of functioning in platform-as-a-service (PaaS)  [41]  mode. Further benchmarks will be conducted to evaluate the application's performance in a distributed environment using MongoDB's sharding functionality.
Acknowledgements This project was funded by  UMR DIADE and Agropolis Fondation  under the reference ID ARCAD  0900-001. The authors thank the  South Green Platform team  for technical support,  Sébastien Ravel  for testing the annotation filters,  Francois Sabot  and  Mathieu Rouard  for meaningful advice, and  Aravind Venktesan  and  Jean-Marc Mienville  for careful reading that helped improve the manuscript.
Availability and requirements Project name: Gigwa Project home page: http://www. southgreen. fr/ content/gigwa Operating system(s): Platform-independent Programming language: Java & MongoDB Requirements: Java 7 or higher, Tomcat 7 or higher, MongoDB 3 or higher License: GNU GPLv3 Restrictions to use for non-academics: None Availability of supporting data Gigwa's source code is available in South Green's public GitHub repository  [42]. Supplementary data, benchmarking material and installation archives can be found in the GigaScience GigaDB repository  [43].
Data collection and clinico--pathological features of employed case series All downloaded datasets were checked to verify that only profiles from primary invasive breast cancer receiving no pre--surgery treatment were included. Samples not satisfying such criteria, cell line and normal tissue profiles were removed. Data were also checked for the presence of replicated CEL files uploaded with different GSM ID and redundancy was removed. Datasets were grouped in four main collections (GENERIC, PROGNOSTIC, TAM and CHEMO) according with available information and treatment received by patients. All relevant clinico--pathological features were equalized and summarized in Supplementary Tables 1--3 for the last three collections.
Data processing using alternative CDFs CEL files were imported using the affy Bioconductor package  [1]  and normalized using fRMA  [2]  with an alternative CDF as previously described  [3]. Such method was specifically optimized to process GEPs from FFPE samples, but we have highlighted an improvement also in the downstream analysis of GEPs obtained from frozen tissues. Moreover, since both the GeneChip Human Genome U133 Plus 2. 0 and U133A were used in this study, we defined here a new alternative CDF (named RefSeq_common) using only probes unambiguously mapping a RefSeq transcript and common to the two chip versions. A total of 11782 probesets (one probeset per gene) was generated. To validate the consistency of signals from the same probesets measured with the two chip versions (i. e. U133A and U133 Plus 2.
0), a dataset (GSE17700) containing 16 breast cancer samples profiled by two different labs and, in each lab, using both U133A and Plus 2. 0 was evaluated. Probeset correlation across the samples was very high, with a median value of 0. 901 (Supplementary Figure  1 ). Notably, the agreement between U133A and Plus 2. 0 data was much higher using our normalization approach than when using MAS5 normalization together with the standard CDF (median correlation = 0. 656) (Supplementary Figure  1 ).
Development of metagene--based predictors of ER and HER2 status For the training of an ER status predictor, we selected two datasets from the GENERIC collection (GSE5460 and GSE19615, n=169) having an ER status accurately and homogeneously defined by IHC. Area under ROC curve (AUC) was computed for all genes and, starting from the best performing ones, we increased the number of genes to be included in metagene computation until the best AUC was obtained. Best performance was obtained using the top 7 genes (C6orf97, ESR1, EVL, ABAT, SLC39A6, GATA3, SCUBE2) giving an AUC=0. 993. A threshold was defined looking at the bimodal distribution of the metagene as well as looking at the agreement with ER status defined by IHC. Using a cut--off of 7. 5, a Cohen's Kappa value of 0. 925 was obtained. The validity of the threshold was confirmed in the whole GENERIC collection (n=1,186) (Supplementary Figure  2 ).
To further validate the metagene as a sufficiently accurate predictor of ER status, it was applied to both the PROGNOSTIC and the TAM datasets. In the PROGNOSTIC dataset an AUC=0. 927 and Cohen's Kappa of 0. 755 were obtained, that can be judged as high considering that the reported ER status was obtained with either IHC or radio--ligand assay methods using different or not specified thresholds. The prognostic value of ER status defined by our metagene was compared with that of the available ER status using Kaplan--Meier curves and superimposable results were obtained (Supplementary Figure  3 ). In the TAM dataset, where all but 5 samples were labeled as ER positive, 43 samples were classified as negative according to our metagene. All the 5 samples originally labeled as ER negative, were classified as negative by our metagene, and the 43 patients (ER--negative according to our metagene classification) had a significantly worst outcome compared with all the others (Supplementary Figure  3 ), suggesting that at least most of them were actually ER negative and did not therefore benefit from hormone treatment.
An analogous approach was applied to identify HER2 positive tumors. Three datasets from the GENERIC collection (GSE5460, GSE16391, and GSE21653, n=417) were selected to develop the HER2 status predictor. In such datasets, HER2--positive samples were defined as those with IHC score=3+ or FISH positive. An AUC=0. 933 was obtained when using the top 10 genes associated with HER2 status to derive a metagene (ERBB2, PGAP3, STARD3, GRB7, PNMT, PSMD3, GSDMB, RPL19, FGFR4, CAP1), eight of which were in the amplicon region. Looking at the metagene distribution and at the agreement with the available HER2 status, a threshold at 8. 35 was defined giving a Cohen's Kappa=0. 738 (Supplementary Figure  4 ). Finally, by combining the ER and HER2 status prediction in the PROGNOSTIC collection we observed for the three groups (ER--HER2--, HER2+ and ER+HER2--) the expected pattern of relapse during the follow--up, that is an early relapse, mostly within 5 years, for ER--HER2--and HER2+ tumors and a quite constant risk of metastasis until 10 years in ER+HER2--cases (Supplementary Figure  5 ).
To allow validation of our findings also in FFPE--derived case series, a re-clustering was also performed in a case series of 44 FFPE samples derived in our lab (GSE38554). As before, genes correlating less than 0. 4 were removed and clusters still containing at least 10 genes were retained. As expected, some of the probesets which were not correlated in FFPE derived GEPs had spurious level of correlations (also negative), that can be only explained by the technical failure of hybridization of the corresponding probes using fragmented FFPE--derived mRNA (data not shown). However, the biological function captured by the cluster will be still accurately measured by the selected well performing probesets. At the end of the two selection steps, 40 of the 45 clusters were confirmed. Guided by Gene Ontology analysis, we picked up among them a T--cell related immune metagene, a metagene related with the proliferation process and a metagene containing ESR1 and ESR1--related genes.
The association with prognosis for the refined proliferation metagene was also validated in the cohort of patients receiving hormone treatment (TAM dataset), both in the same contest of lymph node negative patients and out of context in the lymph node positive group, confirming its independence from lymph node status (Supplementary Figure  9 ). Looking at the Kaplan--Meier curves in Supplementary Figure  9  above, it can be noted that the group of patients with low proliferation tumors has a very good outcome, consequently trying to predict sensitiveness to hormone therapy including such subgroup is disadvantageous from a statistical point of view due to the very low number of events that limit the possibility to identify significant predictive factors. In keeping with this consideration, our approach was to exclude low proliferation ER+HER2--tumors (lower tertile of the proliferation metagene) and to focus on the remaining 394 samples of the TAM collection with intermediate or high proliferation.
Immune metagene prognostic and predictive value in chemotherapy receiving ER--HER2-and HER2+ subtypes Association with treatment response of our CTM in ER--or HER2+ cases receiving neoadjuvant CT was evaluated in two datasets of the CHEMO collection: i) the Horak dataset (GSE41998), where patients received neoadjuvant doxorubicin/cyclophosphamide, followed by 1:1 randomization to ixabepilone or paclitaxel; ii) the Desmedt dataset (GSE16446) where patients only received a single agent treatment (epirubicin). A total of 146 and 114 ER--or HER2+ samples were identified, respectively. High, intermediate and low metagene expression was defined separately in each dataset according with tertiles. In both datasets comparable odds ratios were obtained, with 33% of patients with higher expression of the CTM having a significantly higher rate of pCR (Supplementary Figure  12 ).
The CTM was not evaluated in ER--HER2--and HER2+ samples of the two Hatzis datasets (GSE25055 and GSE25065) because most of these samples were fine needle aspiration (FNA) that are enriched in tumor cells while stromal cells are poorly and variably represented, distorting the evaluation of immune specific genes. We investigated the association with long--term outcome of our CTM in HER2+ tumors (CHEMO collection) after stratifying by ER status (Supplementary Figure  13 ) Association of the CTM with patients' outcome was separately evaluated in: i) Petel dataset (E--MTAB--365) where patients received not homogeneous adjuvant CT and ii) Desmedt dataset (GSE16446) where patients only received a single agent treatment (epirubicin). As before, high, intermediate and low metagene expression was defined in each dataset according with tertiles.