Чим відрізняються "основні", "допоміжні", "сирі" та "оброблені" дані у практиці репозиторіїв?
Додано: П'ят серпня 15, 2025 10:04 am
Чим відрізняються "основні", "допоміжні", "сирі" та "оброблені" дані у практиці репозиторіїв?Чи варто публікувати всі типи даних?
Коротко: ці чотири терміни описують різні виміри набору.
• "Сирі" vs "оброблені" — це про ступінь обробки.
• "Основні" vs "допоміжні" — це про роль у дослідженні.
-----------------------------------------
Визначення (практично)
Сирі дані (raw) — первинні вимірювання/вивантаження без змін: логери сенсорів, вихід мікроскопа, FASTQ з секвенатора, оригінальні зображення тощо.
Проміжні (interim) — очищені/нормалізовані/злиті, але ще не остаточні.
Оброблені (processed/derived) — фінальні таблиці/куби/фігури, на яких базуються результати статті.
Основні (core/primary) — те, що безпосередньо підтримує висновки (мінімальний потрібний набір).
Допоміжні (ancillary/supplementary) — корисні, але не критичні: додаткові експерименти, фото установок, raw скрипти, демо-файли, постери, візуалізації.
-----------------------------------------Подумайте про дані як про вісь: raw → interim → processed, і окремо — мітку їхньої ролі: core або ancillary. Це допоможе зрозуміло структурувати публікацію.
Приклади (типові кейси)
• Експериментальні сенсори:
— raw: хвилинні/секундні лог-файли з приладу;
— interim: очищені від викидів, уніфіковані одиниці;
— processed (core): добові агрегати, що лягають у фігури статті;
— ancillary: фото калібрування, схеми стенду, проміжні графіки.
• Зображення/мікроскопія:
— raw: TIFF/RAW кадри;
— interim: вирівнювання, шумозменшення;
— processed (core): сегментовані маски, підрахунки об’єктів;
— ancillary: анімації/відео, скрипти візуалізації.
• Оміки:
— raw: FASTQ/RAW для MS;
— interim: вирівнювання/піки;
— processed (core): матриці counts/TPM, таблиці диф. експресії;
— ancillary: списки маркерів, додаткові QC-звіти.
-----------------------------------------
Що саме публікувати? Мінімальний набір
- Оброблені (processed) core-дані — те, на чому ґрунтується публікація (таблиці/масиви/фігури в машинозчитуваному вигляді).
- Метадані та опис: README, data dictionary (опис змінних), маніфест файлів, спосіб цитування.
- Код/скрипти, що відтворюють processed з raw (якщо це можливо опублікувати).
- Changelog версій — що змінилося.
- Raw, якщо вони нечутливі, адекватного обсягу та не порушують політики (етика/комерційна таємниця).
- Interim, якщо вони корисні для повторного аналізу або навчання моделей.
- Ancillary файли (схеми, фото, протоколи) — підвищують розуміння, але позначайте їхню роль.
-----------------------------------------Коли є обмеження (конфіденційність/розмір): публікуйте processed + докладний опис процесингу, а для raw — вкажіть, де їх отримати (контрольований доступ/звернення до авторів/дзеркало у дисциплінарному сховищі).
Структура папок і мітки у репозиторії
Рекомендований шаблон:
Код: Виділити все
dataset-root/
├─ data/
│ ├─ raw/
│ ├─ interim/
│ └─ processed/
├─ code/
├─ docs/
└─ metadata/ (README, CHANGELOG, data_dictionary.csv, file_manifest.csv, relationships.csv)
- Завантажуйте з directoryLabel, щоб зберегти структуру.
- У описі файлу вказуйте роль: Raw / Interim / Processed і Core / Ancillary.
- Додавайте теги файлів: Data / Code / Documentation / Supplementary.
- Ведіть file_manifest.csv з полями і
Код: Виділити все
file_path, role, derived_from.Код: Виділити все
checksum
Код: Виділити все
file_path,role,description,derived_from,checksum_sha256
data/processed/results_v1.2.parquet,processed|core,"Фінальні результати",data/interim/clean_v1.2.parquet,9c56cc51...
docs/setup_photos.zip,documentation|ancillary,"Фото установки",,
Чи варто публікувати всі типи даних?
Ідеально — так, але з урахуванням обмежень:
- Етика/конфіденційність: людські/персональні дані — тільки знеособлені або в контрольованих архівах.
- Обсяг і ліміти сховищ: великі raw можуть бути дорожчими для зберігання; іноді краще дисциплінарне сховище з великими квотами.
- Якість і підтримка: якщо raw хаотичні/погано документовані — витратьте час на мінімальний опис або не публікуйте до впорядкування.
- Відтворюваність: якщо raw недоступні — забезпечте максимально прозорий шлях відтворення processed (кроки, версії інструментів, параметри).
- Публікуйте processed core + код + документацію обов’язково.
- Додавайте interim, якщо вони значущі для повторного аналізу.
- Додавайте raw, якщо це безпечно/можливо; інакше — “metadata-only record” + інструкція отримання.
Іменування, щоб було ясно без метаданих
Код: Виділити все
projx_temp_raw_2025-08-15.csv
projx_temp_interim_cleaned_v1.0.csv
projx_temp_processed_daily_v1.2.parquet
projx_images_raw_cam01_2025-08-15T101530Z.tif
projx_counts_processed_v2.0.tsv
Версії та цитування
- Для кожної публічної версії набору ведіть CHANGELOG і оновлюйте version (vX.Y) в описі.
- У цитаті вказуйте конкретну версію (або Version DOI, якщо сховище його надає).
- Якщо raw і processed публікуються окремо — дайте перехресні посилання (RelatedIdentifier / IsDerivedFrom).
Запитання до спільноти
- Які критерії ви застосовуєте, щоб вирішити публікувати raw?
- Чи зберігаєте interim у версіях? У яких кейсах це реально допомогло?
- Які теги/ролі файлів ви використовуєте у Dataverse/Zenodo/Figshare?
Шаблон структури набору (ZIP)Прикріплений файл: dataset-structure-template.zip — містить папки data/raw, data/interim, data/processed, code, docs, metadata і заготовки:
README.md, CHANGELOG.md, data_dictionary.csv, file_manifest.csv, relationships.csv, LICENSE.txt, CITATION.cff, SHA256SUMS.txt.
Після розпакування оновіть метадані під свій набір.
-----------------------------------------
Приклад file_manifest.csv (розширений)
Підтримує кілька ролей через “|”, посилання на джерела у полі derived_from через “;”.
Код: Виділити все
file_path,role,description,derived_from,checksum_sha256,license
data/raw/siteA_2025-08-15.csv,raw,"Сирі сенсори, 1 Гц",,e3b0c44298fc1c149afbf4c8996fb924,CC-BY-4.0
data/interim/siteA_2025-08-15_clean.csv,interim,"Очищення (фільтр Калмана)","data/raw/siteA_2025-08-15.csv",a7f5f35426b927411fc9231b56382173,CC-BY-4.0
data/processed/siteA_daily_2025-08-15.parquet,processed|core,"Добові агрегати","data/interim/siteA_2025-08-15_clean.csv",9c56cc5180c2,CC-BY-4.0
docs/setup_photos.zip,documentation|ancillary,"Фото установки та калібрування",,5d41402abc4b2a76,CC-BY-4.0
code/etl_clean_v0.3.py,code,"Скрипт очищення; параметри у README",,098f6bcd4621d373cade4e832627b4f6,MIT
• role — одна або кілька: raw, interim, processed, core, ancillary, code, documentation.
• derived_from — шлях(и) до джерел у цьому ж наборі або DOI інших наборів.
• checksum_sha256 — контрольна сума для перевірки цілісності (згенеруйте командою нижче).
Код: Виділити все
sha256sum */* > SHA256SUMS.txtПриклад relationships.csv
Код: Виділити все
source,target,relation
data/interim/siteA_2025-08-15_clean.csv,data/raw/siteA_2025-08-15.csv,IsDerivedFrom
data/processed/siteA_daily_2025-08-15.parquet,data/interim/siteA_2025-08-15_clean.csv,IsDerivedFrom
docs/setup_photos.zip,data/processed/siteA_daily_2025-08-15.parquet,IsDocumentationOf
Нотатки для Dataverse/DataverseUA
• Завантажуйте файли зі збереженням структури папок (через directoryLabel або архіватор інтерфейсу).
• У описі файлів вказуйте роль: Raw / Interim / Processed / Core / Ancillary / Code / Documentation.
• Додавайте посилання між файлами у derived_from (маніфест) і у полі “Related Material / Related Dataset” (метадані набору).