dataesr/scientific-paragraphs-categorization huggingface dataset:
RepeatsDB website The RepeatsDB database structure was redesigned to support automatic updates and interoperability with the PDB and UniProt public APIs. Data is however stored locally to prevent broken dependencies and as a MongoDB database. As RepeatsDB data is expected to serve experimentalists as well as bioinformaticians, the website was designed as a multi-tier architecture. It is accessible through a web interface or programmatically exploiting a RESTful architecture. The user interface has been completely redesigned to improve user experience and satisfy both general use and detailed analyses. It retrieves data from public APIs without further processing, allowing accessibility to the same type of data as the web interface to the users of the web server. The web interface is implemented using the Angular and Bootstrap frameworks.
Browsing and searching data The user interface presents an intuitive summary table providing direct access to all entries by structural class directly from the home page, and a search box on the right top for straightforward searches based on UniProt accessions, PDB or RepeatsDB IDs and free text searches. For a finer search, the user can visit either the 'Search' page for generating complex queries or the 'Browse' page providing full classification access (see Figure  2 ). The 'Search' page allows the user to perform advanced queries against a range of RepeatsDB-specific and third-party search fields. The input can be simple text or numeric (single value or range) according to the field type and multiple queries can be combined by boolean operators (AND, OR, NOT). The 'Browse' page provides the entry point for all levels of the new RepeatsDB classification.
PDB and UniProt entry pages This version of RepeatsDB introduces two types of entry pages in order to allow different data visualizations (Figure  2 ). The PDB chain entry visualization is similar to the entry page from previous versions, including basic information about the PDB entry, the summary of detected repeat regions (annotated with start, end, classification) and the position of repeats over sequence and structure. The PDB entry page includes a tab for each repeat region showing the multiple structural and sequence alignment of units. In addition, the novel "structural similarity matrix" allows the visualization of the pattern of similarity between units within a repeat region. The repeat information of different PDB chains mapping to the same UniProt entry is aggregated in the UniProt entry page, newly introduced in RepeatsDB 3.
RepeatsDB API RepeatsDB provides programmatic access to perform a search through a RESTful web service API. A single entry can be retrieved by using PDB or UniProt identifiers, while database searches can be performed by specifying query fields directly as URL parameters in the HTTP request. Free text search is also available, retrieving matches for the most common types of biological identifiers or substrings in the protein name. RepeatsDB annotation is available for download in DB (RepeatsDB files), JSON, FASTA and TSV formats. Aiming to make RepeatsDB data more FAIR, we implemented Bioschemas markup  [35]  using the JSON-LD format in the main and entry pages.
Conclusions and future work RepeatsDB was first introduced in 2014 with an updated release in 2017. Our continuous classification and annotation effort aims to provide the community with a central resource for high-quality tandem repeat protein characterization. The database has been used in several studies regarding TRs and to benchmark algorithms for the detection of proteins with repeats. The iterative annotation process that bases RepeatsDB update and the interface for the automatic prediction curation  [18]  will allow a continuous growth and increase in quality of the extensive TR annotation. The main novelties of the presented RepeatsDB release regard (1) the new data visualization, based on UniProt entries and oriented to standardize the annotation of repeat phases and (2) the addition of two levels in the RepeatsDB classification schema, i.
e. folds and clans, representing TRs with similar overall structural arrangement (twist, curve, etc. ) and TRs with a common sequence motif, respectively. This classification effort provides the basis for future work. A fine comparison and description of the relationship between the tandem repeat region sequence (e. g. from Pfam) and structure-based classifications will provide the toolbox for transferring annotation of TRs from different sources. In addition, uniform TR structural clusters (in terms of evolutionary origin and repeat phase) will provide an additional classification level, the "family" level, and will be exploited for the creation of sequence profiles for use in detecting repeats from sequence in genome-scale analyses  [36]. Finally, the curation community provided by the RepeatsDB consortium and the MSCA-RISE project "REFRACT" will expand repeat classification and guarantee data quality and long term maintenance.
Even a variant present at high levels can remain undetected depending on the selection of primers, probes or restriction enzymes, and in the past, using these methods, duplications have wrongly been classified as deletions  [18, 19, 24, 25]. An attractive idea is therefore to use high-throughput sequencing to detect mtDNA deletions and duplications, as this potentially can provide more sensitive, less biased and more accurate mapping of these alterations. This would also dramatically simplify the workflow, and would enable exploration of mtDNA deletions and duplications in a large body of preexisting sequencing datasets. Due to the high copy number of mtDNA in cells (n = 1,000-10,000), mtDNA-derived reads are typically highly abundant in genomic sequencing data, in principle making the technology ideally suited for the purpose.
We further compared the performance of MitoSAlt with five published pipelines on the same simulated dataset (S1 Table ). Two of the tools, eKLIPse and the PERL script provided in  (Zambelli et al. , 2017) , identified all events, but with the duplications reported as complementary arc deletions (i. e. start and end coordinates in reverse order). eKLIPse and Zambelli et al identified at most 94 and 186 breakpoint-spanning reads, respectively, suggesting that eKLIPse in particular has reduced sensitivity compared to MitoSAlt. Zambelli et al was less accurate when breakpoints were flanked by repeats: the 8,470-13,446 common deletion (flanked by a 13 bp identical repeat) was reported at 8482-13,447, and the 2,500-3,500 duplication (flanked by a longer imperfect repeat) was reported as a deletion at 3,525-2,500.
The remaining tools identified 4 out of 6 events at best. Splice-Break specifically failed to identify duplications associated with inverse-order split alignments (S1 Fig) , suggesting that the algorithm is not designed to handle this case. In addition to finding 4 out of the 6 true alterations, MitoMut identified 4 additional small deletions (S1 Table ). Similar results were obtained when simulated reads were generated using an error model derived from empirical data (S1 Table ). Next, we generated simulated datasets containing large numbers of low heteroplasmy level (0. 5%) deletions or duplications of various sizes (50, 500 and 2000 bp). Each dataset contained 200 events of a single type distributed across the major and minor arcs. Additionally, a dataset with 500 bp deletions with 5 bp random insertions was generated, to test the ability to handle non-template insertions at breakpoints.
Mitochondrial number was set to 6,000, and 50 million reads (5 million 2 × 126 bp) were generated for each dataset, resulting in a mean coverage of ~5,900× on chrM. All events were detected by MitoSAlt and Zambelli et al, though the latter had lower accuracy with respect to exact determination of breakpoint coordinates (Fig  2B  and S1 Table). Remaining tools all showed reduced or no sensitivity with respect to small duplications or duplications in general, as well as deletions with non-template insertions. Heteroplasmy estimates reported by MitoSAlt ranged from 0. 38% to 0. 57% on average in each dataset (Fig  2C ). No events were detected by MitoSAlt or the other tools in a simulated wild type dataset of similar size. MitoSAlt thus compared favorably to other tools in terms of sensitivity and breakpoint coordinate accuracy, in addition to being the only method capable of differentiating between duplications and deletions.
Application to mitochondrial disease patients We next tested the MitoSAlt pipeline on muscle biopsy DNA from mitochondrial disease patients with single high-heteroplasmy mtDNA deletions or duplications present at high levels as detected by long-range PCR (LX-PCR). Two patients carried a deletion while the third duplications, each at 16. 7% heteroplasmy (2 × 126 bp, 10,000,000 reads, resulting in ~2,000× mtDNA coverage). The circular plot shows deleted (blue) or duplicated (red) segments. The upper bar graph indicates the fraction of Mt reads mapped to the mitochondrial genome, while the lower shows heteroplasmy levels estimated by MitoSAlt for each event (events with 1 bp or 5 bp of the expected breakpoints are quantified separately). (B) Evaluation of sensitivity on simulated sequencing datasets containing large numbers of low heteroplasmy deletions and duplications of various sizes.
Alignment of sequencing reads The raw sequencing reads are aligned to the source genome (Nuclear + Mitochondrial) using HISAT2  [46]. HISAT2 is run with default parameters for RNA sequencing and specific parameters are used to customize it for DNA sequencing (-no-temp-splicesite-no-spliced-alignment-max-intronlen 5000). Following the first round of alignment the reads which remain unmapped or are mapped to the mitochondrial genome are extracted and converted to a concatenated FASTQ using Samtools. The FASTQ is realigned to the mitochondrial genome using the lastal (-Q1 -e80), processed using last-split and converted from MAF to BAM and TAB format using maf-convert, where all the binaries are part of the LAST software package. The results in TAB format are parsed in PERL and R to classify the potential deletions and duplications.
Final report and circular plots The CLUSTER, and BREAKPOINT files are further used by an R script to generate a final table, classifying each cluster as a duplication or a deletion using the logic described in S1 Fig. This report also contains information about direct repeat sequences overlapping with or flanking the breakpoints. It should be noted that genomic coordinates in the final table refer to start and end positions of the deleted or duplicated segments, rather than junction coordinates. Finally, the breakpoint positions (at the cluster level) are plotted on a circular plot (size of the input mitochondrial genome) as arcs using the R plotrix package, where the individual arcs are colored to indicate whether they represent deletions or duplications, and where the estimated heteroplasmy is indicated by the intensity of the color.
Generation of simulated sequencing data For the initial evaluation, involving a limited number of high heteroplasmy level events, six mutant mitochondrial reference genomes were generated, each containing a large deletion or duplication as detailed in Results. These were concatenated such that each would be present at a heteroplasmy of 16. 7% and included in multiple copies together with the nuclear human chromsomes (hg19 assembly) to emulate an mtDNA copy number of 6000. Next we generated simulated reads using InSilicoSeq, a Python software package  [36]. Two different error models were used: the default Illumina Hiseq model (10,000,000 2×126 bp paired-end reads) and an empirical error model base on NextSeq 500 generated whole genome sequencing data (6,000,000 2×76 bp paired-end reads). To evaluate the performance on a larger number of low heteroplasmy events, 6 separate datasets were generated, each containing 200 events as described in Results.
Acknowledgments We thank  Brith Leidvik  for technical assistance. We would also like to acknowledge the  Clinical Genomics Stockholm facility at Science for Life Laboratory  and the  Genomics Core Facility at the Sahlgrenska Academy  for providing assistance in next generation sequencing. We acknowledge the contributions of the many clinical networks across ICGC and TCGA, enabling the analysis of whole genome sequencing data from human tumors in this study.
We present an update on CRDB (https://lpsc. in2p3. fr/crdb), the cosmic-ray database for charged species. CRDB is based on MySQL, queried and sorted by jquery and table-sorter libraries, and displayed via PHP web pages through the AJAX protocol. We review the modifications made on the structure and outputs of the database since the first release  (Maurin et al. , 2014). For this update, the most important feature is the inclusion of ultra-heavy nuclei (Z > 30), ultra-high energy nuclei (from 10 15 to 10 20 eV), and limits on antinuclei fluxes (Z ≤ -1 for A > 1); more than 100 experiments, 350 publications, and 40 000 data points are now available in CRDB. We also revisited and simplified how users can retrieve data and submit new ones. For questions and requests, please contact crdb@lpsc. in2p3.
Introduction Cosmic-Ray (CR) physics has been established more than a century ago and progress in the measurements has been performed through this entire period. Besides preserving the measurements for their historical value, the motivations for a CR database are numerous. Firstly, GeV CRs vary with the Solar cycle, and past data are still of interest-for an illustration of the usage of CR data going back to the 50's, see  Ghelfi et al. [1]. Secondly, it is infeasible to design and build CR experiments that measure all species at all energies, so that multi-species studies over different energy ranges have to rely on many datasets from as many experiments-for an illustration of the usage of data samples of H to Ni elements over 45 years, see Shen et al. [2]. Thirdly, new synergies with other fields of astrophysics make the collection of even the rarest CR data desired.
For instance, ultra-heavy elements (UHCRs, Z > 30) have very small fluxes and are difficult to measure. They require dedicated experiments and so far the data are very sparse (e. g. Donnelly et al. [3]  and  Binns et al. [4] ). UHCRs have not been a very active topic in the last decade, but the situation is likely to change: the first detection of gravitational waves from a binary neutron star inspiral [5]-and in particular optical follow-ups-indicated that neutron star mergers could be a major contributor to r-process nucleosynthesis for UHCRs  [6, 7]. Fourthly, in the last two decades, a growing number of high-precision experiments were developed to measure leptons, antimatter, and Z < 30 nuclei in tens of MeV to hundreds of TeV range (AMS-02, PAMELA, TRACER, etc. ). These balloon-borne or space-based experiments allow us to address many astrophysics questions [e.
g. 8] including searches for dark matter [e. g. 9]. In the context of these searches, upper limits on antinuclei were improved  [10]  and efforts are growing towards the first detection of CR antideuterons  [11]. A few puzzling 40 GeV events compatible with 3 He were reported by the AMS-02 collaboration  [12]. Adding previously reported upper limits on antinuclei (on various energy ranges) in a database is thus also timely. A central motivation for a comprehensive CR database is the energy coverage. CR experiments based on direct detection have recently shown a spectral feature in several species at a few hundreds of GV  [13] [14] [15]. Other spectral features have been observed at higher energies: the knee (at a few PeV), the ankle (around 5 EeV), and the toe (flux suppression above 100 EeV); a fainter second knee around 200 PeV was also observed more recently  [16].
These features were observed with ground-based indirect CR experiments (KASCADE-Grande, Pierre Auger Observatory, Telescope Array, IceCube, TUNKA, and many more), which do not resolve CR species individually. Weak spectral features can be confirmed and enhanced by combining data from multiple experiments. Gathering data that cover the full CR spectrum can help to shed light on the Galactic to extragalactic transition (e. g. Globus et al. [17]  and Thoudam et al. [18] ) and on the possible sources for the most energetic CR events ever observed [e. g. 19]. A central shared database offers multiple advantages for research. It enables studies, which would otherwise be too time-consuming or error-prone, by assuring data quality, completeness, and traceability. In principle, it can also allow for a pooling of human resources (from the CR community) to fill and maintain it.
Electronic resources to gather and disseminate data became available in the 90's, but CR databases appeared much later. For Galactic CR (GCR) data, the momentum was provided by teams involved in the development of GCR propagation codes. The GALPROP 1 team started to distribute CR data as a simple ASCII file  [20]. As part of the development of the USINE 2 propagation code  [21] , our team independently gathered these data and set up the first CR database, called CRDB (Maurin et al. [22] ); our database comes along with a contextualised presentation of the data and experiments, ASCII file exports (compliant to GALPROP and USINE formats), and online plot generation. Shortly after, the Italian Space Agency (ASI) developed a CR database to host originally ASI-supported experimental data  [23].
The design and functionality of the CRDB-ASI 3 was strongly influenced by the CRDB, following discussions between our teams. Since then, the CRDB and CRDB-ASI have been independently developed further. The CRDB-ASI is not as comprehensive as the current version of the CRDB, but it offers specialised datasets (trapped events and Solar Energetic Events) absent in our database. For ultra high-energy CRs (UHECRs, above a PeV), the first initiative to build a common database came from the KCDC project 4  [24]. The primary goal of KCDC is to offer researchers open access to raw data of the KASCADE and KASCADE-Grande experiments. It also contains a collection of high-energy CR flux measurements from more than 20 experiments published between 1984 and 2020 (contrarily to CRDB, an account is required to access KCDC data).
This paper discusses CRDB v4. 0, a major upgrade of the database in terms of its data content, user interfaces, and data submission forms. The paper is organised as follows: Sect. 2 recalls important definitions and the database structure; Sect. 3 highlights the specifics of the data added in this version; Sect. 4 briefly goes over the web interfaces and outputs, focusing on the new and simpler data submission form and the updated REST and Solar modulation time series interfaces. We conclude and discuss possible CRDB extensions in Sect. 5. We gather in App. A useful tips and caveats (on extracted data) for CRDB users, and we provide in App. B sorted lists of all experiments and publications in CRDB v4. 0. The meta-data related to experiments are stored in EXP ( §2. 2. 1) and SUBEXP tables ( §2.
Database structure and updates Throughout the paper, we separate the data in two broad categories, data and meta-data (data about data). Clearly separating these two categories is important to define the format to submit new data (see Sect. 3). The categories comprise the following items: • Data: CR data points, including energy range and data uncertainties; • Meta-data: CR data-related informations that include data taking periods, experiments that provide the data, publication from which the data were taken, etc. The first CRDB publication  [22]  focused on the rationale behind the design choices made for the database structure and organisation (in MySQL). In this update, we follow a complementary approach. We start at the data level, moving up to the experiments and then publications, underlining some salient aspects of the data themselves and how they are tied to the other meta-data tables.
Along the way, we highlight the changes made between CRDB v2. 1  [22]  and CRDB v4. 0. The database structure is shown in Fig. 1. By design, each entry has a unique ID in all tables, so that all tables can be accessed by other tables; this is particularly useful to build bridge tables (i. e. building associations between table entries). The different tables, their contents, and the associations between data and meta-data tables are further detailed in the following subsections.
DATA table A data point corresponds to a quantity measurement (with uncertainties) at a given energy. We list below the keys required for a full data entry description in the DATA table (see Fig. 1 ). The only change made since CRDB v2. 1 is enabling upper limits data (new key IS_UPPER_LIMIT). • ID: unique identifier for a data. • NUM and DEN: a data quantity is a single item (NUM) or a ratio of two items (NUM and DEN). The former usually corresponds to a measured flux (in unit of E -1 unit m -2 s -1 sr -1 , with E unit in GeV, GeV/n, or GV in CRDB) and the latter to a ratio of fluxes (no unit). Depending on the detector charge and isotopic resolution, the measured quantities are isotopes (e. g. 12 C), elements (e. g. C), or even groups of elements; the latter case mostly applies for UHCR and UHECR data (see next sections).
EXP and SUBEXP tables and meta-data CR data are collections of data points at different energies, from an experiment measuring one or several quantities. In CRDB, for flexibility, we make the distinction between an experiment and sub-experiment (hereafter sub-exp for short). The experiment is defined by its name and starting date. The sub-exp is linked to the experiment, but is more closely related to the data in order to uniquely tag the dataset released by this experiment. The tag is here to inform us on (i) analyses from different data taking periods, (ii) data from the same period but from different analysis techniques or different sub-detectors, (iii) data relying on third-party model assumptions (e. g. using different Monte Carlo generators for air showers in UHECRs). Experiment and sub-experiment data are meta-data (attached to CR data) stored in the EXP and SUBEXP tables respectively (see Fig.
EXP table A single change has been made for CRDB v4. 0, related to the experience type (key TYPE, see below). • ID: unique identifier for an experiment. • EXPNAME: unique name associated with the main instrument (AMS-01, KASCADE, etc. ). Most of the data before the 90's come from balloons, and to ensure a unique identifier CRDB uses the syntax: Balloon (YYYY) for a single flight, Balloon (1966,1967,. ) for balloons flown several times, and Balloon (1967+1968+. ) for experiments that report only the combined analysis of several flights. • TYPE: in CRDB v4. 0, we allow for three experiment types (balloon, ground, or space) that represent three broad categories of measurement conditions with different caveats and systematic uncertainties. The experiments in the 'Experiments/Data' tab (see Sect.
SUBEXP table The SUBEXP table contains detailed information on possible sub-detector(s) from which the data were obtained; this includes the data taking conditions and, in some cases, the analysis technique. In CRDB v4. 0, a new key was added to track the energy-scale uncertainty (i. e. a calibration uncertainty on the energy measurement), which is especially important for ground-based experiments ( 10 %). We list all keys in the SUBEXP table (see Fig. 1 ) and then comment on the effect of Solar modulation on multi-GeV GCR data  [27]. In particular, we stress how the last three keys listed below are necessary inputs for Solar modulation calculations. • ID: unique identifier for a sub-experiment • EXP_ID: ID of the experiment in the EXP table to which the sub-exp is attached. (∆E/E) scale , which applies to all energies measured by the sub-experiment 5.