bei uns im Team gibt es gerade eine Diskussion darüber welche Zeichen bei Volltexten die aus der OCR kommen verwendet werden sollen. Dabei geht es zur Zeit erst einmal um das altdeutsche “ſ”
Hier ein Bildausschnitt:
Die OCR erkennt daraus folgenden Text:
Reizen des Hügellandes ſo reich geſegnetes Gebiet
die beſten Erinnerungen in unſere Heimat mit-
nehmen. Das Gelingen unſeres Ausfluges verdanken
wir jedoch in hohem Maße auch der perſöulichen
Liebenswürdigkeit der beiden Exkursionsleiter.
Es stehen sich nun verschiedene Meinungen gegenüber. Die eine Seite sagt: Das “ſ” wurde korrekt erkant und ausgezeichnet. Die OCR hat hier richtig gearbeitet. Alles was wir manipulieren führt zu schlechteren Ergebnissen. Die andere Seite sagt: Ein Nutzer erwartet heute in einem OCR geleſenen Volltext kein altdeutscheſ “ſ” ſondern ein “s”, alſo eher ſo ein Ergebniſ:
Reizen des Hügellandes so reich gesegnetes Gebiet
die besten Erinnerungen in unsere Heimat mit-
nehmen. Das Gelingen unseres Ausfluges verdanken
wir jedoch in hohem Maße auch der persöulichen
Liebenswürdigkeit der beiden Exkursionsleiter.
Wir sind uns im Team einig darüber, dass das Optimum natürlich wäre, wenn wir zwischen einer Ansicht von Originalzeichen und normierten Zeichen umschalten könnten, so wie es zum Beispiel das Deutsche Textarchiv anbietet. Allerdings gibt es für diese optimale Lösung verschiedene Aufgaben die noch gelöst werden müssten vorher:
Erweiterung des Goobi viewers Core zur Unterstützung mehrerer Textquellen pro Bilddatei
Erweiterung des Goobi viewer Indexers zum Erkennen von verschiedenen Textquellen und der Differenzierung was neu ist und was eventuell nur ein Update einer bestehenden Textfassung darstellt
Erweiterung der Oberfläche und Bereitstellung eines Umschalters der Sprachversionen inklusive persistenter Verlinkung
…
Deswegen steht gerade der Vorschlag im Raum: “Wir exportieren die angepasste Fassung ohne “ſ” und behalten das Original mit “ſ” weiterhin in Goobi workflow. Sobald die oben beschriebenen Schritte entwickelt und gelöst sind können dann mit einem Reexport der entsprechenden Werke beide Varianten für einen Endnutzer zur Verfügung gestellt werden.”
Was ist die Meinung in der Community dazu? Export mit “ſ” oder mit “s”?
habt Ihr bei Euch auf dem öffentlich zugänglichen Viewer-Testserver ein Beispiel? Mich würde neben der Anzeige als Volltext auch interessieren, wie sich die Suche nach Begriffen mit einem “ſ” verhält.
Es wurde dort allerdings bereits durch @andrey.kozhushkov der Solr so konfiguriert, dass das altdeutsche “ſ” auch mit dem normalen “s” gefunden wird. Der Nachteil davon ist aber, dass in diesen Fällen kein Highlighting mehr funktioniert, da dafür bislang die Buchstaben komplett übereinstimmen müssen. Aber zumindest kann gesucht werden…
Wenn die OCR-Daten potentiell für eine digitale Edition oder für diverse DH-Projekte nachgenutzt werden sollen, wäre eine OCR möglichst nahe am Original verpflichtend.
@jan : Sollte man eine OCR wirklich persistent verlinken?
Ich denke dein Vorschlag wäre die beste Zwischenlösung, denn das Highlighting sollte doch zeitnah funktionieren, gleichzeitig sehe ich auch die Tatsache, dass man langfristig unbedingt sich am Original orientieren aber beide Suchmöglichkeiten anbieten sollte
Bisher ist der Volltext unter /fulltext/IDENTIFIER/SEITENNUMMER/ verlinkt. Wenn wir zwei Varianten anbieten, dann finde ich schon wichtig sich darüber Gedanken zu machen wie ich auf die unterschiedlichen Varianten verlinken könnte.
Das könnte ja zum Beispiel einfach /fulltext/IDENTIFIER/SEITENNUMMER/VARIANTE/` sein.
Dann meinst Du mit “persistent” nur einen eindeutigen Link, nicht aber per DOI oder URN? Wenn man einzelne “Qualitäten einer OCR” per DOI oder URN adressieren wollte, bekäme man doch Probleme mit den durch Nutzer verbesserten OCR-Ergebnissen. Dann müßte jede nutzergenerierte Veränderung, und beträfe sie auch nur wenige Zeichen, eine eigene Persistenz/ Versionierung erhalten?
Ja, ich meine mit persistent eine URL um das verlässlich anspringen zu können innerhalb des Goobi viewers. Ich meine damit nicht eine URN, DOI, HANDLE für die Version des Volltextes zu hinterlegen.
Die OCR soll die Zeichen richtig erkennen, nichts interpretieren. Also wird das lange ſ sowie alle möglichen Umlautzeichen usw. in den Viewer übertragen.
Der von Euch angenommene Nutzer ist übrigens jemand der ein langes ſ kennt und auch erwartet. Dass es dabei zu einem Schluckauf beim Suchen kommt, ist bekannt, und ihr habt das Problem doch schon mit der Einstellung in SOLR gelöst.
Um alles weitere kümmern sich dann diejenigen, die eine Edition daraus erstellen wollen. Die können dann entscheiden, ob sie verschiedene Zeichen durch heute gängige ersetzen wollen. Das muss man aber entsprechend dokumentieren.
Den obigen Vorschlag, so eine standardisierte Edition im Viewer einzubauen, finde ich sehr gut. Das geht mit Suchen und Ersetzen bestimmter Zeichen doch recht einfach.
Der viewer würde dann einfach den normalen CONTENT indexieren und wir hätten auch keine Informationen verloren. So haben wir die Suchergebnisse erst einmal im Einklang mit der alten OCR-Engine und können den Indexer später noch erweitern, die ALTERNATIVE-Elemente auch noch zu berücksichtigen.
Wenn es jetzt keine heftigen Einwände gibt, bauen wir das so in den OCR-Service ein und rollen das auch in den nächsten Tagen aus.
Ich finde die Vorschläge gut. Je mehr Schwabacher und Textur eingelesen wird, umso mehr lustige Sachen werden auftauchen (rundes r, Eichhörnchen-p,…).
Wie wird das eigentlich beim “ß” gemacht? Das ist ja im Prinzip genau das gleiche, nur dass es eine 2:1 statt einer 1:1 Beziehung zwischen den Zeichen ist. Mir war ja gar nicht bewusst, dass die Suchergebnisse auch bei der Suche mit “ß” nur richtig markiert werden, wenn man zufällig mit dem richtigen Zeichen sucht, was angesichts der vershiedenen normgerechten Varianten im Lauf der Zeit eher Glückssache ist. Für das Wort “Nuss” sind ja auch die Varianten Nuſs und Nuß irgendwann orthographisch oder orthotypographisch korrekt gewesen.
In diesem Kontext ist auch wichtig zu bedenken, dass Volltexte versioniert werden müssen. Auch wenn es sich “nur” um eine verbesserte OCR handelt. Ansonsten werden ja Forschungsergebnisse aus den Digital Humanities die auf früheren OCR Versionen beruhen invalide.
