Ten Ti-6Al-4V samples were mounted on a multi-sample stage for EBSD on a Thermo Fisher Apreo SEM equipped with an Oxford Instruments' Symmetry 2 detector at the University of Manchester.

In project multi-sample_1, AZtec reported a saving error when scanning the fifth sample and stopped with 5646 frames saved (.oip~4GB). It is able to montage and export the maps, but any edit on the .oip file cannot be saved.

In project multi-sample_2, we restarted the scan on the rest of the samples and completed with 5601 frames. The .oip is 3.97GB, which almost reaches the size limit. No error was reported during the scanning, and the .oip file is still editable.

This is the raw data used to generate the figures of the paper. The code generating the figures is in a separate GitHub repository: https://github.com/sami-b95/predicting_qaoa_parameters_data

This record serves an an index to the other dataset releases that are part of the paper "Perils of Zero Interaction Security in the Internet of Things" by Mikhail Fomichev, Max Maass, Lars Almon, Alejandro Molina, Matthias Hollick, in Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, vol. 3, Issue 1.

We have chosen to split the dataset into several parts to meet Zenodo size requirements and make it easier to find specific pieces of data. In total, the following datasets exist:

1. Raw data
   These datasets contain raw data, as collected directly from the devices doing the recording. It includes readings from several different sensors, as well as observed WiFi and BLE signals with their signal strength, and in one case, audio recordings. This raw data can be used to repeat our own experiments, or to apply different schemes to it to have a baseline for comparisons. Four datasets exist, mapped to the three scenarios discussed in the paper:
   1. Car Scenario
   2. Office Scenario
   3. Mobile Scenario + audio data in separate deposit (with access control)
2. Processed Data
   The processed data is generated from the raw data using the processing code (which can be found in the code repository). The resulting data contains computed features from the five papers under investigation plus derived machine learning datasets, and can be used to see in detail how the schemes behave in specific situations. These datasets tend to be fairly large. Three datasets exist:
   1. Car Scenario
   2. Office Scenario
   3. Mobile Scenario
3. Result Data
   Finally, the result datasets contain the results of the evaluation (i.e., the computed error rates and generated plots, plus associated caches). The code used to derive these results can once again be found in the source code repository. Here, five datasets exist, one for each investigated paper:
   1. Karapanos et al.
   2. Schürmann and Sigg
   3. Miettinen et al.
   4. Truong et al.
   5. Shrestha et al.

Metadata of a Large Sonar and Stereo Camera Dataset Suitable for Sonar-to-RGB Image Translation

Introduction

This is a set of metadata describing a large dataset of synchronized sonar and stereo camera recordings, that were captured between August 2021 and September 2023 during the project DeeperSense (https://robotik.dfki-bremen.de/en/research/projects/deepersense/), as training data for Sonar-to-RGB image translation. Parts of the sensor data have been published (https://zenodo.org/records/7728089, https://zenodo.org/records/10220989). Due to the size of the sensor data corpus, it is currently impractical to make the entire corpus accessible online. Instead, this metadatabase serves as a relatively compact representation, allowing interested researchers to inspect the data, and select relevant portions for their particular use case, which will be made available on demand. This is an effort to comply with the FAIR principle A2 (https://www.go-fair.org/fair-principles/) that metadata shall be accessible, even when the base data is not immediately.

Locations and sensors

The sensor data was captured at four different locations, including one laboratory (Maritime Exploration Hall at DFKI RIC Bremen) and three field locations (Chalk Lake Hemmoor, Tank Wash Basin Neu-Ulm, Lake Starnberg). At all locations, a ZED camera and a Blueprint Oculus M1200d sonar were used. Additionally, a SeaVision camera was used at the Maritime Exploration Hall at DFKI RIC Bremen and at the Chalk Lake Hemmoor. The examples/ directory holds a typical output image for each sensor at each available location.

Data volume per session

Six data collection sessions were conducted. The table below presents an overview of the amount of data captured in each session:

Session dates Location Number of datasets Total duration of datasets [h] Total logfile size [GB] Number of images Total image size [GB]

2021-08-09 - 2021-08-12 Maritime Exploration Hall at DFKI RIC Bremen 52 10.8 28.8 389’047 88.1

2022-02-07 - 2022-02-08 Maritime Exploration Hall at DFKI RIC Bremen 35 4.4 54.1 629’626 62.3

2022-04-26 - 2022-04-28 Chalk Lake Hemmoor 52 8.1 133.6 1’114’281 97.8

2022-06-28 - 2022-06-29 Tank Wash Basin Neu-Ulm 42 6.7 144.2 824’969 26.9

2023-04-26 - 2023-04-27 Maritime Exploration Hall at DFKI RIC Bremen 55 7.4 141.9 739’613 9.6

2023-09-01 - 2023-09-02 Lake Starnberg 19 2.9 40.1 217’385 2.3

255 40.3 542.7 3’914’921 287.0

Data and metadata structure

Sensor data corpus

The sensor data corpus comprises two processing stages:

raw data streams stored in ROS bagfiles (aka logfiles),

camera and sonar images (aka datafiles) extracted from the logfiles.

The files are stored in a file tree hierarchy which groups them by session, dataset, and modality:

${session_key}/ ${dataset_key}/ ${logfile_name} ${modality_key}/ ${datafile_name}

A typical logfile path has this form:

2023-09_starnberg_lake/ 2023-09-02-15-06_hydraulic_drill/ stereo_camera-zed-2023-09-02-15-06-07.bag

A typical datafile path has this form:

2023-09_starnberg_lake/ 2023-09-02-15-06_hydraulic_drill/ zed_right/ 1693660038_368077993.jpg

All directory and file names, and their particles, are designed to serve as identifiers in the metadatabase. Their formatting, as well as the definitions of all terms, are documented in the file entities.json.

Metadatabase

The metadatabase is provided in two equivalent forms:

as a standalone SQLite (https://www.sqlite.org/index.html) database file metadata.sqlite for users familiar with SQLite,

as a collection of CSV files in the csv/ directory for users who prefer other tools.

The database file has been generated from the CSV files, so each database table holds the same information as the corresponding CSV file. In addition, the metadatabase contains a series of convenience views that facilitate access to certain aggregate information.

An entity relationship diagram of the metadatabase tables is stored in the file entity_relationship_diagram.png. Each entity, its attributes, and relations are documented in detail in the file entities.json

Some general design remarks:

For convenience, timestamps are always given in both a human-readable form (ISO 8601 formatted datetime strings with explicit local time zone), and as seconds since the UNIX epoch.

In practice, each logfile always contains a single stream, and each stream is stored always in a single logfile. Per database schema however, the entities stream and logfile are modeled separately, with a “many-streams-to-one-logfile” relationship. This design was chosen to be compatible with, and open for, data collections where a single logfile contains multiple streams.

A modality is not an attribute of a sensor alone, but of a datafile: Because a sensor is an attribute of a stream, and a single stream may be the source of multiple modalities (e.g. RGB vs. grayscale images from the same camera, or cartesian vs. polar projection of the same sonar output). Conversely, the same modality may originate from different sensors.

As a usage example, the data volume per session which is tabulated at the top of this document, can be extracted from the metadatabase with the following SQL query:

SELECT PRINTF( '%s - %s', SUBSTR(session_start, 1, 10), SUBSTR(session_end, 1, 10)) AS 'Session dates', location_name_english AS Location, number_of_datasets AS 'Number of datasets', total_duration_of_datasets_h AS 'Total duration of datasets [h]', total_logfile_size_gb AS 'Total logfile size [GB]', number_of_images AS 'Number of images', total_image_size_gb AS 'Total image size [GB]' FROM location JOIN session USING (location_id) JOIN ( SELECT session_id, COUNT(dataset_id) AS number_of_datasets, ROUND( SUM(dataset_duration) / 3600, 1) AS total_duration_of_datasets_h, ROUND( SUM(total_logfile_size) / 10e9, 1) AS total_logfile_size_gb FROM location JOIN session USING (location_id) JOIN dataset USING (session_id) JOIN view_dataset_total_logfile_size USING (dataset_id) GROUP BY session_id ) USING (session_id) JOIN ( SELECT session_id, COUNT(datafile_id) AS number_of_images, ROUND(SUM(datafile_size) / 10e9, 1) AS total_image_size_gb FROM session JOIN dataset USING (session_id) JOIN stream USING (dataset_id) JOIN datafile USING (stream_id) GROUP BY session_id ) USING (session_id) ORDER BY session_id;

The dataset contains four sheets: 1) niche width, 2) mean prey size, 3) range, max, min prey size, and 4) SD prey size.

In all sheets, the "species" stands for spider species. The "Body_size" stands for body length of spiders (mm). The "ph1-ph20" stands for the codes to build phylogenetic trees of the spider species.

In the sheet niche width, the "richness_est", "shannon_est", and "simpson_est" stand for the estimated measures of diet breadth, namely: diet richness, Shannon index of diversity, and Simpson index of equitability.

In the sheet mean prey size, the "Mean" stands for the mean body length of prey (mm) utilized by the spider species.

In the sheet range, max, min prey size, the "Range", "Max", and "Min" stand for the range of prey length, maximum prey length, and minimum prey length (mm) utilized by the spider species.

In the sheet SD prey size, the "SD" stands for the standard deviation of prey length utilized by the spider species.

Additional data for the gene zgc::64022, which did not fit the file size limit of the main data set located at the following address: https://doi.org/10.5281/zenodo.5268683

A sample of a measurements dataset. Monitoring of a general purpose Cloud storages (e.g. such as AWS S3) is a part of ENTICE Pareto-SLA component. This dataset has been obtained by performing downloads of objects with random data of various sizes, ranging from 1 kB to 1 GB. Each file object has been generated by dd tool: dd if=/dev/urandom of=rand-1M.bin bs=1M count=1. On the server side a Minio S3 server has been setup with a Nginx gateway. The client who performed downloads was residing in the same local 1 Gbps ethernet network as the server. On the server side, network QoS has been controlled through a Linux tc netem tool, emulating various QoS conditions for the packet delay, jitter and packet loss. The dataset contains the following headers: Timestamp - the timestamp of a measurement performed. Client IP - the IP address of a client - anonymised. Server IP - the IP address of a server - anonymised. QoS - min|avg|max|stdev|ploss denoting minimum, average and maximum packet round-trip-time (RTT) between the server and the client, respectively, followed by the standard deviation of the RTT and emulated packet loss with the tc tool, expressed as a percentage. Object size [B] - the size of the file object in bytes. Download time [s] - the download time of the file object from the client perspective. Download speed [B/s] - the ratio (Object size[B]) / (Download time[s]).

This dataset contains a selection of µCT scans of concrete samples. The samples were made of cement and coarse aggregates without sand fraction. One sample shows induced cracks by 4 freeze-thaw cycles (FTW).

sample induced cracks resolution (px) scaling (µm/px) cement w/c-ratio aggregate grain size fraction [mm] additives

Probe 4 (7d)* no 1800 x 1956 x 3949 1.8750 CEM II A-LL 32,5R 0,37 basalt chipping, Dietrichsberg 5/8 superplasticizer, PCE Viscocrete 2600, 0,01%

Probe 8 (4FTW) yes 467 x 463 x 981 7.6667 CEM II A-LL 32,5R 0,42 basalt chipping, Dietrichsberg 5/8 superplasticizer, PCE Viscocrete 2600, 0,003%

Probe 24 (7d) no 456 x 461 x 991 7.6667 CEM II A-LL 32,5R + pulverised limestone (70:30) 0,45

50% basalt chipping, Dietrichsberg

50% rhyolith chipping, Ottenhöfen

5/8 superplasticizer, PCE Viscocrete 2600, 0,0009%

For "Probe 4 (7d)" all sub files (.7z.001 - *.7z.009) have to be downloaded and unpacked using 7zip.

This dataset contains the MEaSUREs OMI Total Column Water Vapor (TCWV) data and their related data used in the paper titled “Development of the MEaSUREs blue band water vapor algorithm – Towards a long-term data record” by Wang et al. (2023). The unzipped archive contains the following three directories. OMI-H2O-L2/ contains the MEaSUREs Level 2 data (in molecules/cm2) in netCDF4 format for January and July 2005 and 2006. Selected supporting data are also included in each file. OMI-H2O-L3/ contains MRaSUREs Level 3 data (0.25 degree by 0.25 degree, in molecules/cm2) generated using the standard filtering criteria in netCDF4 format for January and July 2005 and 2006. Selected supporting data are also included. Model3_ncresult/ contains netCDF4 formatted files for the MEaSUREs OMI TCWV data (in mm), the AMSR_E TCWV data sampled onto the corresponding OMI pixel locations, and the LightGBM model 3 predictions for the OMI pixels. The linux command ‘ncdump -h filename’ can be used to examine the contents of netCDF4 files. Due to the current size limit of Zenodo, only a small subset of the MEaSUREs data is archived here. The full dataset will be released elsewhere, e.g., NASA EARTHDATA GES DISC. {"references": ["Wang et al. (2023): Development of the MEaSUREs blue band water vapor algorithm - Towards a long-term data record, Atmos. Meas. Tech., amt-2023-66."]} Funding for this project is provided by NASA MEaSUREs program Grant #80NSSC18M0091 and NASA OMI core science team Grant #80NSSC21K0177.

AIT Log Data Sets

This repository contains synthetic log data suitable for evaluation of intrusion detection systems, federated learning, and alert aggregation. A detailed description of the dataset is available in [1]. The logs were collected from eight testbeds that were built at the Austrian Institute of Technology (AIT) following the approach by [2]. Please cite these papers if the data is used for academic publications.

In brief, each of the datasets corresponds to a testbed representing a small enterprise network including mail server, file share, WordPress server, VPN, firewall, etc. Normal user behavior is simulated to generate background noise over a time span of 4-6 days. At some point, a sequence of attack steps is launched against the network. Log data is collected from all hosts and includes Apache access and error logs, authentication logs, DNS logs, VPN logs, audit logs, Suricata logs, network traffic packet captures, horde logs, exim logs, syslog, and system monitoring logs. Separate ground truth files are used to label events that are related to the attacks. Compared to the AIT-LDSv1.1, a more complex network and diverse user behavior is simulated, and logs are collected from all hosts in the network. If you are only interested in network traffic analysis, we also provide the AIT-NDS containing the labeled netflows of the testbed networks. We also provide the AIT-ADS, an alert data set derived by forensically applying open-source intrusion detection systems on the log data.

The datasets in this repository have the following structure:

• The gather directory contains all logs collected from the testbed. Logs collected from each host are located in gather/.
• The labels directory contains the ground truth of the dataset that indicates which events are related to attacks. The directory mirrors the structure of the gather directory so that each label files is located at the same path and has the same name as the corresponding log file. Each line in the label files references the log event corresponding to an attack by the line number counted from the beginning of the file ("line"), the labels assigned to the line that state the respective attack step ("labels"), and the labeling rules that assigned the labels ("rules"). An example is provided below.
• The processing directory contains the source code that was used to generate the labels.
• The rules directory contains the labeling rules.
• The environment directory contains the source code that was used to deploy the testbed and run the simulation using the Kyoushi Testbed Environment.
• The dataset.yml file specifies the start and end time of the simulation.

The following table summarizes relevant properties of the datasets:

• fox
  • Simulation time: 2022-01-15 00:00 - 2022-01-20 00:00
  • Attack time: 2022-01-18 11:59 - 2022-01-18 13:15
  • Scan volume: High
  • Unpacked size: 26 GB
• harrison
  • Simulation time: 2022-02-04 00:00 - 2022-02-09 00:00
  • Attack time: 2022-02-08 07:07 - 2022-02-08 08:38
  • Scan volume: High
  • Unpacked size: 27 GB
• russellmitchell
  • Simulation time: 2022-01-21 00:00 - 2022-01-25 00:00
  • Attack time: 2022-01-24 03:01 - 2022-01-24 04:39
  • Scan volume: Low
  • Unpacked size: 14 GB
• santos
  • Simulation time: 2022-01-14 00:00 - 2022-01-18 00:00
  • Attack time: 2022-01-17 11:15 - 2022-01-17 11:59
  • Scan volume: Low
  • Unpacked size: 17 GB
• shaw
  • Simulation time: 2022-01-25 00:00 - 2022-01-31 00:00
  • Attack time: 2022-01-29 14:37 - 2022-01-29 15:21
  • Scan volume: Low
  • Data exfiltration is not visible in DNS logs
  • Unpacked size: 27 GB
• wardbeck
  • Simulation time: 2022-01-19 00:00 - 2022-01-24 00:00
  • Attack time: 2022-01-23 12:10 - 2022-01-23 12:56
  • Scan volume: Low
  • Unpacked size: 26 GB
• wheeler
  • Simulation time: 2022-01-26 00:00 - 2022-01-31 00:00
  • Attack time: 2022-01-30 07:35 - 2022-01-30 17:53
  • Scan volume: High
  • No password cracking in attack chain
  • Unpacked size: 30 GB
• wilson
  • Simulation time: 2022-02-03 00:00 - 2022-02-09 00:00
  • Attack time: 2022-02-07 10:57 - 2022-02-07 11:49
  • Scan volume: High
  • Unpacked size: 39 GB

The following attacks are launched in the network:

• Scans (nmap, WPScan, dirb)
• Webshell upload (CVE-2020-24186)
• Password cracking (John the Ripper)
• Privilege escalation
• Remote command execution
• Data exfiltration (DNSteal)

Note that attack parameters and their execution orders vary in each dataset. Labeled log files are trimmed to the simulation time to ensure that their labels (which reference the related event by the line number in the file) are not misleading. Other log files, however, also contain log events generated before or after the simulation time and may therefore be affected by testbed setup or data collection. It is therefore recommended to only consider logs with timestamps within the simulation time for analysis.

The structure of labels is explained using the audit logs from the intranet server in the russellmitchell data set as an example in the following. The first four labels in the labels/intranet_server/logs/audit/audit.log file are as follows:

{"line": 1860, "labels": ["attacker_change_user", "escalate"], "rules": {"attacker_change_user": ["attacker.escalate.audit.su.login"], "escalate": ["attacker.escalate.audit.su.login"]}}

{"line": 1861, "labels": ["attacker_change_user", "escalate"], "rules": {"attacker_change_user": ["attacker.escalate.audit.su.login"], "escalate": ["attacker.escalate.audit.su.login"]}}

{"line": 1862, "labels": ["attacker_change_user", "escalate"], "rules": {"attacker_change_user": ["attacker.escalate.audit.su.login"], "escalate": ["attacker.escalate.audit.su.login"]}}

{"line": 1863, "labels": ["attacker_change_user", "escalate"], "rules": {"attacker_change_user": ["attacker.escalate.audit.su.login"], "escalate": ["attacker.escalate.audit.su.login"]}}

Each JSON object in this file assigns a label to one specific log line in the corresponding log file located at gather/intranet_server/logs/audit/audit.log. The field "line" in the JSON objects specify the line number of the respective event in the original log file, while the field "labels" comprise the corresponding labels. For example, the lines in the sample above provide the information that lines 1860-1863 in the gather/intranet_server/logs/audit/audit.log file are labeled with "attacker_change_user" and "escalate" corresponding to the attack step where the attacker receives escalated privileges. Inspecting these lines shows that they indeed correspond to the user authenticating as root:

type=USER_AUTH msg=audit(1642999060.603:2226): pid=27950 uid=33 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="jhall" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=success'

type=USER_ACCT msg=audit(1642999060.603:2227): pid=27950 uid=33 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="jhall" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=success'

type=CRED_ACQ msg=audit(1642999060.615:2228): pid=27950 uid=33 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="jhall" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=success'

type=USER_START msg=audit(1642999060.627:2229): pid=27950 uid=33 auid=4294967295 ses=4294967295 msg='op=PAM:session_open acct="jhall" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/1 res=success'

The same applies to all other labels for this log file and all other log files. There are no labels for logs generated by "normal" (i.e., non-attack) behavior; instead, all log events that have no corresponding JSON object in one of the files from the labels directory, such as the lines 1-1859 in the example above, can be considered to be labeled as "normal". This means that in order to figure out the labels for the log data it is necessary to store the line numbers when processing the original logs from the gather directory and see if these line numbers also appear in the corresponding file in the labels directory.

Beside the attack labels, a general overview of the exact times when specific attack steps are launched are available in gather/attacker_0/logs/attacks.log. An enumeration of all hosts and their IP addresses is stated in processing/config/servers.yml. Moreover, configurations of each host are provided in gather/ and gather/.

Version history:

• AIT-LDS-v1.x: Four datasets, logs from single host, fine-granular audit logs, mail/CMS.
• AIT-LDS-v2.0: Eight datasets, logs from all hosts, system logs and network traffic, mail/CMS/cloud/web.

Acknowledgements: Partially funded by the FFG projects INDICAETING (868306) and DECEPT (873980), and the EU projects GUARD (833456) and PANDORA (SI2.835928).

If you use the dataset, please cite the following publications:

[1] M. Landauer, F. Skopik, M. Frank, W. Hotwagner,

Experimental trial data for the publication: Biomass encounter rates limit the size scaling of feeding interactions.

This is the Raw spectral dataset of the data published in 10.1364/OPTICA.488860 Data are arranged as follows: wavenumber [Nx1] Hyperspectrum_cube [Nx2, A, B]: hyperspectral datacube, where: Hyperspectrum_cube (1:N, :, :) is the real part; Hyperspectrum_cube (N+1:2N, :, :) is the imaginary part maximum [1x1] minimum [1x1]. N: number of spectral bands A and B: size of the spatial coordinates Spectral amplitudes are obtained by: Hyperspectrum_cube=double(Hyperspectrum_cube)./(2.^16-1).*maximum+minimum

This is the final result of using Mask R-CNN to predict the location of relict charcoal hearths (RCH) in and near State Game Lands throughout Pennsylvania.

Please note that only those RCHs falling into one (or more) of the three cluster analyses is considered to be a likely true positive (i.e., an actual charcoal hearth). That is, where ClusterCT =0.

Variables:

id= unique identifier starting with 3-digit SGL number, PAN or PAS (projections) and, within those a unique four-digit identifier score= confidence score SGL= State Game Land number SGLImage= name of TIFF file of merged lidar tiles Confirm= Whether the predicted hearth was determined, through visual inspection, to be a likely true positive (Y) or a false positive (N) Bin#- in assessing these predictions we “binned” the results based upon the confidence score. Bin_select= 1 if this record (predicted RCH) was selected for assessment within that bin TrainID= Original ID of the training data (only training data that matched with a prediction are included). Clusters5_300= resultant clusters from DBSCAN where minimum cluster size= 5 and maximum distance= 300 meters Clusters10_500= resultant clusters from DBSCAN where minimum cluster size= 10 and maximum distance= 500 meters Clusters20_1000= resultant clusters from DBSCAN where minimum cluster size= 20 and maximum distance= 1000 meters CLUSTERCT = How many of the above clusters included the predicted RCH (0-3). Derived from the previous three variables. 3Cluster= whether or not this predicted RCH was included in all three clusters.

For additional information, please see https://zenodo.org/deposit/4593788 .

This dataset describes a sequence of tephra layers recovered from a Holocene sediment core taken at June Lake, California, USA. It includes tephra sediment stratigraphy, sample information, tephra layer thicknesses, tephra grain size data, volcanic glass geochemistry, Fe-Ti oxide geochemistry, SEM imagery, and method information. The tephra layers originate from the Mono-Inyo volcanic system.

Most of this information is contained in a series of spreadsheets that follow tephra community recommended best practices.

The listed files below follow the naming convention and format of Abbott et al. (2020) version 2.0, and they serve as worked examples of that format. See DOI: 10.5281/zenodo.3866266 for more information.

June Lake Collection2b.xlsx (location information, sample information, stratigraphy)

June Lake Sample_Processing.xlsx (sample preparation)

June Lake Physical_analysis2b.xlsx (maximum grain size data, pumice class density)

June Lake Physical_Microanalysis2.xlsx (SEM-EDS images, sample mount images)

June Lake Geochemical_Analysis2.xlsx (EPMA method details)

Glass and Fe-Ti oxide geochemistry by EPMA may be found in the following files:

June Lake Glass DATA.xlsx

June Lake Fe-Ti Oxides DATA.xlsx

SEM and other images may be found in the following file:

June Lake EPMA Images.zip

This dataset contains speech from Finnish parliament 2008-2020 plenary sessions, segmented and aligned for speech recognition training. In total, the training set has:

• 1.4 million samples
• 3100 hours of audio
• 460 speakers
• over 19 million word tokens

Additionally, the upload contains 5h long development and 5h long evaluation sets described in publication 10.21437/Interspeech.2017-1115. Due to the size of the training set (~300 GB) and Zenodo upload limit (50 GB), only the development and evaluation sets are published on Zenodo. Rest of the data is available at: http://urn.fi/urn:nbn:fi:lb-2021051903

The training set comes in two parts:

1. 2008-2016 set which is originally described in publication 10.21437/Interspeech.2017-1115. This set includes a list of samples from sessions in 2008-2014 that can be combined with the 2015-2020 set to form the 3100 hour training set.
2. A new 2015-2020 dataset.

All audio samples are single-channel, 16 kHz and 16-bit wav files. Each wav file has corresponding transcript in a .trn text file. The data is machine-extracted so there still remains small inaccuracies in the training set transcripts and possibly few Swedish samples. Development and evaluation sets have been corrected by hand.

The licenses can be viewed at:

• http://urn.fi/urn:nbn:fi:lb-2019112822 (audio)
• http://urn.fi/urn:nbn:fi:lb-2019112823 (text)

The code used in extraction is available at:

• https://github.com/aalto-speech/finnish-parliament-scripts (2008-2014, dev and eval sets)
• https://github.com/aalto-speech/fi-parliament-tools (2015-2020 set)

This repository contains the data necessary to reproduce the results of the manuscript: "Timing of a future glaciation in view of anthropogenic climate change" Preprint on EarthArXiv: https://doi.org/10.31223/X5P72S

Data organization:

The Zenodo upload is organized as the following inside of results.zip:

Data analysis and figure generation are given by the "*.pynb" and "*.m" files

Data files as NetCDF output are organized with the following structure inside of data:

Data on the equilibrium experiments used to calibrate the weathering rates at the pre-industrial and the last glacial maximum are included in equilibrium_weathering

The emissions functions are located in emission_functions

Experiment: PIeq, PIeq_fix, LGCeq, LGCeq_ice, LGCeq_m05, LGCeq_m10, LGCeq_p05, and LGCeq_p10

Emissions scenario: 0gtc, 500gtc, 1000gtc, 2000gtc, 3000gtc, 4000gtc, and 5000gtc

Component: atmosphere (atm), land surface (lnd_surf), sea ice (sic), biogeochemistry (bgc), ocean (ocn), and ice sheets (e.g., geo_ts.nc/geo_hires_cut*.nc/ice_NH-32KM_ts.nc/smb_NH-32KM.nc)

File type: for each component, files can be divided into timeseries (_ts.nc) or 2D data with a 1 kyr output frequency (.nc)

Note: due to size constraints of the Zenodo repository, only 2D spatial data used to create figures in the main text or extended data are available. For example, only 2D spatial data of the ice sheets between the years 40-60 kyr AP are available. However, this is not an exhaustive dataset. For inquiries regarding additional data, please contact the corresponding author to explore potential availability.

This dataset is an update to the first release of the Pelagic Size Structure database (PSSdb, https://pssdb.net) scientific project, investigating the global particle size distributions measured from multiple pelagicǂ imaging systems. These devices include the Imaging Flow Cytobot (Olson and Sosik 2007), benchtop scanners like the ZooScan (Gorsky et al. 2010), and the Underwater Vision Profiler (Picheral et al. 2010). The data sources originate from Ecotaxa (https://ecotaxa.obs-vlfr.fr/), Ecopart (https://ecopart.obs-vlfr.fr/), and Imaging FlowCytobot dashboards (https://ifcb.caloos.org/dashboard and https://ifcb-data.whoi.edu/dashboard). Links to the PSSdb code and documentation are available on the PSSdb webpage (https://pssdb.net).

This updated version includes the following changes:

• Duplicate data entries and NaN values have been removed.
• Data products now include Normalized Biomass Size Spectra (NBSS), and Particle Size Distribution (PSD), two widely used methods to represent plankton and particles size distribution in marine ecology and biogeochemistry.
• Linear regressions are now performed with log10 transformations of the normalized biovolume/abundance and the size classes.
• Inclusion of UVP6 and other benchtop plankton Scanner datasets from net tows, which expand the temporal and spatial coverage of the data products.
• Unbiased portion of the size spectra is selected by a new thresholding method that accounts for both uncertainties on particle sizes, limited by the camera resolution, and particle count, so that only size classes with less than 20% uncertainty are retained, in addition to gaps in the size spectra.

This PSSdb dataset is composed of two products, specific to each imaging device:

• Product 1a includes the size distribution , computed from normalized biovolume, for NBSS, and normalized abundance, for PSD, of plankton and particles within a set of pre-defined size classes (expressed in both biovolume and equivalent circular diameter), averaged by year and month, and in 1-degree longitude/latitude grid cells.
• Product 1b includes the results of NBSS and PSD regression fit parameters, slopes, intercept, and coefficient of determination (R2), averaged by year and month, and in 1-degree longitude/latitude grid cells. The regression parameters are defined using ordinary least squares linear regressions applied to a log10 transformed normalized biovolume/normalized abundance and biovolume/ diameter size class values.

Size spectra parameters were averaged over a maximum of 16 spatial and temporal subsets (0.5°x0.5°x1 week) to avoid over-representation of repeated sampling events (e.g., time-series datasets) within a grid cell. Linear regressions were performed on the linear portion of the log10-transformed NBSS and PSD estimates, between the size classes with a size measurement or particle count uncertainty greater than 20% (Schartau et al. 2010) , and where the maximum NB/PSD is observed and the largest size class before three empty consecutive size classes.

For additional information, please see the PDF documentation available below ...

Training and test images of live E. coli cells imaged under bright field for the task of segmentation.

Additional information can be found on this github wiki.

The example shows a bright field image of live E. coli cells and the manually annotated segmentation mask.

Data type: Paired bright field and segmented mask images

Microscopy data type: 2D bright field images recorded at 1 min interval

Microscope: Nikon Eclipse Ti-E equipped with an Apo TIRF 1.49NA 100x oil immersion objective

Cell type: E. coli MG1655 wild type strain (CGSC #6300).

File format: .tif (8-bit)

Image size: 1024 x 1024 px² (79 nm / pixel), 19/15 individual frames (training/test dataset)

1024 x 1024 px² (79 nm / pixel), 9 regions of interest with 80 frames @ 1 min time interval (live-cell time series)

Image preprocessing: Raw images were recorded in 16-bit mode (image size 512 x 512 px² @ 158 nm/px). Images were upscaled with a factor of 2 (no interpolation) to enable generation of higher-quality segmentation masks. Two sets of mask images are provided: RoiMaps for instance segmentation using e.g. StarDist or binary images for CARE or U-Net.

Author(s): Christoph Spahn^1,2, Mike Heilemann^1,3

Contact email: christoph.spahn@mpi-marburg.mpg.de

Affiliation(s):

1) Institute of Physical and Theoretical Chemistry, Max-von-Laue Str. 7, Goethe-University Frankfurt, 60439 Frankfurt, Germany

2) ORCID: 0000-0001-9886-2263

3) ORCID: 0000-0002-9821-3578

The dataset contains and processes results of a large-scale survey of 708 websites, made in December 2019, in order to measure various features related to their size and structure: DOM tree size, maximum degree, depth, diversity of element types and CSS classes, among others. The goal of this research is to serve as a reference point for studies that include an empirical evaluation on samples of web pages.

See the Readme.md file inside the archive for more details about its contents.

This is the web service data for version 1 of the BioLiP database, last update in April 01, 2022. Due to file size limit of zenodo, the full data is split into two parts (https://doi.org/10.5281/zenodo.8407896 and https://zenodo.org/record/8407920). To concatenate and decompress the files after downloading the two split parts:
$ cat BioLiP1aa BioLiP1ab > BioLiP.tar.bz2
$ tar -xvf BioLiP.tar.bz2