Архитектура на интеграцията
Open Manuscript Initiative (OMI) е проектиран така, че да остава независим от която и да е отделна платформа или услуга за публикуване. Поради това Open Manuscript Studio работи като самостоятелно приложение със собствена система за съхранение на данни и се свързва с услугите за публикуване, идентификация, съхранение, превод и научни услуги чрез специални адаптери.
Ръкописът е преносим научен обект, а не вътрешен документ на конкретна издателска система.
За актуалния статус на отделните конектори на ниво продукт вижте Integration Implementation Status.
Актуална снимка на внедряването
Към 05.09.2026 г.:
- OJS функционира в настоящия работен процес на Studio, в зависимост от конфигурацията на внедряването, а пълният цикъл на анонимна проверка е проверен в родната среда на OJS 3.5;
- OMP функционира в зависимост от конфигурацията на внедряването, като осигурява изолация на присвоените проучвания и пълна проверка на анонимността на прегледа в цялостния цикъл в родната среда на „OMP“ 3.5;
- ORCID OAuth и свързаните хранилища са интеграции, които зависят от конфигурацията;
- каталогът на доставчиците на интеграция и моделът на режима на удостоверяване на доставчиците са реализирани основи;
- DeepL понастоящем разполага с рамка за доставчици и конфигурации, но не и с пълен работен процес за превод в производствена среда;
- Внасянето на данни в хранилището и създаването на допълнителни връзки към научната инфраструктура остават задачи за бъдещето.
Това са изявления относно прилагането, а не твърдения за съответствие с „OMI“.
Препоръчителна архитектура
External scholarly / publishing system
Own application, identity and persistence
|
| Integration adapter / plugin / provider client
| HTTPS + versioned API + explicit authentication
v
Open Manuscript Studio
OMI manuscript services + Studio persistence
Интеграционният слой ТРЯБВА да използва приложни услуги и API, а не директен достъп между бази данни. Studio НЕ ТРЯБВА да чете или записва във вътрешните таблици на базата данни на платформата за публикуване, а външната платформа НЕ ТРЯБВА да зависи от вътрешната схема за съхранение на Studio.
Това разделяне позволява независими актуализации, изолира границите на сигурността и възникващите неизправности, както и дава възможност на научния обектен модел на „OMI“ да се развива независимо.
Граници на системата за регистриране
Всяка свързана система запазва правото да определя достоверността на данните, които притежава.
| Отговорност | Типична авторитарна система |
|---|---|
| Процес на подаване и редактиране | Платформа за публикуване |
| Редакционен етап и решения | Издателска платформа |
| Покана и възлагане на рецензенти | Платформа за публикуване |
| Крайни срокове за рецензиране и състояние на външния работен процес | Платформа за публикуване |
| Управление на публикации/издания/каталози | Издателска платформа |
| Семантична структура на ръкописа | „OMI“ / Студио |
| Стабилни опори за ръкописи | OMI / Студио |
| Анотации, създадени директно в Studio | OMI / Studio |
| Съвместно редактиране на ръкописи | „OMI“ / Студио |
| История на структурните промени в ръкописа | „OMI“ / „Studio“ |
| Потвърждаване на самоличността | Доставчик на самоличност / свързан регистър, като произходът се запазва от Studio |
| Орган за управление на отдалечени файлове | Доставчик на свързано хранилище |
Межсистемните идентификатори свързват тези записи, без да обединяват техните модели на съхранение.
Нива на интеграционна способност
OMI разглежда интеграцията със системата за публикуване като постепенно разширяваща се функционалност, а не като функция от типа „всичко или нищо“.
Ниво 1 — Интеграция при стартиране
Външната платформа предоставя действие „Отвори в Studio“. Краткотрайно удостоверение за автентичност идентифицира инсталацията, контекста, обекта, участника и разрешените обхвати.
Настоящата реализация на OJS прилага този модел със подписан контекст на стартиране.
Ниво 2 — Интегриране на метаданни
Адаптерът предоставя достъп до разрешените метаданни за подадените материали/ръкописи, като например локализирани заглавия, резюмета, ключови думи, автори и идентификатори. При синхронизацията ЗАДЪЛЖИТЕЛНО трябва да се определят авторитетът и произходът на полетата.
Ниво 3 — Интеграция на файлове
Studio извлича разрешените файлове с ръкописи чрез удостоверени крайни точки на приложението. То НЕ ТРЯБВА да осъществява пряк достъп до пътеките към файловете на частния сървър.
Настоящият сайт OJS използва тази архитектура за извличане на оригинални ръкописи.
Ниво 4 — Синхронизиране на ръкописа
По-разширеният конектор осъществява връзка между структурирания ръкопис на „OMI“ и производните му към външна платформа. Синхронизацията ТРЯБВА да бъде ориентирана към ревизиите и ТРЯБВА да избягва незабележимото заместване на историческите изходни файлове.
Ниво 5 — Интегриране на рецензирането от колеги
Издателската платформа запазва правото си да определя заданията, етапите, крайните срокове и редакционните решения. „Studio“ осигурява структурирана работна среда за научна рецензия.
Настоящата реализация на „OJS/Studio“ включва обработка на рецензиите чрез външни възложители, изгледи за рецензенти и редактори, съобразени с ролите им, както и основи за двойно-сляпа рецензия.
Ниво 6 — Интегриране на публикациите
След одобрение „Студио МАЙ“ може да създаде производни на публикацията или структурирани пакети за последващо производство. Външните системи за публикуване обикновено запазват правото да определят графика, да присвояват номера на изданията/каталожни номера и да осигуряват публичното разпространение.
Удостоверяване и доверие
Интеграционният слой не предполага наличието на универсален метод за удостоверяване. Доставчиците могат да изискват:
- подписани твърдения за краткотрайни стартирания;
- OAuth/авторизация по стандарта OIDC;
- API ключове или токени за достъп;
- удостоверения за достъп до услуги, управлявани чрез разгръщане;
- удостоверения за достъп до приложения, специфични за даден доставчик.
Регистърът на доставчиците на Studio може да предостави тези режими на удостоверяване на потребителския интерфейс, без да ги третира като взаимозаменяеми.
Интеграциите в производствената среда ТРЯБВА да използват HTTPS и принципа на „минимални права за достъп“. Удостоверенията НЕ ТРЯБВА да се включват в изходния код, да се съдържат в пакети с код или да се разкриват пред браузъра, когато принадлежат на услуги за интеграция от страна на сървъра.
Входът с имейл и парола НЕ ТРЯБВА да се измисля за даден доставчик само защото този доставчик има страница за вход в потребителския си уебсайт. Документираният модел за удостоверяване на доставчика, описан в API, е определящ.
OJS интеграция
OJS в момента представлява еталонната интеграция на издателска платформа.
OJS
|
| OMI integration plugin
| - signed launch
| - metadata and contributors
| - manuscript files
| - review assignment context
| - revision/review exchange paths
v
OMI Integration API / Studio service
|
v
Open Manuscript Studio
OJS остава основният източник на информация за работния процес по подаване на статии в списанието, възлагането на рецензенти, етапите на рецензиране, редакционните решения, броевете и статуса на публикуване. Studio остава основният източник на информация за модела на ръкописа „OMI“ и за състоянието на ръкописа/рецензирането, специфично за Studio.
Реализацията вече надхвърля рамките на концептуалния свързващ елемент: налице са подписано стартиране, извличане/импортиране на изходни файлове, обработка на възложени външни рецензии, задължителни родни формуляри за рецензиране, корекции на ръкописа, отделена обратна връзка от рецензентите и подписано потвърждение на промените. Вградените тестове „от начало до край“ на OJS 3.5 проверяват анонимните прогнози на рецензентите и достъпа в рамките на възложените задачи. Пълната версия на OJS Integration Profile v1 остава по-широка от текущо проверената производствена верига, така че не всяка операция с профили трябва да се описва като съответстваща или пълна.
OMP интеграция
OMP продължава да бъде първокласна цел за монографии, сборници, глави и работни процеси в печатната индустрия.
Платформата за оценяване на учебни материали (OMP Integration Profile v1) дефинира архитектурното съответствие, включително авторството и рецензирането на ниво компоненти. Плъгинът „OMP“, готов за внедряване, вече реализира стартиране с подпис и отчитане на ролите, съответствие на монографии и изследвания, достъп до файлове в рамките на заданията, вградени формуляри за рецензиране, корекции, отделна обратна връзка и записване с подпис.
Вградените в „OMP“ 3.5 тестове „от начало до край“ проверяват дали рецензентът получава само възложеното му проучване, представено като анонимна статия. Метаданните на родителската монография, сродните проучвания, неразпределените файлове и самоличността на авторите остават извън тази рецензентска проекция. Формалното съответствие с OMI и по-широката съвместимост с версиите на OMPостават отделни задачи за бъдеще.
Каталог на доставчиците на интеграционни услуги
Studio вече включва регистър на доставчиците на интеграции и потребителски интерфейс за интеграции. Този слой има за цел да позволи откриването и конфигурирането на външни услуги, без да се налага твърдо кодиране на всеки доставчик в несвързани функции на ръкописа.
Определението за доставчик може да описва:
- идентичност и категория на доставчика;
- поддържан режим на удостоверяване;
- състояние на конфигурацията/статуса;
- възможности на клиента/услугата;
- изисквания за внедряване.
Това е основа за разширяемост, а не доказателство, че всеки от изброените доставчици разполага с пълен производствен конектор.
Услуги, свързани с идентичността
ORCID
ORCID OAuth Поддръжката зависи от конфигурацията. Studio може да предостави инфраструктура за свързване на идентичности, но работата в производствена среда изисква валидна регистрация на приложението в ORCID, клиентски идентификационни данни и конфигурация на обратните повиквания.
ROR и метаданни за научната идентичност
ROR/Данните за принадлежност и свързаните с тях идентификатори могат да обогатят информацията за участниците в проекта „OMI“. Външните идентификатори ТРЯБВА да запазват произхода си и НЕ ТРЯБВА да заменят модела на участниците/агентите от „OMI“ със записи, специфични за даден доставчик.
Услуги по превод
В момента DeepL функционира на ниво „доставчик/конфигурация“. Архитектурата поддържа доставчик на преводи, без да му предоставя право на собственост върху структурата на текста или произхода на превода.
Коннекторът за производствен превод трябва допълнително да дефинира сигурна автентификация, съответствие между изходния и целевия език, управление на квоти и грешки, проследяемост на резултатите, както и начина, по който машиният превод се включва в работните процеси за превод на ръкописи, отчитащи версиите.
Свързано хранилище
Десктопната версия на Studio следва модел, при който се дава предимство на локалните данни, и може да запазва ръкописите в обикновени локални или синхронизирани папки. Свързаното отдалечено хранилище представлява отделен въпрос, свързан с интеграцията.
Основите на хранилището от типа WebDAV/Nextcloud могат да бъдат конфигурирани, където това се поддържа. Бъдещите специфични за доставчиците коннектори трябва да спазват същото правило: отдалеченото хранилище е собственик на файловете/обектите в съответната услуга; ръкописът „OMI“ остава преносим и може да бъде експортиран независимо.
Интеграция на хранилището и съхранението
Адаптерът на хранилището може да получи окончателен вариант на ръкописа или пакет за съхранение. Хранилището остава авторитетният източник по отношение на идентичността на депозирания материал, политиката за достъп и състоянието на съхранението.
Тази област остава планирана в еталонната реализация и следва да използва специален интеграционен профил, а не пряко свързване с базата данни.
Интеграция с версии API
Крайните точки за интеграция ТРЯБВА да бъдат обозначени с версии още от самото начало, например:
/api/integrations/v1/...
Промените, които не са съвместими с предишните версии, изискват нова версия на протокола. Коннекторите ТРЯБВА да договарят възможностите, вместо да приемат, че всяка реализация на OMI поддържа всяка операция.
Независимите от платформата профили на „Integration API v1“ и хост профилите определят целта на протокола. Статусът на внедряването на продуктите се проследява отделно на страницата Integration Implementation Status.
Модели на внедряване
Един и същ хост, отделни приложения
https://example.org/ojs/
https://example.org/omi/
Приложенията могат да използват обща инфраструктура, като същевременно запазват отделни граници на съхранение и услуги.
Отделни поддомейни
https://journal.example.org/
https://studio.example.org/
Отделните виртуални хостове осигуряват ясно маршрутизиране и граници на сигурността и са подходящи за много производствени инсталации.
Отделна инфраструктура
Системата за публикуване и Studio могат да се изпълняват на различни сървъри или да се управляват от различни организации. Същият протокол с версии се прилага и при HTTPS.
Преносимост и плавно прекъсване на връзката
Интеграцията НЕ ТРЯБВА да прави ръкописа неизползваем, когато външният доставчик не е достъпен. Състоянието на външната интеграция ТРЯБВА да се представя под формата на идентификатори, връзки, възможности и произход, а не като недокументирани зависимости от структури на отдалечени бази данни.
Това е основно архитектурно свойство на „OMI“: външни системи могат да координират работните потоци, свързани с ръкописа, докато самият ръкопис остава преносим научен обект.
Дисциплина по отношение на статуса
Документацията ТРЯБВА да прави разграничение между:
- статус на нормативния протокол/спецификацията;
- Статус на внедряването наOpen Manuscript Studio;
- готовност за внедряване/конфигуриране;
- доказателство за формално съответствие.
Доставчикът, включен в каталога за интеграция, не е автоматично готов за производствена експлоатация. Проектният профил за интеграция не се внедрява автоматично. От друга страна, продуктът може да функционира в експлоатационни условия, преди да е налична пълна рамка за съответствие с изискванията на „OMI“.
Използвайте Integration Implementation Status за актуалната базова референтна реализация и OMI Implementation Status Matrix за информация на ниво спецификация.