dataesr/scientific-paragraphs-categorization huggingface dataset:
Creating a Docker image with GNU Guix is a one liner: guix pack -f docker -S /bin=bin paml clustal-omega which creates a reproducible Docker image containing PAML and Clustal Omega  [33] , including all of their runtime dependencies. Guix makes it very easy to write new package definitions using the Guile language (a LISP). If you want to include the definition of your own packages (that are not in Guix main line), you can include them dynamically. This is how we add pal2nal  [34]  in below GWL workflow example (see Subheading 3. 3 below).
Conda Conda (https://conda. io/docs/) is a cross-platform package manager written in Python that can be used to install software written in any language. Conda allows the creation of separate environments to deploy multiple or conflicting packages versions, offering a means of isolation. Note that this isolation is not as rigorous as that provided by GNU Guix or containers. The Bioconda  [35]  (https://bioconda. github. io/) project provides immediate access to over 2900 software packages for bioinformatics, and it is maintained by an active community of more than 200 contributors.
Create a Docker Image with Bioconda A Docker container can be created starting from the "Miniconda" image template, which is based on Debian. Note that we provide the version numbering of the packages. If you want to build this container, you can use the Dockerfile provided in the GitHub repository  [30]  and then run: docker build -t scalability. We also added a pre-built container image on Docker Hub  [31]. Conda can also be used outside any container system to install the software directly on a local computer or cluster. To do that first install the Miniconda package https://conda. io/miniconda. html, and then you can create a separate environment with the necessary software to run the workflows. Following is an example to set up a working environment: conda create -n scalability source activate scalability conda config --add channels conda-forge conda install -y perl=5.
The example workflow aligns amino acid sequences using Clustal Omega, creates a neighbor joining tree, and runs CodeML from the PAML suite. The following is one example to look for evidence of positive selection in a specific group of alignments: First we align amino acid with Clustal Omega, followed by translation to a nucleotide alignment with pal2nal. Next we test for evidence of positive selection using PAML's \name{Codeml} with models M0-M3. Note that the tools and settings used here are merely chosen for educational purposes. The approach itself here may result in false positives, as explained by Schneider et al. [37]. Also, PAML is not the only software that can test for evidence of positive selection, for example, the HyPhy molecular evolution and statistical sequence analysis software package contains similar functionality and uses MPI to parallelize calculations  [38].
PAML is used here because it is a reference implementation and is suitable as an example how a legacy single-threaded bioinformatics application can be parallelized in a workflow. In the next section, different workflow systems are presented that can be used to run the described analysis: in a scalable and reproducible manner, locally on a desktop, on a computer cluster, or in the cloud. All the code and data to run these examples is available on GitHub  [30]. To load the code on your desktop, clone the git repository locally. The examples can be executed from the repository tree: git clone https://github. com/EvolutionaryGenomics/scalability-reproducibility-chapter. git.
The benefits of explicitness and isolation are flexibility, portability, and scalability: tools and workflows described with CWL can transparently leverage software deployment technologies, such as Docker, and can be used with CWL implementations from different vendors, and the language itself can be applied to describe large-scale workflows that run in HPC clusters, or the cloud, where tasks are scheduled in parallel across many nodes. CWL workflows are written in JSON or YAML formats. A workflow consists of blocks of steps, where each step in turn is made up of a task description that includes the inputs and outputs of the task itself. The order of execution of the tasks is determined automatically by the implementation engine. In the GitHub repository, we show an example of a CWL workflow to describe the analysis over the protein alignments.
Guix Workflow Language The Guix Workflow Language (GWL) extends the functional package manager GNU Guix  [32]  with workflow management capabilities. GNU Guix provides an embedded domain-specific language (EDSL) for packages and package composition. GWL extends this EDSL with processes and process composition. In GWL, a process describes the computation, for example, running the clustalo program. A workflow in the GWL describes how processes relate to each other. For example, the Codeml program can only run after both clustalo and pal2nal finished successfully. The tight coupling of GWL and GNU Guix ascertains that not only the workflow is described rigorously but also the deployment of the programs on which the workflow depends. To run the GWL example, you need to install GNU Guix (https://www.
gnu. org/software/guix/manual/html_node/ Binary-Installation. html) and the GWL installed on your computer. Once GNU Guix is available, installing GWL can be done using: The example can be run using: cd scalability-reproducibility-chapter/GWL guix workflow -r example-workflow GWL also implements execution engines to offload computation on compute clusters, allowing it to scale. The process engines can use the package composition capabilities of GNU Guix to create the desirable form of software deployment-be it installing programs on the local computer or creating an application bundle, a Docker image, or a virtual machine image. Running our example on a cluster that has Grid Engine: guix workflow -r example-workflow -e grid-engine GNU Guix + GWL can ensure full reproducibility of an analysis, including all software dependencies-all the way down to glibc.
GNU Guix computes a unique string, a hash, on the complete set of inputs and the build procedure of a package. It can guarantee that a package is built with the same source code, dependency graph, and the same build procedure, and produces identical output. In GWL for each process and workflow, a hash is computed of the packages, the procedure, and the execution engine. By comparing hashes it is not only possible to compare whether the workflow is running using the exact same underlying software packages, and using the same procedures, but also the full graph of dependencies can be visualized. To obtain such an execution plot: guix package -i graphviz guix workflow -g example-workflow | dot -Tpdf > exampleworkflow. pdf Note that, unlike the other workflow solutions discussed here, GWL does not use the time stamps of output files.
Whether or not an output file is considered new depends on its time stamp relative to the time stamp of prerequisite input files. In doing so, Snakemake only performs work that has not yet been done or for which the results are out of date, just like GNU Make. Snakemake can be configured to distribute jobs to batch systems or to run jobs on the local system in parallel. The degree of parallelization depends on the dependencies between rules. Snakemake is written in Python and allows users to import Python modules and use them in the definition of rules, for example. It also has special support for executing R scripts in rules, by exposing rule parameters (such as inputs, outputs, concrete values for wildcards, etc. ) as an S4 object that can be referenced in the R script. Snakemake provides native support for the Conda package manager.
A rule may specify a Conda  [35]  environment file describing a software environment that should be active when the rule is executed. Snakemake will then invoke Conda to download the required packages as specified in the environment file. Alternatively, Snakemake can interface with an installation of the Singularity container system  [26]  and execute a rule within the context of a named application bundle, such as a Docker image. To run the Snakemake workflow, you need to install Snakemake (example showed with Conda): conda install -y -c bioconda snakemake=4. 2. 0 And then to run the example from the repository tree: cd Snakemake snakemake.
Nextflow Nextflow  [43]  is a framework and an orchestration tool that enables scalable and reproducible scientific workflows using software containers (https://www. nextflow. io/). It is written in the Groovy JVM programming language  [44]  and provides a domain-specific language (DSL) that simplifies writing and deploying complex workflows across different execution platforms in a portable manner. A Nextflow pipeline is described as a series of processes, where each process can be written in any language that can be executed or interpreted on Unix-like operating systems (e. g. , Bash, Perl, Ruby, Python, etc. ). A key component of Nextflow is the dataflow programming model, which is a message-based abstraction for parallel programming similar to the CSP paradigm (see  [23] ). The main difference between CSP and dataflow is that in the former, processes communicate via synchronous messages, while in the latter, the messages are sent in an asynchronous manner.
But Nextflow can handle this data flow in a parallel and asynchronous manner, so a process can operate on multiple inputs and emit multiple outputs at the same time. In a simple workflow where, for instance, there are 100 nucleotide sequences to be aligned with the NCBI NT database using BLAST, a first process can compute the alignment of the 100 sequences independently and in parallel, while a second process will wait to receive and collect each of the outputs from the 100 alignments to create a final results file. To allow workflow portability, Nextflow supports multiple container technologies such as Docker and Singularity and integrates natively with Git and popular code sharing platforms, such as GitHub. This makes it possible to precisely prototype self-contained computational workflows, tracking also all the modifications over time and ensuring the reproducibility of any former configuration.
For instance, container-based systems such as Docker and Singularity are not always a viable option in HPC environments since they may require updates to the existing computing infrastructure. Also, HPC operating system installations may include kernel versions that do not allow for the so-called user namespaces, a fundamental component among the many kernel features that together allow an application to run in an isolated container environment. Another downside of containers is that it is hard to assess what is in them-they act like a black box. When creating containers with above Docker scripts, it depends on the time they are assembled what goes in. A Debian or Conda update between creating containers, for example, may include a different software version therefore a different dependency graph.
Only GNU Guix containers provide a clear view on what is contained. Containers provide isolation from the underlying operating system. On HPC environments it may be required to run software outside a container. While applications built with Guix or Conda can be run in isolation when container support is available, they do not require these features at runtime. As a package manager Conda, neither depends on container features nor on root privileges, but it pays for this convenience with a lack of both process isolation and bit-reproducibility  [47]. GNU Guix, meanwhile, provides the most rigorous path to reproducible software deployment. In order to guarantee that packages are built in a bit-reproducible fashion and share binary packages, Guix requires to store packages in the directory /gnu/store.
The data collected from the 24 responses generated a motivational vector for each participant. This vector was calculated by adding up all the allocations opted for. The vector was then mapped back into an original circle (the 24 pairs of outcomes are evenly distributed in this circle) thanks to its conversion into an angle of social value. Following  Liebrand (1984) , this angle was then used to characterize the subject with one of five categories. 8 We conducted 12 experimental sessions with a total of 180 subjects. Subjects were undergraduates coming from different departments of the university and from engineering schools, with no background in game theory. The experiment proceeded as follows. As they arrived in the laboratory, subjects received a personal code both to preserve their anonymity and to log into the software dedicated to the experiment.
Dictator and Trust Games Average investment is higher under TG compared to DG (Average investment x are reported in Table  7  in Appendix B). In Figure  1    The possibility of a payment back to the investor has an effect on their decisions to invest. We can see from Figure  1  that the proportion of x > 0 increased significantly from the dictator game to the trust game: it often more than doubled. On the other hand, fewer subjects opted for the 2 euros investment as it was then no longer the only way of achieving equal payoffs. Both results are consistent with Hypothesis 1. We estimate investment econometrically under several specifications. The analysis makes use of the within-subject structure of our data by performing mixed effects Logit models to control for individual heterogeneity and repeated observations for each subject.
10. Specific data from these two tests are reported in our companion paper  Garapin et al. (2015). Results are represented in Table  2  below. 10 For these analyses, we kept 141 individuals that all performed the three parts of the experiment (risk test, social value test, the two games). The remaining subjects were withdrawn from the analysis because they made inconsistent choices either in the risk test or in the ring test (25 subjects) and because of a computer bug in the ring test during one session (14 subjects). As subjects take in total 8 investment decisions (8 treatments), we thus obtain 141 × 8=1128 observations, except for models II, III, VI and VIII limited to one game only, DG or TG (141 × 4=564 observations). Also note that the different parts of the experiments (RT, RA and DG-TG) were sorted differently in every experimental session (see Table  6  in Appendix A).
Background: The problem of access to medical information, particularly in low-income countries, has been under discussion for many years. Although a number of developments have occurred in the last decade (e. g. , the open access (OA) movement and the website Sci-Hub), everyone agrees that these difficulties still persist very widely, mainly due to the fact that paywalls still limit access to approximately 75% of scholarly documents. In this study, we compare the accessibility of recent full text articles in the field of ophthalmology in 27 established institutions located worldwide. Methods: A total of 200 references from articles were retrieved using the PubMed database. Each article was individually checked for OA. Full texts of non-OA (i. e. , "paywalled articles") were examined to determine whether they were available using institutional and Hinari access in each institution studied, using "alternative ways" (i.
MATERIALS AND METHODS The search for articles to be included in this study was carried out on March 29th, 2018 using the PubMed database (http://www. ncbi. nlm. nih. gov/pubmed), developed by the National Center for Biotechnology Information at the National Library of Medicine. The search strategy was: eye diseases [MH] AND 2017:2018 [DP] AND English [LA] AND Journal Article  [PT]  where MH stands for "Medical Subject Headings," DP "Date of Publication," and PT "Publication Type. " "Journal Article" includes the following publication types: journal articles, introductory journal articles, and reviews as previously described in the field of ophthalmology  (Boudry et al. , 2016). Data were downloaded from PubMed in Comma-Separate values and were imported to Microsoft Excel 2013 (Microsoft, Redmond, WA, USA) for data processing.
The cost of unavailable full text articles in each institution was calculated in US dollars, and was also expressed as the percentage of the GDP per capita at PPP (current international $), using the World Development Indicators from the online databases of the World Bank  (World Bank, 2018). The GDP is the market value of all officially recognized final goods and services produced within a country in a given period. Using the percentage of Among the 200 articles studied, 85 full texts (42. 5%) were freely available on publishers' websites ("publisher OA" articles), whereas 115 (57. 5%) full texts were available only with subscriptions ("paywalled articles"). See Supplemental Information 3 for the list of the 115 "paywalled articles. " Figure  1  presents the number of full texts of the 115 "paywalled articles" available in each institution using institutional and Hinari access.
" Furthermore, we wanted to compare the results obtained with the three ways of accessing full text "paywalled articles. " Our data included the average number of full texts available and the average extra costs, in US dollars and expressed as the percentage of GDP per capita at PPP. We found that using institutional/Hinari access; using institutional/Hinari access and "alternative ways;" and using institutional/Hinari access, "alternative ways," and Sci-Hub were significantly different at p < 0. 05 (p-value < 0. 001). However, as the ways of accessing full text "paywalled articles" were not independent (because of the cumulative effect that binds them), these statistical results were not taken into account. We deliberately limited the search to articles published in 2017-2018 to include only very recent articles.
, 2016) ; promoting Green OA (self-archiving in OA repositories) by setting up institutional or national OA policies  (Kirsop & Chan, 2005 ; Machin-Mastromatteo, Uribe-Tirado & Romero-Ortiz, 2016), (e. g. , as it has been done recently in France)  (Boudry & Durand-Barthez, 2017) ; and implementing subscription-based access for a reasonable price. This has already been done in other areas, particularly in the field of music, "offering individual subscription-based access to all articles from all imaginable databases for a price that most scientists in any corner of the world could afford"  (Strielkowski, 2017).
We consider the well-known "Pima Indians" dataset (standardized), which records a binary response variable (the incidence of diabetes) for 532 women, along with seven possible predictors. We specify a Logistic Regression model with predictors: Number of Pregnancies, Plasma Glucose Concentration, Body Mass Index, Diabetes Pedigree Function, and Age (see  [11]  for justification). The prior is β ∼ N(0, I), as in  [11]. To obtain samples from the posterior density, we implement an isotropic Random Walk sampler, using a radially symmetric Gaussian density with σ 2 = 7. 5 × 10 -3 (trace plots indicate this choice mixes well for the model). We ran the Random Walk sampler for 10 3 steps for burn-in, then used the next 2. 5 × 10 4 samples (without any thinning) to obtain a KDE, as well as density estimates using our sensitivity estimator (with control variate).
At CLEF 2018, the Personalised Information Retrieval Lab  (PIR-CLEF 2018)   has been conceived to provide an initiative aimed at both providing and critically analysing a new approach to the evaluation of personalization in Information Retrieval (PIR). PIR-CLEF 2018 is the first edition of this Lab after the successful Pilot lab organised at CLEF 2017. PIR CLEF 2018 has provided registered participants with the data sets originally developed for the PIR-CLEF 2017 Pilot task; the data collected are related to real search sessions over a subset of the ClueWeb12 collection, undertaken by 10 users by using a novel methodology. The data were gathered during the search sessions undertaken by 10 volunteer searchers. Activities during these search sessions included relevance assessment of a retrieved documents by the searchers.
16 groups registered to participate at PIR-CLEF 2018 and were provided with the data set to allow them to work on PIR related tasks and to provide feedback about our proposed PIR evaluation methodology with the aim to create an effective evaluation task. Recent years have seen increasing interest in the study of contextual search: in particular, several research contributions have addressed the task of personalizing search by incorporating knowledge of user preferences into the search process 1 http://trec. nist. gov/data/session. html.
Among some previous attempts to define PIR benchmark tasks based on the Cranfield paradigm, the closest experiment to the PIR Lab is the TREC Session track 1 conducted annually between 2010 and 2014. This track focused on stand-alone search sessions, where a "session" is a continuous sequence of query reformulations on the same topic, along with any user interaction with the retrieved results in service of satisfying a specific information need; however no details of the searcher undertaking the task have been made available. Thus, the TREC Session track did not exploit any user model to personalise the search experience, nor did it allow user actions over multiple search session to be taken into consideration in the ranking of the search output. The PIR-CLEF 2018 Lab has provided search data gathered in search sessions carried out ten volunteer users: the provided data were originally collected for the Pilot Lab run in 2017.
We plan in the future to gather data across multiple sessions to enable the construction and exploitation of persistent user behaviour data collected from the user across the multiple search sessions. This year the data were provided to the 16 groups registered to task. with the objective of allowing them to attempt the proposed tasks. An evaluation using this collection was run to allow research groups working on PIR to both experience with and provide feedback about our proposed PIR evaluation methodology. Two papers were submitted and accepted for presentation at the workshop related to the Lab; both papers report on the usage of the collected data to perform different tasks; the work reported in these papers is summarized later in this overview. The papers give some useful suggestions to improve the data gathering process, which will give rise to interesting discussions during the Lab.
The Pilot task was based on search sessions over a subset of the ClueWeb12 document collection, undertaken by 10 users by using a clearly defined and novel methodology. The collection was defined by relying on data gathered from activities undertaken during the search sessions by each participant, including details of relevant documents as marked by the searchers. An important point to be outlined is that the collection was prepared but not used by any group participating at the pilot task. For this reason at PIR-CLEF 2018 we relied on this data collection. We distributed it to the 16 groups registered to the Lab. We have also prepared a second collection, as well as a prototype system for the comparative evaluation of systems developed by participating groups. The data collection is described in more detail in Section 3.