dataesr/scientific-paragraphs-categorization huggingface dataset:
example, the number of levels in the input profile, the number of channels simulated per profile, and the inclusion or not of cloud liquid water. Note that RTTOV-gb is not supported by NWP SAF. All questions, bug reports, or requests for new coefficients should be sent to rttovgb@aquila. infn. it. Always refer to the RTTOV-gb web page for bug fixes, new coefficients, and code updates: http://cetemps. aquila. infn. it/rttovgb/rttovgb. html  (Cimini, 2019). The RTTOV-gb package contains optical depth coefficient files for sensors supported by RTTOV-gb at the time of release. Coefficients for sensors not currently considered can be requested from rttovgb@aquila. infn. it. Note that RTTOV-gb currently only supports microwave sensors. (Rundle, 2019). For more information on reference profiles and regression limits see the related link on the official RTTOV website (https://www.
Acknowledgements. This work has been stimulated through  COST Actions  supported by  COST (European Cooperation in Science and Technology). Support from the  European Space Agency  through the  WRad  project ( ESA  contract no. 4000125141/18/NL/AF ) is acknowledged. Part of this research was funded by the  Korea Meteorological Administration Research and Development Program  under grant  KMI2018-07410. Microwave radiometer and radiosonde data in Lamont (OK, USA) were obtained from the  Atmospheric Radiation Measurement (ARM) User Facility , a  U. S. Department of Energy (DOE) Office of Science user  facility managed by the  Office of Biological and Environmental Research. Review statement. This paper was edited by  Klaus Gierens  and reviewed by two anonymous referees.
D. Cimini et al. : RTTOV-gb v1. 0 through the Atmospheric Radiation Measurement (ARM) program (https://doi. org/10. 5439/1150245). Supplement. The supplement related to this article is available online at: https://doi. org/10. 5194/gmd-12-1833-2019-supplement. Author contributions. DC, JH, and FDA designed the research, contributed to data processing and analysis, and wrote the original paper. PWR, PM, YYS, and MHA contributed to the investigation in Sect. 2. LL, CR, and FSM contributed with the curation of observed data. FDP, DG, SG, FR, ElR, and ErR contributed with software development. AC, EG, SL, SN, and MV contributed to validation data analysis. All coauthors helped to revise the paper.
Other resources include default pressure levels: http://cetemps. aquila. infn. it/mwrnet/ main_files/DAT/RTTOVgb_101_levels_p. dat, last access: 14 November 2018 regression coefficients: http://cetemps. aquila. infn. it/mwrnet/ rttovgb_coefficients. html, last access: 14 November 2018 regression limits: http://cetemps. aquila. infn. it/mwrnet/main_ files/DAT/RTTOVgb_101_pressure_levels_and_regression_ limits. xlsx, last access: 29 April 2019 -NWP SAF profile sets used for the RTTOV-gb training and independent test: https://nwpsaf. eu/deliverables/rtm/profile_ datasets. html, last access: 29 April 2019.
In this paper, we further propose disentangling flows to steer the organization of some of the latent dimensions to match given target distributions. We evaluate the ability of our model to learn these semantic controls by explicitly targeting disentanglement in the latent space of the semantic tags associated to synthesizer presets. We show that, although the model learns to separate the semantic distributions, the corresponding controls are not easily interpretable. Finally, we introduce a real-time implementation of our model in Ableton Live and discuss its potential use in creative applications (All code, supplementary figures, results, and the real-time Max4Live plugin are available as open-source packages on a supporting webpage: https://acids-ircam. github. io/flow_synthesizer/).
Formalizing Synthesizer Control Considering a dataset of audio samples D = {x i } , i ∈ [1, n] where the x i ∈ R d follow an unknown distribution p(x), we can introduce latent factors z ∈ R z to model the joint distribution p(x, z) = p(x | z)p(x) as detailed in Section 2. 1. In our case, some x ∈ D s ⊂ D inside this set have been generated by a given synthesizer. This synthesizer defines a generative function f s (v; p, i) = x where v ∈ R s is a set of parameters that produce x at a given pitch p and intensity i. However, in the general case, we know that if x j ∈ D s , then x j = f s (v) + where models the error made when trying to reproduce an arbitrary audio sample x j with a given synthesizer. Finally, we consider that some audio examples are annotated with a set of categorical semantic tags t i = {0, 1}, which define high-level perceptual properties that separate unknown latent factors z and target factors t.
Synthesizer Sounds Dataset We constructed a dataset of synthesizer sounds and corresponding parameters, by using an off-the-shelf commercial VST synthesizer Diva developed by U-He (https://u-he. com/products/ diva/). It should be noted that our model can hypothetically work for any synthesizer, as long as we can produce couples of (audio, parameters) as input. We selected Diva as (i) almost all its parameters can be MIDI-controlled, (ii) large banks of presets are readily available, and (iii) presets include well-organized semantic tags pairs. The factory presets for Diva and additional presets from the internet were collected, leading to a total of roughly 11k files. We manually established the correspondence between synth and MIDI parameters as well as the parameters values range and their distributions.
We only kept continuous parameters and normalize each of these parameters so that their values lie in the range [0, 1]. All other parameters are set to their fixed default value. Finally, we performed parameter selection by computing the PCA of the parameters value for the whole presets dataset. We sorted the contribution of each parameter to the principal components that explain more than 80% of the variance and performed manual screening to select increasing sets of the most used 16, 32 and 64 parameters. We use RenderMan (https://github. com/fedden/RenderMan) to batch-generate all the audio files by playing a C4 note for 3 s. and recording for 4 s. to capture the release of the note. The files are saved in 22,050 Hz and 16-bit floating point format.
This seems to further confirm our original hypothesis that feed-forward approaches are not able to handle advanced interactions in the parameters. In order to better understand the results and limits of our proposal, we display in Figure  3  the resynthesis of random examples taken from the synthesizer (left) and vocal imitations (right) datasets. As we can see, in all cases, our proposal accurately reproduces the temporal spectral shape of target sounds, even if the timbre is somewhat distant. Upon closer listening, it seems that the models fail to reproduce the local timbre of voices but performs quite well with sounds from other synthesizers. However, the evolution of the spectral shape is still reproduced. Interestingly, this provides a form of vocal sketching control where the user inputs vocal imitations of the sound that he is looking for.
We showed that for sounds that are not produced by synthesizers, our model is able to match the evolution of the spectral shape quite well, even though the local timbre is not well approximated. We further showed that our formulation also naturally introduces various original and first-of-kind tasks of macro-control learning, audio-based preset exploration, and semantic parameters discovery. Hence, our proposal is the first to be able to simultaneously address most synthesizer control issues at once, while providing higher-level understanding and controls. In order to allow for usable and creative exploration of our proposed methods, we implemented a Max4Live interface that is available freely along with the source code of all approaches on the supporting webpage of this paper. Altogether, we hope that this work will provide new means of exploring audio synthesis, sparking the development of new leaps in musical creativity.
Funding: This work was supported by the  MAKIMOno  project funded by the  French ANR and Canadian NSERC (ANR : 17-CE38-0015-01  and  NSERC : STPG 507004-17 ) and also the ACTOR Partnership funded by the  Canadian SSHRC  (SSHRC: 895-2018-1023 ). This work was also supported by an  NVIDIA GPU Grant and GPU Center grant.
RDF-based data integration is often hampered by the lack of methods to translate data locked in heterogeneous silos into RDF representations. In this paper, we tackle the challenge of bridging the gap between the Semantic Web and NoSQL worlds, by fostering the development of SPARQL interfaces to heterogeneous databases. To avoid defining yet another SPARQL translation method for each and every database, we propose a two-phase method. Firstly, a SPARQL query is translated into a pivot abstract query. This phase achieves as much of the translation process as possible regardless of the database. We show how optimizations at this abstract level can save subsequent work at the level of a target database query language. Secondly, the abstract query is translated into the query language of a target database, taking into account the specific database capabilities and constraints.
During the last fifteen years, much work has investigated how to translate common databases and data formats into RDF. Relational databases were primarily targeted  [36, 34] , along with a handful of data formats such as XML  [3]  and CSV  [28]. Meanwhile, the database landscape has significantly diversified with the adoption of various non-relational models. Initially designed as the core system of Big Data Web applications, NoSQL databases have gained momentum and are now increasingly adopted as general-purpose, commonplace databases. Today, companies and institutions store massive amounts of data in NoSQL instances. So far however, these data often remain inaccessible to RDF-based data integration systems, and consequently invisible to the Web of Data. although unleashing their data could potentially spur new integration opportunities and push the Web of Data forward.
The Semantic Web and NoSQL worlds build upon very different paradigms that are challenging to bridge over: whereas the former handles highly connected graphs along with the rich expressiveness of SPARQL, the latter trades off query expressiveness for scalability and fast retrieval of denormalized data 1. As a result of these discrepancies, bridging the gap between those two worlds is a challenging endeavor. Two strategies generally apply when it comes to access non-RDF data as RDF. In the graph materialization strategy, the transformation is applied exhaustively to the database content, the resulting RDF graph is loaded into a triple store and accessed through a SPARQL query engine  [18]  or by dereferencing URIs (as Linked Data). On the one hand, this strategy easily supports further processing or analysis, since the graph is made available at once.
On the other hand, the materialized RDF graph may rapidly become outdated if the pace of database updates is high. Running the transformation process periodically is a common workaround, but in the context of large data sets, the cost (in time, memory and CPU) of materializing and reloading the graph may become out of reach. To work out this issue, the query rewriting strategy aims to access heterogeneous databases as virtual RDF graphs. A query processor rewrites a SPARQL query into the query language of the target database. The target database query is evaluated at run-time such that only relevant data are fetched from the database and translated into RDF triples. This strategy better scales to big data sets and guarantees data freshness, but entails overheads that may penalize performances if complex analysis is needed.
In previous works we defined a generic mapping language, xR2RML  [25] , that enables the translation of a broad scope of data sources into RDF. The mapping instructs how to translate each data item from its original format into RDF triples, by adapting to the multiplicity of query languages and data models. We applied xR2RML to the MongoDB NoSQL document store 2  and we implemented the graph materialization strategy. To cope with large and frequently updated data sets though, we wish to tackle the question of accessing such databases using the query rewriting strategy. Hence, to avoid defining yet another SPARQL translation method for each and every database, in this paper we investigate a general two-phase method. Firstly, given a set of xR2RML mappings, a SPARQL query is rewritten into a pivot abstract query.
This phase achieves as much of the translation process as possible regardless of the database, and enforces early query optimizations. Secondly, the abstract query is translated into the target database query language, taking into account the specific database capabilities and constraints. We demonstrate the effectiveness of our method in the case of MongoDB, accessing arbitrary MongoDB documents with SPARQL. We show that we can always rewrite an abstract query into a union of MongoDB find queries that shall return all the documents required to answer the SPARQL query. The rest of this article is organized as follows. After a review of SPARQL query rewriting approaches in section 2, we quickly remind the principles and main features of the xR2RML mapping language in section 3. Then, in sections 4 and 5 we describe the two-phase method introduced above.
Rewriting SPARQL to SQL and XQuery Since the early 2000's, various works have investigated methods to query legacy data sources with SPARQL. Relational databases (RDB) have caught much attention, either in the context of RDB-backed RDF stores  [10, 35, 14]  or using arbitrary relational schemas  [5, 38, 29, 31, 32]. These methods harness the ability of SQL to support joins, unions, nested queries and various string manipulation functions. Typically, a conjunction of two SPARQL basic graph patterns (BGP) results in the inner join of their respective translations; their union results in a SQL UNION ALL clause; the SPARQL OPTIONAL clause results in a left outer join, and a SPARQL FILTER results in an encapsulating SQL SELECT WHERE clause. Chebotko's algorithm  [10]  focused on RDB-based triple stores.
Priyatna et al. [29]  extended it to support custom R2RML mappings (the W3C recommendation of an RDB-to-RDF mapping language  [12] ) while applying several query optimizations. Two limitations can be emphasized though: (i) R2RML mappings must have constant predicates, i. e. the predicate term of the generated RDF triples cannot be built from database values; (ii) Triple patterns are considered and translated independently of each other, even when they share SPARQL variables. The resulting SQL query embeds unnecessary complexity that is taken care of later on, in the SQL query optimization step. Unbehauen et al. [38]  clear the first limitation by defining the concept of compatibility between the RDF terms of a SPARQL triple pattern and R2RML mappings, which enables managing variable predicates.
Furthermore, to address the second limitation, they pre-checking join constraints implied by shared variables in order to reduce the number of candidate mappings for each triple pattern. Yet again, two limitations can be noticed: (iii) References between R2RML mappings are not considered, hence joins implied by shared variables are dealt with but joins declared in the R2RML mapping graph are ignored. (iv) The rewriting process associates each part of a mapping to a set of columns, called column group, which enables filter, join and data type compatibility checks. This leverages SQL capabilities (CASE, CAST, string concatenation, etc. ), making it hardly applicable out of the scope of SQL-based systems. In the three aforementioned approaches, the optimization is dependent on the target database language, and can hardly be generalized.
In our attempt to rewrite SPARQL queries in the general case, such optimization are performed earlier, regardless of the target database capabilities. In a somewhat different approach, Rodríguez-Muro and Rezk  [32]  extend the ontop Ontology-Based Data Access (OBDA) system to support R2RML mappings. A SPARQL query and an R2RML mapping graph are translated into a Datalog program. This formal representation is used to combine and apply optimization techniques from logic programming and SQL querying. The optimized program is then translated into an executable SQL query. Other approaches investigated the querying of XML databases in a rather similar philosophy. For instance, SPARQL2XQuery  [4]  relies on the ability of XQuery to support joins, nested queries and complex filtering. Typically, a SPARQL FILTER is translated into an encapsulating For-Let-Where XQuery clause.
Finally, it occurs that the rich expressiveness of SQL and XQuery makes it possible to translate a SPARQL 1. 0 query into a single, possibly deeply nested, target query, whose semantics is provably strictly equivalent to that of the SPARQL query. Commonly, query optimization issues are addressed at the level of the produced target query, or they may even be delegated to the target database optimization engine. Hence, the above reviewed methods are tailored to the expressiveness of the target query language, such that SQL or XQuery specificities are woven into the translation method itself, which undermines the ability to use such methods beyond their initial scope.
Rewriting SPARQL to NoSQL To the best of our knowledge, little work has investigated how to perform RDFbased data integration over the NoSQL family of databases. An early work 3 has tackled the translation of CouchDB 4 documents into RDF, but did not addressed SPARQL rewriting. MongoGraph 5 is an extension of the AllegroGraph triple store to query arbitrary MongoDB documents with SPARQL. But very much like the Direct Mapping  [1]  defined in the context of RDBs, both works come up with an ad-hoc ontology (e. g. each JSON field name is turned into a predicate) and hardly supports the reuse of existing ontologies. Tomaszuk proposed to use a MongoDB database as an RDF triple store  [37]. In this context, the author devised a translation of SPARQL queries into MongoDB queries, that is however closely tied to the specific database schema and thus is unfit for arbitrary documents.
More in line with our work, Botoeva et al. proposed a generalization of the OBDA principles  [30]  to MongoDB  [8]. They describe a two-step rewriting process of SPARQL queries into a MongoDB aggregate pipeline. In section 7, we analyze in further details the relationship between their approach and ours. Interestingly, to the best of our knowledge, only one approach tackled the keyvalue store subset of NoSQL databases. Mugnier et al. [26]  define the NO-RL rule language that can express lightweight ontologies to be applied to key-value stores. Leveraging the formal semantics of NO-RL, they propose an algorithm to reformulate a query under a NO-RL ontology, but SPARQL is not considered. Finally, since NoSQL document stores are based on JSON, let us mention the JSON-LD syntax that is meant for the serialization of Linked Data in the JSON format.
When applied to existing JSON documents, a JSON-LD profile can be considered as a lightweight method to interpret JSON data as RDF. Such a profile could be exploited by a SPARQL rewriting engine to enable the querying of document stores with SPARQL. This approach would be limited though, since JSON-LD is not meant to describe rich mappings from JSON to RDF, but simply to interpret JSON as RDF. It lacks the expressiveness and flexibility required to align JSON documents with domain ontologies that may model data in a rather different manner. Besides, we do not want to define a method specifically tailored to MongoDB; our point is to provide a generic rewriting method that can be applied to the concrete case of MongoDB as well as various other databases.
The xR2RML Mapping Language The xR2RML mapping language  [25]  intends to foster the translation of legacy data sources into RDF. It can describe the mapping of an extensible scope of databases to RDF, independently of any query language or data model. It is backward compatible with R2RML and relies on RML  [13]  for the handling of various data formats. It can translate data with mixed embedded formats and generate RDF collections and containers. An xR2RML mapping defines a logical source (property xrr:logicalSource) as the result of executing a query against an input database (xrr:query and rr:tableName). An optional iterator (value of property rml:iterator) can be applied to each query result, and a xrr:uniqueRef property can identify unique fields. Data from the logical source is mapped to RDF terms (literal, IRI, blank node) by term maps.
There exists four types of term maps: a subject map generates the subject of RDF triples, predicate and object maps produce the predicate and object terms, and an optional graph map is used to name a target graph. Listing 1. 1 depicts two mappings <#Mbox> and <#Knows>, each consisting of a subject map, a predicate map and an object map. Term maps extract data from query results by evaluating xR2RML references whose syntax depends on the target database and is an implementation choice: typically, this may be a column name in case of a relational database, an XPath expression in case of an XML database, or a JSONPath When the evaluation of an xR2RML reference produces several RDF terms, the xR2RML processor creates one triple for each term. Alternatively, the rr:termType property of a term map can be used to group the terms in an RDF collection while specifying a language tag or data type.
Besides, the default iteration model can be modified using nested term maps, notably useful to parse nested collections of values and generate appropriate triples. xR2RML allows to model cross-references by means of referencing object maps that use values produced by the subject map of a parent mapping as the objects of triples produced by a child mapping. Properties rr:child and rr:parent specify the join condition between documents of both mappings. Running Example. To illustrate the description of our method, we define a running example that we shall use throughout this paper. Let us consider a MongoDB database with a collection people depicted in Listing 1. 2: each JSON document provides the identifier, email addresses and contacts of a person; contacts are identified by their email addresses.
org/member/ with the value of JSON field id. Applied to the documents in Listing 1. 2, the xR2RML mapping graph generates the following RDF triples: < http :// example. org / member /105632 > foaf : mbox < mailto : john@foo. com > , < mailto : john@example. org >; foaf : knows < http :// example. org / member /327563 >. < http :// example. org / member /327563 > foaf : mbox < mailto : alice@foo. com >; foaf : knows < http :// example. org / member /105632 >. 4 From SPARQL to Abstract Queries Section 2 emphasized that SPARQL rewriting methods for SQL or XQuery rely on prior knowledge about the target query language expressiveness. This makes possible the semantics-preserving translation of a SPARQL query into a single equivalent target query. In the general case however (beyond SQL and XQuery), the target query language may not support joins, unions, sub-queries and/or filtering.
To tackle this challenge, our method first enacts the databaseindependent steps of the rewriting process. To generate the abstract query, we rely on and extend the R2RML-based SPARQL rewriting approaches reviewed in section 2, while taking care of avoiding the limitations highlighted. More specifically, we focus on rewriting a SPARQL 1. 0 graph pattern, whatever the query form (SELECT, ASK, DESCRIBE, etc. ). The translation of a SPARQL graph pattern into an abstract query consists of four steps, sketched in Fig. 1  and described in the next sub-sections. §4. 1: A SPARQL 1. 0 graph pattern is rewritten into an abstract expression exhibiting operators of the abstract query language. §4. 2: We identify candidate xR2RML mappings likely to generate RDF triples that match each triple pattern. §4.