dataesr/scientific-paragraphs-categorization huggingface dataset:
g. , ancient or fast evolving) composite gene families (whose members do not necessarily connect all together in sequence similarity networks) (fig. 1B ). The "separator" condition implies that composite genes will remain undetected for data sets with highly remodeled genes by MF. Indeed, the repeated use of gene components introduces cyclic paths in sequence similarity networks, which turns composite families into local, but not global separators. Beyond its larger scope and better performance, CompositeSearch can also provide quality descriptions (absent from MF and FT) regarding the size and primary sequence conservation of composite and component gene families, easing critical biological analyses of these data. CompositeSearch is available at https://github. com/ TeamAIRE/CompositeSearch, last accessed November 2, 2017.
Benchmark on Simulated Data We tested and compared CompositeSearch with FT and MF  (Jachiet et al. 2013)  on 100 replicates of simulated data, covering a large range of parameters and simulating 2-components and 3-components composites (supplementary fig. S4  and Materials and Methods, Supplementary Material online). We explored the effect of gene family divergence and multiple component reassortments on composite gene detection under the hypothesis that the more divergent gene families are, the harder they are to detect. The sensitivity and specificity of each program were summarized in supplementary table S1, Supplementary Material online. In terms of detection of composite genes, CompositeSearch performs as well as FT, with identical True Positive Rate (TPR) and False Positive Rate (FPR), but, unlike FT, CompositeSearch returns composite gene families.
Benchmark on Real Data We also used a data set of 204,894 viral proteins from  (Jachiet et al. 2014 ) to benchmark our software against real data. CompositeSearch detected 21,623 composite genes clustered in 5,532 families, vastly outperforming MF (5,845 composites in 1,718 families). FT found slightly more composites (23,305), but did not return any families. This slight increase in the number of composites detected by FT was mainly due to BLAST overextending matches on real data, thus producing false positives.
Performances Because its algorithm uses a dichotomous search to browse the network and because it is multithreaded, CompositeSearch outperforms both FT and MF in terms of speed and memory use, when these parameters are contrasted on a Linux machine with Intel Xeon CPU E5-2630 v2 2. 60-GHz processors and 256 GB RAM, even on one CPU. This is especially noticeable for large metagenomic data sets (table  1 ). By contrast, construction the SSN CompositeSearch. doi:10. 1093/molbev/msx283 MBE composite genes and composite gene families detection runs in a few second to few minutes depending on the network's size.
Discussion CompositeSearch is an efficient tool that detects composite genes and composite gene families. It allows investigating the process of gene remodeling in large data sets, for example metagenomes and/or thousands of complete genomes. Although CompositeSearch is faster than currently available software, like FusedTriplets and MosaicFinder, it still can be improved. We observed that in CompositeSearch, the most time consuming step is the detection of gene families, using a DFS algorithm than runs on a single CPU. Parallelized algorithms that detect connected components are available  (Kang et al. 2009; Iverson et al. 2015) , but they usually require high computational resources. As CompositeSearch was developed with maximum portability in mind, these algorithms are not implemented yet could be in a future version.
Acknowledgments We thank  Rapha€ el Me  ´heust for his helpful and constructive discussion during the development of CompositeSearch. We also thank our beta testers  James O. McInerney ,  Mary J. O'Connell ,  Raymond Moran , and  Rob Leigh. J. S. P. and E. B. are funded by the  European Research Council  ( FP7/2017-2013  Grant Agreement # 615274 ).
PharmML 1 is an XML-based exchange format 2-4 created with a focus on nonlinear mixed-effect (NLME) models used in pharmacometrics,  5, 6  but providing a very general framework that also allows describing mathematical and statistical models such as single-subject or nonlinear and multivariate regression models. This tutorial provides an overview of the structure of this language, brief suggestions on how to work with it, and use cases demonstrating its power and flexibility.
eu). A major undertaking of the DDMoRe project was the development of a language allowing expressing a large variety of models from both pharmacometrics and QSP, and allowing their encoding in a machine understandable format that could be shared across software through the development of translators and connectors. This language, PharmML, is a declarative language, which is a necessary condition to achieve interoperability among the tools used in pharmacometrics. The use of XML to define schemas for exchange formats is widely adopted across various industries and scientific areas (https://en. wikipedia. org/wiki/Category:XML-based_standards). It allows defining domain-specific elements in a way which is both human and machine readable. The creation of the PharmML schema required in-depth analysis of pharmacometrics and the models it uses, especially the nonlinear mixed effect models, and was based on textbooks that describe the mathematical and statistical foundations of the domain.
5, 6 harmML can already interact with major software in the Modeling and Simulation arena, such as the population PK/ PD-specific software Monolix  10  and NONMEM,  9  the general statistical software R,  19  and the Bayesian inference software WinBUGS  20  (Figure  1 ). Indeed, within the DDMoRe framework, a number of converters have already been created to automate calls to these "target" software, demonstrating that PharmML can be used as a cornerstone in interoperability. This tutorial is expected to facilitate further development of these and new converters, to foster the development of PharmML editors and graphical tools, and to encourage life scientists to approach this powerful and flexible language in order to make their daily job less prone to language-related bottlenecks and more suitable for cross-fertilization.
Continuous and categorical covariates, and intrinsic or extrinsic variables that may influence the PK or PD of a drug,  5, 25  are supported, together with the declaration of their distribution, transformation or interpolation. Overall structure of PharmML Figure  2  gives a comprehensive view of a full PharmML code, with its different components delineated by colored dotted lines. The language is structured through markup constructs that provide a hierarchical definition of components and subcomponents. Each of them is called block or element (the former allows referencing) and is identified by a pair of beginning and ending tags (e. g. , <RandomEffects> and </RandomEffects>, respectively, within the Parameter Model) or by a unique self-closing tag, ending with / (e. g. , <ct:SymbRef symbIdRef5"eta_Psi"/>, again within the Parameter Model).
A Trial Design can be described explicitly or implicitly, i. e. , without or with the aid of external files, respectively. The third PharmML component is the "Modeling Steps" section containing the description of estimation, simulation, or design evaluation/optimization tasks with their characteristic features and the target software settings required for their execution (Figure  2 , red box). These three components and their main internal blocks are shown schematically in the "Supplementary information -Figures" file:.
PharmML use cases PharmML can be used to define a variety of models, trial designs, and tasks. We provide several detailed examples in a supplementary file ("Supplementary information -Figure  1  PharmML at the center of interoperability. Once a PharmML model is formulated, using the MDL-IDE or the infix2pharmml tool or translating from SBML, the model can be moved to any PharmML compatible target software and the target output can be translated into a standardized file using the SO format. Figure  2  PharmML code example: visualization of the essential elements of the code implementing a basic continuous data model (this is apparent from the observation model, adopting the <ContinuousData> tag). Note that for the purpose of illustration, the trial design section (blue) contains both the dataset sourcing (NONMEM/Monolix format) and the explicit design, but usually only one of them is used.
The modeling step section (red) declares as an example an estimation task but other tasks are feasible as well. The yellow and gray sections show lines of code providing the header and closure of the code (yellow) and the statement of the name and description of the model, its independent variable and any user-defined functions (gray). Examples") providing for each example the PharmML code, the corresponding codes for execution in at least one target software, and the output files obtained from the executions. The first use case describes the PK/PD of the anticoagulant drug warfarin; we use it to demonstrate typical PK/PD workflows including the estimation of parameters using data from a clinical study, the introduction of interoccasion variability on the PK parameters, the modeling of side effects through time-to-event models, and the use of the estimated parameters to design a new study through optimal design.
Time-to-event data models can be specified by survival or hazard functions. Middle, left: the structural model prediction can be formulated using ODEs, algebraic equations, or PK macros. Middle, right: there are three equivalent options to encode a parameter model, the "structured," "distribution," and "equation" types: an exemplification is shown for each case. Bottom, left: continuous and categorical covariates can be described via multiple options, able to define, where applicable, their distribution, interpolation, transformation, or declaration (for new covariates). Bottom, right: the variability model keeps the available information about parameter-and residual-error-related variability levels and their structure. SBML by reimplementing the mitotic oscillator model from the BioModels repository.
MODEL DEFINITION The Model Definition is the core of PharmML. It allows to encode all required components of NLME models, used to describe studies in which data are collected repeatedly (usually at different timepoints) from several experimental units (subjects). Indeed, the language contains elements to declare the models for the variability structure, the covariates, the parameters, the (deterministic) structure (of the predicted data), and the observations, as shown in Figure  2  (left). The theory of NLME is beyond the scope of the present article and can be found for instance in Lavielle's book 6 or Bonate's book,  5  from which we borrow mathematical notations and definitions here in order to explain the models covered by and expressed in PharmML. Following Lavielle,  6  we define a model as a joint probability distribution describing the relationships between variables.
The second description level of a general NLME model is the parameter model, describing the distribution of the parameters w i : each individual parameter is described through a typical population parameter, w pop , some individual covariates, c i , the coefficients of the fixed effects from those covariates, b, and a subject-specific random effect, g. Both the continuous responses of the observation model and the individual parameters of the parameter model can require transformations (u(Á) in the former and h(Á) in the latter case): as detailed below, PharmML allows to encode the transformed (or untransformed) data and parameters in multiple ways, i. e. , through the definition of distributions, structured equations, or arbitrary functions (U(Á) in the observation model and H(Á) in the parameter model).
Various elements of the NLME models, e. g. , the probability of observing a given residual error, or the distribution of parameters or covariates, are described using a wide range of probability distributions. Encoding of these elements can be greatly facilitated with an external reference database of distributions. For this purpose, DDMoRe developed Pro-bOnto (http://probonto. org), a knowledge base and ontology covering a large family of distributions. 26 4] 27  The rest of this section describes the different parts of the PharmML Model Definition. A detailed overview of its structure is provided by Figure  S2  in the "Supplementary information -Figures" file.
). The Gaussian implementation for the combined error model y5f 1ða1b fÞ $ Nð0; 1Þ (2) where a and b are the parameters of the error model, is provided in CS-2. 1. Another option to specify the observation model is the explicit distribution notation, used for example in WinBUGS, which in its general form reads uðyÞ $ DistribNameðp 1 ; p 2 ;. Þ ( 3 ) where DistribName is the name of a suitable distribution and p1, p2,. are its parameters. (2) reads in this format y $ Nðf ; ða1b fÞ 2 Þ (4) which corresponds to the PharmML code in CS-2. 2, using the element <General> and its child element <Distribution>. A third option, using the <AssignStatement> element, is to utilize an explicit equation-type notation for which an arbitrary expression on the right-hand side is permitted: uðyÞ5Uðf ; n; 1 ; 2 ;.
Covariate model The covariates used to define the individual parameters are described in the <CovariateModel> block, which provides the modelers with multiple options to declare and perform various operations on categorical and continuous covariates. The definitions in this model can be overwritten by declarations in the <TrialDesign> block. The available options are provided below. Distribution. As an example, the following snippet implements a conditional log-normal distribution of body weight, W, for male, SEX 5 M, and female, SEX 5 F, with genderspecific parameters for the mean, l (F,M) , and the standard deviation, r (F,M) : W $ LNðl F ; r F Þ if SEX 5F (18) W $ LNðl M ; r M Þ if SEX 5M (19) This is the PharmML code (see CS-5. 1 for the full implementation), using the <Distribution> element: Variability affects here the volume of distribution, V, which is assumed to be log-normally distributed.
CS-5. 2 and CS-5. 3 provide the codes for the definitions of both creatinine clearance and sex. Interpolation. When continuous covariates are provided through datasets or lookup tables, they appear as timediscrete values. Within the <Interpolation> element, the modeler can decide to use her/his own interpolation algorithm for the intermediate values or choose one from the following list: constant, nearest, linear, spline, pchip, cubic, lastValue. PharmML allows also to declare independent interpolation variables with respect to which the covariate of interest is to be interpolated: e. g. , body weight may be interpolated with respect to age or trial duration (see CS-5. 4 for an example). Transformation. Covariates, once defined, may be transformed through a mathematical expression, yielding a new symbol identifier (symbID) via the <TransformedCovariate> element to distinguish it from the base covariate.
Explicit design For an ODE system, inputs can be the initial values for each model component (e. g. , the initial amounts in the www. psp-journal. com Figure  6  Model-Design-Task: the creation process of a whole PharmML model out of its different components. Top: data type determines the observation and structural model choice. Middle: trial design can be sourced from a dataset or encoded explicitly. Dependent on the clinical study characteristics, the modeler can encode a single subject design, a standard population design, or an optimal design. Bottom: once the model and design are specified, the task and the related settings remain to be declared (see Figure  8  for a detailed representation of this block). The DS (dataset) mark identifies elements where data records can be stored inline or, alternatively, where references to external dataset files can be defined.
Right: complete dataset declaration with column mapping (the dataset is shown as a table for better readability). One <ColumnMapping> element is used for each couple model variable (red)correspondent data column (yellow). In certain cases, such as with categorical covariates, the <CategoryMapping> element is required to map the categorical symbols to the respective symbols used in the dataset. 1) occasions, a within-subject level of variability, may be defined with the <Occasions> element, and associated with a time frame (defined through a vector of start times) to identify different occasions for each subject in the corresponding arm; 2) covariate distributions may be defined with the <Covariates> element, and possibly supersede previous analog definitions (see CS-6. 2).
Optimization takes place under a set of constraints including the total cost (usually equal to the number of samples, but more complex cost functions can also be used) and is executed in different software. 31 These features are specified within the Modeling Steps block of the PharmML code (see Modeling Steps). Dataset declaration and data/model mapping When a trial is actually performed, we can expect deviations from the dosing and sampling schedules specified in the protocol. For instance, a patient may forget to take a dose or make a mistake on the dose amount, or the sample collection may be delayed or omitted. In such cases, individual protocols are extracted from a dataset providing subject-specific observation times, interventions, occasions, and covariate values: the set of individual protocols constitutes the empirical population design.
PharmML has the ability to declare references to external dataset files as well as to encode dataset records explicitly, i. e. , inline (see the "DS" marks in Figure  6 , middle, and CS-7. 2 for an example). Moreover, it is possible to store all observation, dosing, and covariate data in a unique dataset (see Figure  6 , middle right). With respect to this latter option, PharmML supports the most popular NONMEM-type dataset format or the slightly different Monolix-type format, and virtually any tabular format in which data are organized by columns. The declaration of such a dataset is located in the <TrialDesign> section, in the <ExternalDataSet> block. This block must contain a reference to the external file in which the data are stored (element <ExternalFile> in the <DataSet> block), as well as information on how to interpret each column (elements <Column> in the <Definition> component of the same block).
MODELING STEPS The <ModellingSteps> block describes the tasks typically used in pharmacometrics and QSP, such as estimation, simulation, and design evaluation or optimization (Figure  8 ). It starts with the (optional) specification of the target tool and is followed by the definition of one of three predefined elements, <EstimationStep>, <SimulationStep>, or <OptimalDesignStep>, each holding a number of specialized elements. Here we concentrate on the high-level description of the estimation task only, for which a representative complete code is available in CS-8. When performing an estimation task, it is necessary to declare the data used to estimate the parameters of the model. This can be done in two ways. The first is to refer, via the <ExternalDataSetReference> element, to the NON-MEM/Monolix data file defined in the Trial Design within the <ExternalDataSet> element (CS-7.
WORKING WITH PharmML Interacting with PharmML This tutorial has presented so far the PharmML structure and how various model elements can be implemented within it. Moreover, the online "Supplementary information -Examples" file contains a number of complete real-life use cases with detailed descriptions. PharmML, however, is merely an encoding format and any actual execution requires a software infrastructure to use it, i. e. , to read, write, validate, and convert the XML of a PharmML model into a form understandable by a target software, and then to run the defined task. The first three jobs are taken over by LibPharmML, a JAVA Application Programming Interface (API) also developed by DDMoRe. The API is available via SourceForge within the libPharmML project (https://sourceforge. net/ projects/libpharmml.
ddmore. p). A stand-alone validator, executable via command line, is also provided. Documentation for the validator is available in the libPharmML wiki (https://sourceforge. net/p/ddmore/libpharmml/wiki/Home/). The software element that transforms PharmML to target specific code is the converter. Unlike SBML, PharmML describes both the models and the tasks performed on them. This allows a converter to read a PharmML file and to create from it executable source code for both the mathematical elements and the tasks required in the target script. The entire information necessary to transform PharmML into a target code is encapsulated within the converter; an all-encompassing software library is not required to execute PharmML models, as model transformation is handled by the converter and calculation elements are delegated to the target software.
DDMoRe has developed a standardized converter library for PharmML called CCoPI-Mono (CM). CM is a Java library that runs in conjunction with libPharmML to convert a PharmML model into target-specific code. CM has code generators for NONMEM, MATLAB/Octave, R, Python, C/ C11, and FORTRAN. As both SBML and PharmML are interoperable, CM can convert standard SBML models into PharmML. CM has a component to convert an SBML pathway model into an ODE form, which can readily be expressed in PharmML. Once in PharmML form, an SBMLderived model can be executed in platforms that do not traditionally work with SBML, such as Monolix or NONMEM. The reverse direction, translation of PharmML to SBML, is also possible but is limited to the structural model only, as SBML does not support the encoding of any statistical model component.
Finally, if a modeler needs/wants to write a PharmML model from scratch, two DDMoRe tools may support this task. One of them is the infix2pharmml tool, available as a free web service and able to translate expressions from the usual mathematical infix notation into the corresponding PharmML markup (http://infix2pharmml. sourceforge. net/). The other tool is the MDL-IDE, a framework for creating and editing models in the human writeable and readable language MDL 32 : within the same framework, it is possible to translate the MDL code into the corresponding PharmML code. The MDL-IDE benefits from the use of the SO, another XML-based exchange format developed within DDMoRe to store the results of any pharmacometric analyses in a standardized way, so that they can be later recalled, reused, and transferred from one analysis step to another.
DISCUSSION The present tutorial is an introduction to PharmML, a new markup language designed to encode models and analyses in pharmacometric and system pharmacology applications. As an XML-based language, it is structured around a series of specialized hierarchical sections, each addressing a different component of the model, starting with the Model Definition (with covariate, observation, parameter, structural, and variability submodels). The section Trial Design allows specifying the design either through a data reference or as an explicitly coded study structure. A final section, Modeling Steps, contains a description of the activities that can be associated with the model object and of the software settings and variables associated with them: typical tasks involved in pharmacometric and QSP applications are estimation, prediction/simulation, and optimal design, and all of them can be combined within PharmML to define workflows.