dataesr/scientific-paragraphs-categorization huggingface dataset:
SNPs present at least in one-fifth of aligned reads were then considered true positives. SNPs present in homopolymeric region (more than four identical nucleotides) were not considered. The nature of the detected polymorphisms and their frequency are stored as output results (Figure  2F ). Visual checking of the detected and not considered false positives was done using the Tablet software  (Milne et al. 2009)  for ". ACE" alignment files and with the Jalview software  (Waterhouse et al. 2009)  for ". FASTA" files.
Haplotype detection Haplotypes were detected after the SNP detection by identifying and assembling reads sharing the same SNPs. This assembly was performed by comparing each read to all the others and by screening all the SNPs present in overlapping regions. If all the SNPs are identical in this region, the considered reads are assembled to create a haplotype with a maximum size. A unique haplotype is then a sequence characterized by multiple polymorphic sites corresponding to the same and unique The length, position, and GC content of each domain are presented. Genbank accession numbers of the O. sativa and Z. mays sequences used, as well as the percentage of identity and e-value between these and the S. maritima sequences, are mentioned. a 59-ETS was detected using O. sativa genome (v. 204).
allele (Figure  3 ). However, for each alignment, it was necessary to define different windows corresponding to local alignments for counting haplotypes. The windows exhibiting at least one SNP were selected to count the number of locally aligned haplotypes. Two output files allow the dataset visualization: (1) a ". FASTA" file that contains the consensus sequence with the different aligned haplotypes and (2) a tabulated file describing SNPs positions and their nature. A third output file is created during these processes and contains information about the assembly, the name of the contig, the initial and final lengths of the contig obtained after the correction of sequencing errors, the number of reads used to assemble the contig, and the different haplotypes. This file contains the number of SNPs and their position, the number of haplotypes, and their coverage (mean, SD, and C.
SNP validation and haplotype estimation with Illumina data To compare pyrosequencing and cloning SNPs to Illumina SNPs, we mapped 1,263,153 Illumina paired reads with an average read depth of 7886 (SE = 273. 84) on the rDNA sequence consensus of S. maritima using Bowtie2 (score-min: G, 52, 8)  (Langmead and Salzberg 2012). These "score-min" parameters were included in the minimum score function f(x)= 52 + 8 Ã ln(x), where x corresponds to the read length. This function corresponds to a minimum of 87. 06-90. 30% of identity between the mapped reads and the reference sequence for reads with a length of 80-120 bp. The ". SAM" file created by Bowtie2 was converted in a ". PILEUP" format using the Samtools software suite  (Li et al. 2009). We have detected the different SNPs within the Illumina data using custom python scripts (minimum read depth = 30; SNP detection threshold = 2, corresponding to nucleotides that are present more than two out of 100 times per position).
To estimate the relative presence of each haplotype, Illumina reads were mapped on previously detected haplotypes ($100 bp for each region including 59-ETS/IGS, 18S, ITS-1 and 25S) using Bowtie2 (score-min: L, 100, 0; f(x)= 100 + 0 Ã x where x = length of read). Results obtained were filtered using custom python scripts to identify the number of reads mapped with 100% of identity.
Analysis and annotation of the 45S rDNA region The contig obtained with the clustering approach was 8456 nucleotides long; it was assembled from 3219 reads with an average length of 377. 0 bp. Genomic DNA reads of S. maritima were then mapped to the contig with GSMapper (with the following parameters: ml = 100 bp; mi = 95%)  (Margulies et al. 2005) , resulting in a total of 4014 aligned reads with an average length of 506. 8 nucleotides. This step allowed us to build a 45S rDNA reference sequence totaling 8464 bp. The different regions of the 45S rDNA of S. maritima were annotated by homology searches using rDNA sequences from Poaceae species (Zea mays, Oryza sativa) available in GenBank (NCBI) and by motif searches for the 59-ETS region (Table  1 ). The beginning of the 59-ETS region was identified using the TATA-box (59-TATATTAGGGGG-39) motif at position 395, corresponding to the expected plant TATA-box motif (59-TATA(G)TA(N)GGGGG-39), as found in several species such as Zea mays, Oryza sativa, or Arabidopsis thaliana  (Fan et al.
In the noncoding regions, a substitution, the variant presenting substitution and indel at the same position, and two indels were validated using Illumina method in the 59-IGS. In the 59-IGS/ETS noncoding region, a total of 21 polymorphisms were detected using the mapped Roche-454 data, including nine substitutions and 12 indels (two of 4 bp) (Table  3 ). In this region, all the identified substitutions (except one G/T, position 1235) were validated using Illumina data. Within the ITS-1 region, the Roche-454 and Illumina data detected the same SNP (A/T/-) that was validated by (re)-sequencing. However, the indel was only found in the pyrosequencing data. In the 39-ETS/IGS noncoding region, one indel using the Roche-454 data was not validated by Illumina data. Thus, the cloning-sequencing data as well as the Illumina reads substantiated 29 of the 34 polymorphisms previously identified in the Roche-454 reads.
Haplotype detection After rDNA domain annotations and SNP detection and validation, the number of haplotypes for each region of the 45S unit was determined. In this study we retained only the Roche-454 haplotypes constructed with a minimum of 10• read depth. The five indels not validated by cloning and Illumina data were not considered. From the 29 polymorphic sites retained, 20 haplotypes with a mean length of 1197. 70 bp (s = 938. 32; C. I. 95% = 786. 47-1608. 93) were constructed using our program. These haplotypes were constructed from 69. 35 reads on average (s = 66. 24; C. I. 95% = 40. 32-98. 38 ). The 20 different haplotypes were localized on the different rDNA domains as shown in Figure  4. We did not identify any polymorphism in the 5. 8S coding region, the internal transcribed spacer 2 (ITS-2), and the 39 intergenic spacer (IGS).
In the ITS-1/5. 8S/ITS-2, cloning-sequencing data validated the variant detected with the program, and two of three detected haplotypes were validated (Figure  4 , Block III). In the 18S coding region, the two haplotypes detected with the program were validated using Illumina data (Figure  4 , Block II). In the 25S coding region, the two SNPs detected using our program (developed on Roche-454 data) were found with cloning/(re)-sequencing data. Four haplotypes were found with the program and three were validated (Figure  4 , Block IV).
Cloning and sequencing were not performed in the 18S and 39-IGS/ETS regions. (re)-sequencing and also from Illumina sequencing datasets; the results allowed the estimation of the relative proportion of haplotype variation. To date, very few programs or pipelines have been developed to distinguish duplicated copies from next-generation sequencing data without diploid parents as a reference. SNiPloid (Peralta et al. Number of rDNA loci in S. maritima Molecular cytogenetic analysis by FISH revealed the presence of one pair of 45S rDNA signals on the chromosomes of S. maritima instead of the three expected pairs for a hexaploid genome. The number of rDNA loci varies greatly among flowering plants of the same ploidy level. For instance, only one locus was identified in diploid Medicago species  (Rosato et al.
8S; ITS-2; and 25S) using an approach relying on a low-stringency mapping of NGS reads. Detection of the different domains was performed by sequence alignments of 45S rDNA available in the databases of two Poaceae species (maize and rice). Lengths of the rDNA coding regions and ITS of S. maritima are similar to those found in two Poaceae. However, the percentage of GC of the two ITS and 5. 8S coding regions is very low in comparison with other Poaceae (Table  1 ). When examining the GC content of the ITS region in various grass species, we found that some Chloridoideae lineages related to Spartina in the Zoysieae, Cynodonteae, and Eragrostideae tribes similarly exhibit less than 60% GC content (Table  S2 ). In more distantly related Chloridoideae tribes such as Triraphideae and Centropodieae  (Soreng et al.
In summary, our program enables detection of SNPs and haplotypes within NGS read datasets. Haplotype construction and validation are based on three methods/technologies [Roche-454, cloning, and (re)sequencing Sanger method and Illumina approaches] in the context of polyploidy in a nonmodel species where diploid reference parental genomes are not available. The program developed in this study could then be used for any polyploid species (including high ploidy levels) with or without reference genome sequences but also on diploid species (e. g. , for allele detection from amplicon data sets). In the polyploid Spartina genus, which contains various ploidy levels (4•, 6•, 7•, 9•, and 12•), such a program will be useful to detect duplicated homeologous genes and to increase our understanding of their origin and evolutionary fate.
ACKNOWLEDGMENTS We thank two anonymous reviewers for helpful comments on the manuscript. This work was supported by the  International Associated Laboratory "Ecological Genomics of Polyploidy " supported by  CNRS  ( INEE, UMR CNRS 6553 Ecobio), University of Rennes 1, Iowa State University (Ames, USA ), and the  Partner University Funds  (to M. A. , A. S. , J. B. ). The analyses benefited from the  Molecular Ecology Platform  ( UMR CNRS 6553  Ecobio) and  Genouest (Bioinformatics)  facilities. Author J. Boutte  benefited from a PhD scholarship from the  University of Rennes 1.
n Table 1 Identification of the different rDNA regions in S. maritima after comparisons with Oryza sativa and Zea mays Species 59-ETS 18S ITS-1 5. 8S ITS-2 25S S. maritima Length (in bp) 1754 1812 226 167 206 3391 start-end region 392-2145 2146-3957 3958-4183 4184-4350 4351-4556 4557-7947 GC% 50. 9 50 53. 5 52. 7 49. 5 55. 4 O. sativa Length (in bp) 966 1812 198 167 215 3377 GC% 73. 0 51. 3 72. 7 58. 1 79. 1 59. 4 GenBank IDs -a X00755. 1 AF169230 AF169230 AF169230 M11585. 1 Blastn results (Identity, e-value) - 97%, 0. 0 - 94%, 2e-69 - 93%, 0. 0 Z. mays Length (in bp) 834 1809 213 164 220 3385 GC% 70. 0 51. 0 70. 4 56. 7 73. 2 58. 7 GenBank IDs X03989 NR_036655. 1 AF019817 AF019817 AF019817 NR_028022. 2 Blastn results (Identity, e-value) - 96%, 0. 0 - 94%, 2e-68 - 93%, 0. 0.
Identification of miRNA target sites in AD-associated genes and data mining When considering the 220 genes in 29 AD-associated loci, we downloaded the reference 3′-UTR sequences from the UCSC Table Browser (using the human assembly GRCh37/Hg19) and loaded them into the miRANDA (version 3. 3a), TargetScan (version 6. 2), and TargetSpy (version 1) software  [26] [27] [28] [29]. TargetScan allows filtering based on cross-species target site conservation to focus on biologically relevant sites. However, given that AD is a pathology that manifests itself only in humans, we also chose to include less conserved (and perhaps more human-specific) miRNA sites  [30]. To identify target sites in the reference sequences, we initially applied the following filters: a TargetScan context + score <0, a miRANDA prediction score >140 (which corresponds to a perfect seed match, with no other alignments), TargetSpy's sensitive setting  [26] , and canonical sites only.
The target sites predicted by miRANDA and TargetScan were then filtered ("basic score filter") by ranking the scores for each algorithm independently and setting a threshold at 5 % of the "best scores" (a TargetScan context + score less than -0. 318 and a miRANDA prediction score greater than 163). This approach selected the miRNA target sites with the best score and thus increased the likelihood of predicting biologically relevant sites. A graphic illustration of the application of this principle to TargetScan filtering is given in Fig. 1a. To identify target sites affected by singlenucleotide polymorphisms (SNPs), we generated in silico 3′-UTR sequences for each of the genes of interest, containing only the major alleles of all SNPs described in the 1000 Genomes database (with a frequency >1 % in the European ancestry panel, no deletions and insertions, 1000 Genomes Phase 1 integrated release version 3 haplotypes, 2010-11 data freeze, 14 Mar 2012 haplotypes)  [31].
The top 5 % context + scores had a value below -0. 318. b A graphical representation of the "score difference filter" in TargetScan. The percentage change in the context + scores for each miRNA binding site (due to the presence of a PolymiRTS) is plotted on the x-axis, and the number of counts with which each change in score was found is plotted on the y-axis. The top 5 % context + score changes had a value below -8. 25 % or above 8. 25 Mann-Whitney U test were performed with R software (version 3. 2. 2; https://www. R-project. org/).
Discussion The present study was focused on identifying functional SNPs located within AD-linked loci  [8]  that are likely to modulate miRNA binding. To predict the putative effects of AD-associated SNPs, we used the following criteria to select miRNA target site identification algorithms: (1) availability as a stand-alone program, (2) ability to query the latest version of the miRBase database, and (3) ability to handle an independent set of 3′-UTR sequences. The "gold standard" TargetScan, the less stringent miRANDA, and the machine learning algorithm TargetSpy met these criteria  [21, 26, 27]. We could also have used algorithms (such as miRTarBase and miRecords) that take account of the miRNAs' reported functionality by consulting collections of miRNA target data from both low-and high-throughput experiments  [39, 40].
Additional files Additional file 1: Table  S1. Primers used for cloning and mutagenesis of the 3′-UTRs of FERMT2, MS4A2, MS4A6A and NUP160. A summary of the base composition of the primers used for cloning and mutagenesis of the indicated gene 3′-UTRs. The mutated sites are the underlined bases. The purpose and direction of each primer are given. (XLS 21 kb) Additional file 2: Table  S2. PolymiRTSs and the corresponding target genes and miRNAs identified in silico. A summary of the genes, PolymiRTSs, SNP major and minor alleles relative to 3′-UTR strand and their MAF (reported in the EUR panel of the 1000 Genomes database), the targeting miRNAs, and the predicted consequences. (XLS 33 kb) Additional file 3: Table  S3. Other miRNA targeting sites identified by less stringent analysis near rs7143400-C/G, rs2847655-T/C, rs610923-C/A and rs9909-G/C.
Funding This work was funded by the  EU   FP7 project AgedBrainSYSBIO  (grant  305299 ) and the  Lille Métropole Communauté urbaine council. This work was supported by the  LABEX (Laboratory of Excellence Program Investment for the Future) DISTALZ  grant,  Inserm ,  Institut Pasteur de Lille, Université de Lille  and the  Lille University Hospital.
93 0. 90-0. 96 hsa-miR-3976 Creation perfect seed Decreased expression hsa-miR-1185-1-3p Disruption perfect seed Increased expression [8] minor allele frequency, PolymiRTS polymorphism in a microRNA target site, miR and miRNA microRNA A summary of the genes, single-nucleotide polymorphisms, minor allele identity relative to 3′ untranslated region strand, MAF, and OR [95 % CI] (in the International Genomics of Alzheimer's Project database discovery or meta-analysis study when available[8]), affected miRNAs, the effects of the Alzheimer's disease-associated PolymiRTSs identified in this study, and the predicted consequences.
INTRODUCTION Experimental paradigms are a common means by which we quantify human behavior. Given this central role, there would ideally be a coordinated effort to develop and deploy standardized paradigms. Unfortunately there is no openly available, extensible effort, and thus behavioral datasets tend to be small, and not directly comparable across studies. The technology available is an important limiting factor; while several frameworks have been developed for specific steps in the experimentation process (e. g. , jsPsych de Leeuw, 2015 for experiment creation, Psiturk  McDonnell et al. , 2012  for deployment), these tools require expertise with programming or the command line, and lack an integrated framework. Additionally, there is currently no large, open repository of paradigms that can serve as a resource and standard for the field.
A wide range of standard infrastructures are in development to help with this task. Just Another Tool for Online Studies (JATOS) provides infrastructure to set up a local or server-based set of JavaScript experiments with a corresponding database, but does not address the issue of standardizing or re-using paradigms  (Lange et al. , 2015). The Project Implicit Framework (PIP) (http://www. peoplescience. org) is a modular framework that also deploys JavaScript experiments, but requires significant expertise to develop and set up components of the application. Psiturk  (McDonnell et al. , 2012 ) is a Python-based web framework (based on the Flask micro-framework) that researchers can use to develop experiments and deploy on Amazon Mechanical Turk, but is limited to that implementation, and requires researchers to develop their own paradigms.
A commercial solution, E-Prime  (Schneider et al. , 2012 ) must be mentioned in that it has been well adopted into the community. While E-Prime offers equivalent fine-tuned control of stimuli presentation, the requirement of a USB license to run it, inability to serve experiments online (e. g. , on Amazon Mechanical Turk), and substantial learning to create experiments  (MacWhinney et al. , 2001 ) make it ill-suited for widespread and easy deployment of experimental paradigms. MacWhinney et al. (2001)  have the System for Teaching Experimental Psychology (STEP) that is intended to maximize the use of E-Prime for both teaching and experimental purposes. STEP includes documentation and E-Prime scripts for a variety of classic and commonly used paradigms. However, because it uses E-Prime, it inherits the problems of using E-Prime, so it is also ill-suited for widespread adoption and open collaboration.
THE EXPERIMENT FACTORY An essential and often overlooked feature of research workflow is the distinction between developer and user. A developer is a researcher interested in creating experimental paradigms and infrastructure, while a user simply wants to use the paradigms. While some researchers aim to dig deep into the code for an application, others simply want to use it, and a successful infrastructure must serve both. Toward this aim, the Experiment Factory employs a modular strategy, providing separate components (Github repositories) for experiments, surveys, battery, and deployments (see Section 4, The Experiment Factory Infrastructure), and allows researchers to deploy experiments into current tools that researchers already find useful (e. g. , Psiturk, see Table  3  for Glossary of terms), and under different likely scenarios like not having access to an internet connection, or needing to save data to a private database.
Deployment of Experiments The Experiment Factory aims to offer both flexibility and structure. A researcher has complete control over the deployment environment (local or cloud), along with the infrastructure used for the deployment (see Section 4, The Experiment Factory Infrastructure). Under any circumstance, the researcher has complete control over the set of experiments that are selected, and the resulting data are provided in several output formats. For this manuscript, we will walk through several use cases. When we refer to a module such as "experiments," we are referring to a Github repo, and more information is available about these components in Section 4.
Local Deployment of Experiments The most basic use case is when a researcher wants to run participants locally through the paradigms already included in the experiments module. This approach is easily accomplished using the expfactory command line tool (Section 4. 1 The Experiment Factory Software). Using the tool, a researcher can, in one line of code, select experiments, define a participant unique ID, and bring up a web interface to deploy a set of connected experiments called a "battery" (e. g. , "expfactory --run --experiments stroop,nback --subid UID001"). In the case that the user wants to save a static folder to run later, the argument "--generate" can be used in a similar fashion. While the default behavior is to use the latest experiments and battery templates from the repositories, a researcher can ensure that experiments and battery code remains constant by saving (cloning) the repositories to a local machine, and providing the paths to the folders as arguments to the tool (see the docs at expfactory.
Deployment of Experiments Using Psiturk The Psiturk infrastructure is a well-developed platform for deploying experiments on Mechanical Turk. Due to its substantial user base and documentation, it was imperative that our experiments be easily deployable to Psiturk. Using the expfactory command line tool without any arguments, a user can open up a web interface to choose experiments, a database specification, and a deployment. After selection of these variables, either a folder or file to run a virtual machine is provided to the user. This functionality is also possible using the command line tool with "expfactory --generate --experiments stroop,nback --folder /home/output. ".
Development of Experiments and Infrastructure The Experiment Factory uses an open source development strategy, meaning that all code is publicly available on Github (http://www. github. com/expfactory), and contributions are made to any of the code bases via forking of repositories and pull requests. Full documentation about this process is available (http://expfactory. readthedocs. org/en/latest/development. html). The code base has been developed and tested on Linux (Ubuntu) and Mac OS.
Experiment Development Contributing a new experiment constitutes adding a new folder to the experiments repository that meets the minimal requirements for expfactory (i. e. , including a JavaScript file to run the experiment, and a configuration file to specify metadata). Additional script and style files, along with images, sound, or other files necessary for deployment, are optional. We provide an experiment template for researchers to start with, and a recommended strategy is to copy and make modifications to a similar experiment that already exists. Development of an experiment means some familiarity with JavaScript and HTML/CSS, and ability to collaboratively work on Github. We provide both best practices and detailed descriptions about the required variables for the configuration file (Table  1 ).
THE EXPERIMENT FACTORY INFRASTRUCTURE This section is intended for more technical readers and those interested in development of the Experiment Factory modules, and we provide a Glossary of terms (Table  3 ) to explain more technical jargon. The modular strategy of the Experiment Factory infrastructure means providing separate Github repositories for experiments, skeletons for a sequence of experiments (a "battery" of experiments), and deployments. The Experiment Factory aims to be agnostic when it comes to deployment, and to provide support for the current infrastructures that researchers find useful to deploy their experiments. For example, experiments can be easily deployed into a folder structure to plug in to Psiturk, either locally on a virtual machine, or served locally to study participants without an internet connection.