Prüfung von Volltextdateien auf Dubletten

[alw-bsz]

Die DNB berichtet, dass immer wieder Dubletten in OPUS erfasst und abgeliefert werden. Da die Bereinigung mit Aufwand verbunden ist, wäre es gut, die Problematik bereits frühzeitig, d.h. spätestens vor der Freischaltung eines Dokuments, abzufangen.

Idee: Hashsummen neu eingebrachter Volltextdateien mit den Hashsummen der vorhandenen Dateien abgleichen.

Als Basislösung schlage ich vor:
Dateien werden im Hintergrund auf Dubletten geprüft (alle neuen Dateien, ob über das Publish-Modul, den Filemanager oder per SWORD eingebracht). Im Filemanager wird zu jeder Datei symbolisiert, ob die Dublettenprüfung noch im Gange ist (z.B. durch einen drehenden Kreis), es sich um eine Dublette handelt (z.B. rotes X) oder die Datei ok ist (z.B. grüner Haken). Wird eine Dublette erkannt, sollte ein Verweis auf den entsprechenden Datensatz angezeigt werden.

Die Prüfung sollte per Konfigurationsparameter auf bestimmte Dateiformate beschränkt (in aller erster Linie dürfte die Prüfung für PDF-Dateien relevant sein) und für Dateien über einer bestimmten Größe deaktiviert werden können.

Darüber hinaus wären denkbar:

• E-Mail-Notification an den Betreiber, wenn eine Dublette erkannt wurde
• Anzeige des Dublettenprüfungsstatus in der Dokumentenverwaltungsübersicht (admin/documents) mit denselben Symbolen wie im Filemanager
• Hinweis auf den Seiten admin/document/index und admin/document/edit, wenn eine Dublette erkannt wurde (oben auf der Seite direkt unter dem Titel des Dokuments als sofort ins Auge fallende Fehlermeldung)
• Bei nicht allzu großen Dateien könnte die Prüfung direkt on-the-fly während des Upload-Vorgangs erfolgen, bereits dem Einsteller mitgeteilt werden, dass es sich um eine Dublette handelt, und der Einstellvorgang abgebrochen werden. Sinnvoll ist dann sicher ein konfigurierbarer Parameter, um eine Dateigröße anzugeben, ab der die Hashsummenprüfung nicht mehr on-the-fly beim Upload passiert.

[j3nsch]

Wenn ich es richtig verstehe geht es hier um eine Dubletten-Prüfung auf Basis der Volltexte, also in der Regel der PDF-Dateien. Wir haben ja bereits erste Ansätze zur Prüfung basierend auf DOIs, z.B. beim CrossRef-Import. Es ist wichtig, klar darüber zu sein, dass es viele Teilaufgaben gibt, um die Konzepte im Zusammenhang mit Dubletten-Prüfungen in OPUS 4 zu integrieren, und die eigentlich Art und Weise der Prüfung davon unabhängig sein muss und sich im Laufe der Zeit sicherlich weiterentwickeln wird.

Ein erster, sinnvoller Schritt wäre die Entwicklung eines Konsolen-Kommandos, dass die entsprechende Prüfung, basierend auf den Hashes der Dateien, auf Wunsch durchführt. Spricht der Bericht der DNB von identischen PDF Dateien? Es wäre gut, genauer zu wissen, wie groß das Problem ist.

Aufbauend auf die manuelle ausgelösten Prüfungen, könnten automatische Prozesse in den User-Workflow integriert werden. Das bringt eine Reihe von Herausforderungen, wie z.B. robustes Background-Processing. Für eine sinnvolle Anzeige im User Interface müssen zusätzliche Metadaten gespeichert werden und letztendlich müssen weitere Facetten für Administratoren integriert werden, damit man die betroffenen Dokumente findet.

Es gibt sicherlich Möglichkeiten, Teilaspekte, einfach in den existierenden Code rein zu hacken, aber wir können es uns nicht Leisten alles doppelt zu machen und bei jedem Zwischenschritt muss genau überlegt werden wie nachhaltig er ist.

[j3nsch]

Das hier angerissenen Thema hat sehr viele, teilweise größere Teilaspekte, die nicht alle hier in diesem Issue diskutiert werden sollten. Ich habe deshalb ein weiteres Projekt dafür angelegt.

https://github.com/orgs/OPUS4/projects/67/views/1

Größere Teilaufgaben sollten als separate Issues festgehalten werden. Für einige der Teilaufgaben, z.B. das Background-Processing, gibt es bereits Issues.

[j3nsch]

Um ein paar Zahlen zu haben, könnte man ja auch erst einmal mit Linux-Bordmitteln, nach doppelten Dateien im Files-Verzeichnis einer Datei suchen. Viele Teilkomponenten der Behandlung von "Dubletten" werden in OPUS 4 so oder so kommen, weil sie auch für andere Features notwendig sind. Sie sind momentan aber nicht an der Spitze der Liste. Ein paar zusätzliche Eckdaten würden bei der Priorisierung eines integrierten Checks helfen.

Vielleicht reicht ein Tool wie folgendes für einen Bestandsaufnahmen.

https://manpages.ubuntu.com/manpages/jammy/en/man1/rdfind.1.html

[j3nsch]

Ich habe es mal in meiner Entwicklungsinstanz probiert und doppelte Testdateien wurden gefunden, auch wenn sie unterschiedliche Namen hatten. Ich habe rdfind im DryRun-Mode verwendet, damit keine automatischen Änderungen vorgenommen werden.

$ cd workspace/files
$ rdfind -n true .

Die genauen Ergebnisse stehen hinterher in results.txt.

[stconradr]

Ich habe das Paket rdfind bei uns installiert und es bei drei Instanzen mal testweise laufen lassen. Das Tool arbeitet sehr effektiv und schnell im Drymodus. Sehr schön, dass man eine Textdatei erhält, wo genau aufgelistet ist, bei welchen Dokumenten Dubletten vorhanden sind. Beim Auswerten der Dubletten habe ich festgestellt, dass sie aus unterschiedlichen Gründen vorhanden sind.

1. Weil das Dokument Tatsache doppelt erfasst wurde, einschließlich Metadaten und Volltext.
2. Weil z.B. eine Präsentation mehrmals auf unterschiedlichen Veranstaltungen gezeigt wurde. Jede Veranstaltung wurde dann einzeln erfasst und immer das PDF dazu hochgeladen.
3. Weil Artikel aus einer Gesamtbroschüre einzeln erfasst wurden und dann jeweils das Gesamt-PDF dazu hochgeladen wurde.

Ich denke, manche Dubletten könnten vermieden werden, wenn man darauf aufmerksam gemacht werden würde. Da würde ein automatisierter Check sehr helfen (mit Hinweis auf das andere Dokument und eine E-Mail an den Betreiber).
Manche Dubletten sind aber irgendwie dem Workflow geschuldet (z.B. die unterschiedlichen Konferenzveröffentlichungen).

[j3nsch]

Interessant und wie viele Dateien waren betroffen in diesen drei Instanzen?

[stconradr]

Hier ein Auszug aus der results.txt:

Eine große Instanz:
(DRYRUN MODE) Now have 23103 files in total.
(DRYRUN MODE) It seems like you have 797 files that are not unique

Eine mittlere Instanz:
(DRYRUN MODE) Now have 3392 files in total
(DRYRUN MODE) It seems like you have 2 files that are not unique

Eine kleine Instanz:
(DRYRUN MODE) Now have 319 files in total.
(DRYRUN MODE) It seems like you have 24 files that are not unique

[alw-bsz]

in unserem Use Case geht es nur um die "echten" Dubletten, d.h. dass Dateien versehentlich mehrfach im Repositorium veröffentlicht werden. Die Dubletten laufen nicht über einen langen Zeitraum immer weiter auf, sondern werden jeweils beim Harvesting der Dokumente durch die DNB erkannt und anschließend bereinigt. Das Ziel wäre konkret, die Dubletten bereits vor der Ablieferung an die DNB erkennen und bereinigen zu können.