dataesr/scientific-paragraphs-categorization huggingface dataset:
Optical and near The HST/WFC3 imaging and grism spectroscopy were obtained with the dedicated HST follow-up program (Program ID: 13740; P. I. : D. Stern). We obtained F140W imaging (with a field of view of 2 × 2. 3 arcmin 2 at a resolution of 0. 06 arsec pix -1 , obtained after taking into account dithering), and G141 grism spectroscopy (with a thoughtput > 10% in the wavelength range of 1. 08 µm < λ < 1. 70 µm and spectral resolution R = λ/∆λ = 130). This grism was chosen in order to permit the identification of strong emission lines at our target redshift, such as Hα, Hβ, [O ii] and [O iii]. Noirot et al. (2016 Noirot et al. ( , 2018) )  performed the data reduction using the aXe  (Kümmel et al. 2009 ) pipeline, by combining the individual exposures, and removing cosmic ray and sky signal.
Noirot et al. (2018)  performed the source detection with SExtractor  (Bertin & Arnouts 1996)  and extracted two-dimensional spectra for each field, based on the positions and sizes of the sources. The redshifts and emission line fluxes were determined using the python version of mpfit and are published in  Noirot et al. (2018). CARLA J1103+3449 was followed-up with i-band imaging with WHT/ACAM (PI: N. Hatch;  Cooke et al. 2015) , and we obtained a PSF-matched photometric catalog in the WHT/ACAM i-band, WFC3/F140W (detection image), IRAC1 and IRAC2. The i-band, WFC3/F140W, and IRAC1 filters correspond to the UVJ rest-frame bandpasses at the redshift of CARLA J1103+3449. More details on the Spitzer IRAC, HST/WFC3 and WHT/ACAM observations, data reduction and results can be found in  Wylezalek et al.
Keck AGN spectrum observations The redshift for the radio source B2 1100+35, associated with WISE J110326. 19+344947. 2 at the center of CARLA J1103+3449, was first reported in  Eales et al. (1997)  as z = 1. 44, but with no spectrum presented. With no spectrum available from the Sloan Digital Sky Survey of the faint, red (g = 23. 9 mag, i = 21. 4 mag) optical counterpart to the radio source, we observed B2 1100+35 with the dual-beam Low Resolution Imaging Spectrometer (LRIS;  Oke et al. 1995)  at Keck Observatory on UT 2019 March 10. The night suffered strongly from variable, often thick cloud cover. The data were obtained through the 1. 0 slit with the 5600 Å dichroic. The blue arm of the spectrograph used the 600 mm - 1  grism (λ blaze = 400 Å; resolving power R ≡ λ/∆λ ∼ 1600 for objects filling the slit), while the red arm used the 4000 mm -1 grating (λ blaze = 8500 Å; R ∼ 1300).
48 GHz at z ∼ 1. 44 (the mean confirmed cluster member redshift from  Noirot et al. 2018) , observed in NOEMA's 3mm band. We cover our target with three pointings to map the AGN and the central cluster region. The pointings were positioned so that we could cover as many IRAC color-selected members as possible (∼ 40) along with the 7 (out of 8) HST/WFC3 spectroscopically confirmed members (green circles and a red star, for the AGN, in Fig. 2 , based on  Noirot et al. 2018). We chose the antenna configuration C to be able to separate cluster mem-bers in the cluster core. The beam size is 4. 14 × 3. 46 arcsec 2 , the PA = -171. 01 • and the velocity resolution is 50 km s -1 (smoothed to 100 km s -1 ; see below). We perform the entire NOEMA data calibration by running the pipeline in the clic package of the IRAM/GILDAS software 1.
We flag additional data, modify antenna positions and calibrate again the flux. While the pointing and the focus were excellent, the amplitude and phase were of average quality because of the weather conditions. With the reduced data, we create a CO(2-1) continuum emission mosaic map, by using the mapping package of the GILDAS software (Fig. 3 left ). The map was obtained by averaging the flux over a velocity range of 2450 km s -1 , excluding emission lines, with a background rms noise level of σ ∼ 0. 2 mJy beam -1. Then, we subtract the continuum from the CO(2-1) emission in the uv-data set in order to obtain a clean, continuum-subtracted CO(2-1) map. We calculate the root mean square (rms) noise level in the three pointing intersection region of the CO(2-1) map (see Fig. 2 ). In this region, the original velocity resolution is 50 km s -1 and the rms noise level is σ ∼ 0.
ORIGIN OF THE MOLECULAR GAS IN THE CLUSTER CORE In the core of the cluster, we observe two CO(2-1) emission peaks that correspond to a region spatially offset from the center of the AGN continuum emission and that does not correspond to any galaxy detected in our HST or Spitzer images. Radio observations of the CARLA J1103+3449 cluster from the work of  Best et al. (1999)  reveal two radio lobes, which are roughly in the same directions (east and west) as our CO(2-1) molecular gas components and our data extended continuum emission (Fig. 4 , 7, 8). The two radio lobes are asymmetrical, the western being more compact, while the eastern is more diffuse. The asymmetry of their widths may be due to their expansion in an ICM (Intracluster Medium) with a density gradient, in which the more diffuse lobe, the western lobe, would be expanding in a less dense environment (e.
Acknowledgements. We thank the PI of the Keck observations,  Fiona Harrison , for providing these observations and  Thomas Connor  for assisting with the Keck observing. We thank  Philip Best  and  Katherine Inskip  for useful discussion and their kind sharing of their radio, optical and infrared observations of the central radio sources and lobes. The data reduction and mapping and most of data analysis was done by using IRAM/GILDAS free software (http://www. iram. fr/IRAMFR/GILDAS/),and with the assistance of the IRAM support astronomers in Grenoble,  Cynthya Herrera  and  Melanie Krips , which we warmly thank. We would like to thank the GILDAS support team for their help and guidance for the data analysis,  Sébastien Bardeau  and  Vincent Pietu. V. M. would like to thank  Anelise Audibert ,  Benoit Tabone ,  Valeria Olivares  and  Gianluca Castignani  for their help with the data mapping and analysis.
There were neither guidelines nor publications which could help to make this decision. They queried the data warehouse for similar cases and made "the decision on the basis of the best data available. " This paper opened the gates to a new utilization of EHRs: repurposing the clinical data to develop decision support systems inside the EHR. The virtuous circle  6  of translational research could then be closed: from routine care data to research, and from research to clinical care. In the context of rare diseases, the capacity of reusing EHR data to support diagnosis is even more critical. Indeed, given the rarity of these diseases, the diagnosis journey of the patients often last for years  7. Tools taking advantage of the data of already diagnosed patients to help the decisions for the new cases could save a lot of time.
We designed a query (Figure  1 ) to find references in Medline on how the EHR may be used to diagnose rare diseases. This query returned 52 references as of February 14 2019. We performed a manual review and removed 7 references that were false positives (acronyms with other meaning). Among the remaining 45 publications (categories are not exclusive): • 20 publications report the results of clinical studies (epidemiological studies, clinical trials, natural history of diseases). The authors used EHRs to recruit the patients and/or to describe the natural history of the diseases. • 5 publications present structured EHRs tailored for the reuse of the data for a specific rare disease. • 6 publications describe rare disease registries. • 5 publications provide description of methods to recruit patients based on EHR data.
This last example introduces the necessity of integrating data into a new data model to clean and enhance it for efficient repurposing. EHR data models are designed for care purposes not for research. They are optimized to efficiently enter and retrieve all data for one patient at a time. Therefore, they are composed of hundreds to thousands of different tables which make it difficult to make transversal queries (i. e. query specific data for a large number of patients). The strategies that were implemented to overcome this issue: (i) the creation of structured EHRs dedicated to translational research and (ii) the creation of copies of the clinical production databases in translational data warehouses, are described below.
They used international terminologies such as the Human Phenotype Ontology (HPO)  21  , the Online Mendelian Inheritance in Man (OMIM)  22  and Orphanet  23  , as well as a standard data exchange format, the Fast Healthcare Interoperability Resources (FHIR) to structure and transfer the data  24. Semantic integration of EHRs and other resources is another way to improve data reuse. Chelsom et al. enhanced the open source EHR cityEHR with semantic web technologies OWL (Web Ontology Language) to map the data onto knowledge databases in order to display relevant information to the clinician  25. OSSE  26  or FluxMed 27 also implement structured EHRs specialized for rare diseases. Asking clinicians to tick hundred of boxes is, however, not efficient: it is time consuming and in the context of rare diseases checkboxes do not qualify diagnoses or phenotypic descriptions.
Translational data warehouses The common EHR system is rarely the sole source of information in a hospital. Most of the time the Hospital Information System consists of a combination of several software and databases dedicated to specific tasks or specialties (EHR, PACS, Biological Results, pathology, etc. ). These databases are more or less interoperable. In addition, dozens of decommissioned databases are stored on local hard drives or servers inside the hospital and are generally not available for clinical care or research. Until recently, physicians and researchers have built registries to serve specific goals. Wen et al. compared the efficiency (time, cost and number of participants) of registry versus data warehouse methods to recruit patients. They demonstrated that the data warehouse method was more efficient with more participants recruited in less time and at a lower cost  29.
Built on top of EHRs, Clinical Data Warehouses enable collection and secondary use of clinical data for many purposes, including research (Phenome-wide analysis, record mining, epidemiological surveillance, pharmacovigilance, etc. ). Most major hospitals built their own data warehouses to aggregate all the clinical data produced  [30] [31] [32] [33]. For example, the multidisciplinary consortium NACI (NephCure Accelerating Cures Institute) developed a data warehouse specifically to improve care for nephrotic syndrome  34. Several research projects have developed open source or free license data warehouses. The most widespread and commonly used is i2b2 developed by the NIH-funded National Center for Biomedical Computing based at Partners HealthCare System in the US  35, 36. i2b2 is primarily oriented toward structured data related to thesauri.
Another open source tool, Dr Warehouse was developed at Necker hospital, a pediatric hospital specializing in rare diseases, and was oriented toward clinical documents such as narrative reports  37. It integrates 26 different sources of clinical data, over 500 000 patients and 5 millions clinical reports. These data warehouses aim at accelerating recruitment but also the mining of data by integrating pre-and post-processing methods. For example, Davis et al. developed natural language processing methods to extract clinical traits from the Vanderbilt data warehouse in order to recruit patients with multiple sclerosis  38. Their algorithm was highly specific to cases of multiple sclerosis but it highlights the potentiality of biomedical data warehouses to recruit patients with complex phenotypes.
Other search engines, like in Dr Warehouse  37  and Emerse  53  , are oriented toward free text and provide an intuitive user interface to find patients. Dr Warehouse combines queries on free text, coded data, and temporal relations between the search criteria. PheKB is a platform that proposed a catalog of queries including criteria to find patients based on phenotypes (combination of ICD codes, medications, laboratories and natural language processing)  10. For example, Mayo clinic share a flowchart to recruit patient called "Electronic Health Record-based Phenotyping Algorithm for Familial Hypercholesterolemia".
Internet tools and diagnosis The web has become a primary source of information about rare diseases. Several websites offer search engines specializing in rare diseases and use scientific literature to allow users to find diagnoses by querying phenotypes (FindZebra 72 , Phenolyzer 73 , PhenoDis  74  , Rare disease discovery  75  , GDDP  76  ). They extract and curate information found in publicly available information on rare diseases such PubMed, Wikipedia or Orphanet. And they enriched them with ontologies. HPO is widely used as a standard ontology to annotate diseases with phenotypes, to calculate the information content of phenotypes, or to provide common pivot semantics to heterogeneous databases. Other knowledge resources are used to enrich existing data, for example rare disease description or gene-phenotype annotations: Orphanet 23 , UMLS  77  , eRAM  78  , Uberpheno ontology  79  , Gene Ontology 80 , ClinVar 81 etc.
Most of the time, machine-learning algorithms are centered on a specific pathological condition. They can be trained on literature and knowledge extracted from unstructured EHRs (text mining and PheWAS) then applied to EHRs' data to help clinicians diagnose a specific disease. Examples include Hunter syndrome  89  , cardiac amyloidosis  90  , and Allergic Bronchopulmonary Aspergillosis  91. Liang et al. developed a machine-learning model to predict the primary diagnosis of a patient's encounter among a set of 50 diseases 88 by using the clinical data produced during the encounter. Their model was trained on a set of health reports manually annotated by pediatricians and obtained high diagnostic accuracy across multiple organ systems. However none of those diseases were rare.
Imaging and diagnosis Regarding common diseases, several studies demonstrated strong performance in imagebased diagnoses, notably in imaging  92  , dermatology  93  , and ophthalmology  94. In the context of rare diseases, Gurovich et al. published deep learning methods on pictures of patients to detect facial dysmorphism associated with syndromic conditions 66. Their system, called DeepGestalt, was trained on a dataset of over 17,000 images representing more than 200 syndromes. DeepGestalt is a form of next-generation phenotyping technology no longer based on the text but now on photographs.
Artificial Intelligence for care and management The figure  3  detailes the different steps for developing and implementing a CDSS in CKD. Machine learning methods are also used to optimize care processes, for example anemia management in end-stage renal disease  95, 96  , prediction of response after neo-adjuvant chemoradiation  97  , automated alerts on acute kidney injury  98  or outcome predictions of chronic kidney disease with random forest regression  99  or Support Vector Machine 100. For this random forest regression, authors built the model using the data of 61,740 EHRs to predict kidney function and provide clinical decision support with high macro-averaged and microaveraged metrics. Ennis et al showed that CDSS improves primary care physicians adherence to guidelines for laboratory monitoring of CKD  101.
Clinical and omics data Chen et al. 103  developed an algorithm to identify patient with ciliopathies. This group of rare and severe diseases are cause by ciliary dysfunction, associated to over 200 genes. Ciliopathies can affect all organs, and are divided into 30 rare syndromes whose clinical signs overlap each other. The authors addressed two tasks: (1) identifying patient with ciliopathies from patients with other nephropaties, and (2) phenotypic subtyping ciliopathies. For the first task, they compute similarity metrics on the phenotypes extracted from the EHR of Necker hospital. They evaluate several similarity metrics on 77 patients with ciliopathies amongst 10,462 patients with nephropathies. Unsupervised machine learning methods were applied to select the relevant phenotypes to accomplish this task: linear support vector selection with l2 penalty, tree-based selection and random forest selection.
The linear support vector selection gave the best accuracy to find patients with ciliopathies with a precision of 76% in the 30 patients most similar to an index patient. For the second task they considered the clinical research data collected from 1,031 patients mutated on genes associated to ciliar dysfunction. The unsupervised clustering method showed strong concordance with expert knowledge. Similarity metrics applied to rare genetic disease in nephrology offer new perspective to recruit patients for research and reduce the diagnostic journey. The phenotypic similarity associated with omics data will address precision medicine, especially in the context of complex rare diseases like ciliopathies. It is crucial to diagnose the patient before onset of renal failure, so that the patient can benefit from a drug as soon as possible.
EHRs and the hospital's collective memory Several situations may require having access to the hospital memory to make an informed decision for a patient: (i) complex patients with rare conditions for whom the published treatment guidelines do not provide a clear recommendation, (ii) undiagnosed patients, (iii) finding undiagnosed patients eligible for diagnoses based on the presentation of index patients with new mutations. At Stanford, a specialty consultation service composed by a team of medical and informatics experts mine EHRs data and other health databases to "learn from patients like mine". They provide a summary of what happens to patients similar to the patient proposed to the staff  104. Even with a search engine that enables the mining of historical data, it can be a complex task to find patients similar to an index patient.
Conclusion Artificial intelligence based on EHRs to diagnose rare diseases is not yet well developed. Several obstacles must be overcome to accelerate the development of these very promising algorithms to reduce diagnostic wandering and improve patient care management. For example, many efforts must be made to efficiently analyze the free text in order to extract reliable and accurate information. To achieve this goal, we have to decompartmentalize care and research in order to accelerate the repurposing of clinical data for new knowledge and the repurposing of new knowledge for better care. We have described several algorithms developed during research projects but rarely integrated into the hospital information system for use by clinicians. Expectations of patients with rare disease and clinicians are high; learning health systems must strive to meet them.
We developed flexible architecture to cover our customers' varying needs, along with failure and machine domain ontologies. To demonstrate the feasibility of SemKoRe, a proof-of-concept is developed. SemKoRe gathers all failure related data in the knowledge graph, and shares it among all connected customers in order to easily solve future failures of the same type. SemKoRe received the approval of several substantial clients located in USA, UK, France, Germany, Italy and China, associated with various segments such as pharmaceutical, automotive, HVAC and food and beverage.
Schneider Electric works with several Original Equipment Manufacturers (OEMs) who design, build and ship machines for their customers around the world. In our experience, there is no easy way to align the data coming out of these maintenance systems and to thereby get a uniform understanding. This issue is complicated by the heterogeneity of these systems and the associated silos since each business segment and customer is unique and operates under different regulatory and geographic constraints. Despite these challenges, our customers are increasingly demanding better visibility about the performance of their assets, reductions in maintenance costs and downtime, improved productivity and more agility in their end-to-end processes. In this paper, we present the early outcomes of our work, SemKoRe: how we use it to construct knowledge graphs of machine failures and exploit it to address various issues.
g. , Excel). This approach is not fault proof as each person filling out the sheet cannot be expected to provide all the required information and even if that information is given, there will be semantic mismatch, e. g. , one person describes issue as "abnormal rotation speed" while another person describes the same issue as "irregular spinning rate". Both mean the same but use different semantics (we provide more details on it based on interactions with our actual customers in Section 2). SemKoRe helps to avoid this semantic mismatch, and captures all the machine, failure and maintenance data as a knowledge graph, allowing several actors to benefit (Sections 4 and 5). For example, Operators and Technicians can benefit from the knowledge provided by other operators at different sites to address their issues.
Each gateway is connected to a central entity (either a Local SemKoRe or a SemKoRe Server) which collects the data from all the gateways and then aggregates and shares with the gateways connected to the same type of machine. Though, the Achilles heel of our proposal remains the case of the first category of customers, i. e. , who do not want to connect their factories to the cloud. The unique technical solution to share the maintenance knowledge consists of using physical supports (e. g. , USB keys, CDs,. ) with human intervention. However, the internal business case analysis is still in progress. We believe that once the business case is finalized, the technical adaptation of the SemKoRe services will be trivial and will not require lot of efforts. In this paper, we focus on the cloud-based architecture because it covers all the constraints and features of the other architectures.
7. Create instances and check exceptions: Instances of SemKoRe ontology are divided into two parts. The first part, defined by experts during the design time, concerns the generic concepts that will be used for most industrial use cases, such as Severity level (Catastrophic, Critical, Moderate, Low). The second type of instances concern the data provided by the users during the runtime of the SemKoRe. Users instances include details about the failures and symptoms. To check for exceptions, we used Pellet reasoner  [26]  to verify the correctness of our ontology model. In addition to the failure ontology, we also created a machine domain ontology (Figure  4a ) to describe the machine components to satisfy our requirement to link failures to specific machine components when and where they occur, as simply knowing about a failure is not useful on its own.
SemKoRe Process Figure  5  shows the SemKoRe process of failure data collection and sharing. The process is distributed on two layers: on the edge with the SemKoRe Agent, and on the cloud with the SemKoRe Server. The failure data collection starts when a machine failure occurs. The failure information collection service generates the Human Machine Interface (HMI) for the user (Bob or Alice) to offer the details of the failure Figure  6. Through the survey, we first try to know if the failure has really occurred or it was only a false positive case triggered by some failure detection service. Then the user is asked to provide details about the symptoms of the failure by selecting known symptoms or by creating new ones, when necessary. The user checks if the identified failure is already known by the SemKoRe before providing additional details.