OMI-SPEC-150 — Модел за идентичност и сътрудници

Метаданни на документа

Поле	Стойност
Идентификатор	OMI-SPEC-150
Заглавие	Модел за идентичност и сътрудници
Версия	0.1.0
Статус	Чернова
Тип на документа	Нормативен
Нормативна терминология	Английски
Редактори	Администратори на OMI
Последно актуализирано	06.08.2026
Заменя	Няма
Заменено с	Няма
Зависи от	OMI-SPEC-120, OMI-SPEC-140
Използва се от	OMI-SPEC-160, OMI-SPEC-170, OMI-SPEC-190, OMI-SPEC-200, OMI-SPEC-220, OMI-SPEC-310
Схеми	Няма публикувани
Профили	Няма публикувани
Статус на изпълнението	OMI Implementation Status Matrix
Система за проследяване на проблеми	Проблеми в репозиторията „Open Manuscript Initiative“

1. Резюме

Настоящата спецификация определя начина, по който стандартът „Open Manuscript Initiative“ представя участниците и тяхното контекстуално участие в научни обекти и работни процеси. Тя предоставя общ модел за лица, организации, консорциуми, проекти, услуги, неидентифицирани участници, имена, външни идентификатори, принадлежности, роли на сътрудниците, ред на сътрудниците, статут на кореспондент-сътрудник и посочване на авторството.

Моделът разграничава агента от акаунта на приложението, приносителя от агента, който осъществява приноса, и ролята от постоянното свойство на този агент. Той също така разграничава локалната идентичност OMI от твърденията, направени от външни системи за идентификация, като например ORCID или ROR.

Спецификацията поддържа многоезични и исторически имена, принадлежности с ограничен времеви обхват, псевдоними и ограничени идентичности, твърдения за идентичност, съдържащи информация за произхода, както и изрични връзки за принос към ръкописи или други научни обекти. Тя не дефинира протоколи за удостоверяване, разрешения за достъп до работната среда, политика за разкриване на информация при рецензиране от колеги, нито пълната история на ревизиите на записите за идентичност.

2. Статус на настоящия документ

Настоящият документ представлява проект на спецификация на стандарта „Open Manuscript Initiative“.

Моделът, имената на свойствата, класовете за съответствие и изискванията за обработка могат да претърпят промени, водещи до несъвместимост, преди версия 1.0. Реализациите, които твърдят, че поддържат спецификацията, ТРЯБВА да посочат точната версия на спецификацията или неизменния коммит, който са използвали.

Настоящият проект активира идентификатора, запазен за модела за идентичност и сътрудници в регистъра на спецификациите на „OMI“. Дискусиите и предложенията за промени се проследяват в хранилището Open Manuscript Initiative.

3. Съответствие

3.1 Класове на съответствие

Настоящата спецификация определя четири класа на съответствие:

• Производител на съответстваща идентичност: създава или експортира данни за агенти, идентичност, принадлежност или принос.
• Потребител, отговарящ на изискванията за идентичност: внася, съхранява, показва, преобразува или запазва такива данни.
• Валидатор за съответствие: проверява данните спрямо структурните и семантичните изисквания на настоящата спецификация.
• Резолвер за съответствие на идентичността: сравнява, съгласува или обогатява идентичностите на агентите или твърденията за външни идентификатори.

Една реализация МОЖЕ да обхваща повече от един клас.

3.2 Общо съответствие

Една съответстваща реализация ТРЯБВА да отговаря на всяко приложимо изискване от типа ТРЯБВА и НЕ ТРЯБВА за декларирания от нея клас.

Една опционална функционалност МОЖЕ да бъде пропусната. Когато е реализирана, функционалността ТРЯБВА да отговаря на всички изисквания, определени за нея.

Декларацията за съответствие ТРЯБВА да посочва:

• име и версия на реализацията;
• OMI-SPEC-150 версия;
• деклариран клас на съответствие;
• поддържани типове агенти и схеми за идентификация;
• поддържани настройки за поверителност и видимост;
• известни ограничения;
• версия за тестване на съответствието, ако има такава.

3.3 Основни изисквания

REQ-IDN-001: Един агент ТРЯБВА да бъде представян независимо от всеки акаунт в приложението, свързан с него.

REQ-IDN-002: Всеки принос ТРЯБВА да съдържа позоваване към агент и към субект от типа „OMI“, към който е направен приносът; НЕ СЕ ДОПУСКА пълният профил на агента да бъде дублиран като вграден запис за приносител.

REQ-IDN-003: Ролята на принос ТРЯБВА да е свързана с конкретен принос и НЕ ТРЯБВА да се тълкува като постоянна характеристика на субекта.

REQ-IDN-004: Външният идентификатор ТРЯБВА да бъде представен като твърдение, съдържащо схема на идентификатора, стойност, субект, произход и състояние на проверката.

REQ-IDN-005: Потребителят НЕ ТРЯБВА да обединява два агента единствено поради това, че имената, имейл адресите, принадлежностите или непотвърдените външни идентификатори на двамата са еднакви.

REQ-IDN-006: Производителят ТРЯБВА да запази разграничението между неизвестни, скрити, псевдонимни и изрично анонимни самоличности.

REQ-IDN-007: Информацията за самоличността и контактните данни с ограничен достъп НЕ ТРЯБВА да се разкрива чрез публична сериализация или визуализация, освен ако приложимата политика за достъп не разрешава разкриването ѝ.

REQ-IDN-008: Редът на участниците ТРЯБВА да се представя независимо от ролята, самоличността и размера на приноса.

4. Обхват

Настоящата спецификация определя:

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

4.1 Извън обхвата

Настоящата спецификация не определя:

• пароли, passkeys, OAuth, OpenID Connect, управление на сесиите или други механизми за удостоверяване;
• жизненият цикъл на потребителския акаунт и възстановяването на акаунта;
• членство в работната среда, оторизация или изчисляване на разрешения;
• политика за анонимност или разкриване на информация при рецензирането;
• проверка на правната самоличност;
• институционална проверка на трудовата история;
• етика на авторството или критерии за допустимост;
• универсален речник за роли и приноси;
• графики на версиите, набори от промени или пълна семантика на събитията за одит;
• Дизайн на страницата с публичния профил.

Удостоверяването на автентичността е част от сигурността на платформата. Правата за достъп до работните пространства са част от OMI-SPEC-190. Проверката на разкриването на самоличността е част от OMI-SPEC-200. Семантиката на ревизиите и промените е част от OMI-SPEC-160.

5. Терминология

Прилага се документът „OMI Terminology and Definitions“.

5.1 Идентичност на агента

Обектът „OMI“, който представя един агент като различима единица в рамките на определен обхват на идентичност.

Идентичността на даден субект може да се отнася за лице, организация, консорциум, проект, услуга или неидентифициран субект. Тя не представлява удостоверение за автентичност и не предполага правна проверка.

5.2 Акаунт

Запис, управляван от системата за внедряване, който се използва за удостоверяване, оторизиране или персонализиране на достъпа до софтуер.

Един акаунт МОЖЕ да бъде свързан с идентичността на даден участник, но той не е част от модела за научна атрибуция и НЕ ТРЯБВА да се разглежда като самия участник.

5.3 Потвърждаване на самоличността

Изявление, съдържащо информация за произхода, че даден идентификатор, име, принадлежност, контактна информация или друго свойство, свързано с идентичността, се отнася за даден субект.

5.4 Потвърждение на външен идентификатор

Потвърждение на самоличността, свързващо даден агент с идентификатор, присвоен от външна схема или орган.

5.5 Форма на името

Един от начините за изписване на името на даден агент за определен език, азбука, исторически период, цел или източник.

5.6 Принос

Контекстуална връзка, която посочва, че даден агент е участвал в една или повече роли във връзка с определена единица от базата данни „OMI“.

5.7 Посочване на източника

Обозначение на принос с цел признание, отговорност, цитиране, представяне или посочване на източника.

5.8 Ролята на приноса

Стойност, описваща функцията, изпълнявана от даден агент в даден контекст на принос.

5.9 Декларация за принадлежност

Изявление с определена във времето валидност и с посочен източник, свързващо даден субект с организация, организационна единица, проект или подобен институционален контекст.

5.10 Разпознаване на идентичността

Процесът на установяване дали записите за самоличност или твърденията се отнасят до един и същ субект, до различни субекти или до неизяснена връзка.

5.11 Неразкрита самоличност

Идентичност, която е известна в определен контекст, но умишлено не е достъпна за настоящия потребител или аудитория.

5.12 Неидентифициран агент

Агент, чиято идентичност не е известна, не е регистрирана или не може да бъде установена.

Неидентифициран агент не е равнозначно на скрита самоличност.

6. Принципи на проектирането

Този раздел има информационен характер.

• Контекст преди глобалните предположения: ролите, принадлежностите, редът и съответният статус зависят от контекста.
• Идентичност преди показване: един агент не се определя от един-единствен низ с име за показване.
• Утверждения с проследимост: внесените или предоставени от външни източници данни за самоличността остават свързани с техния източник.
• Без рисковано автоматично обединяване: двусмислието се запазва, докато не се намерят достатъчно доказателства, които да подкрепят съгласуването.
• Защита на личните данни още при проектирането: публичното посочване на източника и ограничените оперативни данни са разделени.
• Многоезично представяне: имената и етикетите отразяват езика, азбуката, реда на изписване и историческите варианти.
• Независимост на профила: научните записи могат да се прехвърлят между инсталации и приложения.
• Оперативна съвместимост, отчитаща загубата на данни: при вноса и износа се разкрива пропусната, трансформирана или непроверима информация за самоличността.

7. Общ преглед на модела

Application account
    └── may be privately associated with ── Agent identity
                                               ├── Name forms
                                               ├── External identifier assertions
                                               ├── Affiliation assertions
                                               ├── Contact points
                                               └── Contributions
                                                        ├── Target scholarly object
                                                        ├── Contribution roles
                                                        ├── Contributor order
                                                        ├── Corresponding status
                                                        └── Contextual attribution name

Свързването на акаунтите е специфично за конкретната реализация, освен ако изрично защитен профил за обмен не определя друго.

Една идентичност на участник може да фигурира в няколко приноса. Един принос може да включва няколко роли, но има един основен участник и един обект, към който е насочен приносът. При груповите приноси се използва организация, консорциум, проект или изрично моделиран колективен участник, а не масив, представян като едно лице.

8. Модел на данните

8.1 Идентичност на агента

Цел: Да се представи агентът независимо от акаунти, роли и променяеми етикети за показване.
Идентификатор: Стабилен локален идентификатор в обхвата на идентичността „OMI“, в който се намира.
Животният цикъл: Постоянен; корекциите, обединяването, разделянето, премахването и замяната изискват изрично посочване на произхода.

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Стабилен локален идентификатор.
type	низ	Да	1	Категория на агента.
names	NameForm[]	Да	1..*	Известни представяния на имена.
identifiers	ExternalIdentifierAssertion[]	Не	0..*	Твърдения за външни идентификатори.
affiliations	AffiliationAssertion[]	Не	0..*	Контекстуални връзки.
contacts	ContactPoint[]	Не	0..*	Контактни данни с правила за видимост.
status	низ	Не	0..1	Активно, историческо, обединено, остаряло, неидентифицирано или определено от конкретната реализация разширение.
replacedBy	низ	Не	0..1	Идентификатор на агента, който замества обединен или премахнат запис.
provenance	ProvenanceAssertion[]	Не	0..*	Информация за произхода и съхранението.
extensions	обект	Не	0..1	Съдържание на разширение с пространство от имена.

Основните ценности на „type“ са:

• person;
• organization;
• consortium;
• project;
• service;
• unidentified.

Един профил МОЖЕ да дефинира по-конкретни типове агенти.

REQ-IDN-010: Всяка идентичност на агент ТРЯБВА да има поне една форма на име, с изключение на агента от типа „unidentified“, който МОЖЕ да използва контролиран заместващ етикет.

REQ-IDN-011: Идентификаторът „id“ ТРЯБВА да остава непроменен при промяна на предпочитаното име, принадлежността, контактната точка или външния идентификатор.

REQ-IDN-012: Слитата или премахнатата идентичност ТРЯБВА да запази предишния си идентификатор и СЛЕДВА да посочи своя заместител чрез replacedBy.

REQ-IDN-013: Идентичността на дадено лице НЕ ТРЯБВА да включва официално име, бинарен маркер за пол, титул, имейл адрес, ORCID или принадлежност.

8.2 Форма на името

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Стабилен идентификатор за това твърдение за името.
display	низ	Да	1	Попълнете формуляра за показване.
given	низ	Не	0..1	Компонентът „име“, когато е приложимо.
family	низ	Не	0..1	Част от фамилното име, когато е приложимо.
prefix	низ	Не	0..1	Префикс, когато е семантична част от името.
suffix	низ	Не	0..1	Суфикс, когато е семантична част от името.
literal	низ	Не	0..1	Неанализирано име или име в стила на организацията.
language	BCP 47 таг	Не	0..1	Език на формата на името.
script	Код по ISO 15924	Не	0..1	Скрипт, когато не може да бъде адекватно изразен чрез езиковия таг.
usage	низ	Не	0..1	Предпочитан, публикуван, юридически, бивш, псевдоним, транслитерация, превод или разширение.
preferred	boolean	Не	0..1	Предпочитано в рамките на декларирания контекст.
validFrom	дата или дата и час	Не	0..1	Начало на известния срок на валидност.
validUntil	дата или дата и час	Не	0..1	Край на известния срок на валидност.
source	ProvenanceAssertion	Не	0..1	Източник на формата на името.

REQ-IDN-020: Формата на името ТРЯБВА да включва „display“ и НЕ ТРЯБВА да изисква то да може да бъде разложено без загуба на информация на компоненти „име“ и „фамилия“.

REQ-IDN-021: Потребителят ТРЯБВА да запази формите на имената, които използват азбуки, правила за подреждане или компоненти, които не се поддържат от неговия интерфейс.

REQ-IDN-022: За един и същ агент, език, азбука, употреба и контекст на обработка МОЖЕ да бъде отбелязана като предпочитана най-много една форма на името.

REQ-IDN-023: Транслитерираното или преведеното име НЕ ТРЯБВА да замества името в изходната азбука без предупреждение.

8.3 Утвърждаване на външен идентификатор

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Идентификатор на локално твърдение.
scheme	низ или URI	Да	1	Схема за идентификатори, като например ORCID или ROR.
value	низ	Да	1	Стойност на идентификатора, специфична за Scheme.
uri	URI	Не	0..1	Каноничен или разрешим URI, когато е известен.
subject	низ	Да	1	Идентификатор на агента, към когото се прави препратка.
verification	низ	Да	1	Непроверено, самодекларирано, проверено по източник, проверено в регистъра, отхвърлено или разширение.
verifiedAt	дата-час	Не	0..1	Време на проверка.
verifiedBy	референтен номер на агента или услугата	Не	0..1	Проверка на агента или обработващия субект.
source	ProvenanceAssertion	Да	1	Източник на твърдението.
visibility	низ	Не	0..1	Публичен, ограничен, частен или наследен.

REQ-IDN-030: Сравнението на идентификатори ТРЯБВА да се извършва съгласно правилата за нормализация и сравнение на декларираната схема.

REQ-IDN-031: Производителят НЕ ТРЯБВА да обозначава външен идентификатор като „проверен от регистъра“, освен ако регистрирана операция по проверка не потвърждава този статус.

REQ-IDN-032: Неуспешното разрешаване на идентификатора НЕ ТРЯБВА само по себе си да прави синтаксично валидния постоянен идентификатор невалиден.

REQ-IDN-033: Противоречащите си външни идентификатори ТРЯБВА да се запазят като отделни твърдения, докато не бъдат изрично разрешени, отхвърлени или заменени.

REQ-IDN-034: Утверждението „ORCID“ ТРЯБВА да идентифицира физическо лице; утверждението „ROR“ ТРЯБВА да идентифицира организация.

8.4 Декларация за принадлежност

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Идентификатор на стабилна асерция.
agent	справка за агента	Да	1	Свързан агент.
organization	справка за агента	Да	1	Организация или подобен институционален агент.
unit	низ или препратка към агент	Не	0..1	Катедра, факултет, лаборатория или звено.
position	многоезичен низ	Не	0..1	Позиция или контекстуално заглавие.
role	термин	№	0..1	Характер на принадлежността.
validFrom	дата или дата и час	Не	0..1	Начало на известния срок на валидност.
validUntil	дата или дата и час	Не	0..1	Край на известния срок на валидност.
source	ProvenanceAssertion	Да	1	Отговорност за източниците и твърденията.
verification	низ	Не	0..1	Състояние на проверката.

REQ-IDN-040: Принадлежността ТРЯБВА да се представя като връзка, а не като неизменяемо текстово свойство на дадено лице.

REQ-IDN-041: При принадлежността, използвана за даден принос, СЛЕДВА да се посочи дали тя отразява момента на създаване на приноса, момента на подаване, момента на публикуване или друг посочен контекст.

REQ-IDN-042: Липсата на начална или крайна дата ТРЯБВА да означава, че те са неизвестни или с неопределен срок, съгласно контекста на профила; тя НЕ ТРЯБВА автоматично да означава, че са актуални.

8.5 Контактно лице

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Идентификатор на твърдението за местен контакт.
type	низ	Да	1	Имейл, телефон, пощенски адрес, URI, съобщения или вътрешен номер.
value	низ	Да	1	Стойност на контакта.
purpose	низ	Не	0..1	Кореспонденция, редакционна, административна, публична или свързана с разширяване на дейността.
visibility	низ	Да	1	Публичен, ограничен, частен или наследен.
validFrom	дата или дата и час	Не	0..1	Начало на валидността.
validUntil	дата или дата и час	Не	0..1	Край на валидността.
source	ProvenanceAssertion	Да	1	Информация за източника и съхранението.

REQ-IDN-050: Контактните данни ТРЯБВА да бъдат незадължителни в преносимите научни данни.

REQ-IDN-051: Частната или ограничена точка за контакт ТРЯБВА да бъде пропусната, криптирана, подложена на контрол на достъпа или заменена с механизъм за препращане, който не съдържа чувствителна информация, в изходящите данни, които нямат разрешение да я получават.

REQ-IDN-052: Съвпадението на имейл адресите НЕ ТРЯБВА да се приема като неопровержимо доказателство, че два записи за самоличност се отнасят за един и същ агент.

8.6 Принос

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Идентификатор на стабилен принос.
agent	справка за агента	Да	1	Агент-съавтор.
target	Препратка към обект в OMI	Да	1	Ръкопис, документ, раздел, ресурс, събитие, публикация или друг обект, към който е допринесено.
roles	ContributionRole[]	Да	1..*	Роли за контекстуален принос.
order	цяло число или низ	Не	0..1	Изричен ред в дефиниран списък с участници.
orderContext	низ	Не	0..1	Списък с автори, списък с редактори, списък за показване или контекст, дефиниран в профила.
corresponding	boolean	Не	0..1	Означение на съответния съавтор.
attributionName	низ	Не	0..1	Име на атрибута, визуализирано в зависимост от контекста.
affiliations	препратки към афилиации	Не	0..*	Афилиации, свързани с тази публикация.
statement	многоезичен низ	Не	0..1	Лесноразбираемо изявление за приноса.
validFrom	дата или дата и час	Не	0..1	Начало на валидността на контекста.
validUntil	дата или дата и час	Не	0..1	Край на валидността на контекста.
visibility	низ	Не	0..1	Публичен, ограничен, частен или наследен.
provenance	ProvenanceAssertion[]	Не	0..*	Произход на твърдението и история на промените.

REQ-IDN-060: Всяка операция ТРЯБВА да се отнася точно към един агент и точно към една цел.

REQ-IDN-061: Всеки принос ТРЯБВА да съдържа поне една роля.

REQ-IDN-062: Няколко роли, изпълнявани от един и същ агент по отношение на една и съща цел, МОГАТ да бъдат представени в един принос, когато редът им, видимостта, принадлежността и контекстът на валидността са еднакви; в противен случай те ТРЯБВА да бъдат отделни приноси.

REQ-IDN-063: order ТРЯБВА да се тълкува единствено в рамките на orderContext и съответната цел или профил.

REQ-IDN-064: Статусът на съавторство НЕ ТРЯБВА да предполага, че съответният автор е първи автор, че има по-голям стаж, че притежава правата върху публикацията или че е единственият контакт за комуникация.

REQ-IDN-065: attributionName МОЖЕ да замени изгледа за контекста на приноса, но НЕ ТРЯБВА да заменя формите на името на агента.

REQ-IDN-066: Приноските, отнасящи се само до част от ръкописа, ТРЯБВА да са насочени към съответния раздел, обект или ресурс, а не към целия ръкопис.

8.7 Ролята на вноската

Свойство	Тип	Задължително	Кардиналност	Описание
id	низ	Да	1	Идентификатор на стабилна ролева асерция.
term	низ или URI	Да	1	Стойност на ролята.
scheme	низ или URI	Не	0..1	Речник или регистър, в който се дефинира терминът.
label	многоезичен низ	Не	0..1	Лесноразбираем етикет.
detail	многоезичен низ	Не	0..1	Обяснение, свързано с контекста.

Основните термини, свързани с длъжността, включват:

• author;
• editor;
• translator;
• reviewer;
• publisher;
• data-curator;
• software-contributor;
• illustrator;
• project-administrator;
• funding-acquisition;
• other.

Профилите МОГАТ да използват CRediT или друг стандартизиран речник.

REQ-IDN-070: Терминът за роля, импортиран от контролиран речник, ТРЯБВА да запази своя идентификатор в речника или URI, ако такъв е наличен.

REQ-IDN-071: Разширението на локална роля НЕ ТРЯБВА да бъде погрешно обозначено като термин от контролиран речник.

REQ-IDN-072: Етикетът на ролята има информативен характер и НЕ ТРЯБВА да замества термина за ролята, който може да бъде обработен от компютър.

8.8 Декларация за произход

Настоящата спецификация използва следната минимална структура за проследяване на произхода, докато на адрес OMI-SPEC-160 не бъде дефиниран пълният модел за промени и проследяване на произхода.

Свойство	Тип	Задължително	Кардиналност	Описание
sourceType	низ	Да	1	Потребител, регистър, импортиран запис, институция, услуга, миграция или разширение.
source	препратка към агент, система или URI	Не	0..1	Идентичност на източника.
assertedBy	референтен номер на агента или сметката	Не	0..1	Страна, отговорна за потвърждаването.
assertedAt	дата-час	Не	0..1	Време на твърдението.
evidence	URI или препратка към обект	Не	0..*	Подкрепящи доказателства.
confidence	низ или число	Не	0..1	Степен на достоверност, специфична за източника.

REQ-IDN-080: Провенансът ТРЯБВА да разграничава източника на дадено твърдение от субекта, описан в това твърдение.

REQ-IDN-081: Стойността на доверителния интервал ТРЯБВА да посочва своята скала или терминология.

8.9 Свързване на акаунти

Дадена реализация МОЖЕ да поддържа защитена връзка между идентификатора на акаунта и идентичността на агента.

Свойство	Тип	Задължително	Кардиналност	Описание
account	референция на непрозрачна сметка	Да	1	Сметка, управлявана от имплементацията.
agent	справка за агента	Да	1	Идентификатор на свързания агент.
status	низ	Да	1	В очакване, потвърден, отменен или с удължен срок.
verifiedAt	дата-час	Не	0..1	Време на проверка.
source	ProvenanceAssertion	Да	1	Произход от асоциацията.

REQ-IDN-090: Връзките между акаунти НЕ ТРЯБВА да съдържат тайни за удостоверяване, токени, хеш-стойности на пароли или данни за възстановяване.

REQ-IDN-091: По подразбиране връзките с акаунти НЕ ТРЯБВА да се включват в публичния експорт на ръкописа.

REQ-IDN-092: Изтриването или деактивирането на профил НЕ ТРЯБВА автоматично да води до изтриване на историческите научни позовавания.

8.10 Неизвестни, анонимни, използващи псевдоним и скрили самоличността си агенти

Производителят ТРЯБВА да използва явна семантика:

Състояние	Значение
unidentified	Агентът е неизвестен или не може да бъде възстановен.
anonymous	Авторството на тази публикация умишлено не се приписва на нито един конкретен държавен представител.
pseudonymous	Стабилният псевдоним е идентичността, с която се приписва авторството в съответния контекст.
withheld	Известна е по-конкретна идентичност, но достъпът до нея е ограничен.

REQ-IDN-100: Скритата самоличност ТРЯБВА да запазва стабилна защитена препратка, така че оторизираните системи да могат да поддържат непрекъснатост, без да разкриват самоличността.

REQ-IDN-101: Потребител, който няма достъп до скрита идентичност, ТРЯБВА да запази статуса „скрита“ и НЕ ТРЯБВА да го променя на „неидентифицирана“.

REQ-IDN-102: Агентът с псевдоним ТРЯБВА да бъде представян като идентичност на агент със собствен стабилен идентификатор и форма на псевдоним.

9. Модел на обработката

9.1 Създаване на идентичност на агент

Производителят, който отговаря на изискванията, ТРЯБВА:

1. да се присвои стабилен идентификатор на локалния агент;
2. изберете най-конкретния поддържан тип агент;
3. да регистрира поне една използваема форма на името или изрично състояние „неидентифицирано“;
4. да се запази източникът на внесените твърдения;
5. да прикачват външни идентификатори като твърдения, вместо да заменят локалната идентичност;
6. приложете правилата за видимост преди експортирането.

9.2 Създаване на публикация

Производителят, който отговаря на изискванията, ТРЯБВА:

1. да идентифицира или създаде агента, който предоставя данните;
2. да се определи точната цел за принос;
3. да присвои една или повече контекстуални роли;
4. записва поръчката само когато има контекст на поръчката;
5. да свързва принадлежностите, свързани с конкретни приноси, вместо да разчита на принадлежността, посочена в актуалния профил;
6. класифициране на данните с публичен достъп и тези с ограничен достъп;
7. да се запази произходът, когато приносът е внесен или деклариран от друга страна.

9.3 Сравнение на идентичността

Резолверът ТРЯБВА да сравнява доказателствата в следния ред:

1. проверени идентификатори на схеми;
2. връзки с авторитетни източници;
3. изрично предварително обединяване или твърдения за един и същ агент;
4. съвпадащи имена, принадлежности, дати и контекстуални доказателства;
5. сигнали за сходство, специфични за конкретната реализация.

Самите сигнали за сходство НЕ ТРЯБВА да водят до необратимо автоматично обединяване.

9.4 Обединяване

Операцията по обединяване ТРЯБВА:

1. изберете или създайте идентичност на заместник;
2. да запази всеки предишен локален идентификатор като псевдоним или заместваща препратка;
3. да запази уникалните твърдения и информацията за техния произход;
4. да запази противоречащите си твърдения;
5. пренасочване на препратките към приносите, без да се променя смисълът на приноса;
6. записване на събитието за сливане с оглед бъдеща съвместимост с OMI-SPEC-160;
7. остават обратими, докато приложимата политика за съхранение не позволи тяхното окончателно финализиране.

9.5 Разделяне

Операцията по разделяне ТРЯБВА:

1. създаване на уникални идентификатори на агентите;
2. да преоцени твърденията и приносите, като се позовава на конкретни доказателства;
3. да запази оригиналния запис като исторически, двусмислен или отменен;
4. записвайте нерешените задачи, вместо да гадаете;
5. да се запазят произходът и предишните препратки.

9.6 Посочване на източника

Рендериращият модул ТРЯБВА да избере име в следния ред:

1. attributionName, специфично за дарението;
2. предпочитано име, съответстващо на езика и азбуката на изходния текст;
3. предпочитано име на друг поддържан език или азбука;
4. подходящо публично или псевдонимно име;
5. още едно запазено име за показване;
6. официално одобрен, скрит или анонимен етикет.

Рендериращият модул НЕ ТРЯБВА да разкрива име или идентификатор с ограничен достъп само защото той се съдържа в изходните данни.

10. Валидиране и обработка на грешки

10.1 Нива на валидиране

Проверката включва:

• проверка на синтаксиса;
• структурна валидация;
• семантична валидация;
• проверка на целостта на референциите;
• проверка на схемата за идентификатори;
• проверка на поверителността и видимостта;
• проверка на профила.

10.2 Състояния на грешка

Състояние	Класификация	Изисквано поведение
Липсващ агент id	Грешка	Отхвърлете или поставете в карантина идентификацията на агента.
Неподдържан тип агент	Неподдържана функция	Да се запази като разширение или да се докладва, че обработката е невъзможна.
Внос без посредник или получател	Грешка	Отхвърли вноса.
Принос без роля	Грешка	Отхвърлете или поставете приноса в карантина.
Невалидна препратка към агент, цел, принадлежност или заместител	Грешка	Докладвайте и запазете неразрешените данни, където е възможно.
Невалидна синтаксисна структура	Грешка	Докладвай; не отбелязвай като проверено.
Резолверът не е достъпен	Предупреждение	Запазете твърдението и докладвайте за нерешен статус.
Противоречащи се проверени идентификатори	Грешка	Запази конфликта; забрани автоматичното обединяване.
Наличие на няколко предпочитани имена в един и същ контекст	Грешка	Докладвайте и изисквайте детерминистично разрешаване на конфликти.
Ограничен достъп в публичното извеждане	Грешка в сигурността	Блокирайте, редактирайте или заместете преди извеждането.
Съвпадение с невъзможен интервал от дати	Грешка	Извеждане на съобщение; да не се пренареждат датите без предупреждение.
Неизвестно свойство на разширението	Предупреждение или поддържано разширение	Да се запази съгласно политиката за разширенията.

10.3 Липсващи, нулеви и празни стойности

• Липсващата характеристика означава, че не е предоставена никаква твърдение.
• null НЕ ТРЯБВА да се използва като заместител на „непосочено“, „неизвестно“ или „неприложимо“, освен ако профилът за сериализация не определя такова съответствие.
• Празният низ не е валидно име, стойност на идентификатор, стойност на контакт или роля.
• Празен масив означава, че създателят потвърждава, че в този масив няма стойности за сериализирания контекст.
• „Неизвестно“, „неразкрито“, „анонимно“ и „неприложимо“ ТРЯБВА да използват ясна семантика, когато това разграничение има значение.

10.4 Съхранение при отказ

REQ-IDN-110: Потребител, който не е в състояние да интерпретира дадено твърдение, ТРЯБВА да запази твърдението, неговия идентификатор, видимостта му и произхода му с цел експортиране в двете посоки.

REQ-IDN-111: Валидаторът ТРЯБВА да докладва местоположението и класификацията на всяка грешка в модела на идентичността, без да разкрива стойности с ограничен достъп в логовете, предназначени за по-широка аудитория.

11. Разширяемост

11.1 Точки за разширение

Разширенията могат да дефинират:

• допълнителни видове агенти;
• начини на употреба на името;
• схеми за идентификация;
• състояния на проверка;
• роли, свързани с принадлежността;
• видове контакти;
• роли, свързани с приноса;
• състояния на видимост;
• доказателства за произхода;
• ограничения, специфични за профила.

11.2 Неизвестни разширения

Съвместимият потребител ТРЯБВА да запази съдържанието на неизвестното разширение, когато това е безопасно. Той МОЖЕ да пренебрегне семантиката на разширението, която не реализира, но НЕ ТРЯБВА да преинтерпретира разширението като основно свойство.

Разширенията НЕ ТРЯБВА:

• да отслабят правилата за защита на личните данни;
• предефиниране на основен тип агент;
• да превърнете акаунт в агент;
• да разглеждаме ролята като постоянно свойство на агента;
• прескачане на състоянието на проверка на идентификатора;
• премахване на произхода от външно твърдение.

11.3 Правила за пространствата от имена

Термините на разширенията ТРЯБВА да използват URI, регистриран префикс или пространство от имена, защитено срещу конфликти. Неквалифицираните локални низове МОГАТ да се използват само в рамките на профил или система, които определят обхвата им.

12. Версии и съвместимост

Настоящата спецификация следва Политиката за версии на OMI.

12.1 Размери за съвместимост

Приложимите размери са:

• съвместимост при четене;
• съвместимост при запис;
• съвместимост при двупосочно движение;
• съвместимост на схемите;
• съвместимост между идентичността и референцията;
• съвместимост с политиката за поверителност;
• съвместимост на профилите.

12.2 Съвместими промени

Версия с незначителни промени или корекционна версия може:

• добавете опционален атрибут;
• добавете термин за агент или роля, който не е в конфликт;
• да се изясни поведението при сравняване или показване;
• добавете съответствие на идентификатори;
• добавете пример или предупреждение за валидиране;
• да се прецизират указанията относно произхода, без да се променя съществуващото значение.

12.3 Промени, изискващи актуализация на кода

Промяната, изискваща пренастройка, включва:

• промяна на семантиката на равенството на идентичността;
• промяна на изискваната трайност на идентификаторите;
• превръщането на доброволното разкриване на самоличността в задължително;
• промяна на значението на думите „неизвестен“, „неразкрит“, „анонимен“ или „псевдоним“;
• заместване на препратките към приносите с вградени копия на агентите;
• промяна в тълкуването на поръчката;
• премахване на изискваната информация за произхода или състоянието на проверката;
• промяна на настройките по подразбиране за видимостта по начин, който може да доведе до разкриване на данни.

12.4 Миграция

При миграцията ЗАДЪЛЖИТЕЛНО трябва да се запазят:

• идентификатори на агенти или изрично зададени псевдоними за заместване;
• всички препратки към публикации;
• формите на имената и азбуките;
• твърдения за външни идентификатори и състояния на проверка;
• контекст на принадлежност;
• ограничения на видимостта;
• произход;
• нерешени конфликти.

Отдел „Миграция“ е ДЛЪЖЕН да докладва за всяка загуба на информация.

12.5 Прекратяване на поддръжката

Остарял атрибут или термин ТРЯБВА да посочва:

• замяна;
• засегнатите версии;
• поведение при съвместимост;
• най-ранната версия за премахване;
• изисквания за миграция.

13. Оперативна съвместимост

13.1 Външни стандарти и системи

Външен стандарт или система	Направление	Качество на съответствието	Забележки
ORCID	Двупосочен	Условно беззагубен	Произходът на идентификатора и проверката изискват отделно обработване.
ROR	Двупосочен	Условно без загуба	Приложим за идентичности и принадлежности към организации.
CRediT	Двупосочен	Условно беззагубен	Отразява термините за приноса и ролята, а не самоличността на агента.
JATS Метаданни за сътрудниците на XML	Двупосочни	Възможност за загуба на информация	Името, ролята, принадлежността и моделите за анонимност варират в зависимост от профила.
Метаданни на авторите в Crossref	Експорт и импорт	Възможна загуба на информация	Данните за работния процес и личните данни не се включват в стандартните записи за депозиране.
Метаданни на авторите в DataCite	Експорт и импорт	Възможност за загуба на информация	Речникът на ролите и идентификаторите на имената изискват съпоставяне.
CSL Имена наJSON	Двупосочни	С потенциални загуби	CSL обектите с имена не представят пълния модел на идентичност OMI.
Агенти на Schema.org	Двупосочни	Възможно е да има загуба на информация	Контекстът и произходът може да наложат разширения.

13.2 Съхранение на информация

При съпоставянето ТРЯБВА да се запазят:

• стабилна локална идентичност;
• имена на източници;
• име, език и азбука;
• схема на идентификатора и стойност;
• ролята на приноса;
• ред на авторите;
• текст за принадлежност и идентификатори;
• съответното състояние;
• анонимност или състояние на скритост;
• произход и статус на проверката, когато целта го позволява.

Докладът за картиране ТРЯБВА да посочва пропуснатите или опростени семантични елементи.

13.3 Поведение при двупосочно движение

Един цикъл се счита за беззагубен само когато целевият формат може да запази цялата приложима семантика, свързана с идентичността, ролята, реда, принадлежността, видимостта и произхода. В противен случай процесорът ТРЯБВА да класифицира цикъла като условно беззагубен или със загуба.

14. Съображения, свързани със сигурността, поверителността и целостта

Данните за идентичността могат да съдържат лична информация, поверителни идентификатори за рецензиране, данни за контакт, институционални връзки, постоянни идентификатори и исторически данни за авторство. Неправилното разкриване или обединяване на тези данни може да навреди на отделни лица и да наруши научната просенеция.

14.1 Минимизиране на данните

REQ-IDN-200: Производителят ТРЯБВА да включва само тези идентификационни и контактни данни, които са необходими за декларираната цел и целевата аудитория.

14.2 Контрол на достъпа

REQ-IDN-201: Твърденията с ограничен достъп и частните твърдения ТРЯБВА да бъдат защитени чрез средства за контрол на достъпа, съответстващи на тяхната класификация.

REQ-IDN-202: Публичният експорт ТРЯБВА да прилага правилата за видимост рекурсивно към имена, идентификатори, контакти, принадлежности, приноси и доказателства за произход.

14.3 Целостност на идентификаторите

REQ-IDN-203: Потребителят ТРЯБВА да запази състоянието на проверката и НЕ ТРЯБВА да повишава нивото на доверие само защото даден идентификатор е синтаксически валиден.

REQ-IDN-204: Отговорите от резолвера ТРЯБВА да се третират като външен вход и да се проверяват за валидност преди използване.

14.4 Безопасност при сливане

REQ-IDN-205: Обединяването въз основа на вероятностно съпоставяне ТРЯБВА да изисква преглед или обратим работен процес, когато има вероятност да промени публичното посочване на авторството.

14.5 Водене на дневник

REQ-IDN-206: В логовете и отчетите за валидиране СЛЕДВА да се използват идентификатори на записи или редактирани стойности вместо лични контактни данни и имена с ограничен достъп.

14.6 Разделяне на сметките

Тайните за удостоверяване и токените на доставчиците ТРЯБВА да останат извън научните документи и пакети на OMI. Импортиран ръкопис НЕ ТРЯБВА да може да създава свързване с удостоверен акаунт без изрична операция, за която има доверие.

15. Съображения, свързани с достъпността

Потребителските интерфейси, които показват данни за самоличността, ТРЯБВА:

• да показва пълното достъпно име, независимо от визуалното оформление на името;
• избягвайте да разчитате единствено на цвета за проверка или за определяне на състоянието на видимостта;
• да се предоставят текстови етикети за схемите за идентификация и състоянията на проверка;
• да предостави достъп до реда на авторите и съответния им статус на помощните технологии;
• да се запази достъпът чрез клавиатурата до алтернативни имена, принадлежности и произход;
• избягвайте да съкращавате имената по начин, при който се премахва отличителна информация, без да има достъпно пълно изписване;
• да се даде възможност на потребителите да коригират неправилно анализирани компоненти на имената.

Основният модел ТРЯБВА да запази семантичните разграничения, необходими за достъпно представяне.

16. Съображения, свързани с интернационализацията

16.1 Имена

Реализациите ТРЯБВА да поддържат имена в Unicode. Те НЕ ТРЯБВА да приемат, че:

• всеки човек има име и фамилия;
• фамилията се поставя след името;
• всички компоненти са разделени с интервал;
• изписването с главни букви може да бъде нормализирано безпроблемно;
• един скрипт е каноничен;
• транслитерацията е обратима;
• Името е неутрално по отношение на езика.

16.2 Език и азбука

За езика СЛЕДВА да се използват езиковите кодове BCP 47. Кодовете за азбука по ISO 15924 МОГАТ да допълват езиковите кодове, когато е необходимо.

16.3 Сортиране

Ключовете за сортиране представляват метаданни за обработка, а не идентификатори. Ключът за сортиране, генериран в зависимост от локал, НЕ ТРЯБВА да заменя изходното име.

16.4 Дати и час

Стойностите, представляващи само дата, НЕ ТРЯБВА да се преобразуват в дата и час, без да се запази първоначалната им точност. Датата и часът ТРЯБВА да се представят съгласно стандарта ISO 8601 и да включват времева разлика или посочена часова зона, когато това има значение.

16.5 Двупосочен текст

Рендерите ТРЯБВА да прилагат безопасна двупосочна обработка на текста и НЕ ТРЯБВА да променят реда на съхранените имена, основавайки се единствено на посоката на околния интерфейс.

17. Примери

Примерите имат информационен характер, докато не бъдат публикувани каноничните схеми и фикстурите.

17.1 Минимален брой лица и минимален принос

{
  "agents": [
    {
      "id": "agent-001",
      "type": "person",
      "names": [
        {
          "id": "name-001",
          "display": "Judit Balogh",
          "given": "Judit",
          "family": "Balogh",
          "language": "hu",
          "preferred": true
        }
      ]
    }
  ],
  "contributions": [
    {
      "id": "contribution-001",
      "agent": "agent-001",
      "target": "manuscript-001",
      "roles": [
        {
          "id": "role-001",
          "term": "author"
        }
      ],
      "order": 1,
      "orderContext": "author-list"
    }
  ]
}

В този пример агентът се разграничава от приноса, а редът зависи от контекста.

17.2 Външен идентификатор и принадлежност

{
  "id": "agent-002",
  "type": "person",
  "names": [
    {
      "id": "name-002",
      "display": "Katalin Kovács",
      "language": "hu"
    }
  ],
  "identifiers": [
    {
      "id": "identifier-001",
      "scheme": "orcid",
      "value": "0000-0002-1825-0097",
      "uri": "https://orcid.org/0000-0002-1825-0097",
      "subject": "agent-002",
      "verification": "self-asserted",
      "source": {
        "sourceType": "user",
        "assertedBy": "agent-002"
      }
    }
  ],
  "affiliations": [
    {
      "id": "affiliation-001",
      "agent": "agent-002",
      "organization": "agent-org-001",
      "unit": "Department of History",
      "validFrom": "2024-09-01",
      "source": {
        "sourceType": "user",
        "assertedBy": "agent-002"
      }
    }
  ]
}

17.3 Публикация под псевдоним

{
  "agents": [
    {
      "id": "agent-pseudonym-001",
      "type": "person",
      "names": [
        {
          "id": "name-pseudonym-001",
          "display": "Researcher North",
          "usage": "pseudonym",
          "preferred": true
        }
      ]
    }
  ],
  "contributions": [
    {
      "id": "contribution-pseudonym-001",
      "agent": "agent-pseudonym-001",
      "target": "review-001",
      "roles": [
        {
          "id": "role-reviewer-001",
          "term": "reviewer"
        }
      ],
      "visibility": "restricted"
    }
  ]
}

17.4 Невалиден вграден автор

{
  "contributions": [
    {
      "id": "contribution-invalid-001",
      "agent": {
        "fullName": "Example Author",
        "email": "author@example.org"
      },
      "target": "manuscript-001",
      "roles": []
    }
  ]
}

Това е невалидно, тъй като приносът включва запис за лице, подобен на профил, вместо да се позовава на агент, не съдържа роля на приноса и разкрива данни за контакт без класификация на видимостта.

17.5 Невалидно автоматично обединяване

{
  "merge": {
    "agents": ["agent-101", "agent-202"],
    "reason": "same-display-name"
  }
}

Това е невалидно, тъй като само равенството на имената не е достатъчно основание за сливане на идентичности.

18. Нормативни препратки

• Open Manuscript Initiative, Основни принципи, OMI-SPEC-000, версия 0.1.0.
• Open Manuscript Initiative, Scholarly Object Model, OMI-SPEC-120, версия 0.1.0.
• Open Manuscript Initiative, Модел на метаданните, OMI-SPEC-140, версия 0.1.0.
• Open Manuscript Initiative, Терминология и определения.
• Open Manuscript Initiative, Животният цикъл на спецификациите.
• Open Manuscript Initiative, Политика за версиите.

19. Информативни източници

• ORCID идентификатори и екосистема от записи.
• Регистър на изследователските организации.
• Таксономия на ролите на съавторите в CRediT.
• JATS метаданни за автора.
• Метаданни за авторите в Crossref.
• Метаданни за авторите, предоставили данни в DataCite.
• Модел за име на език в стила на цитиране.

20. Състояние на изпълнението

Open Manuscript Studio понастоящем съдържа проучвателни структури, свързани с идентичността:

• OmiPerson със структурирани имена, текст за принадлежност и идентификатори;
• User с идентификатор на профила, имейл адрес, профил, ORCID, външни идентификатори за вход и настройки;
• WorkspaceMember със роли в работната среда, свързани с контекста.

Тези структури демонстрират съответната проектна работа, но все още не прилагат тази спецификация. По-конкретно, настоящият модел на Studio все още се нуждае от:

• ясно разграничаване на самоличността на сметката и на агента;
• обекти на принос, независими от лица;
• контекстуални връзки;
• твърдения за външни идентификатори, съдържащи информация за произхода;
• многобройни многоезични форми на името;
• управление на защитената видимост;
• съгласуване на идентичностите и поведение при обратимо обединяване;
• съответствие между изискванията и кода и тестове за съответствие.

Класификацията на доказателствата, считани за достоверни, се поддържа в „Implementation Status Matrix“.

21. Нерешени въпроси

Проблем	Последици	Необходимо решение	Проследяване
Каноничен речник на машинно четими свойства	Публикуване на схема	Определяне на точните имена и пространства на имена за сериализация.	Бъдещо издание на схемата
Обхват на идентичността на агентите в различните пакети и хранилища	Устойчивост на идентификаторите	Определяне кога локалните идентификатори остават непроменени по време на прехвърляне.	Координация на OMI-SPEC-160
Регистър на контролираните приноси и роли	Оперативна съвместимост	Да се реши дали „OMI“ ще възприеме, профилира или съпостави CRediT и местните роли.	Бъдещ въпрос, свързан с регистъра
Речник на състоянията при верификацията	Оперативна съвместимост на резолверите	Определяне на минимални общи състояния и изисквания за доказателства.	Бъдещ проблем, свързан с валидирането
Пакетиране с прикрита самоличност на рецензента	Поверителност и съхранение	Съгласуване на защитената самоличност с моделите за рецензиране и контейнери.	OMI-SPEC-200 и OMI-SPEC-330
Обмен на асоциации на акаунти	Сигурност	Проверка дали някой защитен профил може да сериализира връзки с акаунти.	OMI-SPEC-190 и OMI-SPEC-310
Моментални снимки на груповото авторство и членството в консорциуми	Посочване на авторството	Определяне на доказателствата за членство и времевия контекст.	Бъдеща ревизия на проекта
Модел на събития за обединяване и разделяне на идентичности	Провенанс	Свързване на операциите с модела за версии и промени.	OMI-SPEC-160

22. История на промените

Версия	Дата	Статус	Класификация на промените	Обобщение
0.1.0	06.08.2026	Проект	Първоначален проект	Активиран е стандартът „OMI-SPEC-150“ и са дефинирани изискванията за агенти, имена, твърдения за външна идентичност, принадлежности, приноси, разделяне на акаунти, поверителност, валидиране и оперативна съвместимост.

23. Благодарности

Настоящият проект се основава на съществуващата терминология на „OMI“, на моделите на домейните „Open Manuscript Studio“ за потребители и работни пространства, както и на утвърдените практики за научни идентификатори и метаданни за автори. Отговорността за цялото нормативно съдържание остава в ръцете на човешките администратори.