dataesr/scientific-paragraphs-categorization huggingface dataset:
Although both methods are based on the hypothesis that most genes are not differentially expressed, they are computed differently and are not exchangeable unaltered. The size factors computed by DESeq2 are used in the estimation of the mean of the Negative Binomial distribution when the scaling factors proposed by edgeR apply to library sizes (total counts), the normalized library sizes being included as an offset in the statistical model. Thus, an adequate transformation is needed when willing to use any of these normalization methods with any test for differential expression, otherwise leading to inconsistent results as shown in  [12]  and in the S1 Appendix. Similarly, transformation is an important issue at the quality control step where clustering methods and Principal Component Analysis can be used to explore the structure of the dataset.
These methods make the assumption that the data are homoscedastic, meaning that the variance is independent of the signal intensity. However count data are not homoscedastic. Using either raw counts or popular transformations such as Reads Per Kilobase per Million mapped reads (RPKM) normalized expression values is not suited for such methods  [1, 4]. Finally, in the context of developing reproducible research it is essential to fully describe and explore the data and keep track of the full analysis process with the associated parameter values and software versions. edgeR and DESeq2 do not provide an automatic reporting tool for this purpose.
Indeed, it is neither desired nor safe to automate this part of the analysis process. Users who would have to analyse complex experimental designs are encouraged to use directly either DESeq2 or edgeR which both provide extensive help about this kind of experiments. SARTools is composed of an R package and two R script templates that allow to run the analysis with either DESeq2 or edgeR. Both scripts rely on each package-specific functions as often as possible, and on SARTools functions to export figures and tables and to generate the HTML report. Each script starts with a section of about 15 parameters that refer to (i) paths to input files and the working directory where the analysis will be performed, (ii) project identification, (iii) experimental design, (iv) normalization and statistical test, (v) filtering process and (vi) plotting.
If a blocking factor has to be accounted for (e. g. in case of batch effect or paired samples), it is reported in a fourth column. These input files are read by SARTools to build a matrix of integer values in which the intersection of the i-th row and the j-th column reflects how many reads have been mapped to feature i in sample j. This matrix is then used as input for DESeq2 or edgeR. The source code of the package and instructions to quickly install it are available on GitHub (https://github. com/PF2-pasteur-fr/SARTools). Fig  1  describes the successive steps of the workflow and provides the names of the scripts and R functions corresponding to each step. Furthermore, the Galaxy wrappers to integrate SARTools into a Galaxy instance  [15] [16] [17]  are available on the Galaxy Tool Shed of the Institut Français de Bioinformatique at http:// toolshed.
Results and Discussion As soon as the script parameters have been given proper values, and assuming that input files fulfill the format requirements described above, the R script can be run. Using a standard desktop computer, the running time is usually lower than one minute to perform the analysis of 10 samples containing about 50 000 features each. Two types of output files are then made available: 1. a HTML report that describes the whole analysis process in four main steps: • data quality control: numerous plots are proposed to provide a comprehensive description of the dataset, including, for each sample: total number of reads, proportion of null counts, name of the feature having the highest count and proportion of reads associated with it (see the SARTools vignette on GitHub for a full list of the descriptive plots).
Principal Component Analysis (PCA) and sample clustering use properly transformed data (with either the Variance Stabilizing Transformation (VST) or the rlog transformation for DESeq2, or log Count Per Million (CPM) for edgeR). These figures provide redundant yet complementary information that help the user to understand the structure of the data and detect possible problems. Legends and titles are added to all figures. The color associated with each sample remains consistent across all figures to ease the interpretation. • normalization: this section uses the default normalization associated with each package, as they have been shown to perform equally well  [11]. Two alternative normalization methods are available with edgeR and are accessible through a normalization parameter. When running DESeq2 specific histograms are plotted to check the relevance of the normalization option (refer to the package vignette for additional information).
Note that SARTools does not allow the user to perform other normalizations than the ones proposed with the package used for the analysis. For example, it is impossible to provide DESeq2 or edgeR with a matrix of (rounded) RPKM counts as input or any matrix of already normalized values, as both statistical models only accept raw counts as input. • test for differential expression: results include plots to assess the validity of the statistical test as well as lists of up-and down-regulated features. These figures include a histogram a raw p-values, a MA-plot and a volcano-plot for each pairwise comparison. A detailed description of the tab-delimited text files containing these lists is also provided. • R session information and parameter values: this section keeps track of all the information about the packages, methods and parameter values used to run the analysis.
In a reproducible research framework, this section is particularly important if the user has to re-perform the analysis later within the same environment and with the same parameters. Furthermore, providing these pieces of information is also often required for publication purposes. 2. three tab-delimited text files per comparison, containing (i) information about all the genes included in the analysis, (ii-iii) lists of significantly up-and down-regulated features ordered by adjusted p-value. Even if Gene Ontology (GO) term analysis is out of the scope of SAR-Tools, these files can be used as a starting point for such an analysis. All the figures produced by SARTools are integrated into the HTML report and enable the user to perform quality control of the dataset in several ways. Indeed, as they provide complementary pieces of information, they allow a reliable detection and interpretation of possible problems within the dataset and the analysis results.
Common problems that may arise from RNA-Seq experiments can be, but are not limited to, the presence of outlier samples, the presence of a batch effect, an inversion between two samples, the presence of a highly expressed sequence in some or all samples, etc. As an example, the presence of an outlier sample in the dataset may be detected in several ways (Fig 2 ): it can have a much lower-or higher-total number of reads than the other samples. This total count difference may be associated with a higher proportion of null counts (in that case the DESeq2 normalization process will hardly compensate for the difference for these genes having a null count in this sample only, since it is a multiplicative correction), or a clear difference in the density distribution of the counts, or a higher proportion of reads associated with the most represented feature.
Conclusions SARTools supplies a detailed description of the dataset and proposes diagnostic plots for each step of the analysis. The simple structure of the scripts allows the user to easily and quickly adapt the analysis process to the characteristics of the dataset and to detect possible problems. Unlike other RNA-Seq data analysis pipelines, it does not allow the user to pipe any possible method at any step of the analysis process to build his own workflow, as it focuses on the proper use of these statistical methods. Experienced data analysts may be able to use appropriate command lines to check the quality of raw reads and map them appropriately, they may be regular R users as well without being aware of specific requirements of the statistical models involved and possible problems arising from mixing different methods relying on different models or assumptions.
In this context, SARTools provides a safe environment for differential expression analysis of RNA-Seq data on a gene basis. SARTools has been designed for the detection of differentially expressed genes but very recent advances enable one to perform the differential analysis at the transcript/isoform level. For instance, the new tximport R package  [19]  available on Bioconductor allows to import in R transcript-level quantification results from softwares like salmon  [20]  and pass them to DESeq2. One of our objectives in the near future is to adapt SARTools to this kind of analysis.
Acknowledgments We thank  Odile Sismeiro ,  Caroline Proux ,  Bernd Jagla ,  Andrea Rau  and  Christelle Hennequet-Antier  for their support and very helpful comments. We also thank  Christophe Caron  in charge of the  IFB Galaxy Working Group  ( Institut Français de Bioinformatique ) and  Valentin Loux in charge of the bioinformatics work package of the France Génomique  project.
I. INTRODUCTION Much work has been done about fuzzy querying of relational databases (see e. g. [1] ). However, even though relational databases are still widely used, the need to handle complex data has led to the emergence of other types of data models. In the last few years, a new concept has started to attract a lot of attention in the database world, namely that of graph databases (see e. g. [2] ), whose basic purpose is to efficiently manage networks of entities where each node is described by a set of characteristics (e. g. a set of attributes), and each edge represents a link between entities. Such a database model has many potential applications, e. g. for modeling social networks, RDF data, cartographic databases, bibliographic databases, etc. This model may be extended into the notion of a fuzzy graph database where a degree may be attached to edges.
This degree may express the "intensity" of any kind of gradual relation between two nodes (e. g. likes, is friends with, is about). Graph databases, which may be fuzzy or not, raise new challenges in terms of flexible querying since two aspects may be involved in the preferences that a user may express: i) the content of the nodes and ii) the graph structure. We present SUGAR, a system that makes it possible to query a fuzzy graph database in a flexible way. This system is built on the Neo4j Graph Database Management System  [3]  and implements the FUDGE language introduced in  [4].
II. GRAPH DATABASE FUZZY QUERYING The last decade has witnessed a growing interest in preference queries (see e. g. [1] ). Motivations for introducing preferences inside database queries are manifold. First, it has appeared to be desirable to offer more expressive query languages that can be more faithful to what a user intends to say. Second, the introduction of preferences in queries provides a basis for rank-ordering the retrieved items, which is especially valuable in case of a large set of items satisfying a query. Third, a classical query may also have an empty set of answers, while a relaxed version of the query may be matched by some items. In the graph database context, the need for having flexible querying tools is even more acute as users are in general unfamiliar with the representation of the data  [2].
III. THE FUDGE LANGUAGE The FUDGE language  [4]  is based on the CYPHER query language, used for querying graph databases in a crisp way in the Neo4j graph database management system  [3]. FUDGE relies on a formal algebra defined in  [4]. We focus here on selection queries in which fuzzy preferences may appear. A FUDGE selection query is composed of: (1) a list of D E F I N E clauses for fuzzy term declarations. If a fuzzy term fterm is defined by a trapezoidal function with the four positions (abscissa) A-a, A, B and B+b, then the clause has the form D E F I N E fterm A S (A-a,A,B,B+b). If fterm is a decreasing membership function, then the clause has the form D E F I N E D E S C fterm A S (B,B+b) (and there is the corresponding D E F I N E A S C clause for increasing functions). (2) a M A T C H clause of the form M A T C H pattern W H E R E condition where pattern is a fuzzy graph pattern and condition is the possibly compound condition attached to the pattern.
IV. THE SUGAR SOFTWARE The SUGAR software implements the FUDGE language. It is built from the Neo4j REPL Console Rabbithole  [6]  supporting CYPHER queries. SUGAR is a software add-on composed of two modules, which interact with a Neo4j crisp engine (see Fig. 2 ): the Transcriptor module and the Score Calculator one. The former aims to translate a FUDGE query into a (crisp) CYPHER one that retrieves all needed data. This query is then sent to the crisp Neo4j engine. Then the Score Calculator module extracts answers and calculates the satisfaction degree associated with each answer returned by the crisp engine, and ranks the answers. SUGAR proposes a user-friendly GUI, which is an extension of the Rabbithole one. It is composed of (i) a frame for visualizing the graph database and the results of a query and (ii) an input field frame for entering and executing a FUDGE query.
SUGAR also provides logs that trace the evaluation in an associated console, providing each intermediate result of the execution process: the crisp CYPHER query obtained after the transcription stage (output of the Transcriptor module), the result of the crisp query evaluation (an intermediate result 1 The definition of the length of a path is a fuzzy graph notion defined by  [5] : Length(p) = n i=1 1 ρ(x i-1 , x i ) where ρ(x, y) is the degree attached to the edge (x, y). containing additional information needed for the score calculation), and the final result obtained after the score calculation (output of the Score Calculator module). The logs also provide the execution time associated with each stage of the evaluation.
Then, the user may examine the answers and the associated logs, not only to see the result of a query, but also to understand the evaluation process implemented in the software for the evaluation of a FUDGE query, and to make some interesting observations. One is the conciseness of the FUDGE language. Indeed, the crisp CYPHER query obtained after the transcription stage is really complex wrt. the FUDGE one. Concerning the cost of introducing flexibility, the user will observe that the transcription step is only a small part of the overall evaluation process as it only consists of a linear parsing, and transformation when needed, of the FUDGE query. A similar observation concerns the score calculation step, which only consists of a linear parsing of the set of the crisp query answers for calculating the satisfaction degree associated with each of them, and a classical ranking of the answers according to the degrees.
These combined advantages offer to reduce data gaps caused by cloud cover, and, concerning snow, to improve accuracy for monitoring the timing of snow accumulation and snow melt-out relative to the larger repeat cycles of Landsat or SPOT missions. In order to simulate the Sentinel-2 revisit frequency and output products, the French Space Agency CNES (Centre National d'Etudes Spatiales), joined by the European Space Agency (ESA), implemented the SPOT (Take 5) Experiment, which consisted of moving the SPOT-4 and SPOT-5 satellites to a lower orbit before the end of their respective missions, in order to achieve five-day revisit capacity  [35]. The two experiments took place respectively from February to June, 2013, for SPOT-4 (20 m resolution), and from April to September 2015, for SPOT-5 (10 m resolution) over worldwide selected sites, including our study area in the southwestern French Alps.
Remote Sensing Data The SPOT (Take 5) Experiment was carried out using SPOT-4 and 5 satellites. By combining both SPOT-4 sensors, it was possible to obtain an image tile of 110 ˆ110 km 2 , whereas the SPOT-5 images were registered under the regular size of 65 ˆ65 km 2 , using only a single sensor (Figure  1 ). The dataset was completed with Landsat-8 acquisitions available beginning in April 2013, and with near-daily MODIS images (L1B swath data product). The complete image collection was cropped to the SPOT-5 extent, in order to be consistent for image pre-processing, mapping and analysis. We used a digital elevation model (DEM) at 25 m resolution and a forest layer provided by the French National Institute Geographic Information (IGN) to remove pixels from the analysis that were forested and or below 1800 m a.
All processed SPOT (Take 5) images may be freely downloaded from the CNES-ESA web portal (https://spot-take5. org). To complete the time series for 2013 and 2015, we added available Landsat-8 images at 30 m resolution for both years, which were processed by the THEIA Land Data Center using the same atmosphere and slope-correction algorithms as for SPOT (Take 5) outputs. These data are also distributed with a free and open policy (https://theia-land. fr). Considering the L2A-FRE output as the optimal available product, particularly for early spring months characterized by low solar elevation, we acquired all SPOT and Landsat images for this study at this enhanced correction level. In total, we used thirty-eight high-resolution images (see Table  S1  in Supplementary Material), including six SPOT-4 dates (2013), eleven SPOT-5 dates (2015), and twenty-one Landsat-8 dates (nine for 2013, twelve for 2015).
MODIS Image Processing From February 2000 onward, the MODIS sensor onboard the Terra platform has acquired images worldwide with daily temporal resolution. The National Snow and Ice data Center (NSIDC) provides snow map products at daily and eight-day intervals  [50, 51]. However, the steep topography of our study area necessitated the use of an enhanced algorithm for detecting snow cover in mountainous terrain using MODIS data. MODImLab is a MATLAB toolbox allowing MODIS L1B swath data products (radiance at the top of atmosphere TOA) to be downloaded and processed automatically towards the production of binary snow maps and maps of sub-pixel snow fraction  [52]  snow albedo  [53] , and snow specific surface area  [54]. In this study, MODImLab was used to process MODIS/TERRA L1B data using the image fusion approach, which allows for estimation of the short wave infrared band at 250 m spatial resolution  [55].
4  [56] , which is referenced as a standard value by many publications in the literature since the initial paper of Dozier in 1989. This simple threshold-based approach was applied here to all sensors of our images dataset: SPOT, Landsat and MODIS in order to create binary snow maps. Table  1  summarizes the channels and respective wavelengths of the four sensors used in this study for NDSI and NDVI calculation. Concerning MODIS images, the mapping of snow from fused spectral bands was completed using the binary algorithm of the MOD10 Snow Product  [50]  based on the same 0. 4 NDSI threshold. Additional tests on the visible and near-infrared bands, as well as a thermal test on the surface temperature, enable commission errors in water and dark areas to be reduced  [51]. The separation of snow from clouds is a basic requirement of snow cover classifications using optical data and requires routines to discriminate snow on the ground from different types of cloud cover.
Cloud masks were provided by CNES-Cesbio and were applied to Landsat and SPOT images, as demonstrated in Figure  5  (CNES product). Concerning MODIS images, MODImLab implements a cloud detection algorithm based on a selection of tests largely inspired from the MOD35 product  [57] , which was applied to MODIS reflective and emissive bands from the MOD021KM swath L1B products. Combining binary maps retrieved from the NDSI threshold with cloud masks generated snow cover maps at moderate (MODIS 250 m) and high (SPOT and Landsat at 25 m) spatial resolutions. The separation of snow from clouds is a basic requirement of snow cover classifications using optical data and requires routines to discriminate snow on the ground from different types of cloud cover. Cloud masks were provided by CNES-Cesbio and were applied to Landsat and SPOT images, as demonstrated in Figure  5  (CNES product).
Vegetation Data and Ground Measurements of Snowmelt We assembled a database of 1272 vegetation plots from subalpine grasslands, shrub and heathlands, and alpine meadows. Data were provided by the Conservatoire Botanique National Alpin (http://www. cbn-alpin. fr/) and the Ecrins National Park. Floristic surveys were conducted from 2000 to 2014 and consisted of recording all vascular plants occurring in a sampled area ranging from 10 m 2 to 25 m 2. The geo-location error of vegetation plots was less than 10 m. Vegetation plots below 1800 m a. s. l. were disregarded in order to exclude grassland patches interspersed with mountain forests. Similarity-based cluster analysis was conducted using an agglomerative clustering technique  [59]. First, floristic distances between vegetation plots were estimated using the Jaccard index, which is based on presence-absence data.
Acknowledgments: The SPOT (Take 5) Experiments were proposed by CESBIO and implemented by  CNES  with the support of the  European Space Agency. We are grateful to CNES for the selection of our SPAMN ( SPOT-4 ) and ECRINS (SPOT-5) projects as test sites for the SPOT (Take 5) Experiments. Data were processed and delivered by  CNES  for the THEIA Land Data center and the authors wish to highly thank  Olivier Hagolle  from  Cesbio-CNES  for the pre-processing of SPOT-4, SPOT-5 and Landsat-8 images and his reviewing of the image processing section of the paper. The MODIS Level-1B data were processed by the  MODIS Adaptive Processing System (MODAPS)  and the  Goddard Distributed Active Archive Center (DAAC) , which are archived and distributed by the  Goddard DAAC. We thank the  Météo France technical  staff for maintaining instruments at the  Col du Lac Blanc and in the Nivose network , and for handling data acquisition and storage.
We thank  Deborah Verfaillie  ( CNRM-GAME, CEN ) for providing outputs of the S2M reanalysis. We thank  Alexis Mikolajczak  who assisted us in preparing vegetation plot data, and Cédric Dentant who provided data from the  Ecrins National Park. We thank  Jean-Paul Laurent  for the monitoring of snow cover dynamics at the Lautaret pass in the framework of the  FLUXALP  project funded by the  Labex OSUG@2020  (Investissements d'avenir- ANR10 LABX56 ). Thanks are also due to Vincent Thiérion from the  National Institute for Environmental Science and Research (IRSTEA)  for his technical help on the SPOT-4 part of the project, to  Amélie Arnould  for her contribution to the climate figures, and to  Thomas Cavallo  for his work on snow mapping with SPOT-4 images. Pascal Sirguey thanks the  University of Otago , the  Grenoble Institute of Technology (INP-Grenoble)  and the  University Grenoble-Alpes (UGA)  for supporting his contribution to this work while on research and study leave in Grenoble.
Finally, the authors thank the reviewers of this paper for their constructive comments on an earlier version of the manuscript. This research was conducted on the long-term research site  Zone Atelier Alpes , a member of the  ILTER-Europe network , and was supported by the  Zone Atelier Alpes  and by the  Station Alpine J. Fourier (SAJF). The publication was funded by the  Gestion et Impacts du Changements Climatique ,  Drôme: Eau ,  Climat Impacts liés aux Changements (GICC-DECLIC) program.