Based on the data planning at the beginning of the research project, we define a clear data hierarchy that takes into account the entire life cycle of the research data.

Raw data is mainly stored on local drives, which are regularly synchronized with network storage accessible to the chair . Depending on the data type (e.g. code from models or evaluation tools), management is also carried out via a Git repository.

In the course of finalizing the project, the raw data is processed, which increases the data quality and reduces the quantity. All processed data to be stored long-term is stored on the DataHubat RPTU .

Once the project is complete, the target dataset and the associated scientific results will be published. We are aiming for open access publication via conference papers, preprints and submission of the dataset to a Zenodo repository is achieved. In the case of particularly large datasets that cannot be published in full due to their size (e.g. extensive image data from high-speed cameras), we provide the evaluation algorithms used with a representative raw dataset. Finally, the results are published in a peer-reviewed journal article.

The properties of the data are consistently stored in metadata records (JSON templates). This structured description enables clear identification and referencing of data records.

Where possible, data collection and relevant processing steps are linked to an electronic lab notebook(eLabFTW) via unique identifiers, which also serves as an interface to the laboratory organization . In this way, the origin, processing steps and tools used - such as sensors, software, test setups, models or calibration procedures - are documented in a traceable manner via the data history.

The metadata thus depicts both the individual processing steps and the methods and tools used along the data creation chain. Storage locations and archiving times are systematically recorded and managed.

Our research data management is based on the institute's own metadata model, which is implemented as a hierarchical JSON template . The structure is conceptually based on ISA modeling and combines a fixed project folder structure with machine-readable metadata.

Project structure

A fixed folder structure is created for each research project in which all employees work. The project folder contains

• an administration folder (Project_Administration),
• several thematic subprojects (Subproject_1, Subproject_2, ...),
• a Python script (Assembler.py)
• and all meta information belonging to the project in the MetaData.json file.

The subprojects (Subproject_1, Subproject_2, ...) in turn contain data folders for raw data and processed data.

Metadata snippets

The metadata is stored decentrally as JSON snippets in the respective project folders. This enables low-threshold and clear maintenance of the metadata.

The administration folder contains metadata on the project organization, which is based on the requirements of the DFG requirements:

1. Data description
2. Documentation and data quality
3. Storage and technical backup
4. Legal framework
5. Data exchange and long-term accessibility
6. Responsibilities and resources

Additional metadata is available in the sub-projects:

• Project content and responsible parties
• Data sets (raw data, simulations, models, derived data)
• Sensors, software, models or calibrations used
• References to publications or external data sets.

Automatic metadata aggregation

The Python script Assembler.py recursively searches the entire project structure and identifies all existing JSON snippets. These are automatically merged into a complete metadata file. The resulting MetaData.json is archived together with the project and documents the complete data history even if individual raw data is no longer available for storage or data protection reasons.