dataesr/scientific-paragraphs-categorization huggingface dataset:
For this audio dataset, we built two RDF repositories, one for Jazz Encyclopedia tracks and one for Illinois tracks, resulting in JE and ILL RDF datasets respectively. While both sources provided different sets of metadata (compare Figs. 11  and 12 ), each with its own inconsistencies, we were able to express the metadata and their relationships in terms of our semantic model in both cases, thus demonstrating the generality of our model. The two RDF datasets were then merged based on name equivalence (see Section 5. 4), resulting in the 100 Years of Jazz RDF dataset.
Merging and reconciliation We performed the merging of two of our repositories: the Jazz Encyclopedia (JE) and the Illinois subset with the Jazz Discography metadata (ILL). This process is a proof of concept for further merges of jazz metadata repositories using our ontology. Because the two datasets did not overlap in time, no disambiguation of event objects (Sessions, Performances) was required. The decision was taken by jazz researchers in the consortium that in the case of Musicians and Bands equivalence by name is a good approximation at this stage (this approach to disambiguation of musicians and bands had been adopted previously within the datasets). Additionally, for Tunes and Instruments, equivalence by title has been assumed. A straightforward implementation enabled a merged dataset out of the box which successfully drives pattern and similarity search interfaces.
DTL1000 dataset The DTL1000 audio dataset is a 1,060-track subset of the 100 Years of Jazz dataset, which is balanced in regard to the number of tracks per decade of jazz history and covers a range of different jazz styles. Like the 100 Years of Jazz dataset, it includes audio tracks connected to the respective discographic and sessionographic metadata. Additionally, all tracks were segmented and their style was annotated. The 1,060 tracks were manually segmented into parts such as 'theme', 'solo', 'intro' and 'fours'. Solo parts were further annotated with the solo instrument. The segmentation was conducted by one expert (OV). Additionally, two experts (MP and KF) annotated the jazz style of the track using an extension of the style classification system used for the Weimar Jazz Database (TRADITIONAL, SWING, BEBOP, COOL, HARDBOP, POSTBOP, FREE, FUSION plus CONTEMPORARY, LATIN and OTHER)  [14, [34] [35] [36] [37].
For efficiency reasons, each annotator annotated only one half of the tracks, while reaching agreement for some occasional borderline cases. Further, melodic lines were automatically extracted for all 1,705 monophonic solos using the novel deep learning approach developed by a Dig That Lick project partner  [18]. These included instruments such as trumpet, trombone, saxophones, clarinet, violin, cornet, flute. Melody extraction and pattern matching for polyphonic solos, such as by piano or guitar, are much harder tasks and were not addressed. For transcribed solos, note patterns reflecting licks were collected, and lick matches documented. We updated our RDF datasets with these manual annotations (Fig. 13 ). Style labels were attached as an attribute to the SoundSignal class. SoloPerformances and their Instruments were added in accordance with our semantic model (see  Section 4.
4). Solo Performers were automatically inferred. Transcriptions and licks were processed in a separate PostGresSQL database which provided a very efficient implementation of pattern matching; therefore, there was no need to represent them in RDF, particularly given that the number of n-grams was three orders of magnitude larger than the number of solos. Instrument could always be assigned to the SoloPerformance object, based on manual annotations supplied with the solo segmentation. Yet, linking the solo to the performer was only possible if just one performer played the annotated instrument in the given performance. For example, if the solo instrument was annotated as trumpet, but there are five trumpeters in the lineup, we cannot infer unambiguously who of them played the given solo. For such cases, we introduced a property possi-ble_solo_performer.
Disambiguating these links requires detailed domain knowledge. Sometimes jazz aficionados can recognise a performer's style; alternatively information on soloists and the order of solos on a track might be available in jazz literature or other sources. The Jazz Encyclopedia's printed booklets provide this information for a subset of the tracks (not in electronic form); similarly, the Jazz Discography database sometimes provides this information. For other tracks, from the past and from less known soloists, this knowledge has been lost. Potentially, automatic methods of soloist recognition could help to close this gap in the future. In particular, information on the performer's lick preferences could be a good indicator of their unique style. In a different type of problem case, the annotated solo instrument was not found in the lineup.
This was either due to errors of manual annotation (e. g. , where instruments are very similar, such as cornet annotated as trumpet) or due to errors in metadata parsing and processing particularly for the Illinois/JD part. Most of these cases have been resolved manually based on the consortium's jazz expertise. The resulting repository is used for the ''Pattern Search'' and ''Similarity Search'' applications 40  created in our project, which allow to specify a lick and to search the DTL1000 dataset for the same or similar licks. Metadata is used as prefilter and also displayed with the search results. Fig. 13  shows the subset of the ontology used for our interface.
Enrichment While most of the metadata in our RDF datasets has been collected from other sources, we have also enriched these data with new information during our project. DTL1000 was enriched with manual annotations, in particular, with segmentation information, solo instruments, and style annotations (see Section 5. 5). Based on manual annotations, solo performers were inferred. For larger datasets, manual annotation is not sustainable. We have introduced two additional ways to enrich data automatically. First, we linked our Musicians to existing Linked Open Data entries for them. We relied on the collection created by the LinkedJazz project 41 (see Section 2) which scraped the most informative parts of the Web in search of entries for jazz musicians, in particular, DBpedia, 42 the Library of Congress authority files 43 and the Virtual International Authority File.
2) played in it (FR2). Relationships between Musicians playedTogether and bandLeaderOf have been precalculated for our public datasets 45  (FR3). Our ontology represents segmentation entities such as Solos and Licks (Fig. 9 , FR4) as well as the workflow for automatically created metadata (Fig. 10, FR5 ), though licks and workflows were not implemented in our datasets. For the competency questions formulated in Section S1 of the Supplement, we list SPARQL queries and their results on our datasets in Section S3 of the Supplement.
Conclusion In this paper, we have presented an ontology that provides a semantic model of jazz, and assessed the ontology in its capacity to facilitate metadata integration in the Dig That Lick project. The main contributions include a semantic data model describing the jazz domain in a way applicable to large, automatically collected and processed datasets. The model is based on detailed domain knowledge, such as band lineup fluidity and importance of band leaders. The integration of discographic and sessionographic information was crucial to relate audio recordings to informative metadata. This experience might be valuable in other musical genres and traditions where digital discographies do not deliver essential information needed by users, such as perhaps world music or ethnomusicological recordings.
Also, with a view to large datasets and automatic metadata creation, we introduced provenance and workflow modelling for documenting these situations, as the basis of reproducibility and explainability, as well as algorithmic optimisation. We created four RDF repositories of different sizes with different aims, populating our ontology and therefore demonstrating its practical applicability. Further, we have demonstrated that repositories based on our ontology can be merged if mechanisms for entity resolution are available. These repositories are being used in online applications for investigating patterns in jazz performances. Moreover, they open many avenues for further systematic studies in jazz history and musician relationships.
New strategies for matching musicians and bands could be developed, e. g. , based on existing Linked Open Data. We envision that a better resolution of musicians and bands would result in particular from more overlapping data, since each new match (e. g. , fingerprint match between signals or date match between sessions) would lead to further matches between related entities in the iterative process. Integrating further datasets would therefore allow for musician and band disambiguation that is less reliant on string matching of the names.
Fabrication We use the commercial DLW platform Photonics Professional (Nanoscribe GmbH, Germany) to write polymer templates of networks. As a seed pattern, we use a stealthy hyperuniform point pattern generated numerically (stealthiness parameter χ = 0. 65). [24, 27] Next, we perform a Delaunay tessellation on the seed pattern. The tessellation divides the design into tetrahedrons, and the tetrahedrons' mass centers are connected with dielectric rods, creating the desired tetravalent network structure in silico. The computer-generated 3D structure, outer dimensions 70 × 70 × 23 µm 3 , is then fed into the DLW-software and reproduced as a polymer cast using an optimized writing algorithm developed in-house. [35] ne critical issue that occurs when developing the structure is non-uniform shrinking.
Scattering Properties of the Polymer Template We assess the bulk properties of the polymer templates by performing small-angle light scattering experiments. To this end, we collect experimental data using an in-house built small-angle light scattering setup, Figure  2a. A helium-neon laser (λ = 632. 8 nm) passes through a diaphragm and is then focused on the sample using a lens (f = 35 mm). The incident beam passes through the glass substrate. We nearly match the refractive index of the dielectric network (n = 1. 52) by applying a drop of decaline (n = 1. 481) on top of the sample. The drop curvature reduces the refraction of scattered light at the droplet/air interface, and in the following, we neglect refraction. We collect scattered light on a thin white plastic screen at a distance of z = 14 cm.
Experimental Section Structural Design: To generate a hyperuniform network with tetrahedral coordination, a stealthy hyperuniform (SHU) seed point pattern, χ = 0. 65, containing N = 10 000 points in a cubic box (with periodic boundary conditions) following a generalization to three dimensions of the algorithm presented in ref. [24] was created. To avoid any finite-size effects in the following processing, the original point pattern was replicated4 in the three directions, creating an extended pattern with 3 3 N points. A Delaunay (tetrahedral) tessellation was performed on the extended seed point pattern using the Delaunay function of the Python Scipy. spatial library. [46] The center of mass of each tetrahedron was linked to the respective centers of the neighboring tetrahedra. All line segments lying outside of the original box were removed.
Hence, any finite size effect associated with the tessellation next to the boundary of the extended pattern was removed. This procedure defined a fourfold connected network of rods with 3/2 N O nodes; in this case, the number of nodes was ≈1. 7 × 10 6. The network was coded for DLW using the NanoScribe proprietary software package called DeScribe  [35]  such that the first peak of the angle-averaged density autocorrelation function was located at a = 1. 75 µm. [22] irect Laser Writing: The commercially available DLW instrument Photonic professional GT+ (Nanoscribe GmbH, Germany) was used. The instrument's light source was a femtosecond pulsed laser with a wavelength of 780 nm. In addition, an acoustic-optical modulator to adjust the laser power was used. This was operated in stage scanning mode and the most petite feature sizes were achieved using Zeiss's 1.
Acknowledgements The authors thank  Michael Engel  for sharing the original 3D code to generate the stealthy hyperuniform point pattern. The  Swiss National Science Foundation  financially supported this work through the  National Center of Competence in Research Bio-Inspired Materials , No. 182881 , and through projects No. 169074 , No. 197146 , and No. 188494. Open access funding provided by  Universite de Fribourg.
[32]  No No No Table  9  presents the main tools found to assist the work simulations. The primary tool used in the papers is the Georgia Tech Internet Topology Model (GT-ITM)  [40] ; it is a network topology generator used to create flat random and hierarchical graphs to represent network substrate and virtual network requisitions. Other works use their framework to create datasets to represent the substrate and requisitions; the advantage of this way is that the frameworks are more problem-oriented. Only one work uses the Mininet software  [41]. This software is adequate for creating a realistic virtual network with the real kernel, switch, and application code on a single machine with a single command. Table  9. Tools to assist the VNE process.
Implementations on ModelDB generally aim to serve as static reference for a published article (although some entries link to version-controlled repositories) and no restrictions on programming languages or simulators are made. In contrast, all models indexed by OSB 2  are stored in public version-controlled repositories such as GitHub 3  to foster ongoing and collaborative model development. Models in OSB are standardized in the sense that they are made available in the model description languages NeuroML  [43, 44]  or PyNN  [45] , besides potentially further versions. As this study focuses on network connectivity, we review network models of point neurons, simple multicompartment neurons (without considering connectivity specific to compartments), and neural mass models, but exclude neural field models as well as more detailed models.
g. , weights and delays). Turning from the connectivity description in articles to the model implementations, we find that a wide variety of software is used for implementing the connectivity (Fig  4A ). This software is either a general-purpose programming language such as MATLAB, Python, or C/C++, or a dedicated simulator for neuronal networks In the following, we characterize the model networks according to their node and edge properties since these affect the interpretation of connectivity. If the connectivity is defined between single neurons, a connection may represent a single synapse or several individual synapses. However, if the connectivity is defined between nodes that represent populations of neurons, a connection is rather understood as an average over multiple synapses, i. e.
Description languages and simulators A neuronal network simulator typically provides an idiosyncratic model description language or supports a pre-existing one, for example a cross-simulator description language like PyNN  [45] , NeuroML  [43] , NineML  [56] , CSA  [57] , or SONATA  [58]. A less common case is where the simulator consists of a library with an API called by a general-purpose language such as is the case for SPLIT  [59]  and, to some extent, GeNN  [60]. We here consider model description languages either tied to a particular simulator or supported by multiple simulators. The ways in which network connectivity is described in such languages broadly fall into three main categories: procedural descriptions, declarative descriptions at a population-to-population level, and more general declarative descriptions using algebra.
Usually the user is limited to a set of pre-defined rules, although some simulation software allows users to add new rules. Declarative population-level descriptions are for instance supported by the simulators NEST, Moose, and the description languages PyNN (connectors) and NineML. Commonly provided connectivity rules are: one-to-one, all-to-all, and variants of probabilistic rules. The "transforms" in Nengo can also be regarded as declarative descriptions of connectivity. NeuroML supports lists of individual connections. Its associated language NetworkML  [43]  provides declarative descriptions akin to those of PyNN and NineML, while its associated lower-level declarative language LEMS  [44]  supports the definition of types of connectivity based on partially procedural constructs ("structure element types") such as ForEach and If, giving greater flexibility but departing to some extent from the spirit of declarative description.
The information here pertains to NEST version 3. 0. In addition to the built-in connectivity rules, NEST provides an interface to external libraries, for example CSA, to specify connectivity. PyNN is a simulator-independent language. It provides a class of high-level connectivity primitives called Connector. The connector class represents the connectivity rule to use when setting up a Projection between two populations. The information here pertains to PyNN version 0. 9. 6. NetPyNE is a Python package to facilitate the development, simulation, parallelization, analysis, and optimization of biological neuronal networks using the NEURON simulator. It provides connectivity rules for explicitly defined populations as well as subsets of neurons matching certain criteria. A connectivity rule is specified using a connParams dictionary containing both parameters defining the set of presynaptic and postsynaptic cells and parameters determining the connectivity pattern.
The information here pertains to NetPyNE version 1. 0. NineML is an XML-based cross-simulator model specification language. Brian is a simulator which has a unique way of setting up connectivity. Connections between a source and target group of neurons are specified using an expression that combines procedural and algebraic aspects, passed to the connect method of the synapse object S: § ¤ S. c o n n e c t ( j=' E X P R f o r V A R i n R A N G E i f C O N D ' ) ¦ ¥ Here, EXPR is an integer-valued expression specifying the targets for a given neuron i. This expression may contain the variable VAR which obtains values from RANGE. For example, to specify connections to neighboring neurons, we can say § ¤ S. c o n n e c t ( j=' i + ( -1 ) * * k f o r k i n r a n g e ( 2 ) ' , s k i p _ i f _ i n v a l i d=T r u e ) ¦ ¥ where skip if invalid tells Brian to ignore invalid values for j such as -1.
The simulators NEURON and Arbor do not support high-level connectivity rules and are therefore not included here. Perhaps the most fundamental population-level connectivity rule found in model description languages is connecting each source to all targets. This rule is called all to all in NEST and all-to-all in NineML. PyNN provides the AllToAllConnector while NetPyNE provides the fullConn connectivity function. NEST and PyNN support the choice whether to include autapses. The rule connecting each source to one corresponding target (according to some ordering) is called one to one in NEST and one-to-one in NineML. PyNN provides the OneToOneConnector. NetPyNE does not support this form of connectivity. Both NEST and PyNN support the choice whether to include autapses. If source and target population coincide, excluding autapses does not necessarily prevent all connectivity, because the targets can be specified as a permutation of the sources.
SBGN has an online portal  8  , an exchange and data format (SBGN-ML), a software library, and various further tools and databases. Building on current practice in the computational neuroscience community, we propose a graphical notation framework for network models in computational neuroscience by defining which network elements to encode and how. We restrict ourselves to the simplest, most commonly used elements and provide a path to flexibly extend and customize the diagrams depending on the model specifics to expose. The notation uses simple standardized graphical components and therefore does not depend on a specific tool. In the notation, a network is depicted as a graph composed of nodes and edges and enhanced with annotations. The nodes correspond to neuronal units or devices, the edges to connections, and the annotations specify the connections in terms of connection rules, possible constraints, and parameterization.
This is the case even though a large part of the identified connectivity concepts corresponds to rather basic rules. The devil is in the detail: deviations from standard rules, further constraints, or just the lack of rigorous definitions lead to ambiguities. Details sometimes omitted include whether self-connections (autapses) or multiple connections from a given source to a given target (multapses) are allowed. In our review we further survey the use of high-level connection concepts in model descriptions and implementations and observe that they provide multiple advantages. High-level concepts allow for more concise and informative network specifications than explicit specification of atomic connectivity, in the form of either tables (databases) or algorithms expressed in elementary operations.
Furthermore, for most high-level concepts presently used by modelers, simulation software provides dedicated code to efficiently instantiate connections in parallel or generate informative visualizations  [53]. A significant obstacle to the systematic use of high-level concepts at present is the lack of a standardized terminology in the field: The same term may describe slightly different connectivity concepts with different authors or simulation codes, especially with respect to underlying assumptions about constraints, such as the presence of autapses. In contrast to other approaches, we do not propose a new formal language (e. g. , NeuroML, NineML) or a software implementation (e. g. , PyNN). Instead, we gather terminology already in use in the community, expose interrelationships, and provide precise definitions.
Examples include the simulation package NetPyNE  [98] , the model description languages NeuroML  [43]  and NineML  [56] , the SONATA data format for describing large-scale network models  [58] , and the Open Source Brain repository for network models also used here  [42]. To foster the adoption, interoperability, and standardization of description languages and pertaining tools, the INCF Working Group on Standardized Representations of Network Structures 10 was established in 2018. While earlier work focused on the formal description of single neurons, network structure gained increasing importance. This was partly driven by the increasing complexity of network models but also by the need to reproduce network models of others. The latter is highlighted by the research on neuromorphic computing systems.
Verification of these systems requires that the same network model can be instantiated on a conventional computer and on the new system under investigation. Groundbreaking work was carried out by the European FACETS project (2005-2010) in conceiving the meta-simulator language PyNN as a common front end for software and hardware simulation engines  [45]. In this way, once a network has been formulated in PyNN, it can be instantiated in a software simulation engine such as NEST or a neuromorphic hardware system such as SpiNNaker  [99]. The availability of high-level connectivity concepts such as "all-to-all" in PyNN must guarantee that all back-end engines interpret this in the same way. Expanding the connectivity concept into elementary pairwise connect requests already on the level of the PyNN interpreter is not an option as this would deprive a simulation engine of any chance of efficient parallelization.