dataesr/scientific-paragraphs-categorization huggingface dataset:
, 2000; Shi, 2012). We wished to focus our study on fully independent cleavage sites that contain their own PAS and auxiliary motifs. Therefore, we identified the dominant poly(A) sites based on read count, such that all resulting sites were at least 125 nt apart. For this purpose, we ranked the polyadenylation events by read count in descending order and considered only the highranking events that are more than 125 nt apart. This resulted in the overall poly(A) site database. It has been shown that cleavage is not an exact process  (Pauws et al. , 2001) , and we find that cleavage can occur within a small window of positions around the dominant cleavage site (Figure  S2B ). To allow for the variation in cleavage precision (as seen in Figure  S2B ), we computed the per-experiment expression of each poly(A) site by summing the read counts that identify any position in the region  [-5.
Classifying Poly(A) Site Pairs After we select the proximal and distal site for each gene, we classify the pair (and consequently the gene) into same exon, composite exon, and skipped exon. For this classification, we use the gene level annotation that is computed by linearizing the Ensembl gene annotation by merging the transcript annotation. When no annotated splice site is present between the selected poly(A) sites, then the gene is assigned to the same-exon category (Figure  2B ). If there is a splice site present between the selected poly(A) sites, further classification depends on the type of splice site preceding the proximal poly(A) site. If there is a 5 0 splice site immediately upstream of the proximal site, the gene is assigned to the composite-exon category, and, if there is a 3 0 splice site immediately upstream of the proximal site, the gene is assigned to the skipped-exon category (Figure  2B ).
The BRG allows a comparative analysis of RNA maps, for example, showing the BRG in the entire map (reported BRG400, since the entire RNA map window is 400 nt). Furthermore, to determine positions on the RNA map that have the strongest regulatory significance (fold change between repressed/enhanced and control genes), we performed 1M bootstraps (sampling with replacement) on the entire dataset. We then used a 40-nt sliding window and computed the p value by considering data versus bootstrap fold changes. For same-exon proximal poly(A) sites, we found that the most significant 40-nt window is between the À97 th and À57 th nucleotide relative to the repressed proximal poly(A) sites (p value = 1E-6, log2 fold change = 2. 04, BRG = 33). The positions of the 40-nt most significant windows with respective BRGs and fold changes are available for each type of poly(A) site (Table  S6 ).
RNAmotifs2 RNAmotifs2 is an upgraded version of the previously published RNAmotifs software  (Cereda et al. , 2014). We extended the motif search from alternative splicing regions to three regions surrounding poly(A) sites and modified the search algorithm with an iterative clustering method. The approach finds the motif with the strongest signal that differentiates up/downregulated sequences to control sequences first. Next, it removes sequences where the motif signal is strongest and compensates the loss of signal by clustering the strongest motif with additional motifs, iteratively constructing a cluster consisting of up to four different motifs. RNAmotifs2 is a standalone application written in Python. The input of RNAmotifs2 is a list of genomic positions, either alternative exons or alternative poly(A) sites.
ACKNOWLEDGMENTS We thank  João F. Matias Rodrigues  and  Sebastian Schmidt  for discussions on data analysis,  Jan Attig  for assistance with the minigene experiments,  Dalia Daujotyte  for assistance with the QuantSeq experiments, and von Mering and Ule lab members for comments on the manuscript. This work was supported by the  European Research Council  ( 206726-CLIP  and  617837-Translate  to J. U. ) and the  Slovenian Research Agency  ( J7-5460  to J. U. and T. C. ); G. R. and C. v. M. were funded by the  Swiss National Science Foundation  (grant  31003A_160095 ).
However, due to the intrinsic heterogeneity of scientific software (arising from the fact that it rarely is developed for widespread distribution), installing, configuring, and running many of the available methods is often difficult. Most neuroimaging software packages run natively on Linux  [1]  and (to a lesser extent) Mac OS X; however, Windows users often cannot run software natively. Operating system aside, many scientific packages depend on external libraries (often requiring a particular, sometimes outdated version), and require complex configurations of environment variables and/or data files. There have been some attempts in the field of neuroinformatics to solve this issue. The most notable is the NeuroDebian project  [2] , which provides Debian and Ubuntu Linux distributions with packages containing many of the popular neuroimaging software tools.
Installing packages prepared by the NeuroDebian team is very easy, as it can be performed with the built-in Debian/Ubuntu package management system. However, this solution only applies to Linux systems, as Mac OS X and Windows users are required to install Linux inside a Virtual Machine (VM). Additionally, creating new Debian/Ubuntu packages is a non-trivial task, which may limit the rate at which new software is added to NeuroDebian. Another consequence of these deployment and installation issues is that they make it very difficult to perfectly recreate analysis pipelines, which exacerbates reproducibility issues in neuroimaging  [3]. This is partly due to journal space limitations, which typically preclude a full accounting of the scientific software stack used to generate results. But even knowing the versions of all of the software tools employed in an analysis is rarely sufficient to completely reproduce a workflow.
Finally, most existing neuroimaging data processing pipelines expect input datasets to be organized and described in different and idiosyncratic ways. To account for variability in input data organization and a lack of consensus in terms of metadata description, data processing workflows often require users to input metadata manually-in a different fashion for each pipeline. This expandable step can cause errors and lead to incorrect results, while also making it harder to integrate processing pipelines into automated analysis platforms such as those developed to provide "Science as a Service"  [13]. After careful evaluation of existing solutions for the specific problems faced by the neuroimaging community, we have developed a framework for sharing and executing neuroimaging analysis pipelines that improve ease of use, accessibility, and reproducibility for users of all three major operating systems, as well as for researchers using HPC or cloud computing systems.
The framework overcomes Docker's inability to run on multi-tenant HPC systems by capitalizing on the Singularity  [14]  container technology developed specifically for HPC use. To minimize the number of manual inputs required from researchers-and hence reduce the number of errors arising from misinterpretation of those inputs-the framework capitalizes on the recently introduced Brain Imaging Data Structure (BIDS) standard  [15]  for organizing and describing datasets. Correspondingly, the proposed framework is named BIDS Apps. We describe here the anatomy of a BIDS App, the infrastructure used for building, testing and archiving BIDS Apps, as well as steps necessary to run BIDS Apps in various scenarios.
What is a BIDS App? A BIDS App is a container image capturing a neuroimaging pipeline that takes a BIDS-formatted dataset as input. Since the input is a whole dataset, apps are able to combine multiple modalities, sessions, and/or subjects, but at the same time need to implement ways to query input datasets. Each BIDS App has the same core set of command-line arguments, making them easy to run and integrate into automated platforms. BIDS Apps are constructed in a way that does not depend on any software outside of the container image other than the container engine. BIDS Apps rely upon two technologies for container computing: 1. Docker-for building, hosting as well as running containers on local hardware (running Windows, Mac OS X or Linux) or in the cloud. 2. Singularity-for running containers on HPCs  [14].
BIDS Apps are deposited in the Docker Hub (http://hub. docker. com) repository, making them openly accessible. Each app is versioned and all of the historical versions are available to download. By reporting the BIDS App name and version in a manuscript, authors can provide others with the ability to exactly replicate their analysis workflow. Docker is used for its excellent documentation, maturity, and the Docker Hub service for storage and distribution of the images. Docker containers are easily run on personal computers and cloud services. However, the Docker Engine was originally designed to run different components of web services (HTTP servers, databases etc. ) using cloud resources. Docker thus requires root or root-like permissions, as well as modern versions of Linux kernel (to perform user mapping and management of network resources); though this is not a problem in context of renting cloud resources (which are not shared with other users), it makes it difficult or impossible to use in a multi-tenant environment such as an HPC system, which is often the most cost-effective computational resource available to researchers.
How to create a BIDS App? BIDS Apps forge. Inspired by the conda-forge project (https://conda-forge. github. io/), BIDS Apps development is centered around a GitHub organization (http://github. com/ BIDS-Apps) that maintains a code repository for each BIDS App (see  Fig 1). Every repository hosts a Dockerfile describing how to build the container image, a lightweight wrapper for providing a unified command-line interface as well as parsing the BIDS input, and brief documentation. BIDS Apps are an evolution of lightweight wrappers such as the Interface class developed within Nipype  [16] , with the added advantage of being programming language agnostic. Since BIDS Apps merely serve the purpose of capturing dependencies and providing a unified way of calling the relevant program (through the command-line interface), the repositories in the github.
com/BIDS-Apps organization do not actually host the source code or data of the pipelines and workflows being wrapped: these are contained in the built Docker image stored on DockerHub. Building a BIDS App starts with creating a new repository and populating it with a Dockerfile and a run script. Dockerfile creation. A Dockerfile is a script written in a domain specific language that describes the steps necessary to build a Docker image. The Docker project provides excellent documentation and a tutorial on how to write Dockerfiles (https://docs. docker. com/engine/ reference/builder/). However, because the container images built in the BIDS-Apps format are ultimately intended to alternatively run under Singularity, there are some additional requirements that must be followed: • Apps cannot rely on having elevated permissions inside the container image (in contrast to Docker, processes inside a Singularity container run with the privileges of the user running the container).
• Environment variables must be set using the ENV statement within the relevant Dockerfile, rather than relying on config files (such as /root/. bashrc). • Apps should not write anywhere outside of /tmp, $HOME, and the specific output folder provided as a command-line argument. To facilitate the process of writing Dockerfiles, we have created a set of templates that include installation steps for the most popular neuroimaging tools (FSL, FreeSurfer, AFNI, ANTs etc. ): https://github. com/BIDS-Apps/dockerfile-templates. Those templates are also available as container images that can be used directly as a base for new BIDS Apps Dockerfiles using the FROM statement. Command-line interface. To improve user experience and ability to integrate BIDS Apps into various computational platforms, each App follows a set of core command-line arguments: runscript input_dataset output_folder analysis_level For example: runscript /data/ds114 /scratch/outputs participant • input_dataset provides a path to the dataset to be analyzed (read-only), which must conform to the BIDS standard • output_folder is the folder where results of the analysis will be stored • analysis_level denotes the stage of the analysis that will be performed To facilitate easy and efficient execution, analyses in BIDS Apps can be split into stages (see Materials and Methods).
In the simplest design, an App would run in two stages: 'participant' and 'group'. The 'participant' stage runs a first level analysis that can be performed independently for each subject in the dataset (and thus can be executed in parallel). The analysis may optionally be restricted to a subset of participants using the-participant_label argument. The group level analysis runs on the outputs from the participant level analysis and cannot be split into independent parallel jobs. This scheme is inspired by the MapReduce programming model  [17]. Multiple such MapReduce steps can be defined for a single pipeline (full specification of the command-line scheme can be found in the Materials and Methods section). There are no restrictions on what language is used to write the wrapper script as long as it conforms to the prescribed interface.
However, to make it easier to generate new BIDS Apps we have created a basic implementation in Python that can be imported into a new script and filled with App-specific options: https://github. com/BIDS-Apps/bidscmd. We also provide several utilities that make it easier to work with BIDS-compatible directory structures-most notably, the PyBIDS Python package (https://github. com/INCF/pybids), which provides tools for simple but powerful logical queries over entities defined in the BIDS specification (e. g. , retrieving a list of all unique subjects; getting the fieldmap files for all subjects with a valid first scanning run; etc. ). In addition to conforming to a standardized command-line argument scheme, run scripts are also responsible for validation of the input data before running any analysis.
To facilitate the process we have developed a command-line validator that checks whether the input datasets are compliant with the BIDS standard https://github. com/INCF/bids-validator. Because not all BIDS compatible datasets can be analyzed by all BIDS Apps (e. g. a surface reconstruction pipeline requires a high-resolution T1 weighted image), the validator can be configured to reject datasets with particular properties. Integrating the validator is as easy as calling an external command; Dockerfiles and container images with the validator pre-installed are also available. BIDS Apps developers can also choose to implement validation steps themselves if the requirements of their pipelines cannot be easily checked by the standard validator. Building and testing container images. For each BIDS App a Docker image is built and run on a set of lightweight example BIDS datasets  [18].
This execution tests that the command-line interface and BIDS support are correctly implemented (each BIDS App is required to include at least one smoke or integration test running on an example BIDS dataset). The tests are run forcing read-only containers, to ensure compatibility with Singularity (which imposes read-only mode). If the Docker image builds successfully and passes all tests, it is assigned a unique version (based on the tag obtained from the corresponding GitHub repository) and uploaded to Docker Hub with a version tag. Since version tags are unique and Docker images stored on Docker Hub are never overwritten, all historical versions of each BIDS App will always be accessible. Building, testing and archiving of BIDS Apps is performed automatically through a continuous integration service (CircleCI).
Automation of testing and versioning improves reliability due to minimization of human errors. To facilitate the process of creating new BIDS Apps we have made an example App that can also be used as a template for new Apps: https://github. com/BIDS-Apps/example. Additional documentation and tutorials are available at http://bids-apps. neuroimaging. io. Developers seeking help are also encouraged to subscribe to the bids-app-dev mailing list at https:// groups. google. com/d/forum/bids-apps-dev.
Running a BIDS App locally Running a BIDS App on a local system can be performed using Docker, which is easy to install on all three major operating systems. To run the first stage of the example BIDS App for participant number 01 the user needs to open a console (terminal or cmd) and type: docker run -ti --rm \ -v /Users/cajal/data/ds005:/bids_dataset:ro \ -v /Users/cajal/outputs:/outputs \ bids/example:0. 0. 4 \ /bids_dataset /outputs participant --participant_label 01 Where /Users/cajal/data/ds005 is the path to the input dataset and /Users/cajal/outputs the path where results should be stored. If the BIDS App was not run before on this machine, the Docker image will be automatically downloaded from the Docker Hub.
One of the goals of this project was to deliver software that could be applied to wide range of datasets without the need for much user interaction. It is important to emphasize that this goal is not at odds with the ability to modify various parameters of the workflows encapsulated in BIDS Apps. This is an important ability since many researchers have unique needs and many data analysis decisions are considered open scientific questions. The ability to modify internal parameters vary across the presented BIDS Apps, but many of them provide it either in form of command line parameters or input config files. We hope that with the help of new users app developers will be able to learn which parameters should be exposed for modification. It is also important to note that fact that BIDS Apps framework even though is built on container technology (which can be misinterpreted as a "black box") it does not imply a particular software development philosophy.
Additionally, similarly to previous proposals  [9, 10] , the presented solution puts a strong emphasis on clear versioning of container images and the ability to access all previous versions. We envisage that this feature will be very valuable in the context of longitudinal studies (where the same software stack needs to be used over many years) as well as for accurately reporting a set of computational methods in a publication and later replicating them (which can be achieved by simply referencing a BIDS App with a corresponding version). Strict versioning of BIDS Apps is achieved by careful management of Docker images on Docker Hub via a Continuous Integration service which also is responsible for testing the Docker images, further reducing potential errors. It is also worth noting that even though containers increase the reproducibility of scientific results, they do not solve the problem of sensitivity of some results to different operating systems, architectures or third party libraries.
This reduces the number of problems experienced by users due to nuanced differences in system configuration, such as system libraries or software versions. It also makes maintaining the software significantly easier for the developers, who do not need to support a variety of different configurations and can easily reproduce errors. Even though BIDS Apps as a form of neuroimaging software distribution scheme can be perceived as performing a similar task as the NeuroDebian project, the two initiatives, in fact, complement each other. Many of the example BIDS Apps presented in this manuscript use Debian as their base distribution and benefit from the ease of installation provided by the Neu-roDebian project. It not only makes Dockerfiles shorter and easier to maintain but due to the network of NeuroDebian mirror servers the build process is more reliable than downloading software from their original locations.
On the other hand, the NeuroDebian project benefits from the BIDS App distribution scheme by exposing software previously limited only to Debian based distribution to all flavors of Linux. This is important considering that many HPCs run on RedHat and CentOS Linux distributions rather than Debian. Future work will involve engaging more developers of neuroimaging methods to create BIDS Apps. Additionally, there are plans for developing a repository that would be independent of Docker Hub to provide Open Container Consortium as well as Singularity-compatible images. This would provide improved sustainability of the project, but also remove the conversion step (from Docker to Singularity) currently necessary for running BIDS Apps on clusters. Work is currently underway to facilitate the integration of BIDS Apps in other platforms such as XNAT  [48] , CBRAIN  [49] , or cloud-based services like Amazon Web Service (AWS).
The apps will include a machine-readable description of input arguments, their descriptions and acceptable values (based on the Boutiques application descriptor  [50]. Another benefit of such a description is to allow developers integrating BIDS Apps into their platforms to automatically generate user interfaces, and to improve validation of input parameters. Singularity is not the only solution proposed to handle containers on HPCs. "Shifter" (as of September 2016 only available as pre-release beta version) has been discussed in the context of running containerized academic software  [51]. The principles behind Shifter are similar to Singularity, but Shifter also attempts to tackle the problem of managing the container images. Because of this, it depends on several services (Redis and MongoDB servers, worker processes, etc.
) that make setting it up and maintaining it more involved than Singularity. However, despite the differences, all BIDS Apps would be able to run on clusters running Shifter. Singularity is despite its many advantages is not perfect. The need to convert Docker container images outside using docker2singularity tool is less than ideal. In the future, this will be a new feature of Singularity (currently in development) that will allow HPC users to directly import container images from Docker Hub (without the requirement of elevated privileges or access to Docker software). As mentioned above Singularity due to its minimal system requirements is easy to install. We are currently aware of 51 HPCs spread around the world that support Singularity (https://docs. google. com/spreadsheets/d/1Vc_1prq_1WHGf0LWtpUBY-tfKdLLM_TErjnCe1mY5m0/pub?gid=1407658660).
The only elements that are specific to human neuroimaging in BIDS Apps are the format of the input data and the naming convention for command line parameters ("participant" and"group"). Other fields with well-established data standards can easily adopt the same way of constructing, testing and archiving pipelines with their software dependencies. BIDS Apps is a framework to help neuroimaging practitioners deploy the complex data processing workflows that they require in their research. Leveraging existing technologies such as GitHub and CircleCI and extensively using containers (Docker and Singularity), the proposed ecosystem automatically generates the appropriate container images with a minimized impact on the researcher's development flow. This paper shows how these apps are created, stored, and executed either locally or in HPCs.