dataesr/scientific-paragraphs-categorization huggingface dataset:
National Coordinators were supplied with electronic copies of the dataset, coding, and definitions and given a contact for the Study Management Team (SMT) so that any specific queries could be dealt with by the SMT or escalated to the SC as required. Each SMT member acted as a liaison person for a group of countries and kept in contact with NCs in case of issues arising. Data were extracted from national, regional or local OHCA registries and databases, or by use of a paper version of the EuReCa ONE datasheet for data collection. Data were obtained from: existing registries with national coverage (five countries); existing registries with partial country coverage (eight countries); registries provided by the local Resuscitation Council (three countries); patient ambulance records (three countries).
Role of the funding source The study was funded by the European Resuscitation Council (ERC) and by the individual registries within participating countries. Co-funding was provided by the German Anaesthesiology Association (BDA). The Laerdal Foundation for Acute Medicine cofunded a meeting of the NCs, the SMT, and the SC. The funding organisations had no influence on the data analysis or preparation of the manuscript. The ERC appointed a SC that was responsible for the study design, conduct, and data analyses. Technical and administrative support was given by the SMT. Members of the SC had full access to the study data and all NCs were responsible for critical revision of the submitted version of the manuscript.
Outcomes for the Utstein comparator group The Utstein comparator group included patients with a bystander witnessed arrest of suspected cardiac cause and an initial recorded shockable rhythm. In 12. 5% of patients (890/7146), all criteria for the Utstein comparator were available (Supplement S2). Seven countries with less than ten patients in the Utstein comparator group were excluded (25 cases). Information on ROSC was available for 845 (98%) of these cases. The overall proportion of ROSC was 56. 8%, ranging from 25. 0% to 84. 6% between countries. Data on survival was available for 733 patients (85%) (Fig. 5 ). Of these patients, 218 (29. 7%) survived for at least 30 days or to hospital discharge. Survival ranged between 5. 3% and 57. 9%. The incidence rate of survival ranged from 0. 1 survivors to 6.
Discussion This is the first study reporting incidence, community involvement (as bystander CPR), and outcomes following OHCA in 27 European countries. Assuming that the rate of OHCA was similar during the remaining eleven months of the year, we found an incidence rate of 84 per 100,000 population. previous study reported 87. 4 OHCAs per 100,000 person-years for Europe. 21 Thus, our results suggest that the incidence of OHCA in Europe is in the range of what has previously been reported. We found the overall incidence of OHCA where CPR was started to be 49 patients per 100,000 population. This Fig. includes  EMS and bystander treated cardiac arrests. It is clearly higher than previously reported from Europe ten years ago (38. 0 per 100,000). 1 n the other hand, our findings are in good agreement with more recent data from national surveys in Denmark and Sweden.
Third, variation in incidence rate may be due to seasonal variations or indicate, legal, cultural, and religious differences in the willingness to activate EMS and to initiate resuscitation when a low probability of success is expected, or to terminate efforts in the field, which may affect admission rates. Three countries only reported cases where resuscitation was started or continued by EMS staff. Another issue that can influence outcome is the actual availability of EMS resources to the population served. Higher availability may promote the decision to start resuscitation, especially countries bystander CPR is lower. These factors are not recorded and it is not known how they may have affected individual cases. This limits our interpretation of the data and attribution of these differences to biological patient factors or to system paramaters of health care for OHCA.
Funding The study was funded by European Resuscitation Council (ERC) and by the individual registries within participating countries. Co-funding was provided by the German Anaesthesiology Association (BDA). The Laerdal Foundation for Acute Medicine cofunded a meeting of the NCs, the SMT and the SC. The open-Access Option was funded by the German Resuscitation Registry. The funding organisations had no influence on the data analysis or preparation of the manuscript.
Pipeline A pipeline was written in Python (v2. 7) to perform all the actions to create Lifemap and keep it up-to-date. The pipeline uses the ETE 3 toolkit  [14]  for tree operations (traversal) and NCBI interrogation. Here are the main steps: Visualizing a tree with the Lifemap server is a three-step process that is performed from the dedicated web page (top screen). Once the tree file has been uploaded and the computations have been performed, the tree can be explored (bottom screen). This last screenshot shows the appearance of Lifemap for a fully bifurcating tree with nodes automatically named (see text). doi:10. 1371/journal. pbio. 2001624. g003 • Retrieve NCBI taxonomy from the NCBI website (or OTOL taxonomy from the OTOL web site) and convert to Newick format. • Only for the general public version: Remove all taxa whose name contains the words "unidentified," "Unidentified," "unclassified," "Unclassified," "environmental," "Environmental," "uncultured," or "Uncultured," and all taxa below the species level.
• While traversing the tree: • Compute the coordinates of (i) nodes and tips, (ii) half-circles, (iii) half-circle centers where clade names are written at some zoom levels, (iv) rank names along the half-circles • Write all these coordinates in a postgreSQL database that has PostGIS enabled • Write information associated with each node and tip into the Solr Search Engine v5. 4. 0 (scientific name, common name, coordinates, zoom level, rank name, taxid). • Get additional information for each taxa (for now, the number of genomes fully sequenced), and write this information into Solr. All Lifemap functions are freely available (Under the GNU General Public License) on GitHub at https://github. com/damiendevienne/Lifemap/, along with detailed descriptions of the functions, the configuration files, the requirements, etc.
NCBI and OTOL data The NCBI taxonomy data is retrieved from the NCBI ftp site (ftp://ftp. ncbi. nlm. nih. gov/pub/ taxonomy/) every time the tree is updated. This is done automatically by the ETE 3 toolkit  [14]  used in the pipeline described above. For the Lifemap OTOL version, the latest OTOL synthetic tree is downloaded from https://tree. opentreeoflife. org/about/synthesis-release/, and the associated taxonomy version is retrieved from https://tree. opentreeoflife. org/about/taxonomyversion/. Currently, the synthetic tree version 7. 0 is used, along with the taxonomy version 2. 10.
Tiling and image production The zooming capability of the tool relies on the same principle and the same tools as OSM. The whole space is cut into square images (tiles) of 256 x 256 px and to each image at zoom n corresponds four images at zoom n + 1 (Fig  4 ). Images are generated when first requested by a user, thanks to the mod_tile open source apache module linked to the renderd tool (both part of the OSM suite of tools  [15] ) and cached on the server for further accession. The creation of the images is performed by mapnik v3. 0. 9  [16] , which reads the database, formats the graphical elements with respect to a style sheet written for Lifemap, and returns the images to the server. Note that the number of images is expected to grow exponentially. The level zero of Lifemap, where all three superkingdoms are visible, is formed by four images.
Map-browser interaction and mobile version The websites on which Lifemap can be explored were written in HTML5, CSS, and Javascript, using the Leaflet v0. 7 javascript library  [17]. A mobile version of the tool was also written. The user is automatically redirected to this website if accessing Lifemap from a phone. The creation of the mobile app was performed using PhoneGap  [18] , a tool that allows encapsulating an HTML5/CSS/Javascript website and all its dependencies into a fully featured mobile application that can be uploaded to Android, Apple, or Microsoft stores.
Acknowledgments I thank  Stephane Delmotte  and  Bruno Spataro  for help in the Lifemap servers preparation and the creation of the virtual machine, and all the members of the  Laboratory of Biometry and Evolutionary Biology (LBBE, Lyon ) for agreeing to beta-test the tool. Thanks also to  Manolo Gouy ,  Laurent Duret , and  Dominique de Vienne  for insightful discussions and corrections to the first version of this text.
Background. VSEARCH is an open source and free of charge multithreaded 64-bit tool for processing and preparing metagenomics, genomics and population genomics nucleotide sequence data. It is designed as an alternative to the widely used USEARCH tool  (Edgar, 2010)  for which the source code is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use. Methods. When searching nucleotide sequences, VSEARCH uses a fast heuristic based on words shared by the query and target sequences in order to quickly identify similar sequences, a similar strategy is probably used in USEARCH. VSEARCH then performs optimal global sequence alignment of the query against potential target sequences, using full dynamic programming instead of the seed-and-extend heuristic used by USEARCH.
Several pipelines have been developed for microbiome analysis, among which mothur  (Schloss et al. , 2009) , QIIME  (Caporaso et al. , 2010) , and UPARSE  (Edgar, 2013)  are the most popular. QIIME and UPARSE are both based on USEARCH  (Edgar, 2010) , a set of tools designed and implemented by Robert C. Edgar, and available at http://drive5. com/usearch/. USEARCH offers a great number of commands and options to manipulate and analyse FASTQ and FASTA files. However, the source code of USEARCH is not publicly available, algorithm details are only rudimentarily described, and only a memory-confined 32-bit version is freely available for academic use. We believe that the existence of open-source solutions is beneficial for end-users and can invigorate research activities. For this reason, we have undertaken to offer a high quality open-source alternative to USEARCH, freely available to users without any memory limitation.
Reading FASTA and FASTQ files Most VSEARCH commands read files in FASTA or FASTQ format. The parser for FASTQ files in VSEARCH is compliant with the standard as described by  Cock et al. (2010)  and correctly parses all their tests files. FASTA and FASTQ files are automatically detected and many commands accept both as input. Files compressed with gzip or bzip2 are automatically detected and decompressed using the zlib library by  Gailly & Adler (2016)  or the bzip2 library by  Seward (2016) , respectively. Data may also be piped into or out of VSEARCH, allowing for instance many separate FASTA files to be piped into VSEARCH for simultaneous dereplication, or allowing the creation of complex pipelines without ever having to write on slow disks. VSEARCH is a 64-bit program and allows very large datasets to be processed, essentially limited only by the amount of memory available.
Searching Global pairwise sequence comparison is a core functionality of VSEARCH. Several commands compare a query sequence against a database of sequences: all-vs-all alignment (allpairs_global), clustering (cluster_fast, cluster_size, cluster_smallmem), chimera detection (uchime_denovo and uchime_ref ) and searching (usearch_global). This comparison function proceeds in two phases: an initial heuristic filtering based on shared words, followed by optimal alignment of the query with the most promising candidates. The first phase is presumably quite similar to USEARCH  (Edgar, 2010). Heuristics are used to identify a small set of database sequences that have many words in common with the query sequence. Words (or k-mers) consist of a certain number k of consecutive nucleotides of a sequence (8 by default, adjustable with the wordlength option).
All overlapping words are included. A sequence of length n then contains at most nk + 1 unique words. VSEARCH counts the number of shared words between the query and each database sequence. Words that appear multiple times are counted only once. To count the words in the database sequences quickly, VSEARCH creates an index of all the 4 k possible distinct words and stores information about which database sequences they appear in. For extremely frequent words, the set of database sequences is represented by a bitmap; otherwise the set is stored as a list. A finer control of k-mer indexing is described for USEARCH by the pattern (binary string indicating which positions must match) and slots options. USEARCH has such options but seems to ignore them. Currently, VSEARCH ignores these two options too.
The minimum number of shared words required may be specified with the minwordmatches option (10 by default), but a lower value is automatically used for short or simple query sequences with less than 10 unique words. Comparing sequences based on statistics of shared words is a common method to quickly assess the similarity between two sequences without aligning them, which is often time-consuming. The D 2 statistic and related metrics for alignment-free sequence comparison have often been used for rapid and approximate sequence matching and their statistical properties have been well studied  (Song et al. , 2014). The approach used here has similarities to the D 2 statistic, but multiple matches of the same word are ignored. In the second phase, searching proceeds by considering the database sequences in a specific order, starting with the sequence having the largest number of words in common with the query, and proceeding with a decreasing number of shared words.
If two database sequences have the same number of words in common with the query, the shortest sequence is considered first. The query sequence is compared with each database sequence by computing the optimal global alignment. The alignment is performed using a multithreaded and vectorised full dynamic programming algorithm  (Needleman & Wunsch, 1970)  adapted from SWIPE  (Rognes, 2011). Due to the extreme memory requirements of this method when aligning two long sequences, an alternative algorithm described by  Hirschberg (1975)  and  Myers & Miller (1988)  is used when the product of the length of the sequences is greater than 25,000,000, corresponding to aligning two 5,000 bp sequences. This alternative algorithm uses only a linear amount of memory but is considerably slower. This second phase is probably where USEARCH and VSEARCH differ the most, as USEARCH by default presumably performs heuristic seed-and-extend alignment similar to BLAST  (Altschul et al.
, 1997) , and only performs optimal alignment when the option fulldp (full dynamic programming) is used. Computing the optimal pairwise alignment in each case gives more accurate results but is also computationally more demanding. The efficient and vectorised full dynamic programming implementation in VSEARCH compensates that extra cost, at least for sequences that are not too long. If the resulting alignment indicates a similarity equal to or greater than the value specified with the id option, the database sequence is accepted. If the similarity is too low, it is rejected. Several other options may also be used to determine how similarity is computed (iddef, as USEARCH used to offer up to version 6), and which sequences should be accepted and rejected, either before (e. g. , self, minqsize) or after alignment (e.
Clustering VSEARCH includes commands to perform de novo clustering using a greedy and heuristic centroid-based algorithm with an adjustable sequence similarity threshold specified with the id option (e. g. , 0. 97). The input sequences are either processed in the user supplied order (cluster_smallmem) or pre-sorted based on length (cluster_fast ) or abundance (the new cluster_size option). Each input sequence is then used as a query in a search against an initially empty database of centroid sequences. The query sequence is clustered with the first centroid sequence found with similarity equal to or above the threshold. The search is performed using the heuristic approach described above which generally finds the most similar sequences first. If no matches are found, the query sequence becomes the centroid of a new cluster and is added to the database.
If maxaccepts is higher than 1, several centroids with sufficient sequence similarity may be found and considered. By default, the query is clustered with the centroid presenting the highest sequence similarity (distance-based greedy clustering, DGC), or, if the sizeorder option is turned on, the centroid with the highest abundance (abundance-based greedy clustering, AGC)  (He et al. , 2015; Westcott & Schloss, 2015; Schloss, 2016). VSEARCH performs multi-threaded clustering by searching the database of centroid sequences with several query sequences in parallel. If there are any non-matching query sequences giving rise to new centroids, the required internal comparisons between the query sequences are subsequently performed to achieve correct results. For each cluster, VSEARCH can create a simple multiple sequence alignment using the center star method  (Gusfield, 1993)  with the centroid as the center sequence, and then compute a consensus sequence and a sequence profile.
Dereplication and rereplication Full-length dereplication (derep_fulllength) is performed using a hash table with an open addressing and linear probing strategy based on the Google CityHash hash functions (written by Geoff Pike and Jyrki Alakuijala, and available at https://github. com/google/ cityhash). The hash table is initially empty. For each input sequence, the hash is computed and a lookup in the hash table is performed. If an identical sequence is found, the input sequence is clustered with the matching sequence; otherwise the input sequence is inserted into the hash table. Prefix dereplication (derep_prefix) is also implemented. As with full-length dereplication, identical sequences are clustered. In addition, sequences that are identical to prefixes of other sequences will also be clustered together.
If a sequence is identical to the prefix of multiple sequences, it is generally not defined how prefix clustering should behave. VSEARCH resolves this ambiguity by clustering the sequence with the shortest of the candidate sequences. If they are equally long, priority will be given to the most abundant, the one with the lexicographically smaller identifier or the one with the earliest original position, in that order. To perform prefix dereplication, VSEARCH first creates an initially empty hash table. It then sorts the input sequences by length and identifies the length s of the shortest sequence in the dataset. Each input sequence is then processed as follows, starting with the shortest: If an exact match to the full input sequence is found in the hash table, the input sequence is clustered with the matching hash table sequence.
The sequences resulting from dereplication and many other commands may be relabeled with a given prefix followed by a sequentially increasing number. VSEARCH exclusively also offers the possibility of relabelling each sequence with the SHA-1  (Eastlake & Jones, 2001)  or MD5  (Rivest, 1992)  message digest (hash) of the sequence. These are strings that are highly likely to be unique for each sequence. Before the digest is computed, the sequence is normalized by converting U's to T's and converting all symbols to upper case. VSEARCH includes public domain code for the MD5 algorithm written by Alexander Peslyak, and for SHA1 by Steve Reid and others. VSEARCH also includes a new command (rereplicate) to perform rereplication that can be used to recreate datasets as they were before full-length dereplication, but of course original labels cannot be recreated.
Chimera detection Chimeras are detected either de novo (uchime_denovo command) or with a reference database (uchime_ref command) using the UCHIME algorithm described by  Edgar et al. (2011). VSEARCH will divide each query sequence into four segments and look for similarity of each segment to sequences in the set of potential parents using the heuristic search function described earlier. It will consider the four best candidates for each segment using maxaccepts 4 and maxrejects 16, and an id threshold of 0. 55. VSEARCH optionally outputs borderline sequences, that is, sequences having a high enough score (as specified with the minh option) but with too small a divergence from the closest parent (as specified with the mindiv option). Multi-threading is supported for reference-based chimera detection.
Low-complexity sequence masking VSEARCH includes a highly optimized and parallelized implementation of the Dust algorithm by Tatusov and Lipman for masking of simple repeats and low-complexity nucleotide sequences. It is considerably faster than the implementation of the same algorithm in USE-ARCH. Their code available at ftp://ftp. ncbi. nlm. nih. gov/pub/tatusov/dust/version1/src/ is in the public domain. VSEARCH uses this algorithm by default, while USEARCH by default uses an undocumented rapid masking algorithm called fastnucleo. VSEARCH performs soft-masking automatically for the pairwise alignment, search, clustering and chimera detection commands. This behaviour can be controlled with the hardmask option to replace masked symbols with N's instead of lower-casing them, and the dbmask and qmask options, which selects the masking algorithm (none, dust or soft) used for the database and query sequences, respectively.
Supported commands and options VSEARCH implements the following commands available in  USEARCH version 7: allpairs_global, cluster_fast, cluster_smallmem, derep_fulllength, derep_prefix, fastq_chars, fastq_filter, fastq_mergepairs, fastq_stats, fastx_mask, maskfasta, sortbylength, sortbysize, uchime_denovo, uchime_ref   Almost all USEARCH 7 options are supported, except for those related to non-standard database indexing  (alpha, dbaccelpct, dbstep, pattern, slots)  as well as local alignments and alignment heuristics  (band, hspw, lext, lopen, matrix, minhsp, xdrop_g, xdrop_nw, xdrop_u). The same command and option names as in USEARCH version 7 have generally been used in order to make VSEARCH an almost drop-in replacement. In fact, in QIIME many commands will run fine if an alias or link from usearch to vsearch is made.
Performance assessment The performance of the most important functions of VSEARCH version 2. 0. 3 (64-bit) was evaluated and compared to the 32-bit versions of USEARCH version 7. 0. 1090 and 8. 1. 1861. All datasets used were small enough to fit comfortably in the memory allocated to a 32-bit process. Chimera detection was also compared to UCHIME version 4. 2. All tests were run on GNU/Linux CentOS 6. 7 compute nodes with 16 physical cores (Intel(R) Xeon(R) CPU E5-2670 0 @ 2. 60 GHz) and 64GB RAM. Programs were run with 8 threads, if possible. All times indicated are wall-clock times. All scripts and data necessary to perform the evaluations are available in the GitHub repository at https://github. com/torognes/vsearch-eval/ to enable independent replication.