dataesr/scientific-paragraphs-categorization huggingface dataset:
In preliminary analysis we found that the model did not converge onto the entire dataset. To identify children whose CD4-for-age trajectories followed Equation 1 (''asymptotic reconstitution''), each child's CD4 counts were modelled individually, using least squares to fit each child's data to Equation  1. Children were divided into two groups: one in which the least-squares fit had converged, and the other in which it had not. The first group thus consisted of children with asymptotic reconstitution, while the other comprised children with qualitatively different CD4 reconstitution profiles. Modelling asymptotic reconstitution profiles. In the group with asymptotic CD4 reconstitution, recovery was analysed using nonlinear mixed-effects models for ln(CD4-for-age), based on Equation  1. The mixed-effects model assumes that in each child the values of the three parameters int, asy, and c are the sum of a fixed effect-which describes the average response in the whole population of children with asymptotic reconstitution-and a normally distributed random effect-which accounts for and describes inter-individual variability.
A normally distributed error term e ij is added to Equation 1 to represent noise, measurement error, and model mis-specification. We investigated the predictive value of age, sex, WHO disease stage, height-and weight-for-age z-scores at ART initiation, and randomisation to monitoring and first-line ART strategies on proportional recovery rate (c) and CD4-for-age at ART initiation (int) and in the long term (asy), using a backwards-selection procedure based on an exit p = 0. 01 to favour parsimony and avoid including small significant but clinically unimportant effects given the size of the dataset. Height-and weight-for-age z-scores were calculated using UK norms, which, unlike WHO references, cover the whole childhood age range  [28]. Characterising non-asymptotic reconstitution. In children without asymptotic CD4 reconstitution, we used linear models to fit CD4-for-age trajectories and identify those with increasing or decreasing CD4-for-age, those in whom CD4-for-age did not change significantly, and those with insufficient data to characterise a recovery profile.
ARROW is funded by the  UK Medical Research Council  and the  UK Department for International Development (DFID). ViiV Healthcare/GlaxoSmithKline  donates first-line drugs for ARROW. JL was supported by an  Engineering and Physical Sciences Research Council Life Sciences   Interface Doctoral Training Centre studentship  at the  Centre for Mathematics and Physics in the Life Sciences and Experimental Biology (CoMPLEX) , and also received support from the  National Institute for Health Research Biomedical Research Centre Funding Scheme at Great Ormond Street Hospital  and the  Institute of Child Health. NK was partly supported by  Great Ormond Street Hospital Charity. The work was also supported by funding from an  MRC  Grant  G1001190. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
ACKNOWLEDGMENTS Our research described in this review was supported by the  Agence National de la Recherche sur le SIDA (ANRS) ,  Sidaction , and the  Agence Nationale de la Recherche  ( ANR-10-EMMA-0012  grant). We apologize for failing to cite work that may have been relevant but was omitted due to space limitations. The authors thank  K. Arien  and  G. Vanham  for helpful discussions, and their collaborators ( F. Arenzana-Seisdedos ,  F. Baleux ,  D. Bonnaffé ,  P. Clayette ,  E. Crublet ,  Q. Sattentau , and  R. Vivès ) that have, in one way or another, contributed to the research described here.
The two sets of benchmarks resemble strongly each other, except that in the case of the second set we have added large performance gains or losses for certain alternatives in the sets. Secondly, we may notice that the approaches of building the profiles using simple operation on the evaluations of the alternatives in each set generally perform poorer than all the rest. A few exceptions occur when constructing bounding profiles, where the proposed approach is always able to build an upper bounding profile that outranks all the alternatives in the set and a lower bounding profile that is outranked by them. Any fitness results that are above these highlight the fact that we have constructed bounding profiles that come closer to the alternatives in the set, i. e. indifferent to them. The meta-heuristic approaches improve on the results given by the approach of selecting an existing alternative from the dataset.
As clustering may be seen as an exploratory data analysis technique, being able describe clustering results over large sets of alternatives, using a considerably smaller set of central, bounding or separating profiles, would greatly enhance the exploration and understanding of the original dataset. Furthermore, these profiles could also be used in conjunction with the problems of choice and ranking, provided that large groups alternatives are generated as results to these problems. Finally, being able to summarize the information given by a set of alternatives may additionally aid in a process of eliciting the preferences of a DM over large sets of alternatives. We will explore these topics in the future.
Tutorials and course materials on http://www. algodec. org. XMCDA data encoding resources and webservices on http://www. decision-deck. org. Content of the lecture GDRI AlgoDec Algorithmic Decision Theory Decision aiding Bibliography Decision Deck Online Resources 44 contributions on Algorithmic Decision Theory contain videos and presentation materials ori-ginating from the tutorials and courses who took place at the meetings and doctoral schools organised by the COST Ac-tion IC0602 Algorithmic Deci-sion Theory. The Decision Deck project aims at collaboratively develo-ping Open Source software tools implementing MultiCriteria De-cision Aid (MCDA) techniques which are meant to support complex decision aid processes and are interoperable in order to create a coherent ecosystem. 9 / 40 10 / 40 Content of the lecture GDRI AlgoDec Algorithmic Decision Theory Decision aiding Bibliography Content of the lecture GDRI AlgoDec Algorithmic Decision Theory Decision aiding Bibliography 1.
Recently many international initiatives have been developed to improve access to scientifi c information and to promote open data sharing. In the complex fi eld of bioresources, the BRIF (Bioresource Research Impact Fac-tor) project aims to create suitable methods to recognise and measure the use and impact of biological resources in scientifi c/ academic work, in order to maximize access by researchers to collections of biological materials and attached databases, and to recognize efforts involved in their maintenance. The lack of a proper recognition of scientifi c contribution is in fact a major obstacle which impedes bioresource sharing. In this context, the BRIF initiative can be considered as a tool to facilitate research resource sharing,.
THE BRIF INITIATIVE Bioresources are collections of biological samples (biobanks) with associated data (medical/epidemiological, social etc. ) but also databases without samples, or other bimolecular and bioinformatics research tools  (2). Much of our present-day medical knowledge is acquired with the aid of such collections. The main objective of the BRIF project is to promote the sharing of bioresources by creating a link between their initiators/implementers and the impact of scientific research using them. The BRIF international working group aims to develop suitable tools to assess the impact of bioresources and facilitate their traceability  (4, 5). At publication level the effort of recognition of stakeholders in establishing and maintaining such resources is often neglected and/or highly heterogeneous and there is an urgent need to establishing guidelines for the citation of such contributions.
In such a context, the issue of openness of research data is particularly relevant and its application in the field of bioresources is a good example of the complexity associated to data sharing, even when its benefits are fully recognized. The main topics of the public consultation that EC addressed to different stakeholders are synthetically expressed by the following questions: The meeting in Rome offered an opportunity to discuss the issues of open research data with regard to the EC proposal. The outcome of the discussion was orally reported in the EC consultation held in Brussels on July 2, 2013 in the form of a short oral presentation. In particular, there was a general agreement that EC should attentively consider the bioresources as relevant sources of aggregated open research data with a strong impact on both science and society.
Acknowledgements  Elena Bravo ,  Alessia Calzolari ,  Anne Cambon-Thomsen ,  Paola De Castro ,  Laurence Mabile ,  Federica Napolitani  and  Anna Maria Rossi  are part of the  "Bioresource Research Impact Factor" (BRIF) initiative  (http://www. gen2phen. org/groups/brifbio-resourceimpact-factor). The work here reported was partially supported by collaborative projects of the  European Commission   FP7 GEN2PHEN  ( Genotypeto-Phenotype Databases: A Holistic Solution ), grant agreement  200754 ,  BioSHaRE-EU (Biobank Standardisation and Harmonisation for Research Excellence in the European Union) , grant agreement  261433 , and  BBMRI-Large Prospective Cohorts (BBMRI-LPC ) grant agreement  313010.
Background: With the advance of post-genomic technologies, the need for tools to manage large scale data in biology becomes more pressing. This involves annotating and storing data securely, as well as granting permissions flexibly with several technologies (all array types, flow cytometry, proteomics) for collaborative work and data sharing. This task is not easily achieved with most systems available today. Findings: We developed Djeen (Database for Joomla!'s Extensible Engine), a new Research Information Management System (RIMS) for collaborative projects. Djeen is a user-friendly application, designed to streamline data storage and annotation collaboratively. Its database model, kept simple, is compliant with most technologies and allows storing and managing of heterogeneous data with the same system.
Finally, each additional device installed in the laboratory implies training users on new laboratory practices since all LIMS are designed with different user interfaces (UIs). Subsequent fragmentation of systems and resources has a negative impact on quality control (QC). Moreover, administrating heterogeneous LIMS is a complex task that cannot be assumed by a typical wet laboratory structure that does not have the bioinformatics expertise and development resources to adapt tools to its specific needs. Because of these limits, typical LIMS do not favor interdisciplinary and translational collaborations and thus prevent the transfer of knowledge among laboratories generating heterogeneous information that has to be integrated. In this report, we describe the Database for Joomla!'s Extensible Engine (Djeen), a new generation of LIMS that features a simple technological conception coupled with an advanced capacity of adaptation to be directly used or easily adapted to different technologies.
The Djeen database scheme is kept simple to maximize generalization and application possibilities. Only data organization and metadata (annotations) are stored within a database, while experimental data is organized in the file system. In addition, the program is adaptable to any technology since no technology-dependent semantics were used in the code. Djeen can therefore evolve with user and laboratory needs. Since most technology can be managed with Djeen, this allows for unification of all information systems within the lab. Djeen features a large functionality set (import-export, multi-technological implementation, advanced user/groups permissions) and is conceptually more advanced than other LIMS publicly available. Djeen qualifies as a Research Information Management System  [9]. As such, Djeen addresses four fundamental issues in high throughput biomedical data management: data organization, data sharing, collaboration and publication.
Data organization consists in allowing straightforward data retrieval without the presence of the person who generated them. Therefore, data must be securely stored in a standardized way. Data sharing consists in allowing several collaborators to access the same data, while avoiding data duplication or data reformatting. Collaboration is an important aspect of dataset entry and development; it allows several collaborators to manage and maintain the same data, which means that the data is not organized by a single individual. Finally, data publication encompasses secure data sharing for a large group of users (over the Internet or intranet).
Also, there is a strong dependence on the software's vendor and his ability to follow up on the product and insure longevity, which is not guaranteed. Djeen being open source and under CeCILL license, anyone can contribute to it and it will stay available. A number of publicly available open source LIMS exist, and partially addressed the issues described in this paper. Many LIMS are inherently limited to a single technology type, i. e. Proteomics (ms_lims,  [7] ) or microarray (BASE  [6] , or the Longhorn Array Database  [5] ), which is a serious limitation for many laboratories, who need the same system to store all their data. Djeen allows for managing heterogeneous datasets within the same system. Other LIMS can be used to manage multiple technologies. MADMAX  [11]  allows for the storage and analysis of heterogeneous genomics data in the same repository.
However, its implementation is rather complex and based on an Oracle (Redwood City, CA, USA) Database Management System (DBMS), which can be a limiting factor for some laboratories with limited resources. Djeen is based solely on open-source technology, being its database (MySQL or PostgreSQL) or the Content Management System (Joomla!). SIGLa (Systema Integrado de Gerência de Laboratoriós,  [12] ) is based on a workflow management tool that makes it also adaptable to multiple usages. The concept of workflows is not needed by all users and increases dramatically the complexity of data entry. Therefore, workflows are not hard-coded into Djeen to avoid technology-specific code but can be used with annotations when needed. BonsaiLIMS  [13]  is a lightweight LIMS developed initially to centralize patient records for translational research.
User collaboration User collaboration goes beyond data sharing. It implies that datasets are built and contributed to by several collaborators while general project structure and annotations are under the control of a project owner. In Djeen, once permissions are set to appropriate users or groups, project administrators can control homogeneity of annotations with templates. Templates allow enforcing data integrity and homogeneity as well as quality control (QC). Their role is detailed in the 'Data organization and Djeen elements' section.
Content management system Djeen was developed as an extension of the Joomla! Content Management System (CMS). CMS are a category of applications allowing the management and the publication of content, "content" being defined rather loosely (see  [14]  for a review of CMS usage in bioinformatics). In our case, it is related to scientific information, and more precisely, data and their annotations. CMS are very attractive since they are characterized by a modular design and allow for development of new applications for visualizing content. Reuse of CMS tools for web application development potentially simplifies things and allows programmers to focus on the application features instead of spending time on redeveloping a number of generic functionalities, such as site administration and visual design.
Integration within the Joomla! CMS To understand how Djeen interacts with Joomla!, a summary of its architecture and function is given. As shown in Figure  1 , Joomla! was conceived as a three tier system based on this MVC structure, to separate data access (Models), rendering system (Views) and actions (Controllers). The purpose of the framework layer is to manage data within Joomla!, it includes different classes and libraries to access database and file system. The application layer manages Joomla!'s UI, such as administration panel and public website. Finally, the extension layer includes templates to change the website rendering and extensions to change or extend Joomla!'s functionalities. Modules are used to display additional data bits and pieces into specific 'boxes'. Components are a more advanced type of extensions that allow developing full fledged applications while granted access to the Joomla! API.
Djeen is a Component and implements its own database and a dedicated repository. By using the Joomla! API, Djeen is deployed and managed from the Joomla! administrator panel. No third party software or client is needed and compatibility was validated on the Mozilla Firefox® and Google Chrome® browsers (current versions as of publication). The application is embedded to the Joomla! front-end website through the application layer. Data security is ensured by a complete separation of Djeen and Joomla! databases to facilitate backup and keeping Djeen as an independent component at every level. Djeen objects are stored within a specific relational database (PostgreSQL and MySQL drivers are provided) while files are simply stored in the file system. The connection to the Djeen external database is ensured by a second security level that uses an encrypted password stored into the component configuration.
Data organization and Djeen elements In this section, Djeen objects (such as Projects and Templates) are refereed to with a capital letter. These are simply referred to as generic terms in subsequent sections. Figure  2  shows the Djeen data model main elements and the duality files-database. The File object is the central piece of information within Djeen, since it represents the lowest granularity level in most highthroughput analyses. This model and the associated code were designed to be technology-independent and free of specific semantics to stay adaptable to multiple data types and as generalizable as possible. In the database side, the main Djeen entity to manage data is the Project. Projects are organized in a hierarchy and a Project can reference multiple sub-Projects. This hierarchy is mirrored in the corresponding directory organization on the file system side.
Web Interface and Djeen functionality Djeen's UI was designed to facilitate navigation and manipulation of data as intuitively as possible and features a fast learning curve. To optimize interoperability with Joomla! and maximize its maintainability, Djeen was mainly developed in PHP. A data uploader was developed in Perl to allow massive data transfers (of several GBs) for importation of large sets of raw data. All table rendering and user interaction code was implemented an Ajax/Javascript layer through the Mootools library (http://mootools. net). Additionally, a customizable dialog box was made available for administrators to display information such as an End-User License Agreement (EULA) for users, as well as any other information or error messages. The Djeen UI main elements are represented Figure  3.
A notification zone displays messages returned by the system (I) in an elegant and non-intrusive manner. (I) icons are functions present in most tables, namely "Print" and "Export". Icons (J) are general project actions including "Print", "New Project", "Edit", "Copy as template", "Copy in Clipboard" and "Clear Clipboard". Annotations can be either typed within the Djeen interface or imported from preformatted CSV files. Direct annotation entry is facilitated with an integrated advanced table formatting tool. Multiple data files can also be imported at once (using zip or tar archives) and default annotation values specified to speed up data entry. In a set of annotations, the variables that represent the biological question can be flagged to explicitly mark the datasets that could potentially be integrated since they address similar biological question.
Results and Discussion To demonstrate Djeen functionalities and purpose, we describe a detailed microarray importation and management procedure for a microarray dataset of breast cancer patients annotated with clinical conditions. While this specific example is concerned with microarrays, it is also easily applicable to other data types. Specific tutorials detailing management of microarray and flow cytometry data are accessible from the Djeen documentation. The dataset used in the current example  [16]  is publicly available from the Gene Expression Omnibus (NCBI GEO, http://www. ncbi. nlm. nih. gov/geo) under the accession number "GSE7390" This dataset spans 198 CEL files, each of them corresponding to a single breast cancer tumor sample. To be able to enforce annotation format and keep consistency among projects, we set up a template for sample annotation that can be re-used by other projects.
Preparing the project hierarchy within Djeen First, the data must be stored at the appropriate location within Djeen. This depends on the local organization of data as well as on the studied data type. In all cases, careful consideration of the adopted hierarchy must be taken. For our own purpose, we will create a meta project "breast cancer" and then a sub project "Desmedt et al. Local Copy" for the data at hand. This is done by clicking on the general tab "Projects". By using the add button ("+"), a new metaproject called "Meta_Breast_Cancer_Transcriptome" can be added. Dataset description can be filled here, for instance "Meta Breast Cancer Transcriptome project grouping multiple datasets". Permissions can be specified to limit access to the data. Since this is a publicly available dataset, it can be shared with people already registered to the system.
All changes are saved by clicking on the "Save" button. Similarly, a sub-project is being defined to store and describe the data. This is done by clicking the "sub-project" tab, creating a new project called "GSE7390 (Desmedt et al. )". No template is being defined at this point. Again, a description can be added as free text. Permissions are also left to their default settings: access to registered users. Again, changes are saved by a click on "Save". The previous steps generate the following project hierarchy: "Meta_Breast_Cancer_Transcriptome'->'GSE7390" Importing microarray data (CELs files) The full test dataset can be directly downloaded from the Gene Expression Omnibus database using the accession number GSE7390. After downloading the full archive, all CEL files are imported within Djeen by a click on the "File" Icon under the "GSE7390" project.
it allows a project administrator to insure that the data is MIAME compliant and second, it allows re-using the same annotations for other datasets. Templates are added from the Template section of Djeen. For our example, it will be named "Breast Cancer Transcriptome Template". Keywords can be specified as follows: "Transcriptome Breast Cancer Clinical Data". The description can be specified as 'Template for describing microarray of breast cancer samples'. Changes are saved in the system by a click on "Save". Then, the two template key elements must be populated: Characteristics (variables specific to the dataset) and Annotations (variables specific to samples). In our case, the Characteristics are: "Author", "Original GEO/ArrayExpress Accession Number", "Organism", "Platform Vendor" and "Platform Type".