Dokumente mit ungültigen ORCID iDs beim Speichern markieren

[j3nsch]

Beim Speichern soll eine Validierung stattfinden, wenn eine ORCID iD ungültig ist, soll das Dokument so markiert werden, dass das Problem in einer Facette angezeigt werden kann.

Es gibt die Funktionen isValid und getValidationErrors in der Implementation des Datenmodells. Diese werden zur Zeit nicht mehr oder kaum verwendet, weil irgendwann beschlossen wurde, Validierungen in den Formularen durchzuführen, aber im Framework auch das Speichern von ungültigen Werten zuzulassen. Ob das die richtige Entscheidung war, ist nicht ganz klar, aber hier nicht das Thema.

Beim Speichern von ORCID iD Werten werden jetzt vorangestellte URL-Teile entfernt. Dabei könnte auch eine Validierung stattfinden, um bei importierten Dokumente, die nicht in Formularen validiert wurden, ungültige Werte zu erkennen und die Dokumente entsprechend zu markieren.

Ein Problem ist, dass an dieser Stelle im Code, in der storeIdentifierOrcid-Funktion, nicht andere Element, Enrichments, des Dokuments manipuliert werden können oder sollten. Es kann auch zu Race-Conditions kommen, wenn z.B. die Validierung für das gesamte Dokument vorgenommen wird und die Speicherfunktion hinterher den Wert verändert, in dem sie den URL-Präfix entfernt. Wird die Prüfung später angesetzt, sind die Enrichments vielleicht schon gespeichert worden, bevor das Dokument markiert werden kann.

Es muss überlegt werden was ein sinnvolles, robustes Design wäre und dann muss man schauen was mit der aktuellen Implementation ohne viel Aufwand möglich ist. Es kann sein, dass die notwendigen Kompromisse im Augenblick zu groß sind.

[j3nsch]

Einige der Probleme könnten umgangen werden, wenn die Markierungen außerhalb der eigentlichen Metadaten der Dokumente gespeichert würden. Es gibt bereits ein einfaches Properties System für das Speichern von zusätzlichen Informationen über Objekte, wie Dokumente, Personen und Dateien.

Das Properties System ist aber unter anderem noch nicht in die Indexierung integriert, so dass basierend auf diese Informationen keine Facette erstellt werden kann. Die notwendigen Änderungen sind zu groß für einen Patch Release und würden unter anderem ein neues Solr-Schema erfordern. Abgesehen davon gibt es für OPUS 4.8.* zwei opus4-search Packages, für PHP 7 und 8, die beide geändert werden müssten. Letztendlich sind für die Suche einige Bereinigungen notwendig, die vor der Umsetzung neuer Funktionen erfolgen sollten.

Der einzige gangbare Weg im Augenblick sind also Enrichments.

[j3nsch]

Aufgrund der aktuellen Hindernisse bei der Umsetzung einer "synchronen" Prüfung von ORCID iDs beim Speichern, sollte für OPUS 4.8.0.13 erst einmal eine "asynchrone" Prüfung umgesetzt werden, die von außen, unabhängig von der internen Implementation im Framework, erfolgen kann. In OPUS4/application#1307 geht es um ein Kommando für die Validierung aller ORCID iDs in der Datenbank. Dabei könnten Dokumente mit Problemen markiert werden.

[j3nsch]

Ein kurzfristige Lösung wäre vielleicht eine neue DocumentLifecycleListener-Klasse bzw. eine temporäre Erweiterung der Funktionalität der existierenden Klasse, um eine Validierung des Dokumentes und die Manipulierung des Enrichments für Probleme durchzuführen. Damit es keine unnötigen Meldungen für ORCID iDs mit URL gibt, sollte dabei bereits beim Aufruf von setIdentifierOrcid das Entfernen von URL-Präfixen erfolgen.

[j3nsch]

Das Markieren der Dokumente ohne eine Aktualisierung von ServerDateModified kann erreicht werden in dem man den LifecycleListener vom Dokument entfernt bevor es gespeichert wird. Dabei muss natürlich darauf geachtet werden, dass keine anderen relevanten Änderungen vorgenommen werden. Diese Methode scheint aber auch die Indexierung des Dokumentes nach dem Speichern zu verhindern.