Преминете към основното съдържание

Open Manuscript Initiative Регистър на спецификациите

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

ПолеСтойност
Тип документРегистър за управление
СтатусЧернова
Версия0.3.1
Нормативна терминологияАнглийски
Пространство на имена в регистъраOMI-SPEC
Приложимо заНормативни спецификации на OMI и запазени идентификатори на спецификации
Последно актуализирано05.09.2026

1. Цел​

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

В него се определя:

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

Регистърът съществува, защото по-ранните документи от типа „OMI“ са били създадени съгласно няколко временни схеми за номериране. Някои идентификатори са били присвоени на повече от един документ. Един стабилен набор от стандарти не може да съдържа двусмислени идентификатори.

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

2. Правомощия​

Идентификаторите, изброени в раздела Регистър на каноничните спецификации, са официалните идентификатори на спецификациите на OMI.

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

Този регистър не гарантира, че всяка включена в него спецификация е стабилна. Той присвоява идентичност независимо от степента на зрялост. Дадена спецификация може да бъде със статус „Запазена“, „Експериментална“, „Проект“, „Кандидат за преглед“, „Кандидат за внедряване“, „Стабилна“, „Отменена“ или „Заменена“.

3. Синтаксис на идентификаторите​

Регистрираният идентификатор на спецификация от типа „OMI“ има следния формат:

OMI-SPEC-NNN

където NNN е трицифрено десетично число.

Примери:

OMI-SPEC-000
OMI-SPEC-120
OMI-SPEC-221
OMI-SPEC-350

Числовата част представлява идентификатор, а не номер на версия и не е ранг на приоритет.

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

OMI-SPEC-210, version 0.2.0

4. Архитектура на номерирането​

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

ДиапазонКатегория
000–099Основни принципи и конституционни спецификации, общовалидни за всички пакети
100–199Основни семантични модели, модели за идентичност, документи, анотации, валидиране и сътрудничество
200–299Модели за научен работен процес, библиография, цитиране, рецензиране, визуализация и публикуване
300–399Платформа, разширяемост, API, пакетиране, обмен, импорт/експорт и спецификации за съответствие
400–899Запазено за бъдещи групи спецификации на OMI
900–999Запазено за бъдеща експериментална политика за разпределение; не е достъпно за едностранно използване

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

Пример:

  • OMI-SPEC-220 определя библиографските записи;
  • OMI-SPEC-221 определя библиотеките с референции към ръкописи и взаимодействието с регистъра.

5. Състояния на регистъра​

Един запис в регистъра може да бъде в едно от следните състояния на разпределение.

Запазено​

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

Запазен идентификатор НЕ СЛЕДВА да се присвоява на друг субект.

Активен​

Съществува каноничен спецификационен документ, който участва в жизнения цикъл на „OMI“.

Статусът на жизнения цикъл се регистрира отделно.

Остаряло​

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

Отменено​

Определен наследник официално заменя спецификацията.

Оттеглено​

Разработката приключи, преди спецификацията да придобие статут „Стабилна“. Идентификаторът остава трайно недостъпен за повторна употреба.

6. Регистър на каноничните спецификации​

6.1 Основи и основни семантични модели​

ИдентификаторОфициално наименованиеРазпределениеЖивотВерсияКаноничен път
OMI-SPEC-000Основни принципиАктивенЧернова0.1.0docs/foundations/core-principles.md
OMI-SPEC-100Модел на документаАктивенЧернова0.1.0docs/specifications/document-model.md
OMI-SPEC-110Модел „Anchor“АктивенПроект0.1.0docs/specifications/anchor-model.md
OMI-SPEC-120Модел на научни обектиАктивенЧернова0.1.0docs/specifications/core/scholarly-object-model.md
OMI-SPEC-130Модел за анотиранеАктивенЧернова0.2.0docs/specifications/annotation-model.md
OMI-SPEC-140Модел на метаданниАктивенЧернова0.1.0docs/specifications/metadata-model.md
OMI-SPEC-150Модел за идентичност и сътруднициАктивенЧернова0.1.0docs/specifications/identity-contributor-model.md
OMI-SPEC-160Модел за версии и промениАктивенЧернова0.1.0docs/specifications/versioning-change-model.md
OMI-SPEC-170Модел за преводЗапазено——docs/specifications/translation-model.md
OMI-SPEC-180Модел за валидиранеЗапазено——docs/specifications/validation-model.md
OMI-SPEC-190Модел за сътрудничество и разрешенияЗапазено——docs/specifications/collaboration-permission-model.md

6.2 Научен работен процес, източници и публикуване​

ИдентификаторОфициално наименованиеРазпределениеЖивотВерсияКаноничен път
OMI-SPEC-200Модел за прегледАктивенЧернова0.1.0docs/specifications/review-model.md
OMI-SPEC-210Модел за цитиранеАктивенЧернова0.2.0docs/specifications/citation-model.md
OMI-SPEC-220Модел на библиографски записАктивенЧернова0.1.0docs/specifications/bibliographic-record-model.md
OMI-SPEC-221Архитектура на справочната библиотека и регистъраАктивнаЧернова0.1.0docs/specifications/reference-library-registry.md
OMI-SPEC-230Модел на публикуванеАктивенЧернова0.1.0docs/specifications/publishing-model.md
OMI-SPEC-240Модел на профила за визуализация и публикуванеЗапазено——docs/specifications/rendering-publication-profile-model.md

6.3 Платформа, обмен и съответствие​

ИдентификаторОфициално наименованиеРазпределениеЖивотВерсияКаноничен път
OMI-SPEC-300Архитектура на плъгинитеАктивнаЧернова0.1.0docs/specifications/plugin-architecture.md
OMI-SPEC-310Платформа APIАктивнаЧернова0.1.0docs/specifications/api.md
OMI-SPEC-320Формат на файлаАктивенПроект0.2.0docs/specifications/file-format.md
OMI-SPEC-330Контейнерна архитектураАктивнаЧернова0.1.0docs/specifications/container-architecture.md
OMI-SPEC-340Модел за внос и износЗапазено——docs/specifications/import-export-model.md
OMI-SPEC-350Модел на възможностите и съответствиетоЗапазено——docs/specifications/capability-conformance-model.md

7. Регистър на зависимостите​

Списъкът с зависимости съдържа преките нормативни зависимости, които се очакват за каноничната архитектура на спецификацията. В етапа „Проект“ тези зависимости могат да бъдат прецизирани, преди да се премине към етапа „Кандидат за преглед“.

ИдентификаторПряко свързани зависимости
OMI-SPEC-000Няма
OMI-SPEC-100OMI-SPEC-000, OMI-SPEC-120
OMI-SPEC-110OMI-SPEC-000, OMI-SPEC-100, OMI-SPEC-120
OMI-SPEC-120OMI-SPEC-000
OMI-SPEC-130OMI-SPEC-100, OMI-SPEC-110, OMI-SPEC-120
OMI-SPEC-140OMI-SPEC-000, OMI-SPEC-120
OMI-SPEC-150OMI-SPEC-120, OMI-SPEC-140
OMI-SPEC-160OMI-SPEC-100, OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-150
OMI-SPEC-170OMI-SPEC-100, OMI-SPEC-110, OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-150, OMI-SPEC-160
OMI-SPEC-180OMI-SPEC-000, OMI-SPEC-100, OMI-SPEC-110, OMI-SPEC-120, OMI-SPEC-130, OMI-SPEC-140
OMI-SPEC-190OMI-SPEC-100, OMI-SPEC-120, OMI-SPEC-150, OMI-SPEC-160
OMI-SPEC-200OMI-SPEC-110, OMI-SPEC-130, OMI-SPEC-150, OMI-SPEC-160, OMI-SPEC-190
OMI-SPEC-210OMI-SPEC-110, OMI-SPEC-120, OMI-SPEC-220, OMI-SPEC-221
OMI-SPEC-220OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-150
OMI-SPEC-221OMI-SPEC-140, OMI-SPEC-210, OMI-SPEC-220
OMI-SPEC-230OMI-SPEC-100, OMI-SPEC-140, OMI-SPEC-180, OMI-SPEC-210, OMI-SPEC-240, OMI-SPEC-320
OMI-SPEC-240OMI-SPEC-100, OMI-SPEC-140, OMI-SPEC-210
OMI-SPEC-300OMI-SPEC-000, OMI-SPEC-350
OMI-SPEC-310OMI-SPEC-100, OMI-SPEC-150, OMI-SPEC-190, OMI-SPEC-350
OMI-SPEC-320OMI-SPEC-100, OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-160, OMI-SPEC-180
OMI-SPEC-330OMI-SPEC-320
OMI-SPEC-340OMI-SPEC-100, OMI-SPEC-140, OMI-SPEC-180, OMI-SPEC-220, OMI-SPEC-320
OMI-SPEC-350OMI-SPEC-000, OMI-SPEC-300, OMI-SPEC-310, OMI-SPEC-320, OMI-SPEC-340

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

8. Миграция на стари идентификатори​

8.1 Причина за миграцията​

Преди създаването на този регистър в документацията на OMI се използваха два несъвместими подхода за номериране:

  1. кратка поредица от страници, като например OMI-SPEC-001 до OMI-SPEC-012;
  2. серия, структурирана по категории, като например OMI-SPEC-100, OMI-SPEC-110 и OMI-SPEC-120.

Кратката последователност съдържа сблъсъци:

  • OMI-SPEC-003 се използваше както от модела „Anchor“, така и от модела „Annotation“;
  • OMI-SPEC-006 се използваше както от модела „Рецензия“, така и от модела „Библиографска записка“;
  • OMI-SPEC-007 се използваше както от модела за публикуване, така и от архитектурата на справочната библиотека и регистъра.

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

Поради това серията, базирана на категории, се приема като канонична система за регистриране. Тя вече фигурира в архитектурната карта на „OMI“ и в каноничния основен модел на научните обекти.

8.2 Таблица със стари псевдоними​

Следните идентификатори са исторически или временни псевдоними. Те НЕ ТРЯБВА да се използват за нови нормативни препратки.

Стари или временни идентификаториИсторическа употребаКанонични идентификаториДействия по миграцията
OMI-SPEC-001Модел на документаOMI-SPEC-100Заместване на идентификатора; запазване на стария URL, когато е възможно
OMI-SPEC-002Неофициално наричан „моделът на котвата“OMI-SPEC-110Замяна на препратките към зависимости
OMI-SPEC-003Модел „Anchor“OMI-SPEC-110Замяна на идентификатора
OMI-SPEC-003Модел за анотиранеOMI-SPEC-130Замяна на идентификатор
OMI-SPEC-004Модел на метаданнитеOMI-SPEC-140Замяна на идентификатора
OMI-SPEC-005Модел за цитиранеOMI-SPEC-210Замяна на идентификатора
OMI-SPEC-006Модел за прегледOMI-SPEC-200Замяна на идентификатора
OMI-SPEC-006Модел на библиографски записOMI-SPEC-220Замяна на идентификатор
OMI-SPEC-007Модел на публикуванеOMI-SPEC-230Замяна на идентификатор
OMI-SPEC-007Архитектура на справочната библиотека и регистъраOMI-SPEC-221Замяна на идентификатор
OMI-SPEC-008Архитектура на плъгинитеOMI-SPEC-300Замяна на идентификатор
OMI-SPEC-009По-ранен научен модел на обектиOMI-SPEC-120Обединяване на съдържанието в каноничен документ
OMI-SPEC-010Платформа APIOMI-SPEC-310Замяна на идентификатора
OMI-SPEC-011Формат на файлаOMI-SPEC-320Идентификатор „Replace“
OMI-SPEC-012Контейнерна архитектураOMI-SPEC-330Замяна на идентификатор

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

8.3 Изисквания за миграция​

Фазата на рефакторинг на документацията ТРЯБВА:

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

9. Каноничен модел на научните обекти​

OMI-SPEC-120 е присвоен на модела „Scholarly Object Model“ на адрес:

docs/specifications/core/scholarly-object-model.md

Отделен документ на адрес:

docs/specifications/scholarly-object-model.md

е дубликат от старата система, свързан с временния идентификатор OMI-SPEC-009.

Полезното му съдържание трябва да бъде прегледано и обединено в каноничния документ OMI-SPEC-120. След обединяването старият адрес трябва да се превърне в пренасочване или в изрично уведомление за преместване/заместване, а не да остане като втора нормативна спецификация.

10. Правила за каноничния път​

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

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

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

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

11. Правила за заглавията​

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

Промяна на заглавието на редакционния документ МОЖЕ да се извърши без промяна на идентификатора, когато обхватът и нормативният предмет останат същите.

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

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

12. Полета за версия и жизнен цикъл​

Всяка спецификация от типа „Active“ ТРЯБВА да декларира и двете:

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

Примери:

OMI-SPEC-210
Version: 0.2.0
Status: Draft

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

Стойностите на статуса се регулират от документа „Животният цикъл на спецификацията“. Повишаването на версиите се регулира от „Политиката за версиите“.

13. Запазени спецификации​

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

Една запазена спецификация става активна едва след като:

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

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

14. Процедура за разпределение​

Предложението за нов идентификатор ТРЯБВА да включва:

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

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

Идентификаторът МОЖЕ да бъде запазен, преди да съществува пълният проект, когато ранното му разпределяне предотвратява конфликти или координира паралелната работа.

15. Забрана за едностранно разпределяне​

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

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

Нерегистрираните номера, които се появяват в раздели, издания, примери или експериментални документи, нямат постоянен статут.

16. Постоянство на идентификаторите​

След регистрацията идентификаторът ТРЯБВА да остане свързан със същия родословник на концептуалните спецификации.

Идентификаторът НЕ ТРЯБВА да се променя поради:

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

Оттеглен или заменен идентификатор остава запазен завинаги.

17. Разделяне и обединяване на спецификации​

17.1 Разделяне​

Когато една спецификация се разделя на няколко спецификации с независими версии:

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

17.2 Обединяване​

Когато се обединят няколко спецификации:

  • един идентификатор МОЖЕ да бъде запазен, ако неговата концептуална линия ясно доминира;
  • другите идентификатори се отменят;
  • СЛЕДВА да се присвои нов идентификатор, когато нито един от съществуващите идентификатори не отразява точно обединената област на действие;
  • Заменените идентификатори НЕ ТРЯБВА да се използват повторно.

18. Записи за преустановяване на използването и замяна​

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

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

Каноничната страница ТРЯБВА да остане достъпна или да пренасочва към архивна начална страница.

19. Връзки между схеми, профили и регистри​

Идентификаторът на спецификацията „OMI“ идентифицира спецификация в проза. Той не идентифицира автоматично:

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

Тези артефакти изискват собствени идентификатори или имена с версии съгласно приложимите правила за управление на „OMI“.

Записът в регистъра ТРЯБВА да съдържа препратка към такива артефакти, когато те съществуват.

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

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

Базираната на доказателства база данни „OMI Implementation Status Matrix“ съдържа информация за реализацията, схемата, тестовите случаи, валидатора, тестването и доказателствата за независима реализация за всеки регистриран идентификатор.

Наличието на код със сходно име в Open Manuscript Studio не представлява достатъчно доказателство за съответствие със спецификацията.

21. Официални преводи​

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

Пример:

OMI-SPEC-210 — Citation Model
English source version: 0.2.0
Hungarian translation revision: hu-1

Преводът НЕ ТРЯБВА да получава различен номер от серията „OMI-SPEC“.

Метаданните на превода трябва да посочват точната нормативна изходна версия и състоянието на синхронизацията.

22. Позовавания на регистрирани спецификации​

При първото споменаване на нормативна препратка СЛЕДВА да се използват както идентификаторът, така и заглавието:

OMI-SPEC-210, Citation Model

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

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

OMI-SPEC-210 version 0.2.0

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

23. Регистър, подходящ за машинно четене​

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

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

identifier: OMI-SPEC-210
title: Citation Model
allocation: active
status: draft
version: 0.2.0
canonicalPath: docs/specifications/citation-model.md
category: scholarly-references
dependsOn:
  - OMI-SPEC-110
  - OMI-SPEC-120
  - OMI-SPEC-220
  - OMI-SPEC-221
legacyAliases:
  - OMI-SPEC-005
implementationStatus: see-implementation-matrix

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

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

24. Документи за управление извън пространството от имена „OMI-SPEC“​

Следните документи уреждат набора от спецификации, но сами по себе си не получават идентификатори от типа „OMI-SPEC“:

ДокументКаноничен път
Устав на „Open Manuscript Initiative“docs/governance/charter.md
План за развитие на „OMI“ 1.0docs/governance/roadmap-to-omi-1.0.md
Одит на архитектурата на OMIdocs/governance/architecture-audit.md
Животният цикъл на спецификациятаdocs/governance/specification-lifecycle.md
Политика за версиитеdocs/governance/versioning-policy.md
Ръководство за стил на спецификациитеdocs/governance/style-guide.md
Терминология и определенияdocs/governance/terminology.md
Регистър на спецификациитеdocs/governance/specification-registry.md
Шаблон за спецификацияdocs/governance/specification-template.md
Матрица за състоянието на внедряванетоdocs/governance/implementation-status-matrix.md

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

25. Първоначална последователност на миграцията​

След въвеждането на този регистър препоръчителният ред на миграцията е следният:

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

26. Контрол на промените​

Промените в този регистър се класифицират, както следва.

Промяна в патча​

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

Незначителна промяна​

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

Значителна промяна​

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

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

27. Ефекти от осиновяването​

Въвеждането на този регистър има следните непосредствени последици:

  • трицифровите идентификатори, базирани на категории, стават канонични;
  • кратките последователни идентификатори се превръщат в остарели временни псевдоними;
  • конфликтите при идентификаторите се разрешават, без да се използват повторно числа, по отношение на които има неяснота;
  • docs/specifications/core/scholarly-object-model.md става каноничният източник на OMI-SPEC-120;
  • планираните спецификации получават защитени резервирани идентификатори;
  • При изготвянето на бъдещи спецификации трябва да се правят справки с този регистър и да се актуализира.

Само по себе си приемането не променя статуса на жизнения цикъл на която и да е спецификация на „Стабилна“ и не представлява твърдение за съответствие на реализацията.

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

ВерсияДатаОбобщение
0.3.105.09.2026Преминаване на „OMI-SPEC-320“ (разширен формат на файлове) към чернова версия 0.2.0 след пълното пренаписване на шаблона и публикуването на първата канонична схема на ръкописа и прикачните файлове.
0.3.006.08.2026Активирани са „OMI-SPEC-160“, „Versioning“ и „Change Model“ като чернова версия 0.1.0.
0.2.006.08.2026Активирани са „OMI-SPEC-150“, „Identity“ и „Contributor Model“ като чернова версия 0.1.0; добавена е връзка към матрицата за внедряване и е актуализирана регистрацията на документите за управление.
0.1.006.08.2026Създадена е каноничната архитектура на идентификаторите за спецификации на OMI и първоначалният регистър.

29. Обобщение​

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

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