Abstract

Version 1.1 (17.10.2023)

Kleinere Änderungen im Text; Präzisierung des Begriffs »Cluster« zu »(Orts-)Cluster«; Ergänzung sowie Streichung in der Bibliografie.

• 1. Einleitung
• 2. Identifizierung und Lokalisierung von Urbanonymen
• 2.1 Kontextsensitive Entscheidungsfindung
• 2.2 Suchalgorithmen und Ähnlichkeitsanalyse
• 2.3 Historische Orte und Urbanonyme
• 3. Entwicklung des (heuristischen) Algorithmus
• 3.1 Metaheuristik
• 3.2 Datenbereinigung
• 3.3 Suche
• 3.4 Kontextdaten
• 3.5 Clusterung zur historischen administrativen Zugehörigkeit
• 4. Anpassung auf GEDCOM-Dateien
• 5. Validierung und Diskussion
• 6. Zusammenfassung
• Bibliographische Angaben
• Abbildungs- und Tabellenverzeichnis

1. Einleitung

[1]Orte werden tagtäglich in vielen Applikationen identifiziert und lokalisiert.[1] Der Bahnticketautomat, das Navigationsgerät im Auto oder die Suchmaschine im Internet stellen dafür nur einige willkürliche Beispiele dar. Das Prinzip dahinter ist vielfach aber gleich: Nach der Eingabe eines Orts oder mindestens eines Teils davon schlägt die Applikation einen oder mehrere auszuwählende(n) Orte vor. Die letztendliche Auswahl kann vom Menschen getroffen werden. Steht jedoch kein Mensch zur Verfügung, um eine abschließende Auswahl zu treffen, muss die Entscheidung auf zuvor definierten Kriterien beruhen. Durch Dopplungen, Ähnlichkeiten und Variationen von Ortsnamen ist dies jedoch kein triviales Unterfangen.

[2]In Deutschland (und Europa) gibt es beispielsweise zahlreiche Orte namens Neustadt. Allein 36 davon sind in der Arbeitsgemeinschaft Neustadt in Europa zusammengefasst.[2] Hinzu kommt, dass etliche Stadtteile diese Bezeichnung tragen. Werden die historischen, heute nicht mehr genutzten Bezeichnungen inkludiert, sind es nochmals mehr. Das kann zum einen darin begründet sein, dass die Ortsbezeichnungen heute einfach nicht mehr in Verwendung sind, weil es den Ort entweder nicht mehr gibt oder aber eine Umbenennung stattgefunden hat.[3] Zum anderen können die historischen Ortsangaben aber auch einen Ort beschreiben, dessen Relevanz heute nicht mehr ausreichend ist, um diesen durch eine gesonderte Bezeichnung zu würdigen – ohne, dass dieser gänzlich verschwunden wäre. Möglicherweise ist der Ort auch in einem übergeordneten aufgegangen; kleine Siedlungsformen, wie beispielsweise Weiler, verschwanden im Laufe der letzten Jahrhunderte. Die Herausforderungen, die sich heute aus der Lokalisierung von Ortsnamen ergeben, sind bei der Zuordnung historischer Bezeichnungen – im Weiteren als Urbanonyme[4] bezeichnet – also umso größer.

[3]Historische Ortsangaben stehen allerdings selten für sich allein, sondern sind von Kontextinformationen umgeben. Eingebettet in einen Fließtext kann sich aus den weiteren Informationen ergeben, um welchen Ort es sich handelt. Beispielsweise können in einem Adressbuch andere Ortsangaben oder die Angabe einer übergeordneten Gebietskörperschaft vorhanden sein. Diese als Kontext bezeichneten Informationen können zur Identifizierung genutzt werden. Nachfolgend kann auf dieser Basis eine geographische Lokalisierung des Orts angestellt werden. Im Kontext dieser Arbeit meint Lokalisierung eine Ortsbestimmung, die Objekte zu einer Adresse im physischen Raum der Erdoberfläche zuordnet.[5] Eine gesonderte, automatisierte Lösung zur Identifikation und Lokalisierung (speziell deutschsprachiger) historischer Urbanonyme ist bis dato nicht bekannt. Diese Lücke wird durch den vorliegenden Artikel geschlossen, indem ein Algorithmus als Lösung vorgeschlagen wird, der historische Ortsangaben[6] kontextsensitiv lokalisiert. Eine Übersicht der Begrifflichkeiten ist in Abbildung 1 vorhanden.

[4]Für viele wissenschaftliche Fragestellungen reicht allein die Lokalisierung der Ortsangaben jedoch nicht aus. Vielmehr ist es auch wichtig, die (historische) administrative Zugehörigkeit der Orte zu ermitteln und alle zusammengehörigen Ortsangaben zu clustern. Darum wird mit dem Algorithmus auch eine Methode bereitgestellt, mit der Orte über die administrative Zugehörigkeit zu einem definierten Zeitpunkt geclustert werden können. Der Algorithmus wird primär mit Hilfe von Urbanonymen aus genealogischen GEDCOM-Dateien[7] aus der Datenbank Genealogische Datenbasis (GEDBAS) getestet, soll aber auch auf andere Quellen adaptiert werden können. Damit wird ebenfalls einem Vorschlag Gellatlys nachgekommen, eine Software zur Geokodierung von Ortsangaben zu entwickeln.[8]

[5]Im folgenden Kapitel werden zunächst verschiedene bestehende Lösungsansätze betrachtet, auf deren Basis die Entwicklung des Algorithmus stattfindet. Danach wird der entwickelte Algorithmus in der Programmiersprache Python umgesetzt und am Beispiel von GEDCOM-Dateien aus der GEDBAS validiert. Abschließend erfolgt eine Zusammenfassung.

Abb. 1: Übersicht über Begrifflichkeiten und Zusammenhänge. [Goldberg 2022]

2. Identifizierung und Lokalisierung von Urbanonymen

[6]Die Identifizierung beschreibt die Zuordnung eines Urbanonyms (z. B. ›Berlin‹) zu einer physisch existierenden Entität – einem Ort (z. B. der Hauptstadt Berlin der Bundesrepublik Deutschland). Die Lokalisierung hingegen besteht in der Zuordnung von Koordinaten zu diesem Ort. Auch wenn die Lokalisierung das wesentliche Ziel darstellt, so liegt in der vorhergehenden Identifizierung die maßgebliche Herausforderung. Das ist dadurch bedingt, dass zu nahezu allen (identifizierten) Orten die geographischen Koordinaten leicht zu ermitteln sind, die eindeutige Identifizierung jedoch durch verschiedene historisch bedingte Faktoren erschwert wird.

[7]Im Folgenden wird der Stand der Technik verschiedener Teilaspekte dieser Herausforderung beschrieben. Zunächst wird erläutert, wie der Kontext zur Entscheidungsfindung beitragen kann. Danach werden kurz relevante Suchalgorithmen sowie Methoden der Ähnlichkeitsanalyse aufgegriffen. Da eine Identifizierung von Urbanonymen nur unter Hinzunahme (historischer) Ortsverzeichnisse möglich ist, finden auch diese Beachtung. Abschließend wird in die Struktur von GEDCOM-Daten eingeführt, die in dieser Studie zur Validierung des Algorithmus dienen.

2.1 Kontextsensitive Entscheidungsfindung

[8]Das oben angeführte Beispiel Berlins zeigt die Problematik deutlich auf: Neben der Hauptstadt könnte ebenso eine andere Entität, z. B. das Land Berlin der Bundesrepublik Deutschland oder der Ortsteil Berlin der schleswig-holsteinischen Gemeinde Seedorf, gemeint sein.[9] Ohne weitere Informationen, worauf sich die Ortsangabe bezieht oder in welchem Zusammenhang diese genannt wird, kann eine Identifizierung nicht eindeutig vorgenommen werden. Die Informationen im Zusammenhang der Verwendung eines Wortes werden dabei als ›Kontext‹ bezeichnet. Nach Dey und Abowd ist Kontext aus informationstechnischer Sicht jede Information, die zur Charakterisierung der Situation einer Entität genutzt werden kann.[10] Systeme, die diesen Kontext nutzen, werden als ›kontextsensitiv‹ bezeichnet.[11] Kontextsensitive Systeme bedingen also eine Flexibilität in der Ausführung eines Prozesses. Der Kontext als externer Einfluss kann dazu führen, dass der interne Prozess der Informationsverarbeitung angepasst wird.[12] Ein Beispiel dafür ist die Anzeige der Wettervorhersage in Abhängigkeit der Position oder die Veränderung der Bildschirmhelligkeit in Abhängigkeit der Umgebungsbeleuchtung. Auch in CARS (Context Based Recommendation Systems) werden Nutzer*innen auf Basis der ihnen verfügbaren Kontextinformationen in der Entscheidungsfindung unterstützt.[13] Daneben ist eine eigenständige Entscheidung zwischen mehreren konkreten Alternativen ohne menschliches Zutun auf Basis des Kontextes möglich.

[9]Bei der Lokalisierung ist eine Entscheidung notwendig, um die Verbindung zwischen einer konkreten Ortsbezeichnung und einem Ort zu definieren. Solche Entscheidungen können (in Anlehnung an einen binären Klassifikator) richtig oder falsch sein. Jedoch kann auch keine Entscheidung getroffen werden – und auch dieses kann richtig oder falsch sein. Richtig kann eine nicht getroffene Entscheidung für einen Ort beispielsweise sein, wenn die Ortsbezeichnung ›John Michael‹ lautet und kein Urbanonym darstellt, sondern – wie im Beispiel – womöglich aus einem Eingabefehler resultiert und einen Vornamen darstellt (TN). Diese Konstellationen sind in Tabelle 1 dargestellt. Dasselbe Schema ist auf die Lokalisierung und die nachfolgende regionale Klassifizierung anwendbar. Ziel ist es, möglich viele T*-Zuordnungen zu erreichen, gleichzeitig aber die F*-Rate niedrig zu halten.

---

	Identifizierung korrekt	Identifizierung nicht korrekt
Identifizierung erfolgt	True positive (TP)	False positive (FP)
Identifizierung nicht erfolgt	True negative (TN)	False negative (FN)

---

Tab. 1: Konfusionsmatrix zur Identifizierung von Ortsbezeichnungen in Anlehnung an Fawcett. [Fawcett 2006, S. 862]

[10]Um es am Beispiel Berlins auszudrücken: So würde in einer Liste der Bundesländer eher die Entität des Landes aufgegriffen, in einer Liste aller Hauptstädte jedoch die Entität Berlins als Hauptstadt Deutschlands. Der Kontext würde hier den Schluss zulassen, ob es sich um das Land oder die Stadt handelt. Diese Schlussfolgerung ist das Ergebnis einer Heuristik: Alle Werte in der Liste beschreiben Länder, also ist es wahrscheinlich, dass der letzte Wert auch ein Land ist. Jedoch kann der Wert auch kein Land darstellen, wodurch die Schlussfolgerung falsch wäre (FP). Heuristiken garantieren keine richtigen Ergebnisse,[14] sie dienen der Findung einer wahrscheinlich korrekten Lösung unter begrenztem Wissen und wenig Zeit.[15] Insofern sind kontextsensitive Entscheidungen, wenn der Kontext die Entscheidung nicht eineindeutig zulässt, heuristische Verfahren. Um eine Heuristik im Entscheidungsprozess eines technischen Systems einzusetzen, ist ihre Formalisierung notwendig. Eine programmtechnische Formalisierung der Heuristik führt in der Folge zu einem (heuristischen) Algorithmus.

[11]Um den Kontext einer Ortsbezeichnung nun für die Zuordnung zu einer Entität zu verwenden, müssen die Heuristiken definiert werden, die die Entscheidungsfindung beeinflussen. Zandhuis et al. nennen drei Möglichkeiten der Einbindung des Kontextes:

1. den Ort, an dem die Ortsangabe erstellt wurde,
2. eine Gebietszugehörigkeit und
3. die Zeit, in der die Quelle kreiert wurde in Zusammenhang mit der Information, wann ein Ort wie bezeichnet wurde, da die Bezeichnung temporalen Schwankungen unterliegen kann.[16]

[12]Insbesondere bei Sekundärquellen ist der Ort der (Primär-)Quellenerstellung nicht relevant oder bekannt. Auch Gebietsangaben sind nicht immer vorhanden. Ebenso verhält es sich mit den temporalen Informationen. Zudem kann in Sekundärquellen eine sprachliche Anpassung des Ortsnamens (an die Schreibweise zur Zeit der Erstellung der Sekundärquelle) stattgefunden haben.

[13]Aufgrund dieser Schwierigkeiten sind die drei genannten Punkte für eine Identifizierung nicht ausreichend. Es lassen sich jedoch andere Kontextinformationen finden: Der Kontext von Ortsbezeichnungen kann aus weiteren Ortsangaben bestehen, die möglicherweise in einem Zusammenhang stehen. Gegebenenfalls sind im Kontext auch konkrete Angaben zur geographischen Distanz zwischen den Entitäten, zur gemeinsamen administrativen Zugehörigkeit oder einer sonstigen Beziehung vorhanden. Zudem können temporale Angaben im Kontext die Identifizierung der Ortsangaben unterstützen. Aber nicht nur die Nennung von Orten, sondern auch die Personennamen kann relevant sein: Die Häufigkeit von Vornamen variiert über die Zeit, sodass hierüber eine Schätzung des Geburtsjahres – und somit eine zeitliche Verortung der Ortsbezeichnung – vorgenommen werden kann.[17] Wichtiger jedoch erscheint die regionale Dichte und Häufigkeit von Personennamen: Die Verwendung von Nachnamen ist oftmals geografisch nicht gleichverteilt.[18] In Abbildung 2 sind beispielhaft die relative und absolute Verteilung des Nachnamens ›Hinse‹ abgebildet. Es ist eine erhöhte Dichte im westfälischen Raum zu erkennen.[19] Demzufolge ist also wahrscheinlicher, dass der Name in Kombination mit Orten im westfälischen Raum genannt wird.

Abb. 2: Relative (links) und absolute (rechts) Verteilung des Nachnamens Hinse. [Goldberg 2022, erstellt mit Geogen Deutschland, Stöpel 2021a]

[14]Auch bei der Vornamensgebung sind in Deutschland regionale Unterschiede zu erkennen,[20] was teilweise auf unterschiedliche Präferenzen in der Taufnamensgebung verschiedener Konfessionen zurückzuführen ist.[21]

2.3 Historische Orte und Urbanonyme

[19]Um überhaupt Orte zu haben, die als Entitäten dienen und einem Vergleich mit der Ortsbezeichnung zugefügt sind, ist die Auswahl eines Ortsverzeichnisses eine notwendige Bedingung. Im Weiteren wird dazu das Geschichtliche Orts-Verzeichnis (GOV) des Vereins für Computergenealogie Verwendung finden.[26] Dieses enthält etwa 1,2 Millionen Objekte[27] in Europa.[28] Das GOV wird ausgewählt, weil es besonders im deutschsprachigen Raum viele historische Urbanonyme abbildet. Für andere Länder, beispielsweise die Niederlande, gibt es zudem weitere ausführliche Portale.[29]

[20]Zugang zum GOV kann eine externe Anwendung auf zwei Arten erlangen. Zum einen über das sogenannte Mini-GOV worin verschiedene Informationen zu Orten enthalten sind: Als Uniform Resource Identifier (URI) eines Ortes dient die sogenannte GOV-Kennung. Daneben ist der Typ des Objekts vorhanden, gefolgt von dem aktuellen Ortsamen (im Falle von früheren deutschen Siedlungsgebieten auch der letzte deutsche Name). Auch der Staat, dem das Objekt angehört, sowie vier Angaben zur administrativen Zuordnung werden angegeben.[30] Zudem ist die Postleitzahl vorhanden. Abschließend folgen mit den Längen- und Breitengraden die Koordinaten des Objekts. Zum anderen besteht die Möglichkeit über einen Webservice auf die Daten im GOV zuzugreifen. Während durch das Mini-GOV nur die oben genannten Informationen zu einem Ort zur Verfügung stehen, kann über den Webservice auf sämtliche Daten des GOV zugegriffen werden (siehe Abbildung 3).[31] Die Abfrage des Webservice ergibt ein assoziatives Datenfeld (im Folgenden Dictionary), in dem verschiedene Informationen zum Ort enthalten sind. Die Beschreibung der Zugehörigkeit zu übergeordneten Objekten erfolgt im Key ›part-of‹. Das in Abbildung 3 dargestellte Beispiel enthält vier Zugehörigkeiten. Die Dauer der Zugehörigkeit kann entweder über ›timespan‹ definiert sein. Im anderen Fall sind – wie im Beispiel – Beginn und Ende gesondert definiert. Auch ist die GOV-ID des übergeordneten Objekts enthalten. Das ermöglicht beispielsweise zusätzlich die administrativen Zusammenhänge der Vergangenheit zu erfassen. Die dadurch entstehende Baumstruktur ist implizit, da sie erst während der Suche erzeugt wird.

Abb. 3: Auszug aus einer GOV-Abfrage. [Goldberg 2022]

[21]Urbanonyme kommen in vielen Quellen vor. Besonders konzentriert sind Urbanonyme in genealogischen Datenstrukturen zu finden. Hierin sind es die zentralen Vitaldaten von Personen (Geburt bzw. Taufe, Heirat und Tod bzw. Beerdigung), die oftmals auch mit einer Ortsbezeichnung versehen sind. Durch die verwandtschaftlichen Verknüpfungen liegen zudem verschiedene Kontextdaten vor (Personennamen, Zeiten, weitere Ortsangaben). Aufgrund der hohen Informationsdichte werden im Zuge dieser Arbeit genealogische Daten in Form von GEDCOM-Dateien zur Validierung des Algorithmus eingesetzt. Einzelne GEDCOM-Dateien bestehen aus Text mit einer definierten Syntax. Eine Person wird beispielsweise wie im nachfolgenden Beispiel definiert (siehe Abbildung 4). Verschiedenartige Informationen werden dabei mit verschiedenen Tags gekennzeichnet. Standardmäßig definiert der Tag PLAC dabei eine Ortsangabe.[32] Diese kann sich auf die oben genannten Ereignisse beziehen. Im Beispiel ist sie dem Tag DEAT zugeordnet, beschreibt also den Ort des Todes. Ortsangaben unter diesem Tag sollten die Verwaltungszugehörigkeit in aufsteigender Reihenfolge enthalten und mit einem Komma voneinander getrennt werden, beispielsweise: Stadt, Kreis, Bundesland, Land.[33]

Abb. 4: Auszug einer GEDCOM-Datei. [Goldberg 2022]

3. Entwicklung des (heuristischen) Algorithmus

[22]Um historische Ortsangaben im deutschsprachigen Raum zu identifizieren und nachfolgend lokalisieren zu können, wird in diesem Abschnitt die Entwicklung eines Algorithmus beschrieben. In diesem wird die Heuristik zur kontextbasierten Auswahl eines Orts formalisiert. Zunächst wird die Metaheuristik erläutert, die dem zu entwickelnden Algorithmus zugrunde liegt. Die einzelnen Unteraspekte der Metaheuristik werden danach ausführlicher behandelt. Darunter fallen die Datenbereinigung, der Vergleich mit dem Mini-GOV, die Realisierung einer Ähnlichkeitserkennung, die Hinzuziehung von Kontextdaten und deren Alternativen sowie die Ermittlung historischer administrativer Zugehörigkeiten.

3.1 Metaheuristik

[23]Auch der Algorithmus bildet die eingangs eingeführte inhaltliche Zweiteilung ab: Zum einen die Identifizierung eines Ortes, zum anderen die Bestimmung der historischen administrativen Zugehörigkeit zu einem manuell definierten Zeitpunkt (im Folgenden ›Bezugszeit‹ genannt). Die Identifizierung wird zudem in zwei Unterabschnitte getrennt: Im ersten Teil werden zunächst alle Ortsangaben des Kontextes gesammelt und bewertet.[34] Als Erstes werden dabei die Ortsangaben grundlegend bereinigt. Es wird je Ortsangabe geprüft, wie viele Übereinstimmungen mit den Bezeichnungen im Mini-GOV vorliegen. Folgend werden all die Orte, die genau eine exakte Übereinstimmung aufweisen, identifiziert und in die Kontextdaten mit aufgenommen (siehe Abbildung 5). Neben den Bezeichnungen und der GOV-ID werden zu den Kontextdaten auch die geographischen Koordinaten gespeichert.

Abb. 5: Ermittlung und Bewertung von Kontextdaten, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]

[24]Mit Hilfe der nun ermittelten Kontextdaten können im zweiten Teil weitere Ortsangaben identifiziert werden (siehe Abbildung 6): Bei mehreren Übereinstimmungen mit dem Mini-GOV wird geprüft, ob für die zu überprüfende Ortsangabe Kontextdaten zur Verfügung stehen.[35] Falls ja, so werden für die verschiedenen Möglichkeiten jeweils die Koordinaten ermittelt und mit den Koordinaten der Kontextdaten verglichen. Der Ort, der nach diesem Vergleich die geringste Distanz aufweist, wird ausgewählt. Sind keine Kontextdaten vorhanden wird über eine Zuordnung auf Basis des Typs der möglichen Orte entschieden.

[25]Liegt nach dem eingänglichen Vergleich mit dem Mini-GOV keine genaue Übereinstimmung vor, so findet eine Ähnlichkeitsüberprüfung zwischen der Ortsbezeichnung und den Einträgen im Mini-GOV statt. So können Fehler korrigiert werden, die durch die eingängliche Bereinigung nicht erkannt wurden. Besteht dennoch keine Ähnlichkeit mit einem Objekt aus dem Mini-GOV, bleibt der Ort unidentifiziert. Bei einem oder mehreren Treffern wird wie oben beschrieben verfahren.

Abb. 6: Ortsidentifizierung, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]

[26]Der zweite Teil, die Clusterung, beginnt damit, dass für das zu untersuchende Objekt geprüft wird, ob eine Zuordnung zu einer historisch-administrativen Gliederungseinheit bereits früher erfolgt ist (siehe Abbildung 7). Das dient der Vermeidung doppelter Programmdurchläufe und somit der Laufzeitverkürzung. Wurde das Objekt noch keiner übergeordneten Einheit zugeordnet, so wird diese in der Baumstruktur der übergeordneten Objekte gesucht. Das erfolgt, indem in maximal zehn Iterationen jeweils ein übergeordnetes Objekt ausgewählt und neu untersucht wird. Hierzu wird jeweils geprüft, ob das Objekt Teil einer definierten Menge ist. Diese Menge stellt die historisch-administrative Zielgliederung (im Folgenden ›Provinz‹) zur Bezugszeit dar. Entspricht das Objekt einem Element der Zielmenge, so wird dem ursprünglichen Objekt diese Provinz zuordnet. Ist das nicht der Fall, so werden die Informationen aus dem GOV-Webservice für das entsprechende Objekt ausgelesen. Dieses Objekt kann nun wiederum für sich übergeordnete Objekte aufweisen, von denen eines für die nächste Iteration auszuwählen ist. Das geschieht, indem jedes übergeordnete Objekt dahingehend geprüft wird, ob die Bezugszeit in den Zeitraum der Zugehörigkeit des untergeordneten zum übergeordneten Objekt fällt. Ist das der Fall, wird das übergeordnete Objekt einer Liste A (höhere Priorität) hinzugefügt. Um beim obigen Beispiel zu bleiben, könnte etwa ›Mark Brandenburg‹ als übergeordnetes Objekt für ›Berlin‹ ausgewählt werden, wenn die Bezugszeit beispielsweise ›1301–1400‹ beträgt. Liegt die Bezugszeit hingegen nicht in der Zeitspanne der Zugehörigkeit zum übergeordneten Objekt, so wird das Objekt einer Liste B (niedrigere Priorität) zugewiesen.[36] Enthält die entsprechende Liste ein Element, so wird dieses Objekt ausgewählt und mit ihm die neue Iteration begonnen. Enthält die Liste jedoch mehrere Objekte, dann findet ein Vergleich dieser statt. Das ist überwiegend der Fall, wenn die Liste B Verwendung findet. Letztlich wird das Objekt ausgewählt, das zeitlich der Bezugszeit am nächsten ist.

Abb. 7: Analyse der provinziellen Zuordnung, eigene Darstellung als Nassi-Shneiderman-Diagramm. [Goldberg 2022]

3.5 Clusterung zur historischen administrativen Zugehörigkeit

[37]Sind die Orte (im Folgenden ›Objekte‹) identifiziert, so stehen zu ihnen verschiedene Metadaten aus dem Mini-GOV zur Verfügung. Angaben zur historischen administrativen Zugehörigkeit sind dort allerdings nicht zu finden. Über den Webservice des GOV können diese Angaben jedoch ermittelt werden, da dort die historische Zugehörigkeit eingesehen werden kann. Die hierarchische Anordnung von unter- und übergeordneten Objekten ergibt eine Baumstruktur. Jedes Objekt hat Informationen über seine übergeordneten Objekte. In der Folge liegt die Baumstruktur nicht zu Beginn vor, sondern wird mit der Abfrage jedes übergeordneten Objektes implizit weiter aufgebaut. Durch die Verknüpfung der Zugehörigkeiten ergibt sich eine Baumstruktur (Beispiel in Abbildung 8). Um eine administrative Zugehörigkeit zu ermitteln, ist es Ziel, den richtigen Pfad in der Baumstruktur zu finden. Das geht nur, wenn zuvor mögliche Ziele (Cluster, Provinzen) definiert werden. Die Zielmenge ist dabei zeitabhängig: Je nach gewünschter Zeit kann die Clusterung anders ausgestaltet sein. Dazu muss die Zielmenge für verschiedene Bezugszeiten definiert werden. Fertig et al. strukturieren das deutschsprachige Gebiet in 39 Einheiten, die den Zeitraum von 1816 bis 1871 abdecken.[51] Für einen möglichen Bezug auf die heute existierende Gliederung werden die sechzehn Bundesländer Deutschlands genutzt.[52] Allerdings könnte auch eine Gliederung heutiger Daten in den Grenzen von 1850 – oder andersherum, die Einteilung historischer Daten in den heutigen Grenzen – interessant sein. Diese wird durch eine Variation der Bezugszeit ermöglicht. Eine Zuordnung möglicher Provinzen mit GOV-Objekten ist folgend aufgeführt (siehe Tabelle 2). Weitere Regionen – oder eine detailliertere Skalierung der möglichen Cluster (u. a. Kreise, Regierungsbezirke) – können bei Bedarf implementiert werden.

Abb. 8: GOV-Struktur der Stadt Wiedenbrück, Stand: 30. Januar 2021. [Goldberg 2022]

---

Provinz[53]	GOV-Identikator	Bemerkung
ab hier Bezugszeit <= 1871
A 01 Provinz Holstein	object_190122
A 02 Provinz Lauenburg	adm_131053
A 03 Provinz Brandenburg (ohne Berlin)	object_1081716
A 04 Provinz Hessen-Nassau	object_190330
A 05 Provinz Hohenzollern	object_268785
A 05 Provinz Hohenzollern	object_284443	Hohenzollern-Sigmaringen 1850 nach Hohenzollerschen Landen
A 06 Provinz Ostpreußen	adm_368500
A 07 Provinz Pommern	adm_368480
A 08 Provinz Posen	object_211667
A 09 Provinz Sachsen	object_279654
A 10 Provinz Schlesien	adm_368470
A 11 Provinz Westfalen	object_190325
A 12 Provinz Westpreußen	object_213750
A 13 Rheinprovinz	object_1047283	Provinz Jülich-Kleve-Berg bis 1822
A 13 Rheinprovinz	object_405464	Provinz Großherzogtum Niederrhein bis 1822
A 13 Rheinprovinz	object_190337
A 14 Provinz Berlin	BERLINJO62PM
B 01 Amt Bergedorf	object_257607
B 02 Hansestadt Bremen	adm_369040
B 03 Stadt Hamburg	adm_369020
B 04 Stadt Lübeck	LUBECKJO53IU
B 05 Stadt Frankfurt am Main	adm_136412
B 06 Fürstentum Lippe-Detmold	object_217406
B 07 Fürstentum Schaumburg-Lippe	object_217818
B 08 Fürstentum Waldeck-Pyrmont	object_218152
B 09 Großherzogtum Oldenburg	object_352387
B 10 Großherzogtum Baden	object_217952
B 11 Hessen	object_218147
B 12 Großherzogtum Mecklenburg-Schwerin	object_217750
B 13 Großherzogtum Mecklenburg-Strelitz (einschließlich des Fürstentums Ratzeburg)	object_217749
B 14 Herzogtum Anhalt	object_190873
B 15 Herzogtum Braunschweig	object_217954
B 16 Herzogtum Nassau	object_218153
B 17 Herzogtum Schleswig	object_190098
B 18 Königreich Württemberg	object_190729
B 19 Königreich Bayern	object_217953
B 20 Königreich Hannover	object_190327
B 21 Königreich Sachsen	object_218149
B 22 Kurfürstentum Hessen	object_275299
B 23 Landgrafschaft Hessen-Homburg	object_284442
B 24 Thüringische Staaten	object_218143	Sachsen-Weimar-Eisenach
B 24 Thüringische Staaten	object_284441	Reuß Jüngere Linie
B 24 Thüringische Staaten	object_218134	Reuß Ältere Linie
B 24 Thüringische Staaten	object_218137	Sachsen-Altenburg
B 24 Thüringische Staaten	object_218138	Sachsen-Coburg-Gotha
B 24 Thüringische Staaten	object_265487	Sachsen Gotha
B 24 Thüringische Staaten	object_218142	Sachsen-Meiningen
B 24 Thüringische Staaten	object_218150	Schwarzburg-Rudolstadt
B 24 Thüringische Staaten	object_218151	Schwarzburg-Sondershausen
B 24 Thüringische Staaten	object_218141	Sachsen-Hildburghausen
ab hier Bezugszeit >= 1990
Land Baden-Württemberg	adm_369080
Freistaat Bayern	adm_369090
Land Berlin[54]	BERLINJO62PM
Land Brandenburg	adm_369120
Freie Hansestadt Bremen	adm_369040
Freie und Hansestadt Hamburg	object_1259992
Land Hessen	adm_369060
Land Mecklenburg-Vorpommern	adm_369130
Land Niedersachsen	adm_369030
Land Nordrhein-Westfalen	adm_369050
Land Rheinland-Pfalz	adm_369070
Saarland	adm_369100
Freistaat Sachsen[55]	object_218149
Land Sachsen-Anhalt	adm_369150
Land Schleswig-Holstein	adm_369010
Freistaat Thüringen	adm_369160

---

Tab. 2: Zuordnung von Provinzen zum GOV. [Goldberg 2022]

[38]Zur Suche in der Baumstruktur über- und untergeordneter Objekte wird im Folgenden ein informiertes Vorgehen genutzt. Dazu wird jeweils geprüft, ob das derzeitige Objekt Teil der Zielmenge ist. Ist es das nicht, werden die übergeordneten Objekte durchsucht. Hierbei wird überprüft, ob es ein Objekt gibt, welches in den Zeitraum der Bezugszeit fällt. Kann auf die Weise kein übergeordnetes Objekt identifiziert werden, wird dasjenige ausgewählt, dessen Grenzen der zeitlichen Zugehörigkeit am nächsten an der Bezugszeit liegen (z. B. die Bezugszeit 1820 und die zeitlichen Grenzen des nächsten Objektes von 1822-1838).[56] Sind ausschließlich übergeordnete Objekte ohne Zeitangaben vorhanden, weisen sie den gleichen Abstand zur Bezugszeit auf. In dem Fall wird die nächste Iteration mit dem erstgenannten Objekt der GOV-Abfrage durchgeführt. Solche Objekte, die einen kirchlichen oder juristischen Typ[57] aufweisen oder nur im nicht-deutschsprachigen Raum vorkommen, werden ausgeschlossen.[58] Wird ein übergeordnetes Objekt identifiziert, das Teil der Zielmenge ist, ist die Suche der historischen administrativen Gebietskörperschaft gelungen – der Ort wird der Provinz zugeordnet.[59]

[39]Nach der Ermittlung der Zugehörigkeit zu einer historischen Provinz wird diese gespeichert. Bei einer großen Anzahl von zu identifizierenden Ortsbezeichnungen bietet diese Vorgehensweise den Vorteil, dass doppelt vorkommende Ortsangaben mit denselben Kontextdaten nicht doppelt bearbeitet werden.

[40]Dieser Algorithmus findet die entsprechende Provinz nicht, wenn

1. durch die GOV-Abfrage keine übergeordneten Objekte ausgegeben werden (Beispielobjekt ›LIEHA2JO62RV‹) oder
2. kein Objekt der Zielmenge in den übergeordneten Objekten auftaucht,[60] was
3. auch daran liegen kann, dass der identifizierte Ort im Ausland (also außerhalb der Zielmenge) liegt.

4. Anpassung auf GEDCOM-Dateien

[45]Zur Vorbereitung der Validierung wurde der entwickelte Algorithmus in der Programmiersprache Python 3.7 umgesetzt. Der Programmcode ist im Online-Repositorium einsehbar. Er gliedert sich in verschiedene Funktionen, die zunächst einzeln erläutert und dann in ihrem Zusammenhang dargestellt werden. Die Kommentare im Programmcode beschreiben die konkrete Umsetzung des Algorithmus detailliert, sodass hier auf eine tief gehende Erläuterung verzichtet wird. Zum besseren Verständnis des Programms wird hier vielmehr der Aufbau beschrieben. Das Verständnis der Struktur hilft dabei, das Programm anzupassen. Grundlegend ist das Programm in die drei Bestandteile aufgeteilt, die auch schon zur Teilung des Algorithmus dienten (siehe Abbildung 9). Hierzu werden in jedem Schritt eigene CSV-Dateien mit den Zwischenergebnissen erstellt und ausgegeben.

Abb. 9: Aufbau des Programms. [Goldberg 2022]

[46]Vor der Main-Funktion wird dieser Prozess einmal je GEDCOM-Datei angestoßen (siehe Abbildung 10, die Pfeile zeigen an, in welcher Systematik die Funktionen aufgerufen werden). Bevor das geschehen kann, werden die zu untersuchenden GEDCOM-Datei vorbereitend so verändert, dass die Dateinamen eine Zahl gefolgt von der Dateinamen-Endung ›.ged‹ beinhaltet (d. h. ›1.ged‹, ›2.ged‹ etc.). Zahlen dürfen nicht doppelt vorkommen, jedoch ausgelassen werden. Eine durchlaufende Nummerierung ist empfohlen.

[47]Über die Funktion importMiniGOV() findet ein Import des Mini-GOV statt. Hier runter sind verschiedene Textdateien zu verstehen, die zuvor je (heutigem) Staat vom CompGen bereitgestellt werden.[61] Es werden die Mini-GOV-Dateien zu Deutschland, Polen, Österreich, der Schweiz, Tschechien, Dänemark, Frankreich und den Niederlanden integriert. Deutschsprachige Ortsnamen sind als aktueller Name oder letzter deutscher Name gekennzeichnet. Falls es Letzteren gibt, so wird ein zusätzlicher Eintrag kreiert, indem der alte Name den neuen überschreibt.[62] Ansonsten werden die Mini-GOVs aneinandergesetzt und alphabetisch sortiert. Hintergrund der Sortierung ist die Ermöglichung einer binären Suche darin.

[48]Da viele GEDCOM-Dateien einzeln und voneinander unabhängig zu bearbeiten sind, ist eine Parallelisierung des Programmcodes sinnvoll. Die Funktion parallel() wird dazu parallel aufgerufen und bearbeiten. Wesentlich darin ist der nacheinander folgende Aufruf von mainMetadataInspector(), mainPlaceFinder() und mainProvinceFiner(). Die Ergebnisse aus diesen jeweiligen Funktionsaufrufen werden mit der Funktion appendFile() den CSV-Dateien hinzugefügt. Diese Dateien sind zuvor über die Funktion createFile() erstellt worden. Dazu dient unterstützend die Funktion loadData(). Ebenso wurden zuvor die Daten der jeweiligen GEDCOM-Datei über loadGedcomFile() geladen.

Abb. 10: Funktionsweise der Main. [Goldberg 2022]

[49]Für die Inspektion des Kontextes wird eine Liste von Metadaten zu den einzelnen GEDCOM-Dateien geschaffen (siehe Abbildung 11). Dazu werden in der Funktion prePlaceFinder() die Ortsangaben über den Tag PLAC erkannt und über die Funktion minigovSearch() geprüft, ob sie nur eine Übereinstimmung im Mini-GOV aufweist. Hierzu wird über eine binäre Suche nach der Anzahl an Übereinstimmungen gesucht. Die jeweilige Ortsangabe wird dadurch bereinigt, indem nur der Teil nach einem möglichen ersten Komma entfernt wird. Wenn nur ein Treffer erzielt wurde, so wird der Ort in eine Liste eindeutiger Orte mit aufgenommen – die selektierten Kontextdaten.

[50]Nachfolgend wird in der Funktion qualityChecker() zunächst geprüft, ob die untersuchte Datei schon einmal vollständig verarbeitet wurde. In dem Fall wird für jede Ortsangabe zunächst nochmal geprüft, ob sie in der Liste der eindeutigen Werte vorhanden ist. Nicht zu allen eindeutigen Bezeichnungen gibt es jedoch Koordinatenangaben. Einträge, bei denen diese fehlen, finden keine weitere Beachtung. Mit den restlichen wird ein (Orts-)Clusterungsverfahren durchgeführt. Das gröbste mögliche (Orts-)Cluster stellt dabei den Mittelpunkt aus allen selektierten Kontextdaten dar. Sinnvolle Parameter für die Feinheit der (Orts-)Clusterung werden in der Validierung ermittelt. Die Koordinaten der (Orts-)Cluster werden zurückgegeben und ergänzen die Metadaten der Datei. qualityChecker() greift auf verschiedene Funktionen zu: Mithilfe der Funktion gedcomRowParser() werden die Bestandteile einer GEDCOM-Zeile separiert; stringDoublingCounter() dient der Zählung von (Orts-)Clustern.

[51]Im Ergebnis bestehen die Metadaten aus der Bezeichnung der Datei, den Durchschnittskoordinaten der selektierten Kontextdaten, der Anzahl eindeutiger Ortsbezeichnungen, der Anzahl daraus gebildeter (Orts-)Cluster sowie den Mittelpunkten jedes einzelnen (Orts-)Clusters. Die durchschnittlichen Koordinaten ergeben sich aus dem arithmetischen Mittel der Längen- und Breitengrade aller so gefundenen Ortsangaben.

Abb. 11: Funktionsweise der Kontextdatenanalyse. [Goldberg 2022]

[52]In der Funktion mainPlaceFinder() werden die Daten durch die Funktion dataCleaner() zunächst einer weitreichenden Bereinigung unterzogen (siehe Abbildung 12). In der Funktion stringFunc1() wird dazu unter anderem geprüft, ob eine bestimmte Zeichenkette am Anfang steht; diese wird sodann gelöscht, andernfalls wird alles vor dem Teilstring beibehalten. In stringFunc2() fehlt diese alternative Bedingung. Wie im vorherigen Abschnitt zerteilt die Funktion gedcomRowParser() die einzelnen GEDCOM-Zeilen in ihre Bestandteile.

[53]Die konkrete Auswahl eines Orts zu einer gegeben Ortsbezeichnung auf Basis der Kontextdaten findet in der Funktion find() statt, die durch die Funktion placefinder() vorbereitet wird. Hier wird im näheren der in Abbildung 6 gegebene Prozess umgesetzt. Unter anderem findet die kontextsensitive Zuordnung von Ortsbezeichnungen und Orten hier statt. Die Suche nach (Orts-)Clustern im Umkreis der Koordinate ist in die Funktion areaSearch() ausgegliedert. Hier wird auch die typenbasierte Zuordnung realisiert, falls die Umkreissuche fehlschlägt.

[54]Als Ergebnis steht eine Tabelle zur Verfügung, die für jede (unbereinigte) Ortsbezeichnung in jeder Quelle eine Zeile mit der GOV-URI, ihren ermittelten Koordinaten, der Information, über welche Art und Weise die Funktion find() die Zuordnung getroffen hat, der bereinigten und unbereinigten Ortsangabe sowie den Dateinamen enthält.

Abb. 12: Funktionsweise der Ortssuche. [Goldberg 2022]

[55]Zuletzt wird die Provinzsuche durch die Funktion mainProvincefinder() realisiert (siehe Abbildung 13). Zu jedem zuvor identifizierten Objekt wird die Funktion provincefinder() initiiert. Hierin findet die Suche in der übergeordneten Baumstruktur des GOVs statt. Die dazu notwendigen Informationen werden über die Funktion callWebservice() aus dem Internet abgerufen; es ist also eine Internetverbindung vom ausführenden Gerät vonnöten. Es wird angenommen, dass kein Baum mehr als zehn Ebenen besitzt. Deswegen wird in maximal zehn Iterationen immer eines der übergeordneten Objekte ausgewählt und untersucht. Zunächst wird dazu geprüft, ob eines der Objekte bereits Teil der Zielmenge ist.[63] Wenn das nicht der Fall ist, wird die Zeitspanne der Zugehörigkeit zur Auswahl herangezogen. Zur Berechnung von Beginn- oder Endjahren aus Zeitspannen der Zugehörigkeit zu übergeordneten Objekten im GOV werden die Funktionen beginCalculator() bzw. endCalculator() genutzt. In diesem wird aus der julianischen Angabe der Zeitspanne eine gregorianische Jahresangabe ermittelt. Da die Zeitangaben im GOV oftmals unvollständig sind, existiert ein System, dass mögliche Objekte priorisiert und so die Wahrscheinlichkeit vergrößert, das richtige Objekt auszuwählen. Dabei existieren auszuschließende Objekte (hier: Objekte kirchlichen Typus, ausschließlich Verwaltungsgliederungen anderer Staaten oder gerichtliche Institutionen), die nicht ausgewählt werden sollen. Hieraus folgt das Endergebnis: Eine Tabelle, die die ursprüngliche Bezeichnung, den Namen der Quelldatei, die GOV-URI sowie die Bezeichnung der zugeordneten Provinz enthält.

Abb. 13: Funktionsweise der Provinzsuche. [Goldberg 2022]

5. Validierung und Diskussion

[56]Zur Validierung des Algorithmus werden GEDCOM-Dateien aus GEDBAS genutzt. Hier können GEDCOM-Dateien von Nutzer*innen ohne grundsätzliche Beschränkung hochgeladen werden. Dabei können die Nutzer*innen beim Hochladen zulassen, dass ihre Datei anderen zum Download frei zur Verfügung steht. Diese downloadbaren Dateien stellen die Datenbasis für die Validierung dar. Dazu wird der bei Goldberg und Moeller beschriebene Scraper genutzt.[64] Eine Ausführung des Scrapers am 15. April 2020 erbrachte 1.899 GEDCOM-Dateien. Diese enthalten 3.371.825 durch den Tag PLAC[65] definierte Ortsangaben. Eine Separierung der Verwaltungszugehörigkeit durch ein Komma wird in den GEDCOM-Dateien in den überwiegenden Fällen nicht eingehalten, sodass diese Regelung schwerlich zu Identifizierung genutzt werden kann – und da wo sie eingehalten wird, werden unterschiedliche Verfahren genutzt.[66]

[57]Etwa 12 Prozent dieser Ortsbezeichnungen sind einem Objekt im Mini-GOV direkt zuzuordnen. Sie stellen demnach die Kontextdaten dar. Für weitere 34 Prozent gibt es mehrere, für 54 Prozent keinen Treffer. Diese 12 Prozent bilden die selektierten Kontextdaten, mit denen eine (Orts-)Clusterung durchgeführt werden kann. Für diese Anforderungen ist eine (Orts-)Clusterung gemäß DBSCAN-Verfahren geeignet (Density-Based Spatial Clustering of Applications with Noise). Der von Ester et al. beschriebene Algorithmus besagt, dass jeder Datenpunkt für sich betrachtet werden soll; ist er noch nicht klassifiziert wird die Bildung eines neuen (Orts-)Clusters oder die Zuordnung zu einem bestehenden angestoßen.[67] In Anlehnung daran ist eine (Orts-)Clusterung auch für die Kontextdaten realisiert (siehe Funktion qualityChecker()). Um die Parameter der (Orts-)Clusterung anzupassen ist eine Betrachtung der Streuung der (Orts-)Cluster in einzelnen GEDCOM-Dateien von Interesse. Zum einen kann die Mindestanzahl von Orten variiert werden, die nötig sind, um ein (orts-)Cluster zu bilden. Zum anderen ist die Mindestdistanz entscheidend, die ein Ort von einem (Orts-)Cluster entfernt sein muss, um diesem nicht zugeschlagen zu werden. Im Folgenden wird dieses für die GEDCOM-Dateien untersucht.[68] Bei einem Vergleich der Mittelpunkte von (Orts-)Clustern einer Quelle bei Variation der Parameter (Kilometer zur Zusammenführung zweier Orte, Mindestanzahl von Orten für ein (Orts-)Cluster, siehe Abbildung 14) zeigt sich, dass eine Distanz von 10 km (links) dazu führt, dass es sehr viele (Orts-)Cluster gibt, die nah beieinander liegen. Dieses ist ein unerwünschter Effekt, da diese (Orts-)Cluster aus der Perspektive des gesamten deutschen Sprachraumes zu wenig voneinander entfernt sind. Es deutet sich ein weiteres lokales Maximum bei der Distanz von etwa 450 km an. Auch bei 25 km zeigt sich dieses Bild (Mitte), allerdings in sehr abgeschwächter Form. Erst bei 50 km ist der starke Anstieg nach Erreichen des Mindestabstandes abgeflacht (rechts). Der Erwartungswert der Verteilung liegt etwa bei 450 km. Gleiches gilt bei einer Variation der Mindestanzahl an Koordinatendatenpunkten je (Orts-)Cluster zu erkennen. Hierdurch wird jedoch die absolute Zahl der (Orts-)Cluster stark geschrumpft.

Abb. 14: Anzahl an (Orts-)Clustern nach durchschnittlichem Abstand in km bei Variation des Mindestabstandes zwischen (Orts-)Clustern (10 km, 25 km, 50 km) und Mindestgröße von (Orts-)Clustern (2, 6, und 11), jeweils 200 Bins, Abszisse beschreibt den Abstand in km, Ordinate die Anzahl an (Orts-)Clustern. [Goldberg 2022]

[58]Bei einer Betrachtung der Anzahl von (Orts-)Clustern pro Datei für jede dieser neun Optionen ergibt sich, dass die unterschiedlichen Optionen vor allem bei Dateien mit vielen (Orts-)Clustern eine Auswirkung aufzeigen. Liegen eine geringere Mindestgröße und ein geringer Minimalabstand zwischen zwei Punkten von (Orts-)Clustern vor, erhöht sich die Anzahl der gesamten (Orts-)Cluster stark (siehe Abbildung 15). Das bedeutet, dass bei einer niedrigen Mindestdistanz sehr viele nah beieinanderliegende (Orts-)Cluster existieren. Aus diesem Grund wurde die Mindestdistanz von 50 km gewählt. Als Mindestgröße eines (Orts-)Clusters wird >5 gewählt, um einerseits die starke Erhöhung der (Orts-)Clusteranzahl bei einem weiteren Absenken der Mindestgröße zu vermeiden, auf der anderen Seite aber auch in wenig umfangreichen Dateien eine (Orts-)Clusterbildung zu ermöglichen.

Abb. 15: Zusammenhang zwischen Mindestdistanz, Mindest(orts-)clustergröße und (Orts-)Clusteranzahl, links mit logarithmischer Skalierung. [Goldberg 2022]

[59]Definiert wird also, dass ein (Orts-)Cluster mindestens aus sechs Orten bestehen muss. Ferner muss jeder Ort eines (Orts-)Clusters 50 Kilometer von dem Ort eines anderen (Orts-)Clusters entfernt liegen; ansonsten würden sie in einem gemeinsamen (Orts-)Cluster zusammengeführt. Es zeigt sich, dass dadurch 66 Prozent der GEDCOM-Dateien, die überhaupt ein (Orts-)Cluster aufweisen,[69] nur ein einziges (Orts-)Cluster aufweisen, das den oben definierten Eigenschaften (50 km, mind. 6 zusammenhängende Orte) entspricht. 19 Prozent jedoch weisen zwei (Orts-)Cluster auf, 15 Prozent sogar mehr als zwei. Die Entfernung der Optionen einer unidentifizierten Ortsangabe werden für alle (Orts-)Clustermittelpunkte berechnet. Der Ort mit der geringsten Distanz zu einem der (Orts-)Clusterpunkte wird für die Identifizierung gewählt.

[60]Ein weiterer Bestandteil der Validierung bezieht sich auf die Ähnlichkeitsanalyse. Diese ist zwar nicht primär zum kontextbasierten Aspekt des Algorithmus zu zählen, wird aufgrund der Relevanz für das Gesamtergebnis aber trotzdem diskutiert. Die Ortsangaben, zu denen keine Übereinstimmung gefunden werden konnten, werden einer Ähnlichkeitsanalyse unterzogen. Dazu werden zwei Varianten verglichen. Zum einen ist das die Levenshtein-Distanz (bereits in Abschnitt 2.2 erläutert). Zum anderen wird ein Maß gesetzt, dass sich hierarchisch auf verschiedene Bestandteile stützt: Zunächst werden vertauschte Zeichen erkannt, indem die 61 Orte[70] einer Anagrammdetektion unterzogen werden.[71] Falls kein Anagramm erkannt wird, werden zunächst aufeinanderfolgende doppelte Buchstaben in beiden Zeichenketten entfernt. Sind diese dann gleich, besteht eine Zuordnung. Ist das nicht der Fall, so wird mit dem verbleibenden Zeichen ein Vergleich nach der Kölner Phonetik angestellt. Bei einem gleichen Ergebnis findet eine Auswahl statt.

[61]Bei einem initialen Grenzwert von 0,25 (Verhältnis von Anzahl der Änderungen zur Länge der Zeichenkette[72]) ergeben sich sowohl bei der Levenshtein-Distanz als auch bei dem alternativen Maß viele Falschpositive (75 bzw. 74 Prozent). Ein Großteil dieser ist zum einen durch Ortsangaben zu Orten außerhalb des Betrachtungsgebietes bedingt, die dennoch deutschen Ortsnamen ähneln. Zum anderen sind dort überproportional viele Bezeichnungen vorhanden, die Orte in den ehemaligen Ostgebieten beschreiben und bei denen die zeitliche Konsistenz der Ortsbezeichnung (u. a. aufgrund von Umbenennungen) gering ist. Auch liegt das darin begründet, dass Ortsbezeichnungen teilweise sehr ähnlich sind.[73] Vermeintlich korrekte TP-Ergebnisse (z. B. ›Stuttgardt‹ zugeordnet zu ›Stuttgart‹) sind in der Minderheit. Aus diesem Grund wird die Grenze auf 0,17 (ab sechs Buchstaben eine Veränderung, ab 12 Buchstaben zwei Veränderungen etc.) verringert. In der Folge kommt die Ähnlichkeitsanalyse über die Levenshtein-Distanz etwa bei jedem sechsten Fall zu einem Ergebnis, das alternative Maß in jedem fünften Fall (siehe Tabelle 3). Bei 9,34 bzw. 11,90 Prozent ergeben sich mehrere Übereinstimmungen, von denen eine ausgewählt wird. Beide Ähnlichkeitsanalysen produzieren mehr falsche als richtige Ergebnisse. Dieses zeigt, dass die Ähnlichkeitsanalyse insbesondere bei einer schlechten Datenqualität und vor dem Hintergrund einer großen Ähnlichkeit von Ortsbezeichnungen eine Herausforderung ist, die hier nicht zur vollkommenen Zufriedenheit gelöst werden kann. Künftige Forschungen sollten sich diesem Aspekt verstärkt annehmen. Aber auch wenn der Wert bezogen auf die GEDCOM-Dateien nicht zufriedenstellend ist, so sollte dieses Element im Algorithmus dennoch beibehalten werden. Es ist zu erwarten, dass bei anderen Quellen mit einer besseren Datenqualität auch eine bessere Erkennung einhergeht.[74] Da der alternative Vergleich über Anagramme und die Kölner Phonetik bessere Werte (mehr TP-Ereignisse[75]) aufweist, wird diese Alternative im Weiteren ausgewählt.

[62]Eine Ausführung des Algorithmus unter den oben festgelegten Variationen ergibt das in Tabelle 4 dargestellte Ergebnis. 49,72 Prozent der Urbanonyme wird ein GOV-URI zugeordnet, 50,28 Prozent hingegen nicht. Der prozentuale Anteil der jeweils möglichen Ereignisse zeigt, dass fast jedes dritte Urbanonym dem weiteren Verfahren entzogen wird, weil es unerlaubte Bestandteile enthält. In diesem Fall sind die unerlaubten Bestandteile vor allem Hinweise auf eine Angabe außerhalb des Betrachtungsgebiets (z. B. Kürzel von US-Bundesstaaten), die in den vorliegenden Daten sehr häufig vorkommen. Bei anderen Daten können die unerlaubten Bestandteile entsprechend angepasst werden. Die kontextbasierte Auswahl auf Basis der geographischen Nähe bekommt daher eine hohe Relevanz. Auffällig ist auch der hohe Anteil an Ortsangaben, zu denen kein Pendant (also auch keine Ähnlichkeit) zu den Orten des Mini-GOVs vorhanden ist. Dem zugrunde liegen viele Berufsangaben und Orte außerhalb des Betrachtungsgebiets, aber auch vermeintlich korrekte Ortsangaben, die in einem unüblichen Format vorliegen (z. B. als Wikipedia-Verlinkung) oder sehr falsch geschrieben sind. Ansonsten finden sich auch hier überproportional viele Angaben, die auf ehemalige deutsche Ostgebiete hinweisen und nicht in der Ausführlichkeit im Mini-GOV gepflegt sind. Wenig relevant sind dagegen die Fälle, die die Typen der Objekte einbeziehen. Von diesen ist einzig allein die Option, bei der nur ein Objekt einen passenden Typ besitzt, mit 7,44 Prozent bedeutend.

[63]Eine Stichprobe von 100 Werten erbrachte 36 TP-Werte[78], 42 TN-Werte, 11 FP-Werte[79] und 11 FN-Werte.[80] Der hohe Anteil an Falschnegativen ist dadurch zu erklären, dass das Mini-GOV nicht alle Orte oder Varianten enthält (insbesondere in ehemaligen deutschsprachigen Siedlungsgebieten). Die Gründe für eine wahrnegative Lokalisierung hingegen sind überwiegend dadurch bedingt, dass Ortsangaben außerhalb des Betrachtungsgebiets als solche erkannt werden. Insgesamt sind also 78 Prozent der Ortsangaben korrekt und 22 Prozent nicht korrekt behandelt worden.

[64]Der zweite Teil der Validierung bezieht sich auf die (Orts-)Clusterung der GOV-URIs zu den Provinzen. Bei insgesamt 68.011 GOV-URIs wurde versucht, mit dem Algorithmus eine Provinz zum Jahr 1820 zuzuordnen. Bei 46.877 GOV-URIs (69 Prozent) war die Zuordnung erfolgreich. Der hohe Anteil an nicht zugeordneten GOV-URIs ist jedoch diskussionswürdig. Aus diesem Grund wurden 100 zufällige nicht zuordenbare GOV-URIs manuell überprüft.[81] Die Fehler sind in Tabelle 5 dargestellt.

[69]Es zeigt sich, dass der wesentliche Grund für den hohen Grad der Nicht-Erkennung darin liegt, dass die Objekte außerhalb des relevanten Zielgebiets liegen oder aber die GOV-Daten nicht vollständig sind. Letzteres betrifft vor allem die Orte in den heutigen Bundesländern Schleswig-Holstein, Rheinland-Pfalz und im Saarland. Hochgerechnet etwa 94 Prozent der Fehler liegen als nicht primär im Algorithmus begründet. Daraus ergibt sich eine Trefferquote von 97 Prozent[82] für die gesamte Provinzenzuordnung bezogen auf die GOV-URIs im Betrachtungsgebiet bei denen das GOV vollständig gepflegt ist. Hier zeigt sich, dass das GOV bereits eine breite Datengrundlage enthält und viele Fälle abdecken kann, jedoch in Bezug auf die historischen Verwaltungszugehörigkeiten auch künftig weiter komplettiert werden sollte.

[70]Bei einer Änderung der Bezugszeit auf das Jahr 2020 ergibt sich ein ähnliches Bild (siehe Tabelle 6). Auffällig ist, dass die GOV-Verwaltungszugehörigkeiten hier vollständiger sind. Am deutlichsten ist das bei Schleswig-Holstein. Für die Bezugszeit 2020 ergibt sich eine Trefferquote von 96 Prozent. Die Fehler sind allerdings etwas anders bedingt. Zwar sind sie auch darauf zurückzuführen, dass das GOV unvollständig ist. Das Bundesland ist jedoch (anders als oben) Teil der übergeordneten Objekte; lediglich die Dauer der Zugehörigkeit ist nicht gepflegt. Das tritt bei einzelnen Orten in Bayern und in Schleswig-Holstein um Lübeck herum auf.

[75]Insgesamt werden mit dem Algorithmus – unabhängig der beiden getesteten Bezugszeiten – etwa drei von vier Ortsangaben richtig identifiziert und lokalisiert. Werden die Ortsangaben isoliert betrachtet, die einer Provinz zugeordnet werden, so sind hier ebenfalls etwa drei von vier Zuordnungen korrekt. Fast jede identifizierte Ortsangabe kann nachfolgend auch regional geclustert werden.

6. Zusammenfassung

[76]Ob das Neustadt an der Aisch oder in Sachsen, an der Weinstraße oder in Hessen gemeint ist, kann durch den vorgestellten Algorithmus nun ermittelt werden – er trifft eine Entscheidung ohne menschliches Zutun. Grundlage hierfür stellt der Kontext dar, in dem die Bezeichnung des Ortes genannt wird. Die Kontextsensitivität wird dadurch erreicht, dass ein Bezug zu anderen Ortsangaben in der gleichen Quelle hergestellt wird. Die grundlegende Heuristik dahinter besagt: Gemeinsam genannte Orte liegen beieinander. Durch die Formalisierung und Automatisierung dieser Heuristik ergibt sich eine kontextsensitive Anwendung, die auf verschiedenen wissenschaftlichen Gebieten genutzt werden kann. Der Algorithmus trifft bei Anwendung auf die GEDCOM-Dateien der öffentlich zugänglichen genealogischen Datenbank GEDBAS – nach einer Bereinigung – in drei von vier Fällen eine korrekte Entscheidung. Das ist vor dem Hintergrund ein guter Wert, dass die Daten oftmals eine schlechte Qualität aufweisen, kein Standard in der Benennung praktiziert wird und sie Urbanonyme aus aller Welt enthalten, wenngleich der Schwerpunkt im zentraleuropäischen Raum zu verorten ist.

[77]Die Ortsbezeichnungen werden mithilfe des Kontextes identifiziert, durch die Bestimmung der Koordinaten lokalisiert und anschließend in einer (historischen) Provinz regional geclustert. Für den letzten Aspekt ist eine Bezugszeit zu definieren. Der Algorithmus ist derzeit darauf ausgelegt, Orte innerhalb des deutschsprachigen Raums (ohne Österreich und die Schweiz) in den Grenzen von 1815 bis 1871 sowie ab 1990 zuzuordnen. In diesem Rahmen kann sich auch die Bezugszeit bewegen. Dazu wird das Geschichtliche Orts-Verzeichnis (GOV) genutzt, ein geographisches Lexikon, das stetig erweitert wird. Die Zuordnung zu einer definierten Provinz gelingt in 70 Prozent der Fälle. Werden diejenigen Fehler herausgefiltert, die auf einer unvollständigen Datengrundlage und Orten außerhalb des Betrachtungsgebiets basieren, ergibt sich eine Zuordnungsrate von 96 Prozent.

[78]Zusammengefasst werden drei von vier relevanten Ortsangaben lokalisiert, wovon wiederum drei Viertel korrekt sind. Über 90 Prozent der Orte im Betrachtungsgebiet können nachfolgend regional geclustert werden. Der Algorithmus bietet damit eine geeignete Grundlage, um ihn an verschiedene Anwendungsszenarien anzupassen. Er stellt dadurch ein frei verfügbares Werkzeug insbesondere für wirtschafts- und sozialgeschichtliche Untersuchungen dar. Er kann prädestiniert dafür eingesetzt werden, Fragen der räumlichen Mobilität zu erörtern oder einzelne Datensätze in historischen Provinzen zu klassifizieren. Vor allem der Einsatz in kilometrischen Studien ist vorstellbar. Vorteile ergeben sich insbesondere in der Verarbeitung von Massendaten, wodurch neue Perspektiven für die Wissenschaft eröffnet werden. Er ist besonders dann vorteilhaft, wenn viele Ortsangaben im Kontext erfasst sind. Das ist u. a. der Fall, wenn zahlreiche zusammenhängende Orte ausgewertet und lokalisiert werden müssen. Zur Validierung des Algorithmus wurden zwar genealogische Daten genutzt. Prinzipiell ist der Algorithmus aber bei all solchen Quellen empfehlenswert, bei denen im Kontext weitere Ortsbezeichnungen genannt werden und ein räumlicher Zusammenhang nicht explizit verneint werden kann.[83]

[79]Derzeit deckt der Algorithmus den historischen deutschen Sprachraum ab. Da Informationen des GOVs auch für weitere europäische Länder verfügbar sind, könnten diese samt der dazugehörigen Regionen folgend integriert werden. Der Algorithmus ist zwar auf die deutsche Sprache ausgelegt (z. B. der Einsatz der Kölner Phonetik und die String-Bereinigungsregeln). Dennoch könnte er auf weitere Länder / Sprachen angepasst werden. Auch ist eine Weiterentwicklung des Kontextbezugs denkbar. Ein Beispiel dafür stellen die im Kontext genannten Vor- und Familiennamen dar. Voraussetzung hierfür ist eine vorhergehende Erstellung einer Datenbasis über die zeitliche und räumliche Verbreitung von Personennamen, auf die sich der Algorithmus beziehen kann.