dataesr/scientific-paragraphs-categorization huggingface dataset:
Indeed, novel and appropriate containers need to be designed and integrated to IIoT PaaS. These containers should not only support the execution of such processes and manage the inter-communications between them (e. g. , common but distributed execution context for parallel process, simultaneous access to the same shared resources for concurrent processes), but they should also implement the data and control internal workflows of the industry/factory  [50]. This requires major transformation to the service containers, as well as to the communication bindings between them. The exeCution engIne for distributEd data-fLow computing (CIEL(http://www. cl. cam. ac. uk/netos/ciel/)) framework could be used as a starting point. CIEL introduces an execution engine for distributed concurrent and parallel processes  [51].
PaaS for WSNIn [34] , the authors propose Dinam Cloud, the PaaS for on-demand WSN end-user applications development, deployment, configuration and monitoring. The Dinam Cloud architecture consists of three layers, following the three service delivery layers of the cloud architecture: IaaS, PaaS and SaaS. The Dinam IaaS layer offers WSN computing resources (e. g. , processing and storage) and is formed by heterogeneous wireless sensor nodes. The Dinam SaaS includes the concrete applications that are developed based on the Dinam PaaS to integrate WSN capabilities. In the reference implementation of the Dinam architecture, these applications are accessible via REST. The Dinam PaaS facilitates WSN end-user applications provisioning and offers unified services (e. g. , storage, database and networking) to end-user applications.
4. 1. 1 PaaS for WSNIn [34] , the authors propose Dinam Cloud, the PaaS for on-demand WSN end-user applications development, deployment, configuration and monitoring. The Dinam Cloud architecture consists of three layers, following the three service delivery layers of the cloud architecture: IaaS, PaaS and SaaS. The Dinam IaaS layer offers WSN computing resources (e. g. , processing and storage) and is formed by heterogeneous wireless sensor nodes. The Dinam SaaS includes the concrete applications that are developed based on the Dinam PaaS to integrate WSN capabilities. In the reference implementation of the Dinam architecture, these applications are accessible via REST. The Dinam PaaS facilitates WSN end-user applications provisioning and offers unified services (e. g. , storage, database and networking) to end-user applications.
1. Metabarcoding studies should be carefully designed to minimize false positives and false negative occurrences. The use of internal contr ols, replicates, and several overlapping markers i s expected to improve the bioinformatics data analysis. 2. VTAM is a too l to per form all steps of data curation from raw fastq data to taxonomically assigned ASV (Amplicon Sequence Variant or simpl y variant) table. It addresses all known technical error types and includes other features rarely present in existing pipelines for validating metabarcoding data : Filtering parameters are obtained from internal control samples ; crosssample contamination and tag -jump are contr olled; technical replicates are used to ensure repeatability; it handles data obtained from several overlapping markers. 3. Two datasets were analysed by VTAM and the results were compar ed to those obtained with a pipeline based on DADA2.
Features 2. 1 Implementation VTAM is based on the method described in  Corse et al. 2017. It is a command-line application that runs on Linux, MacOS or Wi ndows Subsystem for Linux (WSL). VTAM is implemented in Python 3, using a Conda environment to ensure repeatability and easy installation of VTAM and these third -party applications: WopMars (https://wopmars. readthedocs. io ), NCBI BLAST, Vsearch  (Rognes et al. , 2016) , Cutadapt  (Martin, 2011). Data is stor ed in an SQLite database that ensures traceability. 4.
Filtering Demultiplexed reads are dereplicated and ASVs are stored in a n SQLite database. All occurrences are characteri zed by their read count. FilterLFN: eliminates occurrences likely due to Low Frequency Noise. Occurrences are filtered out if they have low read counts (i) in absolute terms (N i j k is small, where Nijk is the read count of variant i in sample j and replicate k), (ii) compared to the total number of reads of the sample -replicate (Nijk/Njk) or (iii) compared to the total number of reads of the variant ( N i j k /Ni). FilterMinReplicateNumber : Occurrences are retained only if the ASV is pre sent in at least a user -defined number of replicates. FilterPCRerror: ASVs with one difference from another ASV of the same sample are filtered out if the proportion of their read counts is below a user-defined threshold value.
Taxonomic assignation Taxonomic assignation is based on the Lowest Taxonomic Group method described in detail in Supporting Information 1. The taxonomic reference dat abase has a BLAST format with taxonomic identifiers so that custom database s or the complete NCBI nucleotide database can be used by VTAM. A custom taxonomic reference database of COI sequences mined from NCBI nucleotide and BOLD (https://www. boldsystems. org/ ) databases i s available with the pr ogram.
Benchmarking VTAM was tested wit h two published metabarcoding datasets: a fi sh dataset obtained from fish faecal samples  (Corse et al. , 2017)  , and a bat dataset obtained from bat guano samples  (Galan et al. , 2018). Both datasets included negative controls, mock samples and three PCR replicates. A fragment of the COI gene was amplified using two overlapping markers in the fish dataset, and one in the bat dataset (See details in the original studies). Both datasets were analysed by VTAM. The fish dataset was analysed separately for the two markers and the results of both markers were pooled together. Both datasets were also analysed with the DADA2 denoising algor ithm  (Callahan et al. , 2016) , one of the most widely used methods for metabarcoding data curation. The output of DADA2 was filtered by LULU  (Frøslev et al.
, 2017)  t o further eliminate probable false positive occurrences. Then the three repli cates of each sample were pooled (as in VTAM), only accepting the occurrence if it was present in at least two replicat es (Supporting inform ation 2). We compared the α-di versity and β -diversity obtained for the environmental samples to address the effect of the curation pipelines on diversity estimations. αdiversity was estimated using both ASV richness and cluster richness ( clusters aggregate ASVs with <3% divergence) , and β-diversity was summarized using the Bray-Curtis pairwise dissimilarit y index. (Supporting information 3). In the fish dataset , all expected variants in the mock samples were validated by both pipelines. However, in the bat dataset, t wo expected variants had very low read abundance (2-18 reads/replicate ), which were in the range of the number of reads in the negative controls (ten out of the 19 negative controls had at least one read count greater than 18 ).
Conclusions The VTAM metabarcoding pipeline aim s to address known technical errors during data analysis (Table  1 ) to validate metabarcoding data. It is a complete pipeline from raw FASTQ data to curated ASV table s with taxonomic assign ments. The implementation of VTAM provides several advantages such as using a Conda environment to facilitate the installation, data storage in SQLite database for traceability and the possibility to run one or several sequencing run -marker combinations using the same command. VTAM includes features rarely considered in most metabarcoding pipelines, and w e beli eve it provides a useful tool for the analysis and validation of metabarcoding data for conducting robust analyses of biodiversity. development. EM, AG , VD and EC wrote the manuscript. All authors contributed critically to the draft and approved the final version of the manuscr ipt.
Acknowledgements We thank  Diane Zarzoso -Lacoste  and  Samanta Ortuno Miguel  for valuable comments on the use of VTAM ,  Luc Giffon  and  Lionel Spinelli  for the development of Wopmars and  Kurt Villsen  for English editing. Centre de Calcul Intensif d' Aix -Marseille  is acknowledged for granting access to its high performance computing resources. This work i s a contribution to the European project  SEAMoBB , f u nded by  ERA-Net Mar -TERA  and managed by  ANR  (number  ANR_17_MART -0001_01 ).
Data Availability VTAM is available at https://github. com/aitgon/vtam. A detailed user manual is found at https://vtam. readthedocs. io. Empirical data used in this paper are available from the Dryad Digital Repository https://datadryad. org/stash/dataset/doi:10. 5061/dryad. f40v5 and https://datadryad. org/stash/dataset/doi:10. 5061/dryad. kv02g.
Thus, these have been defined as the critical loads of the system. The components sizes have been optimized by considering both economic profitability but also the resilience capacity, observing that, by installing solar photovoltaic modules, Li-ion batteries and diesel generators, according to simulations performed in REopt® software, the microgrid could save approximately $ 440,191 on average over a 20-year life cycle of the facility (both considering the mitigation of energy provide by the power grid and the avoided losses during probable power services interruptions), while increasing the minimum resilience of the installation more than 34 h.
Comparisons between different models Depending on the software to be used, a number of simulations at different scales to assess the resilience of systems (residential, regional and/or district modelling) can be conducted. As shown in Table  1 , REopt® is able to conduct simulations at all of the aforementioned levels. Performance models simulate energy efficiency with system configurations entered by the user. These models can help to plan system sizes to meet energy objectives, reduce LCOE, and minimize carbon emissions. It can be seen from Table  1 , that REopt® has a large number of possibilities that other software could not accomplish. Green cells represent the features that can be used  [25]. On the other hand, the red cells represent the features that cannot be used by the different software tools  [25].
In our case, resilience can be optimized. The other simulations, on the whole, cannot achieve this objective. As far as renewable energies are concerned, REopt® allows simulations to be carried out on a photovoltaic system, wind generators (currently with a beta version), and energy storage through batteries. From all the above, it is clear that REopt® will allow us to model the behavior of the system thus formed. It is now necessary to detail the different inputs that make up the simulation software to be used. Even though other software could have been used to conduct similar simulations and extend the assessments conducted to other locations different to the US, it has as a counterpart the fact that it is not an opensource software such as REopt® is.
Results The work which follows takes up a series of simulations carried out with the REopt® software. The objective is to evaluate the performance of the microgrid through twelve scenarios (two extreme daylight duration times, two starting times and three outage durations for each case), presented in the Materials and Methods section, with the aim to study the share from PV to feed the loads, the energy used to charge the batteries and the energy exported to the power grid. For the readers' help, Table  3  shows the relations of the eight most representative simulations with their corresponding figures. Please bear in mind that, both to reduce redundancy, improve readability and to conform to usual research papers' page limits and format, only significant results have been included and discussed.
[Matsumoto et al. 2015] ). A function is associated with its regular abstraction through a regular language type. For a given function, a regular language type annotation gives the possible regular abstractions of its result for the regular abstractions of its input. Combining those aspects leads to a fully automatic verification technique for higher-order functional programs that is particularly well suited to deal with algebraic data types. Properties are defined using predicates expressed in the functional programming language itself. The salient feature of this technique is that it does not rely on the programmer to provide any intermediate lemmas (like in proof assistants) or type annotations (like in Liquid types or F*). We successfully implemented and tested our technique on examples taken from the benchmark suite of Timbuk.
Experimental results We compared the performances of our implementation over our test suite against Timbuk 3 which is, to our knowledge, the only higher-order tree-processing program verification tool that is publicly available. In particular, we have not been able to compare to the regular-complete verification procedure presented in  [Matsumoto et al. 2015]  which does not offer a public implementation, even if it also targets regular properties. The following graphs show the time performances (averaged over 10 executions) of the two implementations over the compatible regular test instances on a Intel® i7-7600U CPU, 4 2. 80GHz cores. Positive instances (on the left) and negative instances (on the right) are separated by a dashed line. A timeout is set at 120 seconds (red line). This shows that when it succeeds, Timbuk 3 is in average faster than our implementation.
This is expected since our preliminary typing phase and subtyping phase has a cost. However this also shows that in many cases, even on first-order programs our implementation terminates where Timbuk 3 diverges. In particular this is the case for the non trivial merge-sort algorithm for which we successfully identify the regular language of sorted lists. This is also the case for binary-tree processing algorithms such as member-tree where we automatically show that it is invariant by mirroring. We see the same tendency on higher-order programs where Timbuk 3 also diverges on the merge-sort algorithm (where this time the comparison operator is a parameter of the sorting function), and on binary-tree processing programs such as map-tree, where we succeed. Interestingly, our implementation is unable to find a counter-example to a false merge-sort property, where we try to check that ∀.
It has already been successfully used in program verification with Timbuk  [Genet et al. 2018 ], but just like its model-checking counterparts at the time, with the lack of a complete invariant learning procedure. Our approach adapts this technique with actual invariant learning capabilities. Since our approach rely on the same framework, expressivity of the two approaches are close. In particular, our technique covers most of Timbuk's benchmarks but is also able to prove properties on which Timbuk fails, like the merge sort algorithm.
Methods : The study is a prospective, phase III, controlled, multicenter, and randomized, single-blind (patient) clinical trial, including RA patients with a previous failure to anti-TNF therapies. The main objective is the analysis of the clinical and pharmacoeconomic impact after 6 months of treatment. Intervention arm: Prescription of biotherapy (rituximab, adalimumab, abatacept) using SinnoTest® software, a prediction software based on proteomic biomarkers. Control arm: Prescription of biotherapy based on current practice, without the SinnoTest® software (any biotherapy). In addition, a sub study will be carried out within this trial to generate a biobank and further analyze the proteomic pro le of the patients and their modi cation throughout the study. Discussion : This clinical trial study will be the rst validation study of a biotherapy response prediction software, bringing personalized medicine into the management of RA.
This economic burden is even greater when the patient has to change his treatment for a second time. This phenomenon seems di cult to reverse in case of initial misdirection since the probability that the patient who has already received an anti-TNF to respond to another biological treatment decreases gradually according to the increasing number of failures of previous treatments  (27). We hypothesize that the SinnoTest® software, a predictive algorithm for responding to bDMARDs, offers real-world medical-economic and clinical bene ts by integrating the main biotherapies currently available. This study will target patients with RA in rotation of a rst biotherapy due to ine ciency or toxicity. This population corresponds to a very large majority of patients admitted to rheumatology consultations.
Objectives {7} The primary objective of this clinical trial is to study the clinical and pharmacoeconomic impact after 6 months of the use of the SinnoTest® predictive tool in patients with rheumatoid arthritis who have failed to a rst anti-TNF biologic agent compared to usual care. The secondary objectives will be medicaleconomic: budget impact analysis (BIA) at 6 and 12 months and clinical objectives as describe the performance of the software's predictive model on new clinical data from the 6-month trial. We will also carry out a proteomics substudy with the objectives of compare the variation of the proteomic pro le between the M0 (date of inclusion) and the M6 (end of study date). The achievement of this objective will be based on the constitution of a bio-bank, which will serve as a basis for future studies focused on the therapeutic management of these patients.
Trial design {8} This project is a prospective phase III randomized clinical trial in 2 parallel groups, multicentre, controlled (prescription of bDMARD with or without the SinnoTest® software), single-blind (the patient will not know if his bDMARD treatment has been prescribed with or without the help of SinnoTest® software). The inclusion period will be 12 months. Each patient will be followed up to 6 months (clinical evaluation) and up to 12 months (for the analysis of the budgetary impact at 12 months).
The exclusion criteria will be; Patients who do not meet the criteria below will be eligible in the study; Patients with a contraindication to a bDMARD or methotrexate: Patients included in another therapeutic evaluation trial during the trial; surgical intervention programmed during the test; Patients with di culties in understanding the Spanish language; Patients cannot be followed up at 12 months; Psychosocial instability incompatible with regular monitoring (homelessness, addictive behaviour, antecedent of psychiatric pathology or any other comorbidity that would make it impossible for free and informed consent or limit adherence to the protocol); Breastfeeding, pregnancy, although there are bDMARD that can be used in pregnancy, since SinnoTest can recommend one that discourages this condition, it is decided to exclude the inclusion of pregnant.
Intervention description {11a} The patients will be randomized to an intervention group (SinnoTest®) or a control group (placebo). Patients allocated to the intervention arm will receive the prescription of bDMARD (rituximab, adalimumab, abatacept) using SinnoTest® software. While those allocated to the control arm will receive the prescription of bDMARD without the SinnoTest® software which corresponds to current practice (all bDMARDs). Innovative procedure. Innovative Medical Device (IMD): SinnoTest® Software. SinnoTest® is a therapeutic guidance device for patients suffering from chronic in ammatory rheumatism, in particular RA. SinnoTest® consists of the following three elements: "routine" biological assay of biomarkers from a blood sample, calculation algorithm and graphical user interface (software and online application).
This device was designed by the company Sinnovial. The assessment of its conformity was carried out by SurgiQual Institute. Biomarkers are detected and quanti ed in blood samples of patients, using commercial tests aimed at determining the levels of these molecules. These results are sent to the SinnoTest® secure server. These data are processed by algorithms to determine the probability of response to the treatments available in the therapeutic arsenal (biological therapies). This data is sent to a secure server. The graphical user interface is an independent software, accessible through a web platform, which allows authorized health professionals to access the results of the analysis of individual patients. SinnoTest® is a stand-alone IMD-MD software, accessible via a web platform (see g 2, 3, 4 and 5 below).
Secondary Outcome Measures. Budget impact analysis at 6 and 12 months (Time Frame: 12 months). A budget impact analysis will be carried out if the innovation is deemed e cient. This budget impact analysis will describe the resources consumed and the expenses generated by each scenario, a scenario with the use of SinnoTest® and a scenario without SinnoTest®. Software's predictive model performance (Time Frame: 6 months). Sensitivity, speci city, positive and negative predicted values of the predictive models using the biomarkers will be assessed on the new clinical data from the 6-month trial.
Data management {19} Electronics Case report forms (eCRFs) will be used that complies with the general and speci c good practice standards, as well as the highest requirements for computer validation, with restricted access at the user level, provided with inconsistency detection lters and with traceability of all the information until the nal closing of the study. CRFs must be completed for each subject screened/enrolled in this study. This also applies to patients who do not complete the full follow-up planned in the trial. All CRFs must be lled out by the personnel duly authorized to do so, who will have access codes to the application for entering personal and non-transferable data. The investigator will keep the records and data during the trial in compliance with all legal and regulatory provisions in force.
All data must be supported by original documents in the test center. Any record or document used as a source of information (which will be called the "original data of the subject") will be kept for review by authorized representatives of the promoter or regulatory bodies. The CRFs will be lled in as soon as possible after the evaluation has been carried out. All the dates that appear in the CRFs referring to analytical tests and other data must coincide with the dates in which the samples were obtained or the procedures were performed. Study database. To facilitate the statistical analysis, a computerized database will be created in which the integrity of the data from the CRFs will be recorded, so that an exact replica of the information contained in them is created. A data management plan will be made before the beginning of the de nition of the database in which the recording process and the errors and consistency controls that will be performed on the recorded data will be detailed.
A dictionary of variables will be generated in which the correspondence between the data contained in the CRFs and the variables of the database will be detailed, as well as the codi cations used and the meaning of the recorded values. In the event of inconsistencies or errors in the data, requests for clari cation will be generated for the researchers for their veri cation or correction, which will be treated in an equivalent way to the CRFs. Access to the database will be restricted to the Data Manager (design, input and data cleansing) and the personnel in charge of data transcription (data entry). Prior to the declaration of the de nitive database, a veri cation of the consistency of the values of the inclusion / exclusion criteria, of the clinical evaluations, of the results of complementary explorations, of the dates of the visit, of the compliance, of the medication received, adverse events, information about dropouts and evaluation of effectiveness.