Перевірка балів

1. До перегляду результатів зафіксувати словник типів і межі портфеля.
2. Зберегти перелік або фасет із кількістю записів; відкрити приклади кожного типу.
3. Перевірити, чи позначений dataset справді містить або описує дослідницькі дані, а не PDF звичайної статті.
4. Для рівня 4 перевірити зв’язки між публікаціями, даними, кодом та колекціями.

Не є доказом: Порожній пункт меню або тип, який підтримує програмне забезпечення, але не використовує установа. Person та OrgUnit як окремі типи наукових результатів. Подвійний підрахунок Article і journal-article як різних типів.

Пропонована зміна правила. До балів вересня 2026 не застосовано. Оригінальний рівень 2 називає лише публікації та дисертації і не охоплює інші комбінації 2–3 типів. Запропоновано явне розширення, що потребує погодження. Вимогу даних і коду для рівня 4 збережено; її інституційне упередження треба враховувати при інтерпретації.

Проєкт умов для наступного циклу

0Після завершеного огляду не підтверджено жодного цифрово представленого типу результатів.
1Підтверджено один нормалізований тип.
2Підтверджено два або три нормалізовані типи.
3Підтверджено щонайменше чотири нормалізовані типи.
4Крім різноманітності рівня 3, підтверджено публікації, дослідницькі дані, програмний код і колекції та конкретні зв’язки між ними.

Доступність повного тексту

Визначити частку придатних до перевірки текстових ресурсів, повний текст яких реально доступний зовнішньому користувачу без інституційної авторизації.

Одиниця: Один текстовий інтелектуальний об’єкт; дублікати файлів і формати одного твору не утворюють нових одиниць.

Де шукати: Сторінки записів, посилання на файли, фактичні HTTP-відповіді файлів, корпусні фасети доступу з документованою семантикою.

Що дивитися: Сторінки записів; файли

Правило балів цього циклу, вересень 2026

0Повні тексти відсутні
1Менше 25 відсотків
225–49 відсотків
350–79 відсотків
480 відсотків і більше

Як перевіряти

1. Зафіксувати цільовий підкорпус і спосіб добору до завантаження файлів.
2. Для кожного об’єкта перевірити фінальну відповідь і зміст: чи це повний текст потрібного об’єкта, а не abstract, preview, сторінка входу чи помилка.
3. Позначити open, restricted, embargoed, unavailable або technical_unknown; не ототожнювати наявність ORIGINAL із відкритістю.
4. Обчислити p=100*x/N. Окремо вказати census або sample. Частку вибірки не називати часткою всього репозитарію.
5. Якщо є u технічно неперевірених об’єктів, обчислити межі 100*x/N та 100*(x+u)/N. Якщо вони перетинають межу бала — точний бал не присвоювати.

Не є доказом: has_content_in_original_bundle=true без перевірки режиму доступу. Кількість повних текстів без знаменника. Відсутність корпусного фасета як підстава довільно знизити бал. Десять зручних позитивних прикладів як оцінка всього корпусу.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Числові пороги джерела збережено, інтервали зроблено неперервними. Пропонується однозначно визначити R2 саме як публічну доступність тексту. Якщо первинно вимірювалася лише наявність файла, потрібне окреме версіонування та переоцінювання.

Проєкт умов для наступного циклу

0p=0% у визначеній і завершено перевіреній сукупності.
10%<p<25%.
225%<=p<50%.
350%<=p<80%.
480%<=p<=100%.

Версійність і представлення файлів

Розрізнити одне файлове подання, кілька змістових подань і формальне керування версіями того самого інтелектуального об’єкта.

Одиниця: Логічний ресурс із його файлами та, якщо застосовно, історією версій.

Де шукати: Переліки bitstreams/bundles, version history, локальні метадані, API relations, документована інструкція версіонування.

Що дивитися: Метадані версії; перелік файлів

Правило балів цього циклу, вересень 2026

0Не представлено
1Один файл без версії
2Кілька файлів без формальної версії
3Версії зазначаються системно
4Версії та відношення машиночитані

Як перевіряти

1. Класифікувати файли як змістові, похідні або службові.
2. Не зараховувати LICENSE, thumbnail чи автоматично видобутий TEXT як додаткову змістову версію.
3. Знайти version number/date, причину зміни та зв’язок із попередньою або наступною версією.
4. Для рівнів 3–4 застосувати загальне правило системності SYS до визначеного процесу версіонування, а не до всіх історичних творів.

Не є доказом: Два окремі числа журналу. Наявність ORIGINAL+LICENSE+TEXT як доказ трьох змістових версій. Слово version у назві документа без зв’язку між версіями.

Пропонована зміна правила. До балів вересня 2026 не застосовано. Явно запропоновано не рахувати службові/похідні файли як додаткові змістові подання. У короткій вихідній шкалі це не визначено. Нове правило може змінити R3 і має застосовуватися однаково.

Проєкт умов для наступного циклу

0Файлове подання або спосіб представлення версій не підтверджено після завершеної перевірки.
1Є лише одне змістове подання; формальної версії немає. Службові й похідні файли оцінки не підвищують.
2Є кілька змістових подань одного об’єкта, але формальної історії версій немає.
3Є документований механізм версіонування і приклади явно позначених версій, що виконують SYS.
4Умови 3 та ідентифікатори/типізовані відношення між версіями доступні в машинозчитуваному представленні.

Цифрові колекції

Оцінити, чи організовані цифрові матеріали в описані колекції зі сталою ідентифікацією та зв’язками.

Одиниця: Окрема інституційна цифрова колекція та її члени.

Де шукати: Сторінки колекцій/спільнот, collection metadata, API ієрархії та членства.

Що дивитися: Опис колекцій; навігація

Правило балів цього циклу, вересень 2026

0Відсутні
1Окремі скани
2Колекції без структурованого опису
3Структуровані колекції
4Колекції мають PID метадані та зв’язки

Як перевіряти

1. Знайти непорожні цифрові колекції й відкрити їхні об’єкти.
2. Перевірити назву, опис призначення/походження та зв’язок колекція–об’єкт.
3. Для рівня 4 перевірити PID саме колекції і структуроване членство/зв’язки, а не лише DOI окремої статті.

Не є доказом: Сторінка новини про майбутню колекцію. Текстовий список зовнішніх ресурсів без інституційної належності. PID документа замість PID колекції.

Пояснення. Правило бала цього циклу не змінено. Зміст вихідних рівнів збережено; додано одиницю аналізу, необхідні докази та запобігання підміні колекції окремим об’єктом.

Метадані

Обов’язкові описові поля

Виміряти повноту змістовного структурованого опису за наперед визначеним набором застосовних полів, не підміняючи цим правильність усіх метаданих або відповідність стандарту.

Одиниця: Пара запис–поле; знаменник — сума застосовних полів у всіх записах визначеної сукупності.

Де шукати: Повний HTML-запис, JSON API, XML/OAI.

Що дивитися: HTML-запис; OAI-PMH; API

Правило балів цього циклу, вересень 2026

0Менше 30 відсотків полів
130–49 відсотків
250–69 відсотків
370–89 відсотків
490 відсотків і більше

Як перевіряти

1. Набір цього циклу — десять слотів у research/audit-field-map-m1.csv: назва, автор, дата, тип, ідентифікатор, мова, анотація, предмет, видавець, права. Це авторський набір, не список обов’язкових полів DataCite.
2. Для кожного повністю розкритого запису слот рахується один раз, якщо змістовне значення є в будь-якому прийнятому ключі. Порожнє значення, null і None не зараховуються. Значення лише в тексті сторінки, без окремого поля, не зараховується.
3. Знаменник — число розкритих записів, помножене на 10. Однаковий набір для статті, дисертації, набору даних і коду. Профіль особи не входить.
4. Частка p = 100 × заповнені слоти / знаменник. Поріг бала береться з короткої шкали. p перед рішенням не округлюється.

Набір полів цього циклу

Поле	Зараховується, якщо є	Не зараховується
Назва	dc.title; title	порожнє значення
Автор	dc.creator; dc.contributor.author; author — якщо значення не порожнє	ім’я лише в заголовку твору; значення None
Дата	dc.date.issued; dcterms.issued; dc.date; created	рік лише в тексті сторінки
Тип	dc.type; тип у картці запису	порожнє значення
Ідентифікатор	dc.identifier.uri; handle; URI запису; локальний номер; ISSN	файл PDF сам по собі
Мова	dc.language.iso; dc.language; мова записана словом	вимога коду ISO там де мову вже записано словом або в dc.language
Анотація	dc.description.abstract; abstract	порожнє значення
Предмет	dc.subject; keyword; класифікаційний індекс	порожнє значення
Видавець	dc.publisher; publisher	порожнє значення
Права	одне з: dc.rights; dc.rights.uri; dc.rights.license; dcterms.license; license	кілька цих ключів як кілька слотів

Не є доказом: Фраза «більшість полів є» без підрахунку. Висновок про весь портфель на основі титульної сторінки одного випуску. Кількість ключів у JSON без перевірки значень. Вимога абстракту для будь-якого типу об’єкта без карти застосовності.

Пояснення. Правило бала цього циклу не змінено. Десять полів цього циклу зведено в research/audit-field-map-m1.csv 10 жовтня 2026 року. Це той самий набір, за яким уже виставлено бали 28–29 вересня. Числові пороги не змінено. Окрему карту застосовності за типом запису не запроваджено, бали не перераховувано.

Контрольовані словники

Перевірити, чи значення описових полів обираються з керованих словників, а не лише виводяться у фасетах.

Одиниця: Контрольоване поле/словник і значення у записах, до яких він застосовний.

Де шукати: Схеми форм введення, правила каталогізації, словники, URI понять, поля записів і експорт.

Що дивитися: Предметні рубрики; типи; мови

Правило балів цього циклу, вересень 2026

0Відсутні
1Вільний текст
2Окремі контрольовані поля
3Системне використання словників
4Опубліковані та пов’язані словники

Як перевіряти

1. Зафіксувати домени, в яких очікується контрольована лексика.
2. Для кожного перевірити, чи є визначений список/схема, сталі коди та змістовне відображення в записах.
3. Відрізнити фасет, автоматично складений із довільного тексту, від використання словника.
4. Для рівнів 3–4 підтвердити правило застосування і виконання SYS у заявленому обсязі.

Не є доказом: Наявність фасета сама по собі. Однаковий вигляд значень без правила чи схеми. Різні мовні варіанти терміна як автоматичний доказ дублювання: вони можуть бути пов’язаними мітками одного поняття.

Пояснення. Правило бала цього циклу не змінено. Збережено послідовність вихідних рівнів. Конкретний набір полів для системного контролю та зміст SYS мають бути визначені в протоколі.

Походження та дати змін

Встановити, чи можна простежити створення, надходження, зміну та джерело запису метаданих.

Одиниця: Запис метаданих, його службові дати, джерело або відповідальний агент; історія змін — окремий об’єкт перевірки.

Де шукати: HTML-поля Date Deposited/Last Modified/Depositing User, dc.date.accessioned, OAI header/datestamp, API history, provenance і журнали версій.

Що дивитися: Provenance; created; modified

Правило балів цього циклу, вересень 2026

0Відсутні
1Лише дата публікації
2Часткові службові дати
3Системні дати й джерело
4Машиночитана історія походження

Як перевіряти

1. Розділити дату видання/створення твору та службові дати запису.
2. Переглянути HTML і доступні експорти: відсутність поля в одному форматі не переносити на всю систему.
3. Перевірити семантику дати. OAI responseDate, granularity та earliestDatestamp сервера не є датою конкретного запису.
4. Для рівня 3 потрібні службові дати та джерело/відповідальний агент у межах SYS; для 4 — історія, а не лише поточний timestamp.

Не є доказом: Рік публікації як дата депонування. HTTP Last-Modified сторінки як автоматичний еквівалент дати зміни метаданих. OAI Identify/granularity як службова дата кожного запису. Один timestamp як повна історія походження.

Пояснення. Правило бала цього циклу не змінено. Смисл рівнів збережено. Публічні службові дати слід шукати в кількох представленнях; додано відмінність запису, ресурсу й відповіді сервера.

Якість і валідація

З’ясувати, які інституційні процедури забезпечують перевірку та виправлення метаданих.

Одиниця: Документований процес створення/редагування метаданих і приклади його виконання у визначеному ресурсі.

Де шукати: Положення про репозитарій, інструкції депозитора й адміністратора, правила імпорту, схеми форм, звіти перевірок, приклади виправлень.

Що дивитися: Правила введення; validator; документація

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Ручна неформальна перевірка
2Часткові правила
3Документована валідація
4Автоматична й ручна валідація з журналом

Як перевіряти

1. Шукати не лише public validator, а й редакторське погодження, бібліотекарську перевірку, контроль імпорту та обов’язкових полів.
2. Зафіксувати ролі, перевірювані поля, порядок повернення на виправлення та журналювання.
3. Відокремити опис можливості платформи від локального процесу.
4. Для рівня 4 потрібні докази поєднання автоматичних і ручних перевірок та журналу, а не лише слово validation.

Не є доказом: Відсутність загальнодоступного вебвалідатора як достатня підстава для 0. Назва DSpace або підтримка схеми програмою. Одна помилка в записі як доказ повної відсутності контролю. Перевірка, виконана самим аудитором, як доказ інституційної процедури.

Пояснення. Правило бала цього циклу не змінено. Рівні джерела збережено. Уточнено, що ручний інституційний контроль є допустимим доказом і не ототожнюється із вебсервісом валідації.

Ідентифікація

PID ресурсу

Перевірити наявність і працездатність постійного ідентифікатора саме оцінюваного ресурсу.

Одиниця: Один ресурс та його PID; знаменник для охоплення — ресурси погодженого підкорпуса, а не профілі людей і не бібліографічні посилання на чужі праці.

Де шукати: Поле identifier, canonical/landing page, інституційна PID-політика, DOI/Handle/URN resolver, експорт запису.

Що дивитися: DOI; Handle; URN; landing page

Правило балів цього циклу, вересень 2026

0Відсутній
1Локальний нестабільний URL
2Handle або інший PID частково
3PID для більшості ключових об’єктів
4PID системний і перевірений

Як перевіряти

1. Знайти ідентифікатор і з’ясувати, чи належить він цьому ресурсу, іншій версії чи процитованому твору.
2. Перевірити резолвер із переходом за перенаправленнями та зіставити кінцевий об’єкт за назвою/автором/ідентифікатором.
3. Локальну адресу не оголошувати нестабільною лише за виглядом URL. Перевірити заявлену політику сталості й фактичний механізм.
4. Обчислити охоплення PID у зафіксованому scope; для рівня 4 додати правило підтримання PID та виконання SYS.

Не є доказом: DOI у списку літератури замість DOI оцінюваної праці. HTTP 302 як автоматична помилка PID. HTTP 200 зі сторінкою блокування або іншим об’єктом. Локальний префікс Handle як самодостатній доказ глобальної резолюції.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Для рівня 1 слово «нестабільний» замінено на «сталість не підтверджена»: з локальної форми URL несталість не випливає. «Більшість» конкретизовано як понад 50% за визначеним знаменником; це операційне уточнення, не результат первинного вимірювання.

Проєкт умов для наступного циклу

0PID або іншого ідентифікатора ресурсу не підтверджено після завершеної перевірки.
1Є локальна адреса/ідентифікатор, але його сталість як PID не підтверджена.
2Робочі PID підтверджені для частини, але не більшості застосовних ресурсів, або охоплення більшості не встановлено.
3Робочі PID підтверджені для більш ніж 50% застосовних ресурсів у заявленій сукупності.
4Умови 3 та документоване системне надання/підтримання PID з підтвердженням SYS і відповідності ідентифікатора потрібному ресурсу.

ORCID авторів

Виміряти використання конкретних ORCID, однозначно пов’язаних з авторами, та окремо перевірити автентифіковане отримання і синхронізацію.

Одиниця: Авторська позиція: пара record_id–author_position. Показник частки записів хоча б з одним ORCID зберігається окремо і не замінює частку авторських позицій.

Де шукати: Повний запис, структурований масив авторів, профіль автора, експорт/JSON/XML, інституційна документація інтеграції ORCID.

Що дивитися: Поле ORCID; профілі

Правило балів цього циклу, вересень 2026

0Відсутній
1ORCID у тексті
2Окремі структуровані ORCID
3ORCID для більшості авторів
4Автентифікований ORCID і синхронізація

Як перевіряти

1. Зафіксувати авторські позиції та їх застосовність до ORCID.
2. Знайти конкретний iD, перевірити формат/контрольну цифру, резолюцію та зв’язок з автором. Збіг лише за ім’ям не приймати як достатній.
3. Розділити фактичний iD у тексті, структурований iD з прив’язкою до автора, ознаку authenticated та документований обмін.
4. Обчислити p=100*число позицій зі структурованим коректно прив’язаним ORCID/число застосовних авторських позицій. Вибіркове p не поширювати на весь корпус.
5. Для рівня 4 перевірити інституційний workflow OAuth/автентифікованого отримання і синхронізації та конкретне підтвердження його застосування; не збирати токени або приватні дані.

Не є доказом: Слово ORCID у назві презентації або новини. Кнопка Log in with ORCID без доказу використання отриманого iD в авторських метаданих. П’ять записів із ORCID як автоматичний доказ ідентифікації більшості співавторів. Посилання, вручну введене автором, як доказ автентифікованого отримання. ORCID у невідповідному полі без можливості встановити, якому автору він належить.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Джерело каже «більшість авторів», але не визначає одиницю. Запропоновано авторські позиції, а не унікальних осіб: це відтворюється без довільної дедублікації. Додано >50% та явну вимогу покриття для рівня 4. Застосування до старих результатів потребує звіряння первинних даних.

Проєкт умов для наступного циклу

0Після завершеної перевірки не знайдено конкретного ORCID, прив’язаного до автора.
1Є конкретний ORCID потрібного автора лише у неструктурованому тексті.
2Є структуровані ORCID окремих авторських позицій, але p<=50% або більшості авторських позицій не підтверджено.
3Структуровані ORCID коректно прив’язані до більш ніж 50% застосовних авторських позицій у заявленій сукупності.
4Умови 3 та документований автентифікований збір ORCID і синхронізація з конкретними доказами застосування в оцінюваному ресурсі.

ROR установи

Перевірити нормалізоване представлення та ROR саме релевантної установи в правильній ролі, а не будь-який знайдений ROR.

Одиниця: Зв’язок ресурс–організація–роль: афіліація автора, установа-виробник, утримувач колекції або видавець за наперед погодженим профілем.

Де шукати: Поле affiliation/institution/publisher/holding institution, профіль організації, локальний авторитетний запис, ROR record та експорт.

Що дивитися: Поле афіліації; ROR

Правило балів цього циклу, вересень 2026

0Відсутній
1Назва вільним текстом
2Нормалізована назва без ROR
3ROR у частині записів
4ROR системний у метаданих і експорті

Як перевіряти

1. Визначити цільову організацію й роль; відокремити установу від її партнера, видавця, фондодавця та підрозділу.
2. Перевірити, чи назва нормалізована через один локальний ключ, чи це лише вільний текст.
3. Зіставити конкретний ROR із назвою/доменом/зв’язками організації, не виводячи ідентичність лише зі схожої назви.
4. Перевірити збереження iD у машинозчитуваному експорті та охоплення за SYS для рівня 4.

Не є доказом: ROR знайдено лише на головній сторінці сайту. ROR 4TU як автоматичний доказ афіліації TU Delft. ROR фондодавця як заміна ROR установи автора. Збіг ror.org у повному тексті PDF.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Рівні джерела збережено; запропоновано обов’язково фіксувати роль і цільову організацію. Це усуває некоректне зарахування будь-якого ROR незалежно від семантики.

Проєкт умов для наступного циклу

0Організаційний зв’язок у застосовних записах публічно не підтверджено.
1Релевантну установу наведено вільним текстом у відповідній ролі.
2Є нормалізована назва/авторитетний ключ установи, але ROR у відповідній ролі не підтверджений.
3Коректний ROR релевантної установи підтверджено в частині застосовних записів.
4ROR системно використовується у відповідних локальних метаданих і експорті з виконанням SYS.

Дедублікація сутностей

Перевірити механізми нормалізації, авторитетного контролю та розв’язання дублювання осіб/організацій.

Одиниця: Локальна сутність особи або організації та пов’язані з нею варіанти імен і ресурси.

Де шукати: Авторитетні файли, профілі, authority keys, інструкції бібліотекарю, правила об’єднання, історія merge/correction.

Що дивитися: Авторитетні записи; профілі

Правило балів цього циклу, вересень 2026

0Відсутня
1Ручне виправлення
2Часткова нормалізація
3Авторитетний контроль
4Автоматизоване виявлення й підтвердження

Як перевіряти

1. Вибрати варіанти імен або організацій у межах погодженої вибірки без автоматичного ототожнення тезок.
2. Перевірити, чи різні мітки ведуть до одного ключа сутності і чи ресурси зв’язані з ним.
3. Знайти інституційний порядок виправлення/об’єднання дублетів.
4. Для рівня 4 перевірити автоматизоване виявлення кандидатів і контрольоване підтвердження злиття; не вимагати небезпечного автоматичного злиття лише за ім’ям.

Не є доказом: Сторінка зі списком працівників без зв’язку з ресурсами. Підтримка Person у платформі без заповнених сутностей. Однакове ім’я як достатня підстава злиття. Різні мовні мітки як доказ дублета, якщо вони вже пов’язані одним ключем.

Пояснення. Правило бала цього циклу не змінено. Збережено зміст вихідних рівнів; додано відмінність між профілем, словником і реальним механізмом дедублікації.

Інтероперабельність

OAI-PMH або API

Встановити, які інституційні інтерфейси машинного отримання даних реально працюють і як вони документовані.

Одиниця: Незалежний інтерфейс/протокол, а не кожен URL одного API.

Де шукати: Офіційна документація, посилання API/OAI, відповіді Identify, ListRecords/GetRecord, REST lists/details, інституційні журнали перевірок.

Що дивитися: Endpoint; документація

Правило балів цього циклу, вересень 2026

0Відсутні
1Endpoint недоступний або недокументований
2Один робочий інтерфейс
3Кілька документованих інтерфейсів
4Інтерфейси версійні та регулярно перевіряються

Як перевіряти

1. Знайти документований baseURL через інституційні сторінки; не перебирати довільні шляхи безконтрольно.
2. Для OAI зберегти Identify та приклад GetRecord або ListRecords; для REST — запит списку і конкретного об’єкта.
3. Перевірити тіло відповіді, відповідність схемі/об’єкту та належність даних установі.
4. Різні маршрути одного REST API не рахувати окремими інтерфейсами. OAI-PMH і документований REST можуть бути двома.
5. Для рівня 4 потрібна документація версій/змін і регулярного контролю з інституційним доказом, а не лише тестом аудитора.

Не є доказом: Лише HTTP 200. OAI Identify без тесту повернення запису як повна перевірка інтерфейсу. Випадковий /oai із 404 як доказ відсутності OAI за іншим офіційним шляхом. Глобальний API Figshare як інституційний API без підтвердженого фільтра/обсягу.

Пояснення. Правило бала цього циклу не змінено. Кількісну логіку рівнів джерела збережено. Додано визначення інтерфейсу та обов’язкову перевірку змісту; стан доступності відокремлено від оцінки публічного підтвердження.

Стандартний експорт

Перевірити фактичний експорт метаданих у загальновживаних профілях, а не лише перелік доступних кнопок або формат серіалізації.

Одиниця: Окремий семантичний профіль експорту і запис, експортований у цьому профілі.

Де шукати: Export меню, OAI ListMetadataFormats, GetRecord з відповідними metadataPrefix, API export, схема/документація профілю.

Що дивитися: Dublin Core; DataCite; CERIF; інші формати

Правило балів цього циклу, вересень 2026

0Немає експорту
1Власний формат
2Один загальний формат
3Кілька профільних форматів
4Формати задокументовані й валідовані

Як перевіряти

1. Зафіксувати заявлені профілі та фактично експортувати той самий запис у кожному.
2. Перевірити, що файл не порожній, містить правильний об’єкт і відповідає названому профілю.
3. Відокремити загальні цитувальні формати від профілів наукових/бібліотечних метаданих.
4. Для рівня 4 перевірити документацію мапування та результат валідації відповідних експортів; аудиторову перевірку не приписувати установі.

Не є доказом: Кнопка Export без отриманого файла. ListMetadataFormats без перевірки експорту. XML як самодостатня назва стандарту метаданих. Порожній DataCite XML або експорт іншого об’єкта.

Пояснення. Правило бала цього циклу не змінено. Збережено вихідні рівні; кількість форматів конкретизовано, а заявлені та перевірені формати розділено.

Типізовані зв’язки

Перевірити семантично типізовані зв’язки між ресурсами: частина/ціле, версія, додаток, дані до публікації, документування, цитування.

Одиниця: Трійка source_resource–relation_type–target_resource.

Де шукати: dc.relation з визначеною семантикою, DataCite RelatedIdentifier, API relationships, RDF, інституційні правила зв’язування.

Що дивитися: RelatedIdentifier; relations

Правило балів цього циклу, вересень 2026

0Відсутні
1Посилання в тексті
2Окремі структуровані зв’язки
3Контрольовані типи для більшості ресурсів
4Двобічні машиночитані зв’язки

Як перевіряти

1. Зберегти джерело, тип відношення та ціль і перевірити значення типу.
2. Відкрити ціль і підтвердити, що зв’язок стосується потрібного об’єкта.
3. Для кількісної оцінки більшості зафіксувати сукупність ресурсів, де зв’язки очікуються, та частку ресурсів із коректними типізованими зв’язками.
4. Для двобічності перевірити обидва напрямки там, де передбачено обернений тип; не вимагати текстово однакової назви типу у двох системах.

Не є доказом: dc.identifier.citation з бібліографічним описом самого запису. DOI будь-де у PDF. Список DOI без відомої семантики відношення. Одне ребро в API як підтвердження більшості корпусу.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Збережено логіку шкали; конкретизовано «більшість», знаменник та двобічність. Зв’язок цитування може перетинатися з V3, але оцінюється інший аспект; індикатори не слід оголошувати статистично незалежними.

Проєкт умов для наступного циклу

0Зв’язків між ресурсами не підтверджено.
1Зв’язок висловлено лише в тексті або гіперпосиланні без визначеного семантичного типу.
2Є окремі машинозчитувані типізовані зв’язки.
3Коректні контрольовані типи зв’язків підтверджено для більш ніж 50% застосовних ресурсів визначеної сукупності.
4Умови 3 та машинозчитувані двобічні/обернені зв’язки, підтверджені на обох сторонах у межах заявленого процесу.

Відповідність OpenAIRE/CRIS

Встановити підтверджену відповідність обраному профілю OpenAIRE або сумісний обмін дослідницькою інформацією CRIS/CERIF.

Одиниця: Інституційне джерело та конкретний профіль інтеграції з версією й результатом перевірки.

Де шукати: PROVIDE/реєстрова картка, звіти Validator, документація CRIS/CERIF, журнали harvesting та конкретні записи зовнішньої системи.

Що дивитися: Validator; реєстрація; CERIF endpoint

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Заявлена без доказу
2Часткова відповідність
3Успішна валідація або CRIS-обмін
4Регулярна агрегація та моніторинг

Як перевіряти

1. Зафіксувати точну назву й версію профілю, інституційний endpoint та обсяг інтеграції.
2. Розділити заяву установи, реєстрацію джерела, результат валідації та регулярний обмін.
3. Для рівня 3 зберегти звіт валідації потрібного endpoint/profile або перевірений приклад сумісного CRIS-обміну.
4. Для рівня 4 використати вже оприлюднену історію успішних циклів і моніторингу; не видавати одноразовий запит аудитора за регулярну агрегацію.

Не є доказом: Логотип OpenAIRE чи назва DSpace-CRIS. Реєстрація як гарантія поточного успішного harvesting. Валідація іншого endpoint або невказаної версії профілю. Технічна неможливість входу аудитора в PROVIDE як доказ відсутності інтеграції.

Пояснення. Правило бала цього циклу не змінено. Зміст вихідних рівнів збережено; розведено реєстрацію, валідацію та регулярну інтеграцію, які можуть мати різні докази.

Права

Статус доступу

Перевірити, чи правдиво й однозначно позначений режим доступу до конкретного ресурсу.

Одиниця: Ресурс і його статус доступу; за різних статусів файлів оцінювати також файловий рівень.

Де шукати: HTML-позначки, accessStatus/API, machine-readable rights/access fields, політика кодів стану, фактичні відповіді доступу.

Що дивитися: Open; embargoed; restricted; closed

Правило балів цього циклу, вересень 2026

0Не зазначений
1Текстова примітка
2Структуроване поле частково
3Статус для більшості об’єктів
4Статус машиночитаний і контрольований

Як перевіряти

1. Зіставити локальні значення з явно описаними станами open, embargoed, restricted, closed або еквівалентами.
2. Перевірити обсяг статусу: запис чи конкретний файл.
3. Зіставити статус із фактичним анонімним доступом, не обходячи обмежень.
4. Обчислити охоплення структурованим статусом; для рівня 4 перевірити контрольований словник, правила оновлення й SYS.

Не є доказом: Назва колекції Open access як статус кожного файла. Файл завантажується — отже, в метаданих є контрольований статус. Немає корпусного фасета — отже, машинозчитуваного статусу немає. Змішування ліцензії повторного використання зі статусом доступу.

Пояснення. Правило бала цього циклу не змінено. Шкалу джерела збережено з явним знаменником більшості; відокремлено якість опису доступу від відкритості самого контенту.

Ліцензія

Встановити, чи описано застосовні до конкретного об’єкта умови повторного використання у вигляді впізнаваної ліцензії або її машинозчитуваного ідентифікатора.

Одиниця: Ресурс/файл із конкретно призначеною ліцензією; не загальний footer сайту.

Де шукати: rights/rightsURI/rightsIdentifier, SPDX, HTML licence link, політика ліцензування, файл ліцензії із чітко визначеним предметом.

Що дивитися: CC; SPDX; URI

Правило балів цього циклу, вересень 2026

0Відсутня
1Неформальний текст
2Назва ліцензії без URI або URI не для більшості об’єктів
3URI або SPDX для більшості об’єктів
4Політика ліцензування й машиночитане подання

Як перевіряти

1. Визначити, до чого належить повідомлення: ресурс, файл, метадані, сайт чи договір депонування.
2. Зберегти фактичне значення поля, а не висновок із його назви. dc.rights.uri може містити текст, який не є URI.
3. Перевірити URI/стандартизований ідентифікатор, версію ліцензії та відповідність тексту.
4. Порахувати частку застосовних об’єктів із коректним URI або SPDX; policy та machine-readable застосування перевірити окремо.

Не є доказом: Договір дозволу на депонування як автоматична ліцензія кінцевому користувачу. Відкритий файл як дозвіл повторного використання. Назва поля rights.uri без перевірки його значення. CC BY у footer сайту як ліцензія всіх вкладених матеріалів. Текст Public domain як автоматичний URI ліцензії.

Пояснення. Правило бала цього циклу не змінено. Поточна завантажена версія вже враховує URI не для більшості на рівні 2. Збережено цю логіку та додано необхідне розмежування об’єкта, метаданих, доступу й ліцензії. Це аудит опису, не юридичний висновок про законність використання.

Ембарго й обмеження

Оцінити опис і керування часовими та іншими обмеженнями доступу, а не заохочувати сам факт закриття матеріалів.

Одиниця: Ембаргований/обмежений ресурс та інституційний механізм такого обмеження.

Де шукати: Embargo fields, availability dates, access policies, інструкція депонування, ODRL або інша машинозчитувана політика, історичні події відкриття.

Що дивитися: Дата завершення; умови доступу

Правило балів цього циклу, вересень 2026

0Не описано
1Текстова примітка
2Дата без правила
3Структуроване ембарго
4Автоматичне керування й ODRL-політика

Як перевіряти

1. Знайти політику та приклади чинних/завершених обмежень.
2. Розділити текстову заборону, дату і повний структурований зв’язок ресурс–режим–дата–умова.
3. Перевірити, чи дата належить саме завершенню обмеження.
4. Для рівня 4 потрібні документований автоматичний перехід і перевірений історичний приклад/журнал; не чекати штучно нового ембарго і не змінювати доступ самостійно.

Не є доказом: Будь-яка майбутня дата в записі. Публічна заява «ембарго підтримується» як автоматичне підтвердження реалізації в конкретному ресурсі. Відкритий сьогодні файл як доказ автоматичного зняття в минулому. Відсутність обмежених записів у вибірці як доказ незастосовності.

Пропонована зміна правила. До балів вересня 2026 не застосовано. У джерелі рівень 4 прив’язаний саме до ODRL. Запропоновано допустити документований семантично еквівалентний механізм. Це розширення критерія, яке не слід непомітно застосовувати до старих оцінок.

Проєкт умов для наступного циклу

0Застосовні обмеження чи правила їх опису публічно не визначені.
1Є текстове пояснення обмеження або ембарго.
2Є конкретна дата завершення, але не підтверджено повний структурований режим/правило.
3Режим, дата/умова завершення та відповідний ресурс структуровано пов’язані й можуть бути однозначно прочитані.
4Умови 3 та документоване автоматичне керування, машинозчитувана політика і приклад її спрацювання; ODRL або явно описаний семантично еквівалентний механізм.

Відкритість метаданих

Перевірити доступність і явно описані умови повторного використання саме метаданих.

Одиниця: Метадані ресурсу/колекції та політика, що явно поширюється на них.

Де шукати: Metadata policy, terms of use, OAI/API, data licence/CC0 statement, export documentation.

Що дивитися: Політика; API; rights for metadata

Правило балів цього циклу, вересень 2026

0Метадані недоступні
1Доступ лише через інтерфейс
2Експорт без явних умов
3Відкриті метадані з ліцензією
4CC0 або еквівалент і стале отримання

Як перевіряти

1. Перевірити окремо людський перегляд, машинне отримання й умови повторного використання.
2. Знайти чітке поширення політики на метадані визначеної системи/колекції.
3. Перевірити робоче отримання даних і заявлену стабільність інтерфейсу.
4. Не робити власного юридичного висновку про суспільне надбання метаданих за відсутності опублікованих умов.

Не є доказом: CC BY на PDF як ліцензія метаданих. Сам факт роботи OAI як доказ CC0. Загальний copyright сайту без уточнення предмета. Наявність особистого кабінету як умова відкритості всіх метаданих.

Пояснення. Правило бала цього циклу не змінено. Збережено рівні джерела; явно відокремлено ліцензування метаданих від ліцензування файлів. Визначення юридичного еквівалента CC0 потребує точного тексту умов, а не припущення аудитора.

Оцифрування

Політика цифровізації

Встановити, чи оцифрування фізичних матеріалів керується інституційними пріоритетами, планом і контролем, а не відбувається як набір непов’язаних ініціатив.

Одиниця: Програма/політика оцифрування та її обсяг: фонд, колекція або погоджений сегмент портфеля.

Де шукати: Політика цифровізації, стратегія, план колекції, проєктна документація, критерії відбору, звіти виконання.

Що дивитися: Стратегія; регламент; критерії відбору

Правило балів цього циклу, вересень 2026

0Відсутня
1Окремі ініціативи
2Частковий план
3Документована політика
4Політика пов’язана з ризиками та KPI

Як перевіряти

1. З’ясувати, чи оцифрування є функцією оцінюваного портфеля.
2. Знайти джерело з пріоритетами/критеріями відбору, відповідальними, обсягом і очікуваним результатом.
3. Розрізнити план оцифрування та політику довготривалого збереження уже цифрових об’єктів.
4. Для рівня 4 перевірити явний зв’язок із ризиками і вимірюваними показниками та оприлюдненим контролем виконання.

Не є доказом: Будь-який скан як доказ політики. Preservation policy без критеріїв оцифрування. Новина про відкриту науку без плану оцифрування. Назва грантового проєкту без його змісту й меж.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Смисл рівнів джерела збережено. Введено явну перевірку функціональної застосовності; це може змінити знаменники і не має застосовуватися лише до окремих незручних випадків.

Проєкт умов для наступного циклу

0У застосовному обсязі політику або ініціативи оцифрування публічно не підтверджено.
1Підтверджено окремі ініціативи без узгодженого плану.
2Є частковий план конкретних колекцій/проєктів із визначеним обсягом або пріоритетами.
3Є документована інституційна політика/програма з критеріями відбору, ролями та обсягом застосування.
4Умови 3 та врахування ризиків, визначені показники виконання й документований контроль/перегляд програми.

OCR і повнотекстовий пошук

Оцінити доступність машинозчитуваного тексту та повнотекстового пошуку з урахуванням походження документа: OCR для сканів, видобування тексту для born-digital.

Одиниця: Текстовий ресурс і його текстове подання; скановані та первинно цифрові документи аналізуються окремими стратами.

Де шукати: Текстовий шар PDF, sidecar text, OCR output, API bundles, пошукові результати, документація OCR/індексування, звіти якості.

Що дивитися: OCR-текст; пошуковий тест

Правило балів цього циклу, вересень 2026

0Відсутні
1Скани без пошуку
2Текстовий шар або OCR для частини колекцій
3Системний текстовий шар і пошук
4OCR із метриками якості та валідацією

Як перевіряти

1. Встановити тип походження: scan, born-digital або unknown; наявність TEXT сама по собі походження не доводить.
2. Відкрити текстове подання та порівняти фрагмент із візуальним документом.
3. Вибрати фразу з основного тексту, якої немає в назві й описі, виконати пошук і зберегти запит/результат.
4. Для рівня 3 підтвердити процес за SYS у застосовних текстових стратах.
5. Для рівня 4 перевірити задокументовані метрики та процедуру контролю: для OCR — еталон/помилки розпізнавання; для born-digital — повноту видобування/індексування. Vendor confidence не замінює оцінку на еталоні.

Не є доказом: TEXT bundle як автоматичний доказ OCR. Пошук за назвою документа як повнотекстовий тест. Відсутність OCR у born-digital тексті як автоматичний недолік. Маркетингові 99% точності провайдера як якість інституційного корпусу.

Пропонована зміна правила. До балів вересня 2026 не застосовано. Поточне джерело вже допускає текстовий шар на рівнях 2–3, але рівень 4 залишає лише OCR. Запропоновано симетричний рівень 4 для born-digital. Також уточнено назву предмета: «Машинозчитуваний текст, OCR і повнотекстовий пошук». Це зміна, яку слід погодити до переоцінювання.

Проєкт умов для наступного циклу

0Машинозчитуваного текстового подання в застосовному обсязі не підтверджено, або перевірка показала його відсутність; причина 0 фіксується окремо.
1Є цифрові зображення текстових сторінок, але текстовий шар/пошук за вмістом не підтверджені.
2Текстовий шар або OCR підтверджено для частини застосовних документів/колекцій.
3Документований процес текстового подання й пошуку підтверджений за SYS у відповідних текстових стратах.
4Умови 3 та задокументоване вимірювання якості й перевірка результату для застосовного способу отримання тексту: OCR або born-digital extraction/indexing.

Цілісність і формати

Перевірити керування форматами та контроль цілісності файлів, відрізняючи наявність checksum від документованих перевірок.

Одиниця: Файл із форматом/контрольною сумою і пов’язані з ним події перевірки та інституційні правила.

Де шукати: Bitstream metadata, checksum, форматні рекомендації, preservation events, PREMIS/METS, звіти fixity, інституційні технічні політики.

Що дивитися: Checksum; формати; PREMIS

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Формати без політики
2Рекомендовані формати
3Контрольні суми й події
4PREMIS/METS та регулярна перевірка цілісності

Як перевіряти

1. Зберегти формат, алгоритм і значення контрольної суми та ідентифікатор файла.
2. Знайти політику рекомендованих форматів із датою/версією.
3. Для подій перевірити object/file id, event type, timestamp, outcome та agent/tool.
4. Для рівня 4 перевірити не просто наявність METS/PREMIS, а зміст подій і регулярність: правило розкладу та звіт/журнал його виконання.
5. Власне обчислення checksum аудитором не є доказом регулярного інституційного контролю.

Не є доказом: Один MD5 як історія регулярних перевірок. Назва METS bundle без перегляду вмісту. Щорічний перегляд списку форматів як дата fixity-перевірки файла. Звичайний HTTP ETag без підтвердженої семантики як checksum збереженого об’єкта.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Вихідну різницю checksum/події збережено. Для рівня 4 запропоновано семантично еквівалентні preservation metadata, щоб назва контейнера не підміняла функцію. Рівні не вважаються автоматично кумулятивними: необхідні умови вказані в кожному рядку.

Проєкт умов для наступного циклу

0Публічних відомостей про формати/цілісність не підтверджено після завершеної перевірки.
1Формат файла відомий, може бути checksum, але політику форматів і події перевірки не підтверджено.
2Є документовані рекомендовані формати, але комплект доказів подій рівня 3 не підтверджено.
3Є контрольні суми та пов’язані з файлами події контролю цілісності з датою й результатом.
4Умови 3 та машинозчитувані preservation metadata PREMIS/METS або явно зіставлений еквівалент, політика регулярних перевірок і докази виконання.

Резервування і збереження

Встановити публічно підтверджену організацію резервування, довготривалого збереження та відновлення цифрових об’єктів.

Одиниця: Політика/процес збереження, що поширюється на конкретний портфель або його явно визначений сегмент.

Де шукати: Preservation policy, backup/disaster recovery policy, сторінки університетського архіву та ІТ-служби, звіти відновлення, сертифікаційні матеріали з датою і scope.

Що дивитися: Політика backup; копії

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Одна локальна копія
2Періодичні резервні копії
3Розподілене резервування
4План збереження міграція й перевірка відновлення

Як перевіряти

1. З’ясувати, що саме архівується, де, на який строк і хто відповідальний.
2. Розділити поточну реплікацію, резервні версійні копії та довготривалий архів.
3. Для періодичності шукати розклад і строк зберігання копій; для розподіленості — незалежність майданчиків/копій у межах оприлюдненого опису.
4. Для рівня 4 перевірити план міграції та документований результат тесту відновлення.
5. Політика підтверджує задокументовану практику. Без доступу до операційних даних не заявляти незалежну технічну сертифікацію її фактичного виконання.

Не є доказом: Фраза «ми зберігаємо назавжди». Можливість завантажити PDF як доказ резервної копії. Наявність окремого архіву як автоматичний доказ розподілених backup. Чинний чи прострочений сертифікат як заміна перевірки конкретного scope і критерію.

Пояснення. Правило бала цього циклу не змінено. Послідовність джерела збережено. Додано достатні умови кожного рівня і відокремлено політику, реплікацію, архівування та перевірку відновлення. Рівень 2 не є резервною оцінкою, коли доказів на 3 недостатньо.

Сервіси

Пошук і навігація

Перевірити фактичні можливості пошуку та навігації, а не лише наявність пошукового поля.

Одиниця: Погоджені користувацькі сценарії пошуку в оцінюваному портфелі.

Де шукати: Пошуковий інтерфейс, розширений пошук, фасети, browse, пов’язані об’єкти, результати контрольних запитів.

Що дивитися: Простий; розширений; фасети

Правило балів цього циклу, вересень 2026

0Пошук відсутній
1Лише простий пошук
2Розширений пошук
3Фасети й повнотекстовий пошук
4Семантичний пошук і пов’язані об’єкти

Як перевіряти

1. До тестування сформувати однакові за типом сценарії: відомий заголовок, автор, поєднання полів, фільтр типу/року, фраза з тексту де застосовно.
2. Зберегти введений запит, застосовані фільтри, кількість і релевантний приклад результату.
3. Перевірити, що фасет змінює видачу, а не є декоративним списком.
4. Для рівня 4 продемонструвати семантичний механізм: контрольовані синоніми/зв’язки сутностей або інший документований механізм і перехід між пов’язаними об’єктами.

Не є доказом: Слово semantic у рекламному описі. Фасет без контрольного застосування. Виявлення фрази з назви як тест пошуку по повному тексту. Відсутність пошуку в бінарному коді як недолік OCR.

Пропонована зміна правила. До балів вересня 2026 не застосовано. Основні рівні збережено. Для рівня 3 запропоновано еквівалентний сценарій для нетекстового обсягу; його треба погодити до оцінювання, а не вигадувати для окремої установи.

Проєкт умов для наступного циклу

0Пошук або придатну навігацію не підтверджено після завершеної перевірки.
1Працює тільки простий пошук.
2Працює розширений/багатопольовий пошук.
3Працюють фасети та повнотекстовий пошук у застосовному текстовому підкорпусі; для суто нетекстового обсягу — явно погоджений еквівалентний сценарій пошуку за змістовними метаданими.
4Умови 3 та документований і продемонстрований семантичний пошук/навігація пов’язаними об’єктами.

Доступність WCAG

Оцінити публічно перевірювані заходи доступності інтерфейсу та документованість перевірок, не видаючи короткий аудит за сертифікацію WCAG.

Одиниця: Погоджений набір сторінок і користувацьких сценаріїв; версія WCAG і цільовий рівень фіксуються до тестування.

Де шукати: Accessibility statement, HTML/ARIA, контрольні сценарії з клавіатури, автоматизований звіт і ручний протокол, оприлюднений повний аудит.

Що дивитися: Accessibility statement; keyboard; alt text

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Окремі доступні елементи
2Часткова відповідність
3Заява й основні критерії WCAG
4Регулярний аудит і WCAG AA

Як перевіряти

1. Зафіксувати версію WCAG, наприклад 2.2, і scope перевірки. Це параметр протоколу, а не припущення про сайт.
2. Перевірити базовий набір: клавіатурна досяжність, видимий фокус, назви елементів/полів, альтернативи змістовним зображенням, логіку заголовків, контраст у застосовних компонентах.
3. Записати pass/fail/NA для кожного тесту й приклади помилок.
4. Розділити автоматичні результати, ручні тести і заяву установи.
5. Для 4 потрібен змістовний звіт оцінювання AA у відповідному scope та підтверджена регулярність; нуль автоматичних помилок не є достатнім.

Не є доказом: Один aria-label як відповідність усього сайту. Наявність шаблонної accessibility statement як успішний аудит. Автоматичний сканер без помилок як доказ повної WCAG AA. Відсутність однієї з необов’язкових кнопок як доказ недоступності.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Уточнено різницю між аудиторською оцінкою заходів доступності й нормативною відповідністю WCAG. Погоджений чекліст додається окремо до протоколу; його позитивний результат не замінює повного WCAG-EM.

Проєкт умов для наступного циклу

0Позитивних заходів доступності не підтверджено після завершення погодженого базового огляду; це не висновок про всі можливі властивості сайту.
1Є окремі перевірені доступні елементи, але системного охоплення сценаріїв не підтверджено.
2У кількох сценаріях підтверджено доступні елементи/виконані перевірки, проте є нерозв’язані обмеження або неповне документування. Це не формальна «часткова відповідність WCAG».
3Є інституційна заява з обсягом/обмеженнями та успішно пройдені погоджені базові ручні й автоматичні перевірки в цьому обсязі.
4Умови 3 та повноцінний датований звіт відповідності цільовому рівню AA у визначеному scope, включно з ручною оцінкою, і документований цикл повторного контролю.

Профілі й персоналізація

З’ясувати, чи може користувач отримувати персональні функції, а не лише зареєструватися або переглянути публічний профіль дослідника.

Одиниця: Документований персональний сценарій: збереження запиту, сповіщення, добірка, персональна панель, рекомендації.

Де шукати: Публічна інструкція кабінету, help, демонстрація, дозволений тестовий доступ, налаштування рекомендацій/сповіщень.

Що дивитися: Кабінет; збережені запити; рекомендації

Правило балів цього циклу, вересень 2026

0Відсутні
1Реєстрація без персоналізації
2Збережені запити або сповіщення
3Профіль і персональні сервіси
4Контекстні рекомендації з контролем користувача

Як перевіряти

1. Визначити функції, які виходять за межі входу/реєстрації.
2. Оцінити публічну документацію з конкретними екранними прикладами або дозволений тестовий сценарій.
3. Не створювати акаунт і не підписувати користувача без окремого дозволу. Якщо потрібних доказів немає, позначити межу перевірки.
4. Для рекомендацій перевірити пояснення джерел/логіки й можливість керувати або відмовитися від персоналізації.

Не є доказом: Кнопка Log in. Публічний список праць автора без користувацьких налаштувань. Обіцянка платформи, не підтверджена локально. Приватний контент, отриманий без дозволу.

Пояснення. Правило бала цього циклу не змінено. Рівні джерела збережено. Розведено вхід, персональний сервіс і публічний профіль автора; передбачено чесне зазначення documented/directly_tested.

Комунікація та події

Оцінити канали взаємодії установи з користувачами та їх інтеграцію з подіями й комунікаційними процесами.

Одиниця: Функціональний канал взаємодії та задокументований процес подій/повідомлень.

Де шукати: Контакти репозитарію, форми, розсилки, події, реєстрація, help, політика згод і документована CRM-інтеграція.

Що дивитися: Форми; newsletter; events; CRM

Правило балів цього циклу, вересень 2026

0Відсутні
1Контактна форма
2Кілька неінтегрованих каналів
3Системне керування подіями й повідомленнями
4CRM інтегрована з профілями та згодами

Як перевіряти

1. До збору застосувати єдину класифікацію каналів: електронна пошта, телефон, форма зворотного зв’язку, підписка на розсилку, офіційний інтерактивний канал, сервіс подій.
2. Дві адреси e-mail рахувати як один тип; телефон і e-mail — як два. Посібник або статична сторінка не є самостійним каналом зворотного зв’язку.
3. Для рівня 3 перевірити процес події та повідомлень, а не лише новину про подію.
4. Для рівня 4 знайти підтверджену інтеграцію профілю, участі та згод; назва CiviCRM не є обов’язковою.
5. Не надсилати тестові листи/заявки і не підписувати адреси без дозволу.

Не є доказом: Два e-mail як автоматично два різні типи каналів. Посібник користувача як канал повідомлень. Назва CRM у новині. Наявність контактів як доказ автоматизації подій.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Оригінальний рівень 1 називає лише контактну форму. Запропоновано загальний один тип контакту та однаковий підрахунок типів. Це уточнення може змінити частину старих балів.

Проєкт умов для наступного циклу

0Канали взаємодії щодо ресурсу не підтверджено.
1Є один визначений тип контакту/зворотного зв’язку.
2Є щонайменше два різні типи каналів, але спільного процесу подій/повідомлень не підтверджено.
3Є системно описане керування подіями та повідомленнями з відповідальними й пов’язаними етапами.
4Умови 3 та інтеграція з профілями й керуванням згодами, підтверджена конкретною інституційною документацією/сценаріями.

Видимість

Індексація наукових результатів

Перевірити, чи знаходяться конкретні інституційні результати у зовнішніх пошукових/агрегаційних системах і чи установа контролює їх індексацію.

Одиниця: Зовнішня система та підтверджені в ній об’єкти саме оцінюваного портфеля.

Де шукати: Google Scholar/пошукові системи, BASE, OpenAIRE, OUCI та інші профільні індекси; конкретні зовнішні записи і джерела даних.

Що дивитися: OUCI; Google Scholar; OpenAIRE; BASE

Правило балів цього циклу, вересень 2026

0Не підтверджено
1Одна загальна пошукова система
2Дві зовнішні системи
3Кілька профільних індексів
4Контрольована індексація й виправлення помилок

Як перевіряти

1. Обрати однаковий набір класів зовнішніх систем для всіх установ, де це змістовно застосовно.
2. Шукати за точним PID/назвою та перевірити збіг об’єкта й інституційну адресу/джерело.
3. Записувати окремо repository_listing та indexed_object. Для зарахування системи за замовчуванням перевірити два різні об’єкти з фіксованої вибірки; для однооб’єктної колекції — її єдиний об’єкт.
4. Не приписувати індексацію репозитарію, якщо знайдено лише видавничу версію без зв’язку з оцінюваним джерелом.
5. Для рівня 4 перевірити інституційний моніторинг і процедуру виправлення помилок та конкретний приклад/звіт.

Не є доказом: OpenDOAR/re3data listing без конкретних проіндексованих праць. Посилання на BASE з головної сторінки. Збіг назви без підтвердження об’єкта й джерела. Невдалий пошук в одному сервісі як доказ відсутності всюди.

Пропонована зміна правила. До балів вересня 2026 не застосовано. У джерелі рівень 1 передбачає лише загальну пошукову систему й не охоплює одну профільну. Запропоновано закрити прогалину, визначити «кілька» як >=3 і розрізнити каталог репозитаріїв та індексацію об’єктів. Число контрольних об’єктів — авторське правило процедури, не стандарт.

Проєкт умов для наступного циклу

0Індексацію конкретних об’єктів у зовнішніх системах не підтверджено після завершеної перевірки.
1Індексацію об’єктів підтверджено в одній зовнішній системі — загальній або профільній.
2Індексацію об’єктів підтверджено у двох незалежних зовнішніх системах.
3Індексацію підтверджено щонайменше в трьох системах, принаймні дві з яких профільні наукові/бібліотечні.
4Умови 3 та документований контроль індексації й приклад моніторингу/виправлення помилок.

Реєстрація DOI-метаданих

Перевірити представлення конкретного наукового результату в зовнішніх DOI-метаданих і коректність їхніх зв’язків; не дублювати перевірку локального PID у P1.

Одиниця: Ресурс і відповідний зовнішній DOI-запис реєстраційного агентства; registrant і institution_of_resource фіксуються окремо.

Де шукати: Crossref/DataCite або інше належне агентство, DOI agency/резолвер, локальні поля DOI, інституційна політика депонування DOI-метаданих.

Що дивитися: Crossref; DataCite

Правило балів цього циклу, вересень 2026

0Відсутня
1DOI є без повних метаданих
2Реєстрація для частини об’єктів
3Системна реєстрація
4Повні зв’язки цитування даних і версій

Як перевіряти

1. Визначити DOI оцінюваної роботи, а не цитованого джерела, і належне агентство.
2. Зберегти зовнішній запис, зіставити назву, авторів, тип, дату та URL з локальним об’єктом.
3. Відрізняти зовнішньо зареєстрований DOI видавничої версії від DOI, зареєстрованого самим репозитарієм; обидва можуть представляти результат, але це різні інституційні дії.
4. Публічна API-відповідь без запису не є автоматичним доказом незареєстрованого DOI: перевірити агентство, стан видимості та резолюцію.
5. Для рівня 3 перевірити документований процес і SYS; для 4 — застосовні зв’язки citations/data/versions із перевіркою цільових об’єктів.

Не є доказом: Кількість локальних dc.identifier.doi як доказ зовнішньої реєстрації. DOI з іншого агентства, не знайдений у Crossref, як автоматично нечинний. DOI видавця як доказ того, що репозитарій сам його зареєстрував. Порожні relatedIdentifiers як автоматична помилка для об’єкта, який не має відповідних зв’язків.

Операційне визначення. Потребує погодження перед новим циклом і до балів вересня 2026 не застосовано. Розведено ідентифікацію, зовнішнє представлення та дію реєстрації самою установою. Оригінальна назва збережена для сумісності, але семантику registrant потрібно явно уточнити в протоколі. Рівні авторські, а не шкала Crossref/DataCite.

Проєкт умов для наступного циклу

0Зовнішнє DOI-представлення застосовних ресурсів не підтверджено після завершеної перевірки.
1DOI згадано локально, але відповідний повний зовнішній запис метаданих або його належність об’єкту не підтверджені.
2Відповідні зовнішні DOI-метадані підтверджено для частини об’єктів.
3Документований процес DOI-представлення та системне коректне зовнішнє подання підтверджені за SYS.
4Умови 3 та повні для застосовних випадків перевірені зовнішні зв’язки цитування, даних і версій; для незастосовних типів зв’язку зафіксовано обґрунтування.

Відкриті цитування й списки джерел

Перевірити доступність і структурованість вихідних бібліографічних посилань ресурсу та їх передавання назовні.

Одиниця: Ресурс-джерело і елементи його списку використаних джерел; вхідні цитування з інших робіт зберігаються окремо.

Де шукати: Список References у PDF/HTML, поля reference/references, Crossref/DataCite metadata, OpenCitations/OUCI або інші дозволені джерела зв’язків.

Що дивитися: References; COCI; OUCI

Правило балів цього циклу, вересень 2026

0Відсутні
1Списки лише в PDF
2Структуровані частково
3Системна передача references
4Відкриті перевірені цитувальні зв’язки

Як перевіряти

1. Переконатися, що це джерела, на які посилається робота, а не готовий бібліографічний опис цієї роботи.
2. Розрізнити текстовий список і структуровані окремі елементи з DOI/іншими ідентифікаторами або достатнім описом.
3. Для рівня 3 перевірити фактичну передачу елементів у зовнішні метадані за SYS.
4. Для рівня 4 перевірити відкритість умов отримання та коректність зв’язків на прикладах; не змішувати з числом отриманих цитувань.

Не є доказом: dc.identifier.citation, що містить опис самого ресурсу. Лічильник Cited by замість списку джерел. Порожній endpoint citations як доказ відсутності outgoing references. Будь-яке згадування DOI як структурований бібліографічний список.

Пропонована зміна правила. До балів вересня 2026 не застосовано. Для рівня 1 джерело згадує лише PDF; запропоновано включити еквівалентний неструктурований HTML. Уточнено напрям цитування, щоб не оцінювати популярність праці замість інфраструктури.

Проєкт умов для наступного циклу

0Вихідні списки джерел у застосовних ресурсах не підтверджено.
1Списки доступні лише як неструктурований текст PDF або HTML.
2Для частини застосовних ресурсів є окремі структуровані елементи references.
3Структуровані списки джерел системно передаються у зовнішні метадані/індекси за SYS.
4Умови 3 та відкрито доступні цитувальні зв’язки з перевіреною ідентичністю цільових робіт і документованими умовами використання.

Аналітика використання

Перевірити наявність придатної для інтерпретації статистики використання, її методику та відкритість, не змішуючи з розміром колекції.

Одиниця: Метрика використання за визначений період і об’єкт/сукупність, якої вона стосується.

Де шукати: Views/downloads сторінки, usage statistics, CSV/API reports, опис метрик і фільтрації, COUNTER або інший визначений профіль звітності.

Що дивитися: Views; downloads; COUNTER; API

Правило балів цього циклу, вересень 2026

0Відсутня
1Локальний лічильник
2Перегляди й завантаження
3Стандартизована статистика
4Відкрита аналітика з provenance і API

Як перевіряти

1. Встановити, що саме рахується: перегляди метаданих, повнотекстові запити, завантаження тощо.
2. Зафіксувати часовий період і scope. Відокремити поточну кількість файлів/записів від подій використання.
3. Для рівня 3 зберегти назву/версію стандарту, структуру звіту і правила обробки, включно з ботами/повторними зверненнями де застосовно.
4. Для 4 перевірити придатний відкритий експорт/API, дату оновлення й походження агрегатів; не вимагати оприлюднення сирих персональних логів.

Не є доказом: 200000 records або numFound як аналітика використання. Вкладка Statistics, яка не показує жодних значень. Обіцянка статистики без доступного звіту. Довільний лічильник як підтверджена COUNTER-відповідність.

Пояснення. Правило бала цього циклу не змінено. Збережено логіку джерела; явно відокремлено обсяг фонду від використання й задано необхідну семантику лічильників. COUNTER тут приклад стандарту, а не обов’язкова торговельна марка.