dataesr/scientific-paragraphs-categorization huggingface dataset:
Discussion Pantagruel is a comprehensive pipeline for the evolutionary analysis of bacterial pangenome datasets. A central component is the use of reconciliation methods  (Szöllősi et al. 2015)  to compare the phylogeny of a given gene with that of the genome as a whole. State-of-the-art reconciliation techniques are however too computationally expensive to be applied to hundreds of genomes each containing thousands of genes. We therefore implemented within Pantagruel new ways to simplify the input data to ease the computation of reconciliations with limited loss of information. Clades that cluster very similar gene sequences and show little internal topological support are separated from the well supported part of the gene tree (Figure  2 ). The absence of phylogenetic information within those clades, and the possibility of homologous recombination having occurred between such closely related sequences, justify that their relationships should not be considered under a phylogenetic model.
We observed that this way, the reconciliation software achieved large speed-ups, but also could simply be run on gene families in which the initial complexity otherwise led to systematic excess memory use and termination. Pantagruel thus allows the practical use of reconciliation methods (we used ALE but in principle other methods could be used) on large-scale pangenome datasets. Methods for statistical testing of gene lineage association will be developed using simulation-based approaches as previously used for phylogenetically-correct testing of phenotypegenotype associations in clonal microbes  (Collins & Didelot 2018 ). This will be based on simulations of genome evolution under a similar DTL model that accounts for gene linkage evolution. Simulation could be provided by pangenome tree simulators such as FwdTreeSim (https://github.
com/flass/FwdTreeSim) or Zombi  (Davin et al. 2018). Development of analytical solutions to evaluate the likelihood of observing co-evolving pairs under a neutral model is also envisaged, notably using a linear algebra framework  (Behdenna et al. 2016). (init) user-defined parameters given via command-line options are stored into a configuration file that will direct the operations throughout the pipeline. (0) Input data are assembled from variable sources: annotated genome assemblies (formatted as) obtained from NCBI Assembly database; an assembly accession list for annotated genomes to be downloaded from NCBI Assembly FTP; or user-provided contigs of custom assemblies, which will be annotated by Prokka. (6) From each gene family alignments, a rapid maximum-likelihood gene tree is estimated on the full alignment using RAxML.
All proteins are extracted from annotated assemblies, and clustered into homologous families using MMSeqs. (2) Protein family sequences are aligned with ClustalOmega, and reverse-translated into CDS alignments with PAL2NAL. (3) A SQLite database is set up and loaded with data covering organism and genome assembly metadata, protein/CDS annotation and family clustering. (4) Proteins are uniformly annotated with functional domains using InterProScan, and these annotations are linked to Gene Ontology and metabolic pathway ontology terms; all annotation and ontologies are loaded into the SQLite database. (5) Core gene families are concatenated and used to infer a reference species tree with RAxML. Population of closely related genomes are delineated based on the tree topology.
Acknowledgements We thank  Eric Tannier ,  Gergely Szöllősi ,  Vincent Daubin  and  Rafal Mostowy  for fruitful discussions about developing the algorithm for tree collapsing, integration of ALE and general pipeline feature development. Test computational calculations were performed with  Imperial College HPC  and  MRC CLIMB  cloud-based computing servers. This work was supported by  Medical Research Council (MRC)  grant  MR/N010760/1.
( 1 ) 1 All proteins are extracted from annotated assemblies, and clustered into homologous families using MMSeqs. (2) Protein family sequences are aligned with ClustalOmega, and reverse-translated into CDS alignments with PAL2NAL. (3) A SQLite database is set up and loaded with data covering organism and genome assembly metadata, protein/CDS annotation and family clustering. (4) Proteins are uniformly annotated with functional domains using InterProScan, and these annotations are linked to Gene Ontology and metabolic pathway ontology terms; all annotation and ontologies are loaded into the SQLite database. (5) Core gene families are concatenated and used to infer a reference species tree with RAxML. Population of closely related genomes are delineated based on the tree topology.
Data sets Bosch has supplied an open huge dataset 2  (14. 3 Gb) from Kaggle. Each row of this data set represents a product, described by mixed features (numerical, categorical, date stamps), as it progresses through each production line and labels indicating the parts as good or bad. Measurements are done on each part along the assembly line to predict internal failures. Each part has a unique Id. The dataset contains an extremely large number of anonymized features. The training data has 1184687 samples with 968 numerical features, 2140 categorical features and 1156 date features. Features are named according to a convention that tells the production line, the machine on the line, and a feature number. For example, L3 S36 F 3939 is a feature measured on line3, machine36, and the feature number is 3939.
Preprocessing and Model Construction The dataset contains 1184687 observations taken from production lines. Each observation is a vector of thousands of sensor measurements plus a label for indicating pass/fail quality control. There are only a small amount of cases of failure (encoded as 1), whereas a much bigger amount of cases pass the quality control and are encoded as 0. This is a 1:171 proportion. To overcome the problems related to the learning of imbalanced data, several techniques  [29]  have been proposed, such as oversampling, undersampling, and cost-sensitive method. In this experiment, we use the techniques of undersampling by discarding data of the majority class. There are a number of methods available to undersample a dataset used in a typical classification problem. For undersampling the dataset, we use the toolkit Imblearn  [30]  which has already integrated principal oversampling and undersampling methods.
2 As for orthophemisms, they are the "direct or neutral expressions that are not sweetsounding, evasive or overly polite (euphemistic), nor harsh, blunt or offensive (dysphemistic)" (Allan & Burridge  [2006: 29] ). As  Burridge [2012: 66]  argues, Xphemisms have to be studied "within the particular context in which they are uttered. […] There is never 'Everyman's euphemism' or 'Everyman's dysphemism'. " Therefore, each metaphor for a taboo topic has an X-phemistic potential  (Terry [2019a] ) and can be more or less euphemistic or dysphemistic depending on the context of utterance. This paper focuses on DEATH metaphors, and more specifically on the possible influence of the interactions between metaphor and metonymy on the X-phemistic potential of DEATH metaphors and on their continuous euphemistic use in the English language.
Extraction of the data and results 22 As explained in  Terry [2019a]  and  Terry [2019b] , the metaphors were identified in the corpus manually thanks to both videos and scripts that can be found on the Internet. This method considerably limits the size of the corpus as it is quite time-consuming, but as Crespo  Fernández [2017: 15] , who worked on SEX and DEATH metaphors, argues, "it allows for a comprehensive search and considerably reduces the risk of missing significant cases of metaphorical language used in the sample consulted". Additionally, as the metaphors I wanted to analyse were metaphors related to the conceptual taboo domain DEATH, at least a number of occurrences were likely to be creative and therefore, there are a lot of isolated cases -most of them context-related -that would have been missed had I used a corpus linguistics software.
Scientists have to perform multiple experiments producing qualitative and quantitative data to determine if a compound is able to bind to a given target. Due to the large diversity of the potential ligand chemical space, the possibility of experimentally exploring a lot of compounds on a target rapidly becomes out of reach. Scientists therefore need to use virtual screening methods to determine the putative binding mode of ligands on a protein and then post-process the raw docking experiments with a dedicated scoring function in relation with experimental data. Two of the major difficulties for comparing docking predictions with experiments mostly come from the lack of transferability of experimental data and the lack of standardisation in molecule names. Although large portals like PubChem or ChEMBL are available for general purpose, there is no service allowing a formal expert annotation of both experimental data and docking studies.
To address these issues, researchers build their own collection of data in flat files, often in spreadsheets, with limited possibilities of extensive annotations or standardisation of ligand descriptions allowing cross-database retrieval. We have conceived the dockNmine platform to provide a service allowing an expert and authenticated annotation of ligands and targets. First, this portal allows a scientist to incorporate controlled information in the database using reference identifiers for the protein (Uniprot ID) and the ligand (SMILES description), the data and the publication associated to it. Second, it allows the incorporation of docking experiments using forms that automatically parse useful parameters and results. Last, the web interface provides a lot of pre-computed outputs to assess the degree of correlations between docking experiments and experimental data.
The limitations in this process comes from the immense gap of knowledge that individuals in one laboratory can apprehend, in comparison with the ocean of data available in scientific literature. Fortunately, in order to link the experimental activities of various small chemical entities with their (protein) targets into databases, there is a strong ongoing effort to organise these data logically by human experts, a process called curation. Once set up, these databases can be queried via their web interface but also queried using dedicated programmatic access for batch data retrieval  [8, 9]. An important limitation for gathering experimental results for a target comes from the standardisation of experimental data, of target names and of small chemical entities. For example, it is common practice to reference a molecule by a common name in a given laboratory, to use a chemical name or to name it based on the biological process interrupted by the drug.
DockNmine Overview The portal philosophy is directly inspired from funded-based projects, therefore it is designed to isolate independent and confidential data from different users. This management by project allows to assemble ligands, protein(s), docking and experimental data into a coherent ensemble, via dedicated feature-control checks. Once registered and connected, the user can start a new project or join an existing one. In both cases, either a private project or a shared project within a small group, the connected used can start to organise his computational data using dockNmine services. We have set up as an example a new project called "Target" created by the user "demo" by following the workflow presented in Figure  1B. The user can now use the Target tab (Figure  1A3 ) to add the description of its target from a unique identifier, for example the Solute carrier family 2, facilitated glucose transporter member 1, whose uniprot ID is P11166.
Since the crystal structure of GLUT1 contains another ligand (B-nonylglucoside), this ligand was also incorporated into dockNmine. These ligands were screened on the GLUT1 structure (PDB ID: 4PYP) using vina (see Supplementary Materials) and the output of vina is incorporated using the Docking service. To upload a complete docking result, its structure file has to be previously uploaded to the target but this step is more extensively described below (Figure  2D ). Once all mandatory parameters are present, the docking information is added to dockNmine (Figure  3 ). (A) Upon selection of the docking method, a dedicated form allows to link protein, ligand and docking results. Detailed docking parameters must be provided to allow a further comparison of docking profiles between experiments. If required, the plus glyphicon allows to add a target, a ligand or a target structure prior to entering the docking results; (B) Detail of the docking analysis.
This view indicates the principal features of the docking method; (C) After docking processing, the cluster energy of vina is transformed into kJ/mol, LE and SILE automatically, to ease comparison against other experiments or other ligands; (D) Interactive graph depicting the discrete cluster and associated energy. This graph, which can be easily downloaded as an image, allows a rapid overview of the docking energy dispersion for the ligand. The validity of a virtual screening must be assessed by comparing its results with experimental data. Some experimental data are already openly aggregated by entities like BindingBD or ChEMBL but this information can be retrieved automatically during the target addition to dockNmine. Though, there is a important amount of data impossible to share immediately, mostly coming from internal experiments in the laboratory.
The Experiment service allows to include data from the laboratory and its partners without the need to disclose it too early. We have included into the demo account a piperazin derivative where a cellular IC50 was determined of 50 nM is referenced in Binding DB (ID 50155745) from the work of Siebeneicher and co-workers  [14]. The structure file for this compound was incorporated from PubChem using the identifier 1387075.
Ligand Import And Management There are two ways to manage ligand incorporation into the database-(i) by adding one ligand at a time via the dedicated form, (ii) by uploading multiple ligands from a file, which will be regrouped into a library. The single ligand form (Figure  4A ) allows to incorporate ligand information from the Protein Data Bank (PDB)  [17] , PubChem [8] or ChEMBL  [9]. The crystal structure of the glucose transporter contains a glycosyl analogue, b-nonyglucoside, used to trap the protein in an inward-open conformation  [11]. This ligand has the identifier BNG in the PDB. When selecting the PDB input format and searching for BNG, a query on the PDB is performed to retrieve the ligand name, chemical formula, SMILES notation, molecular weight and InChiKey. The ideal three-dimensional coordinates of the molecule is downloaded in sdf format and added as the reference conformation for the ligand.
By default the visibility of any ligand entered using the single ligand form is restricted to the project members only. If multiple ligands are to be added rapidly, that is, from a commercial supplier, another possibility is to create a dedicated library from a multiple-compound sdf file (Figure  4C ). For example, Siebeneicher and colleagues  [14]  have determined a series of GLUT inhibitors involving piperazine derivatives. These results are available in ChEMBL in the document report card CHEMBL3779893. Five compounds were downloaded in sdf format from the ChEMBL report (Table  1 ) and assembled into a single sdf file. This library was incorporated with a free text name using a file upload form (Figure  4C ), resulting into the addition of the five new ligands into the database, joined into the "GLUT inhibitors 2016" library.
To stress the system, the incorporation of a larger library of >11,000 compounds was assessed (data not shown). In this situation, the rate for ligand processing was about 100 ligands/s. The library facility can also be used to regroup existing individual ligands into a coherent ensemble (Figure  4E, F ). This approach allows to delineate sub ensemble of ligands for easier data extraction and analysis but has no strong dependence on the classified ligands. It is therefore easy to remove a library, this will not cascade to the removal of ligands or of ligands data. In both ligand import processes, it is important to not duplicate ligands even if different names are found, coming from the diversity of upstream sources. Instead of relying on ligand names, we have chosen a more robust approach by comparing the InChiKey  [18]  of new ligands to existing ones.
Docking Import And Management The docking process needs a large amount of computational power to screen libraries of ligands against a given target. We envision to provide the possibility of performing some dockings through the interface of dockNmine in future revisions for a limited set of molecules but the potential ressources required are not yet available. Up to now, it is however possible to record already existing vina or autodock  [21] [22] [23]  results. This process already allows to standardize ligand import and management and to perform basic analysis. The course of action for pre-computed docking data is detailed hereafter. The user needs to define the target, the ligand and the structure file used for docking. Depending on the docking software, autodock or vina, different information needs to be provided.
Access Controls Any user can freely discover dockNmine without authentication but a demonstration account is provided to evaluate all of its functionalities. Once connected or registered using the log-in or the briefcase glyphicons (Figure  1A ), the user is attributed a Project Manager role (Table  2 ) and can therefore create a new project, mandatory to start adding data in dockNmine. Once set up, the Project Manager can share the project credentials with collaborators to allow them to join the project. The access controls systems is a combination of Guardian rules and of permissions offered by Django's internal group management system. A lot of predefined permissions can thus be finely tuned to Create, Read, Update and Delete data (CRUD) on any object or data in the database. Since this granularity may be hard to apprehend, we have set up pre-defined roles (Table  2 ) where these permissions are clearly split into viewers (Project Member) and editors roles (Project Manager) with a clear separation of privileges.
To ease dockNmine usage, by default all new accounts have a Manager role but it is recommended to restrict this default role to Member for some collaborators in order to avoid errors. Only the principal dockNmine administrator has full control over the service and can adjust permissions for users, objects and data. Before adding any information, connected users have to select an existing project. This mechanism allows to automatically define data visibility and origin, as all members of the project can see targets, ligands, dockings, experiments and their automated analysis. This per-project access allows to restrict data visibility to project members and accross projects. Pre-defined Manager and Member roles are indicated in the login page to demonstrate the difference between them. With a Member role, the user can add a ligand to the library but cannot upload a specific structure file.
Discussion One of the biggest challenges when trying to reach the precision medicine objectives, the goal to provide a per-individual efficient treatment, is the need to take into account little variation in protein sequences in order to predict if these mutations will lead to dramatic changes in the protein structure  [29]. This research field, also known as structural genomics  [30, 31] , is developing rapidly though many technological obstacles still need to be leveraged to be applied blindly  [32]. In order to illustrate how dockNmine could properly be used to integrate results from these approaches, we have detailed its independent services allowing to assemble existing public and private knowledge into logically organised comprehensive data sets.
Single Protein Analysis We chose the GLUT1 receptor (Solute carrier family 2, facilitated glucose transporter member 1) as an example. We indicated how to add this protein entry into the portal and how to add virtual and publicly available experimental data from databases and scientific literature  [9, 14]. We provided original docking data (see Supplementary Materials for details) to exemplify how one should make use of the portal. If one was willing to reproduce these steps, much more attention would have to be paid to the virtual screening experiments for getting relevant results  [6]. Since these steps require manual expertise and computational time, we have not allowed docking computation to be performed directly within the portal. This situation may change but there are already efficient and popular solutions available for users interested in performing large virtual screening studies  [33] [34] [35] [36].
Multiple Proteins Analysis In order to get a broader overview of the GLUT family response to different molecules, we have processed two other glucose transporters, GLUT2 and GLUT3, for which experimental binding data are also provided in the reference article  [14]. The crystallographic structure of GLUT3 was determined by Deng and colleagues (PDB ID: 4ZW9) [39], the model of GLUT2 was downloaded from Swiss-Model (automatically computed from the structure 4ZXC)  [40]. We selected a crystallographic structure and a publicly available model to compute docking energies with vina for illustrating how one could compare his experimental data with predictions without advanced expertise on computational protein modelling. The incorporation of these proteins, of virtual screening data and of experimental information were processed as previously described.
These results are available by ligand (Figure  7A ) or by target (Figure  7B ) from the drop-down options of the Analysis tab. These views present individual graph and table for dockings and experiments. For the ligand CHEMBL3780153, the experimental IC50 binding values are 4400 nM for GLUT1 and 2200 nM for GLUT3, no data being available for GLUT2. By selecting the GLUT2 receptor from the menu, the predicted binding value of the best pose is -8. 3 kcal/mol, ranking it as a medium binder on the target according to our ranking procedure. Since the docking value allows to rank this ligand in the lowest binding category (rank 3) for both GLUT1 and GLUT3, in agreement with experimental data, this rapid comparison suggests a better recognition of CHEMBL3780153 by GLUT2. This simple comparison of docking and experimental results could be exact but the user is warned about the limited predictive power of the included dataset, with a negative predictiveness and an Area Under the Curve (AUC) under 0.
Server Design, Implementation And Security The django framework (https://www. djangoproject. com/) was used to arrange data into dedicated classes. Access controls are ensured by django's built-in system supplemented by the guardian module to provide per-object control. Each page in the interface is submitted to permission validation ensured by a dedicated decorator developed specifically for this purpose. User interaction and interactive displays are provided using Bootstrap (http://getbootstrap. com/) and jQuery (http://jquery. com/). The specific protein-ligand global statistics analysis is derived from the work of Empereur-Mot and collaborators  [28].