Inhaltsverzeichnis

• Hebraica-Katalogisierung - Ausgangslage
• Funktionsweise der Revrit-API
• Umgang mit den Konversionsergebnissen
• Bearbeiten der Konversionen

Hebraica-Katalogisierung - Ausgangslage

Hebraica wurden vor 2006 auf Basis von Transliterationsstandards erschlossen und in Bibliothekskatalogen verzeichnet, die für Nutzer*innen weitgehend unzugänglich bleiben. 2006 wurde durch die Revision der DIN und ihre Anpassung an internationale Standards eine größere Nutzerfreundlichkeit erreicht. Eine Anreicherung der Titeldaten mit Originalschrift war lange nicht möglich, weder auf der Ebene der Katalogisierungssoftware noch in der Anzeige in Online-Katalogen und Discovery-Systemen. Das änderte sich erst nach 2009 schrittweise.

Um den Nachweis von Hebraica zu verbessern, hat der FID Jüdische Studien ein Retro-Konversionsverfahren entwickelt, mit dem Titeldaten von Hebraica retransliteriert werden. In der ersten Förderphase des FID Jüdische Studien (2016–2019) wurde das Verfahren entwickelt und Bestandsdaten der Universitätsbibliothek Frankfurt am Main erfolgreich mit Originalschrift angereichert. Der Anteil an originalschriftlichen Metadaten im » Fachkatalog Jüdische Studien konnte fast verdoppelt werden. Erweiterungen der Funktionalitäten sind geplant, darunter auch ein gesondertes Verfahren für jiddische Titel.

Die Open-Source-Software und Dokumentation sind auf » Github verfügbar.

Funktionsweise der Revrit-API

Die API führt die automatische Retransliteration in mehreren separaten Schritten durch. Der JSON-Input wird konvertiert, die Konversion mit Titeldaten aus einer Referenzdatenbank abgeglichen und verbessert, und schließlich erfolgt die Ausgabe mit zusätzlichen diagnostischen Informationen zur Evaluierung.

1. Input

Vor Beginn des Prozesses müssen die Daten in ein standardisiertes Format überführt werden. Die API arbeitet mit einem einfachen JSON-Format, bestehend aus 6 Elementen.

{
  "title": ["{ha-} Zemer ha-ʿivri : poʾeṭiḳah, musiḳah, hisṭoriyah, tarbut /
 ʿorekhet ha-ḳovets Tamar Ṿolf-Monzon"],
  "isPartOf": ["Biḳoret u-parshanut"],
  "creator": ["Ṿolf-Monzon, Tamar"],
  "date": [2012],
  "publisher": ["Universiṭat Bar-Ilan, Ramat-Gan"],
  "identifier": ["728971356"]
}

Ergebnis der Konversion: ה @זמר העברי : פואטיקה, מוסיקה, היסטוריה, תרבות / עורכת הקובץ תמר וולף-מונזון

title

Notwendig ist der Titel selbst, bestehend aus dem Haupttitel, den Titelzusätzen und der Verantwortlichkeitsangabe. Wünschenswert sind aber auch weitere Elemente, um die Konversion in Originalschrift in späteren Schritten verifizieren zu können:

isPartOf

enthält den Gesamttitel bei Bänden von mehrteiligen Monographien oder Schriftenreihen.

creator

Unter "creator" werden die Namen der verantwortlichen Personen zusammengefasst.

date

Das Erscheinungsjahr im Feld "date" kann die verschiedenen Formate der hebräischen Jahresangaben verarbeiten.

publisher

Unter "publisher" werden Ort und Verlag zusammengefasst.

identifier

Sinnvoll für die spätere Prozessierung ist die Angabe eines "identifier". Damit kann der konvertierten Titel anschließend wieder in den Katalog zurückgespielt werden.

2. Automatische Konversion

Der erste Prozessschritt der API ist die automatische Konversion in Originalschrift.

Die API basiert auf dem » Open-Source-Programm Deromanize, welches in der ersten Förderphase entwickelt wurde. Deromanize ist unabhängig von der zu konvertierenden Schrift. Das Programm lässt sich also auch für die Verwendung anderer Schriften anpassen.

Zunächst muss der Transliterationsstandard identifiziert werden. Deromanize greift auf Regeln für die Transliteration des Hebräischen nach DIN 31636 und ihren jeweiligen Versionen zurück sowie auf die älteren Standards nach den Preußischen Instruktionen; zusätzlich werden häufige Transliterationsfehler berücksichtigt. Entsprechend der erkannten Transliterationsnorm führt die API die Retransliterierung durch.

Das Ergebnis ist auf Grund der Spezifika des Hebräischen als Konsonantensprache nicht immer eindeutig. Auch erschweren Diakritikafehler aus dem Transliterationsprozess die Rekonversion. Daher erstellt das Tool für jedes Wort eine Liste originalschriftlicher Konversionsmöglichkeiten, wie am Beispiel des Wortes Shalom nachvollzogen werden kann:

• Alle originalschriftlichen Formen, die aufgrund der Transliterationsregeln als mögliche Vorlage für den lateinschriftlichen Text in Frage kommen, werden von der API generiert. Dabei berücksichtigt sie sowohl die Plene- als auch die Defektiv-Schreibweise. Für das Beispiel "Shalom" wird die Möglichkeit in Betracht gezogen, dass die Vokale A oder O sich zum Beispiel durch Aleph oder Vav manifestieren könnten.
• Mit Hilfe interner Lexika (Hspell und Wortlisten, generiert durch originalschriftliche Titeldaten der National Library of Israel und der Universitätsbibliothek Frankfurt am Main) wird ein Wortabgleich durchgeführt, um nichtexistente Worte zu identifizieren. Shalom und shalem werden als reale hebräische Worte gefunden. Worte, die nicht im Lexikon auftreten, erhalten in der Auswahlliste ein niedriges Ranking. Das Ranking wird außerdem sehr stark dadurch beeinflusst, ob die Form im Cache bereits vorhanden ist.
• Für jedes Wort des lateinschriftlichen Inputs wird die originalschriftliche Konversion mit dem höchsten Ranking ausgewählt und daraus wird das originalschriftliche Konversionsergebnis für den gesamten Titelstring zusammengestellt. Dieses Konversionsergebnis hat eine Genauigkeit von 96% für einzelne hebräische Wörter. Je länger ein Titel ist, umso höher wird die Fehlerwahrscheinlichkeit innerhalb des Strings. Für eine Übernahme der konvertierten Titeldaten in das Katalogsystem reicht diese Genauigkeit also nicht aus. Daher erfolgt im 2. Schritt ein Abgleich mit Titeldaten in einer Referenzdatenbank.

3. Verifizierung der Daten

Die Basis dieser Referenzdatenbank sind die Metadaten der National Library of Israel für hebräische Titel. Diese Datenbank wird sukzessive ergänzt mit weiteren originalschriftlichen Titeldaten. Wir verwenden eine lokale Datenbank, die den Vorteil bietet, dass Abfragen im Vergleich zu Live-Onlineabfragen viel zeitsparender durchgeführt werden können.

• Für den Abgleich mit der Referenz wird der Titelstring in die Subfelder unterteilt. Haupttitel, Titelzusätze und Verantwortlichkeitsangabe werden mit unterschiedlicher Stringenz geprüft. Dabei wird berücksichtigt, dass die Unterteilung in Subfelder für denselben Titel in verschiedenen Katalogisaten variieren kann.
• Um den passenden Titel in der Datenbank zu finden, werden auch alternative Retransliterationsmöglichkeiten mit niedrigerem Ranking in Betracht gezogen.
• Weitere bibliographische Daten werden neben der Titelkategorie berücksichtigt, um möglichst sogar die passende Ausgabe zu identifizieren und damit die korrekte Orthographie des Titels.

Kann ein passender Titel in der Datenbank identifiziert werden, erhält der Datensatz die Klassifizierung "verified".

Kann kein Abgleich mit den Referenzdaten erfolgen, wird der Titel als "unverified" klassifiziert. Ein fehlender Abgleich kann mehrere Gründe haben:

• Titeldaten für die Retransliterierung werden nach dem Sprachcode selektiert. Bei größere Datenlieferungen sind daher auch viele Metadaten ohne hebräischen Titel enthalten.
• Einige hebräische Titel fehlen in der Datenbank und können daher nicht gematcht werden.
• Eine weitere Möglichkeit ist, dass das Matching selbst nicht erfolgreich war. Für den Abgleich müssen sehr strikte Bedingungen erfüllt werden. Insbesondere bei alten Drucken besteht das Problem, dass die langen Titelstrings in verschiedenen Katalogisaten völlig unterschiedlich abgekürzt werden und daher große Unterschiede zur Referenz bestehen können.

Das Konversionsergebnis kann aber trotz fehlenden Matchings sehr gute Qualität haben. Diese Daten möchte man auch verwenden. Daher bietet die API detaillierte diagnostische Informationen an, mit deren Hilfe eine Evaluation für die weitere Prozessierung von nicht verifizierten Konversionen möglich wird.
Da die Qualität der einzelnen Titelsubfelder sehr unterschiedlich sein kann und die Sprache zwischen den Subfeldern variieren kann, wird jedes Subfeld einzeln analysiert. Die diagnostischen Informationen werden dann getrennt nach Haupttitel, Zusätzen und Verantwortlichkeitsangabe dokumentiert.

standard

Die erste Angabe ist "standard" und gibt den identifizierten Transliterationsstandard an. Konvertierte Titel ohne diese Angabe sollten nicht automatisch übernommen werden. Manche Titel werden allerdings auch fälschlich als nicht-hebräisch identifiziert. Das gilt insbesondere für Titelaufnahmen, die automatisch aus OCR-gescannten Katalogkarten erzeugt worden sind und die eine hohe Fehlerrate z.B. durch Probleme mit den Diakritika haben.

foreign_tokens

"foreign_tokens" untersucht, ob der Textstring Zeichen enthält, die in hebräischen Transliterationen nicht auftauchen sollten, in anderen Sprachen aber üblich sind. Fehlerhafte Transliterationen können solche Zeichen enthalten, und da die Fehlerwahrscheinlichkeit in solchen Fällen deutlich höher ist, sollten die Konversionsergebnisse nicht automatisch übernommen werden. Wunschwert ist "false".

transliteration_tokens

"transliteration_tokens" prüft, ob die für Transliterationen typischen Diakritika (z.B. für Aleph und Ayin) im Textstring auftauchen. Ihr Vorhandensein kann ein Hinweis darauf sein, dass es sich um eine Transliteration handelt, allerdings treten einige der Diakritika auch in anderen Sprachen auf.

fully_converted

"fully_converted" prüft, ob jedes Wort des Subfeldes konvertiert werden konnte. Unvollständig konvertierte Subfelder sollten nicht automatisch übernommen werden. Wunschwert ist "true".

all_cached

"all_cached" zeigt an, ob die Konversion jedes einzelnen Wortes schon früher erfolgreich verifiziert worden ist. Optimal ist "true".

all_recognized

"all_recognized" untersucht, ob jedes einzelne Wort als Hebräisch erkannt wurde. Auch hier ist der Wunschwert "true".

Umgang mit den Konversionsergebnissen

Die API gibt als Ergebnis eine Empfehlung aus, wie mit den konvertierten Titeln zu verfahren ist.

Klassifikation "verified"

Konnte ein Titel mit der Referenzdatenbank abgeglichen werden, wird der originalschriftliche Referenztitel ("matched_title") vom Layout her angepasst angezeigt und die Unterschiede zwischen Konversion und Match werden quantifiziert.

Input:	ha-Milḥamah ha-sifrutit ben ha-ḥaredim ṿe-ha-maśkilim : peraḳim be-toldot ha-sifrut ha-ʿIvrit be-Rusyah bi-shenot ha-shishim ṿe-ha-shivʿim / Gideʿon Katsnelson. Be-tseruf haḳdamah me-et Yosef Ḳlozner
Konversion:	המלחמה הספרותית בן החרדים והמשכילים : פרקים בתולדות הספרות העברית ברוסיה בשנות השישים והשבעים / גדעון כצנלסון. בצירוף הקדמה מאת יוסף קלוזנר
Match:	המלחמה הספרותית בין החרדים והמשכילים : פרקים בתולדות הספרות העברית ברוסיה בשנות הששים והשבעים / בצירוף הקדמה מאת יוסף קלוזנר

Die API empfiehlt dezidiert die Einspielung des Matches (display: "matched title"). Diese Empfehlung ist Standard bei verifizierten Konversionen. Dadurch erreicht die API eine Genauigkeitsrate bei 99% für den Gesamttitel. Durch das Einspielen des “matched title“ wird im obigen Beispiel der Fehler korrigiert, der sich durch die Uneindeutigkeit der Retransliteration ergibt: בן statt בין

» Link in die vollständige Ausgabeansicht der JSON-API (verified)

Klassifikation "unverified"

Für Titel ohne Abgleich mit den Referenzdaten sind Empfehlungen für die weitere mögliche Prozessierungen angegeben, die für die einzelnen Titelsubfelder (Haupttitel, Titelzusatz, Verantwortlichkeitsangabe) variieren können. Es wird aufgelistet, welche Konversionstitelsubfelder sich für einen Import in eine sichtbare Titelkategorie eignen (display) und welche nur zur Verbesserung der Suchbarkeit in eine Indexkategorie importiert werden sollten (search). Fehlt die Empfehlung, sollte kein automatischer Import der Konversion durchgeführt werden.

Input:	Maṭeh Dan ṿe-Kuzari ḥeleḳ sheni : yokhiaḥ ṿe-yoreh bi-ṭeʿanot sikhliyot bi-reʾayot ḥazaḳot u-.ve-moftim || gedolim amitat she-be-ʿal peh ha-meḳubelet me-R[abotenu] z[ikhronam] l[ivrakhah] ḥokhme || ha-Mishnah ṿe-Shas
Konversion:	מטה דן וכוזרי חלק שני : יוכיח ויורה בטענות סכלייות בראיות חזקות ובמופתים || גדולים אמיתת שבעל פה המקובלת מר ז ל חכמי || המשנה וש״ס

Im dargestellten Beispiel wird aufgrund von Konversions-Problemen mit den Akronymen empfohlen, die Konversion des Haupttitels und der Zusätze nur in Indexfelder zu importieren, und vom Display des Ergebnisses abgeraten.

Ein Match mit der identischen Ausgabe in der National Library of Israel war nicht möglich, da dort die Metzer Auflage von 1779/80 fast ohne Titelzusätze katalogisiert wurde. Das am besten bewertete Suchergebnis ("top query result") ist nur ein Jerusalemer Nachdruck der Londoner Ausgabe desselben Titels und wird daher von der API nur angezeigt und nicht verwendet.

» Link in die vollständige Ausgabeansicht der JSON-API (unverified)

Bearbeiten der Konversionen

Das » Revrit Auditing Webtool erlaubt die intellektuelle Prüfung und Korrektur der Konversionsergebnisse. Daten werden im JSON-Format importiert und nach Bearbeitung ebenfalls in JSON exportiert. Das Auditing Webtool ermöglicht die Selektion der Daten auf Basis der Diagnostik-Informationen von Revrit (verified, unverified, error) sowie der Handlungsempfehlungen für die weitere Handhabung im Zielkatalog (display, search). Konversionsergebnisse können mit dem Auditing Webtool mit der Referenzdatenbank abgeglichen sowie manuell bearbeitet werden. Zur Unterstützung der Bearbeitung einzelner Titel werden wahrscheinliche Konversionsmöglichkeiten angezeigt.

Weitere Informationen finden Sie in der ausführlichen » Anleitung zum Revrit Auditing Webtool