dataesr/scientific-paragraphs-categorization huggingface dataset:
Most of the data used within the PlantCLEF challenge was collected and revised by the TelaBotanica network. Another source of data were contributions of the users of the Pl@ntNet application and the members of the TelaBotanica social network who validated many observations every year. The evaluation metric that was used from 2011 to 2015 was an extension of the mean reciprocal rank  (Voorhees et al, 1999) , classically used in information retrieval. The difference is that it is based on a two-stage averaging rather than a flat averaging such as: S = 1 U U ∑ u=1 1 P u P u ∑ p=1 1 r u,p (1) where U is the number of image authors within the test set, P u the number of individual plants observed by the u-th author (within the test set), r u,p is the rank of the correct species within the ranked list of species returned by the evaluated system (for the p-th observation of the u-th author).
e. the core building blocks of a CNN. A convolutional layer basically takes images as input and produces as output feature maps corresponding to different convolution kernels, i. e looking for different visual patterns. Looking at the impressive results achieved by CNN's in the 2015 edition of PlantCLEF there is absolutely no doubt that they are able to capture discriminant visual patterns of the plants in a much more effective way than previously engineered visual features. The editions of PlantCLEF 2016 and 2017 have also clearly confirmed the capacity of CNNs to take advantage of large noisy datasets. Indeed, in the 2017 edition, all networks trained solely on the noisy dataset (coming from web crawl) outperformed the same models trained on the trusted data (coming from the trusted Encyclopedia of Life website).
For the BirdCLEF challenge, it was decided to not consider the whole Xeno-Canto dataset but to rather focus on a specific region. The objective was to find a good trade-off between scalability and biodiversity coverage. A sufficient number of species had to be considered so as to evaluate the feasibility of a real-world biodiversity monitoring system. But on the other side, it was necessary to limit the volume of data to be processed by the participating research groups so as to mitigate computational challenges and data management. The chosen region of interest has been the Amazonian rain forest because it is one of the richest in the world in terms of biodiversity but also one of the most endangered. For the first edition of the challenge, in 2014, the evaluation dataset was restricted to the 500 species having the most records in an Amazonian area straddling Brazil and neighboring countries.
The geographical extent and the number of species were progressively increased over the years so as to reach 1000 species in 2015/2016, and 1500 in 2017. By nature, the Xeno-Canto data as well as the BirdCLEF subset has a massive class imbalance. For instance, the 2017 dataset contains 48,843 recordings in total, with a minimum of four recordings for Laniocera rufescens and a maximum of 160 recordings for Henicorhina leucophrys. A comprehensive overview of the data shared 11  over the years is provided in Fig. 2. Each year, selected Xeno-canto recordings were split in two parts: 2/3 of the data was shared as training data so as to allow participants to train and optimize their system, and the other 1/3 of the recordings were kept as official test samples and shared to the participants a few weeks after the training set.
The set of species audible in the recording was identified in the meta-data but the vocalizing specimens were not localized in time. Thus, to allow a more accurate evaluation, it was decided to introduce new time-coded soundscapes within the BirdCLEF 2017 challenge. In total, 6. 5 hours of recordings were collected in the Amazonian forests and were manually annotated by two experts including a native of the Amazon forest, in the form of time-coded segments with associated species name. The evaluation protocol of BirdCLEF remained roughly the same during the 4 years it ran. Participants were asked to run their system so as to identify all the actively vocalizing bird species in each test recording (or in each test segment of 5 seconds for the soundscape). Up to 4 run files per participant could be submitted to allow evaluating different systems or system configurations (a run file is a formatted text file containing the species predictions for all test items).
It was exclusively due to the progress of the underlying methods and algorithms since the training set shared within BirdCLEF was exactly the same for these The second main outcome of BirdCLEF which can be observed in Fig. 3 , is that the soundscape task appears to be much more challenging than the classical task that we shall consider here as mono-species recordings. The identification performance actually remains pretty high for the mono-species recordings, even when considering all the species vocalizing in the background (yellow curve). On the contrary, the best mAP obtained on the 2016 soundscape data set is very low and did not improve between 2016 and 2017 (red curve). One of the main difficulties of such recordings is that many individual birds of several species are often singing simultaneously.
This profusion of overlapping sources causes the classical CNN models trained on the mono-species to fail. A good method on the soundscape task seemed to be the feature engineering based method of Lasseck et al. (Lasseck, 2015) , as the deep learning methods employed by the other participants in 2016 and 2017 were less efficient on the non time-coded soundscape 2016 test set. It is likely that the strength of the features engineering method is based on the extraction of very species-specific time-frequency features. This expert fine-grained approach may allow the extraction of features more robust to the species overlap problem. This verdict was the main reason why we introduced a new soundscape dataset in 2017  (Goëau et al, 2017) , in the form of time-coded segments of 5 seconds, each associated with the list of species vocalizing in this small segment.
This approach is unfortunately not realistic because of the cost to produce such content. Another more realistic perspective is to run data augmentation synthesizing new training data from the monospecies recordings themselves. The improvement of the quality of automatic bird activity detection (BAD) is also being taken in consideration as recently depicted in the BAD challenge  (Stowell et al, 2016). Finally, we are investigating a more advanced paradigm towards binaural source diarization and joint classification from stereo soundscape in future BirdCLEF sessions.
SeaCLEF: A 4-year Evaluation Of Sea Organisms Identification The need for automated methods for sea-related multimedia data is driven by the recent sprout of marine and ocean observation approaches (mainly imaging systems) and their employment for marine ecosystem analysis and biodiversity monitoring. Indeed in recent years we have witnessed an exponential growth of searelated multimedia data in the forms of images/videos/sounds, for disparate reasons ranging from fish biodiversity monitoring to marine resource managements to fishery to educational purposes. However, the analysis of such data is particularly expensive for human operators, thus limiting the impact that the technology may have in understanding and sustainably exploiting the sea/ocean. Within LifeCLEF, we investigated several highly demanding annotation scenarios including coral reef fish species monitoring, humpback whale individual recognition, salmon detection for water turbine monitoring and picture-based marine animal species recognition.
Despite these advances, the analysis of the produced data usually requires very time-consuming and expensive input by human observers. This is particularly true for ecological and fishery video data, which often requires laborious visual analysis. This analytic bottleneck greatly restricts the use of these otherwise powerful video technologies and demands effective methods for automatic content analysis to enable proactive provision of analytic informa-tion. The underwater video dataset used within LifeCLEF was derived from the Fish4Knowledge video repository, which contains about 700,000 10-minute video clips that were taken in the past five years to monitor Taiwan's coral reefs. The Taiwan area is particularly interesting for studying the marine ecosystem, as it holds one of the largest fish biodiversities of the world with more than 3,000 different fish species 12.
The dataset contains videos recorded from sunrise to sunset showing several phenomena, e. g. murky water, algae on camera lens, etc. , which make the identification task more complex. Each video has a resolution of either 320x240 or 640x480 with 5 to 8 fps. The data set used for the coral reef challenge of LifeCLEF 2015, LifeCLEF 2016 and LifeCLEF 2017 was a small annotated subset of the Fish4Knowledge repository  (Spampinato et al, 2016). It was composed of about 90 videos manually annotated for a list of 15 fish species. Each video was labelled and agreed by two expert annotators and the ground truth consists of a set of bounding boxes (one for each instance of the given fish species list) together with the fish species. In total the dataset contained more than 9000 annotations (bounding boxes + species) with a relatively high imbalance in the number of instances of fish species: for instance it contained 3165 instances of "Dascyllus Reticulates" and only 72 instances of "Zebrasoma Scopas".
There are presently 4 citizen sciences data collection sites (St. Marys, Majunga, Ifaty and Fort Dauphin) for which hotel-establishments and their customers have become sentinels for data collection. This method helps obtain more than 250 photo IDs each year, which effectively helps produce a photo catalogue of humpback whales reproducing on Malagasy coasts. From that data, we built an evaluation dataset of 2005 images of humpback whales that were collected between 2009 and 2014. After acquisition, each photograph was manually cropped so as to focus only on the caudal fin that is the most discriminant pattern for distinguishing one individual whale from another. Actually, the fins can be distinguished thanks to the natural markings and/or the scars that appear along the years. Automatically finding such matches in the whole dataset and rejecting the false alarms is difficult for three main reasons.
The first reason is that the number of individuals in the dataset is high, around 1, 200, so that the proportion of true matches is actually very low (around 0. 05% of the total number of potential matches). The second difficulty is that distinct individuals can be very similar at a first glance and that it is often difficult to distinguish them even for a human annotator. To discriminate the true matches from such false positives, it is required to detect very small and finegrained visual variations such as in a spot-the-difference game. The third difficulty is that all images have a similar water background of which the texture generates quantities of local mismatches. Concretely, the task consisted in detecting as many true matches as possible from the whole dataset, in a fully unsupervised way.
Acknowledgements: The organization of the PlantCLEF task is supported by the  French project FlorisTic  ( Tela Botanica ,  INRIA ,  CIRAD ,  INRA, IRD)  funded in the context of the national investment program PIA. The organization of the BirdCLEF task is supported by the  Xeno-Canto foundation for nature sounds as well as the French CNRS  project  SABIOD. ORG and EADM MADICS, and  FlorisTic. The annotations of some soundscapes were prepared with the late wonderful  Lucio Pando at Explorama Lodges , with the support of  Pam Bucur ,  Marie Trone  and  H. Glotin. The organization of the SeaCLEF task is supported by the  Ceta-mada NGO  and the  French  project  FlorisTic.
Our data suggest that western Nepal may be as seismically active as central Nepal (Fig. 4 ) and call for reconsideration of the notion of a seismic gap in western Nepal and northern India. Further testing the seismic-gap hypothesis will require studies involving longer time series and additional lacustrine paleoseismic investigations in this region. Future studies of other Himalayan lakes should allow correlating these events over a broader region. We also note the critical need for IPE calibration in this region in order to better quantify the most likely threshold intensity and magnitude to trigger lake turbidites. By using lake-sediment records as a paleo-seismometer for the first time in the Himalaya, this study complements the record obtained from paleoseismological and historical archives, demonstrating the importance of a holistic and diversified approach in paleoseismology to improve seismic hazard assessment.
48. Isotopic analysis of the graphite targets was performed using accelerator mass spectrometry (AMS) at the University of Tokyo, Japan  49. All ages were calibrated using the calibration curve for Northern Hemisphere terrestrial  14  C dates IntCal13  50. Age-depth models of cores RA14-SC05 and RA14-SC06 (Supplementary Fig. 2 ) were produced using Bacon 2. 2 software 51 after removal of the turbidites. The ages indicated in Fig. 2  and Supplementary Fig. 4  correspond to the base of each turbidite Modelling shaking intensity. In order to evaluate the potential impact of historical earthquakes on the Lake Rara sediment record, we used custom software built on top of the core Python library of the open-source seismic hazard engine OpenQuake  52  to compute shaking intensities based on the rupture parameters inferred for these earthquakes and on a set of intensity-prediction equations (IPEs).
1 , Supplementary Fig. 8 ). Instrumental seismicity in western Nepal mainly occurs around the MHT and is concentrated in two bands north and south of Lake Rara  54. These scenarios are modelled by selecting a fixed hypocentral location, which is the midpoint of ruptures that increase in size with the considered magnitude. In the Rara-MHT scenario, the hypocentre is directly below Lake Rara at a depth of 26 km  39. The DF and HF scenarios were modelled at locations corresponding to recent earthquakes, which occurred respectively 2008/12/08 (M W 5. 3), and 1980/ 06/22 (M W 5. 1). Their source parameters were taken from the Global Centroid Moment Tensor database  55, 56  , and we selected the nodal plane that agrees best with the corresponding faults and style of faulting  38, 57. The rupture parameters are summarized in Supplementary Table  6.
Acknowledgements This research was supported by  Marie Curie Initial Training Network iTECC  funded by the  EU REA  under the  FP7 implementation of the Marie Curie Action , grant agreement #  316966. Malin Kylander  ( Stockholm University ) provided access to the Itrax XRF core scanner and analytical support. Y. Miyairi ,  C. Sawada  and  T. Aze  assisted with the AMS measurements, which were funded by grants  JSPS KAKENHI JP15KK0151  and  JP17H1168  to  YY. Lorenzo Gemignani ,  Arnaud Watlet ,  Guillaume Lippinois  and  Rham Kumar  provided scientific and logistical support during and after the field campaign. Thomas Vandorpe  and  Maarten Van Daele  contributed to the CT analysis of the sediment cores. We thank  Thomas Lecocq ,  Tom Roland ,  Arnaud Watlet  and  Thomas Lemaire , as well as  Jamie Howarth  and an anonymous reviewer, for insightful comments on earlier drafts of this manuscript.
Popular formalism for parametric timed model checking include parametric timed automata (PTAs) [AHV93] and parametric time Petri nets  [TLR09]. Several tools support parameters, such as HyTech  [HHWT95]  (parametric hybrid automata), Romeo [LRST09] (parametric time Petri nets), IMITA-TOR  [AFKS12]  (parametric timed automata), PSyHCoS [ALS + 13] (parametric stateful timed CSP), or Symrob (robustness for timed automata) [San15]. In addition, several tools support the larger class of hybrid automata, such as PHAVer [Fre08] or SpaceEx [FLGD + 11] and, while not explicitly supporting parameters, can encode them. 2 Recently, a growing number of analyses and techniques were proposed to analyze parametric timed models (mainly PTAs) such as SMT-based techniques  [KP12] , integer hull abstractions [JLR15], corner-point abstractions [BBLS15], distributed verification [ACN15], NDFS-based synthesis [NPvdP18], machine learning  [AL17, LSGA17] , etc.
, that proposes a suite of benchmarks for hybrid systems [CSBM + 15]. However, it aims at analyzing hybrid systems, which are strictly more expressive than PTAs in theory, and incomparable in practice, as most hybrid systems do not feature timing parameters. In addition, that benchmark suite focuses only on reachability properties. Finally and most importantly, it does not focus on parameters, and the benchmarks are non-parametric. In contrast, our library focuses on parametric timed benchmarks, with various types of properties. Another interesting library is that by Hoxha, Abbas, and Fainekos [HAF14], that offers Matlab/Simulink models of automotive systems. However, it does not aim specifically at parametric timed model checking; two of our benchmarks originally partially come from the aforementioned library [HAF14].
Performance We present a selection of the library in Table  1. Not all benchmarks are given; in addition, most benchmarks come with several models and several properties, omitted here for space concern. We give from left to right the number of automata, of clocks, of parameters, of discrete variables, whether the model is an L/U-PTA, a U-PTA or a regular PTA, whether it features invariants and stopwatches, the kind of property, and a computation time on an Intel i7-7500U CPU @ 2. 70GHz with 8 GiB running Linux Mint 18. "T. O. " denotes time-out (after 300 s). "?" denotes unsolvable, because no such algorithm is implemented in existing tools. "HS" denotes time-out but human-solvable: e. g. , for Fischer, one knows the correctness constraint independently of the number of processes, but tools may fail to compute it.
⋆ This work is partially supported by the  ANR  national research program  PACS  ( ANR-14-CE28-0002 ) and by  ERATO HASUO Metamathematics for Systems Design Project  (No. JPMJER1603 ),  JST. 1 " Formal Methods for Timing Verification Challenge ", in the WATERS workshop: http://waters2015. inria. fr/.
Two monitoring options are available: "on-line" -with remote transfer of coordinate information, and "off-line" -information is read upon arrival at the dispatch center. A mobile module is installed on the vehicle, which consists of the following parts: a satellite receiver, storage and transmission modules for coordinate data. Data on specific indicators of the travel time and standing time can be collected in an active way, using a specially equipped vehicle for driving through the examined sections of the street and road network. A passive system can also be applied, in which specific indicators are calculated on the basis of navigational data collected from various vehicles participating in road traffic. Such data can be obtained from various sources, for example, from transportation company servers.
The Parse. com library was used to work with data for Parse. com. their visualization using the Google Maps geographic information system. The software system is designed to collect and analyze navigational data with further application in the assessment of traffic flow parameters on the basis of the two-fluid model of Herman-Prigogine  [16, 19, 20]. The data are collected using a large number of navigation modules installed on vehicles or smartphones of users. Data analysis is performed centrally on a high-performance computer, as it requires a considerable amount of calculations. The software package proposed for the solution of these tasks is implemented on the client-server architecture basis (Figures  1  and 2 ). Thus, data received from clients are transferred to the server end for further storage, as well as for processing and analysis of these data.
The client end is represented by two types of devicesa built-in navigation module integrated in the vehicle or a C O M M U N I C A T I O N S 2 / 2 0 1 9 V O L U M E 2 1 The use of this DBMS is rational within this work in view of the mobility of deployment and maintenance. In the future, when developing this system, it will be necessary to use more powerful DBMS, as the increased amount of data will lead to limitations of the existing solution. Thus, the hardware of the software package for assessing traffic flow parameters includes: • mobile device for collecting traffic information -a navigation module integrated in the vehicle or a mobile device with a GPS receiver (Android OS 4. 0 and higher) with the data transfer function enabled; • software products of transportation companies that provide navigation data in the CSV format; • automated workstation (AWS) of the operator that includes a personal computer running the Linux family operating system.
Next, it was necessary to calculate the parameters of the Herman-Prigogine model for each street. The parameters were calculated as follows: 1) two types of time were distinguished for each track: total travel time and standing time. In order to determine what state the vehicle was in -moving or standing, a speed limit of 5 km/h was adopted. If the speed was below this limit, the vehicle was considered standing, and if the speed was higher, the vehicle was considered moving; 2) after receiving the time of all tracks, the data was sent to the Herman-Prigogine model, after which the result was obtained. The result is a report file that contains the following information for each route: • route number -position number of the route in the list of streets or routes; • address -street, city, country for the current route; • starting point and end point -route boundary; The implementation of the client end is represented by a mobile software system for data collection.
This system was developed for the Android platform using the Java programming language. The user interface of the system was developed in accordance with the requirements of Google  [4]  for the interface of Android applications. The server end of the system is a web application. The web application is used for: • loading tracks from a file; • processing tracks according to the Herman-Prigogine model; • visualizing the obtained results with overlay on the Google Maps cartographic service  [21] ; • clustering sections of the street and road network according to the parameters of the Herman-Prigogine model. After preliminary processing and storage in the cloud service, the data are uploaded as a file for further analysis. The file in the CSV format is sent to the server end of the system. The server end of the system at this stage receives all tracks from the file, processes and verifies them.
The file in the CSV format containing tracks is sent to the input for analysis. After receiving all tracks for a particular street, the number of tracks, the standing time, and the average speed for this section of the road are determined. Every parameter is assigned a threshold value in advance, on the basis of which it is determined whether a track belongs to the group of unreliable tracks. After passing the verification, the data are sent to the Herman-Prigogine module for calculating parameters. The following algorithm is used to implement the Herman-Prigogine model. All tracks for a particular street are selected from the track database, and information on time and speed at each point in time associated with obtaining of the location is extracted from them. Information on time allows calculating the total travel time, and the speed allows determining how much of this time is spent standing.