Як адаптувати міжнародні стандарти метаданих
Міжнародні стандарти метаданих надають загальні властивості, визначення, ідентифікатори та контрольовані значення для опису дослідницьких об'єктів у репозиторіях, каталогах та інформаційних системах.
У цьому керівництві пояснюється, як створити локальний профіль програми на основі міжнародного стандарту без зміни його початкової семантики. Воно охоплює вибір стандарту, відображення полів, локальні зобов'язання, багатомовні мітки, контрольовані словники, розширення, валідацію та управління профілями.
Інформація про ресурс
Тип ресурсу
Керівництво з розробки профілю програми метаданих
Цільові користувачі
Фахівці з метаданих, менеджери репозиторіїв, розпорядники даних, куратори та розробники
Рекомендоване використання
Проектування профілів метаданих, конфігурація репозиторію, каталогізація та проекти сумісності
Пов'язані результати
Документований, версіонований та технічно реалізований профіль локальної програми
Що означає адаптація?
Адаптація означає вибір та обмеження елементів з існуючого стандарту метаданих для визначеної спільноти, репозиторію, дисципліни або інформаційної системи.
Отриманий профіль програми визначає, які властивості використовуються, які є обов'язковими, які можуть повторюватися, які контрольовані значення приймаються, як відображаються локальні поля та як записи перевіряються.
Адаптація не означає зміну стандарту
Локальний профіль може надавати українські мітки, приклади, додаткові зобов'язання та специфічні для домену розширення. Він не повинен перевизначати значення міжнародної властивості або замінювати її канонічний ідентифікатор непов'язаним локальним полем.
Стандарт, словник та профіль застосування
Схема метаданих
Визначає властивості, структури, потужності, типи значень та технічні представлення для записів метаданих.
Словник метаданих
Визначає властивості або поняття зі стабільними назвами, ідентифікаторами та семантичними визначеннями.
Профіль програми
Вибирає та обмежує терміни з одного або кількох стандартів для конкретної реалізації або спільноти.
Перехід
Документує зв'язки між полями у двох схемах або між локальним профілем та зовнішнім стандартом.
Вибір відповідного стандарту
Виберіть базовий стандарт відповідно до типу ресурсу, цільової системи та необхідної сумісності.
| Стандарт або профіль | Рекомендоване призначення | Типове використання |
|---|---|---|
| Схема метаданих DataCite | Ідентифікація, цитування та зв'язування наборів даних та інших результатів досліджень | Реєстрація DOI, метадані репозиторію та зв'язки між об'єктами дослідження |
| Терміни метаданих DCMI | Загальний семантичний опис цифрових та фізичних ресурсів | Інституційні системи, пов'язані дані та легкі міждоменні описи |
| DCAT | Опис каталогів, наборів даних, сервісів даних та розподілу | Портали відкритих даних, інституційні каталоги та федеративні каталоги даних |
| Керівні принципи OpenAIRE | Надання метаданих для агрегації в OpenAIRE | Збір даних з репозиторію, валідація та реєстрація джерел даних OpenAIRE |
| Дисциплінарний стандарт | Доменно-специфічні наукові змінні, методи та об'єкти | Матеріалознавство, геноміка, геологічні науки, соціальні науки та інші галузі |
Основні принципи адаптації
Збереження семантики
Збереження оригінального значення та ідентифікатора кожної повторно використаної властивості.
Обмеження документа
Чітко визначення локальних зобов'язань, кардинальності, типів значень та правил перевірки.
Повторне використання ідентифікаторів
Використовуйте канонічні URI властивостей, постійні ідентифікатори та визнані терміни словника, де це можливо.
Прозоре розширення
Додавайте локальні або дисциплінарні поля лише тоді, коли жодна відповідна існуюча властивість не може представляти вимогу.
Робочий процес розробки профілю метаданих
Розробіть профіль програми за допомогою задокументованої послідовності від визначення випадку використання до перевірки та управління.
1. Визначення
Визначте ресурси, користувачів, системи та цілі сумісності.
2. Вибрати
Вибрати базовий стандарт, цільовий профіль та точні версії.
3. Зіставити
Зіставити вимоги до локальної інформації з канонічними властивостями.
4. Обмеження
Визначення зобов'язань, кардинальності, правил значення та розширень.
5. Перевірка
Тестування записів прикладів, затвердження профілю та керування його версіями.
Крок 1 — Визначення випадку використання
Профіль метаданих слід розробляти для визначеного набору ресурсів, систем та користувачів, а не для кожного можливого об'єкта дослідження.
Питання для вирішення
- Які типи ресурсів описуватиме профіль?
- Хто створює, переглядає та використовує метадані?
- Яке сховище, каталог або CRIS зберігатиме записи?
- Які зовнішні системи повинні отримувати або збирати метадані?
- Які наукові дисципліни охоплюються?
- Які завдання пошуку, звітності та повторного використання повинні підтримуватися?
- Які українські правові чи організаційні вимоги застосовуються?
Крок 2 — Вибір та встановлення версій базових стандартів
Запишіть точну версію схеми або словника, на якій базується локальний профіль. Не визначайте реалізацію лише як таку, що використовує «найновішу» версію.
Запис версії
Назва профілю: Профіль метаданих набору дослідницьких даних України
Версія профілю: 1.0
Базова схема: Схема метаданих DataCite
Версія базової схеми: 4.7
Додатковий словник: Терміни метаданих DCMI
Цільовий профіль сумісності: Керівні принципи OpenAIRE для архівів даних
Статус профілю: Чернетка
Дата затвердження: РРРР-ММ-ДДКрок 3 — Збір місцевих вимог до інформації
Створіть перелік інформації, яка наразі збирається дослідниками, репозиторіями, установами та національними інформаційними системами.
| Вимога | Джерело | Мета |
|---|---|---|
| Назва та опис набору даних | Репозиторій та дослідники | Виявлення та інтерпретація |
| Творці, учасники та афіліації | Репозиторій, CRIS та інституційна звітність | Атрибуція та відповідальність |
| Програма фінансування та номер проекту | Грантові та інституційні вимоги | Звітність та Зв'язок між дослідженнями та результатами |
| Наукова галузь та класифікація | Репозиторій та національні класифікації | Пошук, статистика та агрегація |
| Доступ та правові обмеження | Автори, етика та правова експертиза | Управління доступом |
| Дисциплінарні методи та змінні | Дослідницькі спільноти | Наукова інтерпретація та повторне використання |
Крок 4 — Створення переходу метаданих
Зіставте кожну локальну вимогу з найближчою семантично еквівалентною міжнародною властивістю. Чітко записуйте невизначені, часткові та непідтримувані зіставлення.
| Локальна вимога | Представлення DataCite | Представлення DCMI | Примітка щодо зіставлення |
|---|---|---|---|
| Назва набору даних | Titles.title |
dcterms:title |
Пряме зіставлення |
| Створювач набору даних | Creators.creator |
dcterms:creator |
Зберегти структуру особи та ідентифікатор |
| Опис | Descriptions.description |
dcterms:description |
Виберіть відповідний тип опису, де потрібно |
| Ідентифікатор набору даних | Ідентифікатор |
dcterms:identifier |
Зберегти схему ідентифікаторів |
| Тема або ключове слово | Subjects.subject |
dcterms:subject |
Зберегти словниковий запас та URI концепцій |
| Ліцензія | Права |
dcterms:license |
Зберігати ліцензію окремо від статусу доступу |
| Пов'язана публікація | RelatedIdentifier |
dcterms:relation або більш конкретний зв'язок |
Зберегти тип ідентифікатора та тип зв'язку |
| Дата публікації | PublicationRic та, де це доречно, Дати |
dcterms:issued |
Не завжди однозначне зіставлення |
Не вважайте, що подібні назви полів еквівалентні
Порівнюйте визначення та правила використання, а не лише мітки. Властивості зі схожими назвами можуть представляти різні ролі, події або рівні опису.
Типи зв'язків зіставлення
Кожен зв'язок пішохідного переходу має вказувати, наскільки близько відповідають властивості джерела та цілі.
Точно
Властивості джерела та цілі представляють одну й ту саму концепцію та рівень опису.
Ширша або вужча
Одна властивість є більш загальною або більш конкретною, ніж інша.
Умовна
Відображення дійсне лише для певних значень, типів ресурсів або умов реалізації.
Немає еквівалента
Локальна вимога потребує розширення або не може бути експортована до цільової схеми.
Крок 5 — Визначення обов'язковості та кардинальності
Локальний профіль може зробити необов'язкову міжнародну властивість обов'язковою для конкретного випадку використання. Це обмеження локального профілю, а не зміна початкового стандарту.
| Правило профілю | Значення |
|---|---|
| Обов'язковий | Властивість має бути присутня в кожному відповідному записі |
| Обов'язковий, коли застосовується | Властивість має бути присутня, коли існує відповідна інформація або застосовується умова |
| Рекомендований | Властивість слід надавати, коли це можливо |
| Необов'язковий | Властивість може бути надано |
| Не використовується | Властивість не включена до цього профілю |
| Кардинальність | Визначає мінімальну та максимальну кількість входжень, наприклад, 1, 0–1, 1–n або 0–n |
Рекомендована специфікація поля
Локальна мітка:
Канонічна властивість:
Визначення:
Мета:
Зобов'язання:
Кардинальність:
Тип значення:
Контрольований словник:
Схема ідентифікатора:
Підтримка мови:
Правило перевірки:
Приклад:
Примітка зіставлення:
Стандарт джерела:
Версія джерела:Крок 6 — Вибір контрольованих словників
Використовуйте контрольовані значення для полів, які потребують послідовної класифікації, перевірки або машинної обробки.
| Тип поля | Рекомендоване значення керування |
|---|---|
| Тип ресурсу | Список контрольованих типів ресурсів, визначений базовим стандартом або профілем |
| Роль учасника | Стандартний словник учасника або ролі |
| Тип зв'язку | Словник контрольованого типу зв'язку |
| Стан доступу | Визначено Словник прав доступу та URI, де потрібно |
| Ліцензія | Назва та URI авторитетної ліцензії |
| Мова | Код стандартної мови |
| Формат файлу | Тип носія або значення реєстру документованого формату |
| Наукова тема | Відповідний загальний або дисциплінарний словник |
Крок 7 — Підтримка постійних ідентифікаторів
Результати дослідження
DOI, ідентифікатор, номер доступу або інший авторитетний ідентифікатор.
Люди
ORCID або інший підтримуваний ідентифікатор особи.
Організації
ROR або інший авторитетний ідентифікатор організації.
Проекти та фінансування
Постійні або авторитетні ідентифікатори грантів, нагород та проектів.
Зберігайте як значення ідентифікатора, так і його схему. Не перетворюйте різні типи ідентифікаторів на недиференційований текст або локальні числові коди.
Крок 8 — Локалізація міток без зміни машинних значень
Інтерфейс користувача та інструкції щодо заповнення можуть бути надані українською та англійською мовами. Канонічні ідентифікатори властивостей, словниковий запас, коди та технічні значення повинні залишатися незмінними.
Шар, що зчитується людиною
- Мітка поля українською мовою;
- Мітка поля англійською мовою;
- Інструкція із заповнення;
- Приклади місцевими мовами;
- Пояснення інституційної практики.
Шар, що зчитується машиною
- Ідентифікатор канонічної властивості;
- Код контрольованого словника або URI;
- стандартна схема ідентифікаторів;
- тег мови;
- визначений тип даних та синтаксис.
| Шар | Приклад |
|---|---|
| Українська мітка | Назва набору даних |
| Англійська мітка | Назва набору даних |
| Канонічна властивість | DataCite: Titles.title |
| Локальна інструкція | За потреби вкажіть конкретну назву, що визначає об'єкт дослідження, метод та обсяг. |
Крок 9 — Додавання локальних та дисциплінарних розширень
Додавайте локальну властивість лише після підтвердження того, що вимога не може бути представлена існуючою властивістю, підвластивістю, контрольованим словником або пов'язаним об'єктом.
Документуйте кожне розширення
- локальний ідентифікатор властивості;
- читабельні для людини мітки;
- визначення та призначення;
- очікуваний тип значення;
- зобов'язання та кардинальність;
- контрольований словник, де це можливо;
- зв'язок із зовнішніми властивостями;
- поведінка експорту та втрати інформації.
Надавайте перевагу пов'язаним розширенням перед ізольованими полями
Блок метаданих, специфічний для домену, має бути явно підключений до запис основного набору даних, щоб загальні метадані виявлення залишалися сумісними, водночас зберігаючи дисциплінарні деталі.
Крок 10 — Визначення технічних представлень
Профіль застосунку повинен відрізняти свою концептуальну модель від форматів, у яких обмінюються або зберігаються записи.
Форма репозиторію
Поля інтерфейсу користувача, що використовуються для введення та перегляду метаданих
JSON
Структуровані метадані для API, локальних пакетів та автоматизованої обробки
XML
Обмін, перевірка та Збір даних з репозиторію
RDF або JSON-LD
Представлення зв'язаних даних з використанням постійних URI властивостей та концепцій
Крок 11 — Розробка правил перевірки
| Рівень перевірки | Приклад перевірки |
|---|---|
| Наявність | Обов'язкова властивість присутня |
| Кардинальність | Властивість знаходиться в межах дозволеного мінімуму та максимуму |
| Тип даних | Дата, URI, ідентифікатор, число або тег мови мають дійсний синтаксис |
| Контрольоване значення | Значення належить до дозволеного словника |
| Умовне правило | Дата закінчення ембарго присутня, коли статус доступу заборонено |
| Правило зв'язку | Пов'язаний ідентифікатор має як тип ідентифікатора, так і тип зв'язку |
| Узгодженість між полями | Інформація про ліцензію, статус доступу та права не суперечить одна одній |
| Розв'язка | Постійний ідентифікатор розв'язується як цільовий об'єкт |
Крок 12 — Перевірка профілю
Перевірте профіль, використовуючи репрезентативні записи, а не один простий приклад.
Рекомендовані тестові записи
- відкритодоступний набір даних;
- обмежений або заборонений набір даних;
- набір даних з кількома авторами та афіліаціями;
- фінансований набір даних з пов'язаною публікацією;
- версійний набір даних;
- набір даних з дисциплінарними метаданими;
- багатомовний запис набору даних;
- запис, що містить локальні розширення.
Керування профілем та його версіями
Профіль метаданих вимагає документованої відповідальності за затвердження, впровадження, підтримку та майбутні оновлення.
| Елемент управління | Необхідне рішення |
|---|---|
| Власник профілю | Організація або група, відповідальна за профіль |
| Технічний менеджер | Особа або команда, яка підтримує схеми та валідатори |
| Процес затвердження | Процедура затвердження нових полів та версій профілю |
| Журнал змін | Документовані додавання, видалення та змінені обмеження |
| Політика сумісності | Правила зворотної сумісності та міграції |
| Цикл перегляду | Регулярний перегляд після змін у зовнішніх стандартах або системах |
| Політика припинення підтримки | Процедура видалення полів без втрати існуючих метаданих |
Необхідна документація профілю
Специфікація профілю
Властивості, визначення, зобов'язання, кардинальності та правила значень
Перехід
Зіставлення між локальними, базовими стандартними та цільовими полями профілю
Посібник з впровадження
Інструкції щодо репозиторію, API, XML, JSON або RDF-представлення
Пакет валідації
Правила, приклади, тестові записи та очікувані результати валідації
Поширені проблеми адаптації
Переклад замість зіставлення
Мітки полів перекладено, але канонічні властивості та їхня семантика не задокументовані.
Одне поле для кількох концепцій
Автори, автори, контакти та установи об'єднані в одному неструктурованому текстовому полі.
Змінена семантика
Міжнародна властивість повторно використовується для локального значення, яке не відповідає її визначенню.
Неконтрольовані локальні значення
Стандартні коди та URI замінюються несумісними варіантами вільного тексту.
Відсутня інформація про версію
Профіль не визначає, яку версію вихідного стандарту він реалізує.
Надмірне розширення
Додано численні локальні поля, хоча існуючі міжнародні властивості можуть представляти цю інформацію.
Експорт із втратами
Повторювані значення, ідентифікатори або зв'язки зводяться в один текстовий рядок під час експорту.
Без управління
Зміни вносяться без схвалення, документації або правил міграції.
Рекомендований метод роботи
Зберігайте профіль програми, перехрестя, списки контрольованих значень, правила перевірки та приклади як окремі, але версійні компоненти одного пакета профілю.
Перш ніж затверджувати нову версію профілю, тестуйте кожну зміну на наявність записів репозиторію та всі цільові формати експорту.
Важливі примітки
- Записуйте точну версію кожного вихідного стандарту та цільового профілю сумісності.
- Зберігайте канонічні ідентифікатори властивостей та визначення стандартів.
- Розглядайте українські та англійські мітки як елементи інтерфейсу та інструкцій, а не як нові властивості метаданих.
- Зберігайте статус доступу, ліцензію, власника прав та процедуру доступу як окремі поняття.
- Зберігайте повторювані поля, вкладені структури, ідентифікатори та типи зв'язків під час експорту.
- Додавайте локальні поля лише тоді, коли існуюча властивість не може відображати вимогу.
- Документуйте втрату даних, коли багатий локальний профіль зіставляється з простішим цільовим форматом.
- Перевіряйте як окремі записи, так і експортовані дані репозиторію.
- Переглядайте профіль після змін у DataCite, DCMI, DCAT, OpenAIRE або програмному забезпеченні репозиторію.
- Не називайте локальний профіль офіційним стандартом DataCite, Dublin Core або OpenAIRE.