Erste öffentliche Version in Vorbereitung
GalleyForge – Projekt
GalleyForge macht aus akzeptierten Manuskripten strukturierte Daten und saubere HTML-Artikel für kleine wissenschaftliche Zeitschriften. Diese Seite beschreibt das Problem, den Entwicklungsstand, meine Rolle ein Beispiel und ein Projekt aus der Praxis. Nichts davon ist ein Serviceangebot.
Problem
In kleinen Journalen ist die Produktion zwischen akzeptierter Word-Datei und veröffentlichtem Artikel noch Handarbeit: Abschnitte strukturieren, Abbildungen und Tabellen platzieren, Referenzen formatieren, Metadaten erfassen und das Ergebnis prüfen. Der Aufwand fällt für jeden Artikel erneut an, unterscheidet sich je nach Bearbeiter und ist selten dokumentiert. Große Verlage lösen das mit proprietären Systemen, die sich kleine Journale nicht leisten können.
Entwicklungsstand
Jeder Punkt wurde am Repository-Code und an den automatisierten Tests geprüft. „Prototyp“ heißt: läuft, ist aber nicht produktionsreif.
Bereits im Prototyp
| Fähigkeit | Was existiert | Grenzen |
|---|---|---|
| DOCX zu strukturierten Daten zu HTML | Ein Python-Prototyp liest ein DOCX-Manuskript, erkennt Titel, Autoren, Affiliations, Korrespondenzautor, Schlagwörter, Abschnitte, Tabellen und Abbildungslegenden, schreibt ein versioniertes JSON-Schema und rendert einen einfachen HTML-Artikel. Quellcode: GalleyForge Core auf GitHub (MIT-Lizenz, nur fiktive Beispieldaten). | Heuristiken, die auf Layout-Konventionen beruhen. Manuskripte mit anderem Layout (zum Beispiel kommagetrennte Autoren ohne Kennzeichen oder einleitende Zeilen) werden nicht zuverlässig gelesen. Tabellen und Abbildungen stehen in eigenen Blöcken, nicht an ihrer Textstelle; Referenzen bleiben Klartext. Kleines Testset, nur fiktive Daten. Keine PDF- oder XML-Ausgabe. |
| Regelbasierte Validierung der strukturierten Daten | Geschäftsregeln melden Fehler, Warnungen und Hinweise (zum Beispiel fehlende Schlagwörter oder Autorendaten). | Ein erster Regelsatz. |
| Plattform-Backend (Grundlage) | Anmeldung und Sitzungen, Organisationen und journalbezogene Rollen, Journal-Einstellungen, Artikeldatensätze, Datei-Upload und -Speicherung, strukturierter Artikelinhalt mit konfliktsicherem Speichern und ein Endpunkt zur Validierung des Artikelinhalts (bisher zwei Regeln). Abgedeckt durch 503 automatisierte Tests. | Nur Backend: noch keine Browseroberfläche, kein Import und Export in der Plattform, kein Deployment. |
| Journalspezifische interne Werkzeuge | Skripte und ein kleines Desktop-Werkzeug zur Erzeugung von HTML-Artikeln sowie ein separater Generator für PubMed-XML-Metadaten, entstanden für die eigene Journalproduktion. | Auf ein Journal zugeschnitten, nicht verallgemeinert, ohne automatisierte Tests. Sie informieren das Produktdesign, sind aber nicht Teil des Produkts. |
Für die erste Version geplant
- Browserbasierter Prüf-Editor mit Autosave (der Speichervertrag ist backendseitig entworfen und getestet)
- DOCX-Import, an die Plattform angebunden
- HTML-Export eines fertigen Artikels inklusive Abbildungen und Tabellen
- Journalbezogene Konfiguration der Pflichtinhalte, durchgesetzt per Validierung
Spätere Roadmap
- PDF-Erzeugung
- Crossref-XML- und PubMed-XML-Export aus der Plattform
- Vollständiges Publikationspaket (ZIP)
- Journal-Templates, Validierungs- und Exportprofile für mehrere Journale
- KI-gestützte Strukturanalyse – stets optional und unter redaktioneller Kontrolle
Ein Veröffentlichungstermin ist nicht festgelegt.
Meine Rolle
Ich habe GalleyForge initiiert und verantworte die Produktanforderungen und die redaktionellen Workflows. Ich bringe die Anforderungen aus der Verlagspraxis ein, definiere die redaktionellen Abläufe, priorisiere Funktionen und prüfe die Entwicklung. Mehr zu meinem Hintergrund steht auf der Seite Über mich.
Beispiel-Workflow
Das Beispiel nutzt ein fiktives Manuskript, das für diese Seite erstellt wurde. Es sind keine echten Artikel-, Autoren- oder Journaldaten beteiligt.
- Eingabe: eine DOCX-Datei mit Hinweiszeile, Titel, drei Autoren mit hochgestellten Affiliation-Kennzeichen, zwei Affiliations, Korrespondenzzeile, Schlagwörtern, den üblichen Abschnitten, einem Declarations-Block, einer Tabelle mit Beschriftung und einer Abbildungslegende.
- Strukturierung: Der Prototyp schreibt ein JSON-Dokument: Titel, Autoren mit Affiliation-Indizes, Affiliations, Korrespondenzautor, Schlagwörter, Abschnitte, Tabellenzeilen und Abbildungslegende.
- Ausgabe: ein einfacher HTML-Artikel samt Tabelle und Abbildungslegende, ohne manuelle Nachbearbeitung erzeugt.
Beispielausgabe öffnen (unbearbeitete Generator-Ausgabe, Englisch)
Grenzen, die bleiben
- Alle Elemente dieses fiktiven Testmanuskripts wurden korrekt extrahiert (Titel, Autoren mit Affiliation-Zuordnung, Korrespondenz, Schlagwörter, Abschnitte, Tabelle, Abbildungslegende). Das Testmanuskript wurde für diesen Zweck geschrieben; echte Manuskripte variieren deutlich stärker.
- Sichtbare Grenzen im Beispiel: Tabelle und Abbildungslegende stehen in eigenen Blöcken nach dem Haupttext, nicht an der Stelle, an der der Text sie erwähnt; der Hinweis „No external references“ erscheint als Referenzeintrag; es ist kein Bild angehängt; die Seite ist schlicht, ohne Journal-Layout, Metadaten oder PDF.
- Frühere Versionen des Prototyps lasen dieses Layout falsch (Korrespondenzzeile als Autor, keine Schlagwörter, keine Tabellen oder Legenden). Der Parser wurde erweitert und um Regressionstests ergänzt. Layouts mit kommagetrennten Autoren, einleitenden Zeilen oder ungewöhnlichen Überschriften werden weiterhin nicht verarbeitet.
Manuskripte, die diese Konventionen verletzen, sind genau der Fall für den geplanten Prüfschritt: Die Redaktion korrigiert die strukturierten Daten vor dem Export, die Validierung weist auf Lücken hin.
Laufende Entwicklung
Projekt aus der Praxis: webbasiertes Multi-Journal-Submission- und Peer-Review-System
Ein separates Projekt aus meiner Tätigkeit als Geschäftsführer eines Verlags; es ist nicht Teil von GalleyForge.
Ausgangslage
Einreichung und Begutachtung für mehrere Journale sollen in einem webbasierten System mit journalspezifischen Einstellungen abgewickelt werden und bisherige manuelle Abläufe ablösen.
Meine Rolle
Ich habe das Projekt initiiert; Anforderungen und redaktionelle Abläufe stammen aus meiner Verlagspraxis.
Konzeptionelle Schwerpunkte
- Manuskriptversionen: Revisionen eines Manuskripts sollen über Begutachtung und Überarbeitung durch die Autoren nachvollziehbar bleiben.
- Reviewer-Verwaltung: Verwaltung von Gutachterdaten einschließlich Kontakthistorie.
- Reviewer-Suche: Unterstützung der Redaktion bei der Suche geeigneter Gutachter, mit Hinweisen auf mögliche Interessenkonflikte; die Entscheidung soll bei der Redaktion bleiben.
- Einladungen und Kommunikation: Einladungen und weitere Schritte sollen als definierte, nachvollziehbare Abläufe gestaltet werden.
Entwicklung
Das System wird laufend weiterentwickelt.
Feedback und Pilotinteresse
Fragen, Rückmeldungen aus der redaktionellen Praxis oder Interesse an einem späteren Pilot: hello@galleyforge.com. Bitte senden Sie keine Manuskripte oder personenbezogene Daten.