[Kobv-opus-tester] Fragen zur Migration von OPUS 3 nach 4

Holger Trapp holger.trapp at hrz.tu-chemnitz.de
Fr Apr 25 10:45:10 CEST 2025


Hallo Herr Schwidder,

Jens Schwidder schrieb am Mittwoch, 23. April 2025, um 19:12 Uhr:

> ich hoffe es gibt irgendwo noch frische Erfahrungen zum Umstieg von OPUS 3
> nach 4. Ich befürchte in den Hosting Teams ist die letzte Migration schon eine
> ganze Weile her. Ich selbst bin erst mit OPUS 4 in die Entwicklung
> eingestiegen und kann daher zu OPUS 3 nichts weiter sagen.

Vielen Dank für Ihre vielen Informationen. Wir hatten OPUS 4 bisher nicht
weiter verfolgt, da die Bibliografie auf Basis OPUS 3 mit unseren Anpassungen
eben lief und seit Jahren eine Ablösung durch DSpace angedacht war, wozu es
UB-externe Entwicklungen gab.

> Das Projekt "migration" enthält Code, der aus der OPUS 4 Application
> ausgelagert wurde, als es keinen akuten Bedarf mehr dafür gab. Der Code wurde
> nicht weiter gepflegt und seit OPUS 4.4.5 hat sich viel verändert.
> 
> Die Dokumentation ist da leider auch nicht mehr hilfreich.
> https://github.com/OPUS4/userdoc/blob/gh-pages/update/migration.md
> 
> Am Besten ist daher wahrscheinlich wirklich eine frische OPUS 4 Instanz und
> dann Skripte, die die Daten von der alten Datenbank in die neue übertragen.
> SWORD ist vielleicht auch eine Möglichkeit, aber vermutlich lassen sich
> darüber nicht alle Metadaten übertragen.

Als Ideenlieferant kann das Projekt "migration" sicher dienen. SWORD wäre ggf.
zu untersuchen.

> OPUS 4.8.* ist noch nicht PHP 8.2 kompatibel. Vieles funktioniert, aber leider
> nicht alles. OPUS 4.9, dass hoffentlich diesen Sommer endlich veröffentlicht
> werden kann, wird den PHP 7.1 Support fallen lassen und damit hoffentlich den
> Weg für PHP 8.2 ebnen.

Das klingt gut. Nils Trampel hatte bereits einen Weg gefunden, für OPUS 4 ein
PHP 8.1 zusätzlich zum PHP 8.2 verfügbar zu machen, aber schön ist es, wenn man
die Standard-Versionen des Systems nutzen kann.

> Anschließend soll es auch mit dem Umstieg von Zend zu Laminas und Doctrine
> weiter gehen. Wenn Zend entfernt ist, können wir hoffentlich auch zügig
> kompatibel zu PHP 8.3+ werden. OPUS 4 hat leider noch ein paar sehr alte
> Abhängigkeiten.

Das kennen wir auch von anderen Tools. Bei unserem alten OPUS 3 haben wir mit
jedem System-/PHP-Upgrade die notwendigen Anpassungen vorgenommen, um die
Software weiter betreiben zu können. So waren beim Umstieg von PHP 5 auf 7
viele Anpassungen im Bereich MySQL-/MariaDB-Zugriff nötig.

> Aktuell gibt es keine Möglichkeit Personen in OPUS 4 mit weiteren
> Informationen anzureichern. Ich gehe unten noch einmal weiter darauf ein.

Das bestätigt unseren Eindruck.

> Lokale Felder für Dokumente können als Enrichments abgebildet werden. Eigene
> Felder für andere Objekte werden bisher nicht unterstützt.

Bei OPUS 3 haben wir an einigen Stellen Felder ergänzt. Das erforderte dann
aber immer Code-Anpassungen. Darauf würden wir künftig gern verzichten.

> Die SWORD Schnittstelle funktioniert auf jeden Fall. Es kann nur sein, dass
> das Import-Format nicht alle gewünschten Metadaten unterstützt. So etwas dann
> bitte als Issue auf GitHub melden.

Da hilft sicher nur ein Test. Bisher haben wir mit SWORD noch keine Erfahrung.

> Ich fände es gut, wenn unsere SWORD-Schnittstelle auch Standard-Formate
> unterstützen würde, aber das ist alles eine Frage der Kapazitäten für die
> Entwicklung.

Sehen wir ein.

> > Existieren konkrete Erfahrungen mit zusätzlichen Personenmerkmalen wie
> > Kostenstellen oder Institutsnamen? Wie lassen sich diese mit den
> > vorhandenen OPUS-Mitteln sinnvoll abbilden?
> 
> Das hilft Ihnen erst einmal nicht, aber es wäre nützlich diese
> Anwendungsfälle als Issues auf GitHub festzuhalten.
> 
> Der Umstieg auf Laminas (im Prinzip Zend 4) und Doctrine soll OPUS 4 auf eine
> moderne technische Basis stellen, für die nächsten 15 Jahre Entwicklung.
>
> Dafür müssen sehr viele Altlasten bereinigt werden. Es ist eine sehr große
> Aufgabe. Was mit dem Umstieg auf Doctrine auch passieren soll, sind
> grundlegende Veränderungen im Datenmodell, unter anderem
> 
> - Trennung von "System" Enrichments und lokalen Metadaten-Feldern 
> - Beseitigung der Sonderbehandlung von Enrichments
> - Erweiterbarkeit aller Datenobjekte

Das klingt sehr interessant.

> Enrichments sollen in Zukunft einfach lokal definierte Felder sein, im
> Gegensatz zu den Standard-Feldern. Es sind aber alles Felder, die ansonsten
> gleich behandelt werden. Es soll das Konzept von "Harten" und "Soften"
> Feldern geben. Die "hart" verdrahteten Felder werden direkt auf Spalten in
> der Datenbank abgebildet. Die "soften" Felder, wie die jetzt Enrichments, in
> allgemeinen Tabellen gespeichert. Mit diesen Änderungen soll die
> Erweiterbarkeit aller Objekte kommen. Zusätzliche lokale Felder für Personen
> sollen damit also auch möglich werden.

Was dann viel Flexibilität ermöglichen würde.

> Das alles ist vom Umstieg auf Doctrine abhängig, weil es keinen Sinn macht
> die alte Codebasis jetzt noch weiter auszubauen. Über den Code für das
> Datenmodell und die Datenbankanbindung hinaus, müssen dafür natürlich auch
> die Formulare und viele andere Aspekte angepasst werden. Wie gesagt, ein
> großer Job.

Ich kann es mir grob vorstellen, da ich seit 2008 immer wieder am OPUS 3
"gefrickelt" habe. Nils ist erst seit einigen Monaten im Team und hatte damit
bisher noch nichts zu tun.

> Eine Zeitrahmen kann ich dafür nicht angeben, weil ich bei der Kern
> Entwicklung alleine unterwegs bin und es immer davon abhängt wie viel
> Ablenkung generiert wird. Ich kann nur eine Aufgabe nach der anderen angehen.

Völlig klar.

> Ziele für dieses Jahr sind auf jeden Fall Fortschritte mit Doctrine (Laminas
> macht mir wenig Sorgen danach), ein neues Publish-Modul und Verbesserungen
> bei der Personenverwaltung, insbesondere auch als Schritte für eine
> umfassendere ORCiD Integration. Dafür müssen auch weitere Informationen für
> Personen gespeichert werden.

Das sind alles Themen, die unser Team interessiert.

> Vielleicht habe Sie mit Ihrer Instanz da schon Erfahrungen gesammelt, die für
> die weitere Planung hilfreich sind. Wir sollten da im Dialog bleiben.

Am Dialog sind wir interessiert. In den letzten Jahren wurde durch UB-externe
Entwickler einer Informatik-Professur versucht, die alte Bibliografie durch
eine neue auf DSpace-Basis zu ersetzen.

Nachdem wir uns den Stand angesehen hatten, kamen Zweifel auf, ob wir dieses
Tool sinnvoll in der UB betreiben können (auch wenn uns das URZ im Hintergrund
zur Verfügung steht). So entstand die Idee, OPUS 4 zu evaluieren, da hier der
Betrieb u.E. deutlich einfacher zu organisieren ist.

> > Gibt es für OPUS 4 eine Dokumentation der SQL-Tabellen analog zum Dokument
> > opus-techdoku-3_0.pdf?
> 
> Ich glaube nicht. Ich würde einfach einfach eine Instanz aufsetzen und mir
> das Schema anschauen. Wenn es Fragen dazu gibt, können sicherlich auch die
> Hosting Teams, andere Betreiber und ich helfen.

OK.

> Aktuell muss erst einmal OPUS 4.9 fertig werden. Danach sind vielleicht
> Teilschritte möglich, um das Datenmodell zu erweitern, auch wenn noch nicht
> alles umgebaut wurde.

Viel Erfolg für die Version 4.9!

Viele Grüße
Holger Trapp


Mehr Informationen über die Mailingliste Kobv-opus-tester