dataesr/scientific-paragraphs-categorization huggingface dataset:
Extending OpenAPI 3. 0 Recall that the OpenAPI Specification describes a meta-model to express an interface to web services. But, unlike our approach, it does not describe how web services are implemented. To get the best of both our approach and OpenAPI's, we propose a way to merge the latter with our meta-model of web services. To preserve tools compatibility we make use of Specification Extensions, as defined in OpenAPI 3. 0  [11]. This mechanism allows to add data to models without breaking their compliance to the specification or their ability to be used by tools designed to be compatible with it. The details of the extensions to OpenAPI 3. 0 can be found in  [20]. The following paragraphs present the nature and the main lines of these extensions for each aspect of our meta-model. Because an OpenAPI model can be seen as a tree (before references are resolved) that has the OpenAPI object as root, we make use of the notion of paths.
A Tool to Generate Consistent Web Services To support the approach of automatically building web services from an extended OpenAPI model (see Section 5), we propose a tool named Safe Web Services Generator (SWSG)  [19]  that automates both consistency verification (see Section 4) and code generation. This tool takes two inputs: a model file (both extended OpenAPI models and our own concrete syntax are supported), and a path to a directory which contains implementations of atomic components. As shown in Figure  3 , our tool follows four sequential steps: 1. Model parsing Input model is parsed as concrete syntax of the meta-model (see  Section 3. 3)  or as an extended OpenAPI model (see  [20] ).
Code generation The model and the implementations of atomic components are used to generate an implementation of the web services they represent. 13 Their paths are components > x-swsg-ac and components > x-swsg-cc. 14 In the x-swsg-ci property of the service. 15 In a x-swsg-name property. Fig. 3. SWSG process Model transformation. Transforming extended OpenAPI models to SWSG models is quite straightforward, except for schemas/types. OpenAPI defines some primitive types and relies on a modified version of the JSON Schema Specification  [9]  for complex types. There are two issues; first, the JSON Schema Specification is more expressive than SWSG's type system. For example, it allows to define refined types, e. g. to add a minimum length to a string. Second, it supports both literal and referenced definition of attribute types.
This composite component has two children that are atomic components. The first takes an ID as input, uses it to query the database and adds the Pet result to the context. The second takes a Pet, serializes it in JSON and put it in an HTTP response. These three components are defined in Listing 5. Implementations are written for every atomic components. Listing 6 shows the implementation of the GetPetById component as an example 16. Step 3: we run SWSG on these inputs and get a PreconditionError. This verification error indicates that a component's precondition is not fulfilled in a given instanciation context. In the current case, we learn that the GetPetById component misses a string named id when instanciated by the FindPet component in the GET /pet/{id} service. Indeed, we voluntarily introduced an error in Listing 5: the GetPetById component is given an integer (by the service) whereas it requires a string.
In this particular example, it should require an integer id variable in order to be consistent with the service parameter. Nevertheless, in more complex projects, this component might have been used inside several other composite components and services. Thus, it might not be a good solution to just change the component's definition because it might break other When running SWSG on a fixed model, the code generation can proceed. The Laravel code generator generates four kinds of files: one file per atomic components (identical to those written manually by the developers; see Listing 6), one file per composite components, a router file and several static files (that do not depend on the model; for example the Component interface definition). Case study #2. After it was successfuly implemented, we want to extend the Petstore example and add a new service to handle PUT /pets/{id} requests.
When instanciated for the POST service, createOnly is given the value true, whereas it is false when the same component is instanciated from the PUT service. Then, the implementation of this atomic component is modified so that it adds or updates pets depending on the value of the createOnly parameter and the one of the id context variable. Listing 7 shows how the new service instantiates a composite component (defined in Listing 8) that in turn calls the CreateOrUpdatePet and passes it the right value for its createOnly parameter. Step 3: we run SWSG. Discussion. Our approach has several advantages over a regular development process, for example writing the whole application using a programming language and a web framework such as Laravel. First, the model-driven approach forces developers to think of their design or design evolutions at a macroscopic scale before writing low-level implementations.
Along with the automatic model verification, this provides them an easy way to spot design mistakes early-on in the process, therefore saving some of their time. In a regular process, developers could only rely on the quality tools offered by the language or the framework. Because there is no static verification step in PHP, for example, and because lots of developers do not write any automated tests, they would often be tempted to skip checking the consistency of their design, especially when making small evolutions on it. Second, because the extended OpenAPI model is used to generate both implementation and documentation, both will stay aligned during the life of the project. In a regular process, this property relies on the will of the developers; they might stop maintaining the OpenAPI model and still make evolutions to the implementation.
Conclusion We proposed a method integrated to OpenAPI 3. 0 to build web services. It is fast, simple, robust and flexible. It is based on a meta-model that allows developers to define implementations of web services, starting from the corresponding high-level contract as expressed by a standard OpenAPI model. Consistency of models can be verified using an operational semantics so that code generated from these models is safe. We built a tool, SWSG, that leverages this process in the technological context of a web company, Startup Palace. The whole approach was illustrated on a two-steps case study to show its advantages. Even if one of the motivations was to develop MVPs applications, the approach is not limited to this scope and is suitable to most applications based on web services. We have several main prospects.
Code generation. The process defined by Figure  3  is generic: it does not rely on a specific language or technology. Yet the language and technologies used to implement atomic components must be identical or compatible with those of the code generation target. Because we experiment in Startup Palace's context, our prototype targets the PHP programming language  [25]  with the Laravel web framework  [13] , which is a common tool stack. Many similar tools (see Section 2) take the approach to generate and output a standalone web application that includes everything necessary to operate it. We took another approach by generating code that should never be manually edited; the generated code does not override any existing files in a Laravel 's architecture and can be easily hooked to an existing web application through configuration.
DNA extraction, genome sequencing and assembly For each isolate, a monospore isolation was performed (Text S1 for details). DNA was extracted from mycelium grown on PDA overlaid with cellophane following  Hoegger et al. (2000). Eighteen isolates were sequenced using the PGM/Proton Ion Torrent sequencer (Thermo Fisher scientific Inc. ) at the platform Genome-transcriptome of Bordeaux (Inra-Université Bordeaux, Bordeaux, France). The 32 other isolates, including one isolate (ABI005) previously sequenced with the PGM technology, were sequenced using Illumina HiSeq2000 technology in paired-end at the Genome and transcriptome GenoToul facilities detection was performed, using the REPET software  (Jamilloux et al. , 2017). REPET uses two pipelines: first, TEdenovo  (Flutre et al. , 2011) , which build a TE consensus library, and second, TEannot  (Quesneville et al.
Mapping and SNP calling After mapping the 46 sequenced genomes on the new masked reference genome using glint software, SNP calling was performed using varscan v2. 3. 7  (Koboldt et al. , 2009 (Koboldt et al. , , 2012) )  with parameters set as follows: minimum coverage 15 reads, minimum length of the high scoring pair (hsp) ≥90, number of mismatches ≤5, no gap allowed, and only best-scoring hits taken into account. Alternative variants were kept if they were present on a minimum of ten reads and at least once on each of the two strands. Sites with heterozygous SNPs (i. e. , alternative variant frequency estimated between 0. 25 and 0. 75 for one isolate; C. parasitica monospore isolates sequenced here are haploid), insertion-deletion sites and non bi-allelic SNPs were removed from the dataset.
Levels of polymorphism, genealogical relationships, clustering and linkage disequilibrium between isolates of C. parasitica in France Based on the filtered SNP dataset, VCFTOOLS  (Danecek et al. , 2011)  were used to estimate nucleotide diversity (π) and SNP density, on a non-overlaping sliding window counting 10,000 nucleotides along the genome. Nucleotide diversity was plotted using R-cran package 'qqplot'  (Turner 2014). Pairwise linkage disequilibrium (LD) between SNPs was estimated using VCFTOOLS LD statistics after keeping one single isolate of each clonal lineage with the best coverage. Tajima's D was tested on SNPs alignments for different sub-populations and seven clonal lineages using DnaSP v5  (Librado & Rozas, 2009). We estimated the genealogical relationships between sequenced isolates using the neighbornet algorithm implemented in SplitsTree4  (Huson and Bryant 2006)  with the uncorrected P distance (i.
e. , in our case the proportion of sites at which two sequences differ compared to all the polymorphic sites of the filtered dataset). This phylogenetic network method is used to identify recombination events among haplotypes, incomplete lineages sorting, or homoplasic mutations  (Bryant and Moulton 2003). Population structure was estimated using BAPS Version 6  (Corander et al. , 2008) , a Bayesian method for identifying the most likely number of sub-populations (k number of clusters) in a given population by comparing the allele frequencies among all the polymorphic sites among sub-populations and the whole population. To increase the resolution and to get the substructure, which is hard to detect because of strongly divergent lineages, we used BAPS through a hierarchical clustering process  (Cheng et al.
, 2013). The largest cluster obtained from the first analysis of the whole dataset was used as input for the second analysis. We obtained the best K value describing these two datasets. From this, we used the fixed k option in BAPS with default parameters to perform four independent runs (K = 2,3,4,5) on the whole dataset and five runs (K = 2,3,4,5,6) on the largest cluster. Genealogies used for the recombination detection and BEAST analysis were estimated using RAxML  (Stamatakis 2014)  with the New rapid hill-climbing algorithm [-f d]; the Generalized Time-Reversible (GTR) substitution model with gamma site heterogeneity model; and other parameters to the default values. Using jmodeltest2, the GTR substitution model was chosen as the most suitable among others for our data  (Darriba et al.
Identification of the different haplotypes among the French clonal lineages We designed a pipeline combining BCFtools, VCFtools and R software (R Development Core  Team, 2008)  to identify and compare the haplotypic sequences along the genome of the seven southern French clonal lineages and the northern emergent genotype H13. For each of these lineages, we chose one reference isolate for which no recent recombination had been detected with the three methods described above. For the RE092 lineage, the most diverse lineage of this study (see results), we chose three reference isolates (VG_1896, STC36 and YVO006). Using VCFtools and per 10kb window along the genome alignment, we extracted a set of variants between each pair of ten reference isolates and all singeltons were removed. The historical isolate VG_1896, the oldest of this study (sampled in 1968), was used as the reference haplotype.
Mapping and SNP calling All the 46 genome sequences from both sequencing technologies were mapped on the new PacBio reference genome with a coverage of 41. 0 to 187. 8X (mean = 100. 5; Table  S1  for details). We identified 118,182 SNPs using the Varscan method. Only three SNPs were detected between the Illumina and the Ion Torrent sequences of the ABI005 isolate after filtering, without considering missing data. This comparison suggests that the two sequencing technologies produced a similar set of SNPs after filtering. Finally, we kept a dataset of 46 isolates with 38,592 SNPs (i. e. , average 1SNPs per kb), and focused on the 26 scaffolds longer than 100kb. Most of the discarded SNPs were present within TEs and incompletely covered regions, while only 44. 0% of SNPs were discarded in the genes (some genes are in fact TEs) compared to 67.
05) for nearly all the clonal lineages and sub-populations considered (Table  1 ), except for RE019 with D=-1. 766 (P<0. 001) indicating an excess of rare alleles. A high linkage disequilibrium (LD) was estimated between pairs of SNPs separated by 1kb in the NA (North American isolates) and FNA (French isolates from North American genetic pool) subsets (r 2 =0. 84 ci95%=9E -3 and 0. 91 ci95%=5E -3 respectively; Fig. 3 ). At this range of genomic distances, the estimate was only 0. 54 (ci95%=9e -3 ) for the Global subset. The distances at which the LD was half decayed -a useful indicator of the importance of recombination in a population (Nieuwenhuis and James 2016) -were approximately ~3kb, ~28kb and ~400kb for the three datasets, Global, NA and FNA.
Discussion Genealogical and clustering analyses based on the filtered dataset of 38,592 SNPs confirmed that isolates belonging to six multilocus genotypes (MLGs) highly repeated within French populations are highly similar on the whole genome (H13 and RE028 excluded of this analysis due to the sequencing of only one isolate). The clonal structure may be even stronger than described by the ten microsatellite loci  (Dutech et al. , 2010; Robin et al. , 2017) , since several MLGs differing by one or two microsatellite alleles were finally considered to belong to the same clonal lineage (for example the clonal lineage H53 identical to RE079). These observed differences in microsatellite alleles are likely to have resulted from recent mutations of the repeated microsatellite motif. Within these clonal lineages -excluding the recombinant regions identified (see below) -we detected a small number of variations (between 17 and 120 different SNPs within each lineage).
Acknowledgments We thank  Donald L. Nuss  and the genome portal of the  Department of Energy (DOE) Joint Genome Institute (JGI)  for making the EP155 genome available;  Pierre Gladieux ,  Christophe Lemaire ,  Aurélien Tellier ,  Simone Prospero  and  Jean-Paul Soularue  for their numerous comments and corrections on previous versions of the manuscript;  Sophie Siguenza  for Mauve alignment of genomes; and  Erika Sallet  for gene annotations. Ion-torrent sequencing was performed at the  Genome Transcriptome Facility of Bordeaux and Illumina at the GeT-PlaGe Facility of Toulouse. This work was supported by the  ANR-12-ADAP-0009  ( Gandalf  project) and an innovative project  INRA department EFPA. A. Demené  was supported by a PhD fellowship from the  Ministère français de l'enseignement supérieur -Université de Bordeaux.
Annotation of protein-coding genes and transposable elements Francisco, California, USA) long run sequencing technology (Institute for Genomic Medicine, UCSD, CA, USA). Genome was assembled using PbcR wgs-8. 2 with the genome size specified to 45Mb, and polished using pbalign (available on https://github. com/PacificBiosciences/pbalign), Quiver and SMRT analysis v2. 3. 0 (https://github. com/PacificBiosciences/DevNet/wiki/SMRT-View) with default parameters. Contigs were ordered using Mauve v2. 4. 0 (Darling et al. , 2004), guided by the EP155 reference genome. Gene models were predicted with a fully automated and parallelized pipeline, egn-ep (http://eugene. toulouse. inra. fr/Downloads/egnep-Linux-x86_64. 1. 4. tar. gz, release 1. 2, Text S2 for details). For each of the 46 isolates, a draft genome was constructed using CLCBio with default parameters in order to blast the two mating types alleles sequences on it (MAT1-1 and MAT1-2, first described by McGuire et al.
XILforEV Architecture The proposed architecture has been originated from the following set of requirements: An overall approach to the XILforEV architecture can be explained with Figure  1. This architecture allows developing the EV subsystem controllers in a realistic environment by leveraging the use of existing facilities. In particular, MIL tools are used for full vehicle simulation in a virtual environment. The SIL technique is applied for investigations on functional reliability of embedded software applications. TRIL is represented by different test setups, which could generally include dynamometers, driving simulators, and other experimental devices. The TRIL and HIL components are connected using real-time communication (RTC). It should be noted that this architecture supposes a plug-in interface allowing flexible inclusion of different test devices depending on the development task.
Therefore real-time systems exchanged UDP messages over virtual LANs using an executing time of 1 ms. The results in Figure  4    VPN extends the VLAN to a public network and allows staying in the private network by using public networks. This technology enables users to send and receive data in a safe way through a public network, using their private network address. Another experiment was conducted with real-time systems located in Ilmenau (Germany) and Tokyo (Japan) to investigate the round-trip time of remote routes, exemplary. As shown in Figure  5 , remote routes introduce a significantly higher round-trip time. For instance, the round-trip time (RTT) between Ilmenau and Japan is about 180 ms. Such high RTTs require additional methods for compensating the delay introduced by remote routes.
040 trajectories. Trajectories were obtained using the HYSPLIT/NOAA model (https://www. ready. noaa. gov/HYSPLIT. php). Trajectory density (the number of trajectories over a 1. 5 km radius) was calculated using ArcGIS ® 10. 2 software. Light blue circles represent glaciers located in South America (data from the Randolph Glacier Inventory database  65  ), and black stars (regions I, II, III, IV, V, VI, and VII) indicate the origins of the trajectories located within regions with a higher density of fire events. in the Amazon Basin, smoke plumes may propagate through vast regions of South America, moving over the banks of the Andean Mountains, as previously detected from satellite observations in 2010  25  (Fig. 1a ). To detail this condition and to investigate where measurable impacts of fire events on ice cover do exist, we compiled all fire events occurring in the Amazon Basin from 2000 to 2016 (fire database was obtained from the Brazilian Institute of Space Research -INPE  26  ).
279°S; -68. 142°W), Bolivia, as a study area (Supplementary Material, Fig. 3 ). Our choice of the Zongo Glacier was based on the availability of longer and continuous meteorological, surface mass balance and melting water discharge data for the glacier provided by the GLACIOCLIM program (https:// glacioclim. osug. fr/) and the GREAT ICE program  29. One important point to observe is that any impacts of biomass burning on Andean ice can only be postulated if the convective rising of Amazon plumes can at least reach the altitudes of the mountain snowline. Over the Amazon Basin, previous LiDAR (Light Detection and Ranging) observations indicated that aerosol plumes during fire events can reach approximately 3. 0-5. 0 km in altitude  30. Although Zongo Glacier extends from 4. 9-6. 0 km ). The Amazon Basin on the east side of the Andean Cordillera is completely covered by smoke from biomass burning.
4 ). estimating black carbon concentrations at Zongo Glacier. Since the start of the MODIS satellite fire monitoring program in 2002, modeled emissions of BC data available at the global fire emission database (GFEDBv4) noted the 2007 and 2010 fire seasons as most critical for the Amazon Basin (Supplementary Material, Fig. 5a, b ). Therefore, to assess the potential maximum impact of BC on the Zongo Glacier, we focused on these episodes. From the above, we modeled continental BC aerosol emissions, atmospheric concentration and deposition from the HYSPLIT/NOAA model. The BC emissions used in our model were from a global fire emission database, which uses a compilation of emission factors retrieved from experiments that include the measurements of BC in the Brazilian Amazon forest during biomass burning events  32.
From our results, atmospheric BC concentrations values due to Amazonian biomass burning emissions ranged from 0 to 5. 0 × 10 -3 mg m -3 in the Central Andes (Supplementary Material, Figs  6  and 7 ), and total BC depositions on the Zongo Glacier were estimated as 0. 88 mg m -2 and 1. 17 mg m -2 during the fire seasons of 2007 and 2010, respectively (Supplementary Material, Fig. 8 ). These predictions are in agreement with the measurements of BC at the Chacaltaya station (5 km from Zongo Glacier), where atmospheric concentrations of black carbon ranging from 0. 2 to 1. 5 × 10 -3 mg m -3 were reported (database from 2012-2014)  33  and with other global aerosol models that estimate BC deposition values between 0. 5-2. 0 mg m -2 for the Andes  34. Modeled BC deposition and measured snowfall at the glacier surface were used to calculate BC concentrations in snow at the Zongo Glacier (details are presented in the methods section).
Liquid precipitation over the glacier is rare and, therefore, neglected in the model. Our estimated BC concentrations in snow were 41. 1 ppb (parts per billion) for September 2007, 73. 4 ppb for September 2010, and 29. 2 ppb at the end of the fire season in October 2010. The lowest concentration (29. 2 ppb of BC) in October 2010 was attributed to the high precipitation over the glacier during that period, which diluted the concentration accompanied by a decrease in fire events in the Amazon Basin. The high BC concentrations estimated for September each year were related to the peak in fire events in South America combined with associated low precipitation rates in the Andes. A comparison of our modeled concentrations with Illimani ice core data shows consistency. The Illimani Glacier is located approximately 55 km southeast of the Zongo Glacier, and due to its geographic proximity, it has a similar influence on the transport of particles from the Amazon Basin (from our model).