dataesr/scientific-paragraphs-categorization huggingface dataset:
The WDL (https:// openw dl. org/) is a community-driven specification and is supported by several workflow engines, among "Cromwell" (https:// github. com/ broad insti tute/ cromw ell). The Workflows are executable as a whole or step-by-step, with detailed logs. The execution engine ensure security, robustness, flexibility and scalability. Used in a multi-users context, it requires asynchronous mechanisms and scheduling of computations. "Cromwell" (Fig. 3 ) allows the execution of workflows (files in WDL format) that describe several lines of commands that can be executed in parallel.
VIGIRISKS user web portal VIGIRISKS was designed with a "front-end" (User Web Portal) connected to a "backend" Java-web server (Fig. 3 ). The "front-end", named also the graphical user interface (GUI) is implemented as developed from the open source tool (JavaScript using Angular). The OpenLayers JavaScript library allows the display and manipulation of produced maps. The back-end server produces web services and uses a Postgres database for data management, scenarios translated into workflows, input parameters and simulation results (Fig. 3 ). To make this work, containers "docker-images" own the configuration files of the Docker image integrating "Cromwell" and others applications. Docker supports the development of VIGIRISKS platform. Docker is an open platform for developing and running applications that provides the ability to package and run an application in a loosely isolated environment called a container.
VIGIRISKS platform uses several containers under Docker: (i) one to manage multiple environment (Development, Stage, Production environments) and (ii) others to manage applications (e. g. Cromwell: workflow management system (web app java) + VIGIRISKS python modules; backend: VIGIRISKS back-end web services (web app java); front-end: VIGIRISKS front end (angular application)). For resuming, the Execution Core relies on Web services which are a Java scientific workflow engine ("Cromwell"), the definition of workflows as text files (WDL) and the description of Parameters in JSON (including Docker, python, HPC and command line execution). VIGIRISKS has three environments: (1) Development or local: for developing and testing codes on PC; (2) Stage: for staging these codes with tags version (rec-vigirisks.
brgmrec. fr) and (3) Production: dissemination of final codes (vigirisks. fr). The Development is where the unfinished code is updated between the co-workers, and committed on different branches live. The Stage environment is as similar to the Production environment as it can be. The production environment is where users access the final code after all of the updates and testing. It is possible for a particular execution of any workflow, to register inputs, parameters and resulting computed datasets, which become new records in the repository. Datasets and workflows will be shareable between groups of users or even publishable as web services when relevant. In order to extend the usefulness of workflows, we can also "Tag" a code appertaining to the Scientific Codes entity of VIGIRISKS platform.
Vigirisks platform for multi-risk assessment application As mentioned previously, the scientific scope of VIGIRISKS platform is the hazard evaluation and risk assessment in the domain of natural hazard (e. g. seismic, landslide, submersion) from the phenomenon modelling to the impact evaluation on exposed elements such 1 3 as buildings and networks. It is intended to have a wide range of methods for calculating hazard and, susceptibility and relations between hazard and vulnerability, for calculating the risk. Workflow for data analysis, preparation and transformation are also in the scope of this platform in order to facilitate the work of scientists in manipulating their datasets. In its first version, this VIGIRISKS platform was designed for the use of BRGM experts and is now in a long-term ambition an open repository of executable workflows for national and international experts in the domain of natural hazards.
The number of existing codes and workflows in not the most important think that is emphasis in the publication, but rather the flexibility and the maneuverability of introducing and implementing new scientific methods. This is the main outcome of the platform and the innovation part is the merge between the scientific, generally static platform and new information architecture that can manage dynamic use. This platform allows the use of scientifically validated methods but it also serve as an innovation tool allowing scientists to propose new methods of risk assessment and to proceed their validation more easily on several datasets covering different study areas. The transition between the scientific code that is developed by the researcher and the Web Portal that is employ by the users, stand in some, surely important but easy, json description files and hence, can be applied very quickly.
Data description The main idea of the VIGIRISKS platform is to put together the existing tools used for different hazard calculation and for risk assessment in BRGM (e. g. Armagedom,  Sedan et al. 2013; Alice, Vandromme et al. 2020; SEISAid; Watersed, Landemaine 2016; Grangeon et al. 2021). Starting with this enouncement, VIGIRISKS use python library and, when necessary, develop specific tool (toolbox) in order to manage and treated different GIS formats that are generally used for spatial description of natural hazards. Consequently, the input files have different formats depending on the type of analysis and on the field to fill in order to have all the necessary entrances and parameters for applying the chosen risk assessment calculation. Moreover, the User Web Portal boxes related to each approach are described by the user through the JSON configuration file, input.
Exposure data Exposure defines here the buildings, infrastructure and population located in hazard-prone areas. For each of the exposed elements corresponding files that describe theirs vulnerability (i. e. the capacity to resist to a particular hazard) are needed for performing risk calculation. Most of the existing exposure and vulnerability database can be used directly or with minimum format changes. For typology and vulnerability, input files can be described by Excel as. xls or. csv files or ASCII-table files. The name of the files for typology and vulnerability are modified from an approach to another in order to indicate the function and information that they have inside. Generally, for a damage calculation we need a file containing the number of buildings for each typology in a homogeneous census zone called "district", a file containing the vulnerability index, a file containing the number of apartments, a file containing the number of persons by apartment and a file containing the casualties matrix (e.
We use the functions developed for tsunami "flow" hazard since the lateral forces due to tsunami flow are the primary cause of damage to the building structure, including building collapse. Hence, the damage on structures is due to the lateral forces caused by drag effects and debris carried along by the tsunami flow (Sect. 5. 5 HAZUS Tsunami). Figure  11  shows a first visualization of the results through User Web Portal and Fig. 12  presents the results for the VIGIRISKS that have been downloaded and re-arranged for a more detailed presentation by an external GIS software. The visualization of the results through User Web Portal represents a quick overview of the results (no dynamic thematic analysis are available for the Portal, the thematic analysis that colored the points is predefined).
Discussion The designing of the workflows is created in order to approach custom and automatic workflows to reduce the gap between the scientific method and its real application on case studies, as well as between development environment and production environment. The main targets of the VIGIRISKS platform are: (1) to easily install and run code on it, (2) to easily develop the code, (3) to integrate legacy code with minor changes, (4) to reduce code duplication as possible, (5) to have execution isolation and (6) to easily execute a workflow or create a new one. All this targets are compatible with execution trace and the re-playable, but easy to change execution parameters. Some issues are still under testing in VIGIRISKS platform. One of them is related to the limit of uploading files for User Web Portal.
g. QGIS, ARCGIS). Nevertheless, the last year several technics and libraries for visualization were considered and this gives a good returns for the representation of the results in vector and json formats (e. g. Figs. 11, 13). Beside the layers of the calculated results, default layers can be adapted from a project to another. For example, the Sisfrance database (www. sisfr ance. net) for seismic simulation is very useful since we can have an idea about the historical earthquake in the area of interest. Concerning raster/grid format visualization, this part is on testing and under development and will be soon available.
VIGIRISKS platform intends to have a wide range of methods for calculating hazard and susceptibility and relations between risk and vulnerability for calculating damage. Workflow for data analysis, preparation and transformation are also in the scope of this platform in order to facilitate the work of scientists in manipulating their datasets. Connecting heterogeneous Scientific Codes and different formats input data sources is a specific issue treated by VIGIRISKS platform. While Scientific Codes are implemented in various technologies, data to process can be for instance georeferenced databases, grids and vectors data provided in various file formats, web services, and internal or external data sources, already referenced in the repository or uploaded by a user. In order to enable such an integration, we defined normalized code entry points and data connectors.
Finally, a User Web Portal offers access to all the functionalities, but main components are also usable through web services or even directly when relevant. The Execution core, based on open sources Java and Python software, is entirely accessible from web services referenced in a metadata catalogue and a version control system. A strong security mechanism allows to publish studies when they are validated, and to ease collaborative work in private groups. A BRGM Python library completes the architecture, by providing specific algorithms for the domain, including data connectors, scientific modification, and data pre-and post-treatments. Currently, the platform is in French, but the internationalization (FR/EN) is ongoing.
Acknowledgements We thank  Boulahya Faiza  for the useful discussions on various software aspects of this study and  Nicolas Taillefer  and  Stéphane Loigerot  for answering our questions on several managerial aspects. The authors are also very grateful to some colleagues of the DRP division who have provided much needed knowledge and insight on their respective physical approaches; namely  Dr. Pierre Gehl ,  Dr. Anne Lemoine ,  Dr. Daniel Raucoules ,  Benoit Aunay  and  Samuel Auclair. We thanks  Goncalves Jean  who joint the IT Teams during the preparation of this publication. Finally, we would like to thank  Karim Ben Slimane  and  Arnaud Garnier  for the support and precious discussions during the  Steering Committee of BRGM VIGIRISKS  project. This article was supported by an internal  BRGM research program  ( VIGIRISKS/ MULTIRISK2018-2022 ).
The research Fayjaloun et al. 2021 and the corresponding VIGIRISKS database was funded by the  European Union 's  Horizon 2020 research and innovation program , grant number  821046 , project  TURNkey. The calculation of earthquake damages for French-Spanish-Andorra border territory in relation with automatic ShakeMap  ( USGS4. 0)was performed during the ongoing European project  Pocrisc , (https:// pocri sc. eu), led by  Institut Cartogràfic i Geològic de Catalunya (ICGC). We thank the anonymous reviewers for their comments on an earlier version of this article.
Data availability The VIGIRISKS platform is open access via free registration on the website https:// vigir isks. fr/. Open data used in the work mentioned in this paper are available in the following portals: For Luchon: https:// vigir isks. fr/#/ my-proje cts/ 20220 11408 40299 22j. vieil le@ brgm. fr. For French West Indies: https:// vigir isks. fr/#/ my-proje cts/ 20210 32609 00274 19C. Negul escu@ brgm. fr. For Mayotte: https:// vigir isks. fr/#/ my-proje cts/ 20210 60911 19168 44C. Negul escu@ brgm. fr. For national statistics database for the buildings typologies  (Tinard et al. 2020 ) adapted from INSEE: https:// vigir isks. fr/#/ my-proje cts/ 20210 32609 00274 19C. Negul escu@ brgm. fr/ workfl ows/ 20200 61007 25147 01r. quique@ brgm. fr.
Sound sequences The sound sequences were simulated based on real road traffic sounds, in order to control their acoustical properties. The sequences consisted of background noise, to which were added a various number of car pass-bys, generated with the SimScene software  [27]. SimScene 1  is an open source library developed in Matlab that allows the simulation of sound scenes in a monophonic format as the additive composition of background and sound sources, using a database of recordings. In this study, the background noise corresponds to a continuous traffic flow that was recorded at 100 m from a urban motorway in Cergy (France), with the omnidirectional setting of a CMC6 Schoeps microphone on a portable recorder Tascam HD-P2. The car pass-bys were recorded with an ORTF system composed of two Schoeps CCM 4 microphones on a Tascam DR-100 near a two-line road in a very calm environment in Rezé (France).
All isolated sound sources are very similar in terms of acoustic characteristics as they correspond to different pass-bys of the same car driving at the same constant speed and at the same distance from the recording point. In order to mix background noise (recorded in monophonic format) and isolated car pass-bys (recorded in stereo format) with the SimScene tool, stereo recordings were transformed into monophonic wave files by mixing the two channels with the Reaper 2  software. Sixteen 2-min sound sequences were created with the following characteristics of an outdoor environment based on a complete two factor design: Emergence of peak levels above the background noise in dB(A) calculated as the difference between L Amax, 1s and background noise L A90. Four emergence levels were considered: +10 dB(A); +15 dB(A); +20 dB(A) and +25 dB(A).
Written participant consent. Training session with two extreme sound sequences (Fig. 2 ). Test per se: participants were exposed to 16 sound sequences while reading. End of the test with debriefing. Filling out a receipt of gratification. The participants were informed about this study via written information with a welcome sheet where various instructions were given, such as the position to hold for the participant during the test. The laptop had to be on the knees, the back well installed in the armchair, the fingers on the keyboard (one key for "true", one key for "false" and one key for "next", see Tab. 3). The interface was developed on OpenSesame 3  , a software designed for psychological tests that records all the participants' answers in the form of variables. The texts, previously designed for psychological tests with children, are calibrated for both size and reading difficulty  [31].
Calculation of the reading times Data were processed to reconstruct the reading and the sound timelines of the participants during the progress of their test. Concerning the reading timeline, four categories of activities performed by the participants have been identified: Reading (R), Waiting (W), Answering the Target-Word (ATW), Answering the Comprehension Question (ACQ). The time limits of each type of activity correspond to the instants when participants select an answering key and the duration of this activity is the difference between these two instants. Then, all participants followed the activities at their own speed for each text, with the following time steps: W 1 -R-R-R-R-R-R-W 2 -ATW-W 2 -ACQ-W 3 (Tab. 3). Concerning the sound timeline, the evolution of the sound level during the test has been divided into five dynamic categories: silence corresponding to the background noise of the laboratory without any sound sequence (Sil), background noise of a sound sequence when there is no emerging event (Bck), rising front of a peak (RF), installed peak (IP) and descending front of a peak (DF).
As a pass-by event is defined when the sound level is above L Amax -10 dB(A), a specific Matlab routine has been developed in order to allocate the different activities (and especially the reading task) to the different clusters of peak dynamic:  (1)  The rising front of the peak (RF) is defined as the first time step when the noise levels exceed L Amax -10 dB(A) for at least 50% of an activity duration; (2) The next following time steps are counted as Installed peak (IP) as long as the noise levels exceed L Amax -10 dB(A) for 100% of an activity duration; (3) The first time step not counted as IP is counted as descending front of the peak (DF) if noise levels exceed L Amax -10 dB(A) for at least 50% of an activity duration; (4) All the time steps that are not clustered in the three previous categories are associated to the background noise (Bck), except if at least 50% of an activity duration is realized after the end of a sound sequence.
Reading disturbance explained by personal and sound sequence factors Multi-level analyses were carried out to explain and quantify the variance of the reading disturbance data (Tab. 5) at the individual and at the sound sequence levels using the package "lme4" of the R statistical software  [40]. Personal data were included in the models as fixed continuous factors, taking the scores of the preliminary questionnaire (Sect. 2. 4) for noise sensitivity and taking the mean reading time per line (Sect. 3. 1. 1) for the reading slowness. Sound sequence parameters correspond to the acoustic indicators L 90 , L Aeq and Emergence (Tab. 1) and the (NoP) factor. In order to respect the assumption of normal distribution of the residuals, two participants were excluded from this analysis. They do not react as the others for the reading disturbance, rating all the sound sequences with constant assessments (around "1") although they are the two slowest readers.
22  [26]  applied to polish the assembly using Illumina reads, including three iterations. Tablet v1. 21. 02. 08  [27]  was used to visually check the distance between forward and reverse reads across the start and end positions of the linearised chromosome to confirm the genomes' circular nature. Prokka v1. 13  [28]  and BLAST2GO  [29]  were used to predict coding sequences (CDS), tRNA, rRNA and tmRNA. The general feature format (. gff) files obtained by the two programmes were merged to build a complete. gff annotation file. The PHASTER server (https://phaster. ca/) [30]  was used to identify and annotate prophage sequences. plasmidFinder server v2. 1 (https://cge. cbs. dtu. dk/services/PlasmidFinder/) [31]  was used to search for plasmid sequence data in the genomes against the replicon database.
BWA-MEM  [32]  with default settings was used to map Illumina reads of each albatross isolate against the A18Y020d closed genome, and the mpileup command in SAMtools v1. 13  [33]  was used to generate summary text files of coverages across the reference genome. The pileup2snp command in Varscan v2. 4. 4  [34]  was used to generate a list of high-quality single nucleotide polymorphisms (SNPs) that were filtered by applying parameters '--min-coverage' of 10, '--minvar-freq' of 0. 8 and '--min-avg-qual' of 20. A custom R script was developed to generate a multi-fasta alignment file based on concatenated SNPs. Roary v3. 12. 0  [35] , with default parameters setting, was used to construct a core gene alignment for a wider phylogenetic analysis, i. e. to place the albatross isolates within the context of global Erysipelothrix spp.
The SNP alignment and core gene alignment files were used to estimate phylogenetic trees for the 16 albatross isolates and the full set of 6 Erysipelothrix spp. genomes, respectively, using RAxML v8. 2. 4  [40]  with Maximum-Likelihood (ML) method implementing a GTR-GAMMA nucleotide substitution model, selected after using MrModeltest v2. 4  [41]. To determine the relatedness of the albatross isolates from this study with other less welldescribed Erysipelothrix species available in the Genome Taxonomy Database (https://gtdb. ecogenomic. org/), a separate phylogenetic tree based on the rpoB gene (beta subunit of RNA polymerase) was estimated. This gene has been found to be a more suitable marker for Erysipelothrix species delineation than the widely used 16S rRNA gene  [37]. Nucleotide sequences of rpoB genes were extracted from whole-genome assemblies of representative samples (one per species, n = 16 total), and aligned using L-INS-i method as implemented in MAFFT v7.
genomes, which shares its most recent common ancestor with E. rhusiopathiae. Based on the rpoB gene phylogeny, other Erysipelothrix species discovered to date are more phylogenetically distant (Figure  S4 ), with the exception of the recently deposited sequence for Erysipelothrix sp. Poltava; based on rpoB analysis, ANI/dDDH (Figure  S5 ) and phylogenomic analyses (Figure  S6 ), strain Poltava is concluded to belong to E. rhusiopathiae Clade 2. Indian yellow-nosed albatross chicks on Amsterdam Island (red text) were compared with other representative Erysipelothrix genomes. The tree was estimated in RAxML using a multiple sequence alignment of conserved (core) genes identified using Roary, implementing a GTR-GAMMA model, and visualised using FigTree (http://tree. bio. ed. ac. uk/software/figtree/).
The type strain, A18Y020d T , was isolated from an Indian yellow-nosed albatross chick carcass on Amsterdam Island. The whole genome of the type strain A18Y020d is available in GenBank (GCA_940143175). support agents at Ceva Biovac for help with laboratory work. This paper is a contribution of IPEV project ECOPATH-1151 to the Plan National d'Action Albatros d'Amsterdam.
Funding information MM was supported by an  Academy of Medical Sciences Springboard  award, with contribution from the  Wellcome Trust  and  Global Challenges Research Fund  ( SBF005\1023 , to TLF). JT received support from  CEVA  and  ANRT  for a CIFRE PhD fellowship and project France relance TVACALBA. AG was supported by the  US National Science Foundation  ( DEB-1557022 ) and the  Strategic Environmental Research and Development Program  ( RC2635 ). TLF was supported by a  Biotechnology and Biological Sciences Research Council   Discovery Fellowship  ( BB/R012075/1 ). The research was also supported by the  French Polar Institute  ( IPEV ECOPATH-1151 ),  ANR ECOPATHS  ( ANR-21-CE35-0016 ),  Zone Atelier Antarctique et Terres Australes (ZATA)  and  OSU OREME ECOPOP. The funders had no role in study design, data collection and analysis, or preparation of the manuscript.
Information retrieval (IR) is one of the most important research and development areas due to the explosion of digital data and the need of accessing relevant information from huge corpora. Although IR systems function well for technologically advanced languages such as English, this is not the case for morphologically complex, under-resourced and less-studied languages such as Amharic. Amharic is a Semitic language characterized by a complex morphology where thousands of words are generated from a single root form through inflection and derivation. This has made the development of Amharic natural language processing (NLP) tools a challenging task. Amharic adhoc retrieval also faces challenges due to scarcity of linguistic resources, tools and standard evaluation corpora. In this research work, we investigate the impact of morphological features on the representation of Amharic documents and queries for adhoc retrieval.