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

OMI-SPEC-120 — Модел на научния обект

Статус: Чернова
Версия: 0.1.0
Стабилност: Експериментална
Категория: Основна спецификация

Зависи от:

  • OMI-SPEC-000 — Основни принципи

Използва се от:

  • OMI-SPEC-100 — Модел на документа
  • OMI-SPEC-110 — Модел „Анкор“
  • OMI-SPEC-130 — Модел за анотиране
  • OMI-SPEC-140 — Модел на метаданните
  • OMI-SPEC-200 — Модел за преглед
  • OMI-SPEC-230 — Модел за публикуване

Резюме​

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

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

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

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

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

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

1. Обхват

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

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

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

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

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

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

2. Нормативна терминология

Ключовите думи ТРЯБВА, НЕ ТРЯБВА, ЗАДЪЛЖИТЕЛНО, ТРЯБВА ДА, НЕ ТРЯБВА ДА, СЛЕДВА, НЕ СЛЕДВА, ПРЕПОРЪЧИТЕЛНО, МОЖЕ и НЕЗАДЪЛЖИТЕЛНО в настоящия документ трябва да се тълкуват като нормативни изисквания.

3. Основна концепция

Научният обект е идентифицируема семантична единица, която участва в научната комуникация.

Един научен обект може да представлява:

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

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

Scholarly Object
│
├── Identity
├── Type
├── Semantic content
├── Metadata
├── Relationships
├── Provenance
└── Lifecycle state

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

4. Ролята на архитектурата

Моделът на научния обект (Scholarly Object Model) представлява общата абстракция, лежаща в основата на семейството спецификации „OMI“.

OMI-SPEC-000
Core Principles
      │
      ▼
OMI-SPEC-120
Scholarly Object Model
      │
      ├── Document Model
      ├── Anchor Model
      ├── Annotation Model
      ├── Metadata Model
      ├── Review Model
      ├── Citation Model
      └── Publishing Model

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

5. Модел на обектната графика

Един ръкопис от типа „OMI“ се представя концептуално като граф.

Scholarly objects
        +
Explicit relationships
        =
Scholarly object graph

Графът съдържа възли и ребра.

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

Пример:

Manuscript
    │ contains
    ▼
Section
    │ contains
    ▼
Paragraph
    │ cited-by
    ▼
Citation
    │ refers-to
    ▼
Bibliographic Record

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

6. Минимален научен обект

Всеки научен обект ТРЯБВА да съдържа:

  • стабилен идентификатор;
  • тип обект.

Минимален пример:

{
  "id": "obj-01J9A6K8P3",
  "type": "paragraph"
}

id определя обекта.

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

7. Обща структура на обектите

Един научен обект МОЖЕ да притежава следните типични свойства:

{
  "id": "obj-01J9A6K8P3",
  "type": "paragraph",
  "schemaVersion": "0.1",
  "content": {},
  "metadata": {},
  "relationships": [],
  "provenance": {},
  "status": "active",
  "extensions": {}
}

Общото представяне на TypeScript може да се изрази по следния начин:

export interface ScholarlyObject<TContent = unknown> {
  id: string;
  type: string;
  schemaVersion?: string;
  content?: TContent;
  metadata?: Record<string, unknown>;
  relationships?: ScholarlyRelationship[];
  provenance?: ProvenanceRecord;
  status?: ScholarlyObjectStatus;
  extensions?: Record<string, unknown>;
}

Конкретните типове обекти МОГАТ да ограничават, да изискват или да разширяват тези свойства.

8. Идентичност на обектите

8.1 Стабилни идентификатори​

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

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

Примери за обикновено редактиране включват:

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

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

8.2 Непрозрачност на идентификаторите​

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

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

Препоръчва се:

{
  "id": "obj-01J9A6K8P3D7M5Q2R"
}

Разочарован:

{
  "id": "chapter-2-paragraph-4"
}

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

8.3 Обхват на идентификатора​

Идентификаторът ТРЯБВА да бъде уникален в рамките на обявения му обхват.

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

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

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

8.4 Запазване на идентичността​

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

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

Например:

Typographical correction
→ same object identity

Paragraph moved to another section
→ same object identity

Paragraph divided into two independent arguments
→ original object may be superseded by two new objects

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

9. Типове обекти

9.1 Свойство „Тип“​

Свойството „type“ определя семантичния клас на даден обект.

Примери:

{
  "type": "manuscript"
}
{
  "type": "figure"
}
{
  "type": "review-annotation"
}

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

За съставните типове се ПРЕПОРЪЧВА използването на имена с тире.

9.2 Основни категории обекти​

OMI разграничава няколко широки категории научни обекти.

Scholarly Object
│
├── Content Object
├── Structural Object
├── Relationship Object
├── Agent Object
├── Asset Object
├── Workflow Object
└── External Resource Object

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

10. Обекти със съдържание

Обектите със съдържание съдържат интелектуален материал или доказателствен материал.

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

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

Пример:

{
  "id": "paragraph-01",
  "type": "paragraph",
  "content": {
    "children": [
      {
        "type": "text",
        "value": "Scholarly content remains independent of presentation."
      }
    ]
  }
}

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

11. Структурни обекти

Структурните обекти организират научното съдържание.

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

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

Пример:

{
  "id": "section-methods",
  "type": "section",
  "content": {
    "title": "Methods",
    "children": [
      "paragraph-01",
      "paragraph-02",
      "table-01"
    ]
  }
}

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

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

12. Обекти „Активи“

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

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

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

Пример:

{
  "id": "asset-figure-01",
  "type": "image",
  "content": {
    "href": "assets/figure-01.png",
    "mediaType": "image/png"
  },
  "metadata": {
    "altText": "Diagram of the OMI semantic layers."
  }
}

Обектът „актив“ ТРЯБВА да включва:

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

13. Обекти на взаимоотношенията

Обектите на взаимоотношенията изразяват семантичните връзки между научните обекти.

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

  • цитат;
  • бележка;
  • препратка;
  • производство;
  • превод;
  • поправка;
  • рецензия;
  • зависимост;
  • връзка към източника;
  • връзка „част-цяло“.

Обектът „връзка“ ТРЯБВА да идентифицира:

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

Пример:

{
  "id": "rel-citation-01",
  "type": "citation",
  "source": [
    "paragraph-01"
  ],
  "target": [
    "reference-17"
  ]
}

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

14. Обекти-агенти

Обектите „агенти“ представляват участниците в научната комуникация.

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

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

Пример:

{
  "id": "agent-author-01",
  "type": "person",
  "metadata": {
    "name": "Example Author",
    "roles": [
      "author"
    ]
  }
}

Информацията, свързана с лични данни, МОЖЕ да се съхранява отделно от преносимото съдържание.

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

15. Обекти от работния поток

Обектите от работния поток представят структурирани научни процеси или решения.

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

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

Пример:

{
  "id": "decision-01",
  "type": "editorial-decision",
  "content": {
    "decision": "major-revision"
  },
  "status": "completed"
}

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

16. Обекти на външни ресурси

Обектите „Външни ресурси“ представляват научни единици, които не са съхранени директно в пакета „OMI“.

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

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

Пример:

{
  "id": "external-resource-01",
  "type": "external-resource",
  "metadata": {
    "identifier": {
      "scheme": "doi",
      "value": "10.0000/example"
    }
  }
}

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

17. Композитни и атомни обекти

Един научен обект може да бъде съставен или атомен.

17.1 Композитен обект​

Композитен обект съдържа или се позовава на други обекти.

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

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

17.2 Атомен обект​

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

Примери за това могат да бъдат:

  • текстов възел;
  • математически символ;
  • стойност на клетката в таблицата;
  • контролирана стойност на метаданните.

Атомарността зависи от модела.

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

18. Ограничаване

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

Пример:

{
  "id": "section-01",
  "type": "section",
  "content": {
    "children": [
      "paragraph-01",
      "figure-01"
    ]
  }
}

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

  1. Един под-обект ТРЯБВА да има идентифицируем родителски обект в рамките на каноничната йерархия на документа.
  2. НЕ СЕ ДОПУСКА образуването на кръгова зона на ограничаване.
  3. Заповедта за ограничаване ТРЯБВА да бъде изрично посочена, когато заповедта е семантично значима.
  4. Премахването на обект от един родителски обект НЕ ТРЯБВА автоматично да унищожава неговата идентичност.
  5. При преместването на обект между родителски обекти неговата идентичност ТРЯБВА да се запази.

19. Поръчки

Някои колекции от обекти са подредени.

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

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

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

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

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

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

20. Взаимоотношения

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

export interface ScholarlyRelationship {
  id?: string;
  type: string;
  source: string[];
  target: string[];
  metadata?: Record<string, unknown>;
  provenance?: ProvenanceRecord;
}

Пример:

{
  "id": "relationship-01",
  "type": "supports",
  "source": [
    "dataset-01"
  ],
  "target": [
    "claim-01"
  ]
}

Връзката МОЖЕ да свързва:

  • един обект към един обект;
  • от един обект към няколко обекта;
  • няколко обекта в един обект;
  • от множество обекти към множество обекти.

21. Позоваване чрез идентичност

Обектите ТРЯБВА да се позовават на други обекти чрез идентификатор.

Препоръчва се:

{
  "target": "paragraph-01"
}

Разочарован:

{
  "target": {
    "sectionNumber": 2,
    "paragraphNumber": 4
  }
}

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

Моделът „Anchor“ определя по-прецизни механизми за избор на цели.

22. Метаданни

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

Метаданните могат да бъдат:

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

Пример:

{
  "id": "figure-01",
  "type": "figure",
  "metadata": {
    "label": "Figure 1",
    "language": "en",
    "rights": "CC BY 4.0"
  }
}

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

23. Произход

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

Документът за произход МОЖЕ да включва:

export interface ProvenanceRecord {
  createdAt?: string;
  createdBy?: string;
  modifiedAt?: string;
  modifiedBy?: string;
  generatedBy?: string;
  derivedFrom?: string[];
  activity?: string;
}

Пример:

{
  "provenance": {
    "createdAt": "2026-07-21T18:30:00Z",
    "createdBy": "agent-author-01",
    "activity": "authoring"
  }
}

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

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

24. Животният цикъл на обекта

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

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

export type ScholarlyObjectStatus =
  | 'draft'
  | 'active'
  | 'superseded'
  | 'deprecated'
  | 'withdrawn'
  | 'deleted';

24.1 Проект​

Обектът е непълен или все още не е включен в каноничния ръкопис.

24.2 Активно​

В момента обектът е част от каноничната научна документация.

24.3 Отменено​

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

24.4 Не се препоръчва​

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

24.5 Оттеглено​

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

24.6 Изтрито​

Обектът е маркиран за изтриване.

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

25. Непроменимост и преразглеждане

OMI не изисква всеки обект да бъде технически неизменен.

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

Могат да се използват два подхода:

Mutable object
+
Version history

или:

Immutable object versions
+
Stable conceptual identity

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

26. Замяна и деривация на обекти

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

Пример:

{
  "id": "paragraph-02",
  "type": "paragraph",
  "provenance": {
    "derivedFrom": [
      "paragraph-01"
    ],
    "activity": "revision"
  }
}

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

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

27. Език

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

Пример:

{
  "id": "quotation-01",
  "type": "quotation",
  "metadata": {
    "language": "la"
  }
}

Стойностите за езика ТРЯБВА да използват признати идентификатори на езици, като например кодовете на езиците по ISO 639, както са дефинирани в модела на метаданните.

28. Обекти, специфични за дадена дисциплина

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

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

Хуманитарни науки​

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

Математика​

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

Химия​

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

Физика​

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

Биология​

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

Социални науки​

  • инструмент за проучване;
  • променлива;
  • пример;
  • сегмент с интервю.

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

Те ТРЯБВА да запазят задължителните свойства „id“ и „type“.

29. Модел за разширение

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

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

Пример:

{
  "id": "object-01",
  "type": "example.org:archival-witness",
  "extensions": {
    "example.org": {
      "shelfmark": "MS 42"
    }
  }
}

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

29.1 Изисквания за разширяване​

Разширение:

  1. НЕ СЕ РАЗРЕШАВА предефинирането на значението на основно свойство на OMI.
  2. АБСОЛЮТНО трябва да се запази стабилната идентичност на обекта.
  3. ТРЯБВА да остане пренебрежим за реализациите, които не го разбират.
  4. ТРЯБВА да предостави публична документация.
  5. ТРЯБВА да се определят правила за валидиране.
  6. НЕ СЕ ДОВОЛЯВА основният обект да стане неразбираем, когато разширението липсва.

30. Плавно влошаване на работата

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

Възможно е:

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

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

Пример:

Known object type
→ native editing and rendering

Unknown object type
→ preserve, identify, and render generically

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

31. Валидиране

Един научен обект се счита за валиден, когато:

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

Валидирането МОЖЕ да се извършва на няколко нива:

Syntax validation
        ↓
Schema validation
        ↓
Reference validation
        ↓
Semantic validation
        ↓
Workflow validation

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

32. Независимост от сериализацията

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

Може да се представи по следния начин:

  • JSON;
  • JSON-LD;
  • XML;
  • CBOR;
  • записи в базата данни;
  • графни структури;
  • бъдещи оперативно съвместими формати.

При сериализацията ТРЯБВА да се запазят:

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

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

33. Осигуряване на независимост

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

Например, обектът „нота“ може да бъде визуализиран по следния начин:

HTML
→ popup or side panel

PDF
→ footnote or endnote

DOCX
→ native Word footnote

JATS XML
→ <fn>

Audio
→ spoken aside

Целта остава същата.

Променя се само рендерерът.

34. Примерна графика от ръкописа

Manuscript
│
├── Metadata
│   ├── Title
│   ├── Authors
│   └── Keywords
│
├── Section
│   ├── Heading
│   ├── Paragraph
│   │   ├── Citation
│   │   └── Annotation
│   └── Figure
│       ├── Image Asset
│       └── Caption
│
├── Bibliography
│   └── Bibliographic Record
│
└── Supplementary Dataset

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

35. Примерна колекция от обекти

{
  "objects": [
    {
      "id": "manuscript-01",
      "type": "manuscript",
      "content": {
        "children": [
          "section-01"
        ]
      }
    },
    {
      "id": "section-01",
      "type": "section",
      "content": {
        "title": "Introduction",
        "children": [
          "paragraph-01"
        ]
      }
    },
    {
      "id": "paragraph-01",
      "type": "paragraph",
      "content": {
        "children": [
          {
            "type": "text",
            "value": "A manuscript is a graph of scholarly objects."
          }
        ]
      }
    }
  ]
}

Това представяне е илюстративно и не представлява пълна схема за сериализация.

36. Пример за семантична връзка

{
  "id": "annotation-01",
  "type": "annotation",
  "content": {
    "body": {
      "format": "text/plain",
      "value": "This claim requires further evidence."
    }
  },
  "relationships": [
    {
      "type": "targets",
      "source": [
        "annotation-01"
      ],
      "target": [
        "paragraph-01"
      ]
    }
  ]
}

Моделът за анотации позволява по-прецизно насочване чрез анкори.

37. Собственост върху обекти

OMI не определя правната собственост върху научните обекти.

Метаданните на даден обект МОГАТ да изразяват:

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

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

38. Поверителност

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

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

Пример:

{
  "id": "review-01",
  "type": "review",
  "metadata": {
    "access": "confidential"
  }
}

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

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

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

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

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

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

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

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

За дългосрочно съхранение:

  1. Идентификаторите на обектите ТРЯБВА да останат непроменени.
  2. Основните семантични свойства ТРЯБВА да са самоописателни.
  3. Неизвестните разширения ТРЯБВА да бъдат запазени.
  4. Външните зависимости ТРЯБВА да бъдат изрично посочени.
  5. Посочените активи ТРЯБВА да включват информация за целостта им, когато това е възможно.
  6. Трябва да се избягват изявленията, които се отнасят единствено до собствеността.
  7. Преобразуванията ТРЯБВА да запазват произхода.

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

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

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

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

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

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

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

Дадена реализация отговаря на настоящата спецификация, ако:

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

42.1 Реализация на създаването на съдържание​

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

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

42.2 Прилагане на обработката​

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

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

42.3 Реализация на рендеринга​

Един съответстващ рендърър ТРЯБВА:

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

43. Инварианти на проектирането

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

43.1 Инвариант на идентичността​

Една научна единица остава разпознаваема, независимо от местоположението или начина ѝ на представяне.

43.2 Семантичен инвариант​

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

43.3 Инвариант на отношението​

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

43.4 Инвариант на преносимостта​

Обектите могат да бъдат интерпретирани извън приложението, в което са създадени.

43.5 Инвариант на разширяемостта​

Неизвестните разширения не правят основния обект невалиден.

43.6 Инвариант на запазване​

Обектите запазват достатъчно контекст за бъдещо тълкуване.

43.7 Инвариант на поверителността​

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

44. Връзка с модела на документа

Моделът на научния обект определя какво представлява един обект.

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

Scholarly Object Model
→ common object semantics

Document Model
→ manuscript structure and composition

45. Връзка с модела „Anchor“

Моделът „Anchor“ определя цялостен научен обект или конкретна област в рамките на такъв.

Scholarly Object
        │
        ▼
Anchor
        │
        ▼
Resolvable target

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

46. Връзка с модела на анотациите

Самата анотация е научен обект.

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

Annotation Object
        │
        ▼
Target Relationship
        │
        ▼
Anchor
        │
        ▼
Scholarly Object

47. Връзка с модела за преглед

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

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

48. Връзка с модела на публикуване

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

Обектният модел остава каноничен.

Scholarly Object Graph
        │
        ▼
Publisher Profile
        │
        ▼
Renderer
        │
        ├── HTML
        ├── PDF
        ├── DOCX
        ├── EPUB
        └── JATS XML

49. Бъдещи задачи

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

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

50. Обобщение

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

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

Следователно ръкописът в формат „OMI“ не е просто форматиран текст.

Това е преносима научна графика на обекти, състояща се от:

Objects
+
Relationships
+
Metadata
+
Provenance

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

Пишете естествено. Създайте структурата веднъж. Публикувайте навсякъде.