dataesr/scientific-paragraphs-categorization huggingface dataset:
Lifewatch LifeWatch  [7]  is the e-Science and Technology European Infrastructure for Biodiversity and Ecosystem Research that aims to advance science in these disciplines and to address the big environmental challenges as well as to support knowledge-based strategic solutions to environmental preservation. This mission is achieved by providing access to a multitude of datasets, services, tools and computing resources in general, enabling the construction and operation of Virtual Research Environments (VREs). Requirements injected into the project are: 1. Integration of different tools based on the cloud, that allow the management of the data lifecycle, the production of data based on FAIR (+R, Reproducibility) principles 2. Integration of tools that allow the automation of saving the data produced by the sensors stored in distributed resources and the management of the metadata for the integration of the different sources.
CTA Very high-energy electromagnetic radiation reaches Earth from a large part of the Cosmos, carrying crucial and unique information about the most energetic phenomena in the Universe. CTA  [8]  (Cherenkov Telescope Array) will answer many of the persisting questions by enabling the detection of more than thousands sources over the whole sky. CTA builds on the proven technique of detecting gamma ray induced particle cascades in the atmosphere through their Cherenkov radiation, simultaneously imaging each cascade stereoscopically with multiple telescopes, and reconstructing the properties of the primary gamma ray from those images. Requirements injected into the project are: 1. Intelligent and automated dataset distribution: The CTA computing model should be distributed among four data centers and two geographic array sites.
The event reconstruction consists of six levels of data, each with specific and complex policies for data distribution: disk vs tape, number of versions, number of replicas per version, etc. Some versions must be automatically erased/removed by the system. Data placement is important to distribute load between the four data centers, not only for storage but also for reconstruction/analysis jobs. The data access rights are also complex. 2. Data ingestion pre-processing: The CTA distributed archive is based on the Open Archival Information System (OAIS) ISO standard. Event data are in files (FITS format) containing all metadata. Metadata need to be extracted from the ingested files, with an automatic filling of the metadata database. Metadata will be used to further query of archive. The system should be able to manage replicas, tapes, disks, etc, with data from low-level to high-level.
5 Exabyte. This extreme scale poses several challenges, technical and economical, on the data management infrastructure. In fact, the storage resources counts roughly for the 50% of the total infrastructure cost. To support these new computing models, improved infrastructure-level data management services would greatly help in lowering the effort to maintain the experiment frameworks. Requirements injected into the project: XDC has to provide smart caches mechanisms to be added to the storage systems currently deployed in the WLCG infrastructures. These caching mechanisms will be the basis to realize a distributed storage system deployed across centers connected by fat networks (10Tb in 2025) and operated as a single service. These so-called "DataLakes" will simplify the dynamic extension of sites to remote locations and allowing for less datasets distribution.
XDC Orchestration system In XDC, the global orchestration layer covers two essential aspects: i) The overall control, steering and bookkeeping including the connection to compute resources, ii) The orchestration of the data management activities like data transfers, and data federation. Consequently, it was decided to split the responsibilities between two different components: the INDIGO Orchestrator  [11]  and Rucio  [12]. The INDIGO PaaS Orchestrator, the system wide orchestration engine, is a component of the PaaS layer that allows to instantiate resources on Cloud Management Frameworks (like OpenStack and OpenNebula) and Mesos clusters. It takes the deployment requests, expressed through templates written in TOSCA YAML Profile 1. 0, and deploys them on the best cloud site available. The Rucio project, the data management orchestration subsystem, is the new version of ATLAS Distributed Data Management (DDM) service, allowing the experiment to manage the large volumes of data, both taken by the detector as well as generated or derived, in the ATLAS distributed computing system.
Rucio is used to manage accounts, files, datasets and distributed storage systems. FTS  [13]  is exploited by Rucio to execute the data movements. The two components, the PaaS Orchestrator and Rucio, provide different capabilities and can complement each other to offer a full set of features to meet the XDC requirements. Rucio is being integrated in the INDIGO Orchestrator as a plugin to be used to steer the data movement. The Orchestrator will be the main entry point for the user requests and, in particular, it will also interact directly with the storage backends (i. e. dCache  [14] , EOS  [15] , Onedata  [16] ) in order to get information about the data availability needed to trigger the right processing flow. The Dynamic Federations system (Dynafed)  [17]  is used to have a very fast dynamic namespace exposed via HTTP and used by the other components to gather information for the data movements and policy creation.
XDC QualityOfService implementation The idea to provide scientific communities with the ability to specify a particular Quality of Service when storing data, e. g. the maximum access latency or minimum retention policy, was introduced within the INDIGO-DataCloud project that carried on three interlinked activities: the definition of a common vocabulary within the framework of the Research Data Alliance (RDA), the rendering of those attributes by a standard protocol or API and a reference implementation of the selected standard. In INDIGO, the network protocol and the implementation was based on an extension of the SNIA  [18]  Cloud Data Management Protocol CDMI  [19]. The XDC QoS-related developments are a continuation of the INDIGO work to consistently compliment all data related activities.
Beyond this scenario, certain extensions are investigated: write support, synchronisation and enforcement of ACLs, namespace synchronisation (allowing discovery of non-resident data), call-out to FTS for data transport, QoS support, integration with storage notifications. In the XDC caching architecture the EOS and dCache storage systems are integrated, each of them operating in a caching mode for the other, staging data in when a cache miss occurs. Dynafed acts as data and cache federator and all the functionalities needed for linking it with other components are under development. Standalone HTTP caches are built from existing web technology, such as NGINX  [20] , modified for horizontal scalability and relevant AAI support.
XDC developments for the Onedata storage federator Onedata is a data management system providing easy, scalable and high-performance access and management of distributed storage resources. It was developed with the contribution of the INDIGO-DataCloud project to support a wide range of use cases. Functionalities for end users are available via the Onezone that provides single-sign on authentication and authorization for users that can create access tokens to perform data access management via the Web browser, REST APIs or using Onedata POSIX virtual filesystem. Onezone can federate multiple storage sites by deploying Oneprovider services on top of the actual storage resources provisioned by the sites. For the purpose of job scheduling and orchestration, Onedata is being extended to provide notification via the XDC message bus.
This will allow the Orchestrator to react to changes in the overall system state (e. g. a new file in a specific directory or space, data distribution changes initiated by manual transfers, cache invalidation or on-the-fly block transfers). On the data access layer, Onedata will provide a WebDAV storage interface. This will enable integration of other HTTP transfer based components such as FTS or EOS. Furthermore, Onezone will allow for semi-automated creation of data discovery portals, based on metadata stored in the federated Oneprovider instances and on a centralized ElasticSearch engine indexing the metadata. In XDC Onedata will also improve its already existing caching capabilities with machine learning techniques used on detailed I/O trace logs generated while running actual user applications.
[9]nical Research Infrastructure Network)[9]is a not-for-profit intergovernmental organisation that provides support for the development and implementation of multinational clinical research projects in Europe. These are mostly investigator initiated (rather than industry sponsored) clinical trials, run by non-commercial Clinical Trials Units (CTUs) based within universities or hospitals, though ECRIN does also support trials initiated by biotech and medical device small and medium enterprises (SMEs). As a result more and more researchers are making such material (generically, clinical trial data objects) available for sharing with others. The datasets are rarely freely available -instead a variety of access mechanisms (e. g. individual request and review, membership of pre-authorised groups, or web based self-attestation) are used in combination with different access types (e.
They presented their methodology to the team and played the role of facilitators throughout all the process stages. The two researchers also gathered all the data generated during the process (from the content of the preparation sessions to the ideas generated in design workshop): some data were their own notes and presentations (especially during preparatory phases), others corresponded to data provided by the workshop participants and gathered by the two researchers (for instance, project scenarios written on specific forms were collected at the end of the design session). The detail of our research material will be presented along Section 3. 2. and Section 4 in correspondence with the design process stages in order to facilitate reading.
The extensions provide specific recommendations for reporting specific study designs (e. g. , cluster RCTs (8)), specific interventions (e. g. , nonpharmacological treatments  (9) ) and specific types of data (e. g. , harms  (10) ). Extensions are frequently published with an E&E document and are to be used in conjunction with the main CONSORT Statement and E&E document. Despite an improvement in the completeness of reporting  (11) , endorsement and adherence to the CONSORT Statement, particularly the extensions, are questionable  (12) (13) (14) (15). Our overarching aim was to determine whether the development, updating process and format of the CONSORT Statement and extensions are in line with users' needs. For this purpose, we first evaluated whether RCTs indexed in PubMed were covered by the main CONSORT and related extensions (i.
Data extraction We recorded the study design, number of groups, type of interventions, comparator, sample size, and medical conditions. We considered that the study was a pragmatic trial and a pilot/feasibility study when it was clearly stated in the title or abstract. According to the study design and intervention, we determined whether the study was covered by a relevant extension, regardless of whether the extension was based on CONSORT 2010 or 2001. Also, for each extension, we determined the proportion of RCTs for which it was relevant. To determine the potential workload for users, we considered the workload when users strictly follow the CONSORT recommendations (i. e. , use the explanation and elaboration in conjunction with the checklist and use the extensions in conjunction with the main CONSORT because extensions provide guidance on only the modified items).
This allows for a full understanding of the Statement and extension. This potential workload also consists of the maximum workload for a user. Consequently, the workload was the total number of documents and pages of the 2010 CONSORT Statement and its 2010 E&E in addition to all relevant extensions and related E&E documents. For practical reasons, we did not consider the workload for extensions related to the type of data, namely "patient-reported outcomes," "harms," "abstracts", and "equity. " One researcher (LG) screened the titles and abstracts of the citations retrieved and recorded data from the abstract. When needed, the full-text article was retrieved to record data not reported in the abstract. As a quality control procedure, another researcher (AC) extracted data for 10% of the 1000 retrieved eligible citations (kappa agreement was 0.
However, in studies on combinations, the ordering of toxicity probabilities between all combinations is not known prior to the study. For instance, the combination of two agents with three and four dose levels respectively, leads to 12 dose combinations. The ordering is only partially known among all these combinations. This leads to uncertainty in the ordering of monotonic toxicities for some dose combinations. This paper was prompted by the phase I VINILO trial, an international phase I trial evaluating the combination of vinblastine and nilotinib in children and adolescents with refractory or recurrent low-grade glioma (ClinicalTrials. gov Identifier: NCT01884922). It was planned to explore respectively four and three dose levels for vinblastine (from 3 to 6 mg/m 2 ) and nilotinib (115 to 350 mg/m 2 ).
For the Yuan and Yin approach, as recommended by the authors, a non-informative prior distribution Gaussian (0, 2) was assigned in the Bayesian computation, and the proportionality coefficients for the initial guesses in the sub-trial were set at (0. 85, 1. 15), as recommended by the authors. We used the dfcrm R package to apply the CRM for each sub-trial. The initial guesses, as proposed by Wang, were set at (0. 05, 0. 1, 0. 2, 0. 3) for Agent A, and (0. 05, 0. 1, 0. 2) for Agent B. As the initial comparison concerned the methods of both Wang and Yuan in the VINILO context, we completed the performance assessment of Wang's design, which was used in VINILO trial, by comparing it with those of designs presented in the paper by Hirakawa et al. [12]  in the context of their simulation studies.
Sensitivity analysis A sensitivity analysis was performed to evaluate the performance of the method where: i) the proportionality coefficients were set at (0. 85,1. 5) and (0. 85,2) instead of (0. 85,1. 15), and ii) different initial guesses using the R function "getprior" in the dfcrm package were used. As stated by Yin G and Lin R  [18] , typically, the maximum dose for each drug in a combination trial cannot exceed their individual MTDs, and as a result, the remaining lower doses can only be fractions of the corresponding MTDs. Thus, the maximum toxicity probability for each drug in the combination typically cannot exceed 20%, as synergism in DLTs is often a major concern.
Program description We proposed scripts using Wang's method. We presented two functions: i) Wang's step-bystep (SBS) design, which computes the dose for the next patient in an actual phase I trial, and ii) Wang's simulation (SIM) design, which provides simulation replicates of a phase I trial using the Wang and Ivanova design. Both functions were written in R language. No downloading of R packages was required. The functions must be loaded in each work session and require several arguments, detailed below.
Application: Validity of R scripts for Wang and Ivanova approach To validate our R scripts, we ran the same scenarios (dose-toxicity relationships) proposed by Wang for the simulation study. The results were compared to those published in their paper. The results using R function were similar to those published by  Wang. Using the R functions, the results on the percentage of DLTs observed, and a recommended MTD at the end of the trial can be also obtained. The MTD is defined as the dose combination associated with a probability of DLT closest to the target toxicity (results available on request).
Important issues The specific characteristics of software production in research have given rise to several important issues: 1. To maintain software-related research output's reproducibility and refutability properties, the scientific community has to be provided with the means to reproduce the experimental conditions that led to such result and to test the algorithms concerned on other datasets. Guaranteeing permanent access to both the software and the data it manipulates means it must be possible: a) to refer to particular versions of the software used as well as their execution environments on a long-term basis; b) to possess platforms capable of permanently storing these versions; c) to possess hardware and system environments which allow software to be re-used identically. This is a complex scientific problem because the rapid obsolescence of hardware can have a strong impact on the reproducibility of certain types of results.
The citation/reputation system As explained above, software is the result of a complex process involving design and development activities  [2]. It cannot be reduced to a sum of lines of code 2. An architectural or algorithmic contribution may not appear directly as a formal production of lines of code because source code management systems only make the names of the developers visible. The creation of traces relating to contributions is therefore a technical problem (effective means for citation are required) as well as an organizational problem (these contributions have to be materialized within the development environment). This all requires metadata quality control procedures which are absent in repositories such as FigShare or Zenodo  [3]  but are currently being developed for HAL  [4].
The technology transfer of software produced by research In terms of referencing, the software databases produced by research are often internal tools involving a mix of issues linked to referencing and the internal evaluation of researchers which prevents them from being opened up for broader usage. Attempts have been made to set up public databases  [5]  but this leads to duplicate data entries and data which is not always automatically updated. A homogeneous foundation of open data therefore needs to be defined which is possibly supplemented by standardized data for internal purposes. Providing different academic institutions with shared availability for this base would enable them to make a single inventory of the software assets produced by their agents which they sometimes co-own joint rights for.
results Overall, 14. 2% of respondents declared to use EBM regularly in their daily practice and 15. 6% declared to use EBM only occasionally. The remaining respondents declared they: knew about EBM but did not use it (33. 1%), had just heard about EBM (31. 9%) or did not know what EBM is (4. 0%). Concerning the use of EBM-related information sources, 83. 4% declared to use at least monthly (or more often) clinical guidelines, 47. 1% PubMed, 21. 3% the Cochrane Library and 6. 4% other medical databases. Fewer pharmacists (12%) declared to use EBM in their practice than nurses (22%) or doctors (36%). No difference appeared when analysed by gender, work setting or years after graduation. The most frequent obstacles perceived for the practice of EBM were: lack of general knowledge about EBM, lack of skills for critical appraisal and lack of time.
Concerning professional information sources, a large majority of professionals in this survey consulted mainly guidelines from official organisations and specialty societies, much more than they searched PubMed, the Cochrane Library or any other bibliographical database. This is logical, though, because conducting a good, comprehensive search for primary evidence (ie, for single research studies, like randomised controlled trials or observational studies, that investigate each an aspect of clinical interest) requires some skills and is time-consuming. Moreover, precisely, the lack of skills and time, together with poor general knowledge of EBM, were perceived in this survey as the most frequent obstacles encountered for practising EBM. These obstacles should be addressed in order to further spread the knowledge and implementation of EBM.
https://www. ebsco. com/. DARE, Database of Abstracts of Reviews on Effectiveness. https://www. crd. york. ac. uk/CRDWeb/. TRIP, Turning Research Into Practice database. https://www. tripdatabase. com. SUMsearch, A federated or meta-search engine. http://sumsearch. org/. ACCESSSS, ACCESSSS Federated Search. https://plus. mcmaster. ca/ACCESSSS/.
Genetic algorithm Genetic algorithm (GA) is a search heuristic that simulates the process of natural selection where the fittest individuals are selected for reproduction in order to produce offsprings of the next generation. GA is based on a set of genetic operators namely crossover, mutation, and selection used in creating the offspring of the next generation. Among its advantage comparing to SA, is the search from a rich database of populations instead of a single state that significantly reduce the probability of being blocked into a local minimum. And this is the reason for using it besides to several other solution approaches to enhance their performances  [3] [5]. However, its major limit is the premature convergence.
Experimental results In this section, we report and discuss the results of the computational experiments carried out on the benchmark instances reported in Table  5. We conduct an experimental comparison between SA and the HSA in order to improve the quality of the found solutions and test the efficiency of the proposed method to solve the PBAP. It is evident from Table  6  that HSA outperforms the classic SA. With most datasets, the proposed HSA algorithm is showing a good performance and giving the highest satisfaction and lowest cost values in many cases. The proposed approach presents two main steps; search by the annealing and evolution by the genetic operators. The initial cost of each instances is the cost of a random assignment. Our proposal gives better results compared to the results of SA for those sets of instances, with an average improvement of 2.
7% even on solving instances from 8-13 which are characterized by a significantly higher number of patients and considerably longer planning periods. For the PBAB, we can see that combining the features of GA with those of SA helped to improve the performance of SA and allowed HSA to obtain better results on all instances, with an average improvement of 2. 55% with the small instances (1-7), and 2. 88% improvement with the larger instances  (8) (9) (10) (11) (12) (13). With regards to the computation time, our algorithm solved the problem in a very acceptable CPU times depending on the dataset size. Besides, the CPU time is not adopted as an important criterion to address the performance of algorithm because the whole decision-making and planning exercise are of an offline type. However, the computational time depends on the coding and structure of the program.