dataesr/scientific-paragraphs-categorization huggingface dataset:
MSE ¼ 1 N X N i¼1 Y True ðiÞ À Y Predict ðiÞ ½ 2 ð20Þ L 1 loss ¼ 1 N X N i¼1 Y True ðiÞ À Y Predict ðiÞ j j ð21Þ The convolutional neural network was trained using 100 epochs, learning rate of 0:008, and batch size equal to 20. The training and validation loss are shown in 16. As observed, in the final epochs the validation loss is lower than the training loss. After carrying out this process, some outputs generated by the developed system are shown below, where the red rectangle corresponds to the abnormality detected by the system. 17 displays the abnormality generated using Gabor filter, and the detection employing ResNet-18. In this way, an example of uveal melanoma detected with ResNet-18 is shown in 18. Meanwhile, 19 exhibits the results of uveal melanoma detected employing ResNet-18 with dataset without light spot on iris using process in 4.
Regarding technologies, it is recommended the use of protocol buffers (Protobuf) to transfer the images from client to server, the use of GPU with NVIDIA Triton Server which helps to standardize the deployment of the model and automatically optimizes the kernels and converts them into code for execution on NVIDIA GPUs, the use of Fast Data Preprocessing with NVIDIA DALI which provides a set of highly optimized building blocks and a runtime engine to accelerate the input data preprocessing for deep learning applications like the one of this study. Besides, it is suggested to use dynamic batching, which combines multiple requests in the same execution so that the model can provide larger performance. This study has shown two architectures with three configurations, each for a total of six models tested under cross-validation and configurations specially designed to address the problems seen in the literature.
Acknowledgment We wish to thank  Dr. Paul T. Finger, MD , the  New York Eye Cancer  and the  Institute of Automation of the Chinese Academy of Sciences  for providing the data required to conduct this study. We would like to thank  Universidad Distrital Francisco José de Caldas, École Nationale Supérieure Mines-Télécom Atlantique Bretagne-Pays and University of Nantes  for encouraging research. The study was self-funded.
Results: In this paper, we present our FAIR approach to transform COVID-19 observational patient data collected in the hospital into machine actionable digital objects to answer medical doctors' research questions. With this objective, we conducted a coordinated FAIRification among stakeholders based on ontological models for data and metadata, and a FAIR based architecture that complements the existing data management. We applied FAIR Data Points for metadata exposure, turning investigational parameters into a FAIR dataset. We demonstrated that this dataset is machine actionable by means of three different computational activities: federated query of patient data along open existing knowledge sources across the world through the Semantic Web, implementing Web APIs for data query interoperability, and building applications on top of these FAIR patient data for FAIR data analytics in the hospital.
The LUMC is a tertiary care, teaching and research hospital in the Netherlands that encompasses clinical and research groups with expertise on immunology, biomedicine, data management and data science. The groups work together on collecting and sharing different types of patient data, analyses, findings, expertise, and novel solutions implemented in the hospital (e. g. see  [20] ). One of the challenges is to implement a FAIR Research Data Management plan (RDM) com-prising FAIRification of priority resources and a FAIR based architecture that complements the existing data management systems in the hospital. We hypothesise that the use of existing ontologies and ontological models will enable turning patient data into machine readable digital objects that are prepared for secondary use. Our objective is to develop ontological models that represent and link the data records and metadata of the datasets in the existing LUMC data management systems (Fig.
1 ). In our ontology centred approach, data can stay in existing systems but are made accessible 'in terms of ' the central data linking model to create a virtual warehouse. We reused existing ontological models such as the core ontological model for common data elements developed in the European Joint Programme on Rare Diseases (EJP RD) for patient registries  [21] , and the Data Catalogue Vocabulary (DCAT) for datasets  [22]. The metadata is made accessible by a FAIR Data Point (FDP) instance  [23]. FDPs ensure that BEAT-COVID resources can be found and used through querying machine readable metadata. It includes the pointers to access the content of the resource for analysis workflows, if access is permitted. By using ontologies, patient data in the hospital are virtually linked with other ontologically described data in the hospital, but also public Linked 'Open'  Data (LOD).
This can boost the potential for knowledge discovery and data+knowledge driven analytics. Interestingly, ontologies may also be used to describe data access restrictions  [24, 25]  to complement FAIR metadata with information that supports data safety and patient privacy. In this paper, we describe and implement our approach for FAIRification of COVID-19 observational patient data in an academic hospital. We selected cytokine measurements of hospitalised patients as our primary objective of FAIRification and development of the FAIR RDM. We synthesized an artificial dataset mimicking original laboratory data obtained from patient samples to study the data lifecycle without the risk of violating patient privacy. Our main result is the FAIRification in the hospital. We also show that our FAIRifcation approach is providing cytokine measurements as FDOs and is enabling applications on top of this FAIR patient data for analytics.
FAIR status of patient data in existing systems Our FAIR assessment of the cytokine data in existing systems revealed that while the structure and findability improved with each step of the data management lifecycle, no FAIR standards were applied to make the data and metadata globally understandable 'for machines' , such as for automated computer processing (Table  1 ). The original data from the clinical laboratory that measured the cytokine levels was well structured, but not in a uniform, globally machine readable way. The data were further preprocessed manually and transferred to the Electronic Data Capture (EDC) software Castor  [26]. Although this captured data electronically and in a uniform way, there were no ontological representations added to the data collection forms to create a FAIR dataset.
Data was subsequently transferred from Castor into the Opal data warehouse system  [27] , conform the standard workflow for preparing data for research at the LUMC. Opal is a generic system to bring datasets from different systems in the hospital into one warehouse, supporting transformations and annotation on the data level with a vocabulary chosen by the user. Opal provides researchers at the LUMC a central access point to research data that are syntactically machine readable. It offers APIs that bioinformaticians can incorporate in their workflows. Anonymised data of daily parameters from patient records was imported into Opal without including retrievable patient identifiers in the research environment of the hospital on almost real time. Opal's native metadata tool Mica  [28]  provides annotation on the dataset level such as how, when, where, by whom, under what conditions data has been collected.
This information is subsequently published in a Web portal. Therefore, Mica provides resource information that is human readable on the Web. This metadata is not also available in a machine readable form. Findability for machines can be improved by adding a machine readable ontological representation. Our automated FAIR assessment of a dataset described in Mica (see here) showed specifically which FAIR improvements could be made to make the metadata descriptions in Mica more machine actionable and standardized. Although Mica implements unique identifiers, these were not persistent in our case, and they were also not explicitly defined in the metadata. This creates challenges for data accessibility and reusability. Some systems, notably Opal  [29] , provide handles to integrate FAIR features, but we chose to first incorporate independent components to minimize requirements for other systems and thereby optimize reusability of the approach.
Coordinated FAIRification A coordinated FAIRification process with BEAT-COVID colleagues was set up to improve the machine readability, global interoperability, and findability of the COVID-19 data. We developed ontological models for data record in collaboration with data collectors, data managers, data analysts and medical doctors. Similarly, we developed machine actionable metadata to improve the findability, accessibility, and reusability of the datasets in collaboration with IT and database managers. Both tasks were performed in parallel and in a synergistic way to consistently support the entire data management lifecycle for data analysis, and they are ongoing for additional data types. While the BEAT-COVID project group was maintaining one-hour bi-weekly video calls for general update and logistic discussions, specific video calls were set up with the required experts and duration for the topic at hand.
A1. 2 is especially relevant in the case of sensitive patient health data. In practice, we designed a model by extending the DCAT2 based metadata model 1  that is to manage the metadata of common datasets. With four additional metadata elements from three standard ontologies, including the property "TYPE" from the DCAT2, the properties "DESCRIBES" and "DATA INPUT OF" from the Allotrope Foundation Ontologies (AFO)  2  , and the property "HAS QUALITY" from the OBO Relations Ontology (RO)  3  , the metadata model features finer semantic granularity. In Fig. 4 , we show how we can specify that the BEAT-COVID data resource in our project is a knowledge base, that describes COVID-19, that is supposed to contain data input of clinical studies, and that has synthetic quality by means of these four object property values or edges in the RDF graph.
FAIR data point for assessing the metadata of BEAT-COVID patient data The basic idea of an FDP is to support scalable and transparent "routing" of data resources through stored metadata. The metadata stored and managed by an FDP makes the data resources described by the metadata semantically findable and reusable by machines. As an open gateway, it also makes different data resources accessible under defined constraints. Based on the designed ontological metadata model, we implemented an FDP to describe datasets in Opal and to publish FAIR metadata of these datasets on the Internet as complementary to the Mica system. This FDP publishes structured metadata for machines to automatically find BEAT-COVID datasets and to interpret how to access and use the data stored in Opal, for instance to those algorithms visiting the data with the right access (Fig.
5 ). Important to the FDP approach is that the data never leave its repository thereby protecting patient data and ensuring only authorized users have access. We performed an automated FAIR assessment of the same dataset from Mica described in the FDP. The results can be found here and showed that various aspects of the metadata description were improved in comparison to the Mica analysis results. For instance, FDP evaluation resulted in better identifier description of the (meta)data. With the publication of the BEAT-COVID resource metadata into the FDP we expect to increase the discoverability of COVID-19 patient data in the LUMC and to enable federated analytics for extended populations. To point out that an FDP is accessible and readable by machines through a REST API, and by humans through a Graphical User Interface (GUI).
Integrating the ontological models with the existing research data warehouse Our next step was to add access to patient measurements as instances of the ontological model ('ontologised data') as a feature to the existing RDM. In Fig. 5 , we show how ontologised data is integrated with the existing Opal and Mica data management system. Our objective was to use the Opal and Mica systems as a foundation for FAIRification in the LUMC. While the Opal system manages integration of datasets in the hospital, the Mica system adds valuable metadata about the data resources. Even though Opal and Mica do not directly provide semantic modelling functionality, they do provide a basic annotation functionality that we used as the basis for connecting the ontological models. To instantiate the ontological linking data model in RDF, we developed an 'RDFizer' Python script as a minimal prototype for patient data FAIRification (see yellow arrow from Opal to Triple Store in Fig.
5 ). Our current prototype uses CSV files with synthetic cytokine data as input to connect data from Opal to the ontological model that we developed for this data, thereby creating 'ontologised data' in RDF. Opal allows exporting datasets to CSV through its export function API  5. Conversely, REST Web APIs can be generated from the ontologised data using the grlc server  [38]  (see yellow arrow from Triple Store to Opal in Fig. 5 ). grlc is a tool to automatically convert SPARQL queries into REST Web APIs and make selected RDF data accessible to the Web. Moreover, it can translate SPARQL  [39]  queries stored and documented in GitHub repositories to Linked Data APIs on the fly. Essentially, it includes an additional DCAT2 data distribution interface (REST APIs) on top of the existing SPARQL endpoint.
Querying FAIR patient data with LOD for medical questions To showcase that the FAIR RDM and the derived data infrastructure allow answering medical questions by querying patient data in terms of the ontological model and together with external open science knowledge, we performed two simple SPARQL queries on the synthetic cytokine data (Table  2 ). The queries were defined to answer the initial real world medical doctors' hypothesis related to cytokines FAIR data. From clinical practice, doctors observed different disease courses with different cytokine related immune responses and different The first query demonstrates that clinical information from the LUMC can be queried, while the second demonstrates that queries can run across LUMC clinical data and external biomedical databases such as the UniProt protein knowledgebase by means of the federated SPARQL query shown in Fig.
FAIRification in the hospital The COVID-19 pandemic revealed how critically important it can be that patient data from multiple systems in the hospital are prepared for instant integrative analysis across those systems, as well as across hospitals and countries. This would be feasible if the hospital had a FAIR RDM plan that implied making patient data available as FDOs and thereby findable, accessible, interopera-ble, and reusable for computers  [1]. However, COVID-19 patient data are not yet natively collected as FAIR data. Therefore, we have described a strategy to facilitate the adoption of the FAIR principles in the hospital based on the FAIR architecture shown in Fig. 1  that complements an existing data management infrastructure. The strategy applies ontologies to increase the interoperability and machine readability of patient data records and patient datasets.
Patient data accessibility hurdles Protecting patient data and privacy is a major concern and it is part of FAIRification to make a clear reference to how data are protected. As researchers, we must establish data management mechanisms that ensure that patient privacy is preserved and its usage under control. There are several options to deal with data privacy and safety such as using anonymised datasets, using substitute synthetic representations of sensitive datasets, and having the legal and ethical framework in place for the processing of sensitive personal data in the sense of the GDPR. As first step, the hospital needs to develop and implement a data governance policy that clearly specifies how to extract and apply the data as approved by the patient in the informed consent. Delaying data governance may delay the FAIRification process because it needs to be clear what data will be available and in which form to plan the FAIRification, but also to specify data governance in the metadata of the resource when an algorithm visits the data to use.
International adoption of the FAIR principles for health data of hospitalised patients The method for FAIRification that we described is focused on patient derived health data, down to the data record level. Two main outcomes are that we produced FAIR data for hospitalized patients, and we demonstrated that this data is instantly reusable for various secondary uses: for building software applications (and analysis workflows) via REST Web APIs, for querying cross-domain patient data and open public knowledge to add richer context to answer healthcare questions. While there are several projects that develop FAIRification procedures, they predominantly focus on life sciences data  [14, 15, 51]. FAIR data in health is gaining momentum, and we already can find dedicated projects such as FAIR4Health  [52]  to use FAIR data in health to improve research.
Therefore, we mapped them to a more general class, for instance we mapped specific interleukins measurement datum types such as for 'interleukin-11' , 'interleukin-26' or 'interleukin-32' (among others) to the general data item class 'blood interleukin measurement'  9  , which is the superclass of 'blood interleukin-6 level' class  10  , or we mapped specific measurement process types such as for 'Tumor Necrosis Factor Ligand Superfamily Member 14' cytokine to the general process class 'Cytokine Measurement'  11. We expect new limitations once we analyze new omics datasets and clinical observations. Also, tools that evaluate the 'FAIRness' of data can guide the FAIRification process. This partly depends on the standards used by the domain of the data community providers  [57] , but it is not always clear what these standards are, if any.
Federated analytics across hospitals We also aim to show how this FAIR infrastructure allows to query FAIR data from the BEAT-COVID project in the LUMC across other hospitals' FAIR data without data leaving their source, i. e. the 'data visiting' approach. In the VODAN project, the GO FAIR VODAN in a box FDP  [60]  was used to test the trains and tracks of the PHT concept  [61]  and demonstrated the first intercontinental FDP SPARQL VODAN Africa proof of concept  [62]  developed by VODAN Africa and Asia -GO FAIR  [2]  query AllegroGraph WebView  [63]. Secure FDP technology testing must be developed to implement trusted access control policies and to enable visiting synthetic datasets and pseudo-anonymised healthcare data. We aim to build on the VODAN and TWOC experiences and prepare an FDP instance that publishes BEAT-COVID metadata to be automatically found and used in trusted automated analytics workflows across multiple hospitals.
FAIR digital objects and globally unique persistent identifiers (GUPRIDs) The FAIR principles, specifically F1, include the requirement that metadata and data should be identified by GUPRIDs. In addition to this, the FAIR principle A1 requires that metadata and data are retrievable by their identifiers using a standardized communications protocol. As such, we set up our persistent identifiers according to these requirements for data and metadata (and the FDP itself as well): Data The patient synthetic cytokines lab measurements dataset, which in turn is described by metadata records as FDOs themselves, is identified and retrievable by the W3ID persistent identifier service  12  base https://w3id. org/biosemantics-lumc/beat-covid/, e. g. the RDF distribution GUPRID is https://w3id. org/biosemantics-lumc/ beat-covid/rdf/beat-covid.
Metadata The metadata of the patient cytokines dataset is identified and retrievable by the PURL persistent identifier service  13  base http://purl. org/biosemanticslumc/test-fdp/dataset/ and the GUPRID is http://purl. org/biosemantics-lumc/test-fdp/dataset/91603187-9281-4588-8c4d-de9108171f85, and accessible through the LUMC BEAT-COVID FDP.
Ontologies We mapped to Open Biological Biomedical Ontologies or OBO ontologies to facilitate biomedical integrative analytics since these ontologies are developed to be interoperable, logically well-formed and scientifically accurate by the community following the OBO principles  [30, 31]. For data annotation with OBO ontologies we mainly used the Ontobee software system  14  , the Ontology Lookup Service from the EBI 15  , and the NCBO BioPortal  16  as search engines to find ontological terms. See the description of the ontologies used for each model below.
Data The BEAT-COVID dataset we based our ontological models was an anonymized longitudinal set of cytokine levels measured on COVID-19 hospitalized patients in the LUMC. We created a cut shorter and synthetic pilot version of the dataset to proof our concept approach for FAIRification in the hospital. We created the synthetic dataset using randomization functions in excel. The synthetic dataset contains 9 rows of measurement records on 103 cytokines performed in 4 different panels using Luminex technology. The dataset contains basic information for each record, such as the record timestamp, the date of sampling, the age of the patient, the date of measurement and the cytokine levels. Example to data records in tabular format is available on this GitHub -synthetic data link.
Software We used several technologies in the different steps of our method. The FAIRification tools and versions used are described within each step in the Methods section below. The software and tools we used to build three different applications on top of FAIR data, were: Data analytics with Semantic Web technologies. We used the W3C recommended SPARQL query language  [39]  to perform data analytics over the LUMC RDF patient data and across diverse external data sources in LOD. We used the free edition of GraphDB Triple Store v9. 7. 0, where the data is natively stored as RDF. Web API development. We used grlc v1. 3. 6  [38]  to enable programmatic access to FAIR data in the hospital. Grlc is a lightweight server that automatically builds consistent, well documented and neatly organized Linked Data APIs on the fly, with no input required from users beyond a URL path to a GitHub repository hosting a set of SPARQL queries that complies with the specific grlc syntax 39.
It provides three basic operations: 1. generates the Swagger spec of a specified GitHub repository; 2. generates the Swagger UI to provide an interactive user facing frontend of the API contents; and 3. translates SPARQL queries into HTTP requests to call the operations of the API against a SPARQL endpoint with parameters set in the queries. Hypothesis generation tool. We used the Neo4j graph database framework  [64]  as used in the structured reviews approach  [59]  for storage, management and mining of FAIR patient data. The graph database technology has been shown to facilitate management and exploration of biomedical knowledge  [65]. Neo4j graph database enables users to query the knowledge graph using the Cypher query language, either through an API or a GUI. RDF data was imported into the Neo4j Community Server v4.
Methods We defined and implemented a method to make COVID-19 observational patient data in the hospital FAIR. This method is described in a detailed FAIRification workflow 39 https://github. com/CLARIAH/grlc illustrated in Fig. 7  and is an adapted version of the workflow presented by Jacobsen et al. [12]. We explicitly add the result obtained in each step, where applicable. We also include in which steps the FAIR experts worked in collaboration with other members of the BEAT-COVID group.