dataesr/scientific-paragraphs-categorization huggingface dataset:
Cardinality The cardinality of a set in mathematics, is the number of elements of the set. Here, we define the cardinality for a given voxel as the number of unique elements over the ensemble of models for the corresponding voxel  (Lindsay et al. , 2012). Computed for all voxels, it provides a cardinality voxet of the same dimensions as the model voxets. It assumes that all voxets of the model ensemble have the same dimensions. By definition, this indicator can be computed on discrete or categorical property fields. For continuous property fields, we propose to use the range between the minimum and maximum value, the standard deviation. Eventually, these continuous indicators can be normalised over the voxet and then averaged or weighted to provide another indicator. Figure  6  shows a cardinality voxet computed from an ensemble of lithocode voxets as well as the range, standard deviation and their normalised average from an ensemble of density voxets.
Multiple-point histogram dissimilarity Multiple-point histograms (MPH,  Boisvert et al. , 2010)  are based on pattern recognition and have been primarily used in the field of geostatistics  (Guardiano and Srivastava, 1993)  to quantify the quality of multiple-point statistics simulations. Patterns are delimited by a search window whose dimensionality matches the one of the dataset. One can count unique patterns; however, the number of unique patterns might be relatively important, in particular for continuous property fields. In that case, it might require that the analysis be restrained to the most frequent patterns  (Meerschman et al. , 2013 ). An alternative is to base the analysis on pattern cluster representatives (see Fig. 11 ). Here, using an l 2 norm distance between patterns and k-means clustering  (Pedregosa et al.
, 2011, scikit-learn implementation) , we classify all patterns into N c = 10 clusters. Each cluster centroid or barycentre defines its representative. In addition, voxets can be easily upscaled, which allows MPH analysis of potentially large scale features with a small search window at a high level of upscaling. Note that at a given level l of upscaling, the size of the dataset is divided by 2 l along each dimension. Here, to avoid property values smoothing, we perform a stochastic upscaling, i. e. in a 2D case, the upscaled value of a 2×2 subset of pixels is achieved  by a uniform random draw among the values of the 4 pixels. Cluster pattern identification is performed at the initial resolution level (l = 0) and at all possible upscaled levels. For a given upscaling level, once k-means clustering of patterns has been performed on two voxets or datasets, distances between cluster representatives of two images can be computed d(C i 1 , C j 2 ) = N w w=1 C i 1 (w) -C j 2 (w) 2 1 2 , where C i 1 is the ith cluster representative for voxet 1, C j 2 is the j th cluster representative for voxet 2 and w denotes the index of the window search elements.
The cluster representatives between two datasets are paired by similarity (smallest distance), and reordered such that ∀i, 1 ≤ i ≤ N c , and C i 1 is paired with C i 2. To account for cluster size differences, the distance between paired cluster representative are weighted by proportion dissimilarities. It results in an MPH cluster-based distance between voxets or datasets 1 & 2 defined as in Eq. (  5 ). d MPH (Voxet 1 , Voxet 2 ) = N c i=1 1 N c 1 + d(C i 1 , C i 2 ) × 1 + |p i 1 -p i 2 | p i 1 + p i 2 -1 , (5) where p i 1 and p i 2 are the proportions of the paired clusters C i 1 and C i 2 with respect to voxets 1 & 2, respectively. One advantage of selecting cluster representatives independently between two voxets is to lower computing requirements over large ensembles of voxets, performing the analysis for N v voxets instead of N v (N v -1) 2 pairs.
Wavelet decomposition coefficient dissimilarity Wavelet decomposition is a way to compress images. Each level of decomposition produces a series of coefficients. If computed for images to be compared, the dissimilarity of histograms of coefficients can be computed with the Jensen-Shannon divergence (Eq. 2). Here, wavelet decomposition (Fig. 12 ) is performed with the PyWavelets Python package  (Lee et al. , 2019 ) at all possible levels of decomposition and using the "Haar" wavelet. Other wavelets could be used; however, tests have shown that such dissimilarity measures are not very sensitive to the choice of the wavelet  (Pirot et al. , 2019). Then a wavelet-based dissimilarity measure between two voxet can be computed as in Eq. (  6 ) by summing the Jensen-Shannon divergences computed for all pairs of approximation and decomposition coefficients at all possible levels: d WVT (Voxet 1 , Voxet 2 ) = i,j JSD(C i,j 1 ||C i,j 2 ) i,j 1 , (6) where C i,j 1 and C i,j 2 denote the distributions of the ith coefficients at upscaling level j for Voxet 1 and Voxet 2 , respectively.
Results: indicator comparison Local measures of uncertainty (see Figs. 14  and 15 ) and global indicators (see Figs. 17 and 18) have been computed for 2D, 3D, categorical and continuous variable voxets (lithocode, scalar field) for an ensemble of 30 model sets. We also provide a comparison of the required computing time for the different indicators and highlight the contributing factors or parameters (see Table  2 ). One can see from Fig. 14  that Shannon's entropy and cardinality computed from lithocode voxets can have a good correlation. However, the following equivalent indicators: continuous entropy, averaged normalised range and standard deviation computed from scalar field voxets, (Fig. 15 ) have very little in common. Indeed, the standard deviation or the range of values is sensitive to extremely different values, while the continuous entropy is sensitive to the proportion of categories of values.
A third reason is due to the fact that assumptions, such as choices in geological interpretations made during the modelling process, are not always tracked and when they are, they are often "forgotten" at the next stage of the modelling workflow  (Jessell et al. , 2018). When these assumptions or justifications are recorded, they are described in metadata or in distinct reports. Consequently, conceptual uncertainty, which describes alternative yet plausible stratigraphy, tectonic and geodynamic settings, is also ignored. Another possible reason is that uncertainty is ignored out of convenience  (Ferré, 2017)  or by ignorance, lack of knowledge or education about the importance of uncertainty quantification. However, the formulation of the collected answers suggests that this is not the case for the surveyed practitioners, who tend to acknowledge the importance and need for tools or algorithms to integrate uncertainty quantification in their modelling workflow.
Conclusions The survey clearly shows that practitioners acknowledge the importance of uncertainty quantification; the majority recognise that they do not perform uncertainty quantification at all and all would like to do better. From this survey we have identified four main factors preventing practitioners from performing uncertainty quantification: lack of data uncertainty quantification, computing requirement to generate one model, poor tracking of assumptions and interpretations and relative complexity of uncertainty quantification. Here, as a first response, we have provided the geomodelling community with loopUI-0. 1, an open-source Python package to compute local and global uncertainty indicators. Then, to increase the confidence in predictions from 3D geological model, efforts should be made to explore conceptual uncer-tainty  (Laurent and Grose, 2020)  as well as towards the implementation of systematic geological data uncertainty quantification, and the exploration of parametric and epistemic uncertainty  (Pirot et al.
, 2020). It should be performed appropriately at all scales, across all geoscientific methods, such as the extraction of additional lithological data from drill hole databases  (Joshi et al. , 2021). To encourage uncertainty propagation among practitioners, accessible and compatible algorithms should be offered (1) to automatically extract geological data from open databases  (Jessell et al. , 2021)  and (2) to quickly generate plausible geological models from a given dataset  (Grose et al. , 2021)  in interaction with geophysical data integration  (Giraud et al. , 2021)  and at an appropriate resolution  (Scalzo et al. , 2021). This special issue  (Ailleres, 2020)  already provides elements of an answer to these problems and is expected to host future advances on these topics.
Acknowledgements. This work is supported by the  ARC -funded Loop: Enabling Stochastic 3D Geological Modelling consortia ( LP170100985 ) and DECRA (DE190100431) and by the  Mineral Exploration Cooperative Research Centre  whose activities are funded by the  Australian Government's Cooperative Research Centre Programme. This is MinEx  CRC Document 2021/5. Financial support. This research has been supported by the  Australian Research Council  (grant nos. LP170100985  and  DE190100431 ) and by the  Mineral Exploration Cooperative Research Centre. Review statement. This paper was edited by  Thomas Poulet  and reviewed by three anonymous referees.
Advancing knowledge and understanding about performed music is hampered by a lack of annotation data for music expressivity. To enable large-scale collection of annotations and explorations of performed music, the authors have created a workflow that is enabled by CosmoNote, a Web-based citizen science tool for annotating musical structures created by the performer and experienced by the listener during expressive piano performances. To enable annotation tasks with CosmoNote, annotators can listen to the recorded performances and view synchronized music visualization layers including the audio waveform, recorded notes, extracted audio features such as loudness and tempo, and score features such as harmonic tension. Annotators have the ability to zoom into specific parts of a performance and see visuals and listen to the audio from just that part.
A previous CosmoNote paper  [7]  discussed the basic design of the software. This paper goes beyond a description of the software to describe the Cos-moNote workflow in detail while including more detailed descriptions of the software functionality and new features and significant changes since the publication of the previous paper. The next section (SEC. 1) describes related work and approaches to music annotation. The next four sections are organized according to the CosmoNote workflow. First, performance data are obtained for inclusion in CosmoNote (SEC. 2). Second, the performance data are presented to annotators as both audio and visuals (SEC. 3). Third, based on the performance data, annotators create their annotations (SEC. 4). Fourth, the annotations are collected and analyzed as shown in two pilot studies (SEC.
Non-Web-Based Tzanetakis and Cook  [8]  wanted to determine whether a computer-assisted human temporal segmentation annotation task benefited from automated segmentation. As part of a pilot user study, they presented users with an annotation application, based on their MARSYAS software framework  [9] , and asked them to mark temporal boundaries based on what they called sound "texture" or changes in instrument or speaker, etc. Similarly, Amatriain et al. developed, using their CLAM audio framework  [10] , the CLAM Annotator  [11] , a combination human-computer annotation application with which users could edit descriptors that were created automatically. Notess and Swan  [12]  developed Timeliner, a humanbased annotation application, to allow users of a digital music library to create annotations for audio files in the library.
The annotation tracks contained region markers and labels for regions, and, like the MUCOSA annotation system, the waveform visualization and the annotations were stacked vertically. Cannam et al. [17]  developed Sonic Visualiser to be "the first program you reach for when want to study a musical recording rather than simply listen to it. " In addition to featuring different visualization layers like waveforms, spectrograms, and notes, Sonic Visualiser allowed annotations to be placed directly over the visualization layers, saving screen space. Of all of the non-Web tools that were examined, Sonic Visualiser had the set of features that matched most closely with the overall workflow.
Recording the Performances For recordings made by the CosmoNote team, the authors use a reproducing piano, the Bösendorfer Enspire  [25] , that is capable of recording performances as MIDI data, producing high-quality acoustic sounds, and enabling fine control of musical expression. During the recording process, the MIDI data are streamed from the piano to the computer simultaneously with the audio, recorded via microphones, ensuring proper synchronization. Fig. 1  shows, via Cos-moNote, a performance of Christian Petzold's Minuet in G minor (originally attributed to J. S. Bach because of its inclusion in Bach's Little Notebook for Anna Magdalena Bach). The performance, which was by co-author Elaine Chew and recorded on the Bösendorfer piano, will be, unless otherwise noted, used throughout the remainder of the article to illustrate the different aspects of CosmoNote.
Preparing the Audio, Note, and Pedal Data Audio files, whether recorded by the CosmoNote team or obtained from another source, start as uncompressed WAV or AIFF. To make the audio faster to download, the audio files were initially compressed using both FLAC  [26]  and OPUS  [27]. FLAC files proved to be quite large for fast downloading, and OPUS was not completely supported by all of the browsers tested. In the end, the authors decided to use MP3 for compressed audio because it provided a good trade-off between fast downloading and audio quality and it was supported by all of the browsers tested. Note data in CosmoNote come from recorded MIDI files, either recorded by the CosmoNote team with the recording piano or from existing recordings. In MIDI, individual notes are split into pairs of note-on and note-off events.
To visualize the notes in CosmoNote, each note needs to be a single event with a start and end time. To that end, a custom Python script that uses the Mido MIDI library  [28]  is used to convert the MIDI data to single-event note data. Pedal data from the sustain, soft, and sostenuto pedals are also taken from MIDI files using the same script. The pedal data from MIDI are a series of control change events rather than pairs on on-off events as with the note events. For recordings from CosmoNote's recording piano, the extent of pedal depression is recorded with an 8-bit resolution of 0-127. For certain pre-existing MIDI files (not recorded with CosmoNote's recording piano), the control change messages for the pedals are only on-off events because the extent of pedal depression was not recorded.
Computing Feature Data In CosmoNote, feature data are defined as the data computed from audio files, MIDI files, or the score for a given performance. Loudness data (in sones) are computed from the audio file, using a custom Python script ported from the MATLAB MA Toolbox  [29] , as a global representation of the perceived intensity of the notes. It corresponds roughly to velocity data shown for the notes, although the perceived loudness is influenced by the number of notes played, their pitches, and how quickly the key is depressed for individual notes as with velocity. Loudness data can be used to, for example, locate a group of notes highlighted by the performer to make a melody more salient than the contextual background or a note more prominent than its neighbors. Tempo is computed using timestamps of the onset of each beat-in which the beats are located by alignment to a MusicXML score using an alignment tool from Nakamura et al.
PRESENTING THE PERFORMANCES Next in the CosmoNote workflow, after the CosmoNote performance data are collected and stored, the data are presented to annotators as both audio and visuals via a client-side Web application. CosmoNote audio uses the Web Audio API  [37]  and CosmoNote visuals use D3  [38] , a highly-customizable, Scalable Vector Graphics-based  [39]  visualization and interaction library. CosmoNote clients get the performance data (as JSON) from the CouchDB server using PouchDB  [40]. Performances are presented to annotators either as whole pieces of music or fragments of pieces. In either case, all of the performances are grouped into collections, whereby collections can be based around a performer, composer, or some other theme. For example, the first sets of collections released in CosmoNote, starting in December 2021, were built around the 1955 recordings of Bach's Goldberg Variations by Glenn Gould and a collection of simple practice pieces for training new annotators.
Visualizing the Performances CosmoNote shows musical data in its main visual pane via waveforms, note and pedal data, and curves based on extracted feature data including loudness, tempo, and harmonic tension (all described in SEC. 2). Each type of visual data is a distinct layer in the overall visualization. With all of the data layers displayed at the same time, the visualization can become dense and difficult to read, so transparency is used to varying degrees in all of the layers. To further mitigate the problem of too much visual data, each information layer can be turned on and off individually. This also allows for a focus on particular data types as shown for different layers in Fig. 7. For all of the layers, the design of the visuals emphasizes general trends in each kind of data because annotators are tasked with annotating expressive structures in the performance rather than finding exact values for any given data type.
Audio Data The lowest layer for CosmoNote visuals is a basic waveform taken from the audio file data from a given recorded performance. To allow for efficient drawing of the waveform, especially with the zoom function, the amount of audio data is reduced down to match the pixel width of the main and zoom panes. When zoomed, the waveform behaves as expected, showing just the waveform from the selected time range. The waveform layer is shown in Fig. 7 (a).
Note and Pedal Data The note visual layer includes note data derived from MIDI recordings with the note value on the vertical axis (from lowest to highest note on the piano) and the length of each note in seconds on the horizontal (time) axis. Because the actual values of the notes played are not needed for the annotation task, the MIDI note value is not shown. However, because all of the performance data in CosmoNote come from piano recordings, a piano graphic is shown along the left vertical axis that allows annotators to loosely infer the values of the notes. The MIDI velocity, associated with approximate loudness, of each note is depicted via the note's transparency with more opaque notes being louder and more transparent notes being quieter. Note data are shown in Fig. 7(b). Sustain, soft, and sostenuto pedal data are taken from the MIDI recordings and shown as area curves.
Supplementary Data In CosmoNote, supplementary data are defined as data that are not directly computed from a recording of a performance or even the score but may still be related to the performance. Essentially any time-based data can be included as supplementary data, although those data are most useful if synchronized with the audio or note data. Supplementary data are presented as curves with customizable appearances and any number of curves can be added. For example, CosmoNote can incorporate related data such as physiological data from performers or listeners. Fig. 10  shows two electrocardiographic signals recorded during a piano performance with the red signal being the player and blue signal the listener.
ANALYZING THE ANNOTATIONS The last step in the CosmoNote workflow is the collection and analysis of the annotation data. The data are exported from the CosmoNote database with a custom Python script that extracts all of annotation data as JSON. Data for each annotation contain a pseudonymous annotator iden-tifier, the collection, the performance, the annotation type (boundary, region, comment, and group), a time (two times for regions), the boundary strength (for boundaries only), a label (if set), a creation timestamp, and an updated timestamp (if subsequently edited after creation). Additionally, note groups also have the MIDI note number and the start and end times for every note in the group. To evaluate how citizen scientists use CosmoNote for annotations tasks, two pilot studies were conducted as described in SEC.
Study Area and Data Collection Our study aimed at quantifying human activity in the French Mediterranean waters. We used the French maritime boundaries and exclusive economic zones (200NM, version 11) (Flanders Marine Institute, 2019) in the Mediterranean Sea, which are composed of the Gulf of Lion and the waters around the island of Corsica (Figure  1 ). We used satellite images collected by the two radar satellites of the European Space Agency Sentinel-1 Copernicus mission  (Copernicus, 2021). Sentinel-1A was launched in April 2014 while Sentinel-1B, an identical satellite, was launched in April 2016 onto the same orbital plane. Together they collect images from the earth surface by day or by night, without being affected by cloud coverage. This allowed us to have a complete dataset of synthetic aperture radar (SAR) images from early 2017 until late 2020.
In order to assess the impact of the Covid-19 pandemic, and particularly the lockdown put in place by the French government between March and May 2020  (Sanchez, 2021) , we collected all Sentinel-1A and 1B images each year from March to November starting 02/03/2017 to 28/11/2020. With these dates we were able to compare the lockdown period and the aftermath during the summer of 2020 to the three prior years. A total of 2 183 images weighing approximately 1. 7 GB each was downloaded from the Alaska Satellite Facility "SAR Search Vertex" interface (https:// asf. alaska. edu/). In addition, the JRC SUMO software (https:// github. com/ec-europa/sumo) produced a folder containing all detection information weighing approximately 1 GB, totaling around 6 TB of information. We were able to locally store the data, but the storage aspect rapidly becomes an issue with bigger scale studies.
SUMO Algorithm To perform ship detection on the SAR images, we used the Search for Unidentified Maritime Objects (SUMO) algorithm based on the pixel-based CFAR method  (Greidanus et al. , 2017a). After applying cross-polarization and co-polarization detection threshold adjustments  (Galdelli et al. , 2021) , SUMO applies a land mask and proposes different buffers to avoid coastal interference. In this study we used a 50-meter buffer integrated into the SUMO software based on OpenStreetMap (2017) to detect coastal activities while avoiding continental interference. The next steps of the object detection apply the CFAR approach by deriving a local detection threshold for all polarization channels. Then, nearby detected pixels are clustered together into a detected object and all detection attributes can be extracted (e.
g. , geographic location, length, significance). The SUMO algorithm can thus discriminate between real ship detections and false alarms based on the attributes of each object. This algorithm was developed with a user interface to run it and manually check every detection to test the performance of different parameters. The software can also be used in "automatic" mode and analyze a series of images that are specified through a configuration file in which all needed parameters for a SUMO analysis are entered as well  (Greidanus et al. , 2017b). In this case, we used a parametrization which minimizes false positives but allows for the detection of all ships with a length over 15 meters based on literature and field work  (Santamaria et al. , 2017). To focus on the coastal activities of fisheries and recreational boats, we removed the shipping lanes provided by the dataset of  Halpern et al.