dataesr/scientific-paragraphs-categorization huggingface dataset:
Many PDM also require other agronomic inputs such as the leaf area index, the height of the canopy, the width between canopy rows (or other measures of foliage density) and soil type (e. g. ,  Batchelor et al. , 1991). However, model evaluation generally requires datasets built on experiments which are designed to contrast treatments to minimize the risk of making a data-fitting exercise when performing calibration, as discussed in the next section. Such contrasting treatments might not make any agronomic sense and consequently are in general not available in field experiments. Considering the coupling of PDM to crop models to estimate the impact on yield, both models need to be verified. This would require specific field trials, where the crop is grown in optimal water and nitrogen conditions, both factorially crossed with at least two levels of disease and pest injuries: "absent" and "present"  (Esker et al.
, 2012). This articulated design is actually not sufficient when multiple disease and pests are addressed. In such a case, very large, multiseason field experiments are to be considered (e. g. ,  Savary et al. , 2000a, b). Such experimental designs however are at the base of model evaluation with the aim of providing guidance in identifying causes of the mismatch between model predictions and the real system performance. These experiments are costly, but the evaluation of coupled pest, diseases and crop models must be thoroughly performed to build confidence in their predictive capabilities, while contributing to the general understanding of system behaviour. Other datasets, with a lower level of detail, can be collected from actual fields to corroborate the model development and calibration made with the detailed dataset presented above.
In plant pathology and entomology, model evaluation is usually done by the same parties that developed the model. An important issue is the risk of overfitting, i. e. , when parameters of the model are adjusted until the model output matches very closely to the training data, and the same model shows poor performances when applied on independent datasets. Overfitting thus leads to false confidence in a model's accuracy and even to failure in conditions that do not exactly match those of the training data. The robustness of a model can be estimated from the stability of performance across treatments and environmental conditions; overfitting using datasets that poorly represent environmental conditions and potential vs. actual management, results in a model with low robustness  (Bellocchi et al.
Modelling frameworks The generic term modelling framework may refer either to conceptual workflows for model development and/or to actual software realizations to develop and run modelling solutions  (Holzworth et al. , 2015). The main desirable features of a modelling framework are extensibility of modelling approaches and modelling solutions, transparency, and the capability to interface to various sources of data. These features allow easier model comparison and model evaluation against a larger number of datasets compared to what can be done with separate model tools. Modelling frameworks may also facilitate model construction, allowing a more direct link to the results of research  (Donatelli et al. , 2014a ) by enabling the easier use of new findings in existing modelling solutions. The following examples are not exhaustive and represent different typologies of modelling approaches and tools available to simulate pest and/or diseases epidemics and impacts on crops.
They may consist of generic crop simulators such as CropSyst  (Stöckle et al. , 2003)  or STICS  (Brisson et al. , 2003) , or of platforms which share parts of the simulation engine (i. e. , modelling approaches) and retain specific modules for crops, such as DSSAT  (Jones et al. , 2003)  or APSIM  (Brown et al. , 2014). Fruit tree crop models are specific for species (e. g. ,  Lakso and Johnson, 1990; Grossman and De Jong, 1994). These models may include modules to account for the damage due to biotic stressors, but these modules are embedded into the code.
, 2015a). DYMEX  (Sutherst and Maywald, 1998)  was developed to simplify the construction of mechanistic, process-based population models  (Sutherst et al. , 2000)  and has been used to describe the life cycles of insects, weeds and diseases. Models are constructed within the DYMEX building software and compiled to run within the DYMEX simulator. The linking of DYMEX and APSIM was favoured over the construction of a specific pest and disease module within APSIM because it reduced overheads and capitalised on the history and success of both modelling frameworks  (Whish et al. , 2015a). The link between the two frameworks was created by wrapping the DYMEX simulation engine within APSIM. This approach took advantage of the multi-point features within APSIM (the ability to simultaneously simulate multiple points in space and the interactions between them) and the input/output features that simplified communication between multiple models.
The integration of DYMEX as an APSIM component allows the DYMEX component to execute with the rest of the APSIM simulation, accepting information from other modules (e. g. weather data from APSIM climate files or soil moisture from the water balance model) and sending information (population size, infected leaf area) to other models within the APSIM framework. The use of the generic wrapper to link the two frameworks, allows any model constructed in the DYMEX building tool to run within APSIM. The DYMEX-APSIM link has been successfully used to model rust (Puccinia striiformis) growth on wheat and demonstrated the interactions of large rust populations reducing the wheat crops leaf area  (Whish et al. , 2015a ). An examination of the population decline in root lesion nematodes (Pratylenchus thornei) over a non-host fallow is another example of this approach  (Whish et al.
NAPPFAST An example of the interactive modelling templates was the North Carolina State University/Animal and Plant Health Inspection Service Plant Pest Forecasting System (NAPPFAST;  Magarey et al. , 2007 Magarey et al. , , 2015) )  that was an active project between 2002 and 2013. The NAPPFAST system employed an internet-based graphical user interface to link interactive templates with weather databases. NAPPFAST included three modelling templates: a degree day template for creating phenology models for arthropod pests and plants, an infection model template for plant pathogens, and a generic template for creating simple empirical models; e. g. , hot and cold exclusion. Each template follows a simple fill-in-the blank design. All templates in NAPPFAST were generic (i. e. , applicable to many species) to meet the needs of diverse users.
The templates in NAPPFAST were linked to stations and to North American and global gridded weather databases. The capabilities allowed NAPPFAST to create pest risk maps  (Magarey et al. , 2011)  at resolutions of 5 km in the United States and 38 km globally. More recently some of the technologies developed for NAPPFAST have been applied for the integrated Pest information Platform (iPiPE) project. The iPiPE was created to promote the exchange of pest data among agricultural professionals  (Isard et al. , 2015). It is an information technology platform that provides tools and models for managing and analyzing data in order to generate products and commentary for integrated pest management (IPM) and national food security. The iPiPE brings together Extension professionals, county agents, crop consultants, industry, federal, and state partners by allowing the exchange of pest observations while protecting client privacy.
3 ). This discretization also reflected in the software development of the components, which provide users with an existing definition of specific domains to focus on when introducing new models, other than favouring their stand-alone application and extension. These tools were developed according to the specifications of the BioMA framework, which is a public domain software framework designed and implemented for developing, parameterizing and running modelling solutions based on biophysical models in the domains of agriculture and environment  (Donatelli et al. , 2014b). The adoption of component-oriented programming and the definition of the ontology of input and output variables promote the link of the Diseases components with large area databases and their interface with external tools to perform model sensitivity analysis.
i) Improve the quality and availability of data for model inputs The process-based modelling of the dynamics of plant pests and diseases aims at reproducing the biophysical processes guiding their development and spread in time. The effect of weather conditions has traditionally been an important focus of these models. The dependency of the pathogen growth rates of pathogens on the variability of weather conditions implies that models should reproduce these relationships by modulating their responses accordingly  (Magarey et al. , 2005; Pfender et al. , 2012). The availability of high-quality input datasets is necessary to calibrate PDM parameters, for instance the ones related to temperature and moisture response functions. As discussed in the section above, the main drawback of low-quality datasets is the reduction of model parameters that have a biophysical meaning to empirical coefficients that merely improve model fit to reference data.
, 2000) , as summarized in the section Data requirements. We propose here a tentative distinction between high (HQ) and medium (MQ) quality reference datasets for model calibration and evaluation, according to the typology of the variables to be measured and to the frequency of their sampling during the growing season. A HQ datasets for PDM calibration and evaluation should include the full complement of data, including injury measurements, environmental (weather), and agronomic (crop growth and development) data characterizing the impact on the crop. Experimental observations should include multiple measurements of pest and disease injuries (e. g. , severity or incidence depending on the injury) during the growing season, and the quantification of yield loss due to pests and diseases. Additionally, detailed measurements related to plant physiological processes as affected by the pathogens should be performed, including for instance effects on photosynthesis, maintenance respiration and leaf senescence.
Injury assessments should be collected in unsprayed experimental plots as well as on protected plots  (Zadoks and Schein, 1979; Savary et al. , 2006; Esker et al. , 2012). Weather data should include temperature, relative humidity, precipitation and leaf wetness (whenever appropriate, e. g. , in the case of diseases of the foliage). Reference leaf wetness data, for instance, should be collected either using visual observations or a camera at a limited number of sites. Agronomic observations should include attainable (i. e. , uninjured) and actual (injured) yield data, as well as leaf area index, crop height, variety, previous crop, and pesticide applications. MQ datasets would not include dynamic information collected during the growing season, but must include quantitative information to characterize the level(s) of injuries (e.
iv) Improve the processes for model evaluation Improving capabilities to estimate the interaction between pests, diseases and crops requires actions along two lines: building models and modelling tools, and model evaluation. Although we aim at building generic modelling frameworks, model evaluation must focus on specific crops (within crop rotations). In the AgMIP project  (Rosenzweig et al. , 2013) , a phase of evaluation requires modelers to run simulations corresponding to test data sets for which they have not seen the observations of the response variable ("blind" datasets, for example yield for crop models). For plant pest and disease modelling, one of the evaluation challenges will be to develop appropriate evaluation criteria to judge model success or failure. For example, observations of pest and disease impact may be typically recorded in terms of units such as insect numbers, percentage of host tissue affected or pest incidence.
Antibody screen (LEGENDScreen Human Cell Screening) CD4 + T cells from donor #42 (from a previous study  [3] ) were TCR-activated for 48h as described above and infected with HIV-GFP. After 24h of infection, CD4 + T cells were incubated with the LEGENDScreen Human Cell Screening PE-conjugated Antibodies (BioLegend), according to manufacturer's recommendations. Briefly, 100,000 cells were stained with each provided PE-antibody for 30 min at 4˚C, according to the manufacturer's protocol, washed with PBS-BSA (1%), fixed with 200 μl of CellFIX (BD Biosciences) and analyzed by FACS Gallios (Beckman Coulter). Marker expression and GFP reporter expression data were analyzed using FlowJo software (Tree Star). Flow cytometry analysis of surface markers and cell sorting CD4 + T cells were collected at 0h, 24h, 48h, and 72h after TCR activation and analyzed by FACS for longitudinal expression assays.
Co-expression analysis of multiple biomarkers was performed at 48h post-activation only. Briefly 100,000 cells were used for each staining, washed twice with PBS-BSA, and incubated at 4˚C for 30 min with the different surface antibodies (S7 Table ). Cells were then washed twice with PBS-BSA, fixed with CellFIX and analyzed by flow cytometry using FACS BD Accuri C6 (BD Biosciences). Data was analyzed using FlowJo software. Staining for cell sorting was performed on a cell suspension of 10-40 million CD4 + T cells, in 250-500 μl of RoboSep buffer (Stemcell Technologies). After cell washing, cells were incubated with the different antibodies (S8 and S9 Tables) at 4˚C for 30 min, washed and resuspended in Robosep Buffer (1-2 ml) prior to sorting on MoFlo Astrios (Beckman Coulter Life Sciences; Flow Sorting Facility, University of Lausanne).
Analysis of transcriptional heterogeneity across single cells was performed using Sincell Bioconductor package  [27]. Differential expression analyses used DESeq2 bioconductor package  [32]. Functional enrichment analysis was performed using STRING with default parameters  [52]. An R script with the code necessary to reproduce all bioinformatics results and figures is provided as S1 File. Versions of R-packages used are detailed in at the end of S1 File.
Acknowledgments Computations were performed at the  Vital-IT  (http://www. vital-it. ch)Center for high-performance computing of the  SIB Swiss Institute of Bioinformatics. We are thankful to the iGE3 platform at the  University of Geneva  for technical support on the single-cell RNA-seq procedure, to the  Genomics Technology Facility (GTF)  and to the  Flow Cytometry Facility (FCF) of the University of Lausanne. We thank as well  David N. Levis  for the kind gift of NLENG1-IRES plasmid.
The research leading to these results has received funding from the  European Union 's  Seventh Framework Program  FP7/2007-2013/ under grant agreement n˚305762/Hit Hidden HIV (http://cordis. europa. eu/fp7/) to AT and AC, from the  Swiss National Science Foundation  (http:// www. snf. ch/en/Pages/default. aspx) grants no. 149724  to AT and  146579  to AC and AT, and from  Novartis Foundation  for medical-biological CD317 were highly enriched for HIV permissiveness. The single-cell analysis approach used in this study allowed for the identification of the most HIV-permissive cell. Research (http://www. stiftungmedbiol. novartis. com/) grant # 16B115  to AC. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
Introduction Over the past decade, a flourishing number of concepts and economic shifts appeared such as cloud computing, Internet of Things (IoT), Semantic Web, or still the sharing economy  [1] [2] [3]. This evolution opens up the way for new applications that leverage ubiquitous connectivity and analytics in a wide range of sectors (e. g. , transportation, energy, manufacturing, healthcare, cities, etc. ), as well as for disruptive innovation and business models that reduce costs for societies, foster a sustainable economic growth, and improve the quality of citizen-oriented services. Ideally, the IoT should provide means to create, when and as needed, ad hoc and loosely coupled information flows between any kinds of smart connected objects, databases and users. Nonetheless, while new smart connected objects hit the market every day, they mostly feed "vertical silos" that are closed to the rest of the IoT  [4, 5]  (e.
Even if it is true that narrowing the range of IoT messaging standards, especially at the application layer, is a necessary step to enable the IoT to live up to its potential, there are other architectural and structural considerations to be taken into account. Amongst them, it is important to provide IoT stakeholders with easy-to-use tools, and most importantly incentive environments for publishing, searching for, and consuming various types of IoT data/services (A distinction is made between "IoT data" and "IoT services". "IoT data" refers to data streams coming from sensors or other systems generating or holding data (database, file. ), while "IoT services" refers to the call of a web service that takes, as inputs, one or more parameters and may imply a processing stage to return the expected result.
Existing IoT platforms often rely on pre-defined data models to describe and annotate data that is generated by Things. However, such data models are technology-dependent and often inherent implementation-specific features (e. g. , specific protocols, language support, structures, etc. ), which affect the way and expressivity of the semantic definition  [27]. In order to overcome these limitations and find a common approach that can be understood and extended by all stakeholders, Semantic Web  [28]  technologies are more and more often applied in IoT projects. The overall approach of applying ontologies to solve the semantic interoperability of the IoT is often described as the Semantic Web of Things (SWoT)  [29]. The cornerstone of the semantic web is the Resource Description Format (RDF) which, when combined with other standards such as RDF Schema (RDFS) and Web Ontology Language (OWL), can represent knowledge about the physical world  [30].
COMPOSE Layer Once Things are published using a common/universal application protocol (ACCESS layer), where they can be found by humans and machines (FIND layer) and their resources be securely shared with third parties leading to potential rewards (SHARE layer), it becomes time to look at how to build meaningful cross-domain and/or cross-platform services. To put it another way, data and services coming from heterogeneous Things can now be easily, or at least with minimum interoperability issues, combined together and plugged to analytics software and mashup platforms in order to fulfil untapped applications across systems and application areas. Such a combination (COMPOSE layer) can be achieved using various IDE (Integrated Development Environment) solutions, ranging from web toolkits (e.
So far, three distinct publication and consumption schemes are made possible in the bIoTope ecosystem, as summarized in Figure  4  (cf. Case 1-3). Case 1 corresponds to the basic publication/consumption scheme, where IoT data/services are published for free and without any access right. In this case, consumers search for relevant and valuable data/services on IoTBnB and then get the necessary information to access the underlying ressource (cf. arrows denoted by to of Case 1 in Figure  4b ). Case 2 provides data/service publishers with the possibility to decide who can access what and how; this being specified at their gateway level (cf. "security module" in Figure  4b ). When a consumer wants to directly access a secured data/service item whose URL is already known, she/he has to send a request to the gateway owner/administrator in order to be granted.
In cases where the consumer discovers and selects the secured data/service item through IoTBnB, a token is generated by IoTBnB on behalf of the data/service owner (cf. arrows denoted by , -of Case 2 in Figure  4b ). Beforehand, the gateway owner/administrator must give full authority to the marketplace to manage the access to (or denial of) the data/service items when consumers have (or not) fulfilled the access/purchasing terms. This is done when the administrator registers her/his node to IoTBnB. Furthermore, to enable administrators to manage the who, what and how their data/services can be accessed by third parties, a complementary security module has been specified and developed in bIoTope, based upon five key requirements, which have been listed in Table  1. Figure  5  provides an overview of what the module consists of, namely: a back-end database: for storing user groups and related access rights; external authentication service: using the external web service Auth0; User Interface: enabling administrators to specify and manage access rights related to the registered users; Access control service: for checking what kind of permissions end-users have on the requested data/service.
Access & Find Layers In this pilot, the temperature data collected by LoRa sensors are exposed through an O-MI/O-DF gateway, which runs on a physical machine having 2 processors (CPU E5-2640 @2. 50GHz) and 48 GB of RAM. This machine is hosted in Lyon (France) behind a firewall. In this section, we propose to evaluate the behavior of the O-MI gateway-mainly in terms of response time-under heavy traffic load. To do so, a stress test is performed by using the open-source software Apache JMeter (Apache JMeter: http://jmeter. apache. org/, accessed on July 2017). This software allows to send concurrent requests to the O-MI gateway. Such requests were generated and sent from Luxembourg University's network (from a APPLE Macbook Pro Retina-mid-2015-with an Intel Core i7 CPU @2. 8GHz and 16 GB of 1600 MHz DDR3 RAM).
Given this, and as part of an ongoing H2020 EU project (named bIoTope), the present paper discusses the EU's vision and ambition to move towards successful and viable open IoT ecosystems. To be technologically and economically viable, and to contribute to break down the vertical silos, open IoT ecosystems need to support key technological layers, described as the Access, Find, Share and Compose in this paper (cf. Figure  2 ). It is argued that, to create a true and federated IoT, the most critical layer is the Access one for which a common agreement about a single universal protocol needs to be reached. However, there is still a fierce competition between standardization fora, making it difficult to to speculate about what standard(s) will remain or disappear in the future. In the framework of the bIoTope project, two open communication standards named O-MI and O-DF are considered at the Access and Find layers respectively.
The smart city pilot, jointly developed with Métropole de Lyon, shows that these two standards enable to meet the prerequisites of an open IoT ecosystem. Pilots in Brussels and Helsinki cities are currently under development, which will be used as comparison basis for evaluating and validating the extent to which one pilot (or part of the pilot) can be replicated in other cities. Future research work is concerned with the integration of contextual data in the ecosystem (e. g. , benefiting from semantic web technologies at the Find layer) in order to design and support more advanced and "smart" services. In addition of this technological proof-of-concept, much remains to help cities and business to step into open IoT ecosystems from a business perspective. To this end, bIoTope proposes an IoT data/service marketplace (called IoTBnB), which opens up new forms of Business-to-Business and Customer-to-Business interactions.