dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments The authors would like to acknowledge  Christian Rossi ,  Prof. Geoffrey M. Henebry , and the anonymous reviewers for their valuable comments and suggestions that greatly improved the manuscript. This work was supported financially by the  Ecology Fund of the Royal Netherlands Academy of Arts and Sciences  (' KNAW Fonds Ecologie ';  KNAWWF/807/19011 ). We thank  Altino Geraldes ,  Joao Carlos Azevedo , and the local farmers and foresters in the Montesinho-Nogueira Natura 2000 site for their help and collaboration. We thank  Emilie Didaskalou  for her lab assistance. J. -B. Féret  acknowledges financial support from  Agence Nationale de la Recherche  ( BioCop  project -ANR-17-32CE-0001 ).
Ribosome profiling (RiboSeq) has emerged as a powerful technique for studying the genome-wide regulation of translation in various cells. Several steps in the biological protocol have been improved, but the bioinformatics part of RiboSeq suffers from a lack of standardization, preventing the straightforward and complete reproduction of published results. Too many published studies provide insufficient detail about the bioinformatics pipeline used. The broad range of questions that can be asked with RiboSeq makes it difficult to use a single bioinformatics tool. Indeed, many scripts have been published for addressing diverse questions. Here (https://github. com/equipeGST/RiboDoc), we propose a unique tool (for use with multiple operating systems, OS) to standardize the general steps that must be performed systematically in RiboSeq analysis, together with the statistical analysis and quality control of the sample.
Briefly, mRNA fragments protected from RNAse degradation (about 30 nucleotides) by the ribosomes are extracted and sequenced. These ribosome footprints (RPF) are then mapped onto a reference genome or transcriptome. The level of translation can be inferred from the density of footprints, providing information about the regulation of translation  [4]. RiboSeq also provides large amounts of qualitative information (pausing sites, new reading frames, stop codon read through, ribosome residence time) through nucleotide resolution  [5] [6] [7] , but these analyses are highly dependent on data quality, which is addressed on a case-by-case basis. Following the advent of RiboSeq, several bioinformatics tools were developed for analysis of the data generated  [8]. Intuitively, one might imagine that RiboSeq and RNAseq data could be analyzed in the same way, but this is not the case due to certain specific features of RiboSeq data.
Firstly, RPF are small (25-30 nucleotides), which complicates the mapping step, particularly for exon-intron boundaries. Secondly, RiboSeq can map ribosomes at the resolution of single nucleotides, which raises important new issues previously unfamiliar to non-specialists, such as the higher density of ribosomes in the coding sequence (CDS) than in UTRs, and periodicity. Unfortunately, this lack of knowledge has resulted in basic controls, such as checking that the data obtained do indeed correspond to active ribosome footprints, not being carried out. Among the various tools, we would like to highlight the RiboGalaxy platform  [9]  that is a very useful resource to analyse (or re-analyse) RiboSeq data. However, no matter how good the tools are, they still suffer from some flaws. They are either very computer-intensive or require data to be uploaded to remote servers (which can pose problems of industrial property), or do not meet the FAIR reproducibility criteria, which makes it difficult to reproduce the results obtained.
The development of many ''home-made scripts", about which too little detail is provided for published results to be reproducible. In the rare cases in which these scripts are made publicly available, it is often difficult, if not impossible, to install them correctly on another computer, for various reasons. These problems have raised serious issues concerning the reproducibility of published data. We present here a new open-source bioinformatics tool called RiboDoc. RiboDoc is designed to perform the first steps of RiboSeq data analysis, from the FastQ files to the differential expression analysis that must systematically be performed in all RiboSeq analyses. RiboDoc includes two different tools for qualitative analyses that can be selected by the user depending on the power of the computer: 1 -RiboWaltz  [10]  an R package for calculation of optimal P-site offsets, diagnostic analysis and visual inspection of ribosome profiling data.
However, RiboWaltz requires a lot of computing power, and we wanted to make these preliminary analyses accessible in local to as many scientists as possible, including those without powerful computers. For this reason, we included a series of home-made scripts called TRiP, which provides controls (CDS enrichment and metagene-periodicity) for checking that the data correspond to active ribosome footprints, together with two statistical validations (principal component analysis (PCA) and Spearman's correlation) to check that the replicates are suitable for the analysis (Fig. 1 ). RiboDoc complies with FAIR (Findable, Accessible, Interoperable, Reusable) principles  [11]  to ensure the highest degree of reproducibility, and is presented in a Docker container for easy and reproducible usage with Linux, Windows or MacOS operating systems.
Technical considerations RiboDoc can be deployed in the Linux, MacOS and Windows 10 operating systems. The minimal requirements are Dockercommunity edition v. 19 or above (http://www. docker. com) warning for Docker Desktop on Windows: Ubuntu from Microsoft Store and WSL2 are required) and internet access (required for Docker image downloading only). The tool itself requires no additional installation and all the pipeline is managed by snakemake (v6. 1. 1). A step-by-step tutorial is available from the github repository (https://github. com/equipeGST/RiboDoc), and a summary is provided below.
Input reference files For data alignment, a reference fasta file of the genome is required. This file may contain a reference transcriptome or a genome. For complex genomes, a transcriptome might be preferable as a lower complexity results in a faster analysis and less resources like RAM are needed. Another fasta file containing the sequences which the user doesn't want to keep in the analysis (e. g. rRNA) is needed. We would advise the users to get those input files from the Ensembl website/database (http://www. ensembl. org) [12]. TRiP was designed to be used with specific transcriptomes for the qualitative analysis. This transcriptome file is created as follows: 1) Select CDS, with 3 0 and 5 0 UTRs annotations from a GFF3 file of the reference genome 2) Transform the resulting file into a BED file 3) Convert the BED file into fasta format with ''bedtools getfasta" [13] 4) Concatenate the UTR and CDS sequence as transcripts 5) Discard transcripts without a UTR 6) For each gene, select the longest transcript by comparing the coordinates of the transcripts associated to each gene, so as to include only one transcript per gene As a means of simplifying the use of RiboDoc, we provide, together with RiboDoc, a human transcriptome based on the Hg38 human genome and its associated GFF3 file, constructed as described above.
Folder preparation Before running RiboDoc, users should prepare their data as follows. After pulling the Docker image, the user should create a project folder, which must contain the duly completed config. yaml file available from the github repository (https://raw. githubusercontent. com/equipeGST/RiboDoc/main/config. yaml). The user should open this file and to save it in the project folder created above (for MacOS users, the file must be saved as a. txt file, and the txt extension must then be removed). Once this has been done, the user can complete the file with the necessary information. Two subfolders must also be created: i) ''fastq" into which all the zipped fastQ files must be dropped. The file name format must be ''sampleName. replicatNumber. fastq. gz" (e. g WT. 1. fastq. gz) and ii) ''database", containing fasta (genome/transcriptome and undesired RNA sequences to align on) and a GFF annotation file for the genome of interest downloaded from http://www.
Fasta indexation The conda (v4. 9. 2) (Anaconda Software Distribution. Computer software. Vers. 2-2. 4. 0. Anaconda, Nov. 2016. Web (https://anaconda. com)) environment is activated in Docker, and the input fasta files are then indexed: i) with Bowtie2 (v2. 4. 2)  [14]  only, for the non-coding RNA fasta data and ii) with both Bowtie2 and Hisat2 (v2. 2. 1)  [15]  for the reference genome.
Adapter trimming and read length selection CutAdapt (v3. 4)  [16]  is used i) to trim reads, to remove the 3 0 adapter sequence (error rate = 12. 5%) and ii) to filter (maximum one N found in each read) and select reads on the basis of their length. Each read represents a RPF of about 28-30 bases in length  [4]. The RiboDoc default parameters are slightly more flexible, retaining reads with lengths between 25 and 35 bases. Users can fix their own range, selecting fragments from 20 to 22 bases long for example, which correspond to another ribosome conformation during translation  [13]. For data that have already been trimmed, we have added an option for selecting only sequences with a particular length of interest.
Generation of BAM files The sequence alignment/map (SAM) files created by Hisat2 and Bowtie2 are merged and only the mapped reads are kept. Working with uniquely mapped reads only can be seen as a limitation, but in our opinion it is the safest procedure to be confident in our analysis. SAM files are then sorted and filtered with the selection of uniquely mapped reads only, and every read corresponding to the flag number 3844 is discarded (https://broadinstitute. github. io/picard/explain-flags. html) with the -F option. These files are then converted into binary alignment/map (BAM) with samtools (v1. 12)  [17].
Quality controls Quality controls are required to ensure that the footprints obtained actually correspond to active ribosomes. Three quality controls are performed independently on each category of read, according to length (default parameters: 25-35 bases long). The first assesses the distribution of read lengths, the second assesses periodicity, and the third evaluates the density of reads in CDS vs. UTRs. Several technical issues may explain a failure of some data to pass these controls and in such cases, the data should be interpreted with considerable caution. RiboDoc contains two pipelines available for this qualitative analysis. The first method is to operate with the integrated R package riboWaltz (v1. 1. 0) [10]. This package requires BAM files corresponding to reads aligned on a format specific reference fasta file and a gtf annotation file which are obtained with gffread (v0.
Data normalization A DESeqDataSet (DDS) object is created from the raw counts for the different conditions. The ''counts" function of DESeq2 is used to normalize data through the DDS object. This step is necessary to eliminate technical biases and to make read counts comparable between samples even with different library sizes. The DESeq2 normalization uses the median of ratios method. For each feature, a pseudo-reference sample is created (ref = sqrt (featureCount_sampleA*featureCount_sampleB)). The ratio of each sample to the reference is calculated (ratio = sample/ref). The normalization factor (or size factor) for each sample corresponds to the median value of all ratios for a given sample (normalization_fac tor_bySample = median(all_feature_ratio)). The raw counts for a sample are then divided by its size factor, to determine the normalized counts.
Results & discussion As we only implemented the published RiboWaltz package into RiboDoc we did not use this option here to demonstrate how Ribo-Doc works. We selected the trip option for the following analysis applied to two datasets: a previously published dataset for human cells  [24]  and an unpublished dataset for yeast from our own group. The human dataset was selected because quality controls had been rigorously performed, making it possible for us to compare RiboDoc with data analyzed with different scripts. We also wished to use RiboDoc with a different genome, and for this purpose we chose to use our own data for the yeast Saccharomyces cerevisiae. These two datasets are very different in size, making it possible to assess the efficacy of RiboDoc with different sample sizes (Table  1 ).
RiboDoc was implemented with Docker. Docker technology is a state-of-the-art platform for deploying software applications without the need to worry about dependency issues. It can be used to deploy an application in a sandbox mode, called a container, on the host system. This is a crucial point for reproducibility. Indeed, all the tools present in RiboDoc have a fixed version number, to prevent discrepancies that could arise later, due to the updating of these tools. We tested RiboDoc by determining whether replacing the +1 programmed frameshifting (PRF) site of the yeast OAZ1 gene with an in-frame version affected gene expression. We have shown that this +1 PRF is under the control of the yeast prion [PSI + ]  [23]. During this study, we also showed that replacing the naturally frameshifted OAZ1 gene with an in-frame allele led to a decrease in polyamine levels  [23].
RiboSeq quality controls When RiboDoc has completed the analysis, the first important control is confirming that the data actually come from active ribosomes. RPF have been reported to be about 28 nucleotides long for eukaryotic ribosome, although smaller fragments may correspond to an alternative ribosome conformation  [20]. The read-length distribution (Fig. 2A ) provides a visual representation of the numbers of each RPF. For the chosen example, we can clearly see that the majority of reads are 28 nucleotides long. However, this is not sufficient to be sure that we are really looking at active ribosomes. Indeed, such fragments could arise from the binding of mRNA to non-translating ribosomes or to ribosomes' proteins. It is therefore necessary to check for an accumulation of signals in the CDS and to ensure that this signal displays a clear periodicity of 3, correspond-ing to the movement of the ribosome along the mRNA in discrete steps of three nucleotides (codon).
Statistical validation Once the initial QC steps have been performed, the reproducibility of the replicates must be verified. RiboSeq data are much more heterogeneous than classical RNAseq data. It is, therefore, essential to ensure a high level of reproducibility between duplicates or triplicates. Based on our own experience, most of the variability observed with human cell lines is due to cell culture parameters, although the nature of the cells also plays an important role. Two statistical analyses are included within RiboDoc. The first is a pairwise sample-by-sample comparison in which Spearman's correlation coefficients are displayed. The second is a PCA analysis. For the example used, we can see in Fig. 4  that the Spearman coefficient for correlation between duplicates is around 0. 93 and 0.
Conclusions We describe here a new tool (RiboDoc) that efficiently performs the initial steps of RiboSeq analysis, regardless of the operating system used (Linux, Windows, MacOS). RiboDoc is provided as a Docker package including all the necessary bioinformatics tools for simplified installation and reproducible analyses. RiboDoc meets the need for standardization in the analysis of RiboSeq data, including two tools depending on the computer power available for the analysis. We checked that RiboDoc worked correctly, by using the ''trip" option to reanalyze high-quality data previously published by others  [19]  and to analyse new data generated by our own laboratory. The results obtained demonstrate that Ribo-Doc works correctly, simplifying and standardizing the initial steps of the analysis.
Acknowledgments The English of this manuscript was corrected by  Alex Edelman & Associates. The authors wish to thank  Claire Toffano-Nioche  and  Thomas Denecker  for providing information about FAIR, Snakemake and Docker. We also wish to thank  Fabrice Leclerc  for his advice on the conda environment. We thank the highthroughput sequencing facility of  I2BC  for providing sequencing and bioinformatics expertise. We also acknowledge support from the  ANR   Rescue_ribosome program  ( 17-CE12-0024-01 ).
Plant LADs have been recently characterized and as for NUP136 associated regions, they correspond to the repressed B compartment, which includes also transposable elements that interact with CRWN1  (21). In addition, chromatin regions enriched in CRWN1 largely overlap with those binding NUP136  (21)  raising the possibility of a possible dual contribution of NPC and nucleoskeleton to promote contact between repressed chromatin and the nuclear envelope. Protein structure of KAKU4, NUP82 and NUP136 were defined using Uniprot  (27)  and pfam  (28)  databases for domain predictions. Secondary structures were predicted using PHYRE2, QUARK and PEP-FOLD3  (29) (30) (31). Intrinsically disordered regions (IDRs) were predicted using DEPICTER, DISOPRED3 and VSL2B  (32) (33) (34)  (Supplemental Table  S2 ).
VSL2B is the baseline predictor of VSL2 that is using only the amino-acid composition-based features that can be calculated directly from the protein sequence  (34). DescribePROT database was used to collect pre-computed IDR predictions for 27,466 proteins of the Arabidopsis thaliana proteome including those predicted by VSL2B  (35). VSL2B predictions were extracted for 31 NUPs, 5 Nucleoskeleton proteins and 5 inner nuclear membrane proteins (Supplemental Table  S3 ). All schemes of protein structures were drawn to scale using the drawProteins R package  (36).
MAUVE  (40)  was used to define Locally Conserved Block (LCBs) between genomic regions of about 100kb each centered on the KAKU4, NUP82 and NUP136 genes. Nonsynonymous (dN) and synonymous (dS) substitution rates were investigated to determine if selection or genetic drift occurs within the KAKU4, NUP82 or NUP136 gene families. To avoid underestimation of dS, the analysis was restricted to 9 close relative species from Brassicaceae (Arabidopsis thaliana, Arabidopsis lyrata, Camelina sativa, Capsella rubella, Eutrema salsugineum, Brassica napus, Brassica oleraceae, Brassica rapa, Raphanus sativus). The Codeml program of the Phylogenetic Analysis by Maximum Likelihood (PAML) package (v. 4. 4c) (41) was used with the variable NSsites to compare the observed dN/dS ratio for KAKU4, NUP82 and NUP136 phylogenetic tree with the null model M0 where all tree branches have the same dN/dS set to 1 (no selection).
The N-terminal region of KAKU4 contains conserved peptide motifs To gain insight into the protein characteristics allowing for KAKU4 enrichment at the plant nuclear periphery, we first searched for protein domains that are evolutionary conserved in the KAKU4 protein sequence using referenced protein domains in pfam  (28). This approach identified a predicted Nuclear Localization Signal (NLS) in the Nterminal part and a Glycine-Arginine rich (GAR or RGG/RG box (  49 )) region at the Cterminus (Figure  2A ) but did not identify other conserved protein regions. Yet, the above database search is not powerful to detect small regions of less than 100 amino acids, which can potentially also contribute to protein interactions. Therefore, we deployed the MEME suite  (39) , to predict novel motifs conserved in 16 KAKU4 protein orthologs from basal to recent angiosperms (Materials and Methods).
e unstructured) by crystallography  (54). Many disorder predictors are available (  55 ), here we used VSL2B an efficient predictor for proteins containing both structured and disordered regions  (34) , the meta predictors DISOPRED3  (33)  and DEPICTER  (32). KAKU4, NUP82 and NUP136 are predicted to contain several IDRs with values obtained for the full-length protein by three predictors ranging from 57. 6% (VSL2, KAKU4) up to 96. 5% (DEPICTER, NUP136) (Figure  6A  and Supplemental Figure  S5A ). Examination of the N-terminal part of KAKU4, NUP82 and NUP136 (amino-acids 1 to 300) indicated several IDRs interspersed with structured regions overlapping the M1 and M2 peptide motifs (Figure  6B ). This prompted us to investigate more proteins located at the NPC and its vicinity. For that purpose, we then took advantage of the DescribePROT database that provides access to pre-computed predictions from VSL2B for the Arabidopsis thaliana proteome  (35).
We present improved data parallel approaches working on graphics processing unit (GPU) compute unified device architecture (CUDA) platform to build hierarchical Euclidean minimum spanning forest or tree (EMSF/EMST) for applications whose input only contains N points with arbitrary data distribution in 2D/3D Euclidean space. Characteristic of the proposed parallel algorithms follows "data parallelism, decentralized control and O1 local memory occupied by each GPU thread". This research has to solve GPU parallelism of component-based nearest neighbor search (component-based NNS), tree traversal, and other graph operations like union-find. For exact NNS, instead of using classical K-d tree search or brute-force computing method, we propose a K-d search method working based on dividing the Euclidean K-dimensional space into congruent and non-overlapping square/cubic cells where size of points in each cell is bounded.
They mainly take advantage of the nearest neighbor search (NNS)  [19]  in Euclidean space since geometrically closest pair of points naturally satisfy the definition of MST  [6] [18]  [20]. While, when considering the 3D or higher K-d EMSF/EMST, previous solutions become even more rarer, the most recent optimal sequential EMST algorithm is the dual-tree EMST proposed by March et al. [6]. It is not an easy trick to make an integral GPU parallel 2D/3D EMSF/EMST algorithm and get actual computing acceleration over state-of-art sequential Kd EMSF/EMST algorithm. This is because building K-d EMST is an iterative procedure including Kd NNS, tree traversal, and other graphical operations. Parallelism of each sub-step should obey the characteristic of "data parallelism, decentralized control, and O1 local memory occupied by each GPU thread" in order to highly utilize the capability of NVIDIA GPU card series.
While, GPU can not support launching large amount of independent BFSs with each thread occupying a large-size local variable. Harish et al. [22]  explore parallelism between frontier nodes of BFS to work in a manner of "data parallel, decentralized control and each thread occupies O1 local memory on GPU". However, when each frontier node works independently and in parallel, communication problems arises for selecting the shortest outgoing edge. Qiao et al. [2]  proposed GPU two-directional BFS, which also adopts an iterative manner similar to Harish et al. [22]  to deal with frontier nodes from root to leaves, but adds a backtrack procedure from leaves to the root again to select the shortest outgoing edge of a local MST. While, this BFS iterative manner needs additional parallel reduction kernels to judge termination at each iteration, leading to the limit of acceleration factors.
GPU Parallel Tree Traversal with Distributed dynamic link list Instead of using GPU parallelism of BFS or DFS for tree traversal to collect the shortest outgoing edge of a local EMST component, we combine the disjoint set data structure with GPU lock-free parallel link list data structure proposed by Nyland et al. [38]  to accomplish this task. It contains two independent GPU CUDA kernels illustrated in Alg. 3 and Alg. 4. Alg. 3 starts from independent point, finds root of this point and adds itself to the root's link list using GPU CUDA lock-free Atomic operation  [38]. Alg. 4 traverses independent link lists from their root nodes to collect the shortest outgoing edge within each component.