dataesr/scientific-paragraphs-categorization huggingface dataset:
Preprocessing of eCLIP data with htseq-clip We have developed a custom python package called htseq-clip  25  to count and extract crosslink sites from sequencing alignment files. htseq-clip is designed to preprocess alignment files from CLIP experiments and to generate a count matrix of crosslink sites that can be used in further downstream analysis. The required inputs for htseq-clip are: gene annotation in GFF format and alignment files (. bam format, coordinate sorted and indexed). for multiple samples from the same experiment are summarised into a crosslink site count matrix file, which will be used as input for further downstream analysis. In this study, we used windows of size 50, 75 and 100 base pairs and slides of size 5 and 20 base pairs. The IP and SMI samples in each study were processed and concatenated into a crosslink site count matrix and was used as input for downstream analysis using DEWSeq.
Calling differentially enriched regions for eCLIP data with DEWSeq We developed the R/Bioconductor package DEWSeq to analyse the crosslink site count matrix from htseq-clip and to test for differential enrichment in IP samples in comparison with SMI samples. For statistical testing, DEWSeq utilises DESeq2  26  , a well-established R/Bioconductor package primarily used for the analysis of differentially expressed genes in RNA-seq data. After DESeq2 initial pruning, normalisation and dispersion estimation, DEWSeq uses a custom one-tailed test for detecting significant crosslink regions enriched in IP samples over SMI, followed by two multiple hypothesis correction steps. In the first step, dependencies between overlapping windows are corrected using Bonferroni correction, as the adjacent sliding windows share crosslink site count information.
In the second step, all windows are corrected for False Discovery Rates (FDR) at the genome level using either Benjamini-Hochberg (BH) method or independent hypothesis weighting (IHW)  44. Finally, all enriched windows passing user specified enrichment thresholds are merged into regions. DEWSeq is available as an open-source R/Bioconductor package (https://bioconductor. org/packages/release/bioc/vignettes/DEWSeq/inst/doc/DEWSeq. html). A sample pipeline for the analysis of eCLIP/iCLIP data using htseq-clip and DEWSeq is available  45. In this study, test for the impact of DESeq2 and DEWSeq parameters on the final results, we ran DEWSeq with the following set of parameters on all ENCODE studies: 1. Dispersion estimation: Using DESeq2 default "parametric" dispersion estimation  26  or a custom function to decide the best fit (either "parametric" or "local" from DESeq2).
Reference set of known RBP motifs In this analysis, we used the presence of an RNA sequence motif in a binding region as a proxy for the biological relevance of the binding region. We used motifs from the catRAPID omics v2. 0 RBP motifs database, whose authors collected and curated motifs from a comprehensive set of sources including ATtRACT, cisBP-RNA, mCrossBase, oRNAment and RBPmap 29. Supplementary Table. 5, Sheet 2 shows the total number of RBPs per motif length in the data source and the number of RBPs in common with the ENCODE dataset. We post-processed this set of motifs by removing any peripheral positions with information content ≤ 0. 1 and rounding down base probabilities ≤ 0. 025 using the R/Bioconductor package universalmotif  46. We then selected motifs with length ≥ 6 nt to reduce the probability of random occurrences.
Discovery and comparison of known motifs sites We predicted the positions of human RNA-binding protein motifs within eCLIP binding regions using version 5. 4. 0 of FIMO  30  from the MEME Suite 47 and the comprehensive benchmark set of RBP motifs described above. For CLIPper, eCLIP binding regions were extended 50 nt upstream of their 5' end, as previously described  14, 41. Enriched regions from DEWSeq were analysed without any extension. We used a near-equiprobable background sequence model calculated across GENCODE 27 transcripts using fasta-get-markov (-norc) from the MEME Suite. We filtered FIMO results using a p-value cutoff ≤ 0. 001. We consciously avoided the use of q-values to filter the results due to the variation in the number of binding sites between different RBPs, which would penalise experiments that succeeded at identifying a larger number of binding sites, and reasoned that p-values would offer more comparable results across experiments.
Comparison to orthogonal datasets We retrieved iCLIP  15  , HITS-CLIP  7  , and PAR-CLIP 8 interaction datasets from the POSTAR2 database (previously known as CLIPdb)  51. For each CLIP experiment type, POSTAR2 provided peak calling results from Piranha  38  , as well as the more specialised CIMS (crosslink-induced mutation sites)  39  and PARalyzer data analysis pipelines  40. We used POSTAR2's standard thresholds such as: p-value < 0. 01 for Piranha, score < 0. 01 for CIMS, and score > 0. 5 for PARalyzer. Additionally, we also obtained a cohesive PAR-CLIP dataset from the DoRiNA database  32  , and used a minimum conversion specificity score of 5 to filter binding regions, which resulted in a similar number of regions as for CLIPper Rep. We performed motif calling on these enriched regions using the reference motif set and methodology described above and compared the fraction of unique motifs present in these results to that of DEWSeq and CLIPper Rep.
Comparing gene region and gene type enrichment using OLOGRAM To determine whether DEWSeq or CLIPper results were biassed towards gene regions (5' UTR, exon, 3' UTR) or gene types (e. g. protein coding RNAs, non coding RNA, mtRNA,. ) we performed gene region and gene type enrichment analysis in both results using OLOGRAM  52. To avoid ambiguities in gene region annotation in genes with multiple transcripts, we selected the transcript with the highest abundance in each gene as the representative transcript. For this purpose we used rRNA-depleted total RNA-seq data from HepG2 (ENCODE accession: ENCFF533XPJ, ENCFF321JIT) and K562 (ENCODE accession: ENCFF286GLL, ENCFF986DBN) cell lines available from ENCODE consortium. After removing lowly expressed transcripts with a TPM value ≤ 1, the datasets were merged and for each gene, the transcript with the highest abundance was selected as the representative transcript.
results and DEWSeq results. (b) comparison of POSTAR2 HITS-CLIP binding regions from Piranha and CIMS pipelines with CLIPper Rep. results and DEWSeq results. (c) comparison of PAR-CLIP binding regions from Piranha, PARalyzer and Mukherjee 32 pipelines with eCLIP CLIPper Rep. results and DEWSeq results. (d) Violin plots showing the absolute number of motif-containing regions in common either between iCLIP, HITS-CLIP, PAR-CLIP datasets analysed with CIMS, Piranha, PARalyzer or Mukherjee and ENCODE eCLIP data analysed with CLIPper Rep. and DEWSeq, respectively.
Rare disease patients are more likely to receive a rapid molecular diagnosis nowadays thanks to the wide adoption of next-generation sequencing. However, many cases remain undiagnosed even after exome or genome analysis, because the methods used missed the molecular cause in a known gene, or a novel causative gene could not be identified and/or confirmed. To address these challenges, the RD-Connect Genome-Phenome Analysis Platform (GPAP) facilitates the collation, discovery, sharing, and analysis of standardized genome-phenome data within a collaborative environment. Authorized clinicians and researchers submit pseudonymised phenotypic profiles encoded using the Human Phenotype Ontology, and raw genomic data which is processed through a standardized pipeline. After an optional embargo period, the data are shared with other platform users, with the objective that similar cases in the system and queries from peers may help diagnose the case.
, 2017). There are a variety of bottlenecks that impede rapid resolution of RD cases through the application of next generation sequencing. One is the collection of the data itself, which is time consuming and requires the work of many skilled individuals, from the medical practitioners who examine the patient, record their phenotype and extract samples, to the specialized laboratory staff who perform DNA sequencing, and the bioinformaticians who process the data to identify variants, supported by high performance computing infrastructures. The ensuing challenge is to identify the one or two disease-causing variants out of the millions found in each human genome. This requires the blending of information from many different data sources to aid variant interpretation, ideally using user-friendly systems that can efficiently help clinical researchers achieve this goal.
, 2016). However, the sharing of RD patient data faces a number of barriers as outlined in Box 1. In recent years, there has been much effort within the RD community towards overcoming these barriers, in particular with respect to the standardization of methodology and terminology for recording phenotypic descriptions, and the responsible processing and sharing of genomic data. These ongoing efforts include initiatives such as the human phenotype ontology (HPO,  Köhler et al. , 2021) , the orphanet rare disease ontology  (ORDO, Nguengang Wakap et al. , 2020) , ClinVar  (Landrum et al. , 2020) , the American College of Medical Genetics (ACMG) standards for variant interpretation  (Richards et al. , 2015) , Matchmaker Exchange  (MME, Philippakis et al. , 2015; Boycott et al. , 2022) , Genomics England PanelApp  (Martin et al.
, 2019) , and work along many different lines within the Global Alliance for Genomics and Health (GA4GH). All these efforts, and many others, will hopefully enable "all people living with a RD to receive an accurate diagnosis, care, and available therapy within one year of coming to medical attention," which is the ambitious vision of the International Rare Disease Research Consortium (IRDiRC) for 2027  (Austin et al. , 2018). The primary goal of the European Union FP7 funded RD-Connect project was to accelerate RD research by connecting databases, patient registries, biobanks, and clinical bioinformatics data through an intuitive user-friendly platform to simplify the analysis of RD cases within a collaborative framework  (Lochmüller et al. , 2018; Thompson et al. , 2014). One of the key assets developed in this project to overcome many of the barriers highlighted in Box 1 was the RD-Connect Genome-Phenome Analysis Platform (RD-Connect GPAP), which is now an IRDiRC recognized resource  (Lochmüller et al.
europa. eu/project/id/951724), the Beyond One Million Genomes project (B1MG, https://cordis. europa. eu/ project/id/951724), ELIXIR (https://elixir-europe. org/), Matchmaker Exchange (MME), and the Global Alliance for Genomics and Health (GA4GH). Here, we describe in detail the RD-Connect GPAP, a scalable and interoperable online system which facilitates the collation, analysis, interpretation, and sharing of integrated genome-phenome datasets, with a particular focus on RD case diagnosis and novel gene discovery. We provide an overview of the different modules that comprise the RD-Connect GPAP, and detail how it facilitates filtering and prioritization of variants based upon both the phenotypic information provided and the incorporation of a wide variety of openly accessible annotations and tools.
Further, we describe how case data can be shared in a controlled manner to support internal and external patient matchmaking, and how case resolution is recorded within the platform, in line with the ACMG guidelines. Finally, we highlight how the RD-Connect GPAP has been BOX 1 Barriers to sharing Rare Disease data RD data often remains effectively siloed, thus impeding research and diagnoses, for a number of reasons, which may differ for different groups of stakeholders (e. g. , funders, clinicians, researchers, industry, etc. ). 3) Technical A. Data may not be discoverable and/or accessible. Relevant data is often stored across different servers/databases which are not freely accessible outwith the institution to which they belong. B. Processes to request access to data may not be clear, or too cumbersome.
4) Ethical and Legal A. Data may not be reusable for example, if there is not an appropriate legal basis for processing in place, such as informed consent, permitting such usage. B. Patient data is inherently private, and thus sharing must be limited, and in line with national and international legal restrictions for example, the European General Data Protection Regulation (GDPR), to prevent undesired re-identification. successfully used in a number of European projects resulting in the diagnosis of hundreds of RD cases.
| User registration and data submission Access to the RD-Connect GPAP is free to all noncommercial members of the RD research community. To become an authorized user of the RD-Connect GPAP, Principal Investigators, or equivalent, must indicate why they wish to access the platform, and sign the RD-Connect Adherence Agreement and Code of Conduct (available via https://rd-connect. eu/forms-and-guides/). Applications are then forwarded to the RD-Connect GPAP Data Access Committee which consists of four leaders in the field of RDs. Upon approval, the Principal Investigator may then request access credentials for other members of their group, each of whom must also agree to the Code of Conduct. Additionally, researchers from countries outside the EU may have to sign a Data Transfer Agreement and a Data Access Agreement.
The whole process is largely based on ethics research conducted within the RD-Connect project  (Mascalzoni et al. , 2016). Data submission is undertaken in three steps. First, the user creates a phenotypic record in the bespoke application PhenoStore, describing the case and any family members for which genomic data is available. In the second step, the submitter must provide a small amount of essential metadata to allow data processing to be undertaken correctly. This metadata describes the type of experiment performed for example, genomic library preparation and sequencing strategy, and to which participant the data belongs. These first two steps can either be performed directly within a userfriendly graphical user interface or via bulk upload using MS Excel templates. In the final step, high-speed transfer of the raw sequencing data, in standard formats (FASTQ, BAM, or CRAM) is facilitated via use of an Aspera server, provided by the Spanish academic and research network RedIris (https://www.
rediris. es/). Furthermore, the RD-Connect GPAP team can broker, upon agreement, the transfer of raw and processed data to the European Genome-Phenome Archive (EGA,  Lappalainen et al. , 2015)  to make them available to the broader research community. Upon request, data submitted to the RD-Connect GPAP may be placed under embargo for up to 6 months, during which time only members of the submitting group have access to the data. Following expiry of the embargo period, the genomic data and limited phenotypic data become visible to all platform users.
, 2020) , and read depth calculated across the target region of interest to provide a measure of data quality for each individual experiment. Before any changes to the core pipeline being implemented, the output of the updated pipeline is benchmarked for validation against the genome sequencing data for the NA12878 sample from NIST/GIAB following the guidelines of  Krusche et al. (2019) , before full reanalysis starting with the raw data of all experiments in RD-Connect using the new pipeline, to maintain internal consistency. All detected variants which are covered by both a minimum of eight sequencing reads and having a genotype quality determined by GATK of at least 20 are uploaded to the GPAP. Nevertheless, the default filter recommendations are set to a minimum coverage of 10 reads and a genotype quality of 30 as our benchmarking has shown that the proportion of false-positive calls below a read depth of 10 increased rapidly.
Furthermore, it is in the user's hands to determine the fraction of reads that should support a heterozygote or homozygote alternative variant call, with defaults of 0. 2-0. 8 for a heterozygote, and >0. 95 for a homozygote. The internal allele frequency for all variant positions in RD-Connect is also calculated and this can be applied as a filter in the same way as the variant frequencies from gnomAD and the 1000 genomes project. This internal allele frequency is also shown in the results view allowing easy identification and removal of any common alignment and variant calling artifacts from the results. Finally, coverage metrics, for example mean/median depth of coverage, and proportion of target region of interest covered by 10 or 20 reads etc. for each experiment are available in the Data Management module, thus providing users with a measure of the overall quality of the data for the experiments undergoing analysis.
| RD-Connect GPAP architecture The RD-Connect GPAP variant storage and processing system have been built on fully scalable technologies. gVCF files output by the analysis pipeline are stored on a Hadoop File System (https://hadoop. apache. org/docs/r1. 2. 1/hdfs_user_guide. html) and the extract, transform and load process is leveraged by Apache Spark (https://spark. apache. org/) and Hail (https://hail. is/). The output of this process is loaded into an Elasticsearch cluster (https://www. elastic. co/ elasticsearch/) which offers low-latency response time to user queries. The core functionalities of the platform are provided by three distinct modules: Data Management, PhenoStore, and Data Analysis, each of which consists of a server and client, all being connected to the same Identity Provider (Keycloak, https://www.
keycloak. org/). The PhenoStore server is implemented in Python/ Flask (https://flask. palletsprojects. com/), the Data Analysis server in Scala/Play2 (https://www. playframework. com/), and the Data Management module written in Python/Django (https://www. djangoproject. com/). The clients are all single-page application implementations written in JavaScript and React (https://reactjs. org/). In addition to these core modules, other microservice modules have been developed such as the MME and Beacon V1  (Fiume et al. , 2019)  servers. The RD-Connect GPAP is hosted by the data centre of the Centro Nacional de Análisis Genómico (CNAG-CRG, Barcelona, Spain). For security purposes, the Unix cluster nodes are not connected to the internet and only communicate to the outside world via a controlled proxy server.
| Data standards To enable interoperability and to overcome language barriers, the RD-Connect GPAP has been designed to use widely adopted and machine readable international and community standards and ontologies whenever possible. Within the PhenoStore module, patient descriptions are recorded using HPO, ORPHA, and OMIM  (Amberger et al. , 2015)  terminology. Phenotypic records can be exported to the GA4GH approved Phenopackets file format (https:// github. com/phenopackets/phenopacket-schema), and family trees in PLINK PED format  (Purcell et al. , 2007). Genomic alignments and variants are stored and transferred (e. g. to the EGA) in GA4GH approved BAM/CRAM, and gVCF/VCF formats, respectively.
| RD-Connect GPAP implementation From the user's perspective the RD-Connect GPAP consists of 3 core modules (Figure  1 ): (1) The Data Management module, which facilitates the upload of raw sequencing data, together with associated metadata required for processing. (2) PhenoStore, an application for the storage and sharing of phenotypic descriptions of all participants (affected individuals and relatives), which uses machine readable ontologies and vocabularies such as HPO, ORDO, and OMIM. (3) The Genomic Analysis module, where researchers/clinicians analyze their own cases, and can discover and access data from cases shared by other researchers, to identify disease-causing variants.
| Data management The Data Management module facilitates the upload of sequencing data and metadata and allows users to keep track of all data they have submitted. With this module, they can easily check for how many participants they have entered data into the system, which types of experiments are linked to these participants, which associated files were uploaded, and to which projects they pertain (Supp. Figure  S1 ). They can also track the progress of their submission, data processing, and analysis status. Further, submitters can see which RD-Connect GPAP users have made queries specifically on their genomic datasets.
| PhenoStore A requirement for collaboration in the RD-Connect GPAP is that all submitted genomic data be accompanied by a corresponding pseudonymised phenotypic description of the individual from whom the sample was taken, which is recorded within the PhenoStore module developed primarily within the EJP-RD. A deep phenotypic record for affected individuals can be generated using HPO terms, which describe observed patient signs and symptoms and, when informative, the absence of certain traits. HPO is a machine-readable standardized vocabulary which aids in breaking language barriers, since each of the terms consists of a unique code linked to a description and additional information (e. g. , synonyms, comments) which have been translated into several languages. HPO is continuously being updated, and new terms are added as necessary, and one of the successful mechanisms to update HPO, and broaden its usage, were workshops organized with disease experts from RD-connect and Solve-RD, among others  (Kohler et al.
, 2021). Where the RD diagnosis is known at the time of submission, or upon case resolution, an ORPHA and/or OMIM identifier can be added to the record, together with a description of the causative variant(s). Each individual record is assigned to a specific family within the system, and a user-friendly pedigree-drawing tool facilitates the linking and addition of family members. For projects focussing on a particular class of RD, customized templates are available in PhenoStore to accelerate data collation. In collaboration with Orphanet and members from several European Reference Networks (https://ec. europa. eu/health/ern_en), 20 templates based on the Genomics England RD data model (https://www. genomicsengland. co. uk/?wpdmdl=5500) have been implemented.
These templates, which include diseases from all 24 European Reference Networks, promote data standardization and harmonization, by indicating which fields and HPO terms are most likely to be relevant for the appropriate RD class, though all HPOs remain available for selection. The templates may also include measurements that are not currently defined within the HPO, for example, the number of observed polyps in the case of tumor risk syndromes, or measurements of key molecular biomarkers. Together these provide a deep and meaningful description of the case which is easily understood by both human and machine alike. The latter is invaluable because it means that the phenotypic description can be directly applied by the user when undertaking variant prioritization within the Genomic Analysis module via the generation of real-time in silico candidate gene panels through the integration of information from sources such as HPO, OMIM, DisGeNET  (Piñero et al.
, 2020) , and Exomiser  (Smedley et al. , 2015). Similarly, machine-readable phenotypic descriptions are essential for patient matchmaking both within the RD-Connect GPAP and worldwide via the MME network. Furthermore, data stored in PhenoStore can be exported to Phenopackets, a GA4GH open file standard for interoperability, transfer, and sharing of disease and phenotypic information. The RD-Connect GPAP was one of the first testers and early adopters of Phenopackets, which are now extensively used within the Solve-RD project as part of its data sharing and analysis strategy (manuscript in preparation).