OMI-SPEC-160 — Модел за версии и промени

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

Поле	Стойност
Идентификатор	OMI-SPEC-160
Заглавие	Управление на версиите и модел на промените
Версия	0.1.0
Статус	Чернова
Вид документ	Нормативен
Нормативна терминология	Английски
Редактори	Администратори на OMI
Последно актуализирано	06.08.2026 г.
Заменя	Няма
Заменено с	Няма
Зависи от	OMI-SPEC-100, OMI-SPEC-120, OMI-SPEC-140, OMI-SPEC-150
Използва се от	OMI-SPEC-170, OMI-SPEC-190, OMI-SPEC-200, OMI-SPEC-230, OMI-SPEC-310, OMI-SPEC-320, OMI-SPEC-340
Схеми	Няма публикувани
Профили	История на основните ревизии; Разклоняване и сливане; Обмен на моментални снимки
Статус на изпълнението	OMI Implementation Status Matrix
Система за проследяване на проблеми	Проблеми в репозиторията на Open Manuscript Initiative

1. Резюме

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

Моделът прави разграничение между променливо работно състояние и непроменлива ревизия, между ревизия на научен обект и версия на софтуер или схема, както и между възстановяване и деструктивно пренаписване на историята. Той позволява на реализациите да използват извличане на събития (event sourcing), съхранение на моментални снимки, транзакции в бази данни, съхранение с адресиране по съдържание, оперативна трансформация, типове данни с безконфликтно репликиране или други вътрешни техники, при условие че експортираната история на OMI запазва семантиката, изисквана от настоящата спецификация.

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

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

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

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

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

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

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

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

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

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

3.2 Профили за съответствие

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

Профил „История на промените в ядрото“

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

Профил на разклоняването и сливането

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

Профил в Snapshot Exchange

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

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

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

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

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

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

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

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

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

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

REQ-VCH-003: Всяка ревизия, която не е коренова, ТРЯБВА да посочва поне една родителска ревизия. Резултатът от сливането ТРЯБВА да посочва всяка пряка родителска ревизия, включена в него.

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

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

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

REQ-VCH-007: Връщането ТРЯБВА да създаде нова ревизия, която отразява ревизията или набора от промени, които се отменят. ТРЯБВА ДА НЕ изтрива върнатата ревизия от историята.

REQ-VCH-008: При изтриването на адресируем научен обект ЗАДЪЛЖИТЕЛНО трябва да се запази „томбстоун“ или еквивалентен запис за произхода, когато профилът на историята изисква проследимост на изтриването.

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

REQ-VCH-010: Записът за обединяване ТРЯБВА да посочва изходната линия, целевата линия, основата или основите за обединяване, ревизия на резултата, както и всеки нерешен или решен конфликт, за който е известно на оператора на обединяването.

REQ-VCH-011: Потребителят НЕ ТРЯБВА да приема без възражения ревизия, чиито декларирани предшественици липсват, освен ако историята ѝ не е изрично обозначена като частична или повърхностна.

REQ-VCH-012: При експортирането на частична история ЗАДЪЛЖИТЕЛНО трябва да се посочат границите ѝ, пропуснатите предци и основната ревизия, която представлява.

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

REQ-VCH-014: Редакторът, запазващ историята, ТРЯБВА да свърже всеки потвърден набор от промени с идентичност на агент, идентичност на услуга или изричен маркер за неизвестен агент в съответствие с OMI-SPEC-150.

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

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

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

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

4. Обхват

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

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

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

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

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

Управлението на версиите на спецификациите се регулира от Политиката за версии на OMI. Правата за достъп са описани на OMI-SPEC-190. Историята на прегледите е достъпна на OMI-SPEC-200. Връзките между преводите са описани на OMI-SPEC-170. Изданията и резултатите от публикуването са достъпни на OMI-SPEC-230 и OMI-SPEC-240.

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

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

5.1 Единица с версия

Единица от типа „OMI“, чиито последователни потвърдени състояния се представят чрез ревизии.

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

5.2 Работно състояние

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

Работното състояние МОЖЕ да съдържа непотвърдени локални операции, временни грешки при валидиране, състоянието на курсора или информация, специфична за интерфейса. То не се включва автоматично в преносимата история на OMI.

5.3 Преразглеждане

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

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

5.4 Преразглеждане на корените

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

Ревизията на корена може да представлява действително създаване или най-ранната включена ревизия от кратка история. Разграничението ТРЯБВА да бъде посочено.

5.5 Ревизия на главата

Ревизията, която в момента е избрана като най-новото състояние на клон, линия или експортиран изглед на историята.

Графиката на ревизиите може да има повече от една начална точка.

5.6 Набор от промени

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

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

5.7 Събитие за промяна

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

Събитието за промяна записва семантичния замисъл. Не е необходимо то да отразява всяко натискане на клавиш или вътрешна за имплементацията промяна.

5.8 Работа

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

5.9 Моментална снимка

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

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

5.10 Графика на ревизиите

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

Графиката на ревизиите, отговаряща на изискванията, НЕ ТРЯБВА да съдържа ревизия, която е неин предшественик.

5.11 Клон

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

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

5.12 Разклонение

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

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

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

5.14 Обединяване на базовата версия

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

5.15 Конфликт

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

5.16 Разрешаване на конфликти

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

5.17 Връщане

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

5.18 Надгробна плоча

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

5.19 Контролен пункт

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

5.20 Етикет за пускане на пазара

Етикет, разбираем за човека, като например submission-2 или accepted-manuscript, свързан с дадена ревизия.

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

5.21 Частична история

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

5.22 Обзор на състоянието

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

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

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

• Непроменима история на потвърдените събития: потвърдените събития се коригират от по-късни събития, а не чрез незабележимо пренаписване.
• Стабилна идентичност на обекта: редакциите променят състоянието, без да променят без необходимост идентичността на научния обект.
• Семантични събития в логовете за натискания на клавиши: „Portable History“ записва научните операции, а не страничните ефекти от реализацията.
• Явна причинно-следствена връзка: връзките между родителските елементи и базите за обединяване носят причинно-следствено значение; времевите отметки не могат да ги заменят.
• Атрибуция, независима от акаунта: промяната на позоваванията за авторство се отнася до преносими агенти, а не до тайни за удостоверяване.
• Обмен с отчитане на загубите: обявяват се пропуснатите данни от историята и неподдържаните операции.
• Алгоритмична неутралност: вътрешните техники от типа на Git, базирани на събития, бази данни, OT или CRDT могат да се различават, като в същото време генерират оперативно съвместими доказателства от типа „OMI“.
• Защита на личните данни още при проектирането: данните от публичната история и тези от оперативния одит с ограничен достъп могат да се разделят.
• Възпроизводими състояния: моменталните снимки, събитията и обобщенията трябва да позволяват равностойно възстановяване, когато избраният профил го изисква.
• Запазване на двусмислието: нерешените противоречия и неизвестният произход се представят, вместо да се пренебрегват.

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

Versioned entity
    ├── Working state (mutable, implementation-local)
    └── Revision graph
          ├── Revision
          │     ├── parentRevisionIds[]
          │     ├── changeSetIds[]
          │     ├── snapshotRef?
          │     ├── stateDigest?
          │     └── provenance
          ├── Change set
          │     ├── baseRevisionIds[]
          │     ├── events[]
          │     ├── actorId
          │     └── atomicity
          ├── Branch
          │     └── headRevisionId
          └── Merge record
                ├── sourceRevisionIds[]
                ├── baseRevisionIds[]
                ├── conflicts[]
                ├── resolutions[]
                └── resultRevisionId

Моделът не изисква всяка ревизия да съдържа пълна моментална снимка. Историята може да използва:

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

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

8. Различни концепции за версиите

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

Концепция	Пример	Цел
Версия на спецификацията на OMI	OMI-SPEC-160@0.1.0	Определя версията на нормативния модел
Версия на схемата или формата	omi-manuscript-0.2	Определя правилата за сериализация
Версия на приложението	Open Manuscript Studio 0.1.0-alpha.2	Показва версията на софтуера
Идентификатор на ревизия на научен обект	urn:uuid:...	Идентифицира едно неизменяемо, финализирано състояние
Наименование на клон	main, translation-hu	Определя сфера на дейност
Етикет за контролен пункт или освобождаване	submitted-2026-08-06	Маркер за работния процес, разбираем за човека
Издание или версия на публикацията	Version of Record	Обозначение на издателската област

При реализацията НЯМА ДА СЕ ДОПУСКА една от тези стойности да се извежда от друга, освен ако приложимата спецификация изрично не определя това извеждане.

9. Основен модел на данните

9.1 Контейнер с история на версиите

Контейнерът за история на версиите свързва обект с версии с неговите ревизии и метаданни за историята.

Препоръчителни области:

Поле	Кардиналност	Значение
modelVersion	1	Точната версия на „OMI-SPEC-160“
entityId	1	Идентификатор на обекта с версия
historyId	1	Идентификатор на това представяне на историята
headRevisionIds	1..n	Брой представени глави
revisions	1..n	Включени записи за ревизии
changeSets	0..n	Включени записи от набор от промени
branches	0..n	Препратки към разклонения
merges	0..n	Обединяване на доказателствата
historyScope	1	complete, partial, shallow или snapshot-only
boundaryRevisionIds	0..n	Най-ранните включени версии, когато липсва информация за произхода
omissionNotice	0..1	Обяснение на пропуснатите данни, разбираемо както за хората, така и за машините

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

9.2 Преразглеждане

Протоколът за преразглеждане ТРЯБВА да съдържа:

Поле	Кардиналност	Значение
id	1	Непроменлив идентификатор на версията
entityId	1	Идентификатор на обект с версия
parentRevisionIds	0..n	Пряко свързани родители
changeSetIds	0..n	Промени, довели до тази версия
createdAt	1	Време на потвърждаване
createdBy	1	Агент или изричен маркер за неизвестен агент
committedBy	0..1	Услуга или агент, извършил промяната
message	0..1	Обобщение, разбираемо за хората
snapshotRef	0..1	Снимка, свързана с ревизията
stateDigest	0..1	Метаданни за дайджест и канонизация
checkpointLabels	0..n	Етикети за работния процес или версиите
supersedesRevisionIds	0..n	Връзки на изрична корекция или замяна
extensions	0..n	Данни за разширения в пространства на имена

При ревизия на корена СЛЕДВА да се посочи дали тя представлява действително създаване на обект или само граница на повърхностната история.

9.3 Идентификатор на ревизия

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

Производителят МОЖЕ да използва:

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

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

9.4 Взаимоотношения с родителите

Връзките между родителските елементи определят причинно-следствените връзки при ревизията.

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

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

9.5 Набор от промени

Наборът от промени ТРЯБВА да съдържа:

Поле	Кардиналност	Значение
id	1	Идентификатор на набор от промени
entityId	1	Целеви обект с версия
baseRevisionIds	1..n	Щат или щати, за които са създадени промените
events	1..n	Подредени събития на семантична промяна
actorId	1	Отговорен агент или неизвестен маркер
performedBy	0..1	Услуга или софтуерен агент
createdAt	1	Време на създаване
committedAt	0..1	Време на потвърждаване
intent	0..1	Цел, определена от човек или от речник
message	0..1	Обобщение, разбираемо за хората
atomic	1	Трябва ли наборът да се прилага атомарно
correlationId	0..1	Групира промените, свързани с различни обекти или услуги
causedBy	0..n	По-ранни събития, задачи, импорти или заявки
visibility	0..1	Класификация на достъпа: публичен или ограничен

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

9.6 Събитие „Промяна“

Събитието за промяна ТРЯБВА да съдържа:

Поле	Кардиналност	Значение
id	1	Идентификатор на събитието
operation	1	Вид операция
target	1	Дескриптор на стабилна цел
before	0..1	Предишна стойност или хеш при запазване
after	0..1	Нова стойност или хеш при запазване
payload	0..1	Данни, свързани с конкретна операция
sequence	0..1	Ред в набора от промени
actorId	0..1	Преопределяне на участник за конкретно събитие
occurredAt	0..1	Време на събитието, когато е различно от времето на набора от промени
reason	0..1	Причина, определена от човек или от речника
visibility	0..1	Класификация на разкриването
extensions	0..n	Данни за разширения в пространства на имена

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

9.7 Дескриптор на целта

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

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

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

9.8 Терминология, свързана с експлоатацията

Основният терминологичен набор за операциите е:

Операция	Значение
create	Създаване на нов идентифицируем обект
update	Промяна на един или повече атрибути, без да се променя идентичността на обекта
replace	Замяна на стойност или представяне на обект при деклариране на обработка на идентичност
delete	Премахване на обект или свойство и създаване на необходимите доказателства за изтриването
restore	Възстановяване на преди това изтрит или отделен обект
move	Преместване на съществуващ обект между контейнери или местоположения
reorder	Промяна на реда в подредена колекция
attach	Добавяне на съществуваща връзка между обекти или принадлежност
detach	Премахване на връзка или членство без изтриване на обекта
annotate	Добавете обяснение за промяната, редакционна бележка или обосновка в машинно четим формат
transform	Прилагане на декларирана автоматизирана или ръчна трансформация
redact	Ограничаване или премахване на чувствително съдържание при запазване на доказателствата за редактиране
resolve-conflict	Записване на разрешаване на конфликт при сливане
revert	Отмяна на по-ранна ревизия, набор от промени или събитие

Разширенията МОГАТ да дефинират допълнителни операции, като използват идентификатори с пространства от имена.

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

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

10.1 Редакции в работно състояние

Дадена реализация МОЖЕ да събира операции с висока степен на детайлност от интерфейса в променливо работно състояние.

Преди да поемете ангажимент, това МОЖЕ:

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

Вярното представяне ТРЯБВА да запази полученото научно значение и посочения произход.

10.2 Процедура за потвърждаване

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

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

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

10.3 Промени в „No-op“

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

При ревизия с нулева операция задължително трябва да се посочи нейната цел.

10.4 Промени, засягащи няколко юридически лица

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

Реализациите МОГАТ:

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

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

11. Моментални снимки и реконструкция

11.1 Свързване на моментални снимки

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

Една моментална снимка ТРЯБВА да включва или да съдържа препратка към:

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

11.2 Реконструкция

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

Потребителят ТРЯБВА да се увери, че:

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

11.3 Обмен само на моментални снимки

Един пакет „Snapshot Exchange“ МОЖЕ да не съдържа пълната история.

Тя ТРЯБВА да включва:

• идентификатор на представляваното юридическо лице;
• идентификатор на представената ревизия;
• версия на схемата или формата;
• historyScope: snapshot-only;
• уведомление за пропуск;
• познати препратки към родителски версии или изходни версии, когато има такива.

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

11.4 Уплътняване

Реализацията МОЖЕ да компресира вътрешната история с цел спестяване на място или подобряване на производителността.

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

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

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

12. Клонове и глави

12.1 Запис за клон

Записът за клон ТРЯБВА да съдържа:

Поле	Кардиналност	Значение
id	1	Идентификатор на стабилната версия
name	0..1	Име, разбираемо за хората
entityId	1	Елемент с версии
headRevisionId	1	Текуща глава на клон
baseRevisionId	0..1	Ревизия, от която е създаден клонът
createdAt	1	Време на създаване
createdBy	1	Агент или услуга
status	1	active, merged, archived или deleted
purpose	0..1	Превод, рецензия, експеримент, корекция или друга цел

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

12.2 Отделени глави

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

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

12.3 Изтриване на клон

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

13. Обединяване на модел

13.1 Обединяване на записи

Един запис за сливане ТРЯБВА да съдържа:

Поле	Кардиналност	Значение
id	1	Идентификатор на обединения запис
entityId	1	Елемент с версии
sourceRevisionIds	2..n	Комбиниране на разклонени глави
baseRevisionIds	1..n	Избран общ предшественик или предшественици
resultRevisionId	1	Резултат от обединяването
performedBy	1	Агент или услуга
performedAt	1	Време на обединяване
strategy	0..1	Деклариран метод за обединяване
conflicts	0..n	Забелязани конфликти
resolutions	0..n	Приложени резолюции
message	0..1	Обобщение, разбираемо за хората

В ревизията на резултата ЗАДЪЛЖИТЕЛНО трябва да бъдат посочени обединените ревизии на изходния код като преки предшественици, освен ако декларираната стратегия и профилът изрично не определят друго равностойно представяне.

13.2 Избор на база за сливане

При сливането ЗАДЪЛЖИТЕЛНО трябва да се посочи базата или базите за сливане, които са били действително използвани.

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

13.3 Автоматично обединяване

При автоматичното обединяване промените МОГАТ да бъдат комбинирани, когато техните обекти и семантика не са в противоречие.

Примери за това са:

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

При автоматичното обединяване ЗАДЪЛЖИТЕЛНО трябва да се запази приписването на участниците и произходът на промените от всеки включен родословник.

13.4 Категории на конфликтите

Основните категории на конфликтите са:

• concurrent-update;
• update-delete;
• delete-restore;
• move-move;
• reorder-reorder;
• identity-collision;
• schema-incompatibility;
• extension-unknown;
• permission-or-policy;
• integrity-failure;
• other.

Записът за конфликт ТРЯБВА да съдържа:

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

13.5 Разрешаване на конфликти

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

Резолюцията МОЖЕ:

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

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

14. Връщане към предишно състояние, възстановяване и корекция

14.1 Семантика на отмяната

Връщането създава нова история.

Събитието за възстановяване ТРЯБВА да съдържа следната информация:

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

14.2 Възстановяване

При възстановяването на изтрит обект СЛЕДВА да се запази оригиналният идентификатор на обекта, когато се възстановява същият концептуален обект.

Когато възстановяването води до създаването на нов концептуален обект, ТРЯБВА да се присвои нов идентификатор, а връзката с изтрития обект СЛЕДВА да се запише.

14.3 Корекция на погрешна информация за произхода

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

Реализациите МОГАТ да ограничават показването на грешната стойност по причини, свързани с поверителността или с правни изисквания, но ТРЯБВА да съхраняват оторизирани одитни доказателства за корекцията, освен ако политиката за съхранение не изисква потвърдено унищожаване.

15. Изтриване и „надгробни камъни“

Надгробната плоча ТРЯБВА да съдържа:

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

В един публичен надгробен камък МОЖЕ да бъде пропуснато съдържание, което преди това е било ограничено.

Потребителят ТРЯБВА да прави разграничение между:

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

Тези действия не са взаимозаменяеми.

16. Подреждане и движение

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

Събитието за повторна поръчка ТРЯБВА да идентифицира:

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

При преносимото подреждане СЛЕДВА да се дава предимство на стабилната семантика на съседство или ранг пред преходните индекси на масиви с начало от нула.

При преместване между контейнери идентичността на обекта ТРЯБВА да се запази, освен ако приложимият модел изрично третира преместването като „копиране и изтриване“.

17. Авторство и произход

17.1 Посочване на агента

При промяна на авторството ЗАДЪЛЖИТЕЛНО трябва да се посочи агент, дефиниран съгласно OMI-SPEC-150, или изрично да се посочи, че авторът е неизвестен, неидентифициран, неразкрит или че става дума за сервизен агент.

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

17.2 Отговорност на хората и софтуера

Една промяна МОЖЕ да се състои в:

• actorId (лице или организация, отговаряща за научното решение);
• performedBy: софтуерен агент или услуга, изпълняваща операцията;
• committedBy: агентът или услугата, която одобрява или запазва промяната;
• onBehalfOf: декларирана връзка за делегиране.

При автоматично извършвана трансформация СЛЕДВА да се идентифицират както софтуерният агент, така и човекът или процесът, предизвикал трансформацията, когато това е известно.

17.3 История на импортираните данни

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

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

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

18. Време и причинно-следствена последователност

Преразглеждането на взаимоотношенията между родителите и последователността на събитията предоставя доказателства за причинно-следствена връзка.

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

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

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

19. Доказателства за почтеност

19.1 Обобщение по щати

Записът в държавния регистър ТРЯБВА да съдържа:

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

19.2 Целостност на събитията и графиките

Реализациите МОГАТ да предоставят:

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

Само по себе си използването на тези техники не доказва авторството, правната валидност или семантичната коректност.

19.3 Нарушение на целостта

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

20. Защита на личните данни, поверителност и редактиране

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

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

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

Тайните за удостоверяване, хешовете на паролите, токените за сесия, частните ключове и токените за обновяване НЕ ТРЯБВА да се появяват в историята на научните публикации на OMI.

20.1 Регистър на редакциите

При редактирането СЛЕДВА да се запазят:

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

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

20.2 Задължения за правомерно изтриване и съхранение

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

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

21. Сериализация

21.1 Примерен исторически запис

Следващият пример е с информативна цел и не определя каноничната схема.

{
  "modelVersion": "OMI-SPEC-160@0.1.0",
  "historyId": "urn:uuid:1798d883-e226-4a39-a601-cadef82aa223",
  "entityId": "urn:uuid:manuscript-001",
  "historyScope": "complete",
  "headRevisionIds": [
    "urn:uuid:revision-002"
  ],
  "revisions": [
    {
      "id": "urn:uuid:revision-001",
      "entityId": "urn:uuid:manuscript-001",
      "parentRevisionIds": [],
      "changeSetIds": ["urn:uuid:changeset-001"],
      "createdAt": "2026-08-06T19:00:00Z",
      "createdBy": "urn:uuid:agent-001",
      "message": "Create manuscript"
    },
    {
      "id": "urn:uuid:revision-002",
      "entityId": "urn:uuid:manuscript-001",
      "parentRevisionIds": ["urn:uuid:revision-001"],
      "changeSetIds": ["urn:uuid:changeset-002"],
      "createdAt": "2026-08-06T19:15:00Z",
      "createdBy": "urn:uuid:agent-001",
      "message": "Revise title"
    }
  ],
  "changeSets": [
    {
      "id": "urn:uuid:changeset-002",
      "entityId": "urn:uuid:manuscript-001",
      "baseRevisionIds": ["urn:uuid:revision-001"],
      "actorId": "urn:uuid:agent-001",
      "createdAt": "2026-08-06T19:14:58Z",
      "atomic": true,
      "events": [
        {
          "id": "urn:uuid:event-002",
          "operation": "update",
          "target": {
            "entityId": "urn:uuid:manuscript-001",
            "property": "title"
          },
          "before": "Untitled manuscript",
          "after": "Version-aware scholarly editing",
          "sequence": 1
        }
      ]
    }
  ]
}

21.2 Примерен запис за обединяване

{
  "id": "urn:uuid:merge-001",
  "entityId": "urn:uuid:manuscript-001",
  "sourceRevisionIds": [
    "urn:uuid:revision-author",
    "urn:uuid:revision-editor"
  ],
  "baseRevisionIds": ["urn:uuid:revision-common"],
  "resultRevisionId": "urn:uuid:revision-merged",
  "performedBy": "urn:uuid:agent-editor",
  "performedAt": "2026-08-06T20:00:00Z",
  "strategy": "three-way-semantic",
  "conflicts": [
    {
      "id": "urn:uuid:conflict-001",
      "category": "concurrent-update",
      "targets": [
        {
          "entityId": "urn:uuid:manuscript-001",
          "property": "title"
        }
      ],
      "status": "resolved",
      "resolutionEventId": "urn:uuid:event-resolution-001"
    }
  ]
}

22. Правила за валидиране

Валидаторът ТРЯБВА да съобщи за грешка, когато:

• идентификаторът на ревизия се повтаря в рамките на една и съща история;
• ревизия без права на суперпотребител няма родителска ревизия, ако няма декларация за „shallow-boundary“;
• родителската ревизия принадлежи към различен обект, без да има изрично междуобектно отношение;
• графиката на ревизиите съдържа цикъл;
• липсва декларирана ревизия на главата;
• наборът от промени няма базова ревизия;
• събитието няма операция или цел;
• един набор от атомни промени се представя като частично приложен;
• в резултата от обединяването липсват задължителните преки родители;
• при разрешен конфликт липсват доказателства за разрешаването му;
• възстановяването изтрива или заменя посочената финализирана ревизия;
• публичното разкриване разкрива данни, маркирани като „с ограничен достъп“ или „секретни“;
• в обобщаващия запис не се посочва алгоритъмът;
• В историята на „complete“ има неразрешени препратки към липсващи родители.

Валидаторът ТРЯБВА да подаде предупреждение, когато:

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

23. Обработка на неизвестни данни и данни за разширенията

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

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

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

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

24. Съвместимост и миграция

24.1 Прехвърляне от ръкописи, съдържащи само времеви отметки

Ръкопис, съдържащ единствено стойности от типа „version“, „createdAt“ и „updatedAt“, не съдържа съответстваща история на промените от типа „OMI“.

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

Синтетичната редакция ТРЯБВА:

• да се определи събитието, свързано с миграцията или вноса;
• да се обяви, че данните за по-ранния период не са налични;
• използвайте historyScope: snapshot-only или shallow;
• избягвайте да измисляте автори, събития или причинно-следствени връзки;
• да запазват оригиналните времеви отметки като твърдения на източника, а не като проверена история на комитовете, когато значението им е неясно.

24.2 Миграция от вградени одитни логове

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

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

24.3 Съвместима еволюция

Една съвместима бъдеща версия на тази спецификация може:

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

Несъвместима промяна включва:

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

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

25.1 Git и разпределен контрол на версиите

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

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

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

25.2 „JSON“ Patch и подобни формати на работа

JSON Patch или подобни формати МОГАТ да кодират операции на ниско ниво. Производителят ТРЯБВА да ги допълва, когато е необходимо, за да се запазят стабилното насочване към обекти, семантичният замисъл, произходът на участниците, семантиката на преместването и поведението на разширението „OMI“.

25.3 Системи, базирани на събития

Система, базирана на събития, МОЖЕ да преобразува нативни събития директно, когато тяхната семантика отговаря на настоящата спецификация. Вътрешните събития, които разкриват поверителна информация, подробности за хранилището или нестабилни пътища на реализация, ТРЯБВА да бъдат преобразувани в преносими събития от типа „OMI“.

25.4 CRDT и системи за оперативна трансформация

Реализацията на CRDT или OT МОЖЕ да запази вътрешно нативните операции. За обмен на данни от типа „OMI“ тя ТРЯБВА да осигурява семантиката на ревизиите, участниците, целите, сливането и пълнотата на историята, изисквана от декларирания ѝ профил.

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

25.5 W3C PROV и системи за проследяване на произхода

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

26. Съображения, свързани със сигурността

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

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

Реализациите ТРЯБВА:

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

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

Интерфейсите за история на версиите ТРЯБВА:

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

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

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

При промени в текста ЗАДЪЛЖИТЕЛНО трябва да се запазят метаданните за езика и азбуката на засегнатото съдържание, когато такива метаданни съществуват.

Приложенията ТРЯБВА да правят разграничение между:

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

При сравняването на низове, токенизацията, нормализирането и обединяването на текстове НЕ СЛЕДВА да се приема, че се използва английски език, латинска азбука или думи, разделени с интервали.

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

Пакетът за съхранение, предназначен за запазване на историята на версиите, СЛЕДВА да включва:

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

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

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

Open Manuscript Studio В момента съхранява променливо състояние на ръкописа с четим за човека низ „version“, както и времеви отметки „createdAt“ и „updatedAt“. Действията по съхранение директно заменят текущото състояние и актуализират времевата отметка за модификация.

Студиото все още не предлага:

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

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

31. Препоръчителна последователност на внедряване

1. добавете versioningModelVersion, historyId и headRevisionId към историята на агрегата на ръкописа или към историята на свързаната работна среда;
2. определят типовете „Revision“, „ChangeSet“, „ChangeEvent“ и „stable“;
3. да обедини текущите промени в заглавията, резюметата, блоковете, разделите и авторите в семантични набори от промени;
4. да запише идентификатора на свързания агент на автентифицирания потребител като изпълнител, когато такъв е наличен;
5. създаване на неизменяеми линейни версии и моментални снимки;
6. да се добави функцията „отмяна“ като история, която възстановява предишното състояние, а не като изтриване на състоянието;
7. да се добавят надгробни плочи за изтрити секции, блокове, агенти и приноси;
8. да се реализира експортиране и импортиране на непълна история или история, състояща се само от моментални снимки;
9. да се добави интерфейс за историята на ревизиите и достъпни обобщения на промените;
10. добавяне на клонове, обединяване на бази, конфликти и разрешаването им;
11. да публикува канонични схеми, както и валидни и невалидни фикстури;
12. съпоставяне на тестовете с изискванията на „REQ-VCH-*“.

32. Изисквания към изпитванията и приспособленията

Един бъдещ комплект приспособления за проверка на съответствието ТРЯБВА да включва:

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

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

Проектът оставя отворени следните въпроси:

1. дали каноничната схема трябва да включва хронологията в самия ръкопис или да допуска само външен ресурс с хронологията;
2. кои профили за канонизация трябва да бъдат регистрирани за държавните дайджести;
3. дали в профила „Stable“ трябва да се изисква идентификаторите на ревизиите да бъдат URI;
4. как семантичните операции върху текста трябва да се позовават на диапазони след едновременни редакции;
5. кои стойности от операционния речник трябва да се превърнат в термини от контролирания регистър;
6. как трябва да бъдат представяни атомарните транзакции между обекти в основната схема;
7. в каква степен ограничените одиторски доказателства могат да се съхраняват в преносими пакети;
8. дали категориите на контролните точки изискват специален контролиран речник;
9. кои стратегии за сливане следва да бъдат стандартизирани извън изискванията за доказателства;
10. как пакетите за съхранение трябва да представят съкратената криптирана история.

Тези проблеми не пречат на внедряването на профила „Core Revision History“.

34. Индекс на нормативните изисквания

Изискване	Предмет
REQ-VCH-001	Идентичност на ревизиите
REQ-VCH-002	Непроменимост на ревизиите
REQ-VCH-003	Взаимоотношения с родителите
REQ-VCH-004	Проследяване на набора от промени
REQ-VCH-005	Провеждане на събития и цели
REQ-VCH-006	Разграничаване на понятията за версии
REQ-VCH-007	Неразрушително възстановяване
REQ-VCH-008	Проследяемост на изтриването
REQ-VCH-009	Семантика на преместването и пренареждането
REQ-VCH-010	Обединяване на доказателства
REQ-VCH-011	Работа с липсващи родители
REQ-VCH-012	Разкриване на частична история
REQ-VCH-013	Защита на историята с ограничен достъп
REQ-VCH-014	Посочване на източника
REQ-VCH-015	Съхранение на разширения
REQ-VCH-016	Разграничаване на времевата отметка и причинно-следствената връзка
REQ-VCH-017	Алгоритъмът „Digest“ и неговият обхват
REQ-VCH-018	Атомарност

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

Версия	Дата	Резюме
0.1.0	06.08.2026 г.	Първоначален проект, определящ неизменни ревизии, семантични набори от промени и събития, графики на ревизиите, моментални снимки, разклонения, сливания, конфликти, възстановявания, „надгробни камъни“, произход, цялостност, обмен на частична история и указания за внедряване.

36. Обобщение

OMI-SPEC-160 определя преносим модел на историята за научни обекти.

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