dataesr/scientific-paragraphs-categorization huggingface dataset:
Step 2 and step 3: analyze data and metadata Research data management in the hospital. From admission date until discharge, patient data were collected by different departments. The types of COVID-19 observational data relevant for research, and so for FAIRification, were diverse: demographics information, clinical information, laboratory measurements, transcriptomics (RNA-Seq) data, metabolomics data, and if the patient was transferred to ICU, then data related to ICU outcome. The format depends on the different EDC systems used. Within LUMC, clinical and preclinical information were collected in HiX  [68]  and Castor EDCs  [26] , whereas ICU data was managed by the MetaVision software  [69]. These EDC systems have different data access interfaces and use different technologies. To provide a single point of data access, research data were combined in the Opal data warehousing system.
Opal is the OBiBa's (Open Source Software for Epidemiology) core database application to store data in central data repositories that integrate under a uniform interface data collected from multiple sources, and it provides tools to import, transform and describe data  [27]. Patient data was anonymised before importing it into Opal using advanced data encryption. Descriptions of the datasets, i. e metadata, stored in Opal were published on the Web through the Mica software application. Mica is used to create Web data portals for large scale studies or multiple study consortia. It provides a structured description of consortia, study catalogues and datasets, annotated and searchable data dictionaries, and data access request Fig. 7  BEAT-COVID FAIRification workflow to make the data management and infrastructure in the hospital more FAIR.
FAIR analysis of COVID-19 observational patient data. To improve the findability, accessibility, interop- erability, and reusability of digital assets, we performed a FAIR analysis of (meta)data, i. e. an analysis of the FAIR status of data and metadata. We analysed data and databases to evaluate the FAIRification effort needed  [12]. We started by analysing observational clinical measurements. We first got access to laboratory measurements of immunoresponse clinical parameters, cytokine levels, collected on different time points per patient to monitor its condition progress. Access to data was provided to us as an anonymised dataset. Then, we analysed the databases where these data were stored, which were first in Castor databases since this was the primary EDC system used in the hospital, second in Opal data warehouse since this system was used to integrate and store data from the various data sources.
Step 2a and step 4a: improving interoperability with semantic web technologies and a linking data model We described a synthetic cytokines dataset with ontologies. In Europe, GDPR imposes obligations onto organizations anywhere, so long as they target or collect data related to people in the EU. To comply with GDPR, we created a synthetic dataset of cytokine measurements, i. e. substituted synthetic representations of sensitive datasets, by using randomization for modelling patient data. This dataset contains basic information related to cytokine measurements and biosamples used per patient and time point, and a patient clinical identifier to link to clinical data. With the goals to answer research questions of medical doctors and make patient data machine readable to enable interoperability within data resources in the hospital and with external open science datasets such as LOD, we designed ontological models for cytokine lab measurements, biosamples and severity scores to represent data based on the Linked Data principles  [71]  and Semantic Web technologies such as the W3C recommended RDF and OWL standards  [32, 33].
Step 3a and step 4b: improving findability, accessibility, interoperability and reusability with semantic web technologies, a metadata model and FAIR data points With the goals to answer research questions of medical doctors and make resource metadata human and machine readable to enable cross-resource data analytics, we designed a metadata ontological model and implemented an FDP instance  [23]  to make LUMC COVID-19 digital objects findable for machines on the Internet. An FDP is a Web application that enables data owners to expose information about their datasets using rich machine actionable metadata. It allows creating, storing, and serving FAIR metadata about datasets and its distributions for both humans and machines. An FDP does not enable open access, but the metadata is expected to include information about what the resource contains and how datasets and content can be accessed under defined conditions.
Opening up FAIR (meta)data by publishing them on an FDP allows algorithms to search these (meta)data, looking for patterns  [72]. Mica is a tool to expose datasets from an Opal database on the Internet through Web portals that allow (meta)data descriptions. An FDP provides additional means to expose FAIR metadata, i. e. machine actionable, via the FDP specification, a standardized metadata ontological model based on DCAT  [22]. FDP also exposes (meta)data via a REST Web API that enables client applications to automate retrieval, aggregation and filtering (meta)data from distributed FDPs. We used FDP v1. 10. 0.
Step 5 and step 6: make (meta)data as linked data and host FAIR data To host and publish patient data, we cut the original synthetic cytokine patient dataset into a few rows. We generated patient Linked Data using this synthetic patient data we created as input and instantiating the linking data ontological model. To do it we developed 'RDFizer' a FAIRification tool in Python 3 that parses and converts the synthetic data CSV file into RDF. To host the generated FAIR data, we used the free edition of GraphDB Triple Store  [73]  v9. 7. 0 where the data is natively stored as RDF. We implemented an FDP instance where the metadata ontological model is described and published as DCAT based Linked Data.
Post-FAIRification Step 7: assessment and software applications Evaluation We evaluated the discoverability of the BEAT-COVID resource by means of the FAIR Maturity Indicators evaluator tool  [74]. We have evaluated our ontological models by means of several CQs  [58]  (in progress). We have answered the questions using SPARQL queries for the sake of reusability, then users can reuse the queries if they want updated answers in the future. Built applications on top of FAIR data. We implemented three different applications: 1. SPARQL federated queries for data analytics with Semantic Web technologies; 2. Web API service for programmatic access; 3. Knowledge graph based hypothesis generation tool. See software details in the Materials section.
Acknowledgements We would like to specially thank  Eleni Mina ,  Tooba Abassi-Daloii ,  Daniël Wijnbergen ,  Winette Koning ,  Luiz Olavo Bonino da Silva  and  Katy Wolstencroft. We would also like to thank our EJP  RD colleagues Peter-Bram 't Hoen  and  Mark Wilkinson  for all the discussions. Finally, we would like to thank  Professor Barend Mons  for inspiring us to make a real difference in data sharing and knowledge representation.
Online monitoring As presented previously, there are two techniques for monitoring the Vds(on) and Ids(on) of EPC2206; "online" and "offline". This involves integrating the online voltage monitoring solution Vce(on) into the LTspice model of the converter. As explained in paragraph 3. 2, the EPC 2206 manufacturer's model has been integrated into the LTspice software. Our work will be focused on the bottom transistor (Q2) because it is referenced to ground compared to the top one. A desaturation protection technique is popular in modern gate driver circuits to protect the transistors from short circuit and overload. A similar approach is used in the online voltage measurement circuit as shown in Fig. 5. Two diodes are connected in a series, and a weak current source (I 1 in Fig. 5 ) is forward-biased to them during the transistor turn-on period of the EPC2206.
It is necessary to record this value at regular intervals to ensure the monitoring. The recording frequency can be defined in an intelligent way and vary during the life of the converter according to the state of ageing of the transistor by an artificial intelligence algorithm. The data acquisition was the subject of a prototype following this study. The filtered voltages from the two values to be measured, Vdson and Idson, are converted into digital data thanks to a 16 bits I2C converter ensuring a satisfactory measurement accuracy. The process is controlled by a microcontroller. The surface temperature of the transistor is measured by a pyroelectric sensor. The data transfer, storage and processing are ensured remotely by a Wifi radio link. The implementation of the monitoring device, the sensor, converter and microcontroller will finally be located near the converter under test, the data will be deported and recorded to the monitoring unit located remotely as an IoT.
Introduction The development of computational tools to assist and inspire the musical composition process constitutes an important research area known as Computer-Assisted Composition (CAC)  (Fernandez & Vico, 2013; Ariza, 2005). Within CAC, target-based computer-assisted orchestration is a compelling case of how machine learning can be used for enhancing and assisting music creativity  (Maresz, 2013). Target-based computer-assisted orchestration takes a target sound as an input and attempts to find instrumental samples that best match the target given a specific similarity metric and a set of constraints. The target can be any arbitrary sound file, it does not have to be pitched, rhythmic, or "musical" in any way. A solution to this problem is a set of orchestral scores that represent the mixtures of audio samples in the database, ranked by similarity with the target sound.
Valid orchestral scores may contain several instruments sounding simultaneously, selected out of a large number of possible combinations of sounds from the database. The approach studied in  (Carpentier, Tardieu, Harvey, Assayag, & Saint-James, 2010)  consists in finding an orchestration for any given sound by searching combinations of sounds from a database with a multi-objective optimization heuristic and a constraint solver that are jointly optimized. Both the target sound and the sounds in the database are embedded in a feature space defined by a fixed feature function and each generated combination of sounds is evaluated by using a specific metric. This method has been substantially improved in  (Cella & Esling, 2018; Cella, 2020)  and is implemented in the Orchidea toolbox for assisted orchestration (www.
The next sections will be as follows: section 2 will describe the dataset we used for experiments and the models we trained as classifiers, showing the classification results. Sections 3 and 4 will present, respectively, the results of orchestration experiments using the trained models and the conclusions of our preliminary study on neural approaches for target-based computer-assisted orchestration. The codebase for this paper can be found at https://github. com/dzluke/ DeepOrchestration and you can listen to audio examples at https://dzluke. github. io/DeepOrchestration/.
From Classification to Orchestration In this paper, we model assisted orchestration as a classification problem. The general methodology is as follows: 1. We train specific models to classify the instruments present in combinations of sounds from a database of instrument notes, up to ten simultaneous instruments; 2. We then pick the best classifier and we feed into it an unknown sound to be classified; 3. Since the output of the classifier will be in the form of the probability that specific instruments-note pairs are present in the sound, we use this information to synthesize an orchestration for the target sound; 4. Finally, we evaluate the generated orchestration against state-of-the-art systems for computer-assisted orchestrations. In order to have a baseline to compare our classification results and to get a sense of the complexity of the problem, we used various parametric classifiers along with the neural models.
Dataset To create the input data for training the classifiers, we used the TinySOL database. TinySOL is a subset of the Studio On Line (SOL) database created by IRCAM  (Cella et al. , 2020). TinySOL contains 1,529 samples from 12 instruments. The instruments come from different orchestral families: strings, woodwinds, and brass. Each sample is one instrument playing a single note in the ordinario playing style, with one of three dynamics: pp, mf, or ff (for example Flute-C4-pp or Clarinet-D5-mf). The instruments and ranges over which they were recorded are summarized in Tab. 1. For a given number of instruments N , each input to our model is a combination of N randomly selected TinySOL samples chosen from an orchestra of ten instruments. The only constraint imposed on the random selection is that there cannot be more than three samples from the same instrument in any one combination.
We used the Librosa package in Python to compute the features; more details on the exact computations can be found in  (McFee et al. , 2015). The choice of the hop length is a compromise between the amount of information extracted by each FFT window, and the ability to capture temporal changes in the sound. The Mel spectrogram is a representation of sound that mirrors the non-linear way in which humans perceive frequency, which makes it a perceptual representation of sound. Since we are attempting to recreate the timbre of a sound, and timbre is a perceptual descriptor, the Mel spectrogram is a fitting representation. It is common in music information retrieval  (Mckinney & Breebaart, 2003)  and has been successfully used in other tasks that employ neural networks for sound classification  (Salamon & Bello, 2017).
Data Augmentation In order to increase variability in the generated data for the neural models, we also used two methods of data augmentation as described in  (Salamon & Bello, 2017; Bhardwaj, 2017) ; more specifically, we used pitch shifting and partial feature dropout. Pitch shifting was applied on the TinySOL samples each time they were selected to generate a new combination. We performed a small pitch shift by reading the samples with different sample rates: a small difference in sample rate will slightly modify the duration and the perceived pitch if played at the normal sample rate. In practice, the sample rates used for this data augmentation were within 5% of the actual 44100Hz. Partial feature dropout was performed on the feature matrix itself of input samples, the Mel spectrogram.
In  (Gillick, Cella, & Bamman, 2019)  the authors propose to use LSTM-based models to predict the embedding features for the combinations used during the optimisation process in assisted orchestration. We believe that by combining their prediction model with our classification models we could generate more faithful representations and improve the overall quality of generated orchestrations. Finally, the OrchideaSOL dataset could replace TinySOL as the dataset used. OrchideaSOL could improve the system by adding extended playing techniques to the data, which can allow noisier targets to be better orchestrated. Orchidea-SOL contains 13,265 samples from 14 instruments, almost ten times as many samples as TinySOL  (Cella et al. , 2020). This would greatly increase the number of classes, and therefore the models would need to be trained on more samples and the number of layers in the models may need to increase.
Forty-two distinct SVs were observed, of which 40 are not reported previously. With this, we quadrupled the number of precisely mapped distinct SVs associated with BCM. This uniquely large collection of BCMlinked SVs not only includes a plethora of unique cases (such as the intrachromosomal gene conversion of an intragenic deletion or an SV undergoing a subsequent loss of a residual OPN1MW gene copy) but also allows us to extract some general features of the structural composition and insights into the mechanisms of nonrecurrent SVs at the OPN1LW/OPN1MW gene cluster. Moreover, our data suggest that such SVs often originate from subjects carrying high-number multicopy gene arrays which are predisposed to undergo genomic rearrangements.
Results SVs at the OPN1LW/OPN1MW Gene Cluster Are a Common Cause of BCM. Among our cohort of genetically confirmed BCM families (n = 213) which were collected and genetically investigated over a period of more than 25 y, we identified 73 families (34%) carrying an SV as a cause of the disease (Fig. 1 ). X-linked inheritance of the condition was commonly reported and documented in the families' pedigree (Dataset S1). The cosegregation of the SV with the disease was tested and confirmed where affected family members were available. We only observed a single case for which we could establish a de novo event in the lineage of an individual family (BCM 17/SVar10, Table  1 )  (19). Landscape of SVs at the OPN1LW/MW Gene Cluster in BCM Patients. Of the 73 independent BCM families that tested positive for an SV in the initial PCR-based screening, we were able to define the exact breakpoint(s) at single-base resolution in all but one family.
High OPN1LW/OPN1MW Gene Copy Number May Predispose to the Occurrence of SVs. Given the high prevalence of SVs in BCM we asked whether certain features of the OPN1LW/ OPN1MW gene cluster predispose to the occurrence of SVs. A special characteristic of the OPN1LW/OPN1MW gene cluster is its repetitive nature with multiple copies of genes and intergenic sequences with very high sequence homology, a feature which is known to induce nonallelic recombination events. We therefore investigated whether a large copy number (prior to the SV event) may predispose to the occurrence of nonrecurrent SVs. For this purpose, we determined the copy number of remaining OPN1LW and OPN1MW genes in subjects with SVs utilizing qPCR and MLPA. We used these data to deduce-by parsimonious assumptions-the minimal number of copies of the individual ancestral array prior to the occurrence of the SV event.
For instance, for a subject with a single full or partially intact OPN1MW copy we conservatively assumed an ancestral copy number of two (one OPN1LW and one OPN1MW gene copy). We excluded SVar1, the intragenic 142-bp deletion which implicates gene conversion, as an underlying mechanism as well as all SVs involving deletions of the entire gene locus or all OPN1MW genes which prohibits ancestral copy number reconstruction. We compared the data from the BCM-SV group (n = 33; i. e. , distinct SVs) with those from a group of color visionnormal observers of German descent (CVNO, n = 35) (Table  2 ). Mean total copy number was 3. 31 for the CVNO cohort and 4. 03 for the BCM-SV group. However, this difference in mean total copy number is in parts inflated due to the very large gene arrays (reconstructed with n = 8 and n = 14 copies) in SVar14 and SVar28 in the BCM-SV group.
The LCR upstream of the OPN1LW/OPN1MW gene cluster governs the expression of the downstream cone opsin genes  (6, 7). Its absence (e. g. , due to deletions) strongly impairs OPN1LW and OPN1MW gene expression and results in BCM. This offers the opportunity to indirectly map the extent of functionally relevant sequences of the human LCR in BCM patients with SVs. In the present patient series, we identified two deletions that were restricted to the LCR: SVar3 (in family BCM 215) with a deletion of 3,542 bp and SVar2 (in family BCM 74) with a deletion of 411 bp. The latter is the smallest LCR deletion ever reported in BCM. Together with an upstream breakpoint (HS102) reported by Nathans et al. (2) , the present data refine the minimal crucial sequence of the LCR to 358 bp which covers the evolutionarily highest conserved sequence element in this region (SI Appendix, Fig.
This predominance of deletions is at least in part due to intrachromosomal (i. e. , intrachromatidal or interchromatidal) NAHR which is equal or higher than interchromosomal NAHR at all tested loci  (53). Other than in these instances, our data suggest that also nonrecurrent SVs involving deletions are driven by an inherent increased instability of large, high-copy gene arrays at the OPN1LW/OPN1MW gene cluster. Although further studies are recommended for validation, such an increased instability of large arrays may explain the high proportion of SVs in subjects with BCM.
The two qPCR assays targeting OPN1LW and OPN1MW sequences and another RNaseP TaqMan Copy Number Reference Assay-performed as triplicates for each sample-were done in parallel on the same instrument run. For MLPA we used a premarketing release version of the SALSA X080-B1 Opsin probe-mix (MRC Holland) targeting sequences of the LCR, and individual exons of OPN1LW and OPN1MW specifically. MLPA was performed according to the manufacturer's recommendations and amplification products separated by capillary electrophoresis on an ABI 3130XL instrument. Data analysis was done using the Coffalyser. Net software (MRC Holland) which calculates ratios in comparison to reference samples coprocessed with the test samples. For both qPCR and MLPA, we used a series of male controls with defined OPN1LW/OPN1MW copy number (ranging from one to six copies) as determined by Southern blot of NotI-digested and pulsed-field electrophoretic separated genomic DNA and/ or Fiber-FISH  (56) , to generate copy number-dependent probe/control ratio and ΔCt calibration curves, respectively.
In Silico Analysis of SV Breakpoints. We performed in silico sequence analysis of 600 bp in the vicinity of the SV breakpoints (300 bp upstream and 300 bp downstream of the actual breakpoint). We used RepeatMasker for the identification of repetitive sequences and performed a BLAST2seq analysis of the upstream and downstream breakpoint sequences for the detection of sequence homologies. Local G/C content was calculated with a sliding window of 50 bp. Microsatellite Markers. Eleven microsatellite markers (including five markers from public databases and six novel designed CA-and TA-repeat markers) encompassing a 3. 9-Mb region on chromosome Xq28 were used for haplotyping. Microsatellite markers were PCR-amplified from genomic DNA using Ampli-Taq Gold (Thermo Fisher) or Multiplex PCR Master Kit (Qiagen) reagents and-owing to fluorescence labeling of primers-separated and detected on an ABI3130-XL capillary electrophoresis instrument.
Array-CGH Analysis. Array-CGH analysis applying the Affymetrix Cytoscan HD array was done at Atlas Biolabs GmbH, Berlin, Germany. Web Resources. Resources used in this study include BLAST2-Seq (https://blast. ncbi. nlm. nih. gov/Blast. cgi), GenBank (https:// www. ncbi. nlm. nih. gov/genbank/), HGMD (www. hgmd. cf. ac. uk/), OMIM (https://omim. org/), and RepeatMasker (https://www. repeatmasker. org/). Data Availability. All study data are included in the article and/or SI Appendix.
ACKNOWLEDGMENTS. We thank all families for participation in this study and  Miss Sabine Tippmann  and the late  Miss Monika Papke  for technical assistance in the initial phase of this project. We also want to thank the late  Christian Hamel  for the excellent and amicable cooperation before his much-too-early passing. The work was supported by a grant of the  German Research Council  ( Wi1189/12-1  to B. W. ), the  Blue Cone Monochromacy Family Foundation , and  Dr. Renata Sarno  as well as in parts by funds of the  UK Medical Research Council  (to A. J. H. ) and a grant from the  National Institute for Health Research Biomedical Research Centre at Moorfields Eye Hospital NHS Foundation Trust  and  UCL Institute of Ophthalmology  (to M. M. ). Patient clinical care and recruitment in Tuebingen was supported by the  Tistou and Charlotte Kerstan Foundation.