Zum Hauptinhalt springen

OMI Architekturkarte

Status: Entwurf

Version: 0.2

Zuletzt aktualisiert: 05.09.2026 Stabilität: Experimentell


Zusammenfassung

Das „Open Manuscript Initiative“ bietet eine offene semantische Architektur für den gesamten Lebenszyklus wissenschaftlicher Manuskripte.

OMI trennt wissenschaftliche Inhalte von Software, Darstellung, Arbeitsabläufen und institutioneller Infrastruktur. Seine Spezifikationen definieren interoperable Modelle für Manuskripte, wissenschaftliche Objekte, Verweise, Anmerkungen, Metadaten, Peer-Review, Veröffentlichung und maschinengestützte wissenschaftliche Arbeit.

Dieses Dokument stellt die übergeordnete Architektur von „OMI“ vor und beschreibt, wie die wichtigsten Spezifikationen und Implementierungsebenen zueinander in Beziehung stehen.


1. Architektonischer Überblick

Die Architektur von „OMI“ gliedert sich in fünf Hauptschichten:

┌─────────────────────────────────────────────────────────┐
│ Application Layer │
│ │
│ OMI Studio · Publisher Systems · OJS · Tools │
├─────────────────────────────────────────────────────────┤
│ Workflow Layer │
│ │
│ Review · Collaboration · Versioning · Publishing │
├─────────────────────────────────────────────────────────┤
│ Semantic Relationship Layer │
│ │
│ Anchors · Annotations · Citations · Provenance │
├─────────────────────────────────────────────────────────┤
│ Scholarly Object Layer │
│ │
│ Manuscript · Section · Paragraph · Figure · Table │
│ Equation · Reference · Dataset · Supplementary Object │
├─────────────────────────────────────────────────────────┤
│ Foundation Layer │
│ │
│ Core Principles · Identity · Portability │
│ Extensibility · Preservation · Interoperability │
└─────────────────────────────────────────────────────────┘

Jede Ebene hängt von den darunterliegenden Ebenen ab.

Die Implementierungen der Anwendungen können variieren, doch die semantischen Modelle bleiben stabil.


2. Zentrales architektonisches Prinzip

OMI betrachtet ein Manuskript nicht lediglich als formatiertes Dokument, sondern als strukturierten Graphen aus wissenschaftlichen Objekten und semantischen Beziehungen.

Scholarly Object

├── has identity
├── has type
├── may contain other objects
├── may be targeted by anchors
└── may participate in semantic relationships

Das Manuskript wird daher wie folgt dargestellt:

Objects + Relationships + Metadata + Provenance

Die Darstellung wird aus dieser kanonischen Darstellung generiert.


3. Die kanonische Handschrift

Die kanonische Fassung enthält den maßgeblichen wissenschaftlichen Inhalt und die maßgebliche Struktur.

Canonical Manuscript

├── Metadata
├── Contributors
├── Sections
│ ├── Headings
│ ├── Paragraphs
│ ├── Figures
│ ├── Tables
│ ├── Equations
│ └── Other scholarly objects
├── References
├── Notes
├── Annotations
├── Provenance
└── Workflow references

Die kanonische Handschrift ist unabhängig von:

  • Seitengröße;
  • Typografie;
  • Verlagsvorlagen;
  • Textverarbeitungssoftware;
  • Ausgabeformat;
  • Render-Engine;
  • Redaktionsmanagement-Plattform.

PDF, HTML, DOCX, EPUB, JATS, XML sowie weitere Veröffentlichungsformate sind abgeleitete Darstellungen.


4. Abhängigkeitsübersicht der Spezifikationen

Die wichtigsten Spezifikationen von „OMI“ bilden die folgende Abhängigkeitsstruktur:

OMI-SPEC-000
Core Principles


OMI-SPEC-120
Scholarly Object Model

├──────────────────────────────┐
▼ ▼
OMI-SPEC-100 OMI-SPEC-140
Document Model Metadata Model


OMI-SPEC-110
Anchor Model


OMI-SPEC-130
Annotation Model

├───────────────┬────────────────┬────────────────┐
▼ ▼ ▼ ▼
Review Model Citation Model AI Assistance Publishing Model

Die Kernprinzipien legen die architektonischen Rahmenbedingungen fest.

Das „Scholarly Object Model“ definiert, was im „OMI“-Ökosystem vorkommen kann.

Das Dokumentmodell ordnet wissenschaftliche Objekte in Manuskripte ein.

Das Anker-Modell identifiziert stabile Ziele.

Das Annotationsmodell definiert die semantischen Beziehungen, die diesen Zielen zugeordnet sind.

Auf diesen Grundlagen bauen die Spezifikationen für Arbeitsabläufe und Interoperabilität auf.


5. Fundamentlage

5.1 Grundprinzipien

„OMI– SPEC-000 – Core Principles“ definiert den architektonischen Aufbau von „OMI“.

Zu den wichtigsten Regeln gehören:

  • Der Inhalt ist kanonisch;
  • Semantik hat Vorrang vor der Formatierung;
  • Wissenschaftliche Objekte besitzen eine stabile Identität;
  • Beziehungen sind Daten erster Klasse;
  • Die Darstellung ist vom Renderer abhängig;
  • Identität und Inhalt sind zwei getrennte Aspekte;
  • Die Implementierungen bleiben herstellerunabhängig;
  • Die Erhaltung ist ein vorrangiges Ziel bei der Planung.

Jede Spezifikation von „OMI“ SOLLTE mit diesen Grundsätzen im Einklang stehen.


5.2 Wissenschaftliches Objektmodell

OMI-SPEC-120 — Scholarly Object Model definiert die gemeinsame Abstraktion, die allen aussagekräftigen Entitäten gemeinsam ist.

Beispiele hierfür sind:

  • Manuskripte;
  • Abschnitte;
  • Absätze;
  • Überschriften;
  • Zahlen;
  • Tabellen;
  • Gleichungen;
  • Quellenangaben;
  • bibliografische Einträge;
  • Anmerkungen;
  • Rezensionen;
  • Datensätze;
  • ergänzende Materialien;
  • Autoren und Mitwirkende.

Ein wissenschaftliches Objekt weist mindestens Folgendes auf:

{
"id": "object-123",
"type": "paragraph"
}

Weitere Eigenschaften hängen vom Objekttyp ab.


6. Kernmodellschicht

6.1 Dokumentmodell

OMI-SPEC-100 — Dokumentmodell definiert den strukturellen Aufbau eines Manuskripts.

Darin wird Folgendes beschrieben:

  • Eigenschaften auf Manuskriptebene;
  • Abschnitte und hierarchische Struktur;
  • Inhaltsblöcke;
  • Inline-Inhalt;
  • Verweise auf externe wissenschaftliche Objekte;
  • Beziehungen zwischen Dokumentkomponenten.

Das Dokumentmodell legt das visuelle Erscheinungsbild nicht fest.


6.2 Anker-Modell

OMI-SPEC-110 — Anchor-Modell definiert stabile Verweise auf wissenschaftliche Objekte oder ausgewählte Bereiche innerhalb dieser Objekte.

Ein Anker kann auf Folgendes verweisen:

  • ein gesamtes Manuskript;
  • ein Abschnitt;
  • ein Absatz;
  • ein Inline-Textbereich;
  • eine Zahl;
  • ein Bildbereich;
  • ein Tisch;
  • eine Tabellenzelle;
  • eine Gleichung;
  • ein Zitat;
  • ein bibliografischer Eintrag;
  • Metadaten;
  • eine externe Quelle.
Anchor


Stable target within a scholarly object

Anhänger sorgen dafür, dass Anmerkungen und Verknüpfungen auch bei der Bearbeitung, Umstrukturierung und Neuausgabe erhalten bleiben.


6.3 Annotationsmodell

OMI– SPEC-130 – Annotation Model definiert Annotationen als wissenschaftliche Objekte erster Ordnung.

Annotation

├── type
├── body
├── creator or actor reference
├── visibility
├── provenance
└── target


Anchor

Anmerkungen können Folgendes darstellen:

  • Anmerkungen;
  • Kommentare;
  • Anmerkungen aus dem Peer-Review;
  • Redaktionelle Hinweise;
  • Zitationsbeziehungen;
  • KI-Vorschläge;
  • Veröffentlichungshinweise;
  • semantische Klassifikationen.

Eine Anmerkung wird unabhängig von dem Text gespeichert, auf den sie sich bezieht.


6.4 Metadatenmodell

OMI-SPEC-140 — Metadatenmodell definiert beschreibende, administrative, technische und konservatorische Metadaten.

Metadaten können Folgendes beschreiben:

  • Titel;
  • Sprache;
  • Urheberschaft;
  • Zugehörigkeiten;
  • Bezeichner;
  • Fächer;
  • Stichwörter;
  • Finanzierung;
  • Rechte;
  • Veröffentlichungsstatus;
  • Herkunft;
  • fachspezifische Informationen.

Das Metadatenmodell ist so konzipiert, dass es mit etablierten Standards und Identifikationssystemen kompatibel ist.


7. Workflow-Ebene

7.1 Überprüfungsmodell

OMI-SPEC-200 — Review Model definiert strukturierte Peer-Review-Arbeitsabläufe.

Es baut auf dem Annotationsmodell auf.

Review Annotation

├── reviewer pseudonym
├── review round
├── recommendation
├── visibility policy
├── confidential or author-facing body
└── target anchor

Das Überprüfungsmodell unterstützt:

  • offene Überprüfung;
  • einzige anonyme Rezension;
  • doppelt anonymes Begutachtungsverfahren;
  • dreifach-anonyme Begutachtung;
  • vertrauliche Anmerkungen des Redakteurs;
  • Kommentare für den Autor;
  • mehrere Überprüfungsrunden;
  • strukturierte Empfehlungen;
  • Prüfpfade überprüfen.

Die Identität des Rezensenten wird vom übertragbaren Inhalt der Rezension getrennt.


7.2 Kooperationsmodell

OMI-SPEC-210 — Collaboration Model definiert die Interaktion mehrerer Benutzer mit einem Manuskript.

Es unterstützt möglicherweise:

  • Autoren;
  • Mitautoren;
  • Redakteure;
  • Übersetzer;
  • Rezensenten;
  • Lektoren;
  • Korrekturleser;
  • technische Mitwirkende;
  • KI-Assistenten.

Berechtigungen für die Zusammenarbeit sind rollenbasiert und objektbezogen.


7.3 Versionsmodell

OMI-SPEC-220 — Versionierungsmodell beschreibt die Entwicklung eines Manuskripts.

Version 1


Change Set


Version 2

Das Modell sollte Folgendes unterstützen:

  • unveränderliche Versionskennungen;
  • Änderungen auf Objektebene;
  • Änderungshistorie;
  • Verzweigung;
  • Zusammenführung;
  • Herkunft;
  • Vergleich zwischen verschiedenen Versionen;
  • Momentaufnahmen aus der Bewertungsrunde.

7.4 Veröffentlichungsmodell

„OMI– SPEC-230 — Publishing Model“ beschreibt die Umwandlung des kanonischen Manuskripts in Veröffentlichungsergebnisse.

Canonical OMI Manuscript


Publisher Profile


Rendering Pipeline

├── HTML
├── PDF
├── DOCX
├── EPUB
├── JATS XML
├── LaTeX
└── Future formats

Verlagsprofile können Folgendes definieren:

  • Typografie;
  • Zitierweise;
  • Notenposition;
  • Überschriftenhierarchie;
  • Seitengeometrie;
  • Abbildung: Bearbeitung;
  • Anforderungen an Metadaten;
  • ausgabespezifische Transformationen.

Die kanonische Handschrift bleibt unverändert.


8. Interoperabilitätsschicht

8.1 Plugin-Architektur

OMI– SPEC-300 — Plugin-Architektur definiert Mechanismen zur Erweiterbarkeit.

Plugins können Folgendes bieten:

  • neue wissenschaftliche Objekttypen;
  • fachspezifische Metadaten;
  • Renderer;
  • Exporteure und Importeure;
  • Validatoren;
  • redaktionelle Arbeitsabläufe;
  • Repository-Integrationen;
  • KI-Dienste.

Plugins DÜRFEN die Portabilität des kanonischen Manuskripts NICHT beeinträchtigen.


8.2 Plattform-API

OMI-SPEC-310 — Platform API definiert die programmatische Interaktion mit Manuskripten und wissenschaftlichen Objekten der „OMI“.

Die „API“ kann Folgendes offenlegen:

  • Abruf von Manuskripten;
  • Erstellung und Änderung von Objekten;
  • Annotationsvorgänge;
  • Anker-Auflösung;
  • Validierung;
  • Rendering;
  • Workflow-Integration;
  • Import und Export;
  • Plugin-Schnittstellen.

8.3 Dateiformat

OMI-SPEC-320 — File Format definiert die portable logische Darstellung „JSON“ eines Manuskripts im Format „OMI“.

Dasselbe logische Dokument kann als eigenständige „.omi.json“-Datei oder als aus einem „OMI“-Container rekonstruierter Manuskriptteil übertragen werden. Das Dateiformat definiert Identifikation, Versionsaushandlung, Parsing, Serialisierung, Validierung, Referenzen, Erweiterungen, optionalen Verlaufsaustausch und Migration, ohne Archivpfade oder Komprimierung vorzuschreiben.

Das Format sollte folgende Aspekte in den Vordergrund stellen:

  • Transparenz;
  • Validierung;
  • Wiederherstellbarkeit;
  • Langzeitkonservierung;
  • Implementierungsunabhängigkeit.

8.4 Container-Architektur

OMI-SPEC-330 — Container Architecture legt fest, wie zugehörige Dateien zu einem überprüfbaren „.omi“-Paket zusammengefasst werden.

Ein Container kann Folgendes enthalten:

manuscript.omi

├── META-INF/
├── manuscript/
├── media/
├── profiles/
├── plugins/
└── publication/

Der Container definiert die Erkennung von Teilen, die Pfadsicherheit, den Umgang mit Medien, die Integrität, Signaturen und die Aufbewahrungsverpackung, während die Semantik der Manuskripte der „OMI“ (SPEC-320) und den Kernmodellen überlassen bleibt.


9. Ebene der künstlichen Intelligenz

9.1 KI-Unterstützung

** „OMI– SPEC-400 – KI-Unterstützung“** beschreibt, wie maschinengenerierte Vorschläge mit wissenschaftlichen Manuskripten interagieren.

KI-Ergebnisse werden als mit Anmerkungen oder Herkunftsangaben versehene Inhalte dargestellt.

AI Service


AI Annotation

├── model or service identifier
├── creation time
├── operation type
├── confidence or rationale
├── target anchor
└── human review status

KI-Vorschläge ersetzen kanonische Inhalte nicht automatisch.


9.2 KI-Überprüfung

„OMI– SPEC-410 — AI Review“ definiert die maschinengestützte Qualitätsbewertung.

Zu den möglichen Vorgängen gehören:

  • strukturelle Validierung;
  • Überprüfung der Quellenangaben;
  • terminologische Einheitlichkeit;
  • Sprachanalyse;
  • Barrierefreiheitsprüfung;
  • Validierung von Metadaten;
  • statistische Hinweise;
  • Einhaltung der Vorgaben zum Publikationsprofil.

Die KI-Begutachtung unterscheidet sich nach wie vor von der Begutachtung durch menschliche Fachkollegen.


9.3 Herkunft

OMI-SPEC-420 — Provenienz dokumentiert, wie wissenschaftliche Objekte erstellt oder verändert wurden.

Die Herkunft kann Aufschluss geben über:

  • menschliche Mitwirkende;
  • Software-Tools;
  • Importvorgänge;
  • KI-Systeme;
  • Transformationsprozesse;
  • Publikationssysteme;
  • Validierungsdienste.

Die Herkunftsangabe fördert die Transparenz, ohne dass alle Identitätsdaten öffentlich offengelegt werden müssen.


10. Anwendungsschicht

10.1 OMI Studio

OMI Studio ist eine Referenz-Erstellungsumgebung, die auf den „OMI“-Spezifikationen basiert.

OMI Studio

├── Manuscript editor
├── Scholarly object inspector
├── Annotation panel
├── Notes editor
├── Review interface
├── Metadata editor
├── Publisher preview
├── Validation
├── Import
└── Export

OMI Studio ist eine Umsetzung der Spezifikationen, nicht die Spezifikation selbst.

Andere Anwendungen können „OMI“ möglicherweise anders implementieren.


10.2 Publisher-Systeme

Verlage und Zeitschriftenverwaltungsplattformen können „OMI“ für folgende Zwecke nutzen:

  • Entgegennahme von Einreichungen;
  • technische Validierung;
  • Peer-Review;
  • Lektorat;
  • Produktion;
  • Veröffentlichung;
  • Hinterlegung in einem Depot;
  • Langzeitkonservierung.

Ein Publisher kann „OMI“ direkt implementieren oder über ein „API“ oder ein Plugin integrieren.


10.3 Externe Systeme

OMI ist auf die Zusammenarbeit mit externer wissenschaftlicher Infrastruktur ausgelegt.

Beispiele hierfür sind:

OMI

├── OJS and journal management platforms
├── Institutional repositories
├── DOI registration services
├── ORCID
├── ROR
├── Crossref
├── DataCite
├── CSL
├── JATS
├── IIIF
├── Preservation systems
└── Research data repositories

OMI soll diese Infrastrukturen nicht ersetzen.

Es stellt eine portable semantische Manuskript-Ebene zwischen ihnen bereit.


11. Architektur für Identitätsmanagement und Datenschutz

Identitäten werden getrennt von kanonischen wissenschaftlichen Inhalten behandelt.

Portable OMI Content

├── actor role
├── pseudonym
├── contribution type
└── public provenance

│ protected mapping

Institutional Identity System
├── account
├── verified identity
├── permissions
└── confidential audit data

Diese Trennung unterstützt:

  • anonyme Begutachtung durch Fachkollegen;
  • Zusammenarbeit unter Wahrung der Privatsphäre;
  • kontrollierte Offenlegung der Identität;
  • institutionelle Rechenschaftspflicht;
  • mobile Prüfprotokolle.

Private Identitätszuordnungen SOLLTEN in portablen Paketen für anonyme Begutachtungen NICHT enthalten sein.


12. Architektur-Rendering

Beim Rendering wird semantischer Inhalt in eine Darstellung umgewandelt.

Canonical Manuscript


Semantic Validation


Target Profile


Renderer

├── HTML
├── PDF
├── DOCX
├── EPUB
├── JATS XML
├── LaTeX
└── Accessible formats

Der Renderer bestimmt:

  • Typografie;
  • Paginierung;
  • Notenposition;
  • Formatierung von Quellenangaben;
  • Abbildungsanordnung;
  • Tabellen-Rendering;
  • Aussehen der Überschrift;
  • Darstellung der Barrierefreiheit.

Die Übersetzung DARF die semantische Bedeutung des Manuskripts NICHT neu definieren.


13. Beispiel: Lebenszyklus einer Peer-Review-Anmerkung

Das folgende Beispiel veranschaulicht, wie mehrere „OMI“-Ebenen zusammenwirken.

1. A paragraph exists as a scholarly object.


2. An anchor identifies a sentence in the paragraph.


3. A reviewer creates a review annotation.


4. The Review Model applies anonymity and visibility rules.


5. The author receives an anonymized review projection.


6. The author revises the canonical manuscript.


7. The Versioning Model records the change.


8. The annotation is resolved or retained as provenance.

Der Anmerkung zur Überprüfung ist nicht dauerhaft in den Absatz eingebettet.

Es bleibt ein eigenständiges, nachvollziehbares wissenschaftliches Objekt.


14. Beispiel: Lebenszyklus einer Veröffentlichung

Authoring


Canonical OMI Manuscript


Validation


Peer Review


Revision and Versioning


Editorial Acceptance


Publisher Profile


Rendering

├── Journal HTML
├── Archival PDF
├── JATS XML
├── EPUB
└── Repository package

Aus ein und derselben kanonischen Handschrift können alle möglichen Ergebnisse hervorgehen.

Kein Ausgabeformat gilt als maßgebliche Quelle.


15. Architekturinvarianten

Alle konformen Implementierungen von „OMI“ SOLLTEN die folgenden Invarianten wahren.

15.1 Invariante kanonischer Inhalt

Darstellungsspezifische Änderungen DÜRFEN die kanonische wissenschaftliche Bedeutung NICHT verändern.

15.2 Invariante der stabilen Identität

Ein wissenschaftliches Objekt SOLLTE seine Identität bei üblichen Bearbeitungsvorgängen beibehalten.

15.3 Beziehungsinvariante

Semantische Beziehungen SOLLTEN explizit und maschinenlesbar bleiben.

15.4 Portabilitätsinvariante

Ein Manuskript MUSS auch außerhalb der Software, mit der es erstellt wurde, interpretierbar bleiben.

15.5 Datenschutzinvarianten

Vertrauliche Identitätsdaten MÜSSEN von den übertragbaren wissenschaftlichen Inhalten getrennt bleiben.

15.6 Herkunftsunabhängig

Sinnvolle automatisierte und manuelle Umwandlungen SOLLTEN nachvollziehbar sein.

15.7 Invariante der Erweiterbarkeit

Ergänzungen SOLLTEN die Gültigkeit und Lesbarkeit des zugrunde liegenden Manuskripts gewährleisten.


16. Architektonische Grenzen

OMI definiert:

  • semantische Manuskriptstrukturen;
  • Identitäten wissenschaftlicher Objekte;
  • Anker;
  • Anmerkungen;
  • Darstellungen von Arbeitsabläufen;
  • interoperable Metadaten;
  • tragbare Verpackungskonstruktionen;
  • Rendering-Eingaben;
  • Ausfahrmechanismen.

OMI schreibt nicht vor:

  • ein einziger Redakteur;
  • eine einzige Veröffentlichungsplattform;
  • eine einzige Datenbank;
  • eine einzige Programmiersprache;
  • eine einzige Peer-Review-Methode;
  • ein einheitlicher Zitierstil;
  • ein einheitliches visuelles Design;
  • ein einheitlicher institutioneller Arbeitsablauf.

Die Implementierungen können ihre internen Technologien weiterhin frei wählen.


17. Übersichtskarte

OMI-SPEC-000
Core Principles


Scholarly Object Model

┌────────────┴────────────┐
▼ ▼
Document Model Metadata Model


Anchor Model


Annotation Model

┌───────────┼───────────┬───────────────┐
▼ ▼ ▼ ▼
Review Model Citation AI Assistance Publishing
│ │ │ │
└───────────┴───────────┴───────────────┘


Portable OMI Manuscript


OMI Implementations

┌───────────────────┼───────────────────┐
▼ ▼ ▼
Studio Publisher Systems Repositories


Publication Renderers

┌─────────────────┼─────────────────┐
▼ ▼ ▼
HTML PDF JATS

18. Schlussfolgerung

Das „Open Manuscript Initiative“ bietet eine mehrschichtige semantische Architektur anstelle eines monolithischen Dateiformats.

Sein zentrales Abstraktionsmodell ist der wissenschaftliche Objektgraph:

Stable scholarly objects
+
Explicit semantic relationships
+
Portable metadata
+
Traceable provenance

Auf diesem Graph basieren Anwendungen, Arbeitsabläufe und Veröffentlichungsformate.

Durch die Trennung der wissenschaftlichen Bedeutung von der Darstellung und der Infrastruktur ermöglicht „OMI“, dass Manuskripte zwischen Autoren, Fachgebieten, Verlagen, Repositorien und zukünftigen Technologien ausgetauscht werden können, ohne dabei ihre intellektuelle Struktur zu verlieren.

Schreibe ganz natürlich. Einmal strukturieren. Überall veröffentlichen.