The data produced from this research project will fall into two categories:

1. The various reaction parameters required for optimization of the chemical transformation.

2. The spectroscopic and general characterization data of all compounds produced during the work.

Data in category 1 will be documented in [file format].
Spectroscopic data in category 2 will be produced as [file format] and converted to [file format] for further use. Other characterisation data in this category will be collected in [file format].

We anticipate that the data produced in category 1 will amount to approximately 10 MB and the data produced in category 2 will be in the range of 4 - 5 GB.

This project will work with and generate three main types of raw data.

1. Images from transmitted-light microscopy of giemsa-stained squashed larval brains.

2. Images from confocal microscopy of immunostained whole-mounted larval brains.

3. Western blot data.

All data will be stored in digital form, either in the format in which it was originally generated (i.e. Metamorph files, for confocal images; Spectrum Mill files, for mass spectra with results of mass spectra analyses stored in CSV files; TIFF files for gel images; MariaDB SQL dump files for genetics records), or will be converted into a digital form via scanning to create tiff or jpeg files (e.g. western blots or other types of results).

Measurements and quantification of the images will be recorded in excel files (for long term preservation, they will be converted in CSV files. Micrograph data is expected to total between 100GB and 1TB over the course of the project. Scanned images of western blots are expected to total around 1GB over the course of the project. Other derived data (measurements and quantifications) are not expected to exceed 10MB.

The data are health records auto-generated by users of the application X. They are subjected to a contract with the company X.

All fields contain user observations and entered manually, except for temperature which is measured by a Bluetooth connected thermometer.

Data fields per user (anonymized by X): User identifier; Age; Weight, Size.

Data fields per users per day of observation:

• Temperature and time at which temperature is taken,

• Cervical fluid quality (none, sticky, creamy, egg white, watery) and quantity (little, medium, lots),

• Cervix height (low, med, high), cervix openness (closed, med, open), cervix firmness (firm, med, soft),

• Sexual intercourse (protected or unprotected),

• Menstruation (light, medium, heavy), spotting, starting a new cycle,

• Custom data (notable predetermined fields are pregnancy test results or ovulation test results).

Data will be received in CSV format, and consists of the record of 2 million users. It will amount to maximum 1GB.

There will be two categories of data: NEW data from this project and EXISTING data from the FOEN Lake Monitoring
program.

The NEW data will consist of several file types, all CSV real number format, which are all organized along the same principle: matrixes of times series with various channels, each corresponding to a sensor (number of sensors varies from 1 to10) and very different length, as the sampling frequency varies by several orders-of-magnitudes.

1. 6 files of CO2, DO, PAR and temperature (24 files at a time; Figure 2), each file only 1 sensor (Delta = 10 min; continuous),
2. Thetis profiles corresponding to time series (equivalent to depth series) of 10 sensors (Delta = 1 s; 5-10 times per day).
3. 5 files of CO2 time series for short-term surface flux measurements (several files, one per month),
4. meteodata file (eight sensors; continuous),
5. T-Microstructure profiles files (6 sensors at 512 Hz; several files, once per month) and
6. excel files for individual chemical samples (such as alkalinity, sediment trap estimates, ect; sporadic).

The EXISTING data is already available (CIPAIS, CIPEL) in excel sheets with matrices for the individual samplings and a variable number of parameters (~10 to ~25). The EXISTING data will not be modified and remains with the organizations. We will keep a copy on our computers during the project. We anticipate the data produced in category 1 to amount to several hundred MB for the moored and profiled sensor files and ~100 GB for the T-microstructure profiles; the EXISTING data in category 2 is in the range of ~20 MB.

The reaction conditions will be recorded and collated using a spreadsheet application and named according to each generation of reaction as follows:
ProjectW-ReactionX-GenerationY-ScientistZ-YYYYMMDD-HHmm.csv

The various experimental procedures and associated compound characterization will be written up using the Royal Society of Chemistry standard formatting in a Word document, each Word document will also be exported to PDF-A. The associated NMR spectra will be collated in chronological order in a PDF-A document.

All samples on which data are collected will be prepared according to published standard protocols in the field [cite reference]. Files will be named according to a pre-agreed convention. The dataset will be accompanied by a README file which will describe the directory hierarchy.

Each directory will contain an INFO.txt file describing the experimental protocol used in that experiment. It will also record any deviations from the protocol and other useful contextual information.

Microscope images capture and store a range of metadata (field size, magnification, lens phase, zoom, gain, pinhole diameter etc.) with each image.

This should allow the data to be understood by other members of our research group and add contextual value to the dataset should it be reused in the future.

Experiments will include appropriate controls to ensure validity [brief description]. Data consistency will be assessed by comparing repeated measures.

Quality of analytical data will be guaranteed through calibration of devices, repetition of experiments, comparison with literature/internal standards/previous data, by a peer review.

All experimental data will be automatically imported into the institutional electronic Laboratory Information System (LIMS) from the measurement device. Methods and materials will be recorded using the institutional Electronic Lab Notebook (ELN).

The experimental records and observations are recorded by hand-written notes followed by digitization (scanning). The analytical data are collected by the instruments that generated them; they are processed by the native programs associated with the instruments. A periodic quality control process will be applied to remove errors and redundancies. Errors include for example incorrect handling and machine malfunction. The quality control process will be documented.

The quality of experimental records and observations will be controlled by repeating experiments.

For NMR and X-ray, the data collection is done through instrument standardised data acquisition programs. For E-chem, UV-Vis, IR, GC, GC-MS, lab-standardized protocols will be used.

The data from the moored sensors is sensor-internally stored and recovered every two months, when sensors will be cleaned and recalibrated if data indicates quality loss. The CO2 sensors will be cross calibrated against atmospheric pressure. The DO and PAR sensors in the mooring will be compared to profiled sensors and deviations detected. Temperature sensors are extremely stable and are only calibrated before and after the two years using the laboratory temperature bath which is calibrated agaist the Office of Metrology in Bern every few years to 0.001 oC. The Thesis sensor data is transmitted when surfacing via GSM communication system directly to the lab where sensors deterioration is weekly checked. The instrument will be retrieved every month and sensors cleaned. The optical sensors will be calibrated according the manual every six months. The T-microstructure sensors do not need calibration as the data 8 is matched to (very accurate) CTD temperature. Small T shifts are irreverent, as only the spectra matter. The sensors deterioration (or frequency loss) will visually be checked and is seen in the quality of the Batchelor spectra. The very simple structure of the CSV files holding the raw data will be documented in a plain text README file. This file, and all raw data files as they become available, will be uploaded to the Eawag Research Data Institutional Collection into one “data package”, which is annotated with general metadata. Copies of the raw data files as well as set of calibrated, quality-controlled files stored on the group computers at ETH will be organized in a folder structure that is also documented in a README file. At the end of the project, the entire set of calibrated, quality-controlled files will be annotated and stored on the Eawag institutional repository as well.

All files produced during this project will be stored in our Electronic Laboratory Notebook (ELN) and Laboratory Information Management System (LIMS) openBIS.

In this ELN, each scientist has a personal folder where to organize projects and experiments. Each experiment is described in the electronic notebook and all data related to the experiment is directly attached to it, in so called “datasets”. Each dataset is immutable, thus different file versions are stored in the lab notebook in different datasets with a manually generated version number. Very large datasets (100s of TBs) are not directly stored in openBIS datasets, but they are linked to the experimental description using an extension to openBIS called BigDataLink. This works similarly to the git version control software, so every time changes are made to the data, these need to be committed to openBIS, which automatically keeps track of the versioning.

The data will be accompanied by the following contextual documentation, according to standard practice for synthetic methodology projects:

1. Spreadsheet documents which detail the reaction conditions.

2. Text files which detail the experimental procedures and compound characterization.

Files and folders will be named according to a pre-agreed convention YXZ, which includes for each dataset, identifications to the researcher, the date, the study and the type of data (see section 1.2).

The final dataset as deposited in the chosen data repository will also be accompanied by a README file listing the contents of the other files and outlining the file-naming convention used.

Metadata will be tagged in XML using the Data Documentation Initiative (DDI) format. The codebook will contain information on study design, sampling methodology, fieldwork, variable-level detail, and all information necessary for a secondary analyst to use the data accurately and effectively.

It will be responsibility of:

• each researcher to annotate data with metadata,

• the Principal Investigator to check weekly (during the field season, monthly otherwise) with all participants to assure data is being properly processed, documented, and stored.

IFS and OpenIFS model integrations will be run and standard meteorological and computing performance data output will be generated. Both will be run at ECMWF, and only performance data will be made available to the public. The meteorological output will be archived in MARS, as it is standard research experiment output. The data will be used for establishing research and test code developments, and will enter project reports and generally accessible publications. The IFS will not be made available, OpenIFS is available through a dedicated license.

IFS meteorological output (incl. metadata) and format follows the World Meteorological Organization (WMO) standards. Compute performance (benchmark) output will be stored and documented separately. Data will be in ASCII and maintained locally. The output will be reviewed internally, and the ECMWF facilities allow reproduction of this output if necessary.

Two types of metadata will be considered within the frame of the project X: that corresponding to the project publications, which has already been described in Section 4, and that corresponding to the published research data.

In the context of data management, metadata will form a subset of data documentation that will explain the purpose, origin, description, time reference, creator, access conditions and terms of use of a data collection.

The metadata that would best describe the data depends on the nature of the data. For research data generated in project X, it is difficult to establish a global criteria for all data, since the nature of the initially considered data sets will be different, so that the metadata will be based on a generalised metadata schema as the one used in ZENODO5, which includes elements such as:

• Title: free text

• Creator: Last name, first name

• Date

• Subject: Choice of keywords and classifications

• Description: Text explaining the content of the data set and other contextual information

• needed for the correct interpretation of the data,

• Format: Details of the file format,

• Resource Type: data set, image, audio, etc.,

• Identifier: DOI,

• Access rights: closed access, embargoed access, restricted access, open access.

Additionally, a readme.txt file could be used as an established way of accounting for all the files and folders comprising the project and explaining how all the files that make up the data set relate to each other, what format they are in or whether particular files are intended to replace other files, etc.

For every data stream (sequences of identical data files) over the entire 2-year period of data acquisition a README File will be generated which contains: (a) the sensors used (product, type, serial number), (b) the temporal sequence of the sensors (time and location, sampling interval), (c) the observations made during maintenance and repairs, and (d) details on the physical units, as well as the calibration procedure and format. This is a standard procedure which we have used in the past.

In the data management system (openBIS ELN-LIMS), metadata are provided as attributes of the respective datasets. Based on the defined metadata schema, openBIS ELN-LIMS will be configured so that the required metadata is automatically assigned to datasets and / or manually provided by the researcher.

*Information required to read and interpret data (incl. metadata standards) to be filled by researchers.

Please check if your project involves one of the following ethical issues:

• Human participants (This includes all kinds of human participation, incl. non-medical research, e.g. surveys, observations, tracking the location of people)

• Human cells/tissues

• Human embryonic stem cells

• A clinical trial

• The collection of personal/private data

• Animal experimentation

• Third countries (access and benefit sharing) / export law issues.

• Environmental and/or health and safety issues (for example, a negative impact on the environment and/or on the health and safety of the researchers.)

• The potential for military applications (dual-use technology).

If you consider that there are no ethical issues in your project, you can use the following statement:

There are no ethical issues in the generation of results from this project.

This project will generate data designed to study the prevalence and correlates of DSM III-R psychiatric disorders and patterns and correlates of service utilization for these disorders in a nationally representative sample of over 8000 respondents. The sensitive nature of these data will require that the data be released through a restricted use contract, to which each respondent will give explicit consent. An ethical authorization will be obtained from the cantonal ethics committee for this project.

Research in this proposal involves the use of animals of the species mouse (Mus Musculus). Animal studies will be preceded by multiple biochemical experiments in vitro and in cultured cells. Mouse experiments will only be used at advanced stages of investigations when few, specific and highly relevant questions can be addressed by a limited number of experiments.

The PI and the research team will work in conformity with all applicable rules, guidelines and principles such as the EU directive 2010/63/EU on the protection of animals used for scientific purposes, the Swiss federal law on animal protection (RS 455), the federal ordinance on animal protection (RS 455.1), and the federal ordinance on animal experimentation, production, and housing (RS 455.163). All animal experiments will only be initiated after having received the approval of the Cantonal and Federal authorities.

Details on animal usage

In performing the experiments, we strive to strictly adhere to the 3Rs principle of Replacement, Refinement, and Reduction.

• Reduction: Each experiment will be designed to use the minimum number of mice required to obtain statistical significance. For the proposed pharmacokinetic experiments, a total number of 24 mice will be required.

• Refinement: The animals will be housed in the animal facilities of EPFL, which meet international housing norms, and the animal health status is monitored by a certified veterinarian. To reduce stress and discomfort of the animals, all procedures will be performed only after animals are anaesthetized. After experiments animals will be euthanized. Also, as soon as animals show signs of severe discomfort and/or tumor burden during experiments, they will be euthanized by cervical dyslocation after being anaesthetized.

• Replacement: Alternatives for mouse experiments will be considered at all stages during the project. Whenever possible, these alternatives will replace the mouse experiments.

Training

All researchers and technicians working with the animals receive proper animal welfare training in conformity with DFE Ordinance 455.109.1 on ‘Training in animal husbandry and in the handling of animals’.

Environmental protection and safety

The PI assures that appropriate health and safety procedures conforming to relevant local / national guidelines / legislation are followed for staff involved in this project. The health and safety of all participants in the research (investigators, subjects involved or third parties) must be a priority in all research projects (see also ETH regulations on health and safety). The project will be conducted in collaboration with ETH’s Safety, Security, Health and Environment department (SSHE).

All data are anonymized, and as such, we are in line with the Swiss Federal Act on Data Protection as described on the page of the Federal Data Protection and Information Commissioner (FDPIC).

The project respects all the constraints and requirements as laid down in the Swiss Federal Act on Data Protection and supervised by the Federal Official Responsible for Data Protection and Transparency.

Indeed, as the finality of the project does not relate to individuals and the published results do not allow to identify the participants nominatively,  we have communicated with all participants giving them the following basic information :

• Author/ Responsible person

• lType and extent of collected/processed data

• Objectives of the processing

• Any communication to be made to third-parties /recipients categories / planned trans borders communications, with all necessary guaranties related to the article 6 of the Data Protection Law (Loi sur la Protection des Données, LPD)

• The facultative nature of the participation to this project and the possibility to resign at all times 

• The consequences, if any, in case of refusal to participate (No inconvenience should result)

• Access and correction rights

The project is a medical research project and respects all the rules and regulations laid down in the Swiss Federal Act on Data Protection and supervised by the Federal Official Responsible for Data Protection and Transparency.

We are only using and processing data for individuals who have given their explicit consent.

Dataset X was obtained from the BAFU and is subject to a confidentiality agreement to keep information about the sampling locations secret. We are allowed to share this information among researchers involved in the project. The dataset is being stored in a location to which only project member have access. Please refer to Section 2.2 for technical details about access restrictions. All project members will be informed about sensitivity of this data and agree not to copy it to other places. This dataset and intermediate datasets containing the sampling locations will be excluded from the data package published along with the final report and replaced with instructions about how to obtain them from the BAFU.

The data will be processed and managed in a secure non-networked environment using virtual desktop technology.

All interviewees and focus group participants will sign a Consent form agreed to by the School ethics committee. We have guaranteed anonymity to our interviewees and focus group participants. Therefore we will not be depositing .wav files as this would compromise that guarantee. However, anonymised transcripts of the interviews and focus groups will be deposited. We will make sure consent forms make provision for future sharing of data. All identifying information will be kept in a locked filing cabinet and not stored with electronic files.

Data will be stored on the centralized file storage system managed by our institutional or school [please specify, e.g. life sciences or basic sciences] IT department. The access to the data is managed through the ETH identity management system, which is a secured system following the best practices in terms of identity management. Our central storage facility has redundancy, mirroring and is monitored.

Research records will be kept confidential, and access will be limited to the PI, primary research team members, and project participants. Data will be housed on a local server controlled by the PI, and will be accessible via SSH and VPN. Data containing identifiable information, or information covered by an NDA, will be held in an encrypted format (symmetric, AES256, key on local server, passphrase only know to PI and primary research team members).

The data we are generating, processing and storing in this project does not pose a particular data security risk. Dayto- day work is conducted on standard-issue workstations in the ETH-environment with standard enterprise-grade access control. The ETH network is a secured system following the best practices in terms of identity management and central storage facility has redundancy, mirroring and is monitored. At different stages, data will be stored in the Eawag Institutional Collection (see section 1.3). This system is accessible only from within the Eawag network and is comprised of several virtualized Linux systems that receive real-time security patches. Access control is handled according to recognized best practices of server administration.

“Notoriously Toxic”, NEH ODH Start-up Grant, Level 1, https://www.neh.gov/files/dmp_from_successful_grants.zip

All data generated in the project will be stored in our open- BIS ELN-LIMS. This operates in a client-server model, which is installed and maintained by the ETH Zurich IT services on ETH Zurich infrastructure. Researchers can access openBIS via any of the most common web browsers. openBIS requires user authentication with ETH Zurich credentials and it provides user right management, so that different users can have different access to all or different parts of the system, as required. Below is a description of the default openBIS roles, which can be modified upon request:

1. Instance admin. Has full admin powers. Can customize settings, create, modify and delete entities, assign user roles, create data spaces.
2. Instance observers. Has read-only access to everything in openBIS.
3. Space admin. Can create, modify, delete entities and assign roles only within a given data space.
4. Space power user. Can create, modify and delete entities only within a given data space.
5. Space user. Can create and modify entities only within a given data space.
6. Space observer. Has read-only access limited to a given data space.

openBIS does not offer any specific option for sensitive data, but the data will be encrypted prior to upload to openBIS. Furthermore, all operations on the system (incl. which users log in and when) are logged, so that it is fully transparent who did what to the data and when.

The data stored in openBIS is physically located on a NAS (network attached storage) provided by the ETH Zurich IT Services. The access to the share’s data is governed by the latest security best practices and only a limited number of employees of the ETH Zurich IT services have access to that share.

The research is not expected to lead to patents. Other Intellectual Property Rights (IPR)issues will be dealt in line with the institutional recommendation. As the data is not subjected to a contract and will not be patented, it will be released as open data under Creative Commons CC0 license.

This project is being carried out in collaboration with an industrial partner. The intellectual property rights are set out in the collaboration agreement. The intellectual property generated from this project will be fully exploited with help from the institutional Technology Transfer Office. The aim is to patent the final procedure and then publish the work in a research journal and to publish the supporting data under an open Creative Commons Attribution (CC BY) license.

Data is suitable for sharing. They are observational data (hence unique) and could be used for other analyses or for comparison for climate change effects among many things. Reuse opportunities are vast. For this reason, we aim to allow the widest reuse of our data and will release them under Creative Commons CC0.

The source code for analysis will most likely utilize the GNU Scientific Library (GSL), which is licensed under the GNU General Public License (GPL). Therefore we will make our analysis software available under the GPL as well.

Storage and back up will be in three places:

• On Laptop of [Name of Researcher]

• On a portable storage device (hard drive)

• On institutional collaborative storage

[Name of Researcher] will be responsible for the storage and back up of data. This will be done weekly. Backups on the institutional infrastructure are automated using the RSYNC tool.

Original notebooks and hardcopies of all NMR and mass spectra are stored in the PI’s laboratory. Additional electronic data will be stored on the PI’s computer, which is backed up daily. Additionally, the laboratory will make use of the PI’s lab server space at institution’s storage facility for a second repository of data storage. The PI’s lab has access to up to 1 terabyte of information storage, which can be expanded if needed.

All the project data will be stored using the institution’s Collaborative Storage, which is backed-up on a regular basis.

All our data will be uploaded to our Electronic Laboratory Notebook. The data is stored on institutional storage facilities and it is set up by our IT support to be automatically backed up daily.

The ETH centralized file storage service follows the best practices and standards regarding storage, for instance high availability, multiple levels of data protection, partnership with providers for support. The service is managed centrally by the hosting department of the Vice Presidency for Information Systems (VPSI) and ensures security, coherence, pertinence, integrity and high-availability.

Two distinct storage locations can be found on the ETH campus with replication between the two. (Please note that these two different storage options correspond to different payments.)Physical servers’ pairing and clustering guarantees local redundancy of data. Moreover, volume mirroring protects data in case of disaster on the primary site. The copy is asynchronous and automatic and runs every two hours.

The file servers are virtualized for separation between logical data and physical storage, RAID groups ensure physical storage protection: data is split in chunks written on many disks with double parity. Moreover, volume snapshots are used and can allow user restoration of previous versions if need be. For specific needs, optional backup on tape can also be done.

Access to the data is managed by the owner of the volumes through the identity management system of ETH. Any person who needs access to data has therefore to be a registered and verified user in the identity management system.

Our team stores the data to be analyzed along with the results using Eawag file services. [copy text from Eawag standard snippet “file services - backup”] To easily share data with our collaborators in Fribourg, we synchronize those data with a folder on SWITCHdrive. Since this is sensitive personal data, the folder being synchronized contains encrypted files (public key encryption, key-pairs specifically created for this project).

by the ETH Zurich IT Services. openBIS uses a postgres database that stores all metadata. This database is backed up (“pg_dump”) every night with a 7 days retention of the dumps and fully backed-up twice a week with a backup retention of 20 days. The full backup procedure includes a point-in-time recovery that allows a finer granularity (up to minutes) of data recovery in case of a disaster. The database backup is stored on the NAS (network attached storage) provided by the ETH Zurich IT services. The same NAS is used to store the data uploaded to openBIS. This network attached storage is snapshot every night with a 7 days retention, and data is backed up on a proprietary tape library with a retention of 90 days.

Data which is no longer actively needed is moved to the long term storage (i.e. tapes). The tape library where openBIS moves the data has a read-only replica in a different geographical location in order to minimize any data loss.

*For data linked to openBIS with the BigDataLink tool, please provide details of the data location and back-up.

Data will be stored for a minimum of three years beyond award period, per funder’s guidelines.  If inventions or new technologies are made in connection data, access to data will be restricted until invention disclosures and/or provisional patent filings are made with the institutional Technology Transfer Office (TTO).

We will preserve the data for 10 years on university’s servers and also deposit it in an appropriate data archive at the end of the project (e.g. Zenodo, see section 4.1 below). Where possible, we will store files in open archival formats e.g. Word files converted to PDF-A or simple text files encoded in UTF-8 and Excel files converted to CSV. In case this is not possible, we will include information on the software used and its version number.

Where possible, we will store files in open archival formats e.g. Word files converted to PDF-A or simple text files encoded in UTF-8 and Excel files converted to CSV. In case this is not possible, we will include information on the software used and its version number.

Data will be stored on ETH servers and will be preserved for the long term at the ETH Data Archive.

Some of the ongoing data will be shared on [Researcher1]’s Github repository (results and code from the project, data from twitter searches). Major revisions of this page will be baked up using the Github-Zenodo connection (see: https://guides.github.com/activities/citable-code/). All other data we will be published on Zenodo under CC0 license.

We chose Zenodo because it supports the FAIR principles (http://about.zenodo.org/principles/). The immediate publication at the end of the project aims to minimize the data loss risk, while the 2 years embargo guarantees us to be first to exploit our data. Zenodo implements long-term preservation features, notably bitstream preservation.

Datasets from this work which underpin a publication will be deposited in the ETH Zurich Research Collection, and made public at the time of publication. Data in the repository will be stored in accordance with funder’s data policies. Files deposited in the Research Collection will be given a Digital Object Identifier (DOI). The retention schedule for data will be set to 10 years from date of deposition in the first instance, with possible extension for datasets which remain in regular use.

The DOI issued to datasets in the repository can be included as part of a data citation in publications, allowing the datasets underpinning a publication to be identified and accessed.

Metadata about datasets held in the Research Collection will be publicly searchable and discoverable and will indicate how and on what terms the dataset can be accessed.

For this project, the National Geoscience Data Centre (NGDC) (see http://www.bgs.ac.uk/services/ngdc/home.html) is the most suited repository. As it is adapted to geodata, it facilitates storage and allows interactive geographical search. In addition, many other researchers in our field are familiar with it.

This repository requires the deposition under Open Governement Licence (see : http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), which demands attribution when the data is reused (our dataset must by cited, similarly to the CC BY license).

Data which underpins any publication will be made available at the time of publication.

All unpublished data will be deposited in a data repository 12 months after the end of the award.

Astronomical data will be diffused but under an embargo of one year for priority of exploitation reasons.

Personal data will be anonymized before diffusion based on the recommendations from the Federal Act on Data Protection(FADP) https://www.admin.ch/opc/en/classified-compilation/19920153/index.html. The package SDC-Micro (https://cran.r-project.org/package=sdcMicro) will be used to assess the risk of identification: we will make sure that each data set has a k-anonymity of 3 at least.

The extensive household survey about water-born diseases poses severe challenges with regard to anonymization, since simple pseudonymization might not be sufficient to guard against the identification of individual households by an inference attack that uses other available information.

Therefore we will be only able to publish summary statistics together with the associated article. If a sufficiently anonymized dataset turns out to still hold scientific value, we will publish it no later than one year after completion of the project.