dataesr/scientific-paragraphs-categorization huggingface dataset:
, Santa Clara, USA). Subsequently, samples were processed by Illumina ® mRNA-Seq Sample Prep Kit (Illumina, Inc, San Diego, USA) according to Illumina protocol. Briefly, mRNA isolation was performed using oligo-dT magnetic beads (Illumina, Inc) followed by the mRNA fragmentation and cDNA synthesis. For the latter, the quality and yield was measured with Lab-on-a-Chip analysis and confirmed the expected size of the product in the range between 200-500 bp. Clustering and DNA sequencing was performed using Illumina cBot (Illumina, Inc) and HiSeq2500 (Illumina, Inc), in line with manufacturer's instructions at the concentration of 16pM of DNA. Image analysis, base calling and quality check was conducted with the Illumina data analysis pipeline RTAv1. 18. 64 (Illumina, Inc) and Bclfastqv1. 8. 4 (Illumina, Inc).
Data obtained from the HiSeq2500 in fastq format was used as source for the downstream data analysis. Alignment of fastq reads was performed using TopHat version 2. 0. 12  [53]  (Johns Hopkins University) against the assembled human genome GRCh37. p13 with the corresponding Ensembl release 75 annotation  [54]  (http://grch37. ensembl. org/index. html). The alignment run with default parameters but allowing for a genome multihit search and transcriptome build and mapping. Alignment quality metrics were collected using Qualimap version 2. 0. 1  [55]  (Max Planck Institute For Infection Biology and Bioinformatics Department). Quantification of feature alignments was performed.
ACKNOWLEDGMENTS We would like to thank  Professor Luigi Naldini  ( San Raffaele Telethon Institute for Gene Therapy, Milan, Italy ) for the generous donation of the pCCLsin. PPT. hPGK. GFP plasmids. We would like to thank  Ms Vasiliki Hatzigeorgiou  ( Cell and Gene Therapy Laboratory, BRFFA ) for generating the luc-lentiviral vector. Moreover, we would like to thank  Dr Panagiotis Politis  ( Histology, Basic Research, BRFAA ) for the donation of CD31 antibody and  Mr Szymon Filip  ( Proteomics Laboratory, Biotechnology, BRFAA ) for assisting in the correlation analysis.
Information sources Data from a previous systematic review was used  (Brasil et al. 2010 ) and updated. The previous systematic review included data from 1980-2009 and the update period included data from 2009-May 2014. Nevertheless, reviewers filled the new forms with data extracted again from all of the full texts from the previous systematic review. The main difference in the version of the forms was the risk of bias section. The Brazilian Health Surveillance Agency (ANVISA) (the regulatory agency for health products) website was visited up to 10 October 2014 to find possible tests of interest for this research. Moreover, authors visited the manufacturer's website up to 10 October 2014 to find technical reports, test brochures, or set of studies' results from tests accuracy data. In addition, the authors tried electronic mail contact with manufacturers of the tests registered at ANVISA's website to request this same information.
Data items The authors planned to collect data related to the tests, samples included in the original investigation, and the investigation itself including the risk of bias questionnaire. The data extraction involved collection of information related to the investigation, such as whether it was a multicentre study (the same protocol being executed in different places) and the period of data collection (when inclusion of volunteers were involved from start to finish), sample characteristics, such as the fraction of children (under 18 years old), the sex, mean/median age, minimum and maximum age, fraction of volunteers included from blood banks donors, fraction of volunteers living in either rural or urban areas, and clinical forms (either with indeterminate form or with cardiac form). Information planned for extraction from each of the ELISA tests were tests names and manufacturers, and from each of the PCR tests were whether the primers targeted the kinetoplast-DNA (k-DNA) minicircles or satellite-DNA (sat-DNA) and whether the technique was DNA hybridisation, PCR standard qualitative, nested, or quantitative.
In the first one, we used a bivariate model proposed by  Reitsma (2005)  (defined as a linear mixed model with known variances of the random effects). The Cochrane Diagnostic Test Accuracy systematic review group currently recommends this method as the standard approach. Some of its characteristics are considered advantageous: it fits the pair of sensitivity and specificity simultaneously, it returns conservative estimates in the presence of heterogeneity, as correlation is one of its parameters, the presence of the threshold effect reduces the confidence interval, and it allows estimation the SROC; however, it was conducted only in the groups with at least four or more studies. Similar to other regression methods, it has limitations, may not converge, and may mislead interpretation due to convergence problems, especially in small datasets.
As an alternative, we used the DerSimonian & Laird random effect (D&L) with a logit transformation (and back-transformation) and the inverse variance method to estimate study weights (as the 2nd method) with all of the groups of interest. All of the analyses were conducted with the R-project statistical package (R Core Team 2015) with libraries meta  (Schwarzer 2015)  and mada  (Doebler 2015).
Study selection On the ANVISA website, the authors found 30 records of ELISA tests and no records of commercial PCR tests. Visiting the manufacturers' websites and by requesting information through their website contact or by phone, we were unable to obtain a return of any technical report during the update period. Nevertheless, the authors looked for possible data of interest in the tests' technical descriptions and the technical recommendations regarding their use. The majority of these 30 tests did not have any information available regarding the test performance on their websites. After removing the replicates from the remote bibliographic database strategy, the authors found 1,532 abstracts including the original and the update period (Fig. 1 ). After including those found through the bibliography search and removing those that did not meet the inclusion criteria or those that met the exclusion criteria, 59 original reports remained for data extraction.
Other outcomes included anthropometric measurements, food intake and blood and fecal biomarkers. The study was registered in Clinicaltrials. gov (NCT01978691). Findings: There were marked differences in the results of the Intention-To-Treat (ITT; n = 209) and Per Protocol (PP; n = 134) study populations. The PP analysis included only those participants who completed the intervention with N 80% product compliance and no antibiotic use. In addition, three participants were excluded from DXA analyses for PP due to a long delay between the end of intervention and the last DXA measurement. There were no significant differences between groups in body fat mass in the ITT population. However, LU + B420 and B420 seemed to improve weight management in the PP population. For relative change in body fat mass, LU + B420 showed a -4.
Materials and Methods This double-blind, randomized, parallel, placebo-controlled clinical trial was conducted in four clinical research centers in southern Finland: VL-Medi Oy (Helsinki), Clinical Research Services Turku (Turku), FinnMedi Oy (Tampere) and Kerava Health Care Center (Kerava). All research procedures performed in this trial were in strict accordance with a pre-defined protocol, and adhered to international GCP guidelines and the Declaration of Helsinki. The study was approved by the Coordinating Ethics Committee of the Hospital District of Helsinki and Uusimaa and all participants signed informed consent prior to participation. This study is registered in ClinicalTrials. gov with the identifier NCT01978691.
Acknowledgements We wish to extend our gratitude to the study participants, investigators, monitors and study nurses who enabled this study. We are especially thankful to  Yvonne Peltonen  for her firm study management. Also, we are thankful to  Angela Paulsen  and  Tad Stewart  from  DuPont Nutrition & Health  for the production and quality control of the study products, as well as to all who participated in sample analyses:  Jaana Larsson-Leskelä ,  Henri Ahokoski ,  Kirsi Stenström  and  Sari Pohjola. We are also very grateful to  Tiina Roine  and  Auli Väänänen  for food diary data extraction.
Introduction Bioinformatics is a broad discipline in which one common denominator is the need to produce and/or use software that can be applied to biological data in different contexts. To enable and ensure the replicability and traceability of scientific claims, it is essential that the scientific publication, the corresponding datasets, and the data analysis are made publicly available  [1, 2]. All software used for the analysis should be either carefully documented (e. g. , for commercial software) or, better yet, openly shared and directly accessible to others  [3, 4]. The rise of openly available software and source code alongside concomitant collaborative development is facilitated by the existence of several code repository services such as SourceForge, Bitbucket, GitLab, and GitHub, among others.
These resources are also essential for collaborative software projects because they enable the organization and sharing of programming tasks between different remote contributors. Here, we introduce the main features of GitHub, a popular webbased platform that offers a free and integrated environment for hosting the source code, documentation, and project-related web content for open-source projects. GitHub also offers paid plans for private repositories (see Box 1) for individuals and businesses as well as free plans including private repositories for research and educational use. GitHub relies, at its core, on the well-known and open-source version control system Git, originally designed by Linus Torvalds for the development of the Linux kernel and now developed and maintained by the Git community.
One reason for GitHub's success is that it offers more than a simple source code hosting service  [5, 6]. It provides developers and researchers with a dynamic and collaborative environment, often referred to as a social coding platform, that supports peer review, commenting, and discussion  [7]. A diverse range of efforts, ranging from individual to large bioinformatics projects, laboratory repositories, as well as global collaborations, have found GitHub to be a productive place to share code and ideas and to collaborate (see Table  1 ). Some of the recommendations outlined below are broadly applicable to repository hosting services. However, our main aim is to highlight specific GitHub features. We provide a set of recommendations that we believe will help the reader to take full advantage of GitHub's features for managing and promoting projects in bioinformatics as well as in many other research domains.
Box 1 By default, GitHub repositories are freely visible to all. Many projects decide to share their work publicly and openly from the start of the project in order to attract visibility and to benefit from contributions from the community early on. Some other groups prefer to work privately on projects until they are ready to share their work. Private repositories ensure that work is hidden but also limit collaborations to just those users who are given access to the repository. These repositories can then be made public at a later stage, such as, for example, upon submission, acceptance, or publication of corresponding journal articles. In some cases, when the collaboration was exclusively meant to be private, some repositories might never be made publicly accessible. Table  1. Bioinformatics repository examples with good practices of using GitHub.
Name of the Repository Type URL Git has a complex set of commands and can be used for rather complex operations, learning to apply the basics requires only a handful of new concepts and commands and will provide a solid ground to efficiently track code and related content for research projects. Many introductory and detailed tutorials are available (see Table  2  below for a few examples). In particular, we recommend A Quick Introduction to Version Control with Git and GitHub by Blischak et al. [5]. In a nutshell, initializing a (local) repository (often abbreviated as repo) marks a directory as one to be tracked (Fig  1 ). All or parts of its content can be added explicitly to the list of files to track. cd project ## move into directory to be tracked git init ## initialize local repository ## add individual files such as project description, reports, source code git add README project.
At any time, it is possible to go back to a previous version. In larger projects, multiple users are able to work on the same remote repository, with all contributions being recorded, restorable, and attributed to the author. Users usually track source code, text files, images, and small data files inside their repositories and generally do not track derived files such as build logs or compiled binaries (read Box 2 to see how to handle large binary files in GitHub). And, although the majority of GitHub repositories are used for software development, users can also keep text documents such as analysis Table  2. Online courses, tutorials, and workshops about GitHub and Git for scientists.
Name of the Material URL reports and manuscripts (see, for example, the repository for this manuscript at https://github. com/ypriverol/github-paper). Due to its distributed design, each up-to-date local Git repository is an entire exact historical copy of everything that was committed-file changes, commit message logs, etc. These copies act as independent backups as well, present on each user's storage device. Git can be considered to be fault-tolerant because of this, which is a win over centralized version control systems. If the remote GitHub server is unavailable, collaboration and work can continue between users, as opposed to centralized alternatives. The web interface offered by GitHub provides friendly tools to perform many basic operations and a gentle introduction to a more rich and complex set of functionalities.
Rule 3: Developing and Collaborating on New Features: Branching and Forking Anyone with a GitHub account can fork any repository they have access to. This will create a complete copy of the content of the repository, while retaining a link to the original "upstream" version. One can then start working on the same code base in one's own fork (https://help. github. com/articles/fork-a-repo/) under their username (see, for example, https://github. com/ ypriverol/github-paper/network/members for this work) or organization (see Rule 2). Forking a repository allows users to freely experiment with changes without affecting the original.
Box 2 Using GitHub or any similar versioning/tracking system is not a replacement for good project management; it is an extension, an improvement for good project and file managing (see for example  [9] ). One practical consideration when using GitHub, for example, is dealing with large binary files. Binary files such as images, videos, executable files, or many raw data used in bioinformatics, are stored as a single large entity in Git. As a result, every change, even if minimal, leads to a complete new copy of the file in the repository, producing large size increments and the inability to search (see https://help. github. com/articles/searching-code/) and compare file content across revisions. Git offers a Large File Storage (LFS) module that replaces such large files with pointers while the large binary file can be stored remotely, which results in smaller and faster repositories.
Git LFS is also supported by GitHub, albeit with a space quota or for a fee, to retain your usual GitHub workflow (https://help. github. com/categories/managing-large-files/) (S1 File, Section 1). project and forms the basis of social coding. It allows anyone to develop and test novel features with existing code and offers the possibility of contributing novel features, bug fixes, and improvements to documentation back into the original upstream project (requested by opening an pull request) repository and becoming a contributor. Forking a repository and providing pull requests constitutes a simple method for collaboration inside loosely defined teams and over more formal organizational boundaries, with the original repository owner(s) retaining control over which external contributions are accepted.
Once a pull request is opened for review and discussion, it usually results in additional insights and increased code quality  [7]. Many contributors can work on the same repository at the same time without running into edit conflicts. There are multiple strategies for this, and the most common way is to use Git branches to separate different lines of development. Active development is often performed on a development branch and stable versions, i. e. , those used for a software release, are kept in a master or release branch (see for example https://github. com/OpenMS/OpenMS/branches). In practice, developers often work concurrently on one or several features or improvements. To keep commits of the different features logically separated, distinct branches are typically used. Later, when development is complete and verified to work (i.
Continuous integration provides a way to automatically and systematically run a series of tests to check integrity and performance of code, a task that can be automated through GitHub. GitHub offers a set of hooks (automatically executed scripts) that are run after each push to a repository, making it easier to follow the basic principles of continuous integration. The GitHub web hooks allow third-party platforms to access and interact with a GitHub repository and thus to automate post-processing tasks. Continuous integration can be achieved by Travis CI, a hosted continued integration platform that is free for all open-source projects. Travis CI builds and tests the source code using a plethora of options such as different platforms and interpreter versions (S1 File, Section 2). In addition, it offers notifications that allow your team and contributors to know if the new changes work and to prevent the introduction of errors in the code (for instance, when merging pull requests), making the repository always ready to use.
Rule 6: Let GitHub Do More Tasks for You: Automate More than just code compilation and testing can be integrated into your software project: GitHub hooks can be used to automate numerous tasks to help improve the overall quality of your project. An important complement to successful test completion is to demonstrate that the tests sufficiently cover the existing code base. For this, the integration of Codecov is recommended. This service will report how much of the code base and which lines of code are being executed as part of your code tests. The Bioconductor project, for example, highly recommends that packages implement unit testing (S1 File, Section 2) to support developers in their package development and maintenance (http://bioconductor. org/developers/unitTesting-guidelines/) and systematically tests the coverage of all of its packages (https://codecov.
io/github/ Bioconductor-mirror/). One might also consider generating the documentation upon code/ documentation modification (S1 File, Section 3). This implies that your projects provide comprehensive documentation so others can understand and contribute back to them. For Python or C/C++ code, automatic documentation generation can be done using sphinx and subsequently integrated into GitHub using "Read the Docs. " All of these platforms will create reports and badges (sometimes called shields) that can be included on your GitHub project page, helping to demonstrate that the content is of high quality and well-maintained.
For example, if the developer needs more information to be able to reproduce a bug, he or she can simply request it in a comment. Additional elements of issues are (i) color-coded labels that help to categorize and filter issues, (ii) milestones, and (iii) one assignee responsible for working on the issue. They help developers to filter and prioritize tasks and turn an issue tracker into a planning tool for their project. It is also possible for repository administrators to create issue and pull request templates (https://help. github. com/articles/helping-people-contribute-to-your-project/) (see Rule 3) to customize and standardize the information to be included when contributors open issues. GitHub issues are thus dynamic, and they pose a low entry barrier for users to report bugs and request features.
A well-organized and tagged issue tracker helps new contributors and users to understand a project more deeply. As an example, one issue in the OpenMS repository (https://github. com/OpenMS/OpenMS/issues/1095) allowed the interaction of eight developers and attracted more than one hundred comments. Contributors can add figures, comments, and references to other issues and pull requests in the repository, as well as direct references to code. As another illustration of issues and their generic and wide application, we (https://github. com/ypriverol/github-paper/issues) and others (https://github. com/ropensci/RNeXML/issues/ 121) used GitHub issues to discuss and comment on changes in manuscripts and address reviewers' comments. Rule 8: Make Your Code Easily Citable, and Cite Source Code! It is a good research practice to ensure permanent and unambiguous identifiers for citable items like articles, datasets, or biological entities such as proteins, genes, and metabolites (see also  Box 3).
Digital Object Identifiers (DOIs) have been used for many years as unique and unambiguous identifiers for enabling the citation of scientific publications. More recently, a trend has started to mint DOIs for other types of scientific products such as datasets  [12]  and training materials (for example  [13] ). A key motivation for this is to build a framework for giving scientists broader credit for their work  [14, 15]  while simultaneously supporting clearer, more persistent ways to cite and track it. Helping to drive this change are funding agencies such as the National Institutes of Health (NIH) and National Science Foundation (NSF) in the United States and Research Councils in the United Kingdom, which are increasingly recognizing the importance of research products such as publicly available datasets and software.
A common issue with software is that it normally evolves at a different speed than text published in the scientific literature. In fact, it is common to find software having novel features and functionality that were not described in the original publication. GitHub now integrates with archiving services such as Zenodo and Figshare, enabling DOIs to be assigned to code repositories. The procedure is relatively straightforward (see https://guides. github. com/ activities/citable-code/), requiring only the provision of metadata and a series of administrative steps. By default, Zenodo creates an archive of a repository each time a new release is created in.
Box 3 Every repository should ideally have the following three files. The first and arguably most important file in a repository is a LICENCE file (see also Rule 8) that clearly defines the permissions and restrictions attached to the code and other files in your repository. The second important file is a README file, which provides, for example, a short description of the project, a quick start guide, information on how to contribute, a TODO list, and links to additional documentation. Such README files are typically written in markdown, a simple markup language that is automatically rendered on GitHub. Finally, a CITATION file to the repository informs your users how to cite and credit your project. GitHub, ensuring the cited code remains up to date. Once the DOI has been assigned, it can be added to literature information resources such as Europe PubMed Central  [16].