dataesr/scientific-paragraphs-categorization huggingface dataset:
So, for complex tasks such as SITS forecasting, the capabilities of DL models seem well suited, provided that a dataset with a long time series is available. In fact, the volume of historical available data representing the same area is important for the DL model to better capture the relationships between past and present images. Some events may occur, for example, only after a long period of time; it is important for the model to have a long enough series to capture the behavior of that event over time. The longer the series, the more training data the model can access; this leads to greater prediction accuracy. Having a long time series also avoids the phenomenon of overfitting that occurs in DL models when it focuses on the training data and fails to make good predictions on new data  [41].
• The Copernicus Open Access Center (https://scihub. copernicus. eu/ (accessed on 10 May 2022)) provides users with full access to Sentinel products. Images are available online as soon as satellite images are received; however, older images are generally not immediately downloadable and must be specifically requested. About six months after the registration of an image, the image is put in offline mode on the official Copernicus website, and a request must be sent to the server to put the product back online, for a determined period. In most platforms, images are generally downloaded individually; however, when a series of images must be collected, it is preferable to automate the downloading of the data using scripts, and, one way to do this is using dhusget program, a download command line based on the cURL and Wget programs and initiated by the Sentinel Data Center.
dhusget. sh [LOGIN] [SEARCH_QUERY] [SEARCH_RESULTS] [DOWNLOAD_OPTIONS] More details on the various setting options are available on the Copernicus Data Access Center user page. (Online (Available): https://scihub. copernicus. eu/userguide/ BatchScripting (accessed on 10 May 2022). ) Another simple way to automatically download S1 images is using aria2c, which is the download manager on the official Copernicus website. With this tool, the user specifies the search criteria related to the AOI, and the validation of the selected products generates a file named products. meta4. The command used to start the batch download is listed below. Note that a valid Copernicus Open Access Center user account is required to run these command lines. aria2c --http-user='username' --http-passwd='password' --check-certificate=false --max-concurrent-downloads=2 -M products.
meta4 A major drawback with the two methods is when a product is offline, the command is not able to immediately download it; however, there is a way to configure the script to send a request to the server when a product is offline, and check its availability after a certain time. For the data used in this study, the researchers downloaded images from the ASF platform and selected all the available images for each study area. The corresponding Python scripts were executed in command lines on a local machine to start the recording of all images. For more information about the bulk collection from the Vertex platform, please navigate to the ASF website. (Online (Available): https://asf. alaska. edu/how-to/datatools/data-tools/ (accessed on 3 July 2022). ) The files containing the source code used to download the images from the three study areas are available at http://w-abdou.
fr/sits/ (accessed on 10 August 2022). Table  1  presents the search parameters used for each study area and all available data from 15 June 2014 to 3 July 2022 were selected to be downloaded. The AOI to be downloaded are delimited using the WKT coordinate; thus, to download the images corresponding to a new location, one needs to know the geographical coordinates and enter them on the platform to generate a corresponding Python file. The command to execute the download file (on a Unix console) is the following: Python name_of_python_file. py 3. 2. Preprocessing 3. 2. 1. SNAP Software For the processing of Sentinel data, the ESA has developed a powerful application called the Sentinel Application Platform (SNAP). The SNAP software was jointly developed by Brockmann Consult, SkyWatch, and C-S for the visualization, processing, and analysis of EO data in general and Sentinel products in particular.
As Figure  4  displays, SNAP uses several technologies such as the Geospatial Data Abstraction Library, NetBeans Platform, Install4J, GeoTolls, and Java Advanced Imaging (JAI). The processing can be done using the SNAP Desktop graphical interface or command line in the SNAP Engine. Within the SNAP software, there is a flexible processing framework called GPF  [26]. The GPF is based on JAI and allows users to implement custom batch processing chains. Figure  5  highlights how the GPF works using assembled graphs from a list of available operators. It is a directed acyclic graph (without loops or cycles) where nodes represent the processing steps called operators, and edges indicate the direction in which data is transferred between the nodes. The data source is the images received as inputs from the read operator, and the output can be either an image recorded by the write operator or a displayed image.
1. Read: The "read" operator is used to load the data. This operator accepts not only S1 images but also other types of data. 2. Apply orbit file (AOF): The default metadata provided when SAR data are downloaded is generally not very accurate. In SNAP, the updated orbit file, with more accurate information to help improve geocoding and other processing results, is automatically downloaded by the AOF operator. This operation should be performed as a priority before all other preprocessing steps for better results.
3. Border noise removal (BNR): Because of irregularities on the Earth's surface, deformations can appear on the Level-1 images during their generation. The BNR operation allows one to correct and remove noises present on the edges of images. 4. Calibration: The calibration step (calibrate) aims to correct the signal intensity according to the sensor characteristics and the local incidence angle. The metadata of the input products allows SNAP to automatically determine the corrections to be applied. In this work, the operation is performed for both VV and VH polarizations. 5. Terrain correction: The initially downloaded S1 images are devoid of geographic coordinates, which makes them unusable for most applications. The ortho-rectification step is performed to geo-reference images in order to project them into the Universal Transverse Mercator system or World Geodetic System 1984.
Batch Processing Using GPT Each graph designed with the SNAP graph builder can be exported as an XML file to automate the process. Even though it is possible to run batch processing from SNAP software, it is recommended to execute operators via the SNAP GPT tool for greater flexibility. The GPT tool is the command-line interface of SNAP that is used to execute raster data operators in batch mode. This is another way to perform batch processing without using the graphical user interface mode within the SNAP software. To use the gpt command, the operations can be processed individually, or they can be processed in a defined workflow. Instead of specifying operator parameters separately in the processing stream, it is possible to use the XML-encoded file as a parameter of the gpt command. The general syntax used to execute the command for one image is offered below.
gpt <GraphFile. xml> [ options ] [<sourcefile1> <sourcefile2>. ] All the XML files used to process images corresponding to the three study areas have almost the same content. The main difference lies in the geographical coordinates used to clip the images (subset operator) and the map projection system (terrain correction operator). To simultaneously execute the processing of all the raw images, the researchers proposed a bash script. The code lines were written to be executed in a Unix environment. This script browses the whole directory and applies the processing chain to each found image. The advantage of having each file name written according to a particular naming convention (Online (Available): https://sentinels. copernicus. eu/web/sentinel/user-guides/sentinel-1-sar/ (accessed on 10 May 2022)) is that it allows one to receive the acquisition date of each image and rename the processed image.
S1A_IW_GRDH_1SDV_20150409T171237_20150409T171302_005410_006E19_7760. zip The XML files defining all the preprocessing operations and the scripts to execute data in the batch are available at http://w-abdou. fr/sits/ (accessed on 10 August 2022). At this stage of the preprocessing workflow, the images can be used for many other applications such as classification, segmentation, spatio-temporal analysis, and so on. For each use case, specific operations must be performed on the preprocessed data. For the specific case of using datasets for SITS prediction, the operations described in the following section prepare the data so that it can be provided to DL networks.
Used Tools The experiments were carried out on a computer with a GNU/Linux operating system (Ubuntu 20. 04. 1 LTS). Table  4  gives the main hardware characteristics of the system used in this study. As far as software tools are concerned, the following programs were used: • SNAP 8. 0: A tool used to design and implement the automatic batch processing workflow. This software also allowed to display and analyze the downloaded data; • QGIS 3. 16. 0-Hannover: A program used for manipulating the shape-files and the geographic information. This tool was also used to analyze the obtained image time series; • Python 3: A programming language mainly used for download scripts;.
Preprocessed Dataset Description At the end of this study, a database of three time series of preprocessed S1 images is built. The SITS are from the selected study areas, namely the BNP, the DBR, and the WRT. During the preprocessing chain execution, no intermediate files are saved. In fact, only the final results are saved on the disk. Since the sizes of the raw images are very large, this avoids unnecessary use of storage memory. A total of 628 images are downloaded with the Python programs. Each raw image, with an average size of 1 GB, is downloaded as a compressed file (zip) using an average rate equal to ten megabytes per second (MB/s). It took about 18 h to download all the data with a total size of 654. 9 GB. One can notice that a fast internet connection is recommended for this step.
The summary of the download information is given in Table  5. The analysis of the collected images depicts that some data are missing in the time series. Indeed, there is about 6% of missing data for the BNP and DBR areas, compared to only 2% for the WRT. Table  6  gives the list of dates (dd/mm/yyyy) where images are not available for each study area. The column "Percentage" represents the proportion of missing data. The raw satellite images contain a lot of information and are very large. Their processing is often time-consuming and requires a processing unit with good capabilities. Table  7  presents the performed processing time for each study area. In sum, about 16 h were required for the three areas. The WRT presents the smallest processing time because the surface considered for the raw image slicing was the smallest, only 44,379 hectares (ha).
The constructed datasets (Figure  7 ) are available at http://w-abdou. fr/sits/ (accessed on 10 August 2022) and can be downloaded for free. A total of 1256 preprocessed images in VV and VH polarization are proposed: 408 for BNP, 414 for DBR, and 434 for WRT. Table  8  gives the characteristics of each dataset. Since the pixel size of the images is 10 m, the areas in hectares for each of the AOI are approximately 221,000 for BNP, 490,000 for DBR, and 44,500 for WRT. Figure  8  shows plots extracted from each AOI. It allows distinguishing globally the type of land cover in each image, thanks to Figure  8a , which corresponds to the RGB image from Google satellite images. Google satellite images show a natural view of surfaces and are imported from the QGIS Tile+ plugin. For example, one can deduce from Figure  8a  that the DBR area is essentially made up of forest cover, while in the BNP there is a lot of savannah or bare soil.
Experiments In this paper, a methodology to collect, preprocess and prepare SITS for use with DL algorithms is presented. The experiments resulted in three datasets that can be used for a variety of applications. To test the effectiveness of the proposed methodology and demonstrate the practicality of the datasets, three LSTM architectures suitable for prediction problems in SITS  [8]  are applied to the VH-band images of BNP and WRT areas. The presented application focuses on SITS prediction problem. In particular, the CNN-LSTM  [42] , ConvLSTM  [43] , and Stack-LSTM  [44]  models are trained with BNP and WRT SITS in order to learn how changes occur from one image to the next one, and then predict the next occurrence of an input sequence. The input size is set to five (timestep = 5) and the models are designed to forecast only one element ( f eatures = 1).
Conclusions In this study, the researchers propose processes for automatic downloading and batch processing of S1 images. The presented processing workflow was designed based on the GPF of SNAP software. The study resulted in three time series made of preprocessed Sentinel-1A (Level-1 GRD) images in VV and VH polarizations. The researchers considered three study areas: the BNP, the DBR, and the WRT. A seven-year long-term series (1256 processed images), along with the source codes used, were made available to the public. The resulting datasets which are diverse can be used for multiple purposes, including time series prediction problems with DL algorithms such as deforestation forecasting. Moreover, the time series can help other applications such as multi-temporal speckle filtering, classification, and time series analysis for the considered areas.
To validate the proposed workflow, the CNN-LSTM, ConvLSTM, and Stack-LSTM architectures were used for the next occurrence prediction in Sentinel-1 image sequences. For each of the series, missing data were found, likely due to sensor failures. Yet, having a complete series is an essential element that influences the quality of the predictions. It would, therefore, be relevant to propose algorithms to reconstruct the missing data in the Sentinel-1 image time series to have complete sequences in future works.
Rab11 and RNPs colocalize in infected cells Recycling endosome vesicles, marked by the small GTPase Rab11, are known to be involved in RNP trafficking of several negative strand RNA viruses  [25] [26] [27] [28]. To investigate the recycling endosomes involvement in RSV RNPs trafficking, we analyzed Rab11a and RSV RNP intracellular localizations. We infected A549 cells constitutively expressing HA-Rab11a (A549-HA-R-ab11a) with wild type RSV  [34]. At the indicated time points, cells were fixed and N and HA-Rab11a were detected by immunostaining. Both N and HA staining revealed numerous individual cytoplasmic dots corresponding respectively to vRNPs and Rab11a positive endosomes, which exhibited partial colocalization (Fig  5 ). To quantify the colocalization between Rab11a and N positive dots, we extracted spot detections and performed object-based  colocalization analysis using Icy software.
However, this method did not enable RNP trafficking analysis  [12, 13]. vRNPs are small, highly mobile objects. To track them, we had to find a compromise between the number of optical slices (z) analyzed and the time interval between 2 images. Our optimized pipeline relies on the acquisition of images on 2 to 3 optical planes with a total thickness of 0. 7 to 2. 3 μm and time-frame intervals of 0. 07 to 0. 21s. Our experiments were conducted on HEp-2 or A549 cells which are very thin as compared to some other cell types. Expanding the method to other cells is likely to require further optimization. In these cells, these parameters allowed a proper automatic tracking of mobile RNPs that are visible in the analyzed volume on several successive images. The potential of our method allowed us to generate high-throughput live imaging datasets otherwise inaccessible with more classical approaches.
Virus and plasmids All the viral sequences were derived from the human RSV strain Long, ATCC VR-26. The wild-type RSV, the RSV-GFP, the RSV-GFP-N and the RSV-L-GFP were rescued by reverse genetics as previously described  [30, 54]. To construct the reverse genetic vector for RSV-GFP-N, the GFP-N coding sequence was amplified from the pmGFP-N vector  [11]  by PCR using specific primers (sequence available upon request) containing RSV gene start and gene end sequences and was cloned into a Eco105I restriction site between the RSV M and SH genes in the pACNR-rHRSV  [30]. The nucleotide sequence of RSV-GFP-N was deposited in the Genbank nucleotide database with accession code OM326756. pmCherry-Rab11a was constructed by inserting the Cherry coding sequence in peGFP-Rab11a  [55]  (kind gift from Dr Sauvonnet) between NheI and XhoI restriction sites.
Immunofluorescence-Colocalization analysis Cells were grown on glass coverslips in 24 wells plates. After infection at high MOI for the indicated times, cells were fixed with PBS-formaldehyde 4% (v/v) for 10 min, washed with PBS and permeabilized with PBS-BSA 1% (w/v)-Triton X-100 0. 25% (v/v) for 10 min. Cells were incubated for 1 h in PBS-BSA 1% (w/v) with the appropriate primary antibodies, rinsed with PBS then incubated for 30 min with the appropriate Alexa Fluor-conjugated secondary antibodies and with Hoechst 33342 (1 μg/ml). Coverslips were rinsed in PBS, then mounted in ProLong diamond antifade reagent (Thermofisher). Cells were examined by confocal microscopy under a WLL Leica SP8 microscope except indicated otherwise. Representative pictures were taken. Colocalization analysis were performed using the open-source software Icy (http://icy.
Live Imaging Live imaging was performed on A549 or HEp-2 cells seeded on Ibidi μ-Slide Angiogenesis, infected and treated as described above. One-minute time-lapse acquisitions were performed at 37˚C and 5% CO 2 using an inverted confocal microscope with a 100x oil-immersion lens (Plan-APOCHROMAT), a CSU-X1 spinning-disk head (Yokogawa, Japan) and a sCMOS-PRIME 95B (Photometrics) camera. The whole setup was driven with MetaMorph software (Molecular Devices, Sunnyvale, CA, USA). One to three z sections with a step of 0. 8 μm were acquired at 70 to 210 ms intervals for 1 min. Laser intensity was set between 10-20% power, and acquisition time was 50 ms. The raw data were processed using ImageJ software (National Institutes of Health, Bethesda, MD, USA) to perform maximum projections of z stacks images and background subtraction.
Tracks analysis was performed on Imaris software 9. 5. 0 (Bitplane Inc. ). Briefly fluorescent spots were identified using Imaris built-in spot generation algorithm (with a seeding spot size of 250 nm). Spot generation was achieved manually for each dataset using intensity at the center of each spot as the threshold. Quality threshold was fixed above 20. 0. The spots were tracked over time to generate motion statistics for each cell using autoregressive motion algorithm (max distance 1μm, max gap size 2). Imaris output file "Position. csv" was further used to calculate the characteristic of each track (track duration, track length, track displacement, track maximum speed, mean track velocity) and to filter tracks using dedicated PYTHON Script available at GitHub (https://github. com/mawelti/ RSV-RNP-TrackAnalysis).
Acknowledgments We thank  Marie Galloux ,  Jean-Francois Ele  ´oue ¨t,  Nadia Naffakh  and  Cedric Delevoye  for sharing protocols and reagents, and for helpful discussions. We are grateful to  Nathalie Sauvonnet  for Rab11 plasmids and helpful discussions. We thank  Jennifer Risso-Ballester , Cedric Diot and  Sabine Blouquit-Laye  for insightful discussions and critical reading of the manuscript. We thank  Aude Jobart-Malfait  and Cymages platform for access to the Leica SP8 microscope and Olympus  FV3000  inverted confocal microscope, which was supported by grants from the  region Ile-de-France. We also acknowledge the  ImagoSeine core facility  of the  Institut Jacques Monod  and thank  Xavier Baudin  for support for spinning disk imaging.
Hyrum's law states a common observation in the software industry: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody". Meanwhile, recent research results seem to contradict this observation when they state that "for most APIs there is a small number of features that are actually used". We investigate this seeming paradox between the observations in industry and the research literature, with a large scale empirical study of client API relationships in one single ecosystem: Maven central. We study the 94 most popular libraries in Maven Central, as well as the 829,410 client artifacts that declare a dependency to these libraries and that are available in Maven Central, summing up to 2.
To support all clients, developers need to invest effort that is proportional to the total size of APIs. Yet, accepting to support only the majority of clients, which use the core API types, allows for significant effort savings. Considering the typical API maintenance task of migration  [5] , the migration of the 6317 clients of library gson:2. 3. 1 to jackson-databind requires supporting migration rules for 162 API types, but this number of types can be decreased to 20 (12%) if only 5669 (90%) clients are to be supported. Our work explores this spectrum of dependency relations, focusing on the Maven Central ecosystem. This choice is motivated by two factors: it is the most popular repository to distribute code artifacts that run on the Java Virtual Machine; it contains both APIs and clients that depend on these APIs.
The Maven Dependency Graph  [7]  provides a snapshot of Maven Central as of September 6, 2018. From this graph, we determine the 94 most used libraries and all the client artifacts in the repository, that depend on any version of one of these libraries. This forms the dataset for our study: 5,225 libraries (union of all versions of the 94 most popular libraries), 901,876 clients, summing up to 2,169,273 dependencies. We study how Maven artifacts depend on each other, around three dimensions. First, we analyze the client-side, to determine to what extent each declared dependency is actually used at least once in their code, i. e. , there is at least one API member used by the client's code. Second, we analyze the API side of dependencies to determine how different API types are used by the clients.
The size of this fraction varies from one API to another, as library API purpose, size, and usage differ. Our dataset is large enough to include some of the most extreme cases that occur in the extraordinary practice of software development, e. g. , a very small API with only annotations, some giant APIs which clients use in a very focused way, or even some artifacts that are massively used even if they have no public types. The contributions of this paper are as follows: • A systematic large-scale analysis of of 2,169,273 Maven client -API relations. • A public dataset of 5,225 libraries (union of all versions of the 94 most popular libraries) and 901,876 clients drawn from Maven Central  [17]  along with an open reproduction package  [28]. This large dataset can fuel the ongoing research initiatives in the areas of dependency management and release engineering.