dataesr/scientific-paragraphs-categorization huggingface dataset:
Model performance For each location of the challenge, models were trained on experimental data. Three types of data were used, to account for three possible use cases. These included stationary data where all sensor boxes were collocated, mobile measurements performed with one or two boxes at a time, and indoor data. Training and testing datasets were obtained by combining all these data types, and four models were obtained, one for each location. 7 ) performs best, and this is due to the increased amount of data, especially mobile, available for this location, since preliminary calibration tests were performed there. This demonstrates that the collection of large amounts of mobile data is crucial for boosting modelling abilities. The Antwerp dataset also contained larger amounts of mobile data, compared to the other two, so that a good performance was obtained as well (Figure  4 ).
Although datasets were more restricted for Kassel and London, indications were that models obtained were displaying good performance (see Figures  5  and 6 ). In general, calibration was successful at identifying general trends in the pollution levels. However, sharp and short peaks are not handled well by the model, and this is due to the lower sensitivity of the low-cost sensors and their delayed response. However, the performance obtained was enough for the purposes of our project, i. e. participatory mapping of pollution with multiple devices, for enhancing environmental awareness.
The AirProbe application The AirProbe application is freely available for the Android platform and can be installed from Google PlayStore. The main objective of the application is to acquire the data from the sensor box and to upload it to the EveryAware server. The application also allows the user to view/annotate data and can operate in three different modes: Live Track, Synchronization and Browsing. Without this application, the sensor box data cannot be accessed nor uploaded to the servers. In order to associate the data uploaded with a specific user, the application must be activated. This process links the application to an existing EveryAware account (which can be created inside the application itself or on the project web site).
Live Track mode This is the standard way to use AirProbe to collect air quality measurements. In this mode, the application will search for Bluetooth devices nearby and present the user with a list of found devices. EveryAware sensor boxes can be easily identified by their MAC suffix. Once the user has selected the sensor box, AirProbe starts displaying real time data collected by the sensor box, using the Bluetooth connection. In Live Track mode, the interface is composed of three different views accessible from their corresponding tabs (Figure  8 ): Map , where users can follow their own live track. The track is represented with different colours, depending on real-time black carbon levels. The user can also add annotations and share them on social networks (Facebook/Twitter), using the buttons at the top right corner.
The web platform The personalized air quality data is collected using the AirProbe module of the EveryAware platform which is a social information technology system used by people to communicate and share information. A characteristic of social information technologies is that they often involve very large amounts of data. In fact, the collection, storage, and analysis of different kinds of data within these systems is a crucial point and also an asset, e. g. , for companies like Facebook 1. As a consequence, in order to pave the way towards analyzing and even triggering behavioral shifts within large citizen populations, methods and techniques of acquiring and handling such data efficiently play a central role. The design of web-based infrastructures for this purpose has a great influence both on data quantity and quality, and hence also on the additional value which can be generated by analyzing the resulting datasets.
Broadly speaking, the relevant data in the context of the EveryAware project can be divided into two classes, namely 1. objective data, which stems mainly from sensors and captures information like sound intensity or air quality measurements (as analyzed in this work), and 2. subjective data, which comprises context information about the collected data including reactions of humans faced with particular environmental conditions. This comes from annotations that users attach to their measurements and is different from the subjective data we collected through the web game. The EveryAware platform has been explicitly designed to support subjective impressions in conjunction with sensor data acquisition by introducing an extendable data concept. A central server efficiently collects, analyzes and visualizes data sent from the arbitrary sources.
Statistics and visualizations In the case of AirProbe the visualized information is represented by several views of the data including a map with different information layers as well as several global and personal statistics. The OpenStreetMap-based 2  map view visualizes the collected data on a map which allows for an easy access to the data as well as for obtaining first insights. It provides a quantitative view by aggregating samples using clusters, grids, as well as a heatmap view in order to emphasize the covered area on a global and on a personal level (see Figure  10 ). Further statistics calculated by the AirProbe application include summaries like latest overall measurement activity or air quality averages. Also, personal user profiles are available which list measurement sessions giving short summaries regarding those sessions and enabling the user to view and replay them.
The influence of the different strategies regarding incentives are somewhat visible when analysing the data in the next section. The analysis presented in this work is based on a large amount of air quality measurements collected using the EveryAware sensorbox during four weeks (phases 2 and 3 of the AirProbe International Challenge) in four European cities. Table  7  summarises the number of data points and tags collected. This shows that in Europe there were over 6 million measurements performed, with Kassel displaying the largest activity. This could be due to the fact that volunteers in Kassel were offered significant monetary rewards for their activity, unlike the other locations. The number of annotations is largest in London, which is due to the instructions they received which underlined the need for subjective annotations.
In the plots presented here, the notches are so small that they are invisible. The plots also contain information about the size of the different datasets: the width of the boxes is proportional to the square root of the number of data points represented. In Kassel, volunteers were grouped into two groups in phase 3: the first group (g1 -three sensor boxes) had as a task to avoid highly polluted areas, while group g2 (6 sensor boxes) had no task other than using the sensor box where they wished. This in order to test whether any learning appears during measurements. For Antwerp, volunteers collected much higher BC levels in phase 3. In London, although  means are not larger, the maximum levels achieved are larger in phase 3. However, for these two cities data in phase 3 is rather limited compared to the other locations and to phase 2 (as shown by the width of the boxplots in Figure  19  and in Figure  15 ).
Group 2 (g2) had no specific goal. of PM, PM10 data were used for comparison with the measurements, due to higher availability, since they give a good indiction of the general level of pollution. In Figure  20 , we compare the daily average PM10 with average BC values obtained by our volunteers. In Antwerp, we also show official average BC levels. As the figure shows, BC levels measured by our volunteers are within a good range compared to PM10 values. Differences are comparable to those observed between reference BC and PM10 in Antwerp and may indicate some particular interest of the volunteers. Also, no increase between phases 2 and 3 is visible in PM10 data. Table  9  shows average PM10 for all locations for phases 2 and 3 (for Antwerp we also show BC). This confirms that no significant increase in overall pollution levels appeared from phase 2 to phase 3.
Acknowledgments This research has been supported by the  EveryAware  project funded by the  Future and Emerging Technologies program  ( IST-FET ) of the  European Commission  under the EU RD contract  IST-265432. The framework in which this study was developed was built and maintained by the  EveryAware consortium  with teams coming from several institutions across Europe, as listed in the author affiliations. We would like to thank all the volunteers at the four locations for participating in our test cases and enabling this research.
The CUORE experiment  [2, 3]  will search for 0νββ decay in 130 Te. CUORE itself is an array of 988 nat TeO 2 cryogenic bolometers that act as both the source and detector of the decay. The bolometers each weigh 750 g and are arranged into 19 towers of 52 crystals each. The total active mass is 741 kg, 206 kg of which is 130 Te (34. 2% natural abundance  [4]  in tellurium). The bolometers are operated at a temperature of about 10 mK which allows it to achieve an energy resolution of about 5 keV FWHM at the Q-value of the decay, 2528 keV  [5]. CUORE is currently under construction at Laboratory Nazionali del Gran Sasso (LNGS) in Italy, and is anticipated to start data taking in 2015. The technology of CUORE was proven by its predecessor, Cuoricino, a 40 kg tower of 62 bolometers that, with 19.
75 kg y of 130 Te exposure, set a lower limit to the decay half-life of 2. 8 • 10 24 y at 90% C. L. [6]. The analysis of that data, combined with Monte Carlo simulations, predicted that the sensitivity of CUORE would be limited by the background from α particles, which are generated by the natural radioactivity of the detector structure. To improve the background for CUORE, we implemented a set of strict protocols to limit the radioactive contamination of the detector materials during production and assembly. The first tower produced on the CUORE assembly line and operated separately from the other 19 towers is called CUORE-0  [7] , and has been taking data since March 2013. It is both an experiment which is expected to surpass the Cuoricino sensitivity in one year of live time, and also a technical prototype for CUORE.
Only certified tools and materials were used to attach thermistors and heaters to the crystals, assemble the crystals in the copper frame, and electrically connect the sensors to the readout cables  [13]. After construction, one thermistor and one heater had non working electrical connections. After the first cool down, we found that we had lost one more heater. In the two channels without heaters the drifts in thermal gain cannot be corrected in the offline data analysis processing, while the channel without a working thermistor is lost completely. CUORE-0 is operated in the same cryostat that previously hosted Cuoricino, in the Hall A of LNGS  [14]. CUORE-0 maintains an operating temperature of about 13-15 mK. At this temperature the typical signal amplitude is 10 -20 μK/MeV, with typical rise and decay times of 50 and 250 ms, respectively.
The analog read-out of the thermistor is performed using the same electronics as was used for Cuoricino  [15]. The signals are first amplified, filtered by 6-pole active Bessel filter  [16]  and then fed into an 18-bit National Instrument PXI analog-to-digital converter (ADC). The filter cutoff and the ADC sampling frequency are set to 12 Hz and 125 Hz, respectively. The data are then processed with Apollo, the data acquisition software developed for CUORE. The trigger is software generated on each bolometer. When it fires, one second of data preceding the trigger and the 4 seconds following are saved to disk. Additionally, the waveforms from the bolometers on the same floor and on the floors above and below the triggering bolometer are acquired, irrespective of their own trigger. This feature, not used in the analysis presented here, has been implemented to perform an accurate analysis of multi-site events.
A CUORE-0 "dataset" consists of 3-4 weeks of low background data taking preceded and followed by 2-3 days of calibration runs. To calibrate the detector, we insert two thoriated tungsten wires between the outer vacuum chamber of the cryostat and the external lead shield. During the offline analysis, we calibrate each channel separately over the energy range 511 to 2615 keV using the γ lines from the daughter nuclei of 232 Th.
Data analysis The raw data from the bolometers are processed offline with Diana, the analysis software suite developed for CUORE. The data reconstruction steps are the same as in the Cuoricino analysis  [6] , but we have improved the automation and robustness of many of the algorithms in anticipation of scaling to CUORE. The offline data production begins by evaluating the signal amplitude of each waveform using the matched filter described in  [17, 18]. Each channel has its own signal template, which is built from an average of 2615 keV γ events in the calibration runs, and its noise spectral density, which is built from randomly triggered events collected during the low background runs. The analysis software also uses the filtered waveforms to evaluate shape parameters on the rising and falling edges of each event, which are later used for event rejection.
The next step of the data production is to stabilize the gain drifts caused by thermal variations using the Joule heater attached to each crystal. The heater injects fixed amplitude pulses of about 3 MeV pulses every 300 s on each bolometer, which provide a measure of the gain dependence on temperature. After stabilizing all events in the dataset, we fit the calibration peaks to a 3 rd order polynomial with zero intercept for each channel, and apply this calibration function to all of the events in the low background data. The final step of the data production, is to evaluate the time coincidences between events on different crystals which are later used in the anti-coincident analysis. The first step in the analysis procedure is to filter the processed data through a series of quality cuts.
1 and 3. 4 MeV is due to 190 Pt contamination internal to the crystal. The continuum from 2. 7 to 3. 9 MeV, excluding the 190 Pt peak, is attributed to degraded α particles that deposit only a fraction of their energy in the crystal and the rest in inactive materials. This α continuum extends down into the ROI and was a significant background for Cuoricino, 0. 110 ± 0. 001 counts/(keV kg y). The α background in CUORE-0 is measured to be 0. 019 ± 0. 002 counts/(keV kg y). This factor of 6 reduction from Cuoricino proves the success of the radiopurity protocols that were implemented for the CUORE production and assembly. We show the energy spectrum in the 0νββ ROI in  Fig 3 (left). The false peak produced by the data salting is clearly evident. The fit consists of a flat background with two gaussians, one for the 2506 keV 60 Co sum peak and one for the 2528 keV 0νββ peak.
The Ingredible project framework To reach our goal we propose a framework composed of five modules: the Capture module retrieves data from tracking devices and generates a unified 15joints skeleton. Skeletons are sent to the Analysis module which tries to recognize the current gesture and its expressivity. The Decision module determines the agent's response depending on the user's behavior and the interaction scenario. The Synthesis module computes the final skeleton animation that is displayed by the Rendering module, implemented in Unity3D. The Ingredible project is still an ongoing project, and this demonstration focuses mainly on the Analysis and Decision modules. The Analysis module collects, in a continuous flow, data from devices enabling skeletal tracking of a single person. The recognition process is based on skeleton analysis and motion features computation.
Skeleton joints are used to compute features which are stored in a reference database. A Principal Component Analysis (PCA) is computed to select the most important features, useful in discriminating gestures. During real-time recognition, using distance measures, real-time selected features are compared to the reference database to find the most similar gesture. More details can be found in  [4]. The objective of the Decision module, shown in Fig. 1 (a), is to generate an appropriate action of the virtual agent according to the user's non verbal behavior. An action can be an animation to play, a joint to move, or an expressivity to change (for example, moving faster). The decision is based on the level of coupling between the human and the virtual agent, which shows mutual influence, engagement, and willing to keep on interacting together.
Modern scientific experiments often involve multiple storage and computing platforms, software tools, and analysis scripts. The resulting heterogeneous environments make data management operations challenging; the significant number of events and the absence of data integration makes it difficult to track data provenance, manage sophisticated analysis processes, and recover from unexpected situations. Current approaches often require costly human intervention and are inherently error prone. The difficulties inherent in managing and manipulating such large and highly distributed datasets also limits automated sharing and collaboration. We study a real world e-Science application involving terabytes of data, using three different analysis and storage platforms, and a number of applications and analysis processes.
We study a materials science experiment at a large scale research facility as a representative e-Science use case, in which datasets are handled by several systems and software. We propose a smart surveillance framework that allows users to monitor data life cycle progress in real-time. This framework offers a unique combination of features: ability to monitor heterogeneous systems and distributed infrastructures, automated data tagging and ability to convey tags across systems, data filtering, and rule-based programming. We demonstrate the benefit of this data surveillance system by implementing a prototype based on the Active Data life cycle model  [1]. Our contributions include: 1) modeling the entire end to end data life cycle in an experiment, with the ability to expose what happens inside the individual systems; 2) extensions to the Active Data model to support data tagging based on Petri Net colors and guarded transition-based code execution; and 3) a data surveillance framework that leverages the life cycle model and allows users to implement sophisticated features at a high level.
A. APS Experiment The materials science experiment focuses on analyzing different sample materials using synchrotron x-rays. Scientists apply techniques such as high-energy diffraction microscopy (HEDM) and combined high-energy small-and wide-angle x-ray scattering (HE-SAXS/WAXS) to characterize different samples. The end-to-end experiment process undertaken by the scientists, shown in Fig. 1 , is both compute and data intensive, using thousands of cores to enable near-real-time analysis of data as it is acquired. Experiments at the beamline currently generate 3-5TB of data per week. Data is obtained from a beamline detector with a direct connection to an acquisition machine with modest storage and compute resources. As data is acquired it is moved to a shared cluster with greater storage capacity.
After transfer to the shared cluster data is processed with several data reduction and aggregation scripts. Files related to a particular experiment or sample are grouped into "datasets". The data is then cataloged in the Globus Catalog. Here automated python-based parsers are used to extract metadata related to the user, experiment and sample. Knowledge of the Nexus HDF format is used to extract Fig. 1 : The Advanced Photon Source experiment structured metadata from the file. The catalog associates various different raw and derived data, scripts, and metadata into self-contained datasets. Following cataloging, data is moved to large scale compute resources. Here a parallel Swift-based analysis pipeline is run to fit a crystal structure to the observed image. This analysis is computationally intensive and involves iterative processing of many rows using a C function on each parameter and a reduction phase to merge the results into a single output.
B. Experiment Tools While not a complete list of tools used in this experiment, the following are the core tools that act upon data. Globus provides high performance, secure, third party data transfer and synchronization. It is operated as Software-as-a-Service and is accessible via a web interface or REST API. Globus Catalog is a service that enables the creation and management of user-defined "catalogs" containing datasets and references to associated data and metadata. Within a catalog, users can create datasets, associate files and directories, and specify user-defined metadata. Swift is a parallel scripting language designed for composing applications into workflows that can be executed in parallel and distributed environments. Swift is implicitly parallel: users do not explicitly program their workflows to be parallel or to handle synchronization, file transfer, or execution locations.
C. Active Data Active Data is a system that aims to make distributed data management more efficient. It offers a formal and graphical model to represent the life cycle of distributed data in terms of data state and state transitions, from creation to deletion. This model is able to represent what individual systems do with data internally and to compose such models that represent movement from one system to another, offering a high-level and flat view of large applications, while also abstracting hardware and software complexity. Based on this application model, Active Data offers an API and a transition-based programming model. Conceptually, data management systems report on their internal activity, and users specify actions to be conducted when specific data state transitions are reported, making it easy to implement decisions and optimizations.
III. OBJECTIVES While the APS use case currently satisfies the needs of its users, there is potential for significant inefficiency, unreported failures and even errors due to the complexity of dealing with several terabytes of data and a number of different tools and systems. Here we present three useful features desired by scientists that appear simple at small scales and when executed on a single machine but present significant challenges with large distributed datasets. 1) Progress Monitoring: Monitoring is not limited to estimating completion time, but also: i) receiving a single relevant notification when several related events occurred in different systems; ii) quickly noticing that an operation failed within the mass of operations that completed normally; iii) identifying steps that take longer to run than usual, backtracking the chain of causality, and fixing the problem at runtime.
A. Data surveillance framework The data surveillance framework provides several unique features: it is able to track files, datasets, and elements related to data (such as file transfers and metadata); it receives events from different systems and integrates the identifiers of data and related elements in a single global namespace that allows advanced querying and filtering; data replicas and their current state are exposed as tokens with a unified identifier used across systems. Tokens provide a model for linking together related data in different systems; finally it allows users to be notified of the progress of their data and to automatically run custom code at many operational stages of the life cycle.