dataesr/scientific-paragraphs-categorization huggingface dataset:
Main concepts of the Ocelet language Entity, relation and scenario are the main concepts adjoined to the basic features available in most programming languages (e. g. blocks, operations on data types, control loops, conditional branching) to form Ocelet. An entity in Ocelet is generally spatial, although this is not necessarily the case. It is defined with a number of properties whose values may change during simulations. A spatial entity has one of its properties to define its spatial extent and position within a spatial reference system. Other non spatial properties of the entities can be of common data types such as String, Integer, Double, and Boolean. Ocelet proposes several data types (geometric types, colour types, date type, user-defined composite types) and collections (group, list, keymap) to facilitate the manipulation and display of spatial and non-spatial information.
Building and using explicit dynamic interaction graphs The downside of the concept of interaction graph being lowlevel and generic is that building such graphs could be tedious without the help of appropriate tools. Ocelet comes with data format specific interfaces (here called datafacer) that can be used to feed the model with ready for use entities. From tabularlike data formats (such as csv, shapefile, PostGIS) one can obtain an entity for each line or record. A match mechanism is implemented for assigning entity property values directly from attribute or column data. Output datafacers also exist for the three above-mentioned formats, plus another frequently used one, specifically for displaying animated maps in Google Earth (kml format). To help build the edges of the graphs, Ocelet also comes with appropriate functions and operators that use entities types and their property values (including spatial properties).
The Ocelet modelling platform Ocelet is a compiled DSL. The compilation consists in automatically translating a model written in Ocelet into Java classes using a code generator. The execution of the compiled model then uses the Ocelet java runtime which contains a set of java classes specifically developed for Ocelet, as well as several other functions from known open-source libraries such as the Java Topology Suite (JTS) and Geotools. In the OMP environment, these software dependencies are rendered transparent to the user. Fig. 2  shows the main features of the OMP interface, built with Eclipse RCP and composed of four frames. In the middle one there is a text editor with syntax highlighting. Code errors are underlined in red. The left frame contains the project navigator. A project contains the description of a model, with all the input data and configuration files organised in sub-folders.
Conclusions and perspectives One of our main motivations when designing Ocelet was to offer to modellers an as large as possible capacity of expression, with (a) no predefined representation of space and the possibility to mix more than one (grid, vector, continuous), and (b) no predefined form of relationship, where most modelling tools have their own relationship meta-model (e. g. agent-population hierarchy, topological adjacency neighbourhood) which can sometimes be constraining for the modelling exercise. We believe that having only one same generic concept to hold any kind of interaction, with the support of a domain specific language, is a good compromise between capacity of expression and ease of use. It also provides appropriate concepts and associated tools to help modellers integrate points of views from different scientific disciplines into one same model.
Given the generic nature of interaction graphs, Ocelet can be used in a wide range of applications involving multidisciplinary issues. For example, Ocelet has been successfully   used for experimenting land use policy simulation scenarios in a participatory approach  [22] , studying farming systems evolution from plot to regional scale  [23] , and modelling mangrove coastline changes  [24]. User feedbacks should help to enrich the language and the platform with new features, although the initial concepts can be considered stable. A foreseen addition to the version 1. 1 presented here will be an important optimisation work on the capacity to mix large grid, continuous and vector representations of space in the same model. An efficient treatment of a large number of grid cells (typically the number of pixels in a satellite image) is being tested  [25]  and is planned to be incorporated in the next version of Ocelet.
Data Collection and Patients Characteristics The MIMIC-II study  [22] [23] [24]  includes all patients admitted to an ICU at the Beth Israel Deaconess Medical Center (BIDMC) in Boston, MA since 2001. For the sake of the present study, only data from MIMIC-II version  26 (2001-2008)  on adult ICU patients were included. Patients younger than 16 years were not included. For patients with multiple admission, we only considered the first ICU stay. A total of 24,508 patients were included in this study.
Patient Inclusion and Measures Two categories of data were collected: clinical data, aggregated from ICU information systems and hospital archives, and high-resolution physiologic data (waveforms and time series of derived physiologic measurements), recorded on bedside monitors. Clinical data were obtained from the CareVue Clinical Information System (Philips Healthcare, Andover, Massachusetts) deployed in all study ICUs, and from hospital electronic archives. The data included time-stamped nurse-verified physiologic measurements (e. g. , hourly documentation of heart rate, arterial blood pressure, pulmonary artery pressure), nurses' and respiratory therapists' progress notes, continuous intravenous (IV) drip medications, fluid balances, patient demographics, interpretations of imaging studies, physician orders, discharge summaries, and ICD-9 codes.
Comprehensive diagnostic laboratory results (e. g. , blood chemistry, complete blood counts, arterial blood gases, microbiology results) were obtained from the patient's entire hospital stay including periods outside the ICU. In the present study, we focused exclusively on outcome variables (specifically, ICU and hospital mortality) and variables included in the SAPS II  [4]  and SOFA scores  [26]. We first took an inventory of all available recorded characteristics required to evaluate the different scores considered. Raw data from the MIMIC II database version 26 were then extracted. We decided to use only R functions (without any SQL routines) as most of our researchers only have R package knowledge. Each table within each patient datafile were checked for the different characteristics and extracted.
The Super Learner then estimates the risk associated to each algorithm in the provided collection using cross-validation. One round of cross-validation involves partitioning a sample of data into complementary subsets, performing the analysis on one subset (called the training set), and validating the analysis on the other subset (called the validation set or testing set). To reduce variability, multiple rounds of cross-validation are performed using different partitions, and the validation results are averaged over the rounds. From this estimation of the risk associated with each candidate algorithm, the Super Learner builds an aggregate algorithm obtained as the optimal weighted combination of the candidate algorithms. Theoretical results suggest that to optimize the performance of the resulting algorithm, the inputted library should include as many sensible algorithms as possible.
This algorithm was included in the SL library so that revised fits of the SAPS II score based on the current data also competed against other algorithms. Comparison of the 12 algorithms relied on 10-fold cross-validation. The data are first split into 10 mutually exclusive and exhaustive blocks of approximately equal size. Each algorithm is fitted on a the 9 blocks corresponding to the training set and then this fit used to predict mortality for all patients in the remaining block used a Fig. 20. 1 Super learner algorithm. From van der Laan, targeted learning 2011 (with permission)  [41]  validation set. The squared errors between predicted and observed outcomes are averaged. The performance of each algorithm is evaluated in this manner. This procedure is repeated exactly 10 times, with a different block used as validation set every time.
Performance measures are aggregated over all 10 iterations, yielding a cross-validated estimate of the mean-squared error (CV-MSE) for each algorithm. A crucial aspect of this approach is that for each iteration not a single patient appears in both the training and validation sets. The potential for overfitting, wherein the fit of an algorithm is overly tailored to the available data at the expense of performance on future data, is thereby mitigated, as overfitting is more likely to occur when training and validation sets intersect. Candidate algorithms were ranked according to their CV-MSE and the algorithm with least CV-MSE was identified. This algorithm was then refitted using all available data, leading to a prediction rule referred to as the Discrete Super Learner. Subsequently, the prediction rule consisting of the CV-MSE-minimizing weighted convex combination of all candidate algorithms was also computed and refitted on all data.
This is what we refer to as the Super Learner combination algorithm  [28]. The data used in fitting our prediction algorithm included the 17 variables used in the SAPS II score: 13 physiological variables (age, Glasgow coma scale, systolic blood pressure, heart rate, body temperature, PaO 2 /FiO 2 ratio, urinary output, serum urea nitrogen level, white blood cells count, serum bicarbonate level, sodium level, potassium level and bilirubin level), type of admission (scheduled surgical, unscheduled surgical, or medical), and three underlying disease variables (acquired immunodeficiency syndrome, metastatic cancer, and hematologic malignancy derived from ICD-9 discharge codes). Two sets of predictions based on the Super Learner were produced: the first based on the 17 variables as they appear in the SAPS II score (SL1), and the second, on the original, untransformed variables (SL2).
Discussion The new scores based on the Super Learner improve the prediction of hospital mortality in this sample, both in terms of discrimination and calibration, as compared to the SAPS II or the APACHE II scoring systems. The Super Learner severity score based on untransformed variables, also referred to as SL2 or SICULA, is available online through a web application. An ancillary important result is that the MIMIC-II database can easily and reliably serve to develop new severity score for ICU patients. Our results illustrate the crucial advantage of the Super Learner that can include as many candidate algorithms as inputted by investigators, including algorithms reflecting available scientific knowledge, and in fact borrows strength from diversity in its library. Indeed, established theory indicates that in large samples the Super Learner performs at least as well as the (unknown) optimal choice among the library of candidate algorithms  [28].
Conclusions Thanks to a large collection of potential predictors and a sufficient sample size, MIMIC II dataset offers a unique opportunity to develop and validate new severity scores. In this population, the prediction of hospital mortality based on the Super Learner achieves significantly improved performance, both in terms of calibration and discrimination, as compared to conventional severity scores. The SICULA prediction algorithm is a promising alternative that could prove valuable in clinical practice and for research purposes. Externally validating results of this study in different populations (especially population outside the U. S. ), providing regular update of the SICULA fit and assessing the potential benefit of including additional variables in the score remain important future challenges that are to be faced in the second stage of the SICULA project.
Code Appendix This case study used code from the Super Learner Library, implemented in R. Further details and code are available from the GitHub repository accompanying this book: https://github. com/MIT-LCP/critical-data-book. The following algorithms are included in the Super Learner Library. Parametric algorithms: -Logistic regression: standard logistic regression, including only main terms for each covariate and including interaction terms  [42]  (SL. glm), -Stepwise regression: logistic regression using a variable selection procedure based on the Akaike Information Criteria  [43]  (SL. stepAIC), -Generalized additive model  [43]  (SL. gam):, -Generalized linear model with penalized maximum likelihood  [44]  (SL. glmnet), -Multivariate adaptive polynomial spline regression  [44]  (SL. polymars), -Bayesian generalized linear model  [45]  (SL.
D. Efficient optimal control solver Our framework relies on the 20 years old optimization package MUSCOD-II  [32] , a multiple shooting solver for highly nonlinear systems submitted to path equality and inequality constraints, developed inside the Optimization and Simulation group at the University of Heidelberg. MUSCOD-II handles multi-phase systems with discontinue dynamics and periodic constraints with efficiency. While MUSCOD-II is a closed-source framework, one can depend on ACADO  [33]  which implements similar features.
VI. DISCUSSIONS AND FUTURE WORKS While our framework shares some common features with the Matlab package developed by Remy et al. [13] , its differs on various aspects. The first difference lies at the optimal control method level. In  [13] , the authors use either collocation or shooting methods. Still, as mentioned in  [35]  and recalls in Sec. III-C, the multiple shooting approach is the most suited in the context of multi-phase dynamical systems submitted to impacts and constraints. In addition, the choice of the C++ programming language to write both our dynamic simulation and optimal control problem is fundamental for efficient and fast computation. Currently, we do not check the stability of the resulting motions, but only its balance at a dynamic level. As future extension, we plan to implement an approach similar to  [37]  to converge on optimal and stable open-loop motions.
ACKNOWLEDGEMENT This work is supported by the  European Research Council (ERC)  through the  Actanthrope project (ERC grant  agreement  340050 ), the  European  project  KOROIBOT  ( FP7-ICT-2013-10/611909 ) and the  French National Research Agency  thought the  Entracte project  ( ANR grant agreement 13-CORD-002-01 ). We warmly thank  Katja Mombaur  and the  Simulation and Optimization group at the Interdisciplinary Center for Scientific Computing (IWR) of Heidelberg University in Germany  for providing the optimal control framework MUSCOD-II.
Arthropods interact with humans at different levels with highly beneficial roles (e. g. as pollinators), as well as with a negative impact for example as vectors of human or animal diseases, or as agricultural pests. Several arthropod genomes are available at present and many others will be sequenced in the near future in the context of the i5K initiative, offering opportunities for reconstructing, modelling and comparing their metabolic networks. In-depth analysis of these genomic data through metabolism reconstruction is expected to contribute to a better understanding of the biology of arthropods, thereby allowing the development of new strategies to control harmful species. In this context, we present here ArthropodaCyc, a dedicated BioCyc collection of databases using the Cyc annotation database system (CycADS), allowing researchers to perform reliable metabolism comparisons of fully sequenced arthropods genomes.
A similar initiative has been launched by the Arthropod Genomics consortium: the i5K initiative, which aims at sequencing the genomes of 5000 arthropod species (http://arthropodge nomes. org/wiki/i5K) (8, 9). The availability of the full genome sequence of an organism allows researchers to have a complete view of its metabolism. The BioCyc collection of Pathway/Genome DataBases (PGDBs)  (10)  constitutes a key resource for studying the metabolism of multiple organisms as it enables comparative studies. The first database of the collection, EcoCyc  (11) , is at present a comprehensive resource to study Escherichia coli biology  (12). The quality of these databases is strongly linked to the annotation used to generate them and, in the most recent release (June 24, 2015version 19. 1), only seven databases are intensively manually curated and frequently updated (BioCyc Tier 1 PGDBs): EcoCyc  (12) , MetaCyc  (13) , HumanCyc  (14) , AraCyc  (15) , YeastCyc  (16) , LeishCyc  (17)  and TrypanoCyc  (18).
Such expert driven annotation is only possible for large communities of scientists working on the same model and, consequently, the majority of the 5711 BioCyc PGDBs available in this release are computationally derived: 39 are subject to moderate manual curation (BioCyc Tier 2 PGDBs) and 5455 to no manual curation at all (BioCyc Tier 3 PGDBs) (see http://biocyc. org/biocycpgdb-list. shtml for an updated listing). The upcoming deluge of fully sequenced genomes, driven by NGS technology, demands the development of a novel genomic infrastructure  (19). To contribute to the need of standardized automated annotation, we developed a Cyc Annotation Database System (CycADS)  (20). CycADS was successfully used to generate AcypiCyc (http://acypicyc. cycadsys. org), a database dedicated to the pea aphid Acyrthosiphon pisum metabolism that was developed during the annotation phase of the genome of this insect  (21).
CycADS annotation management system ArthropodaCyc is a collection of BioCyc PGDBs that contains, at the time of writing (March 2016), the metabolic network of 28 arthropods with sequenced genomes  (4, , including 25 insects, two arachnids and a branchiopod [Figure  1 , note that phylogenetic relationships between species are displayed using a cladogram based on available data  (46) (47) (48) (49) (50) ]. All databases in ArthropodaCyc were generated using CycADS  (20) , an annotation management system programmed in Java (Model-View-Controller structure) and SQL that was originally developed for the annotation of the pea aphid genome  (21). CycADS facilitates the collection and management of information obtained from both genomic data and different protein annotation methods in a SQL database.
A pipeline to filter for bacterial contaminants was developed and integrated in the protein functional annotation system, which involves multiple methods (see below for a detailed description). All data collected in CycADS were then extracted and formatted to generate, for each organism, an ad hoc input file (a BioCyc 'Path-o-logic file' format) used by the Pathway Tools software  (51)  to produce BioCyclike enriched metabolic database (20) (Supplementary Figure  S1 ). Genomes are included in ArthropodaCyc if they fulfil the following criteria: (i) the genome sequence is published and (ii) the sequence data can be downloaded in appropriate formats (comprehensive GFF or Genbank file with compatible gene/mRNA/protein features). Each organism database summary page contains updated information relative to the genome data release used to generate it.
Filtering possible bacterial contaminations Organisms across all kingdoms of life are associated with microbial partners, with interactions ranging from parasitism to mutualism. Arthropods are no exception and can harbour microorganisms at their external surface, or internally as endosymbionts, gut microbiota, parasites or pathogens. Despite the use of specific DNA extraction protocols, massive sequencing of arthropod genomes may generate sequences contaminated by prokaryotic DNA. Since the ArthropodaCyc databases aims at collecting high-quality functional annotations, we decided to implement a pipeline for the detection of putative contaminant bacterial sequences, to be used before the reconstruction step of the arthropod metabolic pathways. First, genomic sequences, annotation files (GFF/GBK) and protein sets of each arthropod genome project were retrieved from public repositories  (52) (53) (54) (55) (56) (57) (58) (59) (60) (61) (62).
Genomic sequences smaller than 50 kbp were compared to the NCBI's RefSeq prokaryotic genome sequences database (63) using BLASTN  (64). Contaminant genomic sequences were identified using a 90% identity threshold over at least 90% of the query length. A BLASTP against the NCBI RefSeq prokaryotic protein sequences database was thus performed to check for bacterial contaminations within the remaining proteins. Protein sequences were filtered based on BLAST results using three different criteria: (i) at least 90% amino acid identity over at least 90% of the query length, (ii) at least 90% amino acid identity over at least 50% of both the query and the hit lengths or (iii) at least 95% identity over a sliding window of 100 amino acids. To reduce the risk of removing arthropod sequences (false-positives), we included a last step performing a BLASTP (80% amino acid identity over at least 80% of the query length) of the putative contaminant protein list against an invertebrate subset of the reference UniProtKB/Swiss-Prot protein sequence database  (65).
Proteins with positive hits were reintegrated in the annotation process. Lists of putative bacterial contaminants detected within the 28 arthropod genomes of ArthropodaCyc are provided in Supplementary Table  S1. The proteins identified as putative bacterial contaminants were flagged upon extraction and they were not ). Included in this table are all reactions in each database which have been assigned either full or partial E. C. numbers, and for which an enzyme has been identified (these statistics do not include pathway holes). Phylogenetic relationships between species are displayed using a cladogram based on available data  (46) (47) (48) (49) (50). used in the Pathway Tools reactions inference (see below). However, they still appear in the database with a gene/protein page and the information about their status of contaminants.
The functional annotation pipeline We used multiple methods to perform a functional annotation: the online KAAS-KEGG annotation pipeline  (66)  and the PRIAM (67), Blast2GO  (68, 69)  and InterProScan  (70)  pipelines with a local installation for faster data generation (summary of results in Supplementary Table  S2 ). These methods generated functional information (EC number, KEGG Orthology and Gene Ontology) related to the protein sequences and all annotations were collected in the database using flexible annotation loaders (annotation collector module) available in CycADS. Default parameters were used for software configurations and the BLAST alignments (prior to the Blast2GO analysis) were performed against the reference UniProtKB/Swiss-Prot protein sequences database  (65). All annotation data were extracted from the CycADS SQL database for each analysed genome and collected in a Pathologic file that was used in Pathway Tools  (51)  to generate the corresponding BioCyc PGDB.
For several arthropods, a genome wide phylogenetic analysis performed using the Phylome pipeline and collected in PhylomeDB (71) was available. In those cases, Gene Ontology annotations were transferred using orthology relationships to Drosophila melanogaster and integrated in the ArthropodaCyc databases using CycADS as previously described  (20). Furthermore, for the arthropods with a Phylome analysis, the orthology predictions generated in MetaPhOrs (June 2015 release) (72) using a combination of phylogenetic information derived from different databases were included into the corresponding BioCyc databases using the orthology functionality of Pathway Tools. Using CycADS, enriched gene records were automatically generated in the Pathologic file format imported by Pathway Tools. Each Pathologic file record contained the gene and the gene product names, synonyms, sequence structural information, as well as the annotations including Enzyme evidences (E.