dataesr/scientific-paragraphs-categorization huggingface dataset:
Compared with the three other LAI software packages, its diploid accuracy is the smallest with values of diploid accuracy ranging from 42% to 57% (supplementary fig. S3 , Supplementary Material online). The fact that haplotypes used for LAI are not exact but can be computationally phased using Beagle causes the severe reduction of diploid accuracy obtained with HAPMIX (supplementary fig. S4 , Supplementary Material online). When considering haplotypes reconstructed with Beagle instead of true haplotypes, diploid accuracy is reduced by 32% on an average. Additionally, we compare diploid accuracy of Loter, RFMix, and LAMP-LD on data simulated under a three-way admixture model (supplementary fig. S5 , Supplementary Material online). As for two-way admixture model, we find that RFMix and LAMP-LD have larger diploid accuracies than Loter for recent admixture and smaller ones for ancient admixture.
Simulated Populus Admixed Individuals We simulate individuals that result from admixture between Populus trichocarpa, which is adapted to relatively humid, moist, and mild conditions west of the Rocky Mountains and Populus balsamifera, which is a boreal species  (Suarez-Gonzalez et al. 2016). As for human data, we compare Loter, RFMix, and LAMP-LD using diploid accuracy as a criterion for comparison. Again, the diploid accuracy of RFMix decreases with increasing admixture time. It ranges from a diploid accuracy of 92. 0% when admixture occurs five generations ago Loter: A Software Package to Infer Local Ancestry. doi:10. 1093/molbev/msy126 MBE to a diploid accuracy of 65. 3% when admixture occurs 500 generations (fig. 5 ). By contrast to the simulations of human data, we find that the diploid accuracy of Loter and of LAMP-LD does not change with admixture time.
Discussion As dense genotype or sequencing data become more affordable, local ancestry inference provides an opportunity for admixture mapping and for deciphering admixture processes as well. We have introduced the software package Loter in order to make local ancestry available for a wide range of species for which biological parameters such as admixture times or recombination rates are not available. The regularization parameter k, which controls smoothing, depends in a complicated manner on several biological and statistical parameters including mutation and recombination rates. To avoid the difficult choice of the regularization parameter, Loter implements an averaging procedure where we average solutions for different values of the regularization parameter. Thanks to an appropriate model averaging strategy, Loter does not require parameter tuning which makes it easy to use.
MBE Compared with other HMM formulations of local ancestries, Loter formulation is more parsimonious because it involves a single regularization parameter  (Scheet and Stephens 2006; Baran et al. 2012 ). In addition to local ancestry reconstruction, dynamic programming has also been used to partition chromosomes into haplotype blocks, which correspond to discrete blocks of limited haplotype diversity  (Zhang et al. 2002; Kimmel et al. 2003). We compared Loter to the local ancestry software packages HAPMIX, RFMIX, and LAMP-LD. We found that the diploid accuracy obtained with HAPMIX is reduced by 32% in average when haplotypes are not known perfectly using trio-phasing but only reconstructed using phasing software such as Beagle. By contrast, RFMIX, LAMP-LD, and Loter are robust to imperfect haplotype reconstruction, which explains why only RFMIX, LAMP-LD, and Loter were further considered in software comparisons.
When admixture took place five generations ago, RFMIX and LAMP-LD provide the largest diploid accuracies but all three software were found to provide an accurate reconstruction of local ancestry with diploid accuracies always >99% for the simulations of Afro-American admixed haplotypes and >89. 9% for the simulations of Populus individuals. Compared with RFMIX and LAMP-LD, results obtained with Loter are more robust with respect to the time since admixture occurred. For simulated human data, the diploid accuracy of Loter decreases to 87% for the most ancient admixture times of 500 generations whereas it decreases to 72% and 81% when using RFMIX and LAMP-LD. For Populus data, diploid accuracy does not depend on admixture times when using Loter and LAMP-LD whereas it is severely impacted when using RFMIX.
The fact that diploid accuracy is not impacted by the considered range of admixture times is encouraging and suggests that local ancestry inference is possible for admixture that occurred hundreds of generation ago when SNP density is large enough, as for Populus data; the mean distance between two SNPs being of 9. 8. 10 À6 cM for Populus data and of 2. 7. 10 À3 cM for the human data. A large enough genetic differentiation between parental populations is another explanation about why LAI can be accurate for Populus even for ancient admixture events; mean F ST between Populus balsamifera and Populus trichocarpa is equal to 0. 22 (A. Geraldes, personal communication) whereas it is only of 0. 14 when comparing CEU and YRI populations  (Bhatia et al. 2013). Diploid accuracy may be impacted by admixture time and explanations may be related to the smoothing procedure of the different software.
For instance, RFMIX has been tuned to genotypes resulting from recent admixture that occurred 10 FIG. 6. Distribution of the length of ancestry chunks for simulated data. For Populus data, we consider the first 500, 000 SNPs of chromosome 6 and for human data, we consider the first 50, 000 SNPs of chromosome 1. When considering Populus data, we run 10 times LAMP-LD on nonoverlapping sets of SNPs in order to avoid the limitation of 50, 000 SNPs of LAMP-LD. FIG. 7. Distribution of the length of Populus balsamifera ancestry tracts. The data consist of genotypes of admixed individuals between P. balsamifera and P. trichocarpa. For the simulations, we replicate the same pipeline as for local inference with real data, which consist of using Beagle to phase genotypes and Loter to reconstruct ancestry tracts.
Loter: A Software Package to Infer Local Ancestry. doi:10. 1093/molbev/msy126 MBE generations ago or less such as admixture between African and Europeans  (Gravel 2012; Bryc et al. 2015). When using default parameters of RFMIX for data resulting from ancient admixture events, reconstructed ancestry tracts are inadequately long (fig. 6  and supplementary fig. S6 , Supplementary Material online) and oversmoothing can affect diploid accuracy. Even providing true admixture time to RFMIX, diploid accuracy of RFMIX remains more impacted by admixture time possibly because of the default of 0. 2 cM for window size (supplementary fig. S7 , Supplementary Material online). When using HAPMIX, a choice of window lengths or of the time since admixture should also be provided. However, choice of admixture time can be very difficult to estimate and impacts biological results.
For instance, lengths of ancestry tracts found with HAPMIX depend on the input value for admixture time  (Patin et al. 2014). The model averaging procedure implemented in Loter has the advantage to avoid putting a strong prior on a particular length of ancestry tract. In addition, model averaging improves parameter inference, which has already been observed when phasing genotypes using a statistical model of Linkage Disequilibrium  (Scheet and Stephens 2006). The simulation results show that accuracy obtained with Loter and LAMP-LD is less sensitive to admixture times compared with the accuracy obtained with RFMix. LAMP-LD is more accurate that Loter for recent admixture times when using human data and for all values of admixture times when considering the Populus data. However, LAMP-LD has limitations for large-scale NGS data that contains a large number of molecular markers.
Its current implementation has a memory allocation limit of 50, 000 SNPs and the software can be computer intensive. To perform local ancestry inference for 500, 000 SNPs and 20 admixed Populus individuals, we compare the running time of the three LAI software using two multicore Intel Xeon E5645 2. 40 GhZ processors (6 cores each); the running time is of 28 minutes using RFMIX, of 58 minutes with LAMP-LD and of 6 minutes using Loter. This small running time shows that Loter can handle massive genomic data set using a desktop or laptop computer. However, although there are differences between LAI software packages, using different LAI software packages can be a wise strategy to provide enhanced evidence for an association or a selection signal  (Zhou et al. 2016). We expect that providing a parameter-free and rapid software for local ancestry inference will make more accessible genomic studies about admixture processes.
Accounting for Phase Errors of Admixed Genotypes Reconstructed haplotypes from an admixed population may contain switch errors  (Pasaniuc et al. 2009; Browning and Browning 2011). As considered in RFMix, it is possible to redistribute ancestry chunks among the two haplotypes from the same individual in order to correct for switch errors. For now, the software Loter accounts for phase error when there are two ancestral populations only. Once local ancestry values for each of the two haplotypes have been found after solving equation (1), we compute the sum of the two haplotypic local ancestries resulting in diploid local ancestry values d ¼ ðd 1 ;. ; d p Þ 2 f0; 1; 2g p as returned by the software HAPMIX. Local ancestry values are then reconstructed using an internal ancestry phasing algorithm.
Acknowledgments Authors acknowledge Grenoble Alpes Data Institute, supported by the  French National Research Agency  under the " Investissements d'avenir" program  ( ANR-15-IDEX-02 ), the  LabEx PERSYVAL-Lab  ( ANR-11-LABX-0025-01 ), the  MACARON  project ( ANR-14-CE23-0003 ), and the  FROGH  project ( ANR-16-CE12-0033 ). JM is also supported by a grant from the  European Research Council  ( SOLARIS  project, number  714381 ).
The article is structured as follows. Section 2 presents related work. Section 3 shows, through an example project, how OpenAPI is usually used in the industry. Section 4 defines extensions to the OpenAPI 3. 0 specification. Section 5 improves the meta-model presented in  (Sferruzza et al. 2018). Section 6 presents a new process to use these extensions in 3 https://gitlab. startup-palace. com/research/swsg SWSG and automatically generate web services from an OpenAPI model. Section 7 re-runs the example in Section 3 using the newly introduced tools. Finally, Section 8 concludes the article with some lessons and future work.
To ease the development of these tools, official examples of OpenAPI models are shipped with the specification. In this article, we focus on the Petstore example 8. It describes a simple application that exposes 4 services to list, show, add and remove data records representing animals. We assume that we are in the context of a company such as Startup Palace; that means the goal is to develop these web services in order for them to be consumed by user interface applications; for example, desktop and mobile applications for the owner of the store. The common top-down development process follows. First, developers make several iterations on writing an OpenAPI model. This model must match the functional specifications and describe web services that are fully exploitable by consumer applications.
EXTENDING OpenAPI 3. 0 The OpenAPI Specification describes a meta-model to express an interface to web services. Therefore, it does not describe how web services are implemented. To make our approach possible, we propose a way to merge OpenAPI with our meta-model of web services introduced in  (Sferruzza et al. 2018). To preserve tools compatibility we make use of Specification Extensions, as defined in OpenAPI 3. 0. 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. In  (Sferruzza 2018)  we present our extensions to OpenAPI 3. 0. The following paragraphs discuss the nature 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.
Therefore our prototype might return errors when working with some OpenAPI models that contain unsupported types or references in schemas. Code Generation. The process defined by Figure  2  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 17 with the Laravel web framework 18 , which is a common tool stack. 17 https://php. net/ 18 https://laravel. com/ Code generation is very similar to the one presented in  (Sferruzza et al. 2018). The generated code is not meant to be manually edited, but can be easily integrated in a manually-developed Laravel application.
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 3. Implementations are written for every atomic components. Listing 4 shows the implementation of the GetPetById component as an example 19. /pets/{id}: get: x-swsg-ci: component: FindPet Listing 2: Instantiating a Component from a Service. We get a PreconditionError when we run SWSG on these inputs. This verification error indicates that a component's precondition is not fulfilled in a given instantiation context. In the current case, we learn that the GetPetById misses a string named id when instantiated by the FindPet component in the GET /pet/{id} service.
components: x-swsg-cc: -name: FindPet components: -component: GetPetById -component: RenderPet x-swsg-ac: -name: RenderPet pre: -name: pet type: entity: Pet -name: GetPetById pre: -name: id type: String add: -name: pet type: entity: Pet Listing 3: Components in the SWSG Petstore Example. SWSG can prevent us to make: because they are reported very early at compile-time, instead of runtime which is too late. Developers can study the problem and decide if they have to build a better implementation or if the process model was badly designed. With the contributions of this article, the decision can even escalate to whether the OpenAPI design has flaws or not, because SWSG guarantes that the process model and the implementations are aligned with the OpenAPI model altogether. The model and code of this case study are available in the repository of SWSG 20.
This dataset offers a good opportunity to test different methods for selecting surrogate species because: i) refined habitat and graph models are already available for fourteen species, and ii) species have been selected carefully to reflect the diversity of habitat requirements and movement abilities of the local forest fauna. To test how the selection of surrogate species affects prioritization outcomes, we ran new prioritization schemes for the same case study using either an indirect approach (based on unspecified forest habitat) or a species-based approach with fewer species (N = 1, 3, 5, 7, or 9). Species were selected from the reference set using six different common methods: (i) each species alternately, (ii) based on their taxonomy (supposedly different traits and life-history), (iii) based on their potential as an umbrella species (large spatial requirements), or (iv) based on their diversity of habitat needs, (v) movement abilities, or (vi) both combined.
Habitat quality and connectivity metrics Maps of habitat quality were developed for each selected species, based on a literature review and using raw data from multiple sources (e. g. Quebec ministries of energy and natural resources, and forests, wildlife and parks). Baseline habitat-quality maps were obtained from a customized 8-class land-cover map at a resolution of 30 × 30 m. These baseline maps were then modified to further account for landscape composition (e. g. forest attributes) and configuration (e. g. forest edge, distance to wetlands). Maps of habitat patches were derived from habitat-quality maps by forming groups of habitat pixels that were large enough (area > minimum patch area) and close enough (distance < gap size) to be used by a particular species (Table  B1 ). Species-specific 5-class maps (2 n -scale from 1 to 32) of movement resistance were developed in the non-habitat pixels to quantify the degree to which pixels in the matrix limit inter-patch movement relative to habitat  (Adriaensen et al.
In addition, given that the reference species set has already been selected to reflect contrasting habitat needs and movement abilities, it is expected it also reflects the needs of the many other vertebrate species within the regional species pool (see Fig. M1. 1 in  Albert et al. , 2017). A major limitation of this dataset is, however, that -like many sets of surrogate species -it contains only vertebrates due to a lack of good data for other taxa from the study area; better data is required to assess how effective our schemes are for plants and insects, for instance. In addition, we focused here only on forest (and treed-wetland) biodiversity, making a full regional assessment of regional connectivity for all ecosystem types (open areas, aquatic habitats) would require additional surrogates and would lead to stronger conservation trade-offs  (Breckheimer et al.
Acknowledgments This research was funded by the  Mediterranean Institute of Biodiversity and Ecology  (PPM team). Computations were performed using the computing platform " Cluster de calcul intensif HPC " of the  OSU Institut Pythéas (Aix-Marseille Université, INSU-CNRS ). We thank  M. Libes  and  C. Yohia , from the  Service Informatique de Pythéas (SIP) , for their technical assistance. We thank  A. Millon ,  B. Rayfield , and  M. Dumitru  for their help and comments on earlier phases of this work. This work contributes to the  Agence Nationale de la Recherche (ANR)  (number  ANR-11-LABX-0061 ) funded by the  French government  through the  A * MIDEX project  (number  ANR-11-IDEX-0001-02 ). AG is supported by the  Liber Ero Chair in Biodiversity Conservation.
Intervention In the current study, the intervention will involve patients and their caregivers, and the main actors involved in the deployment of the m-RESIST solution will be a psychiatrist, a psychologist and a case manager. The key aim of the intervention delivered by the m-RESIST solution is to engage patients with TRS, together with their caregivers, in an active participation in therapeutic processes, and empower them to enable the self-management of their condition. To achieve this objective, the intervention is supported by three mHealth tools: a wearable (smartwatch), a mobile app and a web-based platform (see figure  1 ). Patient compliance will be measured by the number of days that the m-RESIST was used during the 3 months of intervention. Data for usage will be captured automatically by the m-RESIST software.
The functionality of the smartphone is based on the m-RESIST app. Through this app, patients will have access to educational content about TRS condition and related issues; track their early warning signs (EWSs), symptoms and biological variables; ask for help by questionnaires or the 'alarm bottom'; receive and practice helpful CBT-based Some patients may be considered pseudo-resistant to treatment. 22 In this case, presence of active symptoms may be influenced by psychiatric and medical conditions such as social isolation, consumption of toxic substances, presence of nutritional and medical problems, inappropriate health habits which may substantially contribute to poor responses or insufficient effects of medication. Data regarding these conditions will be collected. Patients having at least two failed adequate trials with different antipsychotics (at chlorpromazine-equivalent doses of ≥600 mg/day for ≥6 consecutive weeks) as well as scores of ≥4 on the Clinical Global Impression-Severity (CGI-SCH) and ≤50 on the Global Assessment of Functioning (GAF) scales OR patients with clozapine ongoing treatment due to meeting treatment-resistant criteria as well as scores of ≥4 on the CGI-SCH and ≤50 on the GAF scale.
*Operational definition of treatment-resistant schizophrenia, modified from Suzuki and colleagues. Open access coping strategies and exchange messages with their caregiver or healthcare provider. The wearable is a smartwatch that will collect data from patients and send it wirelessly to the smartphone. Sensor data will be recorded through automatic passive upload. The variables collected will be level of activity, heart rate, sleeping pattern and steps counter. The web-based platform is the tool that the healthcare providers (case manager, psychiatrist and psychologist) will use to collect assessment data, to monitor patients' state and review data collected by sensors, to communicate by texting with patients, caregivers and other professionals, and to consult recommendations (based on guidelines and experts' opinion).
Each variable is composed of a series of Likert-type items (seven levels, from 'totally disagree' to 'totally agree'). Data will be collected at the end of the intervention (V7). ► Usability: two instruments will be used, User Experience Questionnaire and Interval Question. The User Experience Questionnaire will be delivered by online data collection (Qualtrics software) and is composed of a combination of survey questions (4-point Likerttype scale) and open questions. The survey will explore perceived ease of use, perceived usefulness, attitude and perceived quality of content. The open questions will explore lasting impressions and recommendations. The participants will be asked to complete the questionnaire on three occasions during the 3-month intervention: at the start (V0), in the middle (V3) and at the end of the intervention (V7).
Secondary outcomes A complete clinical and economic evaluation would be premature in this feasibility study, due to the small sample. However, it will be useful to collect necessary parameters for planning a full prospective RCT to test the cost-effectiveness of m-RESIST solution. Completion rates and missing data will be explored. Operational criteria definition for missing data: <10% of each set of secondary outcomes is missed during study data collection. The measures for clinical, functional, quality of life and economic outcomes are the following: Clinical outcomes ► Severity of symptoms will be assessed using the instruments Positive and Negative Syndrome Scale (PANSS),  29  Calgary Depression Scale (CDS)  30  and Clinical Global Impression-Schizophrenia (CGI-SCH). 31 PANSS and CDS will be completed on two occasions, at the start (V0) and at the end (V7) of the intervention.
Patients will be asked to wear the smartwatch for a period of at least 15 days, in order to collect enough sensor data to establish the baseline sensor profile. Furthermore, patients and caregivers will also be encouraged to use and familiarise themselves with the app by consulting the educational content and using the messaging system. Patients will also attend a clinical assessment, where secondary outcomes will be collected (see table  3 ). At the end of the preintervention period, the key elements (relapse signature and treatment plan) to deliver a tailored intervention will be explored. 3. Intervention period (V1-V7) aimed at testing the features and action flows that configure the m-RESIST interventions, and at assessing the experience of participants. At the beginning of the intervention, the treatment plan will be defined and the corresponding basal intervention will be activated.