dataesr/scientific-paragraphs-categorization huggingface dataset:
The model runner service then forwards the final data and the model to execution engine which is responsible for running the chosen model. The obtained results are transformed to a meaningful outcome for the decision type in question by the Results specification submodule. The cloud database is updated with the results accordingly. The predictive models will be built using data from 135 subjects to be enrolled: 30 subjects of Group I-patients with symptoms of HF and known HF, 60 subjects of Group IIwith hypertension or obesity and symptoms resembling HF but without HF, 45 subjects of Group III -patients with acute HF) will be collected within three clinical centers (University Of Ioannina Greece-UOI, Consiglio Nazionale Delle Ricerche Italy -CNR, University College Dublin Ireland -UCD). The accuracy of the CDSS will be validated through early clinical testing.
F. KardiaSoft Graphical User Interface (KGUI) All the information is accessed and viewed through the KardiaSoft Graphical User Interface which is responsible for the visual representation of the different modules, the invocation of the respective module and the interaction with the user. It consists of six main segments which are the navigation GUI, the Patient data Management GUI, the Patient Information GUI, the CDSS GUI, the Authentication-Login GUI and the Administration GUI. A summary of the modules of the KardiaSoft system, as well as the segments of each module is presented in Table  I. The interaction between the modules is depicted in the context diagram in Fig. 2.
Participants and Data Collection To gain an overview of the current situation of adoption, teachers were invited via a call on the intranet and in newsletters to participate in an online questionnaire in October and November 2017. A total of 143 fully completed questionnaires were returned. Table  1  provides the general characteristics of the participants. Subsequently, a purposeful sample of 11 teachers was interviewed in December 2017 and January 2018. Selection of participants was based on a two-stage process. First, the 45 teachers who gave permission to be contacted for an interview in the questionnaire were grouped into school level. Second, schools that had some experience with OER were selected. Within these four selected schools, teachers, who indicated they were familiar with OER and had either used or shared resources in the previous academic year, were invited to participate.
To answer the last question, the code support was developed to analyse teachers' need for support to adopt OER. To assure the overall quality of the research study, the audit procedure as described by  Akkerman, Admiraal, Brekelmans and Oost (2008)  has been executed. An audit trail showed an auditor, who was not involved in the analysis of the data, the procedures of data collection and analysis for both the quantitative and qualitative data. It was concluded that the results were visible, comprehensible and acceptable.
Or as Gary puts it, 'you would expect that with ten similar degrees in the Netherlands that there would be exchanges [between institutions], but it doesn't happen. ' Even on a smaller scale, it could be beneficial; some teachers would like to form a community within the institute as Lily explains: 'Right now  [collaboration]  is very ad hoc, random and purely fortuitous. Maybe a database [in which] I can search who teaches [my course], that would be a big advantage already. A database who does what, who has which specialisation so that it becomes possible to contact  [teachers]  outside your own school. '.
Capacity Provided that teachers have availability of OER, most teachers also emphasised the need for technical and pedagogical support in using and sharing OER. Sienna stresses: 'the first thing that is needed, is technical support. How does it [adoption] work?' Ralph already shares his materials but likes to share it outside his network as well, but 'someone who has the expertise can meta-data it so that it can be found. ' In addition to this, some teachers also mention the need for pedagogical support. The main need for teachers is to understand how OER could benefit their teaching and student learning; as Chloe says: 'that is probably my wish regarding OER, how can exercises and assignments scaffold students' drive to study. ' Two teachers specifically mentioned the need for formal training sessions.
General characteristics of tools We designed a data extraction form using Google® Docs and extracted the general characteristics of the tools. We determined whether the tool was scale or checklist. We defined a tool as a scale when it included a numeric or nominal overall quality score while we considered it as a checklist when an overall quality score was not present. We recorded the total number of items (for definitions see Table  1 ). For scales with more than 1 item we extracted how items were weighted, how the overall score was calculated, and the scoring range. Moreover, we checked whether the scoring instructions were adequately defined, partially defined, or not defined according to the subjective judgement of two reviewers (CS and JAG) (an example of the definition for scoring instructions is shown in Table  2 ).
Finally, we extracted all information related to the development, validation, and assessment of the tool's reliability and if the concept of quality was defined. Two reviewers (CS and JAG) piloted and refined the data extraction form on a random 5% sample of extracted articles. Full data extraction was conducted by two reviewers (CS and JAG) working independently for all included articles. In the case of disagreement, consensus was obtained by discussion or by involving a third reviewer (DH). Authors of the reports were contacted in cases where we needed further clarification of the tool.
Manufacturers have little financial incentive to cooperate and provide compatible formats. This resulting diversity of formats is an impediment to reusing data as well as to building large-scale EEG databases. The Brain Imaging Data Structure, originally proposed for magnetic resonance imaging data (MRI), is a human brain research community standard used for organizing and sharing brain imaging study data within and between laboratories for many (ultimately all) imaging modalities 2. BIDS primarily addresses the heterogeneity of data organization by following the FAIR principles 3 of findability, accessibility, interoperability, and reusability. BIDS addresses findability and reusability by providing rich metadata in dedicated sidecar files and interoperability by using existing standard data formats.
and reuse of acquired datasets. Because BIDS data are structured, BIDS also addresses issues of reproducibility by allowing the creation of fully automated data analysis workflows. Here we report on the extension of BIDS to EEG data. EEG-BIDS builds upon the MEG-BIDS extension  4  and is presented concurrently with the iEEG-BIDS extension covering human intracranial electrophysiology  5. In this document we only highlight the main features of EEG-BIDS. The full documentation of the EEG-BIDS extension can be found via the link to the specification on the general BIDS website (https://bids. neuroimaging. io/).
EEG-BIDS Summary The extension of BIDS to EEG data closely follows the general BIDS specification (see Figure  1 ). Each subject's data corresponds to a directory of raw data containing subdirectories for each session and data modality. This is accompanied by a "dataset_description. json" file containing generic information about the dataset and in the case of the EEG modality, a metadata file with the suffix "eeg. json". The "eeg. json" file exhaustively specifies among other metadata details of the experimental task and the EEG recording system. Optional directories include the "sourcedata" directory, which can be used to supply original non-formatted data. Furthermore, a "stimuli" directory and a "code" directory can be present to allow data conversion and preprocessing to be reproduced, as indicated in the original specification  2.
Specific EEG-BIDS Considerations The process of converging on a list of suitable data formats for EEG-BIDS was governed by three major requirements: A suitable data format should (i) address the needs of a large portion of the global EEG community, (ii) be interoperable according to the FAIR principles  3  , and (iii) meet the technical requirements of neuroscientific workflows, such as saving numerical data with high precision. As a solution to this challenge, the EEG-BIDS specification incorporates only two recommended "official" data formats: The European Data Format (EDF), which is an ongoing international effort to provide a common data format for electrophysiological recordings that began in 1992  7  , and the BrainVision Core Data Format, developed by Brain Products GmbH. While the BrainVision Core Data Format was designed by Brain Products GmbH for its proprietary EEG recording equipment and analysis software, it is based on the Microsoft Windows INI file and has a concise documentation.
Both of these formats follow the three requirements for suitable data formats for EEG-BIDS: (i) A recent survey indicates that they are widely used in the community (https://bids. berkeley. edu/news/bids-megeegieeg-data-format-survey), (ii) they have open access documentation and an open source implementation for both reading and writing in at least two programming languages that are widely used in the field (in this case, Python and MATLAB, among others), and (iii) they have high numerical precision (EDF:16 bits, BrainVision Core Data Format:32 bits). To accommodate a larger scientific audience and facilitate adoption, the EEG-BIDS standard also allows two "unofficial" commonly used data formats: The format used by the MATLAB toolbox EEGLAB  8  (". set" and ". fdt" files), and the Biosemi format (".
bdf "). While not actively encouraged, these two formats are included due to their popularity and their interoperability among the major software packages. Future versions of BIDS may extend the list of "officially" supported data formats, based on the fulfillment of the above mentioned three requirements for suitable data formats. Independently of the raw data format used, critical metadata about the recording are always available in BIDS. tsv and. json files. In order to provide an unambiguous documentation of EEG data, we are clarifying two sets of terms that are often used interchangeably: Electrodes versus channels, and fiducials versus anatomical landmarks. We distinguish between electrodes and channels using the following definitions: (i) An EEG electrode is a contact point attached to the skin, (ii) a channel is the combination of the analog differential amplifier and analog-to-digital converter that result in a potential (voltage) difference being stored in the EEG dataset.
Public EEG-BIDS Datasets Several study examples (with zero-byte data files) are available in the BIDS-examples GitHub repository (https://github. com/bids-standard/bids-examples). We have also released three full datasets formatted using the EEG-BIDS standard: • The Matching Pennies dataset  9  is an example of a single recording session per participant. It was collected as part of a student project to replicate a brain-computer interface study of motor intention decoding. • The Rishikesh dataset  10  is an example of multiple recording sessions per participant. Participants were asked to meditate continuously whilst experience-sampling probe questions were presented at random intervals throughout the duration of the experiment. • The simultaneous resting-state EEG-fMRI dataset  11  offers resting-state data in EEG and fMRI modalities, and structural T1 weighted data and diffusion data (NODDI sequence).
Fig. 1  Exemplary EEG-BIDS dataset with previews of EEG files. The left side of the figure shows a standard BIDS directory tree with the root containing files describing the dataset in general ("README", "dataset_ description. json"), a file describing the participants ("participants. tsv"), and as several JSON files ("participants. json", "task-TASKNAME_events. json"), which contain the description necessary to understand the contents of the TSV files. Note that JSON files at high levels get inherited by lower levels unless overridden (the Inheritance Principle). Next to the files at the root, there is a stimuli and a sourcedata directory that can be used to save the respective study data. Most important are the subject directories named "sub-<sub-label> " for each study participant. Nested in the subject directories are all recorded data split over modalities (eeg and anat, for the EEG and structural MRI data respectively).
The right side of the figure shows the contents of the eeg modality directory, including the raw EEG data (1) and associated metadata (  2 ). An events. tsv file (3) specifies all events that were recorded during the session and can reference presented stimuli with the stimuli directory of the dataset (see stim_file column). A "channels. tsv" file (4) provides further information about the raw EEG data and can contain information not present in the raw EEG data file such as filter settings and channel status (good/bad). Finally, an "electrodes. tsv" file (5) and an accompanying "coordsystem. json" file (6) provide electrode locations and specify which coordinate framework to use to interpret the electrode locations (for example with respect to a T1 weighted MRI scan).
Community tools and Software Support As part of the BIDS project, datasets formatted to follow the EEG-BIDS standard can be validated using the "bids-validator", a JavaScript application that runs locally as a command line version (using Node. js) or within an Internet browser (https://bids-standard. github. io/bids-validator/). With this validation tool, researchers can check their newly formatted datasets and make full use of the data structure's strengths for instance, checking for missing data or underspecified metadata. The BIDS starter kit (https://github. com/bids-standard/bids-starter-kit) is a collection of community-driven guides, tutorials, helper scripts, and wiki resources to help researchers get started with BIDS. The resources cover two popular programming languages (Python and MATLAB) and will be extended over time to incorporate additional guides.
We are collaborating with the developers of the most widely used EEG data analysis tools in order to help EEG practitioners convert their existing data to the EDF or BrainVision Core Data Format. Data conversion utilities from many raw EEG data formats to the EDF and BrainVision format are available in MATLAB from the FieldTrip  12  and EEGLAB 8 toolboxes, and in Python from the MNE-Python 13 package. While specific software implementations are beyond the scope of the data specification, we here also want the reader to be aware of further work being undertaken by the open source community to interact with BIDS datasets. For instance, an EEGLAB  8  "study" can now be exported as BIDS (std_tobids. m), FieldTrip  12  can similarly export (data2bids. m) while SPM12  14  (spm_bids. m) and MNE-Python  13  (in form of the MNE-BIDS project https://github.
Data analysis Pipelines and Beyond Sharing Raw Data EEG's long history, versatility and variety of applications makes it a data-and method-rich technique. Recently, the OHBM Committee on Best Practice in Data Analysis and Sharing (COBIDAS) released a guideline for good practice and reproducibility in EEG  15. According to the guideline, even the simplest processing pipeline already contains eight separate steps, making it clear that while EEG-BIDS helps with data sharing, it will remain non-trivial to develop automated processing pipelines of neurophysiology data such as already available for MRI data  16. On its own, EEG-BIDS is the first necessary step toward achieving validated and reproducible data analysis through standardizing the complete documentation of a dataset. This article describes the new EEG extension for BIDS, and has limited itself to sharing raw data using previously developed community standards.
Challenges that are specific to EEG, such as support for data formats, are still under active debate, and some additional formats will likely be incorporated once the technical issues are addressed and FAIR standards are achieved. The development of BIDS for EEG derivatives is also already underway (BIDS Extension Proposal 21): This will also make sharing of processed data possible, thereby fostering re-analyses, meta-analyses, and new analyses without the burden of data preparation.
acknowledgements We thank the members of the BIDS community for their insights, stimulating discussions and helpful comments on early drafts of the EEG extension. We are grateful to Dora Hermes and Chris Holdgraf for sharing their article drafts of the iEEG specification and to Scott Makeig for discussions on data formats and metadata exchange. We would like to thank Deborah Ain for her very helpful comments and corrections. This work was supported by the EU-H2020 Marie Curie "ChildBrain" Innovative Training Network grant no. 641652 to Robert Oostenveld.
Search Strategy A literature search has been performed on the PubMed database of the US National Library of Medicine (https:// www. ncbi. nlm. nih. gov/pubmed) and on Scholar Google (https://scholar. google. fr/). We searched for articles published between January 1990 and December 2018, using the following key words or associations: "diabetes mellitus", "telemedicine" and "telemedicine in diabetes mellitus"; restrictions included: language ("English" or "French"); and type of publication ("Clinical trials", "Review articles" and "Guidelines"). Textbooks on telemedicine and information gleaned from international meetings were also used. Our main objective is to provide practical information to clinicians on the benefits of telemonitoring, documented from the current medical literature data.
This was a pragmatic randomized controlled trial of patients with type 2 diabetes. Both the control (n=79) and intervention groups (n=87) received usual care  [33]. The intervention group also participated in additional health promotion activities with the use of the Prescribed Healthcare Web application for self-monitoring of BG and BP. About every second month or when needed, the general practitioner or the DM nurse reviewed the results and the healthcare activity plan. Analysis of the data showed that there were no significant differences between the groups in the primary outcome HbA 1c level (p=0. 33), and in the secondary outcome HRQoL as measured using SF-36. A total of 80% of the patients in the intervention group at the baseline, and 98% of the responders after 19-month intervention were familiar with using a personal computer (p=0.
In the later situation, the cloud-based software aggregates, cleans, and analyzes patient data to allow for identifying patterns that may indicate potential risks and provide predictive insights on healthcare outcomes, as the software MyPredi TM  [36, 38]. In fact, several informatics solutions or tools have been developed and used in chronic diseases monitoring (as diabetes), such as Artificial Neural Networks (ANN) algorithms, data mining software, ontology  [38]. Besides these tools, it must be emphasized that diabetes telemonitoring may use, as for CHF telemonitoring, implantable invasive devices that send either sporadically or continuous data to the receiving physician (automatic telemonitoring) (outside the scoop of this paper)  [3, 28]. In management of diabetes, implantable telemonitoring devices for multi-parameters including mainly BG-insulin levels monitoring have recently proven to be an effective approach.
In this study, 3230 people with diabetes, COPD, or CHF were recruited from practices by 179 general practices in three areas in England. The patients were divided into 2 groups: usual care or telehealth with remote exchange of data between patients and healthcare professionals as part of patients' diagnosis and management. In this trial, telehealth has been associated with lower mortality and emergency admission rates. Compared with controls, the intervention group had a lower admission proportion within 12 month follow-up (odds ratio 0. 82, 95% confidence interval 0. 70-0. 97, p=0. 017). Mortality at 12 months was also lower for intervention patients than for controls: 4. 6% vs. 8. 3% (odds ratio 0. 54, 0. 39-0. 75, p<0. 001). Future research must also focus on the accessibility and practicality of telemedicine interventions.
The synchrotron emissivity is determined by the electron density and the strength of the local magnetic field. MHD simulations show that the magnetic field strength can vary strongly throughout the nebula. Thus, X-ray data alone do not enable us to determine the particle density or to perform detailed studies of the particle evolution in PWNe. On the other hand, the IC emissivity is determined by the electron density and the energy density of target photon fields. For the production of TeV emission, the latter are predominantly the cosmic microwave background (CMB), and farinfrared (FIR) Galactic dust emission, which are unrelated to the nebular processes, contrary to magnetic fields that determine the synchrotron emission. This means that gamma rays are a direct tracer of the particle densities in a nearly model-independent way (except for uncertainties related to the FIR photon field).
This scenario is in agreement with hydrodynamical simulations that suggest that the cocoon was formed in an evolved stage of the system, when the reverse shock from the SNR crushed the PWN  (Blondin et al. 2001; Slane et al. 2018 ). These simple two-zone models cannot, however, reproduce the details of the multi-wavelength morphology revealed by the latest observations, such as the larger-scale TeV emission overlapping the extended radio nebula  (Abramowski et al. 2012) , or hints of energy-dependent morphology at GeV energies  (Grondin et al. 2013). In this work we have taken advantage of archival data from the Suzaku X-ray Imaging Spectrometer (XIS) and of an extended H. E. S. S. dataset to improve the constraints on the properties of the highest-energy particles and magnetic fields in the Vela X cocoon.
Observations and analysis region definition We used three archival Suzaku observations of the Vela X cocoon conducted in 2006. From north (closer to the pulsar) to south, they have observation IDs 501109010 (hereafter Pointing 0), 501107010 (hereafter Pointing 1), 501110010 (hereafter Pointing 2), for an exposure of 60 ks, 61 ks, and 18 ks, respectively. We define three regions for spectral analysis corresponding to the Suzaku pointings as illustrated in Figure  1. Later we use these very same regions to derive a SED from the X-ray data and the gamma-ray data. For Pointings 1 and 2 we used circular spectral extraction regions with a radius of 7. 5 centred in the middle of the Suzaku XIS field of view (R. A. = 128 •. 7666, Dec. = -45 •. 4581, and R. A. = 128 •. 6368, Dec. = -45 •. 8007, respectively).
For Pointing 0 we defined a spectral extraction region such that we were able to avoid the region immediately adjacent to the pulsar. The pulsar itself emits X-rays up to a few keV due to thermal emission from its surface, and to higher energies from magnetospheric particle acceleration and radiation  (Pavlov et al. 2001). Furthermore, within 1. 5 (0. 13 pc) from the star, the pulsar wind creates a complex jet-torus structure very bright in X-rays  (Kargaltsev et al. 2003; Manzali et al. 2007) , not resolved in gamma rays. We excluded from the analysis a circular region centred on the pulsar with a radius of 3. 6 (0. We applied the following selection criteria to the dataset: observations for which at least three of the 12 m telescopes were operational to improve high-energy performance, since we are interested in gamma rays at energies > 1 TeV, pro-   (Hahn et al.