dataesr/scientific-paragraphs-categorization huggingface dataset:
When rtwo. min increased, the algorithm stopped rapidly with no classification (Table  4 ). Choice of the tuning parameters has thus to be made between no classes and too many classes, such as for CART approaches. From a practical point of view, together with field knowledge, the number of final classes, the R 2 global and the test procedure provided by this package can guide the user in this choice. Note that the choice of a deep tree will be corrected by the graft parameter. The results were compared to the CART approach, using the tree package, tuning parameters being set as follows: mincut = 5, minsize = 10, mindev = 0. 01. The CART approach showed a less accurate classification with 16 final classes (Table  5  and Figure   7 ). A central low risk cluster was also detected (class id 27) as well as the alternation of high and low risk   clusters in the South, but this approach failed to detect the polygonal shape and to gather similar adjacent classes (Figure  8 ).
Different cluster shapes and levels We assessed the SPODT functions analyzing three different situations, and in comparison to the CART algorithm (tree package). The following situations have been studied: Clustered data with a high level within a centered rotated square, and a low level outside. Clustered data with a low level inside a centered ball shape, and a high level outside. Clustered data with a high level under a "V" shape border, and a low level above. For each situation, samples (n = 300) were provided: Planar coordinates following a uniform distribution (1, -1). A dependent variable following a Gaussian distribution with a constant variance (0. 09) and a constant mean for the two level zones: µ 1 = 1 for the low level zone, µ 2 = 1 + β for the high level zone. For each situation, we used four samples: β = 0 (no cluster), β = 0.
Conclusion Among the different tools used dedicated to spatial classification (e. g. ,  Assuncao, Neves, Camara, and da Costa Freitas 2006; Oden, Sokal, Fortin, and Goebl 1993) , the proposed SPODT package provides a classification of a spatial area based on the spatial variability of a dependant variable. Space splitting can be oblique and this classification can be adjusted on covariates and gather similar adjacent classes. Associated functions (spodt. tree and spodtSpatialLines) are useful for graphical representations of the classification, and the spodt. test function provides a test of the oblique decision tree algorithm. SPODT package is provided with a real example set of malaria cases observed in Mali. Using this set and others, SpODT detected spatial and spatio-temporal clusters more accurately than the CART algorithm in all performed comparisons.
Acknowledgments The authors thank  Dr. Bernard Fichet  for many valuable discussions, the reviewers and the editor for their helpful comments. This work was supported by the  AMMA consortium (African Monsoon Multidisciplinary Analysis ). Dr. Jean Gaudart  was also supported by the  ADEREM association for biological and medical research development (Association pour le Developpement des Recherches biologiques et Medicales). The  Malaria incidence field study (Bandiagara, Mali)  was coordinated by the  Malaria Research and Training Center (MRTC, Bamako, Mali ), supported by cooperative agreement 5U01AI065683 from the  National Institute of Allergy and Infectious Diseases  and the grant  D43TW001589  from the  Fogarty International Center, National Institutes of Health.
Results: Here we present SNPchiMp v. 3, a solution to these issues for the six major livestock species (cow, pig, horse, sheep, goat and chicken). Original data was collected directly from SNP array producers and specific international genome consortia, and stored in a MySQL database. The database was then linked to an open-access web tool and to public databases. SNPchiMp v. 3 ensures fast access to the database (retrieving within/across SNP array data) and the possibility of annotating SNP array data in a user-friendly fashion. Conclusions: This platform allows easy integration and standardization, and it is aimed at both industry and research. It also enables users to easily link the information available from the array producer with data in public databases, without the need of additional bioinformatics tools or pipelines.
In addition accessory information including annotation, allele formats, flanking sequences, etc. is often difficult to retrieve, especially for SNP arrays that are no longer commercially available. Integration and standardization difficulties are compounded as basic information such as SNP IDs (e. g. names) are not consistent across array suppliers, and in some cases, not even between array releases from the same supplier. In addition, SNP IDs are not always searchable in public databases and in particular Ensembl and NCBI. Even when SNP related information is available, it often requires the download of large datasets and extensive data manipulation to obtain the required information. Moreover, reference genome assemblies are regularly updated, with consequent changes in SNP coordinates and occasionally in the allele orientation coding.
Data The SNP data contained in SNPchiMp v. 3 can be divided into two main categories: the original data coming from the producer and the information from public databases. Current and historical original data free from intellectual property was collected directly from producers (Illumina, Neogen-GeneSeek and Affymetrix) and International genome consortia (the International Sheep Genomics Consortium [13] and the International Goat Genome Consortium  [14] ). Some of the information contained in SNPchiMp v. 3 is directly available from the manufacturers/consortia websites  [15, 16]. As a result of extensive data collection, a total of 23 SNP arrays (12 cow, 4 pig, 3 horse, 2 sheep, 1 goat and 1 chicken) are currently stored in SNPchiMP, with a total of 3,993,814 SNP and their cross-references.
Public database information was handled in two ways: i) dbSNP database builds from June 2012  [17, 18]  onwards for all six livestock species were downloaded and stored on a local server; ii) tools to interrogate Ensembl databases directly through the web were built, either for querying information for single SNP or to access the Ensembl Biomart  [19, 20]  and/or VeP  [21, 22]  tools. A key feature of SNPchiMp, which is essential to integrate all above sources of information, was obtaining the links between commercial SNP IDs and dbSNP RefSeq (rs) IDs. Affymetrix already provides such association in its SNP knowledge base, whereas all other companies and consortia, which use Illumina-based technology and software, do not provide such information. For these, associations for all species were obtained by matching commercial SNP IDs against the "Submitter ID" or flanking sequences in the locally stored dbSNP database, following a similar procedure as specified in  [23]  for cattle.
Database SNPchiMp v. 3 stores the data on a MySQL Server instance version 5. 1. 73. Data are internally organized as shown in the entity-relationship shown in Figure  1. The different species were considered separately, by replicating the same set of tables for each using a naming scheme (e. g. prefix " < spec > " for each species). The core data was simplified in order to require only four tables: <spec > _arrays contains general SNP array information, including official SNP array name, the assembly used for the design, and the number of SNP contained. <spec > _SNPall contains the original SNP information provided by producers for all arrays. This table includes commercial SNP names and rs IDs (if assigned), all possible alleles coding for that SNP, the Interbull index (if available; only for cattle) and a code for the taxa (for internal control).
The table has two columns that describe the SNP (commercial SNP names and, if available, rs ID) and one Boolean column for each array, recording the presence/absence of that SNP in the specified array, respectively. <spec > _join_ < assembly > is a set of tables. For each species, there are as many of these tables as the number of available assemblies. Each table represents a join between the four core tables, restricted to a single assembly. This data design enhances data compartmentalization with respect to assemblies.
Query engine The query engine relies on a PHP application programming interface (API) written ad hoc to facilitate dynamically built SQL queries of the SNPchiMp v. 3 database (Figure  2 ). Each user input is validated and translated into a SQL query. A conservative approach was applied to ensure the security of the information contained in the database, such that a user request that fails validation returns error status and a set of case-specific error messages. For valid requests, the engine works in two different modes: one to produce a "preview" of the data requested by the user and one to perform the full query of the database. In the first mode, the engine interrogates the MySQL database, parses a subset of 25 elements of the result and returns a properly formatted PHP object. In the second mode, when a full query is requested, the engine returns the mediated user-defined SQL query using a pipeline, which directly connects the database output to the user.
From the technological point of view, the whole tool has been completely rebuilt. Performance, database structure and technology and languages behind the user interface were highly improved to allow current and future scalability and reliability. In addition, this version includes a completely new functionality for direct interrogation of the BioMart and VeP Ensembl resources (i. e. for SNP array automatic annotation). The key to ensure data reliability was to obtain current and historical original data directly from producers and international genome consortia. As SNPchiMp v. 3 aimed at the animal genetics community as a whole, only SNP arrays (or SNP information) that were free from intellectual property (IP) were considered. Once the data was obtained, a specific design of the MySQL database was chosen.
The strong compartmentalization between different species was one of the most important design choices. This ensured smaller table size, and thus easier updates and additions. Moreover, it reduced the probability that corruption in one dataset propagates to others, thus providing higher structure stability. In any case, the original data was stored in the database without modifying the data itself (i. e. data was just integrated, standardized and arranged to a MySQL database format), thus users are not forced to store large annotation files anymore. In fact, users do not need to build crossreference or cross-SNP array files anymore, as all these are already included in the functionalities of this tool (using original information). Another important design choice was the creation of two (controlled) redundant tables per species.
These tables were useful to enhance the performance of the most common queries (by reducing the number of "joins" that need to be performed) and, hence, runtime. The choice of producing a "preview" page of the queries was also linked to high performance, as PHP objects are easy to render graphically and parsing time is very short. Specifically, the "preview" functionality was included to reduce the number of unwanted downloads, which would be both tedious for the user and resource-consuming for the server. A strong effort was put into the design of an appealing, user-friendly and easy-to-manage website that included the interface to interrogate the database. Differently from previous versions, the SNPchiMp v. 3 website was built using the Joomla content management system (CMS) v. 3. 2. 2 [26].
It was functionally and structurally divided in three main areas: a documentation section, a software section and the database interface. The documentation area was highly improved from previous versions. Now it contains general information on the SNPchiMp, the data used, news with an RSS feed (Resource description framework Site Summary) and contact details. The new software section ("Tools") consists of a webpage that points to useful tools, usually linked to SNPchiMp v. 3 outputs (but not necessarily) and either produced in-house or by third parties. All software present in this section is open-access, and all contributors are encouraged to make their scripts open-source. Currently, the Tools menu contains software to extract Affymetrix Axiom genotypes (AffyPipe)  [27] , to convert Illumina-like allele coding and map information (iConvert)  [28]  and a multi-purpose software for SNP data management and analysis (Plato 2.
0)  [29]. The database interface is the true core of SNPchiMp v. 3, and of course was present in the other two versions of the tool. Although background functionalities were completely rebuilt, special attention was taken to maintain user experience as similar as possible to earlier versions. User access to the database is driven by two functions, specifically designed to efficiently query either all SNP array information ("Download" menu) or a subset of SNPs ("Browse" menu). After selecting the desired species, a series of dialog forms and JQuery-Javascript functions (i. e. for radio and box buttons) help users perform the required query of the database in a user-friendly fashion. No SQL coding skills or knowledge of the underlying database is required. User choices consist of the selection of the desired SNP array, genome assembly and the level of detail required for the expected results.
For both download and browse functions a subset of the first 25 rows of the query results is shown in a preview table. After being previewed, the resulting dataset can be downloaded by simply clicking on a "download" button. Three specific features are available when the Browse feature is used to query a subset of SNPs. Firstly, the preview page with results that contains links to related external resources/databases. On each row of the SNP table, two links for SNP specific Ensembl Locations/Variations and NCBI dbSNP pages are displayed. The second feature included in this section, which was not available in earlier version of this tool, was included in response to requests from the animal genetics community, and is the possibility to perform a straightforward SNP array specific annotation.
SNPchiMp v. 3 facilitates this by direct use of the Ensembl BioMart resources, using a "URL based access" interface to the Biomart Central Portal  [30]. The SNPchiMp v. 3 interface prepares the Biomart URL, containing the specified query parameters, in order to visualize the required subset of data. This avoids any need for programming or specific knowledge of the data-mining tools involved. More advanced users can refine their queries with an additional set of options as required. The third feature facilitates the direct interrogation of Ensembl's Variant Effect Predictor (VeP) tool using a REpresentational State Transfer (REST) interface. A Python CGI script was created to submit the data to Ensembl's VeP REST API and visualize the results within the SNPchiMp v. 3 interface. Results are displayed in a table where Ensembl VeP annotations are reported for each SNP.
Conclusions The need for SNP data standardization and integration is underappreciated. Here we present a tool that allows users to avoid performing the long and time-consuming series of steps required to integrate, standardize, and annotate SNP array data in the major livestock species. From its initial release  [23] , this tool was completely rebuilt both on the back-and on the front-end, in order to enhance manageability and user-friendliness. SNPchiMp v. 3 now considers six livestock species, for a total of 23 SNP arrays and allows direct and easy annotation of SNP array data in multiple species using Ensembl resources. It also provides standalone software for basic SNP data management. Its maintenance and constant update is ensured by the strong collaboration between SNP array producers, International Genome Consortia and the animal genetics community.
Acknowledgements George Wiggans  and  Gary Roher  ( USDA, USA ),  Maurizio Marusi  ( ANAFI, Italy ) and  John McEwan  ( AgResearch, New Zealand ) are greatly acknowledged for providing almost real-time news on SNP array updates. We also thank the three unknown reviewers for their useful comments and suggestions. The research leading to these results has received funding from the  European Union 's  Seventh Framework Programme  for research, technological development and demonstration under grant agreement  n°289592 -Gene2Farm.
WORKSHOP ORGANIZATION Before the workshop, suitable and "ready to use" models, that is, models for which executable program, user guide, and documentation, preferably following the TRACE (transparent and comprehensive ecological modeling) recommendations  (Schmolke et al. 2010; Grimm et al. 2014) , were identified, as well as case-study datasets for model applications. The case studies were fully designed before the workshop. Sixty participants were invited and included experts in modeling, ecotoxicology, and risk assessment (regulatory scientists and policy makers). These experts were selected based on their expertise and to provide sector (academic, government, and private sector), geographical, and sex balance. The workshop was divided into 2 meetings separated by a homework period. During the first meeting (Le Croisic, France, 22-25 October 2012), participants were introduced to ecological modeling in general (and to the selected models in particular), and to the challenges in using the models in the risk assessment of pesticides.
Acknowledgment-We are very grateful to the colleagues in the organizing team ( Anne Alix ,  Domenica Auteri ,  Patrice Carpentier ,  Peter Dohmen ,  Walter Schmitt , and  Lina Wendt-Rasch ). We would also like to thank all participants for the valuable contributions during the workshop meetings and the elaboration of the case studies. Financial support for the workshop was provided by  BASF ,  Bayer CropScience, CEFIC LRI ,  INRA ,  Makhteshim Agan ,  Sumitomo Chemical , and  Syngenta.
Highlights: • The ENAtool routine relies on an ensemble parameterization technique Here, we document an easy-to-use routine that allows EwE users to incorporate uncertainty in EwE input data into the calculation of ENA indices. This routine, named ENAtool, is a suite of Matlab functions that performs three main steps: (1) import of an existing Ecopath model and its associated parameter uncertainty values in the form of uncertainty intervals into Matlab; (2) generation of an ensemble of Ecopath models with the same structure as the original, and with parameter values varying based on the prescribed uncertainty limits; and (3) calculation of a set of 13 ENA indices for each ensemble member (one set of flow values) and of summary statistics across the whole ensemble. This novel routine offers the opportunity to calculate ENA indices ranges and confidence intervals, and thus to perform quantitative data analyses.
The Ecopath concept and equations Author-produced version of the article published in  Ecological modelling, 2015, 313, 23-40. The original publication is available at http://www. sciencedirect. com/ doi : 10. 1016/j. ecolmodel. 2015. 05. 036 ©. This manuscript version is made available under the CC-BY-NC-ND 4. 0 license http://creativecommons. org/licenses/by-nc-nd/4. 0/ The Ecopath with Ecosim (EwE) modelling software enables the building and analysis of food-web models  (Polovina, 1984; Christensen and Walters, 2004; Christensen et al. , 2008). The full software package includes several modules (e. g. Ecopath, Ecosim, Ecospace) to explore food webs across both space and time. However, for this study, we will focus only on the Ecopath component, which calculates a static mass-balanced snapshot of the biomass and energy fluxes between functional groups in a food web.
Import of a EwE model into Matlab ENAtool first imports data from EwE6 databases into Matlab, storing them in a variable format we will refer to as EwE input structures (Fig. 1 ). The original data import function, mdb2ewein, relies on the 'mdbtools' (http://mdbtools. sourceforge. net/) set of utilities to read data from the MS Access file format used by EwE. As an alternative for those unwilling or unable to compile C source code, we have provided a companion import function, excel2ewein, which relies on an Excel template to provide the necessary input data (Fig. 1 ). This function is based on a template (see Template A provided in Supplementary Material 2) that must be filled with key input parameters and other related information by first opening the pre-existing EwE model with a Author-produced version of the article published in  Ecological modelling, 2015, 313, 23-40.
The original publication is available at http://www. sciencedirect. com/ doi : 10. 1016/j. ecolmodel. 2015. 05. 036 ©. This manuscript version is made available under the CC-BY-NC-ND 4. 0 license http://creativecommons. org/licenses/by-nc-nd/4. 0/ database program such as Microsoft Access or OpenOffice Base. The template was provided as an Excel file and can be completed using any spreadsheet program (e. g. Microsoft Excel, OpenOffice Calc etc. ) but must be in the end saved as an Excel file (. xlsx). Both functions import all necessary Ecopath data, including basic inputs, diet compositions, fleet catches and discards, and multi-stanza group parameters, to the EwE input structure.
1 ; Table  1 ). The Pedigree index  (Funtowicz and Ravetz, 1990; Pauly et al. , 2000)  was designed to evaluate whether an EwE model was based on extensive field sampling performed within the boundaries of the system during specific dates. The Pedigree component in the EwE software allows marking/categorizing the data origin of each single input using pre-defined tables; the key criterion being that inputs from local data have the best confidence and the highest level in the scale  (Christensen et al. , 2005). In the pre-defined tables, each Pedigree score is associated with a Author-produced version of the article published in  Ecological modelling, 2015, 313, 23-40. The original publication is available at http://www. sciencedirect. com/ doi : 10. 1016/j. ecolmodel. 2015. 05. 036 ©. This manuscript version is made available under the CC-BY-NC-ND 4.
0 license http://creativecommons. org/licenses/by-nc-nd/4. 0/ default level of uncertainty expressed as ±%. For example, a Pedigree score of 1 (e. g. for a local biomass value) indicates a 10% uncertainty value. The createpedigree function builds a table of uncertainties based on an Excel file which contains for each parameter and each functional group the level of uncertainty to be applied to the single value (see Template B in Supplementary Material 3). Again, this Excel file can be opened with any spreadsheet program but must be finally saved as an Excel file. This Excel file can be also an export of the Pedigree table from the EwE software. If the user has no estimate of the uncertainty surrounding the input parameters in the pre-existing EwE model, a level of uncertainty can be set and a matrix of the same dimension as the uncertainty table will be automatically generated.
With no specification from the user, the default values will be 20% around single values  (Richardson et al. , 2006). As inputs, the createensemble function requires the uncertainty table built using the createpedigree function and the model imported into Matlab using mdb2ewein or excel2ewein (Fig. 1 ). The createensemble function generates a defined number of ensemble members that all fall within the prescribed uncertainty ranges. Parameter values can be sampled from a uniform distribution within limits fixed by the uncertainty table or a lognormal distribution with the mean and standard deviation set according to the uncertainty table. Both Latin hypercube and Monte-Carlo sampling methods can be used for random sampling in this interval. In the present application case, parameter values were randomly sampled using a Monte Carlo method from a uniform distribution with bounds directly related to the level of uncertainty.