dataesr/scientific-paragraphs-categorization huggingface dataset:
MetamORF softwares and languages The pipeline used to build MetamORF has been developed using Python (v2. 7) with SQLAlchemy ORM (sqlalchemy. org, v1. 3. 5). The database has been handled using MySQL (mysql. com, v8. 0. 16). Docker (docker. com, v18. 09. 3) and Singularity (singularity. lbl. gov, v2. 5. 1) environments have been used in order to ensure reproducibility and to facilitate deployment on high-performance clusters (HPCs). The MetamORF web interface has been developed using the Laravel (laravel. com, v7. 14. 1) framework with PHP (v7. 3. 0), JavaScript 9, HTML 5 and CSS 3. The NGINX (v1. 17. 10) web server PHP server (v7. 3. 0) were deployed with Docker (docker. com, v18. 09. 3) and Docker-compose (v1. 24. 0) to ensure stability.
DATABASE CONTENT, ACCESSIBILITY AND WEB INTERFACE A new repository of short ORF-related data MetamORF describes 664,771 and 497,904 unique ORFs in the human and mouse genomes respectively, providing at least the information necessary to locate the ORF on the genome, its sequence and the gene it is located on (excepted for intergenic ORFs). Extensive information related to the transcripts is provided respectively for 614,997 (~93%) and 497,904 (100%) sORFs for the human and mouse genomes respectively. These features allowed us to classify 630,953 (~95%) human ORFs and 497,904 (100%) mouse ORFs in at least one class (Table  3 , Figure  2 , Supplementary Figure  S1 ). Interestingly, it should be noticed that a large proportion (36% and 52% respectively for H. sapiens and M. musculus) of ORFs are using an alternative frame to the main CDS.
User-friendly web interface and genome tracks To provide users with a clear, fast and easy-to-use database, MetamORF can be queried through an user-friendly web interface at http://metamorf. hb. univ-amu. fr. A tutorial as well as a documentation page are available online. Briefly, the users may search for sORFs contained in the database starting with a gene symbol (symbol, alias, ID), transcript ID (ID, name), ORF ID, or screening a particular genomic area. The data is made accessible through four types of pages: (i) a "gene-centric" page (Figure  3 ), allowing to visualize information related to all transcripts and sORFs on a gene, (ii) a "transcript-centric" page, allowing to browse information related to a transcript gene and all its sORFs, (iii) an "ORF-centric" page allowing to fetch information related to all transcripts and gene that harbor the chosen ORF and finally (iv) a "locus" page allowing to get information related to all sORFs located in a particular locus.
It is possible to navigate from one to another page easily to get extensive information about an sORF, a gene or a transcript (Supplementary Figure  S2 ). In each page, the results can be filtered on: (i) the identification method (computational prediction, ribosome profiling or mass spectrometry), (ii) the start codon, (iii) the Kozak context (as previously defined), (iv) the genomic length (defined as the sum of lengths of each exon constituting the ORF), (v) the transcript biotype (according to the Ensembl definitions), (vi) the ORF annotation (as previously defined) and (vii) the cell type (Supplementary Table  S3 ). All results can be exported in an easily-parsable format (comma-separated values file, CSV), as well as in FASTA or BED format. On ORF, transcript and locus pages, a link allowing to easily visualize all the ORFs localized in a particular area on the UCSC genome browser (  41 ) is proposed.
DISCUSSION AND CONCLUSION MetamORF contains data about 1,162,675 unique sORFs for the human and mouse genomes identified by both experimental and computational approaches. Whilst the Ribo-seq is considered by most as the "gold standard" method to identify sORFs experimentally, the added value of predictive computational approaches, proteomics and peptidomics to characterize such biological sequences remains certain. Because these technologies are offering complementary information at genomic, transcriptomic and proteomic scales, we decided to include data from both experimental and computational experiments in our database. Nevertheless, data coming from distinct data sources may be difficult to compare, in particular because they are not necessarily using the same genome annotation and definitions of ORF classes and Kozak contexts, for instance.
By homogenizing this information, MetamORF offers the possibility to compare datasets coming from different sources. We noticed that information regarding the Kozak context is missing most of the time and start flanking sequences are usually not provided. Hence, MetamORF provides there a new interesting set of information. It should be noticed that a large amount (~80 %) of the sORFs contained in our database have been described in the sORFs. org repository  (37). Despite being the most prominent sORF database and offering the community data processed in a normalized way using their own workflow, it has already been highlighted that sORFs. org does not provide metagene analyses (1). In addition, such analysis is made difficult by the absence of gene names as well as the high redundancy of information contained in the sORF.
org database  (37) , an issue we addressed with MetamORF. Hence, in comparison with existing resources, MetamORF allows analyses at ORF, transcript, gene and loci levels. In addition, it opens the possibility of studying sORFs as a group, at a global scale. The resource is accessible at http://metamorf. hb. univ-amu. fr and provides an intuitive querying interface to enable wet lab researcher to easily question this large set of information. Moreover, the implementation of MetamORF content in track hubs allows both quick and advanced visualization of data through the UCSC genome browser. Finally, the database content may be exported at various convenient formats widely used by the scientific community (e. g. FASTA, BED). We believe that MetamORF is of interest not only to bioinformaticians working on short ORFs but also to a wider community, including any biologist who may benefit from knowledge regarding the sORFs located on their gene, transcript or region of interest.
As ribosome profiling becomes more appreciated and proteomics starts to allow accurate identification of short peptides, new data describing sORFs in various conditions are expected to be published in the next years, and our database is expected to grow accordingly. As a conclusion, we believe that MetamORF should help to address new questions in the future, in particular regarding the regulatory functions of the sORFs as well as the functions of the short peptides they may encode. FIGURE LEGENDS.
DATA AVAILABILITY Data sources are available on the editor's website or using the links provided in their original publications. The source code used to create the database, and the full technical documentation (source code documentation, manual, database structure, dockerfiles) are available on GitHub (https://github. com/TAGC-NetworkBiology/MetamORF). Full content of the database can be downloaded at BED and FASTA formats from MetamORF website and up-to-date version of track hubs may be download and/or used with your favorite genome browser providing the following link: http://metamorf. hb. univ-amu. fr/hubDirectory/hub. txt. The dump of the database is available on request.
Dieharder A decade later Robert Brown  [6]  produced an extended version of the diehard test suite, called dieharder. The code was rewritten and published under GNU public license, integrated with GNU statistical library and parametrized, so now one can vary the sample size and the number of p-values easily. New tests were added and other improvements made. The resulting package is supported by mainstream Linux distributions. The package involves an extensive documentation. In particular, the man page says: A failure of the distribution of p-values at any level of aggregation signals trouble. The question is, trouble with what? Random number tests are themselves complex computational objects, and there is a probability that their code is incorrectly framed or that roundoff or other numerical -not methodical -errors are contributing to a distortion of the distribution of some of the p-values obtained.
2. 1), or divide the interval [0, 1] into some number of bins and apply χ 2 -test (4. 2. 2). This approach replaces the Kolmogorov-Smirnov test used by Marsaglia in diehard, and in dieharder. As for the case of dieharder, many tests from the NIST collection use approximations for computing p-values. The only warning about the consequences of this approach appears in the last section (p. 4-3): In practice, many reasons can be given to explain why a data set has failed a statistical test. The following is a list of possible explanations. The list was compiled based upon NIST statistical testing efforts. It is hardly surprising that with such a relaxed approach to statistical testing ("over time, statistical tests are revamped") the authors have included two bad tests in the original version of the document, see the paper  [12]  where the errors are noted.
The semiconductor junction is biased to 12 volts using a boost voltage regulator (since USB only supplies 5V), amplified, then digitized at high-speed. The digitized data is selected and whitened internal to the TrueRNG and sent over the USB port with more than 400 kilobits/second of throughput. The new entropy mixing algorithm takes in 20 bits of entropy and outputs 8 bit to ensure that maximum entropy is maintained. The algorithm uses multiplication in a Galois field similar to a cyclic redundancy check to mix the ADC inputs thoroughly while spreading the entropy evenly across all bits  [35]. On the other hand, one should be careful here, since the properties of Zener diodes are not guaranteed  13  , as a simple experiment shows (Fig. 4 ). It is quite possible that noise properties may change over time and depend on the environment (exact voltage and current, temperature etc.
Acknowledgments The author is grateful to all the people in the  RaCAF  project and the  ES-CAPE team (LIRMM, Montpellier), Kolmogorov Seminar (Moscow), Theoretical Computer Science Lab (Moscow, HSE ), and all others from whom I learned about randomness including my (late) teacher  Vladimir Uspensky ,  Leonid Levin ,  Alexander Zvonkin ,  Nikolay Vereshchagin ,  Vladimir Vovk ,  Vladimir Vyugin ,  Andrei Romashchenko ,  Bruno Durand ,  Gregory Lafitte ,  Laurent Bienvenu ,  Péter Gács ,  Wolfgang Merkle ,  Paul Vitányi ,  Daniil Musatov ,  Andrei Rumyantsev ,  Mikhail Andreev ,  Gleb Novikov ,  Bruno Bauwens ,  Konstantin Makarychev ,  Yury Makarychev ,  Ilya Razensteyn ,  Gleb Posobin ,  Alexey Vinogradov ,  Ruslan Ishkuvatov. The work was supported by  ANR RaCAF  grant  ANR-15-CE40-0016-0.
Participants and Materials A total of 138 learners were recruited from three large, public universities in North America. For this paper, a subset of 68 participants (n = 68; 68% female, age: M = 20. 01, SD = 1. 56) were included in our analyses because they met the inclusion criteria: complete eye-tracking, log file, and performance data and were randomly assigned to either the total agency (n = 41) or partial agency conditions (n = 27). Of the subsample, the majority identified as Caucasian (75%), while the remaining identified as Asian, Black, Hispanic or Latino, and Other. Additionally, the majority of the subsample reported rarely playing video games (37%), while the remaining reported occasionally (24%) or frequently (16%), or very frequently (9%) playing. Most participants reported an average level of video game playing skill (41%), whereas others reported none at all (13%), limited skills (21%), skilled or very skilled (25%).
Sixtythree percent of participants reported playing video games 0-2 h per week (63%), while the remaining reported playing 3-4 h (16%), 5-10 h (7%), 10-12 h (12%), or more than 20 h (1%) per week. This study was approved by the Institutional Review Board prior to recruitment and informed written consent was obtained prior to data collection. To measure knowledge about microbiology, a 21-item, 4-option multiple choice assessment was administered before and after participants finished the game, regardless of whether they had solved the mysterious illness plaguing the island. Participants answered between 6 and 18 correct items (Med = 12, M = 57%, SD = 0. 13) 1  on the pretest, and between 10 and 19 correct items (Med = 15, M = 72%, SD = 0. 12) on the post test. The assessments contained 12 factual (e.
Procedure When participants arrived at the laboratory, a researcher confirmed their identity and ensured no clothing, hair, or glasses (including eye conditions such as astigmatisms) would interfere with the eye-tracker calibration and data collection on eye movements. First, participants completed informed, written consent and then were instrumented with an electro-dermal bracelet and calibrated to the eye tracker and facial expressions of emotions software (see Figure  5  for experimental setup) 3. After successful calibration, participants were instructed to complete several questionnaires gauging motivation, emotions, and self-efficacy as well as a 21-item, multiple choice pre-test assessment on microbiology. Next, instrumented participants started learning with Crystal Island while we collected their multichannel data.
Eye-Gaze Behaviors To record eye-gaze behaviors, an SMI EYERED 250 eye tracker  (Center, 2014)  was used in this study and detected pupil and fovea location using infrared light. We used a nine-point calibration and configured the eye tracker to capture eye-gaze data at a sampling rate of 30 Hz, capturing relatively small eye movements at an offset of <0. 05 mm. Eye-gaze fixations were processed in iMotions software (iMotions, 2014), which provided granular post-hoc analysis for creating dynamic areas of interest (AOIs) around game elements related to scientific reasoning (e. g. , time spent fixating on complex text was defined as information gathering; Figure  4 ). We defined two types of AOIs: (1) around game elements in which the learner was not interacting with (e. g. , fixating on a book from a distance), and (2) around the content of the game elements in which the learner was interacting with (e.
Fixations and Interactions With Game Elements Game elements were categorized as either related to scientific reasoning (e. g. , books, research articles, etc. ) or non-scientific reasoning (e. g. , doors, furniture, etc. ) grounded within  Klahr and Dunbar (1988)  SDDS theory. Scientific reasoning game elements were further separated into three variables: (1) gathering information, (2) generating hypotheses, and (3) experimentally testing hypotheses. To define scientific reasoning based on learners' interacting with game elements, we aligned in-game actions with eye-tracking data in order to measure two behaviors: (1) when a participant fixated on game elements, but did not interact with same game elements, and (2) when a participant fixated and interacted with game elements at the same time (i.
Statistical Analyses We cleaned and processed our data in R (Version 3. 6. 2; R Core Team, 2013) using "read_xl"  (Wickham and Bryan, 2017) , "dplyr"  (Wickham et al. , 2018) , and "reshape2"  (Wickham et al. , 2007, p. 1)  packages for the data wrangling, manipulation, and melting features. Utilizing the "bestNormalize" package  (Peterson and Cavanaugh, 2019, p. 1)  and "plot" function from the "base" package (R Core Team, 2013), non-normally distributed variables were transformed into a normal distribution. Specifically, we used log, square root, and ordered quartile transformations, and in some cases, standardization. All variables were normalized or standardized with the exception of pre-and post-test ratio scores as these were normally distributed. Next, 12 participants were eliminated as they demonstrated   (Grubbs, 1969, p.
21). Upon building the models, we used the "stepAIC" function from the "MASS" package to conduct stepwise model selection using Akaike information criterion (AIC) for our first research question  (Venables and Ripley, 2002, p. 271). The "summary" function from the "base" package was used to access object and model statistics, while the "ggplot2" package was used to visualize models and corresponding relationships among variables  (Wickham, 2016). To visualize interaction terms, packages "tidyverse"  (Wickham et al. , 2019 (Wickham et al. , , p. 1686)) , "sjPlot"  (Lüdecke, 2018b) , and "sjmisc"  (Lüdecke, 2018a, p. 754)  were used. To probe the relation between interactions, we used the package, "interactions, " by calling the "probe_interaction" function  (Long, 2019).
Functional magnetic resonance imaging (fMRI) is a standard tool to investigate the neural correlates of cognition. fMRI noninvasively measures brain activity, allowing identification of patterns evoked by tasks performed during scanning. Despite the long history of this technique, the idiosyncrasies of each dataset have led to the use of ad-hoc preprocessing protocols customized for nearly every different study. This approach is time-consuming, error-prone, and unsuitable for combining datasets from many sources. Here we showcase fMRIPrep ( http://fmriprep. org ), a robust tool to prepare human fMRI data for statistical analysis. This software instrument addresses the reproducibility concerns of the established protocols for fMRI preprocessing. By leveraging the Brain Imaging Data Structure (BIDS) to standardize both the input datasets -MRI data as stored by the scanner-and the outputs -data ready for modeling and analysis-, fMRIPrep is capable of preprocessing a diversity of datasets without manual intervention.
The number of publications under the topic of "fmri," as indexed by the Web of Science, has consistently increased from five records in 1992 to nearly 6,000 scientific articles in 2018. This body of literature covers a wide range of applications investigating Figure  1  | Overall workflow of the fMRIPrep protocol. The analytic workflow is subdivided into three principal stages. First, a BIDS-compliant dataset is generated and validated. Next, dataset quality is assessed and the data are preprocessed. Finally, the preprocessed data undergo a generalized linear model (GLM) fitting, which yields participant-and group-level statistical maps of task-related BOLD activity. As further described in the original paper corresponding to this protocol  7  , fMRIPrep leverages the Brain Imaging Data Structure  12  (BIDS) to understand all the particular features and available metadata (i.
e. , imaging parameters) of the input dataset ( Box 1 ). BIDS allows fMRIPrep to automatically configure an appropriate preprocessing workflow without manual intervention. To do so, fMRIPrep self-adapts to the dataset by applying a set of heuristics that account for irregularities such as missing acquisitions or runs. Adaptiveness is implemented with modularity: fMRIPrep is composed of sub-workflows, which are dynamically assembled into appropriate configurations. These building blocks combine tools from widely used, open-source neuroimaging packages. The workflow engine Nipype is used to stage the workflows and deal with execution details (such as resource management).
BIDS  12  is a standard for organizing and describing brain datasets, including MRI. The common naming convention and folder structure allow researchers to easily reuse BIDS datasets, reapply analysis protocols, and run standardized automatic data preprocessing pipelines such as fMRIPrep. The BIDS starter-kit ( https://github. com/bids-standard/bids-starter-kit ) contains a wide collection of educational resources. Validity of the structure can be assessed with the BIDS-Validator ( https://bids-standard. github. io/bidsvalidator/ ). The tree of a typical, valid (BIDS-compliant) dataset is shown to the right. Further instructions and documentation on BIDS are found at https://bids. neuroimaging. io. In the following, we will be using OpenNeuro's ds000003.
Reagents Subjects ( ▲ CRITICAL ). The study must use data acquired after approval by the appropriate ethical review board. If the data are intended to be shared in a public repository such as OpenNeuro ( ◼ RECOMMENDED ), the consent form submitted to the ethical review board should explicitly state that data will be publicly shared (e. g. , the Open Brain consents  21  ) and, if appropriate, the consent form and the data management plan must also comply with any relevant privacy laws regarding pseudo-anonymization (e. g. , GDPR in the EU and HIPAA in the USA). BIDS dataset ( ▲ CRITICAL ). All subjects' data must be organized according to the Brain Imaging Data Structure  12  (BIDS) specification. The dataset can be validated ( ◼ RECOMMENDED ) using the BIDS-Validator. Conversion to BIDS, and the validation with BIDS-Validator are further described below.
For an introduction to fMRI experimental design, refer to Poldrack et al. 22. The BIDS specification includes a prescription for encoding the task paradigm in the raw dataset (files terminated with _events. tsv , Box 1 ), and fMRIPrep generates preprocessed BOLD images ready for analysis and time series corresponding to nuisance regressors (see section Anticipated results for specific naming conventions). The task paradigm and preprocessed data can then be used as inputs to standard software libraries for statistical analysis of functional images. Alongside the inputs provided by fMRIPrep , these software libraries typically require additional specifications of activation contrasts, nuisance regression models, and additional parameters for statistical analysis workflows. A comprehensive guide to using the nuisance regressors and general discussions about fMRI signal regression is now available within the documentation site.
Equipment MRI scanner. If the study is acquiring new data, then a whole-head, BOLD-capable scanner is required. fMRIPrep has been tested on images acquired at 1-3 Tesla field strength. Recent multi-band echo-planar imaging (EPI) sequences are supported, although all performance estimates given in this document derive from benchmarks on single-band datasets. fMRIPrep autonomously adapts the preprocessing workflow to the input data, affording researchers the possibility to fine-tune their MR protocols to their experimental needs and design. Computing hardware. fMRIPrep is amenable to execute on almost any platform with enough memory: PC, high-performance computing (HPC), or Cloud. Some elements of the workflow will require a minimum of 8GB RAM, although 32GB is recommended. fMRIPrep is able to optimize the workflow execution via parallelization.
Use of 8-16 CPUs is recommended for optimal performance. To store interim results, fMRIPrep requires ~450MB of hard-disk space for the anatomical workflow and ~500MB for each functional BOLD run per subject. Therefore, a dataset with an imaging matrix of 90x90x70 voxels and a total of 2,500 timepoints across all its BOLD runs will typically require around 3GB of temporary storage. This storage can be volatile, for example "local" scratch in HPC, which is a fast, local hard-disk installed in the compute node that gets cleared after execution. Visualization hardware. The tools used in this protocol generate HTML reports to carry out visual quality control. These reports contain dynamic, rich visual elements to inspect the data and results from processing steps. Therefore a high resolution, high static contrast, and widescreen monitor (above 30") is ◼ RECOMMENDED.