dataesr/scientific-paragraphs-categorization huggingface dataset:
Dye incorporation and cRNA yield were then verified using a Dropsense™ 96 UV/VIS droplet reader (Trinean, Ghent, Belgium). Cy3-labelled cRNA (600 ng) were hybridised on microarray slides following the manufacturer's instructions. Slides were washed and scanned immediately using an Agilent G2505C Microarray Scanner and the Agilent Scan Control A. 8. 5. 1 software. The Agilent Feature Extraction software v10. 10. 1. 1 was used with default parameters for fluorescence signal extraction and only the most expressed probes values were represented. T-test statistical analysis was carried out to compare differentially expressed genes.
In Silico Database Analysis and Statistics LIFR mRNA expression patterns from GC were extracted from the Oncomine database tool (www. oncomine. org) [45]. Results were filtered for cancer versus normal tissue analysis and/or Lauren classification and gastric cancer cases in the primary filter. Cui (n = 90) and Cho (n = 160) Gastric tissue datasets were chosen and extracted for analysis. The KMplot database tool (www. kmplot. com) [46]  was used to analyse overall survival probability of non-metastatic (parameter M = 0) GC patients (n = 444) according to LIFR, LIF and combined LIFR and LIF expression. The following JetSet best probes, 225575_at (LIFR) and 205266_at (LIF), were used. Analysis was filtered for Lauren classification, to analyse intestinal and diffuse types of GC separately, and the GSE62254 dataset was excluded as suggested by the database to avoid biased results.
Patients' samples were separated according to high or low expressions by the software's best cut-off value auto-setting. P-values were calculated by a log-rank test. Results are expressed as mean ± S. E. M of at least three independent experiments. Statistical tests were carried out using the GraphPad Prism software version 8. 0. 2 (La Jolla, CA, USA). Mann-Whitney test or Student t-test were used for the two-groups comparisons and ANOVA with Bonferroni as a post hoc test or Kruskal-Wallis test with Dunn's test as post hoc were performed for multiple comparisons.
Acknowledgments: We thank  Katia Boniface  ( INSERM UMR1035 ,  University of Bordeaux, France ) for providing anti-Stat3 antibodies, JAK inhibitors and for helpful discussions. We also thank  Jacques Robert  and  Elodie Darbo  ( INSERM U1218 ACTION ,  University of Bordeaux, France ) for their bio-informatical counselling and discussions.
Funding: The PhD fellowship of  Lornella Seeneevassen  was funded by the  French Ministry of Tertiary Education, Research and Innovation. The PhD fellowship of  Camille Tiffon  was funded by the  Ligue Nationale Française Contre le Cancer/French National League against Cancer. Silvia Elena Molina-Castro  was a PhD fellowship recipient of the  University of Costa Rica  ( San José ,  Costa Rica ) and the  Ministry of Sciences and Technologies (MICITT, Costa Rica ). This research was funded by the  Institut National du Cancer/French National Institute on Cancer INCa , grant PLBio  2014-152.
Methods We use a range of different sources to update and curate our database. First, we use official government sources and peer-reviewed scientific papers that report primary data as the gold standard for data inclusion. Government sources include press releases on the official websites of Ministries of Health or Provincial Public Health Commissions, as well as updates provided by the official social media accounts of governmental or public health institutions. Second, to find additional details for each case or patient we augment these data with online reports, mainly captured through news websites (e. g. , https://www. 163. com) or via news aggregators (e. g. , https:// bnonews. com/). We recorded all data sources in our database. Third, in some instances more detailed data are available, typically through peer-reviewed research articles  1, 7  , which were subsequently used to modify existing records in the database.
We added a full list of sources that were used to our Github repository (https://github. com/beoutbreakprepared/nCoV2019/blob/master/source_list. csv). We collected data on the following: (a) Key dates, which include the date of onset of disease, date of admission to hospital, date of confirmation of infection, and dates of travel. (b) Demographic information about the age and sex of patients/cases. (c) Geographic information, at the highest resolution available down to the district level. We excluded information that was at the building level so that cases could not be identified. Geographic information was subdivided into administrative units (admin 0 = country, admin 1 = province, admin 2 = county, admin 3 = city, and where available, specific locations). (d) Symptoms, (e) Any additional information such as exposure to the Huanan seafood market or record of exposure to infected individuals.
To add new geographies to the database, Google Maps (https://www. maps. google. co. uk) and Google Earth (http://www. google. co. uk/intl/en_uk/earth) were used to determine latitude and longitudes, and relevant administrative metadata was extracted by querying the relevant country reference shapefile. For locations that are administrative units, information was populated by referring to the country reference shapefile, sourced primarily from GADM (https://gadm. org/) with the admin_id field to allow for easier polygon selection. The distribution of geographic locations where cases have been reported is shown in Fig. 1. To provide real-time visualization we designed an interactive web application using Mapbox and automatically update the results using JavaScript. This visualisation is available at https://www.
Data records A static copy of the dataset has been uploaded to figshare  6  , which includes a fixed version of the data record at the time of submission, ranging from 1 st December 2019 to 5 th January 2020. A live version of the data record, which will be continually updated, can be downloaded from (https://github. com/beoutbreakprepared/nCoV2019) or directly from Google Drive: https://docs. google. com/spreadsheets/d/1itaohdPiAeniCXNlntNztZ_oRvjh0HsGu-JXUJWET008/edit#gid=0 in CSV format, that can be imported it into a variety of software programs. We have also established a Github repository available at: https://github. com/beoutbreakprepared/nCoV2019/covid19 and provide code for importing the data into R statistical software. The epidemiological situation regarding the COVID-19 outbreak is continuously evolving.
We therefore have made available an archive data folder through our Github repository where new data is uploaded. Each of the rows represents a single individual case and ID. A description of the fields in the database is shown below and is available through a data dictionary on Github (https://github. com/beoutbreakprepared/nCoV2019/covid19): ID -Unique identifier for reported case. Currently ID is run concurrently for cases reported from Hubei, China and cases reported outside of Hubei, China. ID order does not necessarily reflect epidemiological progression, or reporting date, and should not be used to order cases in temporal progression. age -Age of the case reported in years. When not reported, N/A is used. Age ranges are recorded as start_ age-end_age e. g. 50-59. sex -Sex of the case.
Confirmation accuracy is contingent on the data source used. Specific dates are reported as DD. MM. YYYY. Ranges are recorded as DD. MM. YYYY -DD. MM. YYYY. Ranges with uncertain start of finish dates are recorded as -DD. MM. YYYY and DD. MM. YYYY -respectively. symptoms -List of symptoms recorded in the description of the case. lives_in_Wuhan -Recorded relationship of patient with city of Wuhan, Hubei, China. "yes" indicates that the case was a resident of Wuhan. "no" indicates that the case is not a resident of Wuhan (residential). No information indicates that no data was available. travel_history_dates -Recorded travel dates to and from Wuhan. Specific dates are reported as DD. MM. YYYY and indicate date when the individual left Wuhan. Ranges are recorded as DD. MM. YYYY -DD. MM. YYYY when both are available.
Ranges with uncertain start of finish dates are recorded as -DD. MM. YYYY and DD. MM. YYYY -respectively. travel_history_location -An open field describing the recent recorded travel history of the case. reported_market_exposure -An open field indicating "yes" if there was reported market exposure and "no" if there was not. N/A indicates that no information is provided. additional_information -Any additional information that may be informative about the case, such as the occupation of the patient, the purpose of their travels, the hospital they were admitted to, etc. chronic_disease_binary -0 represents a case that was reported to have no chronic disease and 1 represents cases that reported a chronic disease chronic_disease -Reported chronic condition(s) of the reported case. source -URL identifying the source of this information sequence_available -If there was a genomic sequence available the accession number is inserted here.
outcome -Patients outcome, as either "died" or "discharged" from hospital. date_death_or_discharge -Reported date of death or discharge in DD. MM. YYYY format. location -Location of the reported case. admin3 -Administrative unit level 3 (e. g. , zip code) of where the case was reported. admin2 -Administrative unit level 2 (e. g. , county) of where the case was reported. admin1 -Administrative unit level 1 (e. g. , province) of where the case was reported. country_new -Administrative unit level 0 (e. g. , country) of where the case was reported. admin_id -Administrative unit ID of the lowest level available for the case reported. At time of publication the database contained 18,529 geopositioned records from December 1, 2019 to February 5 th , 2020 (Fig. 1 ). A map of all records can be viewed in real-time here: https://www.
technical Validation After initial data entry the database was checked using two complementary methodologies to identify possible duplicate records. One was a machine enabled one and the other was done manually by the data curators. The first algorithm proceeds in 5 steps. (1) columns with no variability across all records were removed, (2) the remaining data were hashed using a 32-bit variant of MurmurHash3 implemented in the R package FeatureHashing version 0. 9. 1. 3  8, 9 , (3) a principle component analysis on the centered, scaled hashed feature matrix is performed for dimension reduction, with principle components having standard deviations greater than 0. 5 retained, (4) pairwise, Euclidean distances are then calculated and are normalized based on the smallest observed distance between records, and (5) records that have pairwise distances less than the 0.
5th percentile are flagged as duplicates. Duplicate are defined as cases that refer to the same case. Code for these methods is hosted on our GitHub repository (https://github. com/beoutbreakprepared/nCoV2019/covid19). Records identified as possible duplicates were communicated to data curators via Github and flagged in the database. Curators then discussed amongst themselves via an online chat system (www. slack. com) to reach a consensus on how to address the possible duplications.
Usage Notes These data can be used to investigate the epidemiological COVID-19 outbreak in China and elsewhere. This includes descriptive mapping of occurrences through time and estimation of key epidemiological parameters using mathematical models. The data are openly available and we will continue to curate the database as new information is made available. However, if the epidemic continues to grow then public health agencies are unlikely to continue to report individual-level case data, and instead will switch to reporting only total numbers (or estimates thereof) of confirmed or suspected cases as done for previous large outbreaks such as pandemic flu H1N1  10. When detailed data becomes increasingly less available as the epidemic grows we may transition to an augmented database structure that only reports total new cases per location.
Other groups have presented similar datasets which are complimentary to the one presented in this publication  11. However, the dataset presented here includes fine grained geographic details and the most comprehensive list of cases. While every effort has been made to standardize the geographic representation of cases, with a common source of reference shapefiles outlined, when considering geographic analysis of the data a few limitations must be acknowledged. The first is that, while native speakers were consulted wherever possible, there is the possibility of transliteration errors occurring when extracting data from native language into English-script analogues. This is most likely to happen when looking at point data. We have provided sources consulted so that users may cross-reference the original source wherever this is may be an issue.
Initial cases from Wuhan are well described, mostly thanks to epidemiological studies published towards the end of January  7. Even though we made the best attempt to report data as accurately as possible, given the dynamic nature of the outbreak we caution that the database cannot be guaranteed to be free from error, and we apologize in advance if there are missing entries that were not picked up using our standardised protocol  12. Going forward we will likely update records in the period described here which occurs frequently after outbreaks  [13] [14] [15] [16]. We encourage users of the database to contact us directly if potential errors or omissions have been found. This can be done by either emailing the corresponding authors or, preferably, by submitting a request via the Github repository (https://github.
Acknowledgements We thank all those individuals and organizations across the world who have been willing and able to report data in as open and timely manner as possible. This work attempts to synthesize information from across a myriad set of data sources. MUGK is supported by a  Branco Weiss Fellowship. Bo Xu  acknowledges support from the  China Scholarship Council. JDM and DMP are supported by the  Bill & Melinda Gates Foundation  ( INV-006113 ). We acknowledge support from the  Oxford Martin School  and a grant from  Google. org.
The xAAL system was designed with this idea in mind  [3, 4]. The architecture organizes services into functional components along a communication bus. A protocol is designed, as well as components interfaces. As a result, xAAL is a solution for home automation interoperability. Simply speaking, it allows a device from vendor A (e. g. , a switch) to talk to a device from vendor B (e. g. , a lamp). Advanced usages include wellbeing  [5, 6]  or assistive robotic  [7, 8]. A simple home automation setup can be improved with little effort to get an advanced one. For the wellbeing scenarios, missing environmental sensors have been added (dust, brightness, noise levels, CO 2 ) to supplement the existing ones (temperature, humidity, PIR). Also, a dedicated gateway has been added to the home automation bus to forward selected data to logging and coaching services in clouds.
• Database of Metadata. Each automation device within a facility is likely to be associated with a piece of user-defined information: for instance some location information (e. g. , declare that the equipment typed as a lamp and having address X is located in the "kitchen" or in the "bedroom of Bob"), possibly a friendly name to be displayed to the end user (e. g. , device having address X is called "lamp#1"), or any useful piece of information for users regarding devices on its facility (e. g. , pronunciation of the nickname of the device for a voice interface, or whatever). All this information is grouped in a database of metadata. This database contains somehow the configuration of home automation devices, from the end-user point of view. The database of metadata is present on the xAAL bus.
Other xAAL devices can query it via this bus to obtain information associated with the identifier of a device, or conversely a list of devices associated with a given piece of information. There should be at least one database of metadata on the bus. There could be several. Such pieces of information are structured as key-value pairs. Keys and values are UTF8 strings. The xAAL specification does not define a normative list of predefined or well-known key entries. As a consequence, the meaning of a key makes sense only for the entity that writes it in the database and for the entities that read it. This is the responsibility of those entities to agree on common semantics to interpret information.
Typical Work Flow Such a functional architecture allows managing the dynamic aspects of the infrastructure (modularity, scalability, adaptation, etc. ). Thus, advanced functions such as HMI or automata of scenarios can adapt themselves automatically to the infrastructure and to its modifications (if equipment enters/leaves, if one fails or is replaced, etc. ). The typical work flow of an HMI could be 1. Query the xAAL bus to be aware of the present devices; 2. Query devices about their description (model, manufacturer, URL, etc. ); 3. Optionally, download non-standard schemas from the URL of the description of those non-standard devices, or else use standard schemas; 4. Query the database of metadata about devices to get the configuration of the installation (a friendly name to display, location and other key values associated with each device); 5.
The xAAL Devices Behavior and xAAL Schemas xAAL devices are described by so-called schemas. Schemas are documents specifying attributes, notifications and methods API. Note that the idea of specifying home automation devices by schemas is inspired by the UPnP approach  [24]. Thanks to that, UPnP entities could discover new entering devices, ways to interact with them, and possibly dynamically build user interfaces (for this latter point, UPnP schemas usually pointed to some Microsoft DLL installers or Internet Explorer plugins to be installed on the user's PC, which is not very secure). The other advantage of a formal specification of home automation devices is for software production. Having a clear API specification may help to automatically build skeletons of code. That was the case with the XDR (External Data Representation) for Sun's RPC (Remote Procedure Call) since the middle of the 1990s.
OpenHAB The Open Home Automation Bus (OpenHAB  [55] ), ported by the OpenHab Foundation is a popular open-source software solution for home automation. This is a central solution (e. g. , to be installed in a home automation 'box'). This centralizes in a single software with several home automation functions: user interface, scripting features for automation, and gateways towards many physical devices and technologies. To address interoperability issues, this software supports multiple vendor specific home automation systems by the means of add-ons (named bindings in the OpenHAB vocabulary). For now, add-ons are developed by the open-source community. Home automation companies are then invited to provide their add-ons for their devices (similar to PC drivers for peripherals). Due to this technical detail, this is still the OpenHAB name and logo that is displayed on the box, not the ones of home automation companies.
This can be a real obstacle to the adoption of this approach. The software is developed with the Java language, and uses an OSGi architecture (Open Services Gateway initiative  [56] ). Natively, Java VM does not provide technical means for dynamic libraries loading. OSGi is an answer to cover the need. OSGi proposes a component architecture. Components, named bundles, can be dynamically loaded to extend the software, and are communicating with each other via a software bus. OpenHAB specializes this bus with channels; this bus is the B of OpenHAB. OpenHAB is not a network protocol. However, some bundles propose a REST API to remotely control the box from iOS, Android, or Web applications.
Conclusions This paper presented xAAL with the last improvements, a proposal for home automation interoperability. The solution is based on an open distributed system with ciphered communications on an IP multicast bus. The system provides a discovering mechanism to dynamically integrate new devices. Semantics of each device is rigorously described from the functional point of view, and thus allows others to interact with it regardless if it comes from the same manufacturer or not. A specification dialect for those schemas is therefore provided to define participating components, with associated functions and data models. A mechanism of inheritance allows extending schemas openly, and therefore to integrate devices with more sophisticated functionalities. The proposed pivot communication protocol is compact, lightweight, and ciphered to address security and privacy issues.
The project comes with open-source reference implementation stacks, a set of schemas for typical devices, and experiments in the real world. The paper gives all technical details for third parties implementation. It also discusses alternatives and presents choices that sustain the proposal. Modern home automation systems must be able to detect, reason and act on their environment. xAAL allows us to manage various systems made up of sensors and actuators. It makes it possible to collect data consolidated with pieces of semantics, and it also offers the creation of sophisticated scenarios. The next step is to evolve towards ambient intelligence. We are currently working on integrating recognition of daily activities and automatic planning of action sequences.
, 2020; Mégarbane and Scherrmann, 2020). As of the 11th June 2020, 77 interventional clinical trials for evaluating these drugs in both the prevention and treatment of COVID-19 were registered and recruiting participants on ClinicalTrials. gov. The relatively weak antiviral activity against SARS-CoV2 in vero cell cultures has motivated trialling of higher loading and maintenance doses than usually given in malaria or hepatic amoebiasis  (World Health Organization, 2015). This has caused concern over the potential for cardiovascular toxicity. Nevertheless, despite the lack of any convincing evidence of clinical benefit, these drugs are now being used 1 of 26 Manuscript submitted to eLife extensively in COVID-19 prevention and treatment across the world. Sadly, patients who need hydroxychloroquine or chloroquine for the treatment of malaria and rheumatological conditions are often having difficulty obtaining them (Straits Times, 2020).
Borba et al. reported results from a randomised trial in Brazil of two dose regimens of chloroquine in COVID-19 treatment (CloroCovid-19 study, ClinicalTrials. gov NCT04323527)  (Borba et al. , 2020). The trial was stopped early after recruiting only 81 patients because of cardiac toxicity and greater mortality in the higher dose group; two of 41 patients given the higher dose regimen developed ventricular tachycardia before death and 7 of 37 patients in this group developed electrocardiograph QTcF intervals over 500 msec compared with 4 of 36 in the lower dose group. The higher dose regimen, comprising 600 mg base chloroquine administered twice daily for ten days, is substantially higher than recommended in malaria or rheumatological conditions  (World Health Organization, 2015)  and represents the standard malaria loading dose repeated 19 times at 12 hour intervals.