dataesr/scientific-paragraphs-categorization huggingface dataset:
This example is detailed in the running example (see Section 2. 2. 2). As every database in the repositories of environmental data has been represented with one point of view, we claim that this can prevent data consumers from being aware that some data may be interesting even if they seem to address non-connected topics. The existence of "non-explicitly defined" points of view can thus make it difficult to use and cross data. Yet, crossing such data may be of crucial interest, for instance to better understand the effects of global changes.
Case Study Our work is applied in the framework of the O-LiFE (Observatoire Libano-Francais de l'Environnement: http://www. o-life. org) observatory. O-LiFE was created in 2011 as a shared environmental observatory between France and Lebanon to serve as a medium for scientific collaboration, resources and facilities' sharing, as well as for knowledge and expertise exchange. Our work is applied on real datasets in the framework of the O-LiFE observatory aiming at studying the critical zone around the Mediterranean Sea and addressing major environmental subjects such as water resources, biodiversity, natural hazards, environment management and, ultimately, land uses. There is indeed a growing need to cross several types of data for simultaneous analysis. An example is dust monitoring, where real-time wind direction and dust concentration need to be compared in order to trigger meaningful alerts to an operator.
Another very active example now in Lebanon is the effect of waste incineration on air quality. Based on concrete environmental data and information, the platform allows for effective management of current issues while predicting future trends, scenarios and challenges. Structuring, sharing, processing and integrating environmental data comprise the main mission of O-LiFE. Our work is applied on real datasets in the framework of the O-LiFE observatory. In this article, we thus introduce two databases that are exploited to show the results of our method: (i) the snow data database collected from three permanent stations located on the heights of Mount Lebanon and the (ii) wells' data collecting information on groundwater wells in the Bekaa region in Lebanon.
In this article, we focus on the first four steps that are described in the next sections, as they are focused on data preparation to be used in order to exploit the databases by crossing data. This work has been implemented in the context of the information system of the O-LiFE environmental observatory. As we work on environmental data, we rely on standard models that are presented in this article before introducing our contributions. The article is organized as follows. We first present the methodology we propose and the data we have used, before reporting the results.
Methodology Our methodology consists of the following components: This article focuses on the first four steps for preparing the data to be crossed. In this respect, our work does not focus on data volumes that should be managed by such architectures, but rather on data preparation, which only requires local computations for data transformation. This work prepares the next step (machine learning, data mining) for data crossing, which requires distributed databases and high performance computing. • The whole process is described by Figure  2.
Reconciling Data Schemes with Standards In our model, we consider a repository of environmental data collected from a set of n data sources. This set is denoted by S, with S = {S 1 ,. , S n }, and every s i is a specific data source. For instance, we consider the three data sources s 1 "Bird", s 2 "Snow" and s 3 "Wells". These databases must be represented using standards. The transformation first requires that the data can be understood by non-producers, and thus "translated", which refers to the semantic field, or in each case, surrounded by a shared ontology and thus co-constructed between producers and data users. The success of data usually lies in their ability to be exploited in support of well-identified scientific questions, or on the contrary, in their versatility, which can be used for unexpected questions.
However, the same data can be linked in the following way: number of individuals ↔ place ↔ observation date. In this case, it may be possible to characterize the migration of individuals or the population from site to site, for example under the effect of global warming. What has changed, of course, is the point of view, which has led to the creation of new links with the same data. This change of view could be induced by a new scientific question "Is there a climatic migration of species" or simply by linking data with new links "to see". Data mapping is used to translate environmental data into alternative representations without compromising the mission of primary data. Thus, in our example, each point of view generates all the links and therefore the database adapted to its study, provided that the mapping of the data can be done correctly.
This mapping is therefore a key to the process. The data must be transformed into the O&M model of SOS to insert the data into the SOS web service, or in other words make the "mapping", which is a procedure consisting of identifying these elements in the source database and matching with the O&M model of SOS. Moreover, the environmental observatories' IT infrastructure has been studied for many years. It comes from previous work allowing, on the one hand, one to manage the spatio-temporal data (GIS), the sensors data arriving in flow and the heterogeneity. The work in  [9]  defines observatories as answering a scientific question from which follows an observation model corresponding to data to be collected and followed by relying on a technical, scientific and institutional device and a set of actors.
It can be added that, observatories being intended to value the data essentially beyond its producer, they must also be the place of definition of points of view and therefore the place of realization of links between distributed data. In environmental observatories, spatial data are managed in the so-called Spatial Data Infrastructures (SDI) that provide the basic physical and organizational structures required to facilitate and coordinate the efficient and effective discovery and use of spatial data. The main implementations of SDI rely on the OGC, which provides consensus standards with the help of various contributors (companies, government agencies and universities). OGC standards are used in most environmental observatories, thus enabling the exchanges and uses of data from such observatories.
The OGC Sensor Web Enablement (SWE) framework consists of a set of standards defining data formats for sensor data and its metadata, as well as service interfaces to access sensor data, task sensors or send and receive alerts based on sensor measurements  [10]. These standards, for example, SensorMLand O&M, provide syntactic interoperability that enables the integration of sensors and sensor data into Spatial Data Infrastructures (SDI) and thus makes it possible to use the data measured by sensors in a broad range of applications. The Sensor Observation Service (SOS) is one of the OGC-SWE standards that defines a web service interface for providing access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems including remote, in situ, fixed and mobile sensors.
For the observation in the 52 • North database model shown in Figure  3 , every piece of data is described using the same features, some of them being mandatory. For instance, spatial information, feature of interest (e. g. , weather, birds' diet), procedure (sensors being used) and phenomena (e. g. , air temperature) are some of the requested information. Figure  1  presents a simple view of SOS data modeling, taken from Figure  3. Roughly speaking, in SOS, objects named features of interest, the location of which is known (should it be stationary like a building or mobile like a car or an animal), are studied over time by means of some phenomena (also known as observed properties) expressed by values given with particular units of measurement.
For instance, the SKOSmodel allows one to have a preferred label (skos:prefLabel), alternative label (skos:altLabel) and hidden label. As can be seen from this literature review, many works have addressed the question of mixing Semantic Web and SOS-based observatories. However, these works are limited to SOS-compliant data and do not help to model data from our running example that may be considered as not easily SOS-mappable. For this reason, we have introduced a new method in previous works  [8]  helping SOS users to model the different mappings of their data to SOS models by extending existing properties. As presented above, sensors data are represented in an SOS database with the following entities: FoI, date, location, phenomena (or observed properties), sensors, measured values and units of measurements.
Whenever data are received in centralized databases, the data must be transformed into this model. These data are however raw data, often stored within Excel sheets or text files, which may combine several observations and information of a different nature at different levels of granularity, etc. It is then often possible to define several points of view, and thus several sets of possible links, in particular to specify which objects of the data source can be defined as features of interest. The co-existence of these points of view is linked to the co-existence of several objectives (scientific or operational) possible for the collection and for the analysis of the data, at more or less fine spatial and temporal scales. Moreover, the scientific topic considered at the time of observation of the data (for instance the study of the diet of some specific birds) may change when the data are crossed with other ones to address another scientific issue (for instance the evolution of pollution in some geographic areas and its impact on the fauna).
Extending and Refining the Ontology We propose to refine some parts of the SSN ontology in order to be able to represent multiple mappings and to point out the existence of multi-mapping to the users. We regroup our proposals under a new vocabulary and propose to use the mssn prefix, standing for multi-mapping SSN. In particular, we propose the addition of a new class representing alternative observation design, with the label mssn : AltObservationDesign, as a subclass of ssn : Observation. Every mapping will then be described under one alternative observation. In order to highlight the existence of alternative mappings, we also propose to refine the following SSN properties: featureOfInterest, observedProperty and observedBy. The case of the feature of interest is described in Figure  9. Table  1  details the extensions we propose (introducing the mssn prefix): • the alternative observation class allows a given observation from the real dataset to be designed in different manners, meaning multiple mappings are available; • the alternative feature of interest property makes it possible to highlight the fact that the observation being considered can be designed in various manners in order to define the feature of interest; • the alternative observed property makes it possible to highlight the fact that the observation being considered can be designed in various manners in order to define the observed property; • the alternative observed by property makes it possible to highlight the fact that the observation being considered can be designed in various manners in order to define the sensor.
All these examples are built from sample data from the running example depicted by Figure  13 , Figure  14  showing the 52 • North SOS schema it relies on. We consider that URIs have been provided for the data, as proposed by the SOS framework, and that the prefix for this dataset is @pre f ix f auna : < oli f esite/data/ f auna/ >. We thus have RDF triplets such as: fauna:species mssn:altFeatureOfInterest ssn:FeatureOfInterest.
The Information System (IS) should store the data collected by various means (electronic, human, automated or manual, etc. ). These data are saved in a central database and then inserted into the SOS service using HTTP requests. Then, these data can be queried and viewed by the clients by also using HTTP requests. Figure  16  shows the system's general architecture. Several clients are developed to retrieve these data and display them on maps and diagrams. Those are web clients using JavaScript libraries to connect to the SOS service through basic profile operations. In addition, these clients use open source data visualization tools such as Open Layers. We have used the SOS. js client, which is a JavaScript library used to build web pages to access the SOS service to use the observation data.
This library contains the basic operations of SOS to retrieve the data of the observations and the metadata of the sensors. Similarly, it defines a web-based graphical interface to visualize the data. This client is open source and can be adapted to the needs of the SOS service. As described in  [30] , the O-LiFE observatory is implemented by relying on the 52 • North German initiative for Geospatial Open Source software, Sensor Observation Service (SOS) and Observations and Measurements (O&M) The SOS is a web service to query real-time sensor data and sensor data time series and is part of the Sensor Web framework. A 52 • North PostgreSQL database with a predefined schema by the 52 • North implementation of the SOS is used to store the sensors' data. The PostGIS spatial extension is included in the PostgreSQL database.
In particular, the necessary data to run the experiments is provided at http://www. value-cost. eu/data, and both the downscaled data and the individual validation results are available at the VALUE validation portal http://www. value-cost. eu/ validationportal. The paper is organized as follows. The experimental framework followed and the predictor and predictand data used are described in Sec. 2. Section 3 presents the methods contributing to this study (a brief description and specific implementation details for each method are given in Annex 1). It also describes the selection of the predictors and data preparation and analyzes the predictor-predictand link established by the different methods. Sections 4 and 5 presents the validation results for precipitation and temperatures, respectively, focusing on the biases in the mean and the standard deviation resulting from the methods.
g. Kottek et al. 2006)  shown in Table  1  has been calculated directly from the data using MeteoLab http://meteo. unican. es/trac/MLToolbox/ wiki. Figure  1  shows the eight PRUDENCE  (Christensen and Christensen 2007)  sub-regions used to combine and summarize the individual validation results at a sub-regional level along the paper. These regions are British Isles, Iberia, France, Central Europe, Scandinavia, the Alps, the Mediterranean, and Eastern Europe. The resulting dataset (including daily data for precipitation and temperatures for the analysis period) is publicly available in text (csv) format at http://www. value-cost. eu/data.
b. Reanalysis Predictors ERA-Interim  (Dee et al. 2011 ) was selected by the CORDEX initiative as the reference reanalysis for the coordinated downscaling experiments. Therefore, in order to be aligned with this initiative, VALUE also used ERA-Interim to drive the experiment with "perfect" predictors. Although reanalysis uncertainty has been recently reported as an additional source of uncertainty for statistical downscaling  (Brands et al. 2012) , the effect on the downscaled results is relevant only in the tropics  (Manzanas et al. 2015). Therefore, this factor was not tested in VALUE. In order to keep the experimental framework as controlled as possible and to facilitate the work of the contributing groups, we generated a reference predictor dataset downloading ERA-Interim data from ECMWF's MARS.
The dataset includes a reduced number of commonly used predictors, degraded to a common 2 • grid and post-processed by computing daily means from the original 6 hourly fields when required (see Table  2 ). This reference dataset includes most of the circulation and thermodynamic predictors at different pressure levels (including some surface predictors), typically used in downscaling applications in different European regions  (Huth 1999; Benestad 2002; Huth 2002; Timbal et al. 2003; Huth 2005; HanssenBauer et al. 2005; Gutiérrez et al. 2013; Hertig et al. 2014; San-Martín et al. 2017) , excluding redundancy as much as possible. For instance, vorticity and divergence have been considered as potential predictors in the literature (see, e. g. Hessami et al. 2008 ), but they were excluded from the standard set since they reported similar results to geopotential or wind directions in some studies  (Gutiérrez et al.
2013). However, some contributors used in-house ERA-Interim datasets instead, for convenience or because they needed extra predictors (see Sec. b for more details). Since MOS methods typically work with the direct model output at the nearest gridbox to the target station, we also compiled surface precipitation (PRC) and minimum (TMIN) and maximum (TMAX) temperature from the original ERA-Interim dataset at 0. 75 •. In order to illustrate the effect of the model resolution on the results, in the analysis we will consider raw ERA-Interim outputs at two different resolutions: 2 and 0. 75 • (hereafter referred to as  respectively).
c. RCM Predictors (for MOS methods) Since MOS methods are typically applied to both GCM and RCM outputs, a second (optional) predictor dataset for MOS methods was produced considering daily surface precipitation (PRC) and minimum (TMIN) and maximum (TMAX) temperature from a state-of-the-art RCM (the RACMO2 model) driven in climatic mode by ERA-Interim (see  Meijgaard et al. 2012 , for a detailed description of the model). This simulation was produced in the framework of the EURO-CORDEX project  (Jacob et al. 2014 ) using 40 hybrid coordinate full vertical levels on a regional 0. 11 • domain over Europe. RACMO2 ranked among the best performing RCMs over Europe in this reanalysis-driven experiment  (Kotlarski et al. 2014). The MOS techniques contributing to this additional experiment are indicated with a check mark in the second column (labelled as 'R') of Tables  3  and 4.
Therefore, interesting conclusions could be obtained by comparing the results of QM methods taking into account the different configurations and implementations. The participating PP methods (#26-42,#24-46, for precipitation and temperatures, respectively) broadly represent the most popular and widely used families of techniques -analogs (A), transfer function / regression (TF) and weather-type (WT) methods-in fairly standard implementations in most of the cases. The analog techniques are the only multivariate methods (multi-site and/or multi-variable). However, some of the TF methods use PCs as predictors (Sec. b), which may provide some imprinted spatial inter-consistency due to their spatial character. Those cases are indicated with a 'yes' multi-site code in Tables  3  and 4. Nonparametric regression methods (e.
Promoting Transparency and Reproducibility of Results Research transparency and reproducibility is a major concern in the different experimental disciplines (see a string of freely available nature articles on reliability and reproducibility of published research at http: //go. nature. com/huhbyr). For instance, a recent survey over 1500 scientists recently reported by  Baker (2016)  revealed that the work published in different research fields (including Earth and Environment) were mostly not reproducible (over two-thirds). As a result, there is growing alarm about results that cannot be reproduced. In VALUE substantive steps were taken in order to improve transparency and reproducibility of results, and to promote awareness within the downscaling scientific community. The main difficulties for research reproducibility identified include 1) access restrictions to raw input data and/or results, 2) poor experimental design information, 3) lack of code availability, and 4) incomplete documentation of the particular configuration and implementation used (data preprocessing, method configuration and specific parameter values, training options, etc.
). In some cases, the steps involved in the downscaling process are very technical and they are not always appropriately documented in practical applications, thus making difficult the reproducibility of the results. The following actions have been undertaken in VALUE in order to avoid the above mentioned problems: • 1) All the data needed for the experiments described in this paper has been collected and made available at http://www. value-cost. eu/data. Moreover, the daily downscaled data and the resulting validations for each of the methods and experiments are also publicly available under the liberal Creative Commons Attribution (CC BY) License (http://creativecommons. org/licenses/by/4. 0). Contributors also get access to VALUE PRIVATE published data, which is made available internally to the consortium for quality check and verification purposes before publication (more info in http://www.
value-cost. eu/terms). • 2) The experimental framework was designed and published  (Maraun et al. 2015)  in advance of the open call for contribution to this validation experiment. • 3) The code used for the validation framework (from data loading to computing all the validation measures) has been coded in R and is publicly available from http://github. com/SantanderMetGroup/ R_VALUE. In addition, the packages and/or code needed to reproduce the results for some of the downscaling methods are publicly available (see Annex 1). Other methods use proprietary software and cannot be replicated; however, we decided to also include this information to favor method inter-comparability, but requiring the open publication of the results (both predictions and validation results), which was mandatory for all methods contributing to this paper.
• 4) Furthermore, a metadata description vocabulary for statistical downscaling methods has been defined and implemented in the VALUE Validation Portal, providing information on the method characteristics and implementation details needed to properly analyze the results. Finally, transparency is further promoted by the VALUE Validation Portal http://www. value-cost. eu/validationportal, providing public access to the metadata and data for all contributing methods and also for all validation results, as well as tools to filter and visualize (both in tabular and graphical formats) the results.
Conclusions In this paper we present the ensemble statistical downscaling methods produced in the VALUE collaboration, which covers the three common downscaling approaches (perfect prognosis, model output statistics ?including bias correction? and weather generators) with a total of over fifty downscaling methods. We also present the first results from the inter-comparisson experiment under the same cross-validation experimental framework using "perfect" predictors. Additional experiments with GCM data will follow to contribute to the EURO-CORDEX initiative. Appropriate metadata on the main model characteristics (e. g. deterministic or stochastic nature) and implementation details (predictors, geographical domain, monthly/seasonal training, etc. ) have been collected in order to properly analyze the results.