dataesr/scientific-paragraphs-categorization huggingface dataset:
6F ). Similar results were obtained when using DN thymocytes derived from Rag2 -/-mice (Rag2-DN) as control samples (Supplemental Fig. S10 ). To extend our findings to another T-ALL model, we used a recently published dataset from transgenic mice overexpressing NUP214-ABL1 oncogenic fusion along with the TLX1 transcription factor, two cooperative oncogenic factors in T-ALL (Supplemental Table  S1 )(Vanden  Bempt et al. 2018). Analysis of broad and sharp H3K4me3 peaks in wt and NUP214-ABL1 + /TLX1 + thymus, along with analysis of gene expression and TLX1 binding sites, provided consistent results with those obtained with the TLX3 model (Supplemental Fig. S11 ). In particular, we found that the expression of genes associated with broad H3K4me3 domains in NUP214-ABL1 + /TLX1 + thymus was significantly up-regulated as compared to a set of expressionmatched genes with sharp H3K4me3 peaks (Supplemental Fig.
Processing of ChIP-seq data Publicly available datasets are listed in Table  S1. The reads were trimmed for low-quality reads with sickle (https://github. com/najoshi/sickle) and mapped to the hg19 reference genome using Bowtie 0. 12. 7  (Langmead et al. , 2009). The peaks were called using MACS2. 08 (Feng et al 2012) with a P value cut-off less than 0. 1 and using the "--broad" and "-bdg" options. For each cell population, the respective ChIP-seq inputs were used as control data during peak calling. In addition to the peak files, MACS2 generated bedGraph files which are transformed to bigWig files with bedGraphToBigWig. When spike-in from Drosophila S2 cells was available, bigWig files were produced using deepTools bamCoverage and scaling the signal by 100,000 divided by the number of reads mapping to the Drosophila exogenous BDGP6 genome.
Average tag density profile of histone marks The average tag density profiles around the TSS for the histone mark H3K4me3, in a given cell line, were generated by calculating the mean tag density normalized as coverage per million (CPM), within -5kb of the TSSs of reference and control lists genes. The TSSs were grouped into different classes based on their H3K4me3 breadth at each T cell developmental stage and different cell lines. The tag density profiles were computed individually for each class and average density over 50 bp windows were used to generate the density profiles. The average densities were computed using R script and the profiles were plotted using the package ggplot2 under R (R Code Team 2020). We defined the pausing region as the region from 250 bp upstream to 250 bp downstream of the TSS and defined the elongation region as the region from 200 bp downstream of the TSS to 200 bp upstream of the TTS.
Functional analyses Functional enrichment analyses of broad H3K4me3 domain-associated genes were produced using a custom pipeline to automate multi-sample queries to GREAT web-service  (McLean et al. 2010). In summary, broad and sharp peaks were queried with rGREAT R package  (Gu 2020)  against GO Biological Process. Genomic association rules with genes were done using default GREAT "Basal plus extension". Significant terms were filtered as those having Binomial Fold Enrichment higher than 2 and both Binomial and Hypergeometric tests Benjamini-Hochberg adjusted P values lower than 0. 05. GOSemSim R package  (Yu 2020)  was used to compute Wang similarity distance between all terms. Terms with a similarity distance higher than 0. 8 were grouped. Terms were further filtered for heatmap display to keep only the best 5 terms for each sample according to the binomial P value.
RNA-seq data analysis Processed RNA-seq data for a series of 41 adult T-ALLs and thymic subpopulations have been previously published  (Bond et al. 2017; Cieslak et al. 2020). Normalization and differential expression analyses were performed using DESeq2 (Anders and Huber 2010). Control lists were determined based on a reference gene list computed as optimally matched for similar signal level of expression using R script. The statistical comparisons were performed using the Wilcoxon test unless mentioned otherwise.
Plates were then incubated for further 4 hours and read using a Multimode Plate Reader VICTOR Nivo™ (Perkin Elmer). The values of IC 50 for PBIT and OICR-9429 were determined using GraphPad Prism 5. 0 software. For ChIP-seq experiments, Jurkat cells were treated with either DMSO or either 10 μM PBIT or 25 μM of OICR-9429 for 5 hours. The immunoprecipitation reaction was complemented with 10% of Drosophila chromatin from S2 cells as a spike control  (Orlando et al. 2014). For RNA-seq experiments, Jurkat cells were treated with either DMSO or 10 μM PBIT for 5 or 24 hours.
Flow cytometry Transduced thymocytes were analyzed for GFP expression and immunophenotyped by flow cytometry using the following antibodies: CD4-Pacific Blue (Catalog No. 558107), CD8-Alexa-Cy7 (Catalog No. 561097) (both from BD Biosciences Pharmingen) at days 4, 15, 22, 30 after transduction. All data were acquired on a BD CantoII instrument and seven-color analysis was performed using FlowJo software (Tree Star).
Microarray Expression analyses RNA from DN-TLX3 + cells and Rag2 -/-thymocytes (Rag2-DN) were analyzed in triplicate using the Affymetrix Mouse Gene 1. 0 ST. Microarray data from DN thymocytes were obtained from  (Oravecz et al. 2015). Expression data were MAS normalized using the Affy library from R-Bioconductor (http://www. R-project. org). Gene expression levels were determined by using the RMA-Level Gene Expression software (Affymetrix).
Acknowledgments We thank the  Cell Imaging Platform of Institut des Maladies Génétiques Imagine , the  Transcriptomics and Genomics Marseille-Luminy (TGML)  sequencing platform, the Marseille-Luminy cell biology platform for the management of cell culture, and the  CRISPR Screen Action  platform from the  Canceropôle PACA. We thank students from the  Master "Biologie Structurale et Génomique " (class  2020-2021 ,  Aix-Marseille University ) who provided technical help during a practical session. Work in the laboratory of S. S. was supported by recurrent funding from  INSERM  and  Aix-Marseille University  and by specific grants from the  European Union 's  FP7 Programme  (agreement N°  282510-BLUEPRINT ), the  Foundation for Cancer Research ARC  ( ARC PJA 20151203149 ),  A*MIDEX  ( ANR-11-IDEX-0001-02 ), Plan Cancer 2015 ( C15076AS ),  Institut National du Cancer (INCA)-PLBIO and Ligue contre le Cancer (Equipe Labellisée ).
Data access All raw and processed sequencing data generated in this study have been submitted to the NCBI Gene Expression Omnibus (GEO; https://www. ncbi. nlm. nih. gov/geo/) under the metaseries GSE164228 and are listed in Supplemental Table  S1. All scripts used in this study are available at GitHub (https://github. com/guillaumecharbonnier/mw-belhocine2021) and as Supplemental Code S1.
Introduction Viral genomic data is expanding, and their in silico analysis poses many challenges, including how to predict the likely host of a given virus  (de Jonge, et al. , 2020; Dzunkova, et al. , 2019; Kieft, et al. , 2020; Li, et al. , 2020; Santiago-Rodriguez and Hollister, 2019). The gold standard for host identification remains the experimental evidence, which can take a long time and considerable effort to obtain. Four years passed between the prediction of Bacteroidetes as the putative host for crAssphage (the most abundant human gut bacteriophage) and the first experimental evidence that the strain Bacteroidetes intestinalis APC919/174 serves as a host for crAss001  (Dutilh, et al. , 2014; Shkoporov, et al. , 2018). The GenBank  (Sayers, et al. , 2019)  database might be expected to provide information about the host of a virus, but these records mostly identify the host only to genus or species level, which is insufficient.
Results We circumvented the challenges associated with virus host range analysis, by designing the Viral Host Range database (VHRdb, https://viralhostrangedb. pasteur. cloud/), which compiles experimental host range data provided by contributors. This open web-based resource can be used to explore and analyze publicly accessible data with a powerful search engine that scans data and metadata (virus or host names, contributor name, location, GenBank accession number, etc. ). Not only can users find a virus, but they can also immediately identify the set of hosts on which it has been tested, across all the available data. Filters, analysis and display settings can facilitate rapid visualization of the most relevant information, such as the highest host range score or the most susceptible host (Figure  1 ).
Importantly, when discrepancies between datasets are detected, they are highlighted and direct access is provided to the source data, for further investigations. We designed a user-guided process for uploading data compatible with the VHRdb mapping tool, to facilitate comparisons of datasets. This mapping tool is the cornerstone of VHRdb, translating the contributor's original (numerical) data into a unified ranking system. The mapping tool was designed to allow each contributor to classify the results of virus-host interaction tests into a maximum of three responses: "0", for "no infection"; "2" for "infection"; and "1" for "intermediate", corresponding to any interaction that is different from "0" and "2". Then, contributors can readily compare their results with publicly available datasets (curated by administrators to ensure that the database remains homogeneous).
If kept private, data are neither accessible to, nor curated by administrators. Analysis across a restricted number of datasets is also possible, to focus on specificities associated with one or several viruses or hosts. Another issue affecting the accurate appreciation of a virus host range is the lack of precise characterizations of tested hosts. In particular, most of clinical isolates used to determine the host range of bacteriophages for phage therapy applications are not sequenced. In addition, viruses themselves evolve over time and adapt their host range to the available hosts  (Rothenburg and Brennan, 2020). The VHRdb therefore handles GenBank accession numbers for both viruses and hosts, as a solution to provide unique identifiers. In addition to the identification of suitable hosts for viruses and the cross-analysis of experimental tests, we anticipate that the VHRdb will become a resource for the development of machine learning approaches, which require large amounts of data, to improve the prediction of the host of a virus, or even the receptor that it uses  (Leite, et al.
, 2018; Young, et al. , 2020). It could also be used more directly by clinicians, who will increasingly have access to the genome sequences of pathogens. If the strain infecting a patient is closely related to a tested strain present in the VHRdb, candidate bacteriophages are immediately identified, shortening the time required to develop an appropriate treatment. The VHRdb will also provide opportunities to address fundamental questions in virology, from ecological dynamics to the molecular mechanisms underlying virus-host interactions. The VHRdb is a unique, publicly accessible resource for the community of microbial virologists, for the rapid identification, characterization and dissemination of data for virushost interactions of broad interest to the educational, scientific and medical communities, and to private sector entities developing applications.
Data Availability The ViralHostRangeDB application is available from https://viralhostrangedb. pasteur. cloud. , 2017). During the mapping of the responses of a file onto the global scheme, the thresholds suggested to users are calculated with the NumPy  (Oliphant, 2006)  and Scikit-learn  (Pedregosa, et al. , 2011)  packages. The NCBI identifiers describing the host and virus strains are validated with Entrez web services  (Sayers, et al. , 2020)  which are queried with the BioPython  (Cock, et al. , 2009)  package.
Privacy The access to uploaded datasets can be finely controlled, by restricting it to the uploader only, sharing it with a specific set of other users, or making it public. It is also possible to set permissions for the edition of a dataset for each user. Private data sources can be accessed only by explicitly authorized users, regardless of whether the user is a curator or a privileged administrator. To secure edition operations on the datasets, all modifications are logged and stored in histories, to allow rollback.
web interface allows the interrogation of datasets. A `search module`, accessible either through a quick search box or through a specific advanced search page, can be used to discover datasets through full text and specific filters (e. g. Host or Virus names, contributor, publication…). The exploration module, accessible from the top menu or from the search results, provides the main functionality of the application: the ability to compare the responses of any number of hosts to any number of viruses, across all the datasets accessible. Legend to Figure 1. Diagram presenting the main functionalities of the Viral Host Range database. The top panel (Search) introduces the search tool and links to subsequent information. The bottom panel (Contribute) presents the main steps that contributors must achieve to record new data.
Its source code is freely available from the Gitlab hub of Institut Pasteur (https://gitlab. pasteur. fr/hub/viralhostrangedb),undertheterms of the MIT license, together with detailed documentation (https://hub. pages. pasteur. fr/viralhostrangedb/)ArchitectureThearchitecture of the ViralHostRangeDB web application is based on the Django Web Framework, and the PostgreSQL database. Data are displayed, on the server side, in the Django REST framework. This environment provides efficient and safe data storage as well as tight control access. The application, its database and routine processes(backup, email.
Acknowledgments We warmly thank  Roger Carlson ,  David Dunigan ,  Mart Krupovic ,  Sylvain Moineau ,  Marie-Agnès Petit ,  Catherine Schouler  and  Denise Tremblay , and all current and former members of the  laboratory of L. Debarbieux  for contributing data to the VHRdb. We thank the  IT department of Institut Pasteur , including  Thomas Menard , in particular, for providing access to the Kubernetes cluster and initial training. We thank  Jean-François Charles  for assistance in designing the figure. Q. L. -B. is funded by  École Doctorale FIRE -Programme Bettencourt.
Its source code is freely available from the Gitlab hub of Institut Pasteur (https://gitlab. pasteur. fr/hub/viralhostrangedb),undertheterms of the MIT license, together with detailed documentation (https://hub. pages. pasteur. fr/viralhostrangedb/)ArchitectureThearchitecture of the ViralHostRangeDB web application is based on the Django Web Framework, and the PostgreSQL database. Data are displayed, on the server side, in the Django REST framework. This environment provides efficient and safe data storage as well as tight control access. The application, its database and routine processes(backup, email notifications, virus/host identifier analysis, etc. ), are hosted on a Kubernetes cluster (https://kubernetes. io/), providing high availability, scalability and fail-over. The global software quality of the application is ensured through unit test scenarios covering 99% of the code base.
Importing data Any authenticated user can contribute datasets via the top menu. Datasets can be uploaded as Excel files as detailed in the online documentation (https://hub. pages. pasteur. fr/viralhostrangedb/compatible_file. html). Excel data files are imported with the Pandas and xlrd Python packages (McKinney including instructions for use, deployment and administration purposes. A demonstration server can be run directly from a docker image (https://hub. docker. com/r/viralhostrangedb/demo), providing a way of testing all features of the application, including the privileges and (in)visibility of private data sources.
The ever-increasing amount of remotely-sensed data pertaining to archaeology renders human-based analysis unfeasible, especially considering the expert knowledge required to correctly identify structures and objects in these type of data. Therefore, robust and reliable computer-based object detectors are needed, which can deal with the unique challenges of not only remotely-sensed data, but also of the archaeological detection task. In this research -across-domain collaboration between archaeology and computer science -the latest developments in object detection and Deep Learning -for both natural and satellite imagery -are used to develop an object detection approach, based on the YOLOv4 framework, and modified to the specific task of detecting archaeology in remotely-sensed LiDAR data from the Veluwe (the Netherlands).
INTRODUCTION Remote sensing has become an essential part of archaeological spatial research, to locate and characterise the surviving physical evidence of past human activity in the landscape  (Verhoeven 2017). Consequently, the manual analysis of remotely-sensed data is a common practice in local and regional scale archaeological research and heritage management  (Cowley 2012; Opitz and Herman 2018). However, the amount of open access, high-quality remotely-sensed data is continuously growing and exceeds the capacity of general hardware, software, and/or human resources, i. e. , it can be considered Geospatial Big  Data (McCoy, 2017). Therefore, alternative strategies, which for instance rely on citizen science or computational approaches, are needed to effectively and efficiently analyse these datasets and find and document the overwhelming number of potential archaeological objects therein  (Bennett, Cowley & De Laet 2014; Bevan 2015).
CHALLENGES OF OBJECT DETECTION IN REMOTELY-SENSED DATA Recently, multiple domains have endeavoured to adapt Deep Learning techniques for automated detection in remotely-sensed data, especially in satellite imagery  (Ball, Anderson & Chan 2017). For instance,  Van Etten (2018)  published an extensive review of challenges and possible solutions for using CNNs in satellite-based earth observation. Many of these challenges are not domain specific, but are also prevalent in archaeological automated detection (see  Verschoof-van der Vaart in press). The most common challenge is the fact that although the remotely-sensed images are massive in size, the objects of interest are generally very small. This is especially true in comparison to the size of images and objects found in more general purpose datasets, such as Microsoft COCO  (Lin et al.
2014)  or Pascal VOC  (Everingham et al. 2010 ). These general purpose datasets contain 'natural images' (i. e. , photographs of scenes seen in normal, every-day settings) in which objects are generally large and prominent, and occupy a major portion of the image. Traditional object detection methods take advantage of this by downscaling (and pooling) the images when they pass through the CNN to greatly reduce the computational cost. However, this also removes small objects, rendering them impossible to detect. In addition, the objects of interest are often densely clustered but scarcely distributed (e. g. , cars in a parking lot or barrows in heathland), generally lack a consistent orientation, are often occluded (by trees, human-made objects, etc. ), and in the case of archaeology are also in various states of preservation (Verschoof-van der Vaart in press).
AIM Based on the above, the main aim of this paper is to develop a reliable, accurate, and fast workflow geared towards the detection of multiple classes of archaeological objects in remotely-sensed data, by using the latest developments from other domains, and from Deep Learning object detection in general. To accomplish this, the research presented is a joint effort between archaeologists from the Faculty of Archaeology at Leiden University and computer scientists from the French Graduate Engineering School ESIEA. A state-of-the-art object detection approach, called YOLOv4 (Bochkovskiy, Wang & Liao 2020), has been modified, both in architecture and training regime, for the specific problem of archaeological object detection in LiDAR data. The developed approach is trained and tested on a dataset from the Netherlands (Figure  1 ).
In addition, the performance of this optimised model is compared to a general version of the same model, i. e. , without any modi-fications, and other object detection approaches used in recent archaeological research. These comparisons allow us to investigate the benefits of using state-of-the-art techniques and modifications. Finally, the potential of cross-domain collaboration between archaeologists and computer scientists can be evaluated. In the next Section (2), the research area and datasets are introduced, followed by a detailed overview of the object detection approach and modifications used (Section 3). In Section 4 and 5 the results of the experimental evaluation are presented and discussed. The paper ends with an overview of the main insights and future research planned (Section 6).
RESEARCH AREA In this research, LiDAR data from the Veluwe, a region (ca. 2200 km 2 ) in the central part of the Netherlands is used (Figure  1 ). Nowadays, this region consists predominantly of forest and heathland, interspersed with agricultural fields, built-up areas of various size, and major and minor roads (for a detailed overview of the area see Lambers, Three classes of archaeological objects are of interest for this research: barrows, Celtic fields, and charcoal kilns (Figure  2 ). Barrows are small, round or oval mounds of raised earth (or stone), which are placed over one or several burials. These funerary monuments are fairly common in north-western Europe and date, in the case of the Veluwe, from around 2800 to 1400 cal. BCE  (Bourgeois 2013). The diameter of barrows in our datasets is on average about 18 m, although their size varies considerably (Verschoof-van der Vaart in press).
The second class of archaeological objects are Celtic fields: agricultural field systems from later prehistory (Late Bronze Age until the Roman Period; ca. 1100 cal. BCE -200 CE). These are composed of roughly rectangular, embanked plots of fairly regular size (on average 40-50 m) that form extensive, checkerboard-shaped systems  (Arnoldussen 2018). In our datasets, these individual plots are considered as a single Celtic field object, not the entire field. This greatly increases the number of examples in the dataset and allows for easier detection, since a single plot is generally rectangular, while the shape of the entire field often is not (see  Verschoof-van der Vaart & Lambers 2019). Charcoal kilns are circular platforms or mounds surrounded by a shallow ditch or circle of pits, used for the production of charcoal by heating wood at a specific temperature, while covered with soil  (Hirsch et al.
DATA The datasets used in this research (see also  Verschoofvan der Vaart et al. 2020 ) are constructed using LiDAR data, freely available from the online geospatial data repository PDOK (Nationaal Georegister 2021). The data is disseminated as an interpolated Digital Terrain Model (DTM) in GeoTIFF images of 10,000 by 12,500 pixels (5 by 6. 25 km). In this research, the DTM has first been processed with the fill no data tool in QGIS (QGIS Development Team 2017) to remove pixels without values from the raster image. Subsequently, the DTM was visualised with the Simple Local Relief Model (SLRM; Hesse 2010) visualisation from the Relief Visualisation Toolbox  (Kokalj & Hesse 2017).