OMP Профил за интеграция v1

Статус: Чернова
Основен протокол: omi-integration/1
Идентификатор на профила: omi-integration/1/omp

1. Обхват

Профилът за интеграция „OMP“ определя как инсталацията на Open Monograph Press (OMP) съпоставя работните процеси при издаването на научни книги с неутралния по отношение на платформите стандарт за интеграция „OMI“ API v1.

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

OMP а услугата „OMI“ остава отделно приложение с отделен слой за съхранение на данни. Плъгинът за интеграция „OMP“ действа като адаптер. „Open Manuscript Studio“ НЕ ТРЯБВА да осъществява пряк достъп до базата данни „OMP“ или до директорията с частни файлове.

2. Архитектурна граница

OMP
Own application and database
        |
        | OMP OMI Integration Plugin
        | supported PKP/OMP services / repositories / hooks
        |
        | HTTPS + OMI Integration API v1
        v
Open Manuscript Studio
Own application and PostgreSQL database

Адаптерът НЕ ТРЯБВА да изисква промени в основните файлове на OMP. Той СЛЕДВА да изолира специфичните за версията детайли на реализацията на OMPот протоколния слой на OMI.

3. Модел на авторитета

OMP е авторитетен източник за:

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

OMI / „Студио“ е авторитет в областта на:

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

4. Необходимо съпоставяне на профилите

OMI Интеграция API ресурс	OMP концепция
installation	Инсталация наOMP
context	преса
submission	обект от работния процес за подаване на статии / монографии в списанието „OMP“
component	глава, предни страници, задни страници, приложение или друг елемент на публикацията
contributor	автор, редактор, преводач, автор на глава или друг сътрудник
file	файл за подаване или производство
reviewAssignment	Задание за рецензия на „OMP“
reviewRound	Преглед на „OMP“
revision	проследимо състояние на редакцията на ръкописа/подадената статия
publication	издаване на монографии и състояние на каталога

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

5. Идентификационни данни за инсталацията

Всяка свързана инсталация на „OMP“ ТРЯБВА да разполага със стабилен installationId.

Пример:

{
  "installationId": "omp-example-university",
  "platform": "omp",
  "profile": "omi-integration/1/omp",
  "baseUrl": "https://books.example.edu/"
}

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

6. Контекст на печата

Пресата от OMP съответства на OMI context.

{
  "externalId": "3",
  "type": "press",
  "path": "example-press",
  "name": {
    "en": "Example University Press"
  },
  "url": "https://books.example.edu/index.php/example-press"
}

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

7. Съпоставяне на подадените данни

Една научна публикация от OMP съответства на OMI submission.

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

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

Пример:

{
  "externalId": "431",
  "type": "edited-volume",
  "status": "review",
  "title": {
    "en": "Studies in Scholarly Communication"
  },
  "primaryLocale": "en",
  "updatedAt": "2026-08-07T18:30:00Z"
}

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

8. Сборници с научни трудове

Профилът „OMP“ разглежда структурата на съединенията като основен аспект на интеграцията.

Представянето в OMI МОЖЕ да съдържа:

Book
├── Front matter
│   ├── Title page
│   ├── Preface
│   └── Introduction
├── Chapter 1
├── Chapter 2
├── Chapter 3
├── Appendix
├── Bibliography
└── Back matter

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

9. Компоненти

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

Пример:

{
  "externalId": "chapter-7",
  "type": "chapter",
  "title": {
    "en": "The Evolution of Scholarly Editing"
  },
  "sequence": 7,
  "parentExternalId": null
}

Един компонент ТРЯБВА да запазва:

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

Компонентите МОГАТ да бъдат вложени един в друг.

10. Сборници

Сборникът НЕ ТРЯБВА да се свежда до списък с един-единствен автор.

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

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

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

11. Обхват на участниците

Пример за редактор на ниво книга:

{
  "externalId": "contributor-18",
  "name": {
    "given": "Anna",
    "family": "Editor"
  },
  "roles": ["editor"],
  "scope": {
    "type": "submission",
    "externalId": "431"
  }
}

Пример за автор на глава:

{
  "externalId": "contributor-29",
  "name": {
    "given": "Bela",
    "family": "Author"
  },
  "roles": ["author"],
  "scope": {
    "type": "component",
    "externalId": "chapter-7"
  }
}

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

12. Идентификатори на участниците

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

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

13. Файлове за подаване и производство

OMP файловете съответстват на ресурсите от OMI file.

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

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

Пример:

{
  "externalId": "file-221",
  "name": "chapter-07.docx",
  "mediaType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
  "stage": "submission",
  "componentExternalId": "chapter-7",
  "revision": 2
}

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

14. Импортиране в Studio

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

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

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

При импортирането НЕ СЕ РАЗРЕШАВА промяна на изходните файлове OMP.

15. Стратегии за работното пространство на „OMI“

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

15.1 Стратегия за едно работно пространство

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

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

15.2 Стратегия за координирано работно пространство

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

Edited volume workspace
├── Chapter 1 workspace
├── Chapter 2 workspace
├── Chapter 3 workspace
└── Shared book metadata / structure

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

16. Контрол на достъпа до сборници

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

Редакторът МОЖЕ да получи по-широк достъп до целия том.

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

17. Изпращане на ревизиите на адрес OMP

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

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

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

Пример:

{
  "target": {
    "type": "component",
    "externalId": "chapter-7"
  },
  "baseExternalRevision": "2",
  "source": "omi",
  "omiRevision": "01J...",
  "message": "Revised chapter from Open Manuscript Studio"
}

Историческите файлове НЕ ТРЯБВА да се презаписват без предупреждение.

18. Подписана процедура за пускане

Добавката „OMP“ ТРЯБВА да предоставя действие „Отвори в Studio“ за оторизираните участници в работния процес.

Утверждението при стартиране ТРЯБВА да посочва:

• инсталиране;
• контекст на натискане;
• подаване;
• целеви компонент (по избор);
• външен участник;
• исканите обхвати;
• време на издаване;
• изтичане на срока;
• nonce.

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

19. Идентичност на потребителя и свързване

Идентификаторът на потребител в „OMP“ представлява външно удостоверение на самоличността. Studio МОЖЕ да го свърже с локален акаунт след успешно стартиране с вход и оторизация.

Препоръчителният външен идентификационен ключ е:

installationId + externalUserId

Имейлът НЕ ТРЯБВА да бъде единственият неизменен ключ за идентификация, валиден във всички системи.

20. Орган за рецензиране от колеги

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

Студио MAY осигурява структурирана среда за научна рецензия.

21. Цели за преглед

За разлика от обикновения работен процес при публикуване на статия, рецензията в списанието „OMP“ МОЖЕ да се фокусира върху:

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

Примерна задача за преглед на глава:

{
  "externalId": "review-612",
  "roundExternalId": "round-1",
  "target": {
    "type": "component",
    "externalId": "chapter-7"
  },
  "reviewMode": "double-anonymous",
  "permissions": ["manuscript.read", "review.write"]
}

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

22. Преглед на анонимността

Коннекторът „OMP“ ТРЯБВА да прилага политиката за ефективен преглед, преди да предаде данните.

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

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

23. Структуриран преглед

Подкрепа от Studio MAY:

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

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

24. Междукомпонентен преглед

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

Пример:

{
  "assignmentExternalId": "review-700",
  "target": {
    "type": "submission",
    "externalId": "431"
  },
  "annotations": [
    {
      "anchor": "omi:anchor:chapter-2:01J...",
      "body": "This chapter should define the term earlier."
    },
    {
      "anchor": "omi:anchor:chapter-8:01J...",
      "body": "This section conflicts with the terminology used in Chapter 2."
    }
  ]
}

Моделът на анкер „OMI“ ТРЯБВА да позволява тези коментари да остават на същото място при промени в оформлението и разбиването на страници.

25. Отговор на автора и преработка

Когато „OMP“ разрешава преразглеждане, Studio може да предостави одобрените коментари от прегледа на редакторите на книги, авторите на книги или авторите на отделни части, в зависимост от обхвата.

Авторът на даден компонент МОЖЕ да отговаря и да редактира само онези компоненти, за които има право да извършва промени.

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

26. Няколко кръга на преглед

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

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

27. Работно пространство за редактиране

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

Редакционните решения запазват своята авторитетност в списанието „OMP“.

28. Интеграция на производството

След одобрение „Studio MAY“ ще изготви структурирани материали за продукцията „OMP“.

Възможните производни включват:

• стандартният пакет „OMI“;
• структуриран XML;
• JATS-съвместимо с XML, където е уместно;
• HTML;
• EPUBсъдържание, насочено към;
• DOCX-производни производствени файлове;
• цифри и свързаните с тях активи;
• други формати, поддържани от конвертора.

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

29. Публикуване и интегриране в каталога

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

Коннекторът МОЖЕ да предоставя метаданни за публикациите, като например:

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

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

30. Сериал

Сериите са организационна единица в публикациите/каталозите на „OMP“ и ТРЯБВА да останат OMP-авторитетни.

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

31. Формати на публикациите

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

Издание в формат „PDF“, „EPUB“, „HTML“ или друг формат на публикация НЕ ТРЯБВА автоматично да се превръща в каноничния ръкопис на OMI само защото се разпространява публично.

32. Изисквания към възможностите

Коннекторът „OMP“, който отговаря на базовия профил „omi-integration/1/omp“, ТРЯБВА да поддържа:

launch
metadata.read
contributors.read
files.read

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

Коннекторът „OMP“, предназначен за синхронизиране на ръкописи, ТРЯБВА допълнително да поддържа:

manuscript.read
manuscript.write
revision.read
revision.write

Всеки конектор от типа „OMP“, за който се твърди, че интегрира рецензиране от колеги, ТРЯБВА да поддържа:

review.read
review.write

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

publication.read
publication.export

33. Препоръчителна повърхност на крайната точка

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

GET  /capabilities
POST /launch
GET  /contexts/{contextId}
GET  /contexts/{contextId}/submissions/{submissionId}
GET  /contexts/{contextId}/submissions/{submissionId}/components
GET  /contexts/{contextId}/submissions/{submissionId}/components/{componentId}
GET  /contexts/{contextId}/submissions/{submissionId}/contributors
GET  /contexts/{contextId}/submissions/{submissionId}/files
GET  /contexts/{contextId}/submissions/{submissionId}/files/{fileId}/content
GET  /contexts/{contextId}/submissions/{submissionId}/revisions
POST /contexts/{contextId}/submissions/{submissionId}/revisions
GET  /contexts/{contextId}/submissions/{submissionId}/reviews/{assignmentId}
POST /contexts/{contextId}/submissions/{submissionId}/reviews/{assignmentId}/result
GET  /contexts/{contextId}/submissions/{submissionId}/publication

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

34. Разрешение

Всяка операция ТРЯБВА да бъде одобрена на нивото на приложението „OMP“.

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

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

35. Състояние на синхронизацията

Студиото ТРЯБВА да запази метаданните за интеграцията, включително:

installationId
contextExternalId
submissionExternalId
componentExternalId(s)
externalPublicationId (when applicable)
lastExternalRevision
lastSynchronizedAt
source checksum(s)

Това състояние ТРЯБВА да остане отделено от каноничния документ OMI.

36. Управление на конфликти

Коннекторът ТРЯБВА да върне стойността „409 Conflict“, когато външната работа се е променила спрямо базовата ревизия, използвана от Studio, и автоматичното записване би довело до риск от загуба на данни.

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

37. Идемпотентност

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

38. Одит и произход

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

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

39. Изолиране на неизправности

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

OMP липсата на достъп НЕ ТРЯБВА да води до анулиране на вече импортиран научен обект от типа „OMI“.

Защитените операции по интеграция ТРЯБВА да завършват с неуспех.

40. Съвместимост при актуализации

Коннекторът ТРЯБВА да разделя адаптацията на приложението, специфична за OMP, от протокола OMI:

OMI Integration API
        |
OMP profile mapper
        |
OMP-version adapter
        |
Supported OMP services / repositories / hooks

Това позволява OMP-промени в реализацията, специфични за дадена версия, без да се предефинира omi-integration/1.

41. Внедряване на PKP с общо ползване

OJS а конекторите от типа „OMP“ МОГАТ да използват повторно общите библиотеки за интеграция на PKP за:

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

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

                 OMI Integration API v1
                          |
                  PKP shared library
                    /           \
          OJS profile adapter   OMP profile adapter
                 |                    |
                OJS                  OMP

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

42. Разширения

OMP-специфичните данни МОГАТ да бъдат предоставени чрез обект с разширение в пространство от имена:

{
  "extensions": {
    "org.pkp.omp": {
      "stageId": 3
    }
  }
}

Основните клиенти ТРЯБВА безопасно да игнорират неизвестните разширения. Разширенията НЕ ТРЯБВА да предефинират основните полета на Integration API.

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

Една реализация, която претендира за съответствие с „omi-integration/1/omp“, ТРЯБВА:

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

44. Инвариант на дизайна

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

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