dataesr/scientific-paragraphs-categorization huggingface dataset:
One of the original goals of the WASABI project was to build a dataset comprising metadata produced by natural language processing applied to the lyrics. As shown in Figure  1 , we therefore started from LyricsWikia, a wiki-based, crowdsourced website gathering a large number of commercial song lyrics, metadata concerning the discography of thousands of artists (name, genre, labels, locations, duration, album release dates etc. ). We collected data of 2M songs, 77K artists and 200K albums, including links and ids to songs, artists and albums on other platforms: Wikipedia, YouTube, MusicBrainz, Last. fm, Discogs, etc. Subsequently, we used the links and ids to gather metadata from these multiple platforms. For instance, from several DBpedia language editions we retrieved music genres, awards and albums durations; from MusicBrainz: artist type (group, person, etc.
), gender, life span, group members, albums' bar code, Merging was necessary when different properties of the same meaning coming from different data sources provided different, possibly complementary results (e. g. using owl:sameAs from DBpedia). The disambiguation properties of Discogs and the availability of multiple URIs from different data sources for the same song/artist/album also made it possible to detect gross errors. Conflict detectors were set up (e. g. for dates) and manual arbitration occasionally took place. We organized "WASABI Marathons" along the project lifetime where participants used the Wasabi Explorer  [6]  to identify errors. These marathons helped set up scripts to detect and fix errors ranging from spelling errors/variations (e. g. "Omega Man" by The Police is sometimes spelled "Ω Man"), to rules (e.
7 Concerning the explicitness of the lyrics content, we provide both the predicted labels in the WASABI Song Corpus (715k lyrics, 52k tagged as explicit) and the trained classifier to apply it to unseen text. As for emotion, the dataset integrates Deezer's valence-arousal annotations for 18,000 English tracks 8   [8] , as well as the valence-arousal predictions for the 1. 73M tracks with lyrics. We also make available the Last. fm social tags (276k) and emotion tags (87k) to allow researchers to build variants of emotion recognition models. Finally, we provide the topic distribution of our LDA topic model for each song and the trained topic model for future research.
Extracting chords through automatic audio content analysis We enriched the dataset with automatic chord recognition  [23]  for reasons of consistency, formatting and coverage. Even though automatic transcriptions are not flawless, at least they are consistent and well-structured. Chord extraction can also be applied to each song for which audio is available, and therefore avoids the popularity bias that would follow from scraping crowd-sourced resources. In order to mitigate algorithmic imperfections, we used a chord recognition algorithm that additionally returns a song-wide measure of confidence in the quality of transcription  [22]. Weighing by this measure makes dataset aggregations more reliable, although it obviously is of limited use when an individual song of interest has a particularly low confidence associated with it.
A chord vocabulary consisting of sixty chords was imposed: all combinations of twelve possible root notes with five chord types (major, minor, dominant 7th, major 7th, minor 7th). The Deezer song identifiers provided a link to audio recordings. The actual analysis required access to the raw, unprotected audio and was therefore run by Deezer on their servers. 1. 2 million songs in the WASABI dataset have an associated Deezer identifier, so can potentially be enriched with a chord transcription. This process is still ongoing, currently 513K songs have been processed. The chord symbols (without timing due to copyright restrictions) and their confidence measures can be obtained along with the rest of the dataset through the REST API and SPARQL endpoint. Other musical properties based on automatic content analysis can be integrated as future work.
IRCAM tools for on-demand audio/MIR analysis Timeside is an an open, scalable, audio processing framework in Python, enabling low and high level audio analysis, visualization, transcoding, streaming and labelling. Its API supports reproducible and extensible processing on large datasets of any audio or video format. For WASABI, some parts have been created or extended: a secured and documented API with JWT access capabilities, a Provider module to handle automatic extraction of YouTube's and Deezer's tracks or 30 seconds extracts, an SDK for the development of client applications and a new web front-end prototype. A hosted instance has been connected to the main WASABI API so that every available tracks can be dynamically processed and played back through the multi-track analyzer web player.
Formalizing, generating and publishing the RDF Knowledge Graph The WASABI dataset essentially consists of two parts: the initial dataset produced over the last 3 years by integrating and processing multiple data sources, as explained in section 3, and the RDF dataset derived thereof, namely the WASABI RDF Knowledge Graph that we describe hereafter. The latter provides an RDF representation of songs, artists and albums, together with the information automatically extracted from lyrics and audio content.
Representing songs, artists and albums in RDF Beyond the terms of WASABI ontology, the resource descriptions use terms from multiple vocabularies. The namespaces and prefixes are given in Listing 1. 1 and the diagram in Figure  2  is the representation of a song from the WASABI database. This song is linked to its album through the schema:album property, and both the album and song are linked to the artist using the mo:performer Music Ontology property. Only a small subset of songs' metadata is depicted here: title (dcterms:title), audio gain (wsb:gain), chords (chord:chord )  13  given @prefix af : < http :// purl. org / ontology / af / >. @prefix chord : < http :// purl. org / ontology / chord / >. @prefix dcterms : < http :// purl. org / dc / terms / >. @prefix foaf : < http :// xmlns. com / foaf /0.
The RDF Knowledge Graph Generation Pipeline The dataset described in section 3 consists of a MongoDB database comprising three main collections: songs, artists and albums. The song collection provides not only the metadata, but also a representation of the chords extracted by the audio analysis, and the information extracted from the lyrics. In a first stage, each JSON document of MongoDB was pre-processed so as to facilitate its translation to RDF, then translated to an RDF representation as described in section 4. 2. The translation was carried out by Morph-xR2RML,  14  an implementation of the xR2RML mapping language  [19]  for MongoDB databases. All files involved in this pipeline are provided under the Apache License 2. 0.
Publishing and Querying the WASABI RDF Knowledge Graph Table  4  synthesizes the amount of data processed to produce the WASABI RDF Knowledge Graph, and reports the number of triples produced. Table  5  reports some statistics about the instances. Dataset Description and Accessibility. In line with data publication best practices  [9] , the WASABI RDF Knowledge Graph comes with rich metadata regarding licensing, authorship and provenance information, linksets, vocabularies and access information. These can be visauliazed by looking up the dataset URI  15. The dataset is available as a DOI-identified downloadable RDF dump and a public SPARQL endpoint (see Table  6 ). All URIs can be dereferenced with content negotiation. Further information (modeling, named graphs, third-party vocabularies) are documented in the GitHub repository.
Dataset Licensing. Like the rest of the WASABI dataset, the WASABI RDF Knowledge Graph is published under the Creative Commons Attribution-NonCommercial-ShareAlike 4. 0 International License. Copyrighted data such as the full text content of the song lyrics and audio are not included but URLs of original source material are given. Sustainability Plan. We plan several research lines that will exploit and extend the dataset and improve its resilience. We intend to add more audiorelated computed metadata from our collaborators at IRCAM and QMUL e. g. links from the song ids to the TimeSide API will ensure that the audio based analyses can be provided or re-triggered even if new songs are added or of the audio data change or vary from the external providers. We also deployed a SPARQL endpoint that benefits from a high-availability infrastructure and 24/7 support.
Visualization and Current Usage of the Dataset The size and the complexity of the dataset require appropriate tools to allow users to explore and navigate through it. This multidimensional dataset contains a large variety of multimedia attributes (lyrics, sounds, chords, musical instruments, etc. ) that are interlinked, thus featuring a large and rich knowledge graph. To assist users, we investigate various visualization techniques. Our goal is to help users explore the dataset by providing answers to common visualization questions such as to get an overview of itemsets fitting some userdefined criteria, exploring details of particular itemsets, identify relationships (such as patterns, trends, and clusters) between itemsets, etc. These common tasks are defined in the information-seeking mantra introduced by Schneidermann  [25]  which guides the design of all visualization tools.
We designed and implemented a large set of visualization techniques using the D3. js library and made these techniques available to the user in a gallery. Figure  3  illustrates some of the visualization techniques currently available and all are interactive so that user can select an itemset and apply zoom and filtering to explore the dataset. The creation process for the gallery of information visualization techniques is rather opportunistic and incremental. It allows us to explore different alternatives for showing information to the users but also to combine different attributes. The visualization is driven by the type and inner structure of the data that results from the queries embedded into the visualization tools. Whilst visualization tools created this way are not generic, they remove part of the inner complexity of creating (SPARQL) queries, making the tools easier to use and particularly suitable to communicating results to a broad audience.
It is worthy of notice that some of the visualization techniques includes multimedia content, for example the Figure  4  includes images that refer to cover of albums of an artist. So far, beyond the interactive graphics, only text and images are used in multimedia visualization, we are working to enrich the information visualization gallery with techniques that include audio contents. 6 Evaluating the quality of the dataset, future updates Assessing and ensuring the quality of a large dataset built by aggregating multiple data sources is challenging and continuous process. It is common that metadata coming from various sources be erroneous or conflicting. The multiple hackathons helped in spotting many errors, conflicts and recurring problems, and we wrote a set of scripts (available in the Github repository) to fix some of them.
The dataset is meant to be maintained over at least the next three years as we have new ongoing projects that will exploit and extend it. More metadata will be added (in particular from MIR audio analysis of songs, linking songs to existing midi transcriptions or online scores), and we are developing new metadata quality assessment tools (based on visualisations and inferences rules) that shall allow the community to better detect and report erroneous, conflicting or missing metadata. On the other hand, the quality of extracted metadata about lyrics have been validated using different methods described in the papers cited in section 3. 2.
Potential Impact and Reusability To the best of our knowledge, the WASABI dataset is the first one integrating cultural and MIR data at this scale into a single, coherent knowledge graph that makes it possible to initiate new research. The wide range of metadata resulting from the analysis of song lyrics is one of the remarkable points. Many recommendation systems are based on cultural information and user profiles, sometimes taking into account data from the audio analysis, but few rely on the content of the lyrics or their analysis. Furthermore, mixing the emotions extracted from the textual analysis with results on the analysis of emotions extracted from the audio from other datasets (e. g. AcousticBrainz) provides new prospects for recommendation systems  [20]. In addition to being interoperable with central knowledge graphs used within the Semantic Web community, the visualizations show the potential of these technologies in other fields.
The availability of this rich resource can also attract researchers from the NLP community. 16 nterest of communities in using the Dataset and Services. The openness of the data and code allow contributors to advance the current state of knowledge on the popular music domain. We initiated collaborations with other groups and, in particular, researchers from the FAST project already used and contributed to the dataset. IRCAM researchers also started cross-domain analyses on songs (i. e structure and emotion detection using both audio and text  [18] ). Collaboration with IRCAM will continue as the integration of additional audio data is a priority for us in the coming months and will trigger updates. Application scenarios, targeted users, and typical queries. Following a user-oriented requirement analysis, we designed a set of motivating scenarios: Scenario 1: research of artists and songs related to current events, set with the help of archivists from Radio-France.
Scenario 4: search for songs of a particular style, in a given key, or containing specific chords, with lyrics with given topics, set with the help of music schools and professional composers. E. g. : look for a blues in E with a tempo of 120 bpm, then get similar songs but with chords outside the key; show artists who wrote a type of songs, sorted by popularity; search for songs with given themes and emotions in the lyrics or with certain types of orchestrations (e. g. guitar and clarinet). Like in scenario 1, these queries involve searches through the dataset, yet they are meant for very different users with different needs that require specific user interfaces: journalists vs. music schools and composers. Whilst some questions might be answered by showing the correlation between components (e.
Conclusion and Future Work In this paper, we described the data and software resources provided by the WASABI project to make it easier for researchers to access, query and make sense of a large corpus of commercial music information. Applications meant for different types of users (composers, music schools, archivists, streaming services) can be built upon this corpus, such as the WASABI explorer that includes a chord search engine and an augmented audio player  [6]. We generated and published an RDF knowledge graph providing a rich set of metadata about popular commercial songs from the last six decades. These metadata cover cultural aspects of songs/albums/artists, lyrics content as well as audio features extracted using Music Information Retrieval techniques. The RDF representation currently uses some free text values coming from the original sources.
To be more in line with Linked Data practices, in the future we intend to improve this by reusing, extending or defining thesauruses with respect to musical genres, music instrument types (currently 220 distinct values among which 16 different types of guitar) and equipment types (e. g. microphone, amplifier). We also published the pipeline we set up to generate this knowledge graph, in order to (1) continue enriching it and (2) spur and facilitate reuse and adaptation of both the dataset and the pipeline. It is important to note that during the project we had access to copyrighted content (song lyrics, audio files) that we are not allowed to include in the published dataset. Nevertheless, a lot of work has been done on the analysis of song lyrics and the results are available on the GitHub of the project (metadata, ML templates, Python scripts and Jupyter notebooks).
It is still possible for researchers to get the lyrics (e. g. via the commercial MusixMatch API 17 ) or the audio (via Deezer's public API which offers 30-second clips, or via the YouTube API for example) to reproduce our results. Some computed metadata related to the synchronized chord sequences (used by the augmented audio player in the WASABI online explorer) were published only partially to avoid copyright infringement (as they are too close to music scores). Nevertheless, in collaboration with Deezer and IRCAM, we plan to carry out further audio analyses, mainly for scenarios of interest to music schools, musicologists, archivists and broadcast services. Results from the lyric processing are provided in the original dataset in different forms (json, csv, etc. ). At the time of writing, only the explicitness metadata are included in the RDF knowledge graph, and we are working on a future update that will include other metadata.
This result could be an explanation of the lack of nanodomains formation in the laboratory BY4741 strain, which derives from S288c (see Figure  S1 ) since FLO11 is not expressed in this strain due to a nonsense mutation in FLO8 that encodes a major transcriptional activator of this gene  (Liu et al. , 1996 , Kobayashi et al. , 1999). To verify this explanation, we retrieved FLO11 gene sequence of S288c as well as that of FLO11 from L69 strain whose genome was recently sequenced (Lallemand Inc unpublished data). Interestingly, we found that the FLO11 gene (provisional GenBank accession number BankIt2416107 Seq1MW448340) of this industrial strain was 1. 06kbp longer than that of BY4741 (ie 5. 16 vs 4. 10 kbp). Both genes were cloned into the high copy pYES2. 1 plasmid under the control of GAL1 promoter.
Comparative sequence analysis of Flo11p from various yeast strains and construction of Flo11p variants from L69 strain Using Clustal Omega, we aligned the amino acids sequence of Flo11p from L69 strain (provisional GenBank accession number BankIt2416107 Seq1MW448340) with that of different Saccharomyces cerevisiae strain, including the originally genome-sequenced strain S288c (Goffeau, 1998), 1278b  (Dowell et al. , 2010) , a strain widely studied for its remarkable properties of colony morphology, invasive and pseudohyphal growth  (Reynolds & Fink, 2001 , Dowell et al. , 2010 , Voordeckers et al. , 2015)  and the flor yeast strain 133d reported to form buoyancy biofilms also termed velum  (Fidalgo et al. , 2006). We found that Flo11p L69 is 355 and 512 amino acids longer than Flo11p BY and Flo11p  , respectively, but only 92 amino acids longer than Flo11p from strain 133d (see Figure  S3  in supplementary data).
However, there are major differences between the Flo11p of L69 strain and that from the other yeast strains. In particular, Flo11p 69 contains more repeats (TRs) than the proteins from BY4741 and 1278b (Figure  4 ), but slightly less (46 vs 49) than Flo11p from the Flor strain 133d. Interestingly, a search for the intragenic repeats in FLO11 using EMBOSS TANDEM software (https://www. bioinformatics. nl/cgi-bin/emboss/etandem) indicated that FLO11 from strain 133d harbored a same repeat of 81 nt that is repeated 49 times, whereas 4 different intragenic repeats with different nucleotide size were identified in the other FLO11 genes (see details on intragenic repeats in Table  S2  in supplementary data). A second difference was in the presence in Flo11p L69 of two additional amyloid core sequences "VVSTTV", which possess 75.
It confers the ability to S. cerevisiae to use acetamide as the sole nitrogen source  (Solis-Escalante et al. , 2013)  enabling selection of prototroph strains. As the CRISPR/Cas9 technique requires the identification of a unique 20N (NGG) sequence, the candidate target sequence was identified using the online software CRISPR-direct (https://crispr. dbcls. jp ), and determined as to be located in the middle of each region of FLO11 to be deleted. Linear healing fragments of 120 bp were designed with 60 bp overlapping the upstream and downstream sequences of the region to be deleted, namely the N-terminal (from 4 bp to 675 bp), the C-terminal (from 3889bp to 5163 bp), the RR1 domain (from 735bp to 2573bp) and the RR2 domain (from 3575bp to 4375bp). Ligation of gRNA sequence into the plasmid was made using a T4 DNA ligase at 16°C overnight and transformed into DH5 chemically competent bacteria according to the manufacturer protocol (NEB).
Bioinformatics The gene FLO11 was retrieved from the L69 strain genome which has been fully sequenced internally (Lallemand, Inc, unpublished data) using the Pacific Biosciences method, whereas the sequences of FLO11 in the laboratory strain BY4741 and 1278b were uploaded from the SGD database (https://www. yeastgenome. org). Clustal Omega was used to perform amino acid sequence alignments  (Sievers & Higgins, 2014). Structural and functional comparison between the sequences of Flo11p L69 , Flo11p BY4741 and Flo11p 1278b were carried out using Hydrophobic Cluster Analysis (HCA)  (Lemesle-Varloot et al. , 1990)  giving a plot of each open reading frame that draws as a helical projection, vertically repeated. Secretion signal and the GPI signal anchorage to cell wall -glucan were searched using SignalP-4.
1 server (http://www. cbs. dtu. dk/services/SignalP-4. 1/)  (Nielsen, 2017) , PredGPI tool (http://gpcr. biocomp. unibo. it/predgpi/) (Pierleoni et al. , 2008). TANGO software (http://tango. crg. es/) (Fernandez-Escamilla et al. , 2004)  with default settings for pH, ionic strength, and temperature was used to determine Flo11p regions with β-aggregation potential superior to 30%. Intragenic repeats in the FLO11 ORF were screened using the EMBOSS ETANDEM software (http://emboss. bioinformatics. nl/cgibin/emboss/etandem) (Rice et al. , 2000). Criteria were selected those with a repetition length >10, a score >20, and a repetition conservation >60%.
All results were analysed with the JPK Data Processing software. The adhesion values measured on cells were determined from the retract forcedistance curves. The stiffness values (kcell) were determined as the slope of the linear portion of the force versus indentation curves according to: 𝑘 𝑐𝑒𝑙𝑙 = 𝑘( 𝑠 1 -𝑠 ) The effective spring constant of the cell k cell is calculated from the experimental slope s of the force curve and the spring constant k of the cantilever measured by the thermal noise method. All stiffness and adhesion values were considered for the histograms, which were generated using OriginPro version 2020 (OriginLab, Northampton, USA). A synthetic peptide based on the amyloid sequence VVSTTV bearing a replacement of V by A (VASTTV) was purchased from Gencust and used as anti-amyloid peptide against Flo11p amyloid sequence.
Statistical analysis All phenotypic assays were carried out at least 3 times with independent biological samples. Statistical analysis were made by one-way analysis of variance followed by Tukey's test on Microsoft Excel software. Statistical significant values were denoted by asterisks on the figures as *= p-value < 0. 05, * * =p-value < 0. 01 and * * * = p-value < 0. 001. strains were pre-grown in YNGal that was supplemented with the auxotrophic requirements when needed (ie uracil, leucine, histidine, methionine at 0. 1% for BY4741, BYflo11 and YSTW3 but only leucine, histidine, methionine for BYflo11 and flo11 expressing FLO11 BY , FLO11 L69 or FLO11 BY -[RR2] L69 ) until stationary phase.