21/01/2026
RDA і MARC21 часто згадують разом, але вони виконують різні ролі в екосистемі каталогізації. Найпростіше уявити це так:
RDA відповідає на питання “що саме ми описуємо і за якими правилами/семантикою?”
MARC21 відповідає на питання “у які поля/підполя і в якому кодуванні ми це запишемо в бібліотечній АБІС?”
Нижче — як саме вони пов’язані.
1) Різні рівні: “контент-стандарт” vs “формат обміну/запису”
RDA (Resource Description and Access)
Контент-стандарт: визначає які атрибути ресурсу фіксувати і як формулювати дані (транскрипція, джерело інформації, мова/писемність, ідентифікатори, взаємозв’язки між сутностями тощо).
Оперує моделлю сутностей і зв’язків (у сучасній RDA — LRM-підхід): Work/Expression/Manifestation/Item, Agent тощо, та відносинами між ними.
MARC21
Формат бібліографічних/авторитетних/холдингових записів: поля, підполя, індикатори, коди, фіксовані позиції.
Сильний у сумісності між системами, але це “контейнер”, а не правила опису.
Ключова думка: RDA не є “форматом”, а MARC21 не є “правилами”. RDA визначає зміст і структуру даних на семантичному рівні, MARC21 — спосіб кодування і передачі.
2) Як RDA “вміщується” в MARC21 на практиці
У реальних системах (включно з Koha) зазвичай роблять так:
Каталогізатор описує ресурс за правилами RDA.
Система зберігає/обмінюється цими даними у MARC21, розкладаючи атрибути RDA по полях/підполях.
Це називають “RDA-in-MARC”: тобто RDA як логіка опису, MARC як реалізація/упаковка.
3) Які “маркери” в MARC21 вказують, що запис зроблено за RDA
Найтиповіші сигнали (на практиці це залежить від політики установи):
040 $e rda — у бібліографічному записі: вказує, що опис сформовано за RDA (підполе про “правила опису”).
336/337/338 — “Content/Media/Carrier type”: це поля, які масово прийшли в практику саме з RDA-логіки (розділення змісту, медіа і носія).
drop-in replacement для старого GMD (245 $h) та частково 007/008-логіки.
Часто також зустрічаються:
264 (виробництво/публікація/розповсюдження/виготовлення/копірайт) як структурованіший підхід порівняно з 260.
3xx блок (крім 336–338 є й інші: 340, 344, 347 тощо) для детальніших характеристик носія/файлу/звукозапису.
4) “Карта відповідності”: RDA елемент → MARC поле/підполе
RDA говорить “запишіть елемент”, а ви обираєте, куди його класти у MARC. Наприклад:
Назва (RDA) → 245, 246
Відповідальність → 245 $c + авторизовані точки доступу 1xx/7xx
Видавничі дані → 264 (або 260 у старішій практиці)
Тип вмісту/медіа/носія → 336/337/338
Ідентифікатори (ISBN тощо) → 020, 024
Зв’язки між сутностями (наприклад, переклад, адаптація, частина серії) → 7xx/76x–78x, 8xx, примітки 5xx (залежно від типу зв’язку)
Важливо: відповідність не завжди 1:1. Один RDA-елемент може “розмазуватись” по MARC (наприклад, відносини), або навпаки — одне MARC поле може містити кілька RDA-елементів (традиційна MARC-компресія даних).
5) Напруга між RDA і MARC21: чому інколи “незручно”
RDA задумано як більш “графова” модель даних (сутності + зв’язки). MARC21 історично — плоский запис, де багато змісту закодовано:
індикаторами,
позиціями 008,
текстовими примітками,
“рядковими” полями, які складно перетворювати на чисті зв’язки.
Тому:
RDA краще розкривається у linked data/BIBFRAME-підходах,
але MARC ще довго залишатиметься транспортом у бібліотеках, бо сумісність, інструменти, обміни, спадщина даних.
6) Висновок для практики (особливо в Koha)
Ви можете працювати за RDA, але зберігати в MARC21 — це нормальна і найпоширеніша практика.
Якість “RDA-in-MARC” залежить від:
шаблонів фреймворків,
контрольованих словників (336/337/338),
політик по 264/260, 040 $e, відносинах у 7xx,
авторитетного контролю (щоб зв’язки між сутностями були стабільні).
Якщо ми щось пропустили, до допишіть в коментарях.
+ нова читачка в нашій колекції. Фігурка-дзвіночок, виготовлена в Тайвані з матового фарфору в 1978 році компанією Jabsco Merri-Bells.
