dataesr/scientific-paragraphs-categorization huggingface dataset:
User interfaces for the Serratus databases We implemented an on-going, multi-tiered release policy for code and data generated by this study, as follows. All code, electronic notebooks and raw data is immediately available at https://github. com/ababaian/serratus and on the s3://serratus-public/ bucket, respectively. Upon completion of a project milestone, a structured datarelease is issued containing raw data into our viral data warehouse s3://lovelywater/. For example, the. bam nucleotide alignment files from 3. 84 million SRA runs are stored in s3://lovelywater/bam/X. bam; the protein. summary files are in s3://lovelywater/psummary/X. psummary, where X is a SRA run accession. These FAIR and structured releases enable downstream and third-party programmatic access to the data. Summary files for every searched SRA dataset are parsed into a publicly accessible AWS Relational Database (RDS) instance which can be queried remotely via any PostgreSQL client.
This enables users and programs to perform complex operations such as retrieving summaries and meta-data for all SRA runs matching a given reference sequence with above a given classifier score threshold. For example, one can query for all records containing at least 20 aligned reads to Hepatitis Delta Virus (NC 001653. 2) and the associated host taxonomy for the corresponding SRA datasets: SELECT genbank_id, run_id, tax_id, n_reads FROM nsequence JOIN srarun ON (nsequence. run_id = srarun. run) WHERE n_reads >= 20 For users unfamiliar with SQL we developed Tantalus (https://github. com/serratus-bio/tantalus, an R programming-language package which directly interfaces the Serratus PostgreSQL database to retrieve summary information as data-frames. Tantalus also offers functions to explore and visualise the data.
Finally, the Serratus data can be explored via a graphical web interface by accession, virus, or viral family at https://serratus. io/explorer. Under the hood, we developed a REST API to query the database from the website. The website uses React+D3. js to serve graphical reports with an overview of viral families found in each SRA accession matching a user query. All four data access interfaces are under ongoing development, receiving community feedback via their respective GitHub issue trackers to facilitate the translation of this data collection into an effective viral discovery resource. Documentation for data access methods is available at https://serratus. io/access.
BioSamples with geocoded coordinates were combined with BioSamples with submitted coordinate information to form a set of 5,325,523 geospatial BioSamples. This is then cross-referenced with our subset of SRA accessions with an RdRP match to generate the figure. All intermediate and resulting data from this step is stored on the SQL database described in 1. 3. Development work is public at https://github. com/serratus-bio/biosample-sql.
DIAMOND optimisation and output To optimise DIAMOND for small (< 10 Mb) databases such as the RdRP search database, we built a probabilistic hash set which stores 8-bit hash values for the database seeds, using SIMD instructions for fast probing. This index is loaded as a memory mapped file to be shared among processes and allows us to filter the query reads for seeds contained in the database, thus omitting the full construction of the query seed table. We also eliminated the overhead of building seed distribution histograms that is normally required to allocate memory and construct the query table in a single pass over the data using a deque-like data structure. In addition, query reads were not masked for simple repeats, as the search database is already masked. These features are available starting from DIAMOND v2.
coronaSPAdes RNA viral genome assembly faces several distinct challenges stemming from technical and biological bias in sequencing data. During library preparation, reverse transcription introduces 5 end coverage bias, and GC-content skew and secondary structures lead to unequal PCR amplification  [65]. Technical bias is confounded by biological complexity such as intra-sample sequence variation due to transcript isoforms and/or to presence of multiple strains. To address the assembly challenges specific to RNA viruses, we developed coronaSPAdes, described in detail in a companion manuscript  [26]. In brief, rnaviralSPAdes and the more specialized variant, coronaSPAdes, combines algorithms and methods from several previous approaches based on metaSPAdes  [66] , rnaSPAdes  [67]  and metaviralSPAdes  [68]  with a HMMPathExtension step.
coronaSPAdes constructs an assembly graph from a RNA-sequencing dataset (transcriptome, meta-transcriptome, and meta-virome are supported), removing expected sequencing artifacts such as low-complexity (poly-A / poly-T) tips, edges, single-strand chimeric loops or doublestrand hairpins  [67]  and subspecies-bases variation  [68]. To deal with possible misassemblies and high-covered sequencing artefacts, a secondary HMMPathExtension step is performed to leverage orthogonal information about the expected viral genome. Protein domains are identified on all assembly graphs using a set of viral hidden Markov models (HMMs), and similar to biosyntheticSPAdes  [69] , HMMPathExtension attempts to find paths on the assembly graph which pass through significant HMM matches in order. coronaSPAdes bundled with the Pfam SARS-CoV-2 set of HMMs  [70] , although these may be substituted by the user.
Classification of assembled RdRP sequences Our methods for RdRP classification are described and validated in a companion paper  [19]. Briefly, we defined a barcode sequence, the polymerase palmprint (PP), as a 100 aa segment of the RdRP palm sub-domain delineated by well-conserved catalytic motifs. We implemented an algorithm, Palmscan, to identify palmprint sequences and discriminate RdRPs from reverse transcriptases. The combined set of RdRP palmprints from public databases and our assemblies were classified by clustering into operational taxonomic units (OTUs) at 90%, 75% and 40% identity, giving species-like, genus-like and family-like clusters (sOTUs, gOTUs and fOTUs), respectively. Tentative taxonomy of novel OTUs was assigned by aligning to palmprints of named viruses and taking a consensus of the top hits above the identity threshold for each rank.
Reverse transcriptases (RTs) are homologous to RdRP. Retroviral insertions into host genomes induce ubiquitous sequence similarity between host genomes and viral RdRP. Palmscan was designed to discriminate RdRP from sequences of RT origin. Testing on a large decoy set of non-RdRP sequences with recognisable sequence similarity showed that the Palmscan false discovery rate for RdRP identification is 0. 001. We estimated the probability of false positives matches in unrelated sequence by generating sufficient random nucleotide and amino acid sequences to show that the expected number of false positive palmprint identifications is zero in a dataset of comparable size to our assemblies. We also regard the low observed frequency of palmprints in DNA WGS data (in 2. 6 Pbp or 25. 8% of reads, accounted for 100 known palmprints and 95 novel palmprints or 0.
Annotation of CoV assemblies Accurate annotation of CoV genomes is challenging due to ribosomal frameshifts and polyproteins which are cleaved into maturation proteins  [74] , and thus previously-annotated viral genomes offer a guide to accurate gene-calls and protein functional predictions. However, while many of the viral genomes we were likely to recover would be similar to previously-annotated genomes in Refseq or GenBank, we anticipated that many of the genomes would be taxonomically distant from any available reference. To address these constraints, we developed an annotation pipeline called DARTH  [75]   1  which leverages both reference-based and ab initio annotation approaches. In brief, DARTH consists of the following phases: standardise the ordering and orientation of assembly contigs using conserved domain alignments, perform reference-based annotation of the contigs, annotate RNA secondary structure, ab intio gene-calling, generate files for aiding assembly and annotation diagnostics, and generate a master annotation file.
Phage assembly Each metagenomic dataset was individually de novo-assembled using MEGAHIT  [87] , and filtered to remove contigs smaller than 1 kbp in size. ORFs were then predicted on all contigs using Prodigal v2. 6. 3  [88]  with the following parameters: -m -p meta. Predicted ORFs were initially annotated using USEARCH  [62]  to search all predicted ORFs against UniProt  [89] , UniRef90 and KEGG  [90]. Sequencing coverage of each contig was calculated by mapping raw reads back to assemblies using Bowtie2  [59]. Terminase sequences from Al-Shayeb et al. [45]  were clustered at 90% amino acid identity to reduce redundancy using CD-HIT  [91] , and HMM models were built with hmmbuild (from the HMMER3 suite  [77] ) from the resulting set. Terminases in the assemblies from Serratus were identified using hmmsearch, retaining representatives from contigs greater than 140 kbp in size.
Deploying the assembly and annotation workflow The Serratus search for known or closely related viruses identified 37,131 libraries (14,304 by nucleotide and 23,898 by amino acid) as potentially positive for CoV (score ≥20 and ≥10 reads). To supplement this search we also employed a recently developed index of the SRA called STAT  [17]  with which identified an additional 18,584 SRA datasets not in the defined SRA search space. The STAT BigQuery was WHERE tax id=11118 AND total count >1 accessed on June 24th 2020. We used AWS Batch to launch thousands of assemblies of NCBI accessions simultaneously. The workflow consists of four standard parts: a job queue, a job definition, a compute environment, and finally, the jobs themselves. A CloudFormation template 2  was created for building all parts of the cloud infrastructure from the command line.
The job definition specifies a Docker image, and asks for 8 virtual CPUs (vCPUs, corresponding to threads) and 60 GB of memory per job, corresponding to a reasonable allocation for coronaSPAdes. The compute environment is the most involved component. We set it to run jobs on cost-effective Spot instances (optimal setting) with an additional cost-optimization strategy (SPOT CAPACITY OPTIMIZED setting), and allowing up to 40,000 vCPUs total. In addition, the compute environment specifies a launch template which, on each instance, i) automatically mounts an exclusive 1 TB EBS volume, allowing sufficient disk space for several concurrent assemblies, and ii) downloads the 5. 4 GB CheckV  [95]  database, to avoid bloating the Docker image. The peak AWS usage of our Batch infrastructure was 28,000 vCPUs, performing 3,500 assemblies simultaneously.
A total of 46,861 accessions out of 55,715 were assembled in a single day. They were then analysed by two methods to detect putative CoV contigs. The first method is CheckV  [95] , followed selecting contigs associated to known CoV genomes. The second method is a custom script 3  that parses coronaSPAdes BGC candidates and keeps contigs containing CoV domain(s). For each accession, we kept the set of contigs obtained by the first method (CheckV) if it is non-empty, and otherwise we kept the set of contigs from the second method (BGC). A majority (76%) of the assemblies were discarded for one of the following reasons: i) no CoV contigs were found by either filtering method, ii) reads were too short to be assembled, iii) Batch job or SRA download failed, or iv) coronaSPAdes ran out of memory.
Taxonomy prediction for coronavirus genomes We developed a module, SerraTax, to predict taxonomy for CoV genomes and assemblies (https://github. com/ababaian/serratus/tree/master/containers/serratax). SerraTax was designed with the following requirements in mind: provide taxonomy predictions for fragmented and partial assemblies in addition to complete genomes; report best-estimate predictions balancing over-classification and under-classification (too many and too few ranks, respectively); and assign an NCBI Taxonomy Database  [96]  identifier (TaxID). Assigning a best-fit TaxID was not supported by any previously published taxonomy prediction software to the best of our knowledge; this requires assignment to intermediate ranks such as sub-genus and ranks below species (commonly called strains, but these ranks are not named in the Taxonomy database), and to unclassified taxa, e.
g. TaxID 2724161, unclassified Buldecovirus, in cases where the genome is predicted to fall inside a named clade but outside all named taxa within that clade. SerraTax uses a reference database containing domain sequences with TaxIDs. This database was constructed as follows. Records annotated as CoV were downloaded from UniProt  [89] , and chain sequences were extracted. Each chain name, e. g. Helicase, was considered to be a separate domain. Chains were aligned to all complete coronavirus genomes in GenBank using UBLAST  [62]  to expand the repertoire of domain sequences. The reference sequences were clustered using UCLUST  [62]  at 97% sequence identity to reduce redundancy. For a given query genome, open reading frames (ORFs) are extracted using the EMBOSS getorf software  [76]. ORFs are aligned to the domain references and the top 16 reference sequences for each domain are combined with the best-matching query ORF.
Phylogenetic inference We performed phylogenetic inferences using a custom snakemake pipeline (available at https://github. com/ lczech/nidhoggr), using ParGenes [101], v1. 1. 2. ParGenes is a treesearch orchestrator, built on top of ModelTest-NG  [102]  and RAxML-NG, enabling higher levels of parallelisation for a given tree search. To infer the maximum likelihood phylogenetic trees , we performed a tree search comprising 100 distinct starting trees (50 random, 50 parsimony), as well as 1000 bootstrap searches. We used ModelTestNG to automatically select the best evolutionary model for any given treesearch. The pipeline also automatically produces versions of the best maximum likelihood tree annotated with Felsenstein's Bootstrap (  [103] ) support values, and Transfer Bootstrap Expectation (  [104] ) values.
Extended Table  1 : SRA run queries and CoV assembly table Queries and accessions from this study. a SRA queries to retrieve collections of datasets. b Run accessions, assembly statistics and select meta-data for the 11,120 runs for which Coronaviridae, or Coronaviridae-like sequences were assembled. c Assignment of assembled runs to operational taxonomic units (OTUs) based on 97% identity of the RNA dependent RNA polymerase (RdRp) domain. d Assignment of GenBank records to RdRp OTUs. e Assignment of expected viral host for GenBank records based on Sequence Read Archive and JGI GOLD metadata  [2, 31]. f Taxonomic source for RdRp containing assemblies. }.
Extended Tables 2 Extended Figures Extended Figure  1  Extended Figure  5 : Newly characterised Deltavirus and Deltavirus-like genomes (cont'd) Structure and organisation of selected examples from the 14 delta virus-, 39 epsilon virus-and 311 zeta virus-like genomes identified in our study. a Similar to human deltavirus (HDV), delta virus-like genomes from vertebrates (PmacDV SRR7910143; MmonDV SRR2136906; TgutDV SRR5001850; IchiDV SRR8954566 and BglaDV SRR8242383) and environmental datasets (SRR7286070 and SRR6943136) share similar predicted stable rod-like folding, a predicted ORF coding for the delta antigen (δAg) and a delta ribozyme (dvrbz) on each polarity. Folding of the circular DNA virus Porcine Circovirus 2 (PCV2) and a shuffled MmonDV sequence are shown as negative controls. b Epsilon virus-like genomes detected in invertebrates (SulaEV SRR8739608; GsulEV SRR7170939 and BaerEV SRR12300397) and environmental datasets (SRR8840728 and SRR6943136) show similar structure and organization to deltaviruses, with one or two predicted ORFs (epsilon antigen or Ag) and two hammerhead ribozymes (hhrbz) in equivalent genomic regions.
c Zeta virus-like genomes detected in invertebrate (Ocassitermes sp. ZVs SRR8924823) and environmental datasets (SRR7286070, SRR6943136, SRR8840728, SRR6201737, SRR5864109 and SRR12063536) are smaller than delta and epsilon agents. Up to 90% of the zeta genomes have sizes multiple of 3 and predicted ORFs without stop codons, capable to encode endless tandem-repeated zeta antigens in both polarities (ζAg+ and ζAg-shown as yellow and red arrows, respectively). Both genomic zeta polarities keep hhrbzs (shown as arrows overlapping the ORFs) similar to the epsilon ribozymes (Extended  Fig 6). Larger zeta virus-like genomes (>651 nt) were less abundant (7% of all zeta genomes) and frequently show stop codons, or their sizes are not multiple of 3. Extended Figure  6 : Evolutionary history of deltavirus-like agents (cont'd) a Consensus structures (weighted nucleotide conservation threshold of 90%) of deltavirus ribozymes, including the 14 genomes described in this work.
Acknowledgments The  Serratus  project is an initiative of the hackseqRNA genomics hackathon (https://www. hackseq. com). We would like to thank the many contributors for code snippets and bioinformatic discussion;  E. Erhan ,  J. Chu ,  S. Jackman ,  I. Birol ,  K. Wellman ,  O. Fornes ,  C. Xu ,  M. Huss ,  K. Ha ,  M. Krzywinski ,  E. Nawrocki ,  R. McLaughlin ,  C. Morgan-Lang ,  C. Blumberg , and the  J. Brister lab. A. Rodrigues ,  S. McMillan ,  V. Wu ,  C. Kennett ,  K. Chao , and  N. Pereyaslavsky  for AWS support. We would also like to thank the  J. Joy lab ,  G. Mordecai ,  J. Taylor ,  S. Roux ,  N. Kyrpides ,  T. Reddy ,  L. Bergner ,  R. Orton , and  D. Streicker  for virology discussions. We are grateful to the entire team managing the  NCBI SRA. TA is grateful for the Advanced Research Computing resource at the  University of British Columbia.
PB was financially supported by the  Klaus Tschira Foundation ,  RC  by  ANR Transipedia, Inception  and  PRAIRIE grants  ( PIA/ANR-16-CONV-0005 ,  ANR-18-CE45-0020 ,  ANR-19-P3IA-0001 ),  MdlP by Ministerio de Economía y Competitividad of Spain and FEDER  grant ( BFU2017-87370-P ), AK and DM were supported by the  Russian Science Foundation  (grant  19-14-00172 ) and computation was carried out in part by  Resource Centre "Computer Centre of SPbU ". AK and DM are grateful to  Saint Petersburg State University  for the overall support of this work. Project support and computing resources were kindly provided by the  University of British Columbia Community Health and Wellbeing Cloud Innovation Centre , powered by  AWS. Special thanks to our patient and understanding partners.
Scribe is a legal judgment annotation platform. Its objective is to improve dataset quality for machine learning models, to make annotation task faster and easier, and to boost interactions between annotators and developers. The platform manages 3 different classes of annotation: claims, named entities and sections. The platform facilitates the expression of annotation needs by developers. Multiple annotators can quickly respond to these needs by working in parallel. The collaborative process ends when the expected model performance is reached. The platform is organized by modules, maintainable and extensible in addition to its flexibility and unified output result in JSON format. See our demo https://lawbot. unimes. fr/annotateur.
Overview of the platform Scribe consists of a web application, secured by a user authentication system  [1]. The main purpose of the platform is to facilitate French court decisions datasets annotation process, and communicate rapidly between legal experts and NLP developers. System specifications. The Scribe prototype has been designed to get simple interfaces adapted to French legal judgments annotation tasks. It enables links creation between datasets and annotations in such way that developers can check annotation states and query the database easily. On the other hand, annotators can search for particular court decisions, annotate decisions (alone or with other experts independently on the same set of decisions), save and edit annotations. The first step of the Scribe pipeline is composed of three tasks: claim categories, named entity recognition (NER), and sectioning the decision (header, facts, etc.
). Figure  1  highlights Scribe use cases. Two actors can interact with Scribe: Annotators (legal experts) and Developers. Both of them need admin authorization to access the platform. For each task (claims categories, NER, and sectioning), annotators should be able to create, delete or update items (rows) such as type of jurisdiction and chamber for entities tables (see Figure  1 ); and attributes (columns) like category name or description. Annotators can associate a resizable dataset (can add and remove decisions as they want) to a specific task row (such as type of jurisdiction in NER task) by searching specific court decisions from the database with a dynamic number of keywords either required or excluded, wanted dataset size, and the legal judgment deliver (either Cassation, Appeal and/or First instance court).
They can display the content of the decisions resulting from the search, one by one, and then select (deselect) the decisions to include (exclude). Once the decisions choice is complete, they can append them to the selected task row as the associated dataset. If the task row is already associated with a dataset, then the selected decisions are added to the existing one. Annotators can autonomously annotate created datasets and multiple annotators may annotate the same dataset and update annotations. They can display dataset decisions one by one in the interface annotation, delete unwanted ones, and select text spans corresponding to the correct annotation from the decision text. Once finished, they can save it, and move to another one. Developers may check the progress state of the annotation process continuously and can download datasets at any moment in standardized format on the homepage for easy access).
The creation of a new row in a given task is a dataset query, for instance creating the row "claims of non-recoverable charges, the article 700" in the table claims categories. After that, either developers or annotators can associate a dataset (decisions list) to this row (search by keywords and by standard jurisdiction). Once done, annotators can save annotations of this dataset, and the developer can simultaneously follow the annotation progress and download the dataset. The database component is responsible for saving data (raw decisions, annotations, tasks classes and users) and for the database exploration with a search engine used when composing datasets. MongoDB is a Data Base Management System DBMS which is a NoSQL database that allows the structure of the document to be modified  [2] , and to handle big data.
Modules. Scribe is composed of four main components, as shown in The annotation component contains three sub-components, each one dedicated to its specific task (discussed in Section 2) and contains its suitable form. For example, in the NER form, the user selects an entity from the decision text body then all occurrences are automatically selected. In the sectioning form, the user has just to select a decision part that represents the section. As a decision can include multiple claims of the same category, the form of this task allows the annotator to create dynamic similar forms. The three sub-components consume dataset raw decisions (obtained from the search step in the database component) and provide their annotations (also stored in the database). Django is used to implement the backend logic and Reactjs for the frontend.