dataesr/scientific-paragraphs-categorization huggingface dataset:
ACKNOWLEDGMENTS. We thank  Joshua L. Dickerson  for calculation of photoelectron path lengths and  Robert Thorne  for critical comments on the submitted version of the manuscript. The study was carried out in September 2016 at ID13 of the  ESRF  (Proposal  LS2586 ), and we warmly thank the  ESRF  staff for beamtime assistance. The study was supported by  Agence Nationale de la Recherche (ANR)  grants to M. W. (BioXFEL) and J. -P. C. (Grants  ANR-15-CE18-0005-02  and  ANR-17-CE11-0018-01 ); a grant from the  France-Alzheimer Foundation  to J. -P. C. (Grant  FA-AAP-2013-65-101349 ); support from the  US Department of Energy, Office of Science, Office of Basic Energy Sciences  to I. C. (Award  DE-FC02-04ER15533 ); and a CCP4 grant to E. F. G. (funding for C. S. B. ). Institut de Biologie Structurale acknowledges integration into the Interdisciplinary Research Institute of Grenoble (Commissariat à l'Énergie Atomique et aux Énergies Alternatives [CEA])  and financial support by  CEA ,  CNRS , and  Université Grenoble Alpes.
Pitfalls and Technical Challenges Sequencing sensitivity and Normalization. With each new protocol comes a host of new technical problems to overcome. The rst wave of software utilities to deal with the analysis of single cell datasets were statistical packages, aimed at tackling the issue of "dropout events" during sequencing, which would manifest as a high prevalence of zero-entries in over 80% of the featurecount matrix. These zeroes were problematic, since they could not be trivially ignored as their presence stated that either the cell did not produce any molecules for that transcript, or that the sequencer simply did not detect them. Normalisation techniques originally developed for bulk RNA-seq had to be adapted to accommodate for this uncertainty, and new ones were created that harnessed hurdle models, data imputation via manifold learning techniques, or by pooling subsets of cells together and building general linear models  [4].
The Burgeoning Software Ecosystem Since its conception, several di erent packages and many pipelines have been developed to assist researchers in the analysis of scRNA-seq  [5, 6]. The vast majority of these packages were written for the R programming language since many of the novel normalisation methods developed to handle the dropout events depended on statistical packages that were primarily R-based  [7]. Standalone analysis suites emerged as the di erent authors of these packages rapidly expanded their methods to encapsulate all facets of the single-cell analysis, often creating compatibility issues with previous package versions. The Bioconductor repository provided some muchneeded stability in this regard by hosting stable releases, but researchers were still prone to building directly from repository sources in order to reap the bene ts of new features in the upstream versions  [8, 9].
As a result of this analysis diversity, there are many tutorials on how to perform scRNA-seq analysis each oriented around one of these pipelines  [13]. Error propagation and Analysis Uncertainty. Di erent pipelines produce di erent results, where the stochastic nature of the analyses means that any uncertainty in a crucial quality control step upstream, such as ltering or the removal of unwanted variability, can propagate forward into the downstream sections to yield wildly di erent results on the same data. This uncertainty, and the statistically-driven methods to overcome Compiled on: August 28, 2020. Draft manuscript prepared by the author. them, leaves a wide knowledge gap for researchers simply trying to understand the underlying dynamics of cell identity.
Rise of 10x Genomics 10x Launch. In 2015, 10x Genomics released their GemCode product, which was a droplet-seq based protocol capable of sequencing tens of thousands of cells with an average cell quality higher than other facilities  [14]. This unprecedented level of throughput steadily gained traction amongst researchers and startups seeking to perform single-cell analysis, and thus 10x datasets began to prevail in the eld. 10x Analysis Software. 10x Genomics provided software that was able to perform much of the pre-processing, and provided feature-count matrices in a transparent HDF5-based format which provided a means of e cient matrix storage and exchange, and conclusively removed the restriction for downstream analysis modules to be written in R. ScanPy, a popular alternative. The ScanPy suite  [15] , written in Python, using its own HDF5-based AnnData format became a valid alternative for analysing 10x datasets.
Solutions in the Cloud Accessible Science. As the size of datasets scaled, so did the computing resources required to analyse them, both in terms of the processing power and in storage. Galaxy is an opensource biocomputing infrastructure that exempli es the three main tenets of science: reproducibility, peer review, and openaccess -all freely accessible within the web-browser  [16]. It hosts a wide range of highly-cited bioinformatics tools with many di erent versions, and enables users to freely create their own work ows via a seamless drag-and-drop interface. Reproducible Work ows. Galaxy can make use of Conda or Containers to setup tool environments in order to ensure that the bioinformatics tools will always be able to run, even when the library dependencies for a tool have changed, by building tools under locked version dependencies and bundling them together in a self-contained environment  [17].
These environments provide a concise solution for the package version instability that plagues scRNA-seq analysis notebooks, both in terms of reproducibility and analysis exibility. A user could keep the quality control results obtained from an older version of ScanPy, whilst running a newer ScanPy version at the clustering stage to reap the bene ts of the later improvements in that algorithm. By allowing the user to select from multiple versions of the same tool, and by further permitting di erent versions of the tools within a work ow, Galaxy enables an unprecedented level of free-ow analysis by letting researchers pick and choose the best aspects of a tool without worrying about the underlying software libraries  [18]. The burden of software incompatibility and choice of programming language that plagued the scRNAseq analysis ecosystem before, are now completely alleviated from the user.
User-driven Custom Work ows. Analyses are not limited to one pipeline either, as the datasets which are passed between tools can easily be interpreted by a di erent tool that is capable of reading that dataset. In the case of scRNA-seq, Galaxy can convert between CSV, MTX, LOOM and AnnData formats. This interexchange of modules from di erent tools further extends the exibility of the analysis by again letting the user decide which component of a tool would be best suited for a speci c part of an analysis. Training Resources. Galaxy also provides a wide range of learning resources, with the aim of guiding users step-by-step through an analysis, often reproducing the results of published works. The teaching and training materials are part of the Galaxy Training Network (GTN), which is a worldwide collaborative e ort to produce high-quality teaching material in order to educate users in how to analyse their data, and in turn to train others of the same materials via easily deployable workshops backed by monthly stable releases of the GTN materials  [19].
Pre-processing Work ows The pre-processing scRNA-seq materials tackle the two most common use-cases that researchers will encounter when they rst begin the eld: processing scRNA-seq data from 10x Genomics, and processing data generated from alternative protocols. For instance, microwell-based protocols have been known to yield more features and display lower levels of dropouts compared to 10x, and so we accommodate for them by providing a more customizable path through the preprocessing stage  [21]. Barcode Extraction. Before the era of 10x Genomics, scRNA-seq data had to be demultiplexed, mapped, and quanti ed. The demultiplexing stage entails an intimate knowledge of cell barcodes and Unique Molecular Identi ers (UMIs) which are protocol dependent, and expects that the bioinformatician knows exactly where and how the data was generated.
One-click Pre-processing Quanti cation with Cell Ranger. 10x Genomics simpli ed the scRNA package ecosystem by using a language independent le format, and streamlining much of the barcode particularities with their Cell Ranger pipeline, allowing researchers to focus more on the internal biological variability of their datasets  [23]. Quanti cation with STARsolo. The pre-processing work ow (titled "10X StarSolo Work ow") in Galaxy uses RNA STARsolo utility as a drop-in replacement for Cell Ranger, because not only is it a feature update of the already existing RNA STAR tool in Galaxy, but because it boasts a ten-fold speedup in comparison to Cell Ranger and does not require Illumina lane-read information to perform the processing  [24, 25]. Other Approaches. The pre-processing work ows for these "one-click" solutions consume the same datasets and yield approximately the same count matrices by following similar modes of barcode discovery and quanti cation.
Downstream Work ows Common Stages of Analysis. The downstream modules are dened by the ve main stages of downstream scRNA-seq analysis: ltering, normalisation, confounder removal, clustering, and trajectory inference. There are three work ows to aid in this process (two of which are shown in Figure  2 ), each sporting a di erent well-established scRNA-seq pipeline tool. Quality Control with Scater. The Scater pipeline follows a visualise-lter-visualise paradigm which provides an intuitive means to perform quality control on a count matrix by use of repeated incremental changes on a dataset through the use of PCA and library size based metrics  [30]. Once this pre-analysis stage is complete, the full downstream analysis (comprising the ve stages mentioned above) can be performed by workows based on the following suites: RaceID and ScanPy.
Downstream Analysis with the RaceID Suite. RaceID was developed initially to analyse rare cell transcriptomes whilst being robust against noise, and thus is ideal for working with smaller datasets in the range of 300 to 1000 cells. Due to its complex cell lineage and fate predictions models, it can also be used on larger datasets with some scaling costs. Downstream Analysis with the ScanPy Suite. ScanPy was developed as the Python alternative to the innumerable R-based packages for scRNA-seq which was the dominant language for such analyses, and it was one of the rst packages with native 10x genomics support. Since then it has grown substantially, and has been re-implementing much of the newer Rbased methods released in BioConductor as "recipe" modules, thereby providing a single source to perform many di erent types of the same analysis.
Disadvantages of Filtering. There is always the danger of overltering a dataset, whereby setting overzealous lower-bound thresholds on gene variability, can have the undesired e ect of removing essential housekeeping genes. These relatively uniformly expressed genes are often required for setting a baseline to which the more desired di erentially expressed genes can be selected from. It is therefore important that the user rst performs a naive analysis and only later re ne their ltering thresholds to boost the biological signal.
Pseudotime Trajectory Analysis Inferring Developmental Pathways. The cell pseudotime series analysis is often referred to as the trajectory inference stage, since cells are ordered along a trajectory to re ect the continuous changes of gene expression along a developmental pathway under the assumption that the cells are transitioning from one pluripotent type to another less-potent type. Pseudotime Techniques. For the trajectory inference stage, there is the Partition-based Graph Abstraction (PAGA) technique championed by ScanPy  [39] , and there is also the FateID and StemID packages for the RaceID work ow  [40]. The former provides a level of graph abstraction to the datasets in order to infer a community graph structure, which it can use to learn the shape of the data and infer pathways between neighbourhoods.
A table containing the full list of tools in the subdomain, as well as their application to the previously mentioned stages of scRNA-seq analysis is given in Supplemental Table  1. Human Cell Atlas community members, led by the European Bioinformatics Institute and the Wellcome Sanger Institute have their own subdomain at humancellatlas. usegalaxy. eu [42] , providing access to widely applicable tools including ScanPy, Seurat and Monocle3  [43] , but also specialist tools such as those for cell type prediction (including scmap  [44] , scPred  [45]  and Garnett [46]). Analysis in Galaxy work ows. The tools outlined in the Downstream Work ows subsection expose the full set of parameters of their underlying program suites, in order to serve the same level of customisation that the users would expect when running a notebook-based analysis.
Galaxy Interactive Environments (GIE). For the more computer programming-oriented users, Galaxy hosts interactive environments at live. usegalaxy. eu which allows users to spin up their own Jupyter  [47]  or RStudio  [48]  notebooks whilst harnessing the same cloud compute infrastructure. Here, users can import their Galaxy datasets, process them in their own desired manner, and export them back into their histories in a similar way to how datasets are treated in work ows. List of GIEs. In addition to interactive notebooks, the GIE also boasts a selection of other interactive tools such as the previously mentioned cellxgene featured in Figure  3 , as well as SPARQL a query language interface, BAM/VCF IOBIO a le format analysis viewer  [49] , EtherCalc a web spreadsheet  [50] , PHINCH a metagenomes visualiser  [51] , Wallace a species modelling platform  [52] , WILSON an omics visualiser  [53] , IDE for materials science, Panoply a netCDF viewer  [54] , HiGlass a Hi-C data visualiser  [55] , and even an XFCE Virtual Desktop environment  [56].
Reproducible Cloud-based Analysis. The advent of scRNA-seq analysis within the Galaxy framework re-echoes the e orts to standardise the analysis of scRNA-seq with the promise of presenting reproducible research. The burden of computation on the ever-growing size of the datasets is shifted to the cloud computing resources, and as scRNA sequencing technology scales, more researchers are likely to migrate towards cloud-based solutions in order to reap the bene ts of superior computing abilities and storage capabilities. Ultimately, the Galaxy framework abstracts the user from the many nontrivial technicalities of the analysis, and exposes them to a legible interface of tools that they can pick and choose from. Longevity and Accessibility. The community regularly comes together during scheduled code festivals (CoFests) or hackathons to review, contribute, and actively maintain the training materials.
The number of community contributions have steadily increased over the last four years  [16] , and this growing trend ensures that the Galaxy resources will stay current and adapt to changes in scRNA sequencing technology and analysis methods if necessary. The GTN also makes use of language translation tools to provide international interpretations of the training materials in order to reach a wider more internationally diverse audience. Future of scRNA-seq in Galaxy. The capacity for growth of scRNAseq in Galaxy is limitless, with the continuing acquisition of new single-cell tools being incorporated into Galaxy workows, and the expanding GTN community bringing more expert-level contributions to the training material. The vestiges of incompatible libraries and in-exchangeable le formats are unburdened from the user as the epoch of web-based tools and strong biocomputing frameworks become more dominant.
Acknowledgements We thank the bioinformatics group at the  University of Freiburg  for the development and hosting of the European Galaxy server,  Monika Degen-Hellmuth  at the  Backofen Lab  for her assistance in the organization of the project, the  Institut Français de Bioinformatique (IFB)  for its support of the ARTbio team,  Charles Girardot  at  EMBL Heidelberg  for his useful feedback, and we also thank the worldwide contributions from users and developers towards the Galaxy Project and all upstream authors and contributors of the software ecosystem that we use and rely on.
Availability of supporting data and materials All datasets used in the GTN are independently hosted at Zenodo and are easily ndable under the tag "Galaxy Training Network", as well as being directly hosted within the Galaxy Data Libraries on the UseGalaxy. eu server. The tool wrappers which serve as the functional components of the many di erent single-cell analysis tools are hosted at the GitHub Tools-IUC repository, as well as at the Galaxy Toolshed under the category of "Transcriptomics".
In semantic annotation, semantic concepts are linked to natural language. Semantic annotation helps in boosting the ability to search and access resources and can be used in information retrieval systems to augment the queries from the user. In the research described in this paper, we aimed to identify ontological concepts in scientific text contained in spreadsheets. We developed a tool that can handle various types of spreadsheets. Furthermore, we used the NCBO Annotator API provided by BioPortal to enhance the semantic annotation functionality to cover spreadsheet data. Table2Annotation has strengths in certain criteria such as speed, error handling, and complex concept matching.
Enabling a fast annotation process with the Table2Annotation tool Pierre Larmande 1,2* , Kazim Muhammed Jibril 2 be seen as an ontology matching process, in which natural language texts are matched with concepts. There are already some existing web services and tools that use semantic annotation for ontology matching, as have been evaluated by Oliveira and Rocha  [1]. However, few of these tools handle spreadsheet data as text input. We developed the Table2Annotation tool with that purpose because there is a need for such a tool in the life sciences community, which produces extensive experimental data in spreadsheets. Semantic annotations will facilitate more complex analyses across several datasets. The paper is organized as follows. Section 2 defines the challenges of semantic annotation.
" -Gene/protein disambiguation: In the biomedical context, all proteins have associated genes, often with the same name, making it difficult to annotate texts dealing with genes and proteins. -Detection of name variants: Variations of entity naming can take many forms, thereby complicating annotations. For example, abbreviations and shorthand texts are difficult to normalize with ontological concepts. The challenges faced in annotation can be tackled by two approaches, which can be also combined. The first one is the termto-concept matching method, which involve matching some parts of the provided text to structured knowledge databases, dictionaries, or vocabularies. However, it is difficult to maintain comprehensive lexicons to be used for annotation. The second approach is machine learning, which involves creating annotators for specific purposes and usage instead of more general ones  [5].
Challenges of semantic annotation tools Diverse tools are used in semantic annotation  [1]. These tools also encounter some challenges, a few of which are listed below: -Speed: This is one of the most common challenges. Annotations performed on huge datasets can take a lot of time to process. -Language specificity: Most annotators are in English, which makes it difficult to apply semantic annotation in other languages. -Document genre genericity: Annotators that support document input can face the problem of having to annotate different document formats, and not supporting a particular format could be a challenge. -Text variation: According to Jovanovic and Bagheri  [5] , challenges are faced also due to the fact that there are different kinds of biomedical texts and variations in texts, for example between biomedical and clinical texts.
This annotator is currently used in AgroPortal  [11]  and BioPortal. The flow of Table2Annotation is quite simple and understandable. The system starts by taking an input dataset (CSV, Excel, etc. ) and then processes the file by reading the data and fetching the necessary data to be annotated. It takes the necessary data and calls an external API provided by AgroPortal to annotate the data. The results returned from this process are processed by taking the Uniform Resource Identifier (URI), concept ID, and the matched words. Finally the annotated terms are saved and written to an output file for the user to access. The operation of the matching system is described diagrammatically in Supplementary Fig. 1. In building this Table2Annotation tool we decided to use the NCBO annotator (AgroPortal API) to support the annotation of terms.
Running Table2Annotation Table2Annotation is a Java-based program that is currently executed through the command line interface. The user must have a dataset that he or she wants to annotate first. Table2Annotation is compiled after the code and all the functions explained in the previous section have been fully implemented. The compilation of Table2Annotation is done with all the necessary libraries included in the Java project. To run the system the user needs to input the following parameters: input file (mandatory), column (mandatory), suggestions (optional), slice (optional), separator (optional), and sheet (optional). First, the user provides the path to the input file (dataset) and then provides the name of the column to be annotated. These two parameters are mandatory and the others are optional.
Results In this section, we describe the results obtained from the Table2Annotation tool. We also describe the context of obtaining the results and an evaluation of the system. First of all, we needed a dataset to test the tool, as shown in Fig. 1. The dataset that we used was quite small, as using a small dataset better demonstrates how the results are obtained, but the same principles are applied when using a large dataset. The dataset contains a "PROPERTY" column, which contains the terms to be annotated.
Test with a permutation algorithm In this section, we tried to show the effect of having an algorithm to solve the problem of conjunctions in terms, which was mentioned earlier. We annotated the term "drought and salinity tolerance" and Fig. 4  shows the results. Fig. 4  (A, dataset result without algorithm) shows the results from the operation without the algorithm, and we can see that there are only matches for "drought" and "salinity tolerance. " Fig. 4  (B, dataset result with algorithm) shows the results from the operation with the algorithm, which yields  matches for three terms: "drought", "salinity tolerance", and "drought tolerance. ".
The filters (slice and suggestions) also help to tailor the results to match the user's expectations. The system has strengths, but also has some weaknesses, such as relying on an internet connection and being dependent on the API. The system uses an external API, which can cause problems. Firstly, the system cannot work offline as it needs internet access to call the external API, which could be seen as a weakness. Secondly, if the external API is down for some reason, the system cannot be used. These weaknesses can be solved by building a full annotation system that does not depend on the availability of any external annotation API. In the future, we think that we can improve algorithms to handle grammar problems and disambiguation. These algorithms should use language dictionaries to be able to transform terms without meaning (short forms) to something understandable to improve the process of matching to concepts.