<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="https://www.zfdg.de/sites/default/files/schema/tei_zfdg.rnc" type="application/relax-ng-compact-syntax"
?>
<TEI xmlns="http://www.tei-c.org/ns/1.0"
xmlns:html="http://www.w3.org/1999/html"
xmlns:tei="http://www.tei-c.org/ns/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<teiHeader>
<fileDesc>
<titleStmt>
<title>
<biblStruct>
<analytic>
<title level="a">Kontextsensitive Entscheidungsfindung zur automatisierten
Identifizierung und Clusterung deutschsprachiger Urbanonyme</title>
<respStmt>
<resp>
<persName>
<name role="marc_aut">
<forename>Jan Michael</forename>
<surname>Goldberg</surname>
</name>
<email>jan.goldberg@wiwi.uni-halle.de</email>
<idno type="gnd">1240406630</idno>
<idno type="orcid">0000-0002-4817-4283</idno>
</persName>
</resp>
<orgName>Martin-Luther-Universität Halle Wittenberg, Lehrstuhl für empirische Makroökonomik</orgName>
</respStmt>
<idno type="doi">10.17175/2022_005</idno>
<idno type="ppn">1817560271</idno>
<idno type="zfdg">2022.005</idno>
<idno type="url">https://www.zfdg.de/node/339</idno>
<date when="2022-10-10">10.10.2022</date>
</analytic>
<monogr>
<title level="j">Zeitschrift für digitale Geisteswissenschaften</title>
<respStmt>
<resp>Publiziert von</resp>
<orgName role="marc_pbl">Herzog August Bibliothek</orgName>
</respStmt>
<respStmt>
<resp>Transformation der Word Vorlage nach TEI</resp>
<persName/>
<name role="marc_trc">
<surname>Baumgarten</surname>
<forename>Marcus</forename>
<idno type="gnd">1192832655</idno>
</name>
</respStmt>
<availability status="free">
<p>Available at <ref target="https://www.zfdg.de">https://www.zfdg.de</ref>
</p>
</availability>
<biblScope unit="year">2022</biblScope>
<biblScope unit="artikel">005</biblScope>
</monogr>
</biblStruct>
</title>
</titleStmt>
<editionStmt>
<edition>Elektronische Ausgabe nach TEI P5</edition>
</editionStmt>
<publicationStmt>
<distributor>
<name>
<orgName>Herzog August Bibliothek Wolfenbüttel</orgName>
</name>
</distributor>
<idno type="doi">10.17175/zfdg.01</idno>
<idno type="ppn">0819494402</idno>
<authority>
<name>Herzog August Bibliothek</name>
<address>
<addrLine>Lessingplatz 1</addrLine>
<addrLine>38304 Wolfenbüttel</addrLine>
</address>
</authority>
<authority>
<name>Forschungsverbund Marbach Weimar Wolfenbüttel</name>
<address>
<addrLine>Burgplatz 4</addrLine>
<addrLine>99423 Weimar </addrLine>
</address>
</authority>
<availability status="free">
<p> Sofern nicht anders angegeben </p>
<licence target="http://creativecommons.org/licenses/by/4.0/">CC BY SA 4.0</licence>
</availability>
<availability status="free">
<p> Available at <ref target="workID">https://www.zfdg.de; (c)
Forschungsverbund MWW</ref>
</p>
</availability>
</publicationStmt>
<sourceDesc>
<p>Einreichung als Fachartikel in der ZfdG durch die Autor*innen</p>
</sourceDesc>
</fileDesc>
<encodingDesc>
<editorialDecl>
<p>Transformation der WORD-Vorlage nach XML/TEI-P5 durch TEI-Oxgarage und
XSLT-Skripten</p>
</editorialDecl>
<editorialDecl>
<p xml:lang="de">Lektorat des Textes durch die Redaktion in Person von <persName>Martin Wiegand</persName>.</p>
<p>Medienrechte liegen bei den Autor*innen</p>
<p>All links checked<date when="2022">03.08.2022</date>
</p>
</editorialDecl>
</encodingDesc>
<profileDesc>
<creation>Einreichung als Artikel der Zeitschrift für digitale
Geisteswissenschaften</creation>
<langUsage>
<language ident="de">Text in Deutsch</language>
<language ident="de">Abstract in Deutsch</language>
<language ident="en">Abstract in Englisch</language>
</langUsage>
<textClass>
<keywords scheme="gnd">
<term>Historische Geografie<ref target="4025103-2"/>
</term>
<term>Cluster-Analyse<ref target="4070044-6"/>
</term>
<term>Lokalisation<ref target="4195351-4"/>
</term>
<term>Kontextbezogenes System<ref target="4739720-2"/>
</term>
<term>Klassifikation<ref target="4030958-7"/>
</term>
</keywords>
</textClass>
</profileDesc>
<revisionDesc>
<change/>
</revisionDesc>
</teiHeader>
<text>
<body>
<div>
<div type="abstract">
<argument xml:lang="de">
<p>Viele historische Quellen enthalten zahlreiche Ortsangaben,
deren manuelle Zuordnung viele Ressourcen bindet. Um hier Abhilfe zu schaffen wird
ein Algorithmus beschrieben, mit dem solche Urbanonyme automatisiert geokodiert
werden können. Ebenso ist es möglich, die Orte entsprechend ihrer gemeinsamen
historischen Verwaltungszugehörigkeit zu clustern. Probleme wie gleiche Namen bei
Ortsbezeichnungen werden vor allem durch eine Einbeziehung weiterer Informationen
desselben Kontextes (derselben Quelle) gelöst. Eine Validierung geschieht anhand von
etwa 3,4 Millionen überwiegend deutschsprachigen Ortsangaben aus der genealogischen
Datenbank <hi rend="italic">GEDBAS</hi>. Zusammenfassend lassen sich etwa drei von
vier relevanten Ortsangaben identifizieren und lokalisieren. Über 90 Prozent der
identifizierten Ortsangaben können ihrer historischen Provinz zugeordnet werden.</p>
</argument>
<argument xml:lang="en">
<p>Many historical sources contain numerous names of places, the
manual assignment of which ties up a lot of resources. To simpliy this, an algorithm
is described with which such urbanonyms can be geocoded automatically. It is also
possible to cluster the places according to their common historical administrative
affiliation. Problems such as identical terms for place names are solved primarily
by including further information from the same context (same source). A validation
is done on the basis of about 3.4 million mostly German-language place names from
the genealogical database <hi rend="italic">GEDBAS</hi>. In summary, about three out
of four relevant place names can be identified and localised. More than 90 percent
of the identified place names can be assigned to their historical province.</p>
</argument>
</div>
<div type="chapter">
<head>1. Einleitung</head>
<p>Orte werden tagtäglich in vielen
Applikationen identifiziert und lokalisiert.<note type="footnote"> Die Identifizierung beschreibt die Zuordnung zu
einem Identifikator, der einem physischen Ort zugeordnet ist. Dagegen
umfasst die Lokalisierung die gelungene geographische Verortung des
identifizierten Ortes.</note> 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.</p>
<p>In Deutschland (und Europa) gibt es
beispielsweise zahlreiche Orte namens Neustadt. Allein 36 davon sind in der
Arbeitsgemeinschaft <term type="figure">Neustadt in Europa</term>
zusammengefasst.<note type="footnote"> <ref type="bibliography" target="#working-group_neustadt_2021">Working Group Neustadt in Europa (Hg.) 2021</ref>.</note> 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.<note type="footnote"> <ref type="bibliography" target="#zedlitz_survey_2014">Zedlitz / Luttenberger 2014</ref>, S. 218–231.</note> 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<note type="footnote"> Der Begriff der Urbanonyme
beschreibt dabei Siedlungsstrukturen (z. B. Städte, Dörfer) und stellt somit
eine Unterkategorie der Toponyme da. Er wird im Folgenden synonym zum
Begriff der Ortsbezeichnung verwendet.</note> bezeichnet – also umso
größer. </p>
<p>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.<note type="footnote"> Die Bestimmung der
Position wird heute oftmals satellitengestützt realisiert (vgl. <ref type="bibliography" target="#gentile_techniques_2013">Gentile et al.
(Hg.) 2013</ref>). Diese Möglichkeit setzt voraus, dass das zu lokalisierende
Objekt (1.) bekannt ist und sich (2.) an der zu lokalisierenden Position
befindet. Historische Ortsangaben hingegen beschreiben Positionen von
(unbekannten) Objekten zu vergangenen Zeitpunkten. Deshalb sind moderne
Möglichkeiten der Lokalisierung auf diese Problematik nicht
anwendbar.</note> 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<note type="footnote"> Als <hi rend="italic">historische Ortsangaben</hi> werden im
Folgenden solche Bezeichnungen beschrieben, die in deutscher Sprache einen
Ort im deutschsprachigen Raum im Zeitfenster der Neuzeit beschreiben. In
Abgrenzung dazu finden Ortsbezeichnungen aus antiken und mittelalterlichen
Quellen keine Verwendung.</note> kontextsensitiv lokalisiert. Eine
Übersicht der Begriffliche ist in <ref type="graphic" target="#urbanonyme_2020_001">Abbildung 1</ref>
vorhanden.</p>
<p>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<note type="footnote">
Sie enthalten oftmals sehr viele Ortsangaben zu Lebensereignissen wie
Geburten oder Hochzeiten. GEDCOM-Dateien stellen dabei den gängigen Standard
im Austausch genealogischer Informationen dar (vgl. <ref type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 112;
<ref type="bibliography" target="#harviainen_genealogy_2018">Harviainen / Björk 2018</ref>). </note> aus der Datenbank <bibl>
<title type="desc">Genealogische Datenbasis</title>
</bibl> (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.<note type="footnote">
<ref type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 118.</note>
</p>
<p>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.</p>
<figure>
<graphic xml:id="urbanonyme_2020_001" url=".../medien/urbanonyme_2020_001.png">
<desc>
<ref target="#abb1">Abb. 1</ref>: Übersicht über Begrifflichkeiten und Zusammenhänge.

[Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_001"/>
</desc>
</graphic>
</figure>
</div>
<div type="chapter">
<head>2. Identifizierung und Lokalisierung von Urbanonymen</head>
<p>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.</p>
<p>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.</p>
<div type="subchapter">
<head>2.1 Kontextsensitive Entscheidungsfindung</head>
<p>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.<note type="footnote"> In dem Fall würde es
sich bei der Ortsangabe um ein Choronym, nicht um eine Urbanonym,
handeln.</note> 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.<note type="footnote"> <ref type="bibliography" target="#abowd_context-awareness_1999">Abowd / Dey 1999</ref>, S. 1, 3-4.</note> Systeme,
die diesen Kontext nutzen, werden als ›kontextsensitiv‹ bezeichnet.<note type="footnote"> <ref type="bibliography" target="#sitou_requirements_2009">Sitou 2009</ref>, S. 28,
123.</note> 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.<note type="footnote"> <ref type="bibliography" target="#rosemann_process_2006">Rosemann / Recker
2006</ref>, S. 149.</note> 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 zu ihnen verfügbaren
Kontextinformationen in der Entscheidungsfindung unterstützt.<note type="footnote"> <ref type="bibliography" target="#zheng_integrating_2019">Zheng et al. 2019</ref>, S.
2453.</note> Daneben ist eine eigenständige Entscheidung zwischen mehreren
konkreten Alternativen ohne menschliches Zutun auf Basis des Kontextes möglich. </p>
<p>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.</p>
<table>
<row>
<cell/>
<cell>Identifizierung korrekt</cell>
<cell>Identifizierung nicht korrekt</cell>
</row>
<row>
<cell>Identifizierung erfolgt</cell>
<cell>True
positive (TP)</cell>
<cell>False
positive (FP)</cell>
</row>
<row>
<cell>Identifizierung nicht erfolgt</cell>
<cell>True
negative (TN)</cell>
<cell>False
negative (FN)</cell>
</row>
<trailer xml:id="tab01">
<ref type ="intern" target="#tab1">Tab. 1</ref>: Konfusionsmatrix

zur Identifizierung von Ortsbezeichnungen in Anlehnung an Fawcett. [Fawcett 2006, S.

862]<ref type="graphic"
target="#urbanonyme_2020_t1"/>
</trailer>
</table>
<p>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,<note type="footnote"> <ref
type="bibliography" target="#feigenbaum_computers_1963">Feigenbaum / Feldman (Hg.) 1963</ref>, S. 6.</note> sie
dienen der Findung einer wahrscheinlich korrekten Lösung unter begrenztem Wissen und
wenig Zeit.<note type="footnote"> Vgl.
<ref
type="bibliography" target="#gigerenzer_heuristics_1999">Gigerenzer / Todd (Hg.) 1999</ref>, S. 147.</note> 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.</p>
<p>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: </p>
<list type="ordered">
<item>den Ort, an dem die Ortsangabe erstellt wurde, </item>
<item>eine Gebietszugehörigkeit und </item>
<item>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.<note type="footnote"> <ref
type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 36.</note>
</item>
</list>
<p>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. </p>
<p>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 von Namen 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.<note type="footnote"> <ref
type="bibliography" target="#gallagher_estimating_2008">Gallagher / Chen 2008</ref>.</note>
Wichtiger jedoch erscheint die regionale Dichte und Häufigkeit von Namen: Die
Verwendung von Nachnamen ist oftmals geografisch nicht gleichverteilt.<note type="footnote"> Vgl. <ref
type="bibliography" target="#seibicke_personennamen_1982">Seibicke 1982</ref>,
S. 148.</note> In <ref type="graphic" target="#urbanonyme_2020_002">Abbildung 2</ref> sind
beispielhaft die relative und absolute Verteilung des Nachnamens ›Hinse‹ abgebildet.
Es ist eine erhöhte Dichte im westfälischen Raum zu erkennen.<note type="footnote"> Die Karte wurde mit <ref target="https://geogen.stoepel.net/legacy.html?">Geogen</ref> erzeugt und basiert auf
etwa 35 Millionen Telefonbucheinträgen. Stöpel 2021b.</note> Demzufolge
ist also wahrscheinlicher, dass der Name in Kombination mit Orten im westfälischen
Raum genannt wird.</p>
<figure>
<graphic xml:id="urbanonyme_2020_002" url=".../medien/urbanonyme_2020_002.png">
<desc>
<ref target="#abb2">Abb. 2</ref>: Relative (links) und

absolute (rechts) Verteilung des Nachnamens Hinse. [Goldberg 2022, erstellt mit

Geogen Deutschland, Stöpel 2021a.]<ref type="graphic" target="#urbanonyme_2020_002"/>
</desc>
</graphic>
</figure>
<p>Auch bei der Vornamensgebung sind in
Deutschland regionale Unterschiede zu erkennen,<note type="footnote"> <ref
type="bibliography" target="#gesellschaft_vornamen_2019">Gesellschaft für deutsche Sprache e. V. (Hg.)
2019</ref>.</note> was teilweise auf unterschiedliche Präferenzen in der
Namensgebung verschiedener Konfessionen zurückzuführen ist.<note type="footnote"> Vgl. <ref
type="bibliography" target="#seibicke_personennamen_1982">Seibicke 1982</ref>, S.
150.</note>
</p>
</div>
<div type="subchapter">
<head>2.2 Suchalgorithmen und Ähnlichkeitsanalyse</head>
<p>Alle (vormals) existierenden Orte
können in einer Liste dargestellt werden. Sie stellen eine endliche Menge dar. Da es
jedoch hunderttausende Orte gibt (oder gab), von denen jeweils einer ausgewählt
werden soll, ist anzunehmen, dass die Auswahl eines Suchalgorithmus erhebliche
Auswirkung auf die Performance hat. Zur Suche in Listen existieren verschiedenste
Algorithmen, die oftmals an ihre jeweilige Anwendung angepasst werden. Da es sich
bei Ortsbezeichnungen um Zeichenketten handelt, sind hier insbesondere
String-Matching-Algorithmen relevant. Die Namen der Orte fungieren dabei als
Eigenschaft der Entität, die mit der Ortsbezeichnung verglichen werden kann.</p>
<p>Suchalgorithmen können grundlegend in
einfache und informierte Suchen unterteilt werden. Im Gegensatz zu den einfachen
Suchen ist bei den informierten Suchen ein Wissen über den Suchraum vorhanden.<note type="footnote"> Vgl. <ref
type="bibliography" target="#clarke_principles_2009">Clarke et al.
2009</ref>, S. 34.</note> Bei einer gegebenen Liste von Orten findet ein
einfaches Suchverfahren Verwendung, bei der Auswahl eines Suchalgorithmus sind
dagegen insbesondere Laufzeit und Genauigkeit von Interesse: Während bei einer
linearen Suche in Listen jedes Element betrachtet werden muss, ist bei der binären
Suche nur die logarithmische Anzahl von Vergleichen durchzuführen. Es zeigt sich,
dass bei der Verarbeitung vieler Urbanonyme soweit wie möglich auf lineare Suchen
verzichtet werden sollte; stattdessen ist der Einsatz binärer Suchalgorithmen
angebracht. Hierzu ist vorbereitend eine alphabetische Sortierung möglicher Zielorte
durchzuführen.</p>
<p>Ortsbezeichnungen können jedoch
Rechtschreibfehler wie vertauschte Zeichen aufweisen. Ebenso kann die Schreibweise
von Orten im Zeitverlauf einer Variation unterliegen, ohne dass eine gänzliche
Umbenennung erfolgt ist. Auch wenn die Suche keine eindeutigen Treffer hervorbringt,
kann über einen Vergleich der Ähnlichkeit eine Identifizierung erfolgen. Zum
Vergleich der Ähnlichkeit gibt es verschiedene Maße. Ein übliches Maß stellt die
Levenshtein-Distanz dar, eine Metrik, mit der Schritte der Veränderung zwischen
Wörtern gezählt werden.<note type="footnote"> <ref
type="bibliography" target="#levenstejn_codes_1966">Levenštejn 1966</ref>.</note> Die Distanz ist bei
identischen Zeichenketten 0 und beträgt maximal die Länge des längeren Strings. Hier
besteht die Herausforderung, einen Wert auszuwählen, der für den jeweiligen
Vergleich als plausibel gilt,<note type="footnote"> Es sind keine allgemein üblichen Toleranzkriterien bei
dem Vergleich von Ortsstrings bekannt. Möglicherweise ist eine solche Art
der Ähnlichkeitsanalyse bei Orten nicht besonders zielführend, da viele Orte
sehr gleichklingend sind und eine Levenshtein-Distanz von 2 bereits
wesentliche Veränderungen herbeiführen kann.</note> wobei ein Bezug auf
die Länge der gesuchten Zeichenkette angebracht sein kann.<note type="footnote"> Vgl. <ref
type="bibliography" target="#list_distanz_2010">List 2010</ref>, S.
8.</note>
</p>
<p>Statt in einer Liste können Orte auch
in Bäumen strukturiert sein. Zur Optimierung des Suchverhaltens in diesen ist ein
informierter Ansatz möglich, der beispielsweise nur solche Pfade mit definierten
Eigenschaften durchsucht.</p>
</div>
<div type="subchapter">
<head>2.3 Historische Orte und Urbanonyme</head>
<p>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 <bibl>
<title type="desc">Geschichtliche Orts-Verzeichnis</title>
</bibl> (GOV) des Vereins
für Computergenealogie Verwendung finden.<note type="footnote"> Das GOV ist nicht das einzige Verzeichnis, dass
historische Ortsangaben zusammengeführt. Daneben gibt es verschiedene
Ortslexika. Ein online-verfügbares Beispiel stellt das <ref target="https://hov.isgv.de/">Historische
Ortsverzeichnis von Sachsen</ref> dar (vgl. <ref
type="bibliography" target="#institut_ortsverzeichnis_2020">Institut für sächsische
Geschichte und Volkskunde (Hg.) 2020</ref>). Für den gesamten deutschsprachigen
Raum ist das GOV jedoch die einzige digitale, klar strukturierte Sammlung
historischer Ortsangaben. Zudem unterliegt das Mini-GOV einer Creative
Common Lizenz und kann deshalb in diesem Rahmen Verwendung
finden.</note> Dieses enthält etwa 1,2 Millionen Objekte<note type="footnote"> Diese Objekte sind jeweils
sogenannten Typen zugeordnet. Die Typen beschreiben nicht nur Urbanonyme,
sondern auch politische, kirchliche oder gerichtliche Verwaltungen; auch
geographische Objekte oder solche zum Verkehrswesen sind
vorhanden.</note> in Europa.<note type="footnote"> <ref
type="bibliography" target="#verein_gov_2015">Verein für Computergenealogie e. V. (Hg.) 2015</ref>. Das
GOV erscheint insbesondere für den deutschsprachigen Raum geeignet.
</note> Das GOV wird ausgewählt, weil es besonders im deutschsprachigen Raum
viele historische Urbanonyme abbildet. Für andere Länder, beispielsweise die
Niederlanden, gibt es zudem weitere ausführliche Portale.<note type="footnote"> Vgl. <ref
type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S.
24.</note>
</p>
<p>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 <term type="dh">Uniform Resource Identifier</term> (URI) eines Ortes dient die sogenannte
GOV-Kennung. Daneben ist der Typ des Objekts vorhanden, gefolgt von dem aktuellen
Namen (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.<note type="footnote"> Die administrative Zuordnung unterscheidet sich je
nach heutigem Staat. In Deutschland ist die adm. Zuordnung 1 auf das
Bundesland bezogen, die adm. Zuordnung 2 auf den Regierungsbezirk, die adm.
Zuordnung 3 auf den Kreis, Landkreis, Stadtkreis die kreisfreie Stadt oder
die Region und die adm. Zuordnung 4 auf die Stadt, Gemeinde, den Markt oder
Flecken.</note> Zudem ist die Postleitzahl vorhanden. Abschließend
folgen mit der Längen- und Breitengrade 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 <ref type="graphic" target="#urbanonyme_2020_003">Abbildung 3</ref>).<note type="footnote"> <ref
type="bibliography" target="#verein_gazetteer_2021a">Verein für Computergenealogie e.
V. (Hg.) 2021a</ref>.</note> 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 <ref type="graphic" target="#urbanonyme_2020_003">Abbildung 3</ref>
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.</p>
<figure>
<graphic xml:id="urbanonyme_2020_003" url=".../medien/urbanonyme_2020_003.png">
<desc>
<ref target="#abb3">Abb. 3</ref>: Auszug aus einer

GOV-Abfrage. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_003"/>
</desc>
</graphic>
</figure>
<p>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 (Namen, 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 <ref type="graphic" target="#urbanonyme_2020_004">Abbildung 4</ref>). Verschiedenartige Informationen werden dabei mit
verschiedenen Tags gekennzeichnet. Standardmäßig definiert der Tag <code>PLAC</code> dabei eine Ortsangabe.<note type="footnote"> Neben dem Standard können
einzelne programmspezifische Tags entwickelt werden. Diesen ist ein
Unterstrich (›_‹) vorangestellt. So ist es prinzipiell möglich, weitere
ortsbezogene Tags zu entwickeln und anzuwenden. Hervorzuheben ist hierbei
insbesondere der Tag <code>_LOC</code>, über den ein eigener
Datensatz zu der Ortsangabe erstellt wird. Darin können u. a. Tags wie <code>_GOV</code> genutzt werden, über welchen direkt die
GOV-URI zugeordnet wird. Über die Tags <code>LATI</code> und
<code>LONG</code> können zudem seit der GEDCOM-Version
5.5.1 direkt Koordinatenangaben gemacht werden (vgl. <ref
type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 118).
In der Validierung werden diese Tags nochmals aufgegriffen.</note> Diese
kann sich auf die oben genannten Ereignisse beziehen. Im Beispiel ist sie dem Tag
<code>DEAT</code> 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.<note type="footnote"> <ref
type="bibliography" target="#gellatly_reconstructing_2015">Gellatly 2015</ref>, S. 117.</note>
</p>
<figure>
<graphic xml:id="urbanonyme_2020_004" url=".../medien/urbanonyme_2020_004.png">
<desc>
<ref target="#abb4">Abb. 4</ref>: Auszug einer
GEDCOM-Datei. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_004"/>
</desc>
</graphic>
</figure>
</div>
</div>
<div type="chapter">
<head>3. Entwicklung des (heuristischen) Algorithmus</head>
<p>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.</p>
<div type="subchapter">
<head>3.1 Metaheuristik</head>
<p>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.<note type="footnote"> Die Metaheuristik beschränkt sich
bei der Hinzuziehung des Kontexts zur Identifizierung auf weitere
Ortsangaben. Eine Erläuterung für diese Auswahl ist in Abschnitt 3.4 zu
finden. Quellenspezifisch muss der Kontext jeweils definiert
werden.</note> 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 <hi rend="italic">eine</hi> exakte Übereinstimmung aufweisen,
identifiziert und in die Kontextdaten mit aufgenommen (siehe <ref type="graphic" target="#urbanonyme_2020_005">Abbildung 5</ref>). Neben den Bezeichnungen und der
GOV-ID werden zu den Kontextdaten auch die geographischen Koordinaten
gespeichert.</p>
<figure>
<graphic xml:id="urbanonyme_2020_005" url=".../medien/urbanonyme_2020_005.png">
<desc>
<ref target="#abb5">Abb. 5</ref>: Ermittlung und Bewertung von Kontextdaten, eigene Darstellung als Nassi-Sneiderman-Diagramm.[Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_005"/>
</desc>
</graphic>
</figure>
<p>Mit Hilfe der nun ermittelten
Kontextdaten können im zweiten Teil weitere Ortsangaben identifiziert werden (siehe
<ref type="graphic" target="#urbanonyme_2020_006">Abbildung 6</ref>): Bei mehreren
Übereinstimmungen mit dem Mini-GOV wird geprüft, ob für die zu überprüfende
Ortsangabe Kontextdaten zur Verfügung stehen.<note type="footnote"> Es kann sein, dass der Kontext so einen geringen
Umfang hat, dass die vorhergehende Ermittlung der Kontextdaten kein Ergebnis
brachte. Das ist hier konkret der Fall, wenn keine weiteren Ortsangaben
vorliegen.</note> 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.</p>
<p>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.</p>
<figure>
<graphic xml:id="urbanonyme_2020_006" url=".../medien/urbanonyme_2020_006.png">
<desc>
<ref target="#abb6">Abb. 6</ref>: Ortsidentifizierung, eigene Darstellung als Nassi-Sneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_006"/>
</desc>
</graphic>
</figure>
<p>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 <ref type="graphic" target="#urbanonyme_2020_007">Abbildung 7</ref>). 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.<note type="footnote">
Liste A und B dienen der Priorisierung weiterer Schritte. Falls die Liste A
kein Element enthält, ist kein übergeordnetes Objekt zeitlich exakt passend.
Das kann u. a. daran liegen, dass das GOV nicht vollständig gepflegt ist
oder aber ein Objekt erst nach der Bezugszeit entstanden ist und deswegen
keine Zugehörigkeit zur Bezugszeit bestehen kann. Nur im Falle einer leeren
Liste A wird mit der Liste B weiter verfahren.</note> 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.</p>
<figure>
<graphic xml:id="urbanonyme_2020_007" url=".../medien/urbanonyme_2020_007.png">
<desc>
<ref target="#abb7">Abb. 7</ref>: Analyse der provinziellen Zuordnung, eigene Darstellung als Nassi-Sneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_007"/>
</desc>
</graphic>
</figure>
</div>
<div type="subchapter">
<head>3.2 Datenbereinigung</head>
<p>Da es denkbar ist, dass
Ortsbezeichnungen systematische Fehler enthalten, ist eine grundsätzliche
Bereinigung der Daten angebracht.<note type="footnote"> Je nach Ermittlung der Bezeichnungen sind dabei andere
Fehler denkbar. So wird eine automatisierte Texterkennung andere Fehler
machen als ein Mensch.</note> Der Algorithmus sollte auf die jeweils
auftretenden systematischen Fehler der Quelle spezifisch angepasst werden. Die
Veränderung der Ortsbezeichnungen ist dabei nicht unkritisch, da mit dieser eine
Interpretation der Daten einhergeht. Auf große Datenmengen angewendet kann es bei
verallgemeinerten Korrekturregeln zu vermehrten Fehlinterpretationen kommen (FP). An
dieser Stelle werden darum nur allgemeine Fehler abgedeckt (zum Beispiel die
Entfernung von Sonderzeichen oder sonstiger unerwünschter Bestandteile). Spezifische
Regeln können vom Anwender jeweils ergänzt werden.</p>
</div>
<div type="subchapter">
<head>3.3 Suche</head>
<p>Grundlage der Suche eines passenden
Ortes sind die Angaben über Namen von Orten im Mini-GOV – und der (teilweisen)
Übereinstimmungen mit der gegebenen Ortsbezeichnung aus den Quellen. Das Mini-GOV
liegt als CSV-Datei für jeden heute existierenden
Staat vor. Aus diesem Grund müssen (neben dem Deutschland-Mini-GOV) weitere Länder,
in denen es vormals deutschsprachige Gebiete gab, integriert werden. Die einzelnen
Mini-GOVs werden zu einem gemeinsamen zusammengeführt. Dadurch ergibt sich eine
Liste mit mehreren Hunderttausend Orten. Zur Reduzierung der Suchdauer des
Algorithmus ist es hier wichtig, keine lineare Suche zu verwenden, sondern das
Mini-GOV vorher zu sortieren.<note type="footnote"> Beispielsweise bei einer GOV-Liste von 100.000 Orten
und 10.000 zu lokalisierenden Urbanonymen wären bei einer einfachen Suche
eine Milliarde einzelne Vergleiche durchzuführen.</note> Die Sortierung
ermöglicht den Einsatz einer binären Suche.<note type="footnote"> Diese wird so ausgeführt, dass zunächst der
mittlere Eintrag der sortierten Instanz des Mini-GOVs identifiziert wird.
Liegt die zu suchende Bezeichnung in alphabetischer Reihenfolge vor dem Ort,
der in der Mitte steht, wird in einem nächsten Durchlauf die Mitte der
vorderen alphabetischen Hälfte analysiert. Das wird so lange wiederholt, bis
die nächste Mitte nur noch 10 Positionen von der vorherigen entfernt ist. Da
es in einer alphabetischen Reihenfolge in einer Liste mehrere
aufeinanderfolgende Treffer geben kann, ist eine vollständige Ausführung der
binären Suche nicht angebracht. Diese würde nur ein Element zum Resultat
haben. Aus diesem Grund werden die 30 Positionen vor und 30 Positionen nach
der letzten ermittelten Mitte zusätzlich linear durchsucht. Das liegt darin
begründet, dass kein einzelner Ortsname mehr als 30 Mal im GOV
vorkommt.</note> Die Suche kann drei Ergebnisse hervorbringen:</p>
<list type="unordered">
<item>Kein Treffer: Es gibt keinen Wert im definierten Bereich des Mini-GOVs, der
genau der bereinigten Ortsbezeichnung entspricht.</item>
<item>Genau ein Treffer: Es gibt nur einen Wert im definierten Bereich des
Mini-GOVs, der genau der bereinigten Ortsbezeichnung entspricht.</item>
<item>Viele Treffer: Es gibt mehr als einen Wert im definierten Bereich des
Mini-GOVs, der genau der bereinigten Ortsbezeichnung entspricht.</item>
</list>
<p>Bei genau einem Treffer wird eben
dieser ausgewählt. In den anderen beiden Fällen ist eine weitere Analyse notwendig.
Beim Ausbleiben eines Treffers werden ähnliche Zeichenketten gesucht, da u. a.
Tippfehler in den Ortsbezeichnungen eine genaue Übereinstimmung verhindern. Im Fall
mehrerer Treffer wird der Kontext der Ortsangabe zur weiteren Identifikation
herangezogen (siehe <ref type="intern" target="#hd10">Abschnitt 3.4</ref>).</p>
<p>Wird keine genaue Übereinstimmung
zwischen Ortsbezeichnung und dem Namen eines Ortes im Mini-GOV gefunden, kann eine
teilweise Übereinstimmung bei der Identifizierung helfen. Eine Berechnung zwischen
der Ähnlichkeit aller Namen im GOV und der zuzuordnenden Ortsbezeichnung ist vor dem
Hintergrund der Rechenkapazität nicht erstrebenswert. Aus diesem Grund werden
lediglich die Orte verglichen, die zuvor schon eingegrenzt wurden.<note type="footnote"> Das führt dazu, dass Fehler bei
anfänglichen Buchstaben nicht erkannt werden. Die Vorteile durch die
schnellere Suche scheinen jedoch für die praktische Durchführung wichtiger
zu sein.</note> Zum Vergleich von Strings existieren, wie in <ref type="intern" target="#hd4">Abschnitt 2.2</ref> erörtert, verschiedene
Distanzmaße.<note type="footnote">
Zandhuis et al. empfehlen zwar initial die Levenshtein-Distanz, bei mehreren
Treffern sollte jedoch ein Vergleich der geographischen Entfernung
vorgenommen werden. <ref
type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 37.</note> Die Verwendung
unterschiedlicher Distanzmaße wird im <ref type="intern" target="#hd13">Abschnitt 5.
Validierung</ref> diskutiert.</p>
</div>
<div type="subchapter">
<head>3.4 Kontextdaten</head>
<p>Ansatzpunkte zur Ermittlung der
Kontextdaten können sich aus der Quelle der zu lokalisierenden Ortsangabe ergeben.
Als Kontext für eine Bezeichnung in einem Buch kann so unter Umständen das ganze
Buch dienen. Wie in <ref type="intern" target="#hd3">Abschnitt 2.1</ref> gezeigt, gibt es
verschiedene Informationen im Kontext von Ortsbezeichnungen (insbesondere andere
Ortsbezeichnungen, Vor- und Nachnamen, Zeitangaben). Im Weiteren werden
ausschließlich die anderen Ortsangaben als Kontextangaben genutzt. Der Ausschluss
von Vor- und Familiennamen sowie Zeitangaben geschieht vor dem Hintergrund, dass zu
den Namen einerseits keine Studie zur geografischen Verteilung ab dem 17.
Jahrhundert existiert,<note type="footnote"> Allenfalls gibt es solche Betrachtungen für einzelne
Regionen oder bestimmte Namen, beispielsweise in der Verteilung
verschiedener Schreibweisen des Namens ›Mayer‹ (vgl. <ref type="bibliography" target="#hohensinner_name_2011">Hohensinner 2011</ref>).</note>
andererseits wird die geographische Zuordnung von Vornamen mit zunehmender Zeit
unschärfer.<note type="footnote"> Die
Namensgebung passiert heute in Deutschland weniger formalisiert als noch vor
100 Jahren, sondern bietet mehr individuelle Freiheiten (u. a. eine deutlich
größere Variation der Vornamen).</note> Eine fehlende Übersicht zur
Veränderung der Ortsnamen im Zeitverlauf führt dazu, dass auch der temporale Aspekt
nicht weiter herangezogen wird. Zudem betrifft die Veränderung der Bezeichnung
innerhalb der Neuzeit nur einen kleinen Teil der Orte. Dagegen sind weitere
Ortsangaben als Kontext besonders geeignet, vor allem wenn eine Dichte Nennung von
Orten erfolgt. Bei einer Ortsangabe in einem Buch, in dem der nächste Ort erst 200
Seiten später genannt wird, ist der Kontext hingegen zur Identifizierung
voraussichtlich nicht geeignet. Sind in einer Quelle auf 20 Seiten aber 200
Ortsangaben, erscheint es wahrscheinlicher, dass diese in einer inhaltlichen
Beziehung zueinander stehend genannt werden.<note type="footnote"> Auch diese Aussage ist nicht allgemeingültig: In
einer alphabetisch sortierten Ortsliste ist das nicht der Fall.</note>
Vor der Anwendung dieses Algorithmus sollten eine Quelle und ihr Kontext dahingehend
begutachtet werden.</p>
<p>Eine Eigenschaft dieser Vorgehensweise
ist, dass Ortsangaben, sollen sie als Kontext zur Identifizierung anderer
Ortsangaben genutzt werden, selbst zunächst einmal identifiziert werden müssen. Aus
diesem Grund werden alle Ortsangaben zunächst auf Übereinstimmung mit dem Mini-GOV
geprüft. Die Ortsangaben, bei denen eine eindeutige Zuordnung zu einem Eintrag im
Mini-GOV vorgenommen werden kann, bilden die Kontextdaten. Hier wird deutlich, dass
nur ein Teil der Ortsangaben in die Kontextdaten eingeht.</p>
<p>Um anhand der Kontextdaten nun eine
Auswahl zwischen verschiedenen Orten zu treffen, ist die geographische Nähe das
wesentliche Kriterium. Den Grundgedanken, dass die <quote>geographical unit that has the smallest geographic distance to the place of
origin</quote> für die Zuordnung von Ortsangaben genutzt werden kann, hatten
bereits Zandhuis et al.<note type="footnote"> <ref type="bibliography" target="#zandhuis_toponyms_2015">Zandhuis et al. 2015</ref>, S. 37.</note> Wobei der <quote>place of origin</quote> in dem Fall der Entstehungsort der Quelle
der Ortsangabe ist, der (1.) selten vorliegen dürfte und (2.) auch erstmal
identifiziert werden müsste. Der Ansatz hingegen, andere Ortsangaben desselben
Kontextes zu nutzten, ist neu und basiert auf der Annahme, dass zusammen genannte
Orte oftmals auch nah beieinanderliegen. Insbesondere bei genealogischen Quellen
trifft diese Annahme zu. So werden oftmals Ehepartner
aus einer engeren räumlichen Entfernung gewählt.<note type="footnote"> Vgl. <ref type="bibliography" target="#kocka_familie_1980">Kocka et al. 1980</ref>.</note>
Oftmals wurden auch Ehepartner aus dem gleichen Ort gewählt.<note type="footnote"> Vgl. <ref type="bibliography" target="#baehr_bevoelkerungsgeographie_1992">Bähr et al. 1992</ref>.</note> Ein
hoher Anteil der Bevölkerung war lange nur sehr eingeschränkt mobil. Diese Methodik
ist also insbesondere geeignet für Urbanonyme, die zusammen mit Personen genannt
werden (beispielsweise in prosopografischen Quellen). Weniger geeignet ist sie für
Quellen, bei denen die Orte eindeutig in keinem räumlichen Zusammenhang stehen (z.
B. eine alphabetische Liste aller Städte).</p>
<p>Zu jedem Ort in den Kontextdaten
liegen durch das Mini-GOV Koordinaten vor. Das geographische Mittel<note type="footnote"> Es gibt keine
allgemeingültige Norm des geographischen Mittels, da neben den Koordinaten
beispielsweise die Topographie in die Gewichtung mit einfließen kann. An
dieser Stelle wird das arithmetische Mittel jeweils von Längen- und
Breitengrad genutzt.</note> dieser Orte stellt dabei eine Position dar,
die zu allen anderen Orten durchschnittlich die geringste Distanz hat. In dieser
Vorgehensweise wird ein weiterer Nachteil ersichtlich: Die Quelle kann Orte
enthalten, die geografisch sehr weit voneinander entfernt sind. Wenn diese sich
nicht gleichflächig über den Raum verteilen (wovon auszugehen ist), können sich
verschiedene Räume mit einer großen Dichte an Datenpunkten ausbilden.<note type="footnote"> Eine alternative
Idee ist es aus diesem Grund, nicht alle Orte in die Kontextdaten einfließen
zu lassen, sondern vormals nochmal zu selektieren. Bei genealogischen Daten
könnten z. B. nur die Orte der Personen, die eine nahe verwandtschaftliche
Verknüpfung aufweisen, einbezogen werden. Die Verwandtschaftsbeziehungen
stellen weitere Kontextdaten dar. Die wenigsten historischen Quellen
verfügen jedoch speziell über diese Kontextdaten. Aus diesem Grund findet
dieser Aspekt keine Anwendung.</note> Die geographische Mitte würde in
keinem dieser Ballungsgebiete liegen. Hierbei schafft die Bildung dezentraler
Cluster<note type="footnote"> Diese
Bildung von Cluster aus den Kontextdaten ist nicht mit der (späteren)
Clusterung der identifizierten Orte entsprechen ihrer regionalen
Zusammengehörigkeit identisch. Vielmehr dürfen diese nicht verwechselt
werden. In beiden Fällen wird geclustert, weshalb der Begriff derselbe ist.
Zur Unterscheidung ist ein genauer Blick auf den Zusammenhang zu werfen, in
dem der Begriff verwendet wird.</note> Abhilfe. Die Validierung wird
zeigen, welche praktischen Auswirkungen diese Art der Clusterung mit sich
bringt.</p>
<p>Für den Fall, dass keine Kontextdaten
vorhanden sind, jedoch trotzdem eine Auswahl zwischen verschiedenen Orten
stattfinden soll, ist eine alternative Entscheidungsfindung zu definieren. So kann –
unter Hinzuziehung weiterer Heuristiken – auf die Wahrscheinlichkeit für die
Zugehörigkeit eines Urbanonyms zu einem bestimmten Ort geschlossen werden. Wenn z.
B. gleichnamig eine Stadt und ein kleiner Weiler mit demselben Namen existieren,
dann ist es wahrscheinlicher, dass die Stadt gemeint ist. Dahinter wiederum verbirgt
sich die Annahme, dass mehr Menschen in einer Stadt als in einer kleinen Ansammlung
von Häusern gelebt haben. Diese Unterscheidung wird durch die Objekttypen im
Mini-GOV ermöglicht. Dazu wird folgende Reihenfolge definiert: </p>
<list type="ordered">
<item>Kreisfreie Stadt</item>
<item>Stadt</item>
<item>Dorf</item>
<item>Pfarrdorf</item>
<item>Ort</item>
<item>Ortsteil</item>
<item>Ortschaft</item>
<item>Wohnplatz</item>
<item>Weiler </item>
</list>
<p>Sollten zwei Orte gleichen Objekttyps
übrigbleiben, ist eine Identifizierung fehlgeschlagen.</p>
</div>
<div type="subchapter">
<head>3.5 Clusterung zur historischen administrativen Zugehörigkeit</head>
<p>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 <ref type="graphic" target="#urbanonyme_2020_008">Abbildung 8</ref>). 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.<note type="footnote"> Vgl. <ref type="bibliography" target="#fertig_zeitalter_2018">Fertig et al.
2018</ref>.</note> Für einen möglichen Bezug auf die heute existierende
Gliederung werden die sechzehn Bundesländer Deutschlands genutzt.<note type="footnote"> Beispiel: Bei einem Interesse an
der Zuordnung Dresdens wäre im Jahr 2000 der Freistaat Sachsen korrekt
(GOV-Objekt ›object_218149‹), 1850 aber beispielsweise das Königreich
Sachsen (GOV-Objekt ›object_218149‹).</note> 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 <ref type="graphic" target="#urbanonyme_2020_t2">Tabelle
2</ref>). Weitere Regionen – oder eine detailliertere Skalierung der möglichen
Cluster (u. a. Kreise, Regierungsbezirke) – können bei Bedarf implementiert
werden.</p>
<figure>
<graphic xml:id="urbanonyme_2020_008" url=".../medien/urbanonyme_2020_008.png">
<desc>
<ref target="#abb8">Abb. 8</ref>: GOV-Struktur der Stadt <ref target="http://gov.genealogy.net/item/show/object_113700">Wiedenbrück</ref>, Stand: 30. Januar 2021. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_008"/>
</desc>
</graphic>
</figure>
<table>
<row>
<cell>Provinz<note type="footnote"> Die mit A angeführten Provinzen sind Preußen zugehörig, dem mit
dem B stellen weitere Territorien dar.</note>
</cell>
<cell>GOV-Identikator</cell>
<cell>Bemerkung</cell>
</row>
<row>
<cell>ab hier Bezugszeit
<= 1871</cell>
</row>
<row>
<cell>A 01 Provinz Holstein</cell>
<cell>object_190122</cell>
<cell/>
</row>
<row>
<cell>A 02 Provinz Lauenburg</cell>
<cell>adm_131053</cell>
<cell/>
</row>
<row>
<cell>A 03 Provinz Brandenburg (ohne
Berlin)</cell>
<cell>object_1081716</cell>
<cell/>
</row>
<row>
<cell>A 04 Provinz
Hessen-Nassau</cell>
<cell>object_190330</cell>
<cell/>
</row>
<row>
<cell>A 05 Provinz
Hohenzollern</cell>
<cell>object_268785</cell>
<cell/>
</row>
<row>
<cell>A 05 Provinz
Hohenzollern</cell>
<cell>object_284443</cell>
<cell>Hohenzollern-Sigmaringen 1850
nach Hohenzollerschen Landen</cell>
</row>
<row>
<cell>A 06 Provinz Ostpreußen</cell>
<cell>adm_368500</cell>
<cell/>
</row>
<row>
<cell>A 07 Provinz Pommern</cell>
<cell>adm_368480</cell>
<cell/>
</row>
<row>
<cell>A 08 Provinz Posen</cell>
<cell>object_211667</cell>
<cell/>
</row>
<row>
<cell>A 09 Provinz Sachsen</cell>
<cell>object_279654</cell>
<cell/>
</row>
<row>
<cell>A 10 Provinz Schlesien</cell>
<cell>adm_368470</cell>
<cell/>
</row>
<row>
<cell>A 11 Provinz Westfalen</cell>
<cell>object_190325</cell>
<cell/>
</row>
<row>
<cell>A 12 Provinz Westpreußen</cell>
<cell>object_213750</cell>
<cell/>
</row>
<row>
<cell>A 13 Rheinprovinz</cell>
<cell>object_1047283</cell>
<cell>Provinz Jülich-Kleve-Berg bis
1822</cell>
</row>
<row>
<cell>A 13 Rheinprovinz</cell>
<cell>object_405464</cell>
<cell>Provinz Großherzogtum
Niederrhein bis 1822</cell>
</row>
<row>
<cell>A 13 Rheinprovinz</cell>
<cell>object_190337</cell>
<cell/>
</row>
<row>
<cell>A 14 Provinz Berlin</cell>
<cell>BERLINJO62PM</cell>
<cell/>
</row>
<row>
<cell>B 01 Amt Bergedorf</cell>
<cell>object_257607</cell>
<cell/>
</row>
<row>
<cell>B 02 Hansestadt Bremen</cell>
<cell>adm_369040</cell>
<cell/>
</row>
<row>
<cell>B 03 Stadt Hamburg</cell>
<cell>adm_369020</cell>
<cell/>
</row>
<row>
<cell>B 04 Stadt Lübeck</cell>
<cell>LUBECKJO53IU</cell>
<cell/>
</row>
<row>
<cell>B 05 Stadt Frankfurt am
Main</cell>
<cell>adm_136412</cell>
<cell/>
</row>
<row>
<cell>B 06 Fürstentum
Lippe-Detmold</cell>
<cell>object_217406</cell>
<cell/>
</row>
<row>
<cell>B 07 Fürstentum
Schaumburg-Lippe</cell>
<cell>object_217818</cell>
<cell/>
</row>
<row>
<cell>B 08 Fürstentum
Waldeck-Pyrmont</cell>
<cell>object_218152</cell>
<cell/>
</row>
<row>
<cell>B 09 Großherzogtum
Oldenburg</cell>
<cell>object_352387</cell>
<cell/>
</row>
<row>
<cell>B 10 Großherzogtum Baden</cell>
<cell>object_217952</cell>
<cell/>
</row>
<row>
<cell>B 11 Hessen</cell>
<cell>object_218147</cell>
<cell/>
</row>
<row>
<cell>B 12 Großherzogtum
Mecklenburg-Schwerin</cell>
<cell>object_217750</cell>
<cell/>
</row>
<row>
<cell>B 13 Großherzogtum
Mecklenburg-Strelitz (einschließlich des Fürstentums Ratzeburg)</cell>
<cell>object_217749</cell>
<cell/>
</row>
<row>
<cell>B 14 Herzogtum Anhalt</cell>
<cell>object_190873</cell>
<cell/>
</row>
<row>
<cell>B 15 Herzogtum
Braunschweig</cell>
<cell>object_217954</cell>
<cell/>
</row>
<row>
<cell>B 16 Herzogtum Nassau</cell>
<cell>object_218153</cell>
<cell/>
</row>
<row>
<cell>B 17 Herzogtum Schleswig</cell>
<cell>object_190098</cell>
<cell/>
</row>
<row>
<cell>B 18 Königreich
Württemberg</cell>
<cell>object_190729</cell>
<cell/>
</row>
<row>
<cell>B 19 Königreich Bayern</cell>
<cell>object_217953</cell>
<cell/>
</row>
<row>
<cell>B 20 Königreich Hannover</cell>
<cell>object_190327</cell>
<cell/>
</row>
<row>
<cell>B 21 Königreich Sachsen</cell>
<cell>object_218149</cell>
<cell/>
</row>
<row>
<cell>B 22 Kurfürstentum
Hessen</cell>
<cell>object_275299</cell>
<cell/>
</row>
<row>
<cell>B 23 Landgrafschaft
Hessen-Homburg</cell>
<cell>object_284442</cell>
<cell/>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218143</cell>
<cell>Sachsen-Weimar-Eisenach</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_284441</cell>
<cell>Reuß Jüngere Linie</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218134</cell>
<cell>Reuß Ältere Linie</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218137</cell>
<cell>Sachsen-Altenburg</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218138</cell>
<cell>Sachsen-Coburg-Gotha</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_265487</cell>
<cell>Sachsen Gotha</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218142</cell>
<cell>Sachsen-Meiningen</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218150</cell>
<cell>Schwarzburg-Rudolstadt</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218151</cell>
<cell>Schwarzburg-Sondershausen</cell>
</row>
<row>
<cell>B 24 Thüringische
Staaten</cell>
<cell>object_218141</cell>
<cell>Sachsen-Hildburghausen</cell>
</row>
<row>
<cell>ab hier Bezugszeit
>= 1990</cell>
</row>
<row>
<cell>Land Baden-Württemberg</cell>
<cell>adm_369080</cell>
<cell/>
</row>
<row>
<cell>Freistaat Bayern</cell>
<cell>adm_369090</cell>
<cell/>
</row>
<row>
<cell>Land Berlin<note type="footnote"> Berlin heute stellt das
gleiche GOV-Objekt dar wie bei der historischen Klassifizierung.
Insofern wir hier die Bezeichnung <hi rend="italic">A 14
Provinz Berlin</hi> und nicht <hi rend="italic">Land
Berlin</hi> ausgegeben.</note>
</cell>
<cell>BERLINJO62PM</cell>
<cell/>
</row>
<row>
<cell>Land Brandenburg</cell>
<cell>adm_369120</cell>
<cell/>
</row>
<row>
<cell>Freie Hansestadt Bremen</cell>
<cell>adm_369040</cell>
<cell/>
</row>
<row>
<cell>Freie und Hansestadt
Hamburg</cell>
<cell>object_1259992</cell>
<cell/>
</row>
<row>
<cell>Land Hessen</cell>
<cell>adm_369060</cell>
<cell/>
</row>
<row>
<cell>Land
Mecklenburg-Vorpommern</cell>
<cell>adm_369130</cell>
<cell/>
</row>
<row>
<cell>Land Niedersachsen</cell>
<cell>adm_369030</cell>
<cell/>
</row>
<row>
<cell>Land Nordrhein-Westfalen</cell>
<cell>adm_369050</cell>
<cell/>
</row>
<row>
<cell>Land Rheinland-Pfalz</cell>
<cell>adm_369070</cell>
<cell/>
</row>
<row>
<cell>Saarland</cell>
<cell>adm_369100</cell>
<cell/>
</row>
<row>
<cell>Freistaat Sachsen<note type="footnote"> Hier besteht
die gleiche Situation wie bei Berlin (siehe vorherige
Fußnote).</note>
</cell>
<cell>object_218149</cell>
<cell/>
</row>
<row>
<cell>Land Sachsen-Anhalt</cell>
<cell>adm_369150</cell>
<cell/>
</row>
<row>
<cell>Land Schleswig-Holstein</cell>
<cell>adm_369010</cell>
<cell/>
</row>
<row>
<cell>Freistaat Thüringen</cell>
<cell>adm_369160</cell>
<cell/>
</row>
<trailer xml:id="tab02">
<ref type="intern" target="#tab2">Tab. 2</ref>: Zuordnung von Provinzen zum GOV. [Goldberg 2022]<ref type="graphic"
target="#urbanonyme_2020_t2"/>
</trailer> </table>
<p>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).<note type="footnote"> Die
Nähe der Grenzen zur Bezugszeit ist auch in dem seltenen Fall das Kriterium,
in dem mehrere übergeordnete Objekte in der Bezugszeit liegen.</note>
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<note type="footnote"> Objekte können im Zeitverlauf verschiedenen Typen
unterliegen, dieser Umstand wird nicht weiter betrachtet, weil sich die
Objektkategorie nicht ändert. Ein Dorf kann beispielsweise zur Stadt werden,
eine Kirche aber nicht zur Stadt.</note> aufweisen oder nur im
nicht-deutschsprachigen Raum vorkommen, werden ausgeschlossen.<note type="footnote"> Beispielsweise bei dem Objekt
›NEUTE1JO44XB‹ gibt es zwei übergeordnete Objekte ohne zeitliche Angaben.
Hier erfolgt jedoch eine konkrete Zuordnung zu dem Objekt, das keinen
kirchlichen Typ aufweist.</note> 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.<note type="footnote">
Eine Alternative dazu wäre eine klassische Tiefen- oder Breitensuche.
Hierbei würden alle Zweige des Baumes analysiert, bis ein Objekt der
Zielmenge gefunden wird. Das ist vor dem Hintergrund von Laufzeitaspekten
ungünstig, da dazu sehr oft auf das nur online verfügbare GOV zugegriffen
werden müsste und die Internet-Schnittstelle zu einer Verlängerung der
Durchlaufzeit führte.</note>
</p>
<p>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.</p>
<p>Dieser Algorithmus findet die
entsprechende Provinz nicht, wenn </p>
<list type="ordered">
<item>durch die GOV-Abfrage keine übergeordneten Objekte ausgegeben werden
(Beispielobjekt ›LIEHA2JO62RV‹) oder </item>
<item>kein Objekt der Zielmenge in den übergeordneten Objekten auftaucht,<note type="footnote"> Das ist derzeit
bei allen Orten der ehemaligen Provinz Holstein der Fall, da diese nicht
mit dem entsprechenden Objekt im GOV verknüpft sind. Allerdings kann
dieses auch einzelne Orte anderer Provinzen betreffen, z. B. Wesel
(›WESSELJO31HQ‹, Stand 18. Juni 2020). Dadurch, dass das GOV stetig
erweitert wird, können die fehlenden Verknüpfungen in der Zukunft
nachgeholt werden.</note> was </item>
<item>auch daran liegen kann, dass der identifizierte Ort im Ausland (also außerhalb
der Zielmenge) liegt.</item>
</list>
</div>
</div>
<div>
<p></p>
<p></p>
<p></p>
<p></p>
</div>
<div type="chapter">
<head>4. Anpassung auf GEDCOM-Dateien</head>
<p>Zur Vorbereitung der Validierung wurde der entwickelte Algorithmus in der
Programmiersprache Python 3.7 umgesetzt. Der Programmcode ist im <ref target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-urbanonyme">Online-Repositorium</ref>
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
<ref type="graphic" target="#urbanonyme_2020_009">Abbildung 9</ref>). Hierzu werden in jedem
Schritt eigene CSV-Dateien mit den Zwischenergebnissen erstellt und ausgegeben.</p>
<figure>
<graphic xml:id="urbanonyme_2020_009" url=".../medien/urbanonyme_2020_009.png">
<desc>
<ref target="#abb9">Abb. 9</ref>: Aufbau des Programms. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_009"/>
</desc>
</graphic>
</figure>
<p>Vor der Main-Funktion wird dieser
Prozess einmal je GEDCOM-Datei angestoßen (siehe <ref type="graphic" target="#urbanonyme_2020_010">Abbildung 10</ref>, 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. </p>
<p>Über die Funktion <code>importMiniGOV()</code> findet ein Import des Mini-GOV statt. Hier runter sind
verschiedene Textdateien zu verstehen, die zuvor je (heutigem) Staat vom CompGen
bereitgestellt werden.<note type="footnote"> Vgl. <ref type="bibliography" target="#verein_index_2021b">Verein für Computergenealogie e. V. (Hg.)
2021b</ref>.</note> Es werden die Mini-GOV-Dateien zu Deutschland, Polen,
Österreich, der Schweiz, Tschechien, Dänemark, Frankreich und den Niederlanden
integriert. Deutschsprachige Ortsnamen sind als <hi rend="italic">aktueller Name</hi> oder <hi rend="italic">letzter deutscher
Name</hi> gekennzeichnet. Falls es Letzteren gibt, so wird ein zusätzlicher
Eintrag kreiert, indem der alte Name den neuen überschreibt.<note type="footnote"> Die Eintragungen der anderen
europäischen Staaten, die keinen letzten deutschen Namen aufweisen, werden
bewusst nicht gelöscht, da das Programm unnötig verschlechtert würde und so
ein Ansatz gelegt ist, um auch auf internationale Ortsangaben adaptiert zu
werden.</note> Ansonsten werden die Mini-GOVs aneinandergesetzt und
alphabetisch sortiert. Hintergrund der Sortierung ist die Ermöglichung einer binären
Suche darin.</p>
<p>Da viele GEDCOM-Dateien einzeln und
voneinander unabhängig zu bearbeiten sind, ist eine Parallelisierung des
Programmcodes sinnvoll. Die Funktion <code>parallel()</code> wird dazu
parallel aufgerufen und bearbeiten. Wesentlich darin ist der nacheinander folgende
Aufruf von <code>mainMetadataInspector()</code>,
<code>mainPlaceFinder() </code>und <code>mainProvinceFiner()</code>. Die Ergebnisse aus diesen jeweiligen
Funktionsaufrufen werden mit der Funktion <code>appendFile()</code> den
CSV-Dateien hinzugefügt. Diese Dateien sind zuvor über die Funktion <code>createFile()</code> erstellt worden. Dazu dient unterstützend die
Funktion <code>loadData()</code>. Ebenso wurden zuvor die Daten der
jeweiligen GEDCOM-Datei über <code>loadGedcomFile()</code> geladen.</p>
<figure>
<graphic xml:id="urbanonyme_2020_010" url=".../medien/urbanonyme_2020_010.png">
<desc>
<ref target="#abb10">Abb. 10</ref>: Funktionsweise der
 Main. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_010"/>
</desc>
</graphic>
</figure>
<p>Für die Inspektion des Kontextes wird
eine Liste von Metadaten zu den einzelnen GEDCOM-Dateien geschaffen (siehe <ref type="graphic" target="#urbanonyme_2020_011">Abbildung 11</ref>). Dazu werden in der Funktion <code>prePlaceFinder()</code> die Ortsangaben über den Tag <code>PLAC</code> erkannt und über die Funktion
<code>minigovSearch() </code>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.</p>
<p>Nachfolgend wird in der Funktion <code>qualityChecker()</code> 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 Clusterungsverfahren durchgeführt. Das
gröbste mögliche Cluster stellt dabei den Mittelpunkt aus allen selektierten
Kontextdaten dar. Sinnvolle Parameter für die Feinheit der Clusterung werden in der
Validierung ermittelt. Die Koordinaten der Cluster werden zurückgegeben und ergänzen
die Metadaten der Datei. <code>qualityChecker()</code> greift auf
verschiedene Funktionen zu: Mithilfe der Funktion <code>gedcomRowParser()</code> werden die Bestandteile einer GEDCOM-Zeile separiert;
<code>stringDoublingCounter()</code> dient der Zählung von
Clustern.</p>
<p>Im Ergebnis bestehen die Metadaten aus
der Bezeichnung der Datei, den Durchschnittskoordinaten der selektierten
Kontextdaten, der Anzahl eindeutiger Ortsbezeichnungen, der Anzahl daraus gebildeter
Cluster sowie den Mittelpunkten jedes einzelnen Clusters. Die durchschnittlichen
Koordinaten ergeben sich aus dem arithmetischen Mittel der Längen- und Breitengrade
aller so gefundenen Ortsangaben.</p>
<figure>
<graphic xml:id="urbanonyme_2020_011" url=".../medien/urbanonyme_2020_011.png">
<desc>
<ref target="#abb11">Abb. 11</ref>: Funktionsweise der
 Kontextdatenanalyse. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_011"/>
</desc>
</graphic>
</figure>
<p>In der Funktion <code>mainPlaceFinder()</code> werden die Daten durch die Funktion <code>dataCleaner()</code> zunächst einer weitreichenden Bereinigung unterzogen (siehe
<ref type="graphic" target="#urbanonyme_2020_012">Abbildung 12</ref>). In der Funktion <code>stringFunc1()</code> 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 <code>stringFunc2()</code>
fehlt diese alternative Bedingung. Wie im <ref type="intern" target="#hd11">vorherigen
Abschnitt</ref> zerteilt die Funktion
<code>gedcomRowParser() </code>die einzelnen
GEDCOM-Zeilen in ihre Bestandteile.</p>
<p>Die konkrete Auswahl eines Orts zu
einer gegeben Ortsbezeichnung auf Basis der Kontextdaten findet in der Funktion <code>find()</code> statt, die durch die Funktion <code>placefinder()</code> vorbereitet wird. Hier wird im näheren der in <ref type="graphic" target="#urbanonyme_2020_006">Abbildung 6</ref> gegebene Prozess umgesetzt. Unter
anderem findet die kontextsensitive Zuordnung von Ortsbezeichnungen und Orten hier
statt. Die Suche nach Clustern im Umkreis der Koordinate ist in die Funktion <code>areaSearch()</code> ausgegliedert. Hier wird auch die
typenbasierte Zuordnung realisiert, falls die Umkreissuche fehlschlägt.</p>
<p>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 <code>find()</code> die Zuordnung getroffen hat, der
bereinigten und unbereinigten Ortsangabe sowie den Dateinamen enthält.</p>
<figure>
<graphic xml:id="urbanonyme_2020_012" url=".../medien/urbanonyme_2020_012.png">
<desc>
<ref target="#abb12">Abb. 12</ref>: Funktionsweise der
 Ortssuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_012"/>
</desc>
</graphic>
</figure>
<p>Zuletzt wird die Provinzsuche durch
die Funktion <code>mainProvincefinder()</code> realisiert (siehe <ref type="graphic" target="#urbanonyme_2020_013">Abbildung 13</ref>). Zu jedem zuvor identifizierten
Objekt wird die Funktion <code>provincefinder()</code> initiiert.
Hierin findet die Suche in der übergeordneten Baumstruktur des GOVs statt. Die dazu
notwendigen Informationen werden über die Funktion <code>callWebservice()</code> 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.<note type="footnote"> Die Zuordnung von Provinzen zu
GOV-Objekten ist in Tabelle 6 definiert. Diese GOV-URIs bilden die Zielmenge
für die Clusterung der identifizierten Orte.</note> 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 <code>beginCalculator()</code> bzw. <code>endCalculator()</code> 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.</p>
<figure>
<graphic xml:id="urbanonyme_2020_013" url=".../medien/urbanonyme_2020_013.png">
<desc>
<ref target="#abb13">Abb. 13</ref>: Funktionsweise der
 Provinzsuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_013"/>
</desc>
</graphic>
</figure>
</div>
<div type="chapter">
<head>5. Validierung und Diskussion</head>
<p>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.<note type="footnote"> Vgl. <ref type="bibliography" target="#goldberg_extraktion_2021">Goldberg / Moeller
2021</ref>.</note> Eine Ausführung des Scrapers am 15. April 2020 erbrachte 1.899
GEDCOM-Dateien. Diese enthalten 3.371.825 durch den Tag <code>PLAC</code>
<note type="footnote">
Neben dem Tag <code>PLAC</code> gibt es auch die Tags <code>FORM</code> (wenn er sich auf <code>PLAC</code> bezieht) oder <code>_LOC</code>, ja sogar die
direkte Möglichkeit der Angabe von Koordinaten über <code>LATI</code> und <code>LONG</code>. Ebenso existiert der Tag
<code>_GOV</code>, mit dem zu einem Ort direkt die GOV-URI
zugeordneten werden kann. Diese finden allerdings in GEDBAS eher weniger
Verwendung (<code>FORM</code> in Bezug auf <code>PLAC</code>: 2.085 Verwendungen über alle Dateien (diese allerdings in
nur 8 verschiedenen Dateien), <code>_LOC</code>: 101.603 (50),
<code>LATI</code>: 54.719 (88), <code>LONG</code>: 54.718 (88), <code>_GOV</code>: 5.043 (26)).
Das Ergebnis bestätigt die Auffassung von Gellatly, dass diese Art der Geokodierung mehrheitlich nicht genutzt
wird, vgl. Gellatly 2015, S. 118. Aufgrund dieser sehr geringen Verwendung
wird sich im Weiteren auf den Tag <code>PLAC</code> bezogen. Es
ist nachdrücklich erstrebenswert, dass Genealogen diese Felder künftig
direkt pflegen.</note> 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.<note type="footnote"> In 1.629.274 <code>PLAC</code>-Angaben
(48 Prozent) kommen insgesamt 3.933.251 Kommata vor – bei einer konsistenten
Verwendung wären es etwa zehn Millionen. Allerdings ist zu erkennen, dass
die Kommasetzung in einigen großen (meist englischsprachigen) Dateien stark
konzentriert ist: 80 Prozent der Kommata fallen in 2,6 Prozent der Dateien
an. Allein 13 Dateien (von 2.899) enthalten die Hälfte aller <code>PLAC</code>-Kommata. Das zeigt deutlich, dass diese
Ordnungssystematik bei der Identifizierung von GEDBAS-Urbanonymen keine
breite Hilfestellung sein kann.</note>
</p>
<p>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 Clusterung durchgeführt werden kann. Für diese Anforderungen ist eine
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 Clusters oder die Zuordnung zu einem bestehenden
angestoßen.<note type="footnote">
Vgl. <ref type="bibliography" target="#ester_noise_1996">Ester et al. 1996</ref>, S. 229.</note> In Anlehnung daran ist eine
Clusterung auch für die Kontextdaten realisiert (siehe Funktion <code>qualityChecker()</code>). Um die Parameter der Clusterung anzupassen ist eine
Betrachtung der Streuung der Cluster in einzelnen GEDCOM-Dateien von Interesse. Zum
einen kann die Mindestanzahl von Orten variiert werden, die nötig sind, um ein
Cluster zu bilden. Zum anderen ist die Mindestdistanz entscheidend, die ein Ort von
einem Cluster entfernt sein muss, um diesem nicht zugeschlagen zu werden. Im
Folgenden wird dieses für die GEDCOM-Dateien untersucht.<note type="footnote"> Bei der Validierung durch andere
Quellen würden gegebenenfalls andere Ergebnisse resultieren.</note> Bei
einem Vergleich der Mittelpunkte von Clustern einer Quelle bei Variation der
Parameter (Kilometer zur Zusammenführung zweier Orte, Mindestanzahl von Orten für
ein Cluster, siehe <ref type="graphic" target="#urbanonyme_2020_014">Abbildung 14</ref>) zeigt sich,
dass eine Distanz von 10 km (links) dazu führt, dass es sehr viele Cluster gibt, die
nah beieinander liegen. Dieses ist ein unerwünschter Effekt, da diese 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
Cluster zu erkennen. Hierdurch wird jedoch die absolute Zahl der Cluster stark
geschrumpft.</p>
<figure>
<graphic xml:id="urbanonyme_2020_014" url=".../medien/urbanonyme_2020_014.png">
<desc>
<ref target="#abb14">Abb. 14</ref>: Anzahl an

 Clustern nach durchschnittlichem Abstand in km bei Variation des Mindestabstandes zwischen
 Clustern (10 km, 25 km, 50 km) und Mindestgröße von Clustern (2, 6, und 11), jeweils 200 Bins. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_014"/>
</desc>
</graphic>
</figure>
<p>Bei einer Betrachtung der Anzahl von
Clustern pro Datei für jede dieser neun Optionen ergibt sich, dass die
unterschiedlichen Optionen vor allem bei Dateien mit vielen Clustern eine Auswirkung
aufzeigen. Liegen eine geringere Mindestgröße und ein geringer Minimalabstand
zwischen zwei Punkten von Clustern vor, erhöht sich die Anzahl der gesamten Cluster
stark (siehe <ref type="graphic" target="#urbanonyme_2020_015">Abbildung 15</ref>). Das bedeutet, dass
bei einer niedrigen Mindestdistanz sehr viele nah beieinanderliegende Cluster
existieren. Aus diesem Grund wurde die Mindestdistanz von 50 km gewählt. Als
Mindestgröße eines Clusters wird >5 gewählt, um einerseits die starke Erhöhung
der Clusteranzahl bei einem weiteren Absenken der Mindestgröße zu vermeiden, auf der
anderen Seite aber auch in wenig umfangreichen Dateien eine Clusterbildung zu
ermöglichen. </p>
<figure>
<graphic xml:id="urbanonyme_2020_015" url=".../medien/urbanonyme_2020_015.png">
<desc>
<ref target="#abb15">Abb. 15</ref>: Zusammenhang
 zwischen Mindestdistanz, Mindestclustergröße und Clusteranzahl, links mit
 logarithmischer Skalierung. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_015"/>
</desc>
</graphic>
</figure>
<p>Definiert wird also, dass ein Cluster
mindestens aus sechs Orten bestehen muss. Ferner muss jeder Ort eines Clusters 50
Kilometer von dem Ort eines anderen Clusters entfernt liegen; ansonsten würden sie
in einem gemeinsamen Cluster zusammengeführt. Es zeigt sich, dass dadurch 66 Prozent
der GEDCOM-Dateien, die überhaupt ein Cluster aufweisen,<note type="footnote"> 52 Prozent GEDCOM-Dateien weisen
kein Cluster auf. Das liegt darin begründet, dass kein Cluster von
mindestens fünf Ortsangaben gebildet werden konnte.</note> nur ein
einziges Cluster aufweisen, das den oben definierten Eigenschaften (50 km, mind. 6
zusammenhängende Orte) entspricht. 19 Prozent jedoch weisen zwei Cluster auf, 15
Prozent sogar mehr als zwei. Die Entfernung der Optionen einer unidentifizierten
Ortsangabe werden für alle Clustermittelpunkte berechnet. Der Ort mit der geringsten
Distanz zu einem der Clusterpunkte wird für die Identifizierung gewählt.</p>
<p>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 <ref type="intern" target="#hd4">Abschnitt 2.2</ref>
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<note type="footnote"> Siehe
hierzu Anm. 41.</note> einer Anagrammdetektion unterzogen werden.<note type="footnote"> Der Nachteil dieses
Vorgehens liegt auch hier darin, dass vertauschte Zeichen am Anfang der
Zeichenkette nicht erkannt werden, weil sie in einer alphabetischen
Sortierung weit entfernt sind. Zudem erkennt eine Ähnlichkeitsanalyse durch
ein Anagramm nur vertauschte Zeichen, nicht aber ausgelassene oder
zusätzlich vorhandene Buchstaben.</note> 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.</p>
<p>Bei einem initialen Grenzwert von 0,25
(Verhältnis von Anzahl der Änderungen zur Länge der Zeichenkette<note type="footnote"> Bei der Kölner Phonetik wird dazu
die Levenshtein-Distanz der ursprünglichen Zeichenketten
herangezogen.</note>) 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.<note type="footnote"> Bei einer zulässigen Levenshtein-Distanz von 2
sind beispielsweise Orte wie Nehmten und Nehren, Neiden und Nehren, Bövingen
und Böttingen, Muron und Murr, Murow und Murr, Balden und Belsen, Weißstein
und Beilstein oder Hattingen und Böttingen als gleich anzusehen. Selbst bei
einer Verringerung der Toleranz auf eine Distanz von 1 würden viele
FP-Ergebnisse produziert, beispielsweise bei Nehden und Nehren, Bötzingen
und Böttingen oder Oderthal und Odenthal.</note> 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 <ref type="graphic" target="#urbanonyme_2020_t3">Tabelle 3</ref>). 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.<note type="footnote">
Eine Idee für die künftige Erweiterung des Algorithmus besteht darin, dass
unklare Ortsangaben zunächst innerhalb des Kontextes verglichen werden.
Insbesondere in GEDCOM-Dateien besteht eine hohe Wahrscheinlichkeit, dass
Orte doppelt genannt werden; Schreibfehler könnten hierüber gegebenenfalls
effektiv erkannt werden.</note> Da der alternative Vergleich über
Anagramme und die Kölner Phonetik bessere Werte (mehr TP-Ereignisse<note type="footnote"> Zur Ermittlung
wurden 100 zufällige Ergebnisse ausgewählt und manuell eingeschätzt, ob es
sich um ein richtiges oder falsches Ergebnis handelt.</note>) aufweist,
wird diese Alternative im Weiteren ausgewählt.</p>
<table>
<row>
<cell>Ähnlichkeitsmaß</cell>
<cell>Erkennung = 1</cell>
<cell>FP</cell>
<cell>TP</cell>
<cell>Erkennung > 1<note type="footnote"> Die Angabe zu den Falschpositiven und
Falschnegativen bezieht sich zudem auf die nachfolgende Auswahllogik
eines der erkannten Orte (anhand geographischer Nähe, Typ etc.); nur
dieses wird untersucht.</note>
</cell>
<cell>FP</cell>
<cell>TP</cell>
</row>
<row>
<cell>Levenshtein-Distanz</cell>
<cell>6,23 %</cell>
<cell>68</cell>
<cell>32</cell>
<cell>9,34 %</cell>
<cell>71</cell>
<cell>29</cell>
</row>
<row>
<cell>Anagramm und Kölner
Phonetik</cell>
<cell>7,22 %</cell>
<cell>65</cell>
<cell>35</cell>
<cell>11,90 %</cell>
<cell>67</cell>
<cell>33</cell>
</row>
<trailer xml:id="tab03">
<ref type ="intern" target="#tab3">Tab. 3</ref>: Vergleich

verschiedener Ähnlichkeitsmaße, alle Angaben in Prozent, Grenze: 0,17. [Goldberg
2022]<ref type="graphic" target="#urbanonyme_2020_t3"/>
</trailer>
</table>
<p>Eine Ausführung des Algorithmus unter
den oben festgelegten Variationen ergibt das in <ref type="graphic" target="#urbanonyme_2020_t4">Tabelle 4</ref> 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. Hierzu dienen insbesondere
Hinweise auf eine Angabe außerhalb des Betrachtungsgebiets (z. B. Kürzel von
US-Bundesstaaten). 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.</p>
<table>
<row>
<cell>Auswahlkriterium</cell>
<cell>Anteil
in Prozent</cell>
</row>
<row>
<cell>Unerlaubte Bestandteile</cell>
<cell>31,51</cell>
</row>
<row>
<cell>Unerlaubter Angabe</cell>
<cell>0,07</cell>
</row>
<row>
<cell>Einziger passender Treffer in
Ähnlichkeitsanalyse</cell>
<cell>2,05</cell>
</row>
<row>
<cell>Einziger mit Koordinaten nach
Ähnlichkeitsanalyse</cell>
<cell>0,58</cell>
</row>
<row>
<cell>Geographische Nähe nach
Ähnlichkeitsanalyse</cell>
<cell>2,42</cell>
</row>
<row>
<cell>Einziger gültiger Typ nach
Ähnlichkeitsanalyse</cell>
<cell>0,02</cell>
</row>
<row>
<cell>Keiner mit gültigem Typ nach
Ähnlichkeitsanalyse</cell>
<cell>0,00</cell>
</row>
<row>
<cell>Ein passender Typ nach
Ähnlichkeitsanalyse</cell>
<cell>0,05</cell>
</row>
<row>
<cell>Zu viele passende Typen nach
Ähnlichkeitsanalyse</cell>
<cell>0,00</cell>
</row>
<row>
<cell>Ein einziger passender
Treffer</cell>
<cell>11,25</cell>
</row>
<row>
<cell>Ein einziger Treffer mit
Koordinaten</cell>
<cell>6,53</cell>
</row>
<row>
<cell>Geographische Nähe</cell>
<cell>18,87</cell>
</row>
<row>
<cell>Einziger gültigen Typ</cell>
<cell>0,41</cell>
</row>
<row>
<cell>Keiner mit gültigem Typ</cell>
<cell>0,05</cell>
</row>
<row>
<cell>Ein passender Typ</cell>
<cell>7,44</cell>
</row>
<row>
<cell>Zu viele passende Typen</cell>
<cell>0,00</cell>
</row>
<row>
<cell>Kein Auswahlkriterium
entscheidend</cell>
<cell>0,48</cell>
</row>
<row>
<cell>Kein Pendant im Mini-GOV
gefunden</cell>
<cell>18,17</cell>
</row>
<trailer xml:id="tab04">
<ref type ="intern" target="#tab4">Tab. 4</ref>: Endzustände des

Algorithmus am Beispiel Ortsangaben in GEDCOM-Dateien, Grundgesamtheit von 262.741
Einträgen.<note type="footnote"> Die

erhebliche Verkleinerung der Anzahl zu untersuchender Ortsangaben (von

3.057.810 auf 262.741) ist auf die Löschung doppelter Ortsangaben in einer

Datei zurückzuführen.</note> [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t4"/>
</trailer>
</table>
<p>Eine Stichprobe von 100 Werten
erbrachte 36 TP-Werte<note type="footnote"> Erkannte Orte aus den nicht-deutschen Mini-GOVs fallen
in diese Kategorie.</note>, 42 TN-Werte, 11 FP-Werte<note type="footnote"> Nicht erkannte Orte aus den
nicht-deutschen Mini-GOVs fallen in diese Kategorie.</note> und 11
FN-Werte.<note type="footnote"> Die
für die Einordnung in die vier Kategorien notwendige manuelle
Klassifizierung basierte dabei auf der Hinzunahme von Informationen, die bei
der Bereinigung gelöscht wurden sowie dem Aufrufen der GEDCOM-Datei und
Vergleich mit den Orten der näheren Verwandtschaft (nicht wie im Algorithmus
mit den Clustern der Quelle generell). Ortsbezeichnungen in den Ländern der
inkludierten Mini-GOVs wurden hierbei wie Orte in Deutschland
behandelt.</note> 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.</p>
<p>Der zweite Teil der Validierung
bezieht sich auf die 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.<note type="footnote"> Dieser Schritt wurde im Verlauf
der Erarbeitung iterativ durchgeführt, um ungünstige Funktionen des
Programmcodes zu entdecken und zu verbessern.</note> Die Fehler sind in
<ref type="graphic" target="#urbanonyme_2020_t5">Tabelle 5</ref> dargestellt.</p>
<table>
<row>
<cell>Grund
der fehlgeschlagenen Klassifizierung</cell>
<cell>Anzahl</cell>
</row>
<row>
<cell>
<p>Ort liegt außerhalb der Zielprovinzen
</p>
<p>(In heutigen
Staaten: Niederlande 29x, Frankreich 12x, Österreich 9x, Tschechien 5x,
Schweiz 3x, Polen 3x, Dänemark 1x)</p>
</cell>
<cell>62</cell>
</row>
<row>
<cell>
<p>GOV-Daten sind unvollständig</p>
<p>(Klassifiziert nach den
heutigen Bundesländern: Schleswig-Holstein 12x, Rheinland-Pfalz 7x,
Saarland 4x, Sachsen 2x, Baden-Württemberg 2x, Hessen 2x, Bayern 1x,
Thüringen 1x, Sachsen-Anhalt 1x)</p>
</cell>
<cell>32</cell>
</row>
<row>
<cell>Ausgestaltung des Algorithmus
deckt Fall nicht ab</cell>
<cell>6</cell>
</row>
<trailer xml:id="tab05">
<ref type="intern" target="#tab5">Tab. 5</ref>: Fehler in der
 Zuordnung der Provinzen bei der Bezugszeit 1820. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t5"/>
</trailer>
</table>
<p>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<note type="footnote">
[Anzahl gefundener Provinzen] ÷ [Anzahl
gefundener Provinzen + (1 – Anteil Fehler) × Anzahl nicht gefundener
Provinzen].</note> 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. </p>
<p>Bei einer Änderung der Bezugszeit auf
das Jahr 2020 ergibt sich ein ähnliches Bild (siehe <ref type="graphic" target="#urbanonyme_2020_t6">Tabelle 6</ref>). 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.</p>
<table>
<row>
<cell>Grund
der fehlgeschlagenen Klassifizierung</cell>
<cell>Anzahl</cell>
</row>
<row>
<cell>
<p>Ort liegt außerhalb der Zielprovinzen
</p>
<p>(In heutigen
Staaten: Niederlande 41x, Polen 22x, Österreich 12x, Tschechien 10x,
Frankreich 5x, Schweiz 2x, Dänemark 1x)</p>
</cell>
<cell>93</cell>
</row>
<row>
<cell>
<p>Ausgestaltung des Algorithmus deckt Fall
nicht ab</p>
<p>(Klassifiziert nach den heutigen Bundesländern: Schleswig-Holstein 3x,
Bayern 3x, Rheinland-Pfalz 1x)</p>
</cell>
<cell>7</cell>
</row>
<trailer xml:id="tab06">
<ref type="intern" target="#tab6">Tab. 6</ref>: Fehler in der
 Zuordnung der Provinzen bei der Bezugszeit 2020. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t6"/>
</trailer>
</table>
<p>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.</p>
</div>
<div type="chapter">
<head>6. Zusammenfassung</head>
<p>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.</p>
<p>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 <bibl>
<title type="desc">Geschichtliche Orts-Verzeichnis</title>
</bibl> (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.</p>
<p>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.<note type="footnote"> Der Algorithmus sollte zudem nicht auf antike oder
mittelalterliche Quellen angewendet werden, da die hier verwendete
Referenzdatenbank, das GOV, keine Daten über solch frühe Strukturen enthält.
Darüber hinaus bestehen andere Herausforderungen, die einer gesonderten
Betrachtung bedürfen. Die Idee der kontextsensitiven Entscheidungsfindung
über geographische Distanzen kann jedoch auch bei solchen Quellen Anwendung
finden.</note>
</p>
<p>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 Namen, auf die sich der Algorithmus beziehen kann.</p>
</div>
<div type="bibliography">
<head>Bibliographische Angaben</head>
<listBibl><bibl xml:id="abowd_context-awareness_1999">Gregory Dominic Abowd / Anind
K. Dey / Peter J. Brown / Nigel Davies / Mark Smith / Pete Steggles: Towards a
Better Understanding of Context and Context-Awareness. In: Handheld and
Ubiquitous Computing. Hg. von Hans-Werner Gellersen. Berlin / Heidelberg 1999.
S. 304-307. <ptr type="gbv" cRef="302206205"/></bibl>
<bibl xml:id="baehr_bevoelkerungsgeographie_1992">Jürgen Bähr / Christoph Jentsch / Wolfgang Kuls:
Bevölkerungsgeographie. Berlin u. a. 1992. <ptr type="gbv" cRef="028380339"/></bibl>
<bibl xml:id="clarke_principles_2009">Bertrand Clarke / Ernest Fokoue / Hao Helen Zhang:
Principles and Theory for Data Mining and Machine Learning. Dordrecht u. a. 2009. (=
Springer Series in Statistics) <ptr type="gbv" cRef="593579658"/> </bibl>
<bibl xml:id="ester_noise_1996">Martin Ester / Hans-Peter Kriegel / Xiaowei Xu: A
Density-Based Algorithm for Discovering Clusters in Large Spatial Databases with
Noise. In:
Proceedings. Second
International Conference on Knowledge Discovery & Data Mining. Hg. von Evangelos
Simoudis / Jiawei Han / Usama Fayyad (KDD-96: 2,Portland, OR, 02.–04.08.1996) Menlo
Park, CA 1996. PDF. [<ref target="https://www.aaai.org/Papers/KDD/1996/KDD96-037.pdf">online</ref>] <ptr type="gbv" cRef="223215147"/></bibl>
<bibl xml:id="fawcett_introduction_2006">Tom Fawcett: An introduction to ROC analysis. In: Pattern
Recognition Letters 27 (2006), H. 8, S. 861–874. <ptr type="gbv" cRef="129161756"/></bibl>
<bibl xml:id="feigenbaum_computers_1963">Computers and thought. Hg. von Edward A. Feigenbaum /
Julian Feldman. New York, NY u. a. 1963. <ptr type="gbv" cRef="020732821"/></bibl>
<bibl xml:id="fertig_zeitalter_2018">Georg Fertig / Christian Schlöder / Rolf Gehrmann /
Christina Langfeldt / Ulrich Pfister: Das postmalthusianische Zeitalter: Die
Bevölkerungsentwicklung in Deutschland, 1815–1871. In: Vierteljahrschrift für
Sozial- und Wirtschaftsgeschichte 105 (2018), H. 1, S. 6–33. <ptr type="gbv" cRef="129459623"></ptr></bibl>
<bibl xml:id="gallagher_estimating_2008">Andrew C. Gallagher / Tsuhan Chen: Estimating age, gender,
and identity using first name priors. In: IEEE Conference on Computer Vision and
Pattern Recognition (2008). DOI: <ref target="https://doi.org/10.1109/CVPR.2008.4587609">10.1109/CVPR.2008.4587609</ref> <ptr type="gbv" cRef="577792776"/></bibl>
<bibl xml:id="gellatly_reconstructing_2015">Corry Gellatly: Reconstructing Historical Populations from
Genealogical Data Files. In: Population Reconstruction. Hg. von Gerrit Bloothooft /
Peter Christen / Kees Mandemakers / Marijn Schraagen. Cham u. a. 2015, S. 111–128.
<ptr type="gbv" cRef="833549804"/></bibl>
<bibl xml:id="gentile_techniques_2013">Geolocation Techniques: Principles and Applications. Hg.
von Camillo Gentile / Nayef Alsindi / Ronald Raulefs / Carole Teolis. New York, NY
u. a. 2013. <ptr type="gbv" cRef="73135057X"/></bibl>
<bibl xml:id="gesellschaft_vornamen_2019">Ausführliche Auswertung: Vornamen 2018. Hg. von
Gesellschaft für deutsche Sprache e. V. In: gfds.de. Wiesbaden u. a. 2019.
Pressemitteilung vom 02.05.2019. [<ref target="https://gfds.de/ausfuehrliche-auswertung-vornamen-2018/">online</ref>] </bibl>
<bibl xml:id="gigerenzer_heuristics_1999">Simple Heuristics that make us smart. Hg. von Gerd
Gigerenzer / Peter M. Todd. New York, NY u. a. 1999. <ptr type="gbv" cRef="252837991"/></bibl>
<bibl xml:id="goldberg_extraktion_2021">Jan Michael Goldberg / Katrin Moeller: Automatisierte
Extraktion und Lemmatisierung historischer Berufsbezeichnungen in deutschsprachigen
Datenbeständen. In: Zeitschrift für digitale Geisteswissenschaften 6 (2021). DOI: <ref target="https://doi.org/10.17175/2022_002">10.17175/2022_002</ref></bibl>
<bibl xml:id="harviainen_genealogy_2018">J. Tuomas Harviainen / Bo-Christer Björk: Genealogy,
GEDCOM, and popularity implications. In: Informaatiotutkimus 37 (2018), H. 3, S.
4–14. DOI: <ref target="https://doi.org/10.23978/inf.76066">10.23978/inf.76066</ref>
</bibl>
<bibl xml:id="hohensinner_name_2011">Karl Hohensinner: Der Name Mayr / Mair / Mayer / Maier etc.
im Oberösterreichischen Familiennamenatlas. In:
Familiennamengeographie. Ergebnisse
und Perspektiven europäischer
Forschung. Hg. von Rita
Heuser / Damaris Nübling / Mirjam Schmuck. Berlin u. a. 2011, S. 91–106. <ptr type="gbv" cRef="617916810"/> </bibl>
<bibl xml:id="institut_ortsverzeichnis_2020">Das Historische Ortsverzeichnis von Sachsen. Hg. von
Institut für sächsische Geschichte und Volkskunde. In: hov.isgv.de. Dresden 2020.
[<ref target="https://hov.isgv.de/">online</ref>] </bibl>
<bibl xml:id="kocka_familie_1980">Jürgen Kocka / Karl Ditt / Josef Mooser / Heinz Reif /
Reinhard Schüren: Familie und soziale Plazierung. Studien zum Verhältnis von
Familie, sozialer Mobilität und Heiratsverhalten an westfälischen Beispielen im
späten 18. und 19. Jahrhundert. Opladen 1980. <ptr type="gbv" cRef="023831081"/></bibl>
<bibl xml:id="levenstejn_codes_1966">Vladimir Iosifovič Levenštejn: Binary Codes Capable of
Correcting Deletions, Insertations, and Reversals. Soviet Physics /Doklady 10
(1966), H. 8, S. 707–710. <ptr type="gbv" cRef="129482234"/></bibl>
<bibl xml:id="list_distanz_2010">Johann-Mattis List: Distanz- und Alignmentanalysen in
derhistorischen Linguistik. Düsseldorf 2010. PDF. [<ref target="http://lingulist.de/documents/sequence.pdf">online</ref>] </bibl>
<bibl xml:id="rosemann_process_2006">Michael Rosemann / Jan Recker: Context-aware Process
Design: Exploring the Extrinsic Drivers for Process Flexibility. In: Proceedings of
the Workshops and Doctoral Consortium. Hg. von M. Petit / T. Latour. Belgium 2006,
S. 149–158. [<ref target="https://eprints.qut.edu.au/4638">online</ref>]</bibl>
<bibl xml:id="seibicke_personennamen_1982">Wilfried Seibicke: Die Personennamen im Deutschen. Berlin
u. a. 1982. <ptr type="gbv" cRef="024283177"/></bibl>
<bibl xml:id="sitou_requirements_2009">Wassiou Olarewaju Sitou: Requirements-Engineering
kontextsensitiver Anwendungen. München u. a. 2009. PDF. [<ref target="http://mediatum.ub.tum.de/doc/679228/document.pdf">online</ref>] </bibl>
<bibl xml:id="stoepel_geogen_2021a">Christoph Stöpel (2021a): Geogen v4. In:
geogen.stoepel.net. 2005–2021. [<ref target="https://geogen.stoepel.net/legacy.html?">online</ref>] </bibl>
<bibl xml:id="stöpel_geogen_2021b">Christoph Stöpel (2021b): Geogen Onlinedienst. Allgemeine
Informationen / Häufige Fragen (FAQ). In: legacy.stoepel.net/. 2005–2021. [<ref target="https://legacy.stoepel.net/de/Infos">online</ref>].</bibl>
<bibl xml:id="verein_gov_2015">GOV/Webservice. Hg. von Verein für Computergenealogie e. V.
In: GenWiki. 2015. Beitrag vom 01.11.2015. [<ref target="http://wiki-en.genealogy.net/GOV/Webservice">online</ref>]</bibl>
<bibl xml:id="verein_gazetteer_2021a">The Historic Gazetteer. Hg. von Verein für
Computergenealogie e. V. (2021a) In: Genealogy.net. 2021. [<ref target="http://gov.genealogy.net/search/index">online</ref>]</bibl>
<bibl xml:id="verein_index_2021b">Index of /gov/minigov. Hg. von Verein für
Computergenealogie e. V. (2021b) In: Genealogy.net. 2021. [<ref target="http://www.genealogy.net/gov/minigov/">online</ref>]</bibl>
<bibl xml:id="working-group_neustadt_2021">Neustadt in Europe - Overview. Hg. von Working Group
Neustadt in Europa. Overview. In: neustadt-in-europa.de. Neustadt an der Weinstraße
2021. [<ref target="https://www.neustadt-in-europa.de/en/list.html">online</ref>]</bibl>
<bibl xml:id="zandhuis_toponyms_2015">Ivo Zandhuis / Menno den Engelse / Edward Mac Gillavry:
Dutch Historical Toponyms in the Semantic Web. In: Population Reconstruction.
Hg. von Gerrit Bloothooft / Peter Christen / Kees Mandemakers / Marijn
Schraagen.Gerrit Bloothooft et al. Cham u. a. 2015, S. 23–41. <ptr type="gbv" cRef="833549804"/>. </bibl>
<bibl xml:id="zedlitz_survey_2014">Jesper Zedlitz / Norbert Luttenberger: A Survey on
Modelling Historical Administrative Information on the Semantic Web. In:
International Journal on Advances in Internet Technology 7 (2014), H. 3/4, S.
218–231. [<ref target="http://www.iariajournals.org/internet_technology/tocv7n34.html">online</ref>]</bibl>
<bibl xml:id="zheng_integrating_2019">Yong Zheng / Shephalika Shekhar / Alisha Anna Jose / Sunil
Kumar Rai: Integrating context-awareness and multi-criteria decision making in
educational learning. In: Proceedings of the 34th ACM/SIGAPP Symposium on Applied
Computing. Hg. von Association for Computing Machinery. (SAC '19: 34, Limasol,
08.–12.04.2019) New York, NY 2019, S. 2453–2460. <ptr type="gbv" cRef="1684173736"/> </bibl></listBibl>
<div type="abbildungsnachweis">
<head>Abbildungs- und Tabellenverzeichnis</head>
<desc type="graphic" xml:id="abb1">Abb. 1:
Übersicht über Begrifflichkeiten und Zusammenhänge. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_001"/></desc>
<desc type="table" xml:id="tab1"><ref type="intern" target="tab01">Tab. 1</ref>:
Konfusionsmatrix zur Identifizierung von Ortsbezeichnungen in Anlehnung an
Fawcett. [Fawcett 2006, S. 862]<ref type="graphic"
target="#urbanonyme_2020_t1"/></desc>
<desc type="graphic" xml:id="abb2">Abb. 2:
Relative (links) und absolute (rechts) Verteilung des Nachnamens Hinse.
[Goldberg 2022, erstellt mit Geogen Deutschland, Stöpel 2021a.]<ref type="graphic" target="#urbanonyme_2020_002"/></desc>
<desc type="graphic" xml:id="abb3">Abb. 3:
Auszug aus einer
 GOV-Abfrage. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_003"/></desc>
<desc type="graphic" xml:id="abb4">Abb. 4:
Auszug einer GEDCOM-Datei. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_004"/></desc>
<desc type="graphic" xml:id="abb5">Abb. 5:
Ermittlung und Bewertung von Kontextdaten, eigene Darstellung als
Nassi-Sneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_005"/></desc>
<desc type="graphic" xml:id="abb6">Abb. 6:
Ortsidentifizierung, eigene Darstellung als Nassi-Sneiderman-Diagramm. [Goldberg
2022]<ref type="graphic" target="#urbanonyme_2020_006"/></desc>
<desc type="graphic" xml:id="abb7">Abb. 7:
Analyse der provinziellen Zuordnung, eigene Darstellung als
Nassi-Sneiderman-Diagramm. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_007"/></desc>
<desc type="graphic" xml:id="abb8">Abb. 8: GOV-Struktur der Stadt
<ref target="http://gov.genealogy.net/item/show/object_113700">Wiedenbrück</ref>
,
Stand: 30. Januar 2021. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_008"/></desc>
<desc type="table" xml:id="tab2"><ref type="intern" target="tab02">Tab. 2</ref>:
Zuordnung von Provinzen zum GOV. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t2"/></desc>
<desc type="graphic" xml:id="abb9">Abb. 9:
Aufbau des Programms. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_009"/></desc>
<desc type="graphic" xml:id="abb10">Abb. 10:
Funktionsweise der Main. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_010"/></desc>
<desc type="graphic" xml:id="abb11">Abb. 11:
Funktionsweise der Kontextdatenanalyse. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_011"/></desc>
<desc type="graphic" xml:id="abb12">Abb. 12:
Funktionsweise der Ortssuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_012"/></desc>
<desc type="graphic" xml:id="abb13">Abb. 13:
Funktionsweise der Provinzsuche. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_013"/></desc>
<desc type="graphic" xml:id="abb14">Abb. 14:
Anzahl an Clustern nach durchschnittlicher Abstand in km bei Variation des
Mindestabstandes zwischen Clustern (10 km, 25 km, 50 km) und Mindestgröße von
Clustern (2, 6, und 11), jeweils 200 Bins. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_014"/></desc>
<desc type="graphic" xml:id="abb15">Abb. 15:
Zusammenhang zwischen Mindestdistanz, Mindestclustergröße und Clusteranzahl,
links mit logarithmischer Skalierung. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_015"/></desc>
<desc type="table" xml:id="tab3"><ref type="intern" target="tab03">Tab. 3</ref>:
Vergleich verschiedener Ähnlichkeitsmaße, alle Angaben in Prozent, Grenze: 0,17.
[Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t3"/></desc>
<desc type="table" xml:id="tab4"><ref type="intern" target="tab04">Tab. 4</ref>:
Endzustände des Algorithmus am Beispiel Ortsangaben in GEDCOM-Dateien,
Grundgesamtheit von 262.741 Einträgen. [Goldberg 2022]<ref type="graphic" target="#urbanonyme_2020_t4"/></desc>
<desc type="table" xml:id="tab5"><ref type="intern" target="tab05">Tab. 5</ref>:
Fehler in der Zuordnung der Provinzen bei der Bezugszeit 1820. [Goldberg
2022]<ref type="graphic" target="#urbanonyme_2020_t5"/></desc>
<desc type="table" xml:id="tab6"><ref type="intern" target="tab06">Tab. 6</ref>:
Fehler in der Zuordnung der Provinzen bei der Bezugszeit 2020. [Goldberg
2022]<ref type="graphic" target="#urbanonyme_2020_t6"/></desc>
</div>
</div>
</div>
</body>
</text>
</TEI>