Пам’ятка: де публікувати дані — Zenodo vs Figshare vs DataverseUA

Опис вашого першого форуму.
Відповісти
admin
Адміністратор сайту
Повідомлень: 35
З нами з: Чет серпня 15, 2024 4:51 am

Пам’ятка: де публікувати дані — Zenodo vs Figshare vs DataverseUA

Повідомлення admin »

Пам’ятка: де публікувати дані — Zenodo vs Figshare vs DataverseUA

Навіщо репозитарій?
Репозитарій — це не «папка в хмарі», а вітрина з паспортом даних: постійна адреса (DOI), опис (метадані),
видимість у пошуку, версії та контроль доступу.

----------------------------------------------
Що є спільним для всіх платформ
  • Заповніть: назву й короткий опис укр+англ, ключові слова, ORCID авторів, ROR установи.
  • Вкажіть ліцензію (звично CC BY 4.0 або CC0).
  • Додайте README та словник полів (що означає кожна колонка, одиниці, приклад).
  • Тримайтеся машиночитних форматів (CSV/JSON/TIFF; за можливості мінімізуйте пропрієтарні).
----------------------------------------------
Zenodo
Найкраще для: швидкої публікації відкритих даних і релізів коду (GitHub → DOI).
Плюси:
  • Безкоштовно, DOI «з коробки».
  • Проста подача; режими open/embargo/restricted/closed.
  • Чудово підходить для коду і невеликих наборів.
Обмеження:
  • Доступ «за запитом» — більше ручної роботи; немає іменного доступу через академічний логін (AAI/SSO).
  • Мінімальна курація; складні політики доступу не підтримуються.
Порада: публікуйте реліз коду на GitHub і зв’яжіть з набором даних взаємними DOI.
Довідка: https://zenodo.org

----------------------------------------------
Figshare (особливо інституційний)
Найкраще для: відкритих наборів та візуальних матеріалів з гарною вітриною;
установи яка має Figshare for Institutions.
Плюси:
  • Зручний інтерфейс, колекції, DOI, попередній перегляд файлів.
  • В інституційній версії — кращі політики доступу та брендинг.
Обмеження:
  • Рівень керування доступом залежить від плану установи.
  • Для суворого іменного доступу (AAI/DUA) частіше краще інституційний Dataverse.
Порада: перевірте внутрішні вимоги університету/інституту щодо Figshare.
Довідка: https://figshare.com

----------------------------------------------
DataverseUA (інституційний)
Найкраще для: наборів з модерацією, ембарго або доступом за запитом; відповідності FAIR/EOSC; роботи з DUA.
Плюси:
  • DOI через DataCite, багаті метадані, індексація.
  • File-level restricted із кнопкою Request Access, підтримка ембарго, модерація/версійність.
  • Можлива інтеграція з AAI/SSO та правила доступу за атрибутами/ролями (ABAC) + DUA.
Обмеження:
  • Не «миттєва» публікація — є модерація/курація.
  • Потрібно заповнити мінімум метаданих перед поданням.
Порада: ідеально, коли частина файлів відкрита, а чутливі — за DUA та іменним доступом.
Довідка: про платформу Dataverse — https://dataverse.org

----------------------------------------------
Як обирати (коротко)
  • Є обмеження/ембарго або потрібен іменний доступ? → DataverseUA.
  • Немає обмежень, треба швидко і є код у GitHub? → Zenodo.
  • Є інституційний Figshare і потрібна «вітрина» для відкритих наборів? → Figshare.
  • Є сильний дисциплінарний репозитарій (GBIF, ICOS тощо)? → публікуйте там, а в DataverseUA створіть запис-«вітрину» з посиланням на DOI.
Щоб не наступити на граблі
  • Не дублюйте ті самі файли у різних місцях. Тримайте один «канонічний» DOI, в інших — запис із посиланням (RelatedIdentifiers).
  • Не викладайте «німі ZIP-файли» — додайте README і словник полів.
  • Не лишайте поле «ліцензія» порожнім — інакше інші не знатимуть, що їм дозволено.
Підсумок: DOI + прості метадані + ліцензія + README/словник = видимість і довіра. Для чутливих даних — DUA та іменний доступ через AAI/SSO.
Визначення:
ABAC, або управління доступом на основі атрибутів (англ. Attribute-Based Access Control), це модель контролю доступу, яка надає або забороняє доступ до ресурсів на основі атрибутів суб'єкта, ресурсів, середовища та операцій, а не лише на основі ідентифікатора користувача чи ролі.
DUA, або Data Use Agreement (Угода про використання даних), це юридичний документ, який регулює використання та розповсюдження даних між сторонами. Вона визначає правила, обмеження та умови, за яких одна сторона може використовувати дані, що належать іншій стороні.
admin
Адміністратор сайту
Повідомлень: 35
З нами з: Чет серпня 15, 2024 4:51 am

Re: Пам’ятка: де публікувати дані — Zenodo vs Figshare vs DataverseUA

Повідомлення admin »

Практикум-навігатор: де публікувати дані (Zenodo vs Figshare vs DataverseUA)
Мета: швидко вирішити “куди класти набір/софт”, що саме заповнювати і як зробити так, щоб набір підхопив OpenAIRE.
1) Чекліст перед публікацією
  • Тип даних: сирі / опрацьовані / похідні; розмір (МБ/ГБ/ТБ); чутливість (відкрите / обмежений доступ / ембарго).
  • Де публікувати:
    DataverseUA (інституційний/національний, колекції, версіонування, великі описи; OAI-PMH для OpenAIRE).
    Zenodo (швидко, GitHub-інтеграція для софту, DOI відразу).
    Figshare (зручні візуалізації/колекції; часто — інституційні акаунти).
  • PID/ідентифікатори: DOI для набору/релізу; ORCID авторів; ROR установи; пов’язані DOI публікацій/софту/проєктів (related identifiers).
  • Мінімальний профіль метаданих:
    — Назва (уникати “Dataset 1”), анотація (що всередині, як отримано).
    — Автори з ORCID; установа з ROR; контактний e-mail.
    — Ключові слова (із словників/онтологій); дисципліна; метод/інструмент.
    — Ліцензія (CC-BY 4.0 для відкритих; для коду — MIT/BSD/GPL/Apache-2.0).
    — Дати збирання/публікації; версія; мова.
    — Посилання на пов’язані об’єкти (публікація, софт, інший набір).
    — Формати файлів (CSV/Parquet/NetCDF/GeoTIFF/…); Readme з інструкцією відтворення.
  • Як додати в OpenAIRE (один із шляхів):
    — Репозиторій підтримує OAI-PMH та профіль OpenAIRE; у метаданих є DOI/ORCID/ROR, ліцензія, access rights.
    — Додайте інформацію про фондера/проєкт (якщо є).
    — Дочекайтесь індексації (зазвичай від кількох годин до кількох днів) — запис з’явиться в OpenAIRE Graph.
2) Decision tree: ДАНІ
  • Дані чутливі/обмежені? → Так → Публікуємо описові метадані і політику доступу (restricted/embargo). Для доступу: контакт, умови, дата зняття ембарго.
  • Ні → далі.
  • Потрібен швидкий DOI без складних структур? → Так → Zenodo.
    — Якщо є код на GitHub → підв’язати репозиторій і робити релізи (автоматичний DOI).
  • Ні → далі.
  • Потрібні колекції, централізоване адміністрування, довгі описи, версіонування, OAI-PMH?DataverseUA.
    — Створіть колекцію інституту/проєкту; завантажте файли; заповніть блоки метаданих; додайте PID/ідентифікатори.
  • Потрібні прості прев’ю/візуалізації та спільна робота з командою/університетом?Figshare (особливо, якщо є інституційний обліковий запис).
  • Розмір > кількох десятків ГБ? → Розбийте на частини або розмістіть у хмарному сховищі з посиланнями/маніфестом у записі репозиторію; перевірте ліміти конкретного сервісу.
3) Decision tree: СОФТ
  • Є публічний репозиторій коду? → GitHub/GitLab.
  • Потрібен DOI для цитування релізу?
    — GitHub ↔ Zenodo</b>: підключіть інтеграцію, зробіть Release → отримайте DOI (версійний + концептуальний).
    — Або завантажте релізний архів до Zenodo/Figshare/DataverseUA вручну з метаданими.
  • Ліцензія коду додана? → Додайте SPDX-сумісну (MIT/BSD/Apache-2.0/GPL-3.0).
  • Метадані: назва, опис, мова/платформа, залежності/сумісність, інструкція встановлення, приклади запуску, посилання на статтю/дані (related identifiers).
  • Цитування: додайте CITATION.cff (GitHub), вкажіть DOI релізу, авторів з ORCID, ROR установи.

4) Конкретні поради під платформу
  • DataverseUA: використовуйте шаблони колекцій; додавайте блочні метадані (методи/інструменти, гео, дисципліна); кладіть Readme; прикріплюйте пов’язані DOI (публікації/код).
  • Zenodo: для даних — оберіть правильну ліцензію (CC-BY/CC-0), для софту — ліцензію коду; використовуйте “Communities” для видимості; перевіряйте пов’язані ідентифікатори.
  • Figshare: структуруйте колекції; додавайте прев’ю; для великих файлів — маніфест і контрольні суми.
  • Усюди: ORCID авторів, ROR установи, grant ID; чітка анотація і ключові слова з контрольованих словників (OLS/BioPortal).

5) Мінімальні шаблони метаданих
  • Заголовок: коротко, по суті, зі словами доменної області (напр., “STM topography of…”).
  • Анотація: 4–6 рядків — що це, як отримали, що всередині, як відтворити.
  • Автори: Ім’я Прізвище (ORCID).
  • Установа: повна назва (ROR).
  • Ключові слова: 5–10, бажано з онтологій (URI за потреби).
  • Методи/інструмент: назва приладу/версія ПЗ/параметри.
  • Ліцензія: CC-BY 4.0 (дані) / MIT/Apache-2.0/GPL-3.0 (код).
  • Related identifiers: DOI статті, DOI коду/інших даних, grant ID.
  • Формати: перелік і короткий опис (CSV/Parquet/NetCDF/…).

6) Приклади лінків (для копію-вставки у тему)

7) Типові помилки, які знижують видимість
  • Немає ORCID/ROR → графи не “бачать” автора/установу.
  • Вільні ключові слова замість контрольованих термінів → поганий семантичний пошук.
  • Відсутні ліцензії → набір/код не можна легально перевикористати.
  • Немає related identifiers → втрачаються зв’язки “дані ↔ публікація ↔ код ↔ проєкт”.
  • Завантажили “як є” без Readme і форматів, що читаються (CSV/Parquet/NetCDF) → низька повторюваність.

8) Коли точно варто обрати кожен сервіс
  • DataverseUA — коли важливі колекції, довгострокове зберігання, складні метадані, національний контекст, OAI-PMH/інтеграції.
  • Zenodo — коли потрібен миттєвий DOI і/або потрібно процитувати реліз GitHub.
  • Figshare — коли зручно працювати в інституційній екосистемі з прев’ю і простими колекціями.
Відповісти