dataesr/scientific-paragraphs-categorization huggingface dataset:
Contacting the corresponding authors of identified RCTs Corresponding authors of each RCT were contacted by personalized email to participate in a specific IPD MA project and to provide IPD from their RCT. The email stated that the French Cochrane Centre aimed to initiate collaboration among trialists to perform IPD MAs on important orthopaedic topics and that the first project had as an objective the clinical research question for which the RCT was eligible. We guaranteed protection of patient data and secure storage of datasets. We also systematically asked whether the corresponding author or another colleague wanted to be a co-author of the published IPD MA and whether we should cover costs related to data extraction. The emails were personalized for each trialist and clinical research question, with inclusion of the name of the corresponding author, title, year of publication and journal in which the author's trial was published, as well as the objective of the IPD MA and a link to the protocol synopsis of the IPD MA corresponding to the research question assessed.
The rate of response could have been higher if we had contacted authors by telephone or postal mail. Also, it could have been higher with the collaboration of learned societies. We were able to contact only 79 % of investigators because of invalid email addresses, which can be explained by their moving to another institution. Author identification initiatives and online research profiles such as ResearchGate could help identify contact information of investigators  [32]. The positive responses we received were an agreement to share IPD, but with no guarantee to finally obtain the IPD, so we may have overestimated the real number of datasets available for our IPD MA projects. Finally, Hannink et al. [4]  identified an IPD MA published in 2011 assessing a question close to one of our 38 questions, which may explain the lack of positive response for this question  [33].
Possible explanations and implications The arguments given by corresponding authors for refusing to send IPD agree with the barriers to data sharing described in the literature: concerns about protecting patient confidentiality and anonymity  [1, 7, 40] , lack of time and costs  [1] , and unusable datasets  [1]. Practical solutions and guidelines to circumvent those obstacles have been proposed  [12, 14, 40, 41] , but significant efforts must be made to raise the awareness of the surgical community about the benefits of data sharing. Data sharing is a necessary condition to perform IPD meta-analyses, recognized as providing the highest level of evidence. This type of study is of great interest in domains for which randomized controlled trials are difficult to perform, such as in surgery to increase precision and power, to improve external validity and to perform subgroup analyses.
Major academic funders as well as some pharmaceutical companies are also adopting policies to support this sharing of data. This movement should also spread to surgical domains. Specialized journals, learned societies, funders as well as research leaders have a major role to play to help improve data sharing in surgical domains. Nevertheless, there are practical issues as sharing data 10 years after the completion of a trial may be difficult related to availability and format of data, and because there is no patient consent. The responsibility for cleaning, storing and sharing databases is so far supported by individual researchers. As outlined in an article published in Current Biology, in the long term, research data cannot be reliably preserved by individual researchers  [32]. Data cleaning, storage and export in a suitable format represent an important burden for researchers with no specific funding dedicated to this process.
It was shown  [37]  that a particular diet is able to increase the gene richness: an increase of genes was observed with the LGC patients after a 6-weeks energy-restricted diet. [38]  conducted a similar study with Dutch individuals, and made a similar conclusion: there is a hope that a diet can be used to induce a permanent change of gut flora, and that treatment should be phenotype-specific. The goal of our experiments is to predict to which group a patient belongs, and it is a binary classification problem. Another challenge is to find a compact subset of biomarkers which minimizes the prediction error. 5. 3. 1 Brief Data Description. The MicrObese corpus contains meta-data (clinical data), gene expressions of adipose tissue, and gut flora metagenomic data. For each patient, we have the information to which class he or she belongs.
Acknowledgments The clinical work was supported by  Agence Nationale de la Recherche  ( ANR MICRO-Obes ),  KOT-Ceprodi  and the association Fondation Coeur et Arteres. All ethical agreement are obtained. This work is also part of the  European Union 's  Seventh Framework Program  under grant agreement  HEALTH-F4-2012-305312  ( Metacardis  project). MicroObese Consortium list of contributors:  Aurélie Cotillard ,  Sean P. Kennedy ,  Edi Prifti ,  Nicolas Pons ,  Emmanuelle Le Chatelier ,  Mathieu Almeida ,  Benoit Quinquis ,  Florence Levenez ,  Nathalie Galleron ,  Jean-Michel Batto ,  Joel Doré ,  Stanislav Dusko Ehrlich ,  Catherine Juste ,  Tomas de Wouters.
Acknowledgments This work was supported in part by the joint research program MANON between  CEA-Saclay and University Pierre et Marie Curie-Paris 6. This work was also supported by  Fondation Sciences Mathmatiques de Paris, OSD/AFOSR/MURI  Grant  FA9550-09-1-0613 , and  ONR  Grant  N00014-11-1-0713. We would like to thank  Prof. F. Hecht  for very valuable advices regarding our numerical simulations with FreeFem++ [21, 22].
, 2013b ). All the algorithms were coded in MATLAB. To fit the stochastic Kriging models, we used the code provided on http://stochastickriging. net/ , for CKG we used the code on http://people. orie. cornell. edu/pfrazier/src. html , the TSSO code was based on http://www. ise. nus. edu. sg/staff/ngsh/download/ matlabdocs/SOK/ and the eTSSO code was obtained from the authors of  Liu et al. (2014). The remaining algorithms were coded by the authors themselves and compared with the DiceOptim package in R  ( Picheny & Ginsbourger, 2014 )  to ensure correctness. As most of the algorithms allow for revisits, the covariance matrix of the metamodel may become ill-conditioned; we follow the guidelines in Section 4. 3 of  Picheny and Ginsbourger (2014)  for handling this issue. Table  7  shows the average running time of different algorithms for one macroreplication in all the test problems (on a Dell desktop with 3.
Acknowledgments This research was supported by the  Research Foundation-Flanders (FWO)  (Grant no. G. 0822. 12  ). We would like to thank  Professor Szu Hui Ng ,  Department of Industrial & Systems Engineering, National University of Singapore , for sharing eTSSO code with us. Some of the computational resources and services used in this work were provided by the  VSC (Flemish Supercomputer Center) , funded by the  Hercules Foundation  and the  Flemish Governmentdepartment EWI. We thank the two anonymous reviewers for their constructive comments, that substantially improved the paper.
The development of magnetic resonance imaging (MRI) techniques has defined modern neuroimaging. Since its inception, tens of thousands of studies using techniques such as functional MRI and diffusion weighted imaging have allowed for the non-invasive study of the brain. Despite the fact that MRI is routinely used to obtain data for neuroscience research, there has been no widely adopted standard for organizing and describing the data collected in an imaging experiment. This renders sharing and reusing data (within or between labs) difficult if not impossible and unnecessarily complicates the application of automatic pipelines and quality assurance protocols. To solve this problem, we have developed the Brain Imaging Data Structure (BIDS), a standard for organizing and describing MRI datasets.
Adoption of a common standard to describe data and its organization on disk can provide multiple benefits: • Minimized curation: Common standards make it possible for researchers who were not directly involved in data collection to understand and work with the data. This is particularly important to ensure that data remain accessible and usable by different researchers over time in the following instances: a) within a laboratory over time, b) between labs facilitating collaboration and making combining data in multi-center studies easier and less ambiguous, c) between public databases (i. e. OpenfMRI) allowing for the quick ingestion of big data organized according to a common scheme.
• Error reduction: Errors attributed to the misunderstanding of the meaning of a given datum (e. g. , when variable names are not explicitly stated in the data file and standardized across files). • Optimized usage of data analysis software is made possible when the metadata necessary for analysis (i. e. details of the task or imaging protocol) are easily accessible in a standardized and machine-readable way. This enables the application of completely automated analysis workflows, which greatly enhances reproducibility and efficiency. • Development of automated tools for verifying the consistency and completeness of datasets is realized. Such tools make it easier to spot missing metadata that limit how the data could be analyzed in the future. Previous approaches to neuroimaging data management typically involved complex data management systems  [2] [3] [4] [5] [6] [7] [8].
However, the challenges associated with installing and maintaining an additional software application, and interacting with one's data primarily through that application, may outweigh the benefits for smaller labs with limited technical resources  9. In addition, the vast majority of data analysis software requires access to files stored on a hard drive, which is only directly supported by some neuroimaging data management systems. This leads to the need for exporting datasets to a filesystem as the first step of any analysis  10. The goal of previous databasing approaches has been to efficiently store and manage data rather than creating a format for describing and standardizing it. In contrast, the XML-based Clinical Experiment Data Exchange schema (XCEDE)  11  attempted to provide a standard for describing results of clinical, including neuroimaging, experiments (independent of any particular databasing system).
The approach used by XCEDE employs the eXtensible Markup Language (XML)  12  to provide a hierarchical description of a dataset. This description includes location of every data file along with metadata. Due to the fact that location of files is decoupled from their purpose, XCEDE supports any arbitrary arrangement of files on the hard drive (or even remote locations). In addition, it does not provide any recommendation on the choice of the file format that the imaging data should be stored in (which puts burden of data conversion on the shoulders of tool developers). Unfortunately, the XCEDE format was not widely adopted, although a number of useful tools were developed  [13] [14] [15]. We suspect that the combination of extensive use of XML (which is hard to use for scientists without informatics expertise), lack of specification of the file format details, as well as relatively limited support in data analysis packages all may have contributed to the low adoption rate.
In a similar fashion to XCEDE, the OpenfMRI database  16  introduced a dataset description format to fulfill the needs of data curation and dissemination. It relies heavily on specific file naming schemes and paths to convey the functions of files, which allows the application of automated analysis workflows for the entire processing stream. The use of specific filenames and paths can be initially viewed as a limitation in contrast to XCEDE, but it makes it much easier to write software to analyze the data since it does not require consulting additional files (XML descriptions) to understand the purpose of a particular file. In addition, the OpenfMRI standard uses the Gzip compressed version of the Neuroinformatics Informatics Technology Initiative (NIfTI) format  17  to achieve a balance of data analysis software compatibility and file size.
This avoids the need to convert between file formats as may have been necessary with XCEDE since it did not specify a particular file format (given that many software tools are limited in the formats that they can read). An important limitation of the OpenfMRI standard is that it had no explicit support for a number of important data types including physiological recordings, diffusion weighted imaging, or field maps, and also had no formal scheme to accommodate longitudinal studies with multiple visits. Despite these limitations and the fact that the OpenfMRI standard was designed to fulfill the needs of one particular repository, it has provided a unified and simple way to organize and describe data. This led to it being adopted (with some modifications) as an internal standard for organizing data in a number of laboratories as well as support by Nipype workflow engine  18.
Dataset description can also be considered part of provenance. W3C PROV standard defines provenance as "information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness"( https://www. w3. org/TR/prov-overview/ ). Considering this definition metadata describing for example scanner field strength used to obtain MRI data fall into this category. However, most neuroimaging literature discussing provenance focuses on recording entities and activities interacting with data after it was acquired (for example version of software used to perform spatial smoothing)  19, 20. An exception to this trend is work of Mackenzie-Graham et al. proposing a provenance scheme that included information about data acquisition parameters  21.
However, because this scheme was mainly focused on data processing provenance it only included a few acquisition parameters (such as repetition time, pulse sequence, coil type etc. ) and did not include paradigm details and other metadata crucial for analyzing task fMRI or diffusion data. When developing the Brain Imaging Data Structure (BIDS) standard, proven parts from the aforementioned standards were combined with common laboratory practices to maximize ease of use and adoption. Common practices included encoding the purpose of a file in its filename and reusing already existing and widely recognized file formats (NIfTI, JavaScript Object Notation [JSON], and Tab Separated Value [TSV] text files). The process of defining this standard involved consultations with leading scientists in the field, public calls for comments, and most importantly the generation of example BIDS compatible versions of publicly available MRI datasets.
Results The following standard describes a way of arranging data (see Figure  1 ) and specifying metadata for a subset of neuroimaging experiments. It follows a simple but carefully defined terminology. The filenames are formed with a series of key-values and end with a file type, where keys and file types are predefined and values are chosen by the user. Some aspects of the standard are mandatory. For example, each dataset needs to have at least one subject directory. Some aspects are regulated but optional. For example, T1-weighted scans do not need to be included, but when they are available they should be saved under a particular file name pattern specified in the standard. The standard provides data dictionaries and strict naming conventions for structural (T1w, T2w etc. ), diffusion, and functional MRI data as well as accompanying behavioural and physiological data.
In addition clear definitions of terms used in TSV and JSON files are provided together with links to DICOM, Cognitive Atlas  24    This standard aspires to describe a majority of datasets, but acknowledges that there will be cases that do not fit the present version (1. 0. 0) of BIDS. In such cases one can include additional files and subfolders to the existing folder structure following a set of general naming guidelines and common sense. For example, one may want to include eye tracking data (BIDS does not cover this type of data yet). A sensible place to put it is next to the continuous recording file with the same naming scheme but different extensions. To make sure such additions are not accidental the provided validator raises a warning for all files that do not fit the specification.
The solutions will vary from case to case and publicly available datasets will be periodically reviewed to include common data types in the future releases of the BIDS specification. Raw vs. derived data BIDS in its current form is designed to standardize (convert to a common file format) and describe raw data. During analysis, such data will be processed and intermediate as well as final results will be saved. Derivatives of the raw data, should be kept separate from the raw data. This clearly separates raw from processed data, makes sharing of raw data easier, and prevents accidental changes to the raw data. Even though BIDS specification currently does not contain a particular naming scheme for different data derivatives (correlation maps, brain masks, contrasts maps, etc. ) we recommend keeping them in a separate "derivatives" folder with a similar folder structure as presented below for the raw data.
The Inheritance Principle Any metadata file (e. g. , files ending with:. json,. bvec, _events. tsv, _physio. tsv. gz, and _stim. tsv) may be defined at one of four levels (in hierarchical order): MRI acquisition, session, subject, or dataset. Values from the top level are inherited by all lower levels unless they are overridden by a file at the lower level. For example, /task-nback_bold. json may be specified at the dataset level to set Time of Repetition (TR) for all subjects, sessions and runs. If one of the runs has a different TR than the one specified in the dataset level file, a /sub-<subject_id>/sub-<subject_id>_task-nback_bold. json file can be used to specify the TR for that specific run.
Imaging files Since BIDS is aimed at facilitating data sharing as well as analysis the file format for storing imaging data was selected based on support from various neuroimaging data analysis packages. We have chosen the NIfTI file format because it is the largest common denominator across neuroimaging software. However, since it offers limited support for the various image acquisition parameters available in DICOM or other scanner specific files, the BIDS standard requires users to provide additional meta information in a sidecar JSON file (with the same filename as the. nii. gz file, but with a. json extension -see section"Key/value files" for more information). BIDS standard specifies a carefully selected set of fields together with their definitions which extends the standard DICOM ontology with terms that are crucial for data analysis such as the polarity of phase encoding direction or slice timing (which traditionally have been recorded in inconsistent ways across scanner manufacturers and are not part of the DICOM ontology).
In addition to terms specified in BIDS we encourage users to include other information extracted from DICOMs (including private manufacturer fields) during the conversion process so no metadata would be lost. Extraction of a minimal set of BIDS compatible metadata can be performed using dcm2niix ( https://www. nitrc. org/projects/dcm2nii/ ) and dicm2nii ( http://www. mathworks. com/matlabcentral/fileexchange/42997 ) DICOM to NIfTI converters. A provided validator ( https://github. com/INCF/bids-validator ) will check completeness of provided metadata and look for conflicts between the JSON file and the data recorded in the NIfTI header.
Required, recommended, and optional metadata To maximize adoption and flexibility of the BIDS standard only a small subset of metadata fields and files is required (compulsory). The decision which metadata fields and files are required was based on the minimal metadata needed to perform standard basic analyses on each type of data. For anatomical scans only specifying the type (T1 weighted, T2 weighted, T1 map etc. see Section 8. 3 in Supp. File 1) is required. For functional scans (fMRI), the researcher is required to specify task name (which could be "rest" in for so-called resting-state scans), repetition time (in seconds) and timing and duration of all events (stimuli and/or responses, unless the subject was not performing any task; for more details see Section 8. 4 in Supp. File 1). For diffusion weighted imaging the required metadata is limited to b-values (in the form of.
bval files) and diffusion gradient tables (in the form of. bvec files; for more information see Section 8. 8 in Supp. File 1). Different types of fieldmaps also include a set of corresponding required fields (see Section 8. 9 in Supp. File 1). Similarly when including physiological (breathing or cardiac) or other continuous recordings the researcher is required to specify a start time (relative to the beginning of image acquisition) and sampling frequency (for more details see Section 8. 6 in Supp. File 1). When a required file or metadata field is missing the BIDS Validator will report an error. In addition to those mandatory pieces of metadata, the BIDS standard strongly recommends inclusion of other metadata that are crucial for performing some additional types of analyses. Those include, but are not limited to slice timing (necessary for slice timing correction), phase encoding direction, effective echo spacing, and echo time (required for performing field unwarping).
When a recommended piece of metadata is missing, the BIDS Validator will report a warning. Finally, the BIDS specification also defines a large set of metadata fields that are optional. Those include information that is not crucial for any particular data analysis method, but can be useful when trying to understand the nature of the data or combining data from multiple sources. Those fields include, but are not limited to scanner manufacturer, scanner software version, head coil name, instructions given before the task, multiband acceleration factor etc. In addition the researcher can extend the metadata dictionaries with their own keys (as long as they do not collide with those already defined in BIDS specification) to include additional information.
Creating a BIDS compatible dataset The process of creating a BIDS compatible dataset can be split into several steps. In the following section we will present this procedure using a dataset acquired at UCLA by Jessica Cohen as a part of her Ph. D. research 28. This dataset includes anatomical, diffusion and task fMRI data and is available (in BIDS format) in OpenfMRI repository under the accession number ds000009. Step 1: Convert DICOM files to NIfTI This dataset has been acquired using an MRI scanner that outputs DICOM files (Siemens Trio) so we can use a DICOM to NIfTI converter such as dcm2niix. This particular converter supports BIDS --it normalizes idiosyncrasies of different scanner manufacturers that are not standardized by DICOM, and outputs a BIDS compatible JSON with most of the required and recommended metadata (such as repetition time, slice timing, and phase encoding direction).