diff --git a/2022_005_goldberg/urbanonyme_2020_001.png b/2022_005_goldberg/urbanonyme_2020_001.png new file mode 100644 index 0000000000000000000000000000000000000000..604c92b720708bd4da27e5c8b62156d02096f217 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_001.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_002.png b/2022_005_goldberg/urbanonyme_2020_002.png new file mode 100644 index 0000000000000000000000000000000000000000..4fc4d8c340fabfe74ac8c80a3bbe2e053b2fa018 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_002.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_003.png b/2022_005_goldberg/urbanonyme_2020_003.png new file mode 100644 index 0000000000000000000000000000000000000000..683462d856266659b2cef1942249626d101a1f64 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_003.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_004.png b/2022_005_goldberg/urbanonyme_2020_004.png new file mode 100644 index 0000000000000000000000000000000000000000..0894e25500445f84c46d5ced3ae334bf2a51ecd9 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_004.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_005.png b/2022_005_goldberg/urbanonyme_2020_005.png new file mode 100644 index 0000000000000000000000000000000000000000..40db02fd093dc722f48f75e70f29edbf6e65a943 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_005.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_006.png b/2022_005_goldberg/urbanonyme_2020_006.png new file mode 100644 index 0000000000000000000000000000000000000000..51a47e69f6dfa968894aea7cb23787cef3f66dc9 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_006.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_007.png b/2022_005_goldberg/urbanonyme_2020_007.png new file mode 100644 index 0000000000000000000000000000000000000000..5ca3ae74eec008cd6f40045a0e0e30db32ec49d4 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_007.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_008.png b/2022_005_goldberg/urbanonyme_2020_008.png new file mode 100644 index 0000000000000000000000000000000000000000..7a47caccee4acf3f7e2f99755cefe11f96258c93 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_008.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_009.png b/2022_005_goldberg/urbanonyme_2020_009.png new file mode 100644 index 0000000000000000000000000000000000000000..8fd68b3a3e4b9407a794ddb488185e7c9a371787 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_009.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_010.png b/2022_005_goldberg/urbanonyme_2020_010.png new file mode 100644 index 0000000000000000000000000000000000000000..a11271e44e4145eeb921ef8b71a8bab3858a0c1e Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_010.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_011.png b/2022_005_goldberg/urbanonyme_2020_011.png new file mode 100644 index 0000000000000000000000000000000000000000..e7aecbb938807a5c5f9cc39cecc30b724780b0b0 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_011.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_012.png b/2022_005_goldberg/urbanonyme_2020_012.png new file mode 100644 index 0000000000000000000000000000000000000000..09c93a523fef7a851abd4b82e7b3d286081ddfb7 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_012.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_013.png b/2022_005_goldberg/urbanonyme_2020_013.png new file mode 100644 index 0000000000000000000000000000000000000000..851ab363c7af786ca7bb6bc929da2b5c1956964e Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_013.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_014.png b/2022_005_goldberg/urbanonyme_2020_014.png new file mode 100644 index 0000000000000000000000000000000000000000..0ee5c033900af6ce2c74e611148b08c74ca10ebb Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_014.png differ diff --git a/2022_005_goldberg/urbanonyme_2020_015.png b/2022_005_goldberg/urbanonyme_2020_015.png new file mode 100644 index 0000000000000000000000000000000000000000..3697649173c232d02c17353b98a2b8198fad5ea2 Binary files /dev/null and b/2022_005_goldberg/urbanonyme_2020_015.png differ diff --git a/2022_005_goldberg/urbanonyme_v1_0.pdf b/2022_005_goldberg/urbanonyme_v1_0.pdf new file mode 100644 index 0000000000000000000000000000000000000000..75212f54be236bf155708ae3f26fa53465d16f8f Binary files /dev/null and b/2022_005_goldberg/urbanonyme_v1_0.pdf differ diff --git a/2022_005_goldberg/urbanonyme_v1_0.xml b/2022_005_goldberg/urbanonyme_v1_0.xml new file mode 100644 index 0000000000000000000000000000000000000000..99d914d2a9ecc1dec93145c8826a8061e3ff8f1e --- /dev/null +++ b/2022_005_goldberg/urbanonyme_v1_0.xml @@ -0,0 +1,2186 @@ +<?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>