diff --git a/2023_001_goldberg/record_2022_001.png b/2023_001_goldberg/record_2022_001.png new file mode 100644 index 0000000000000000000000000000000000000000..b49bf829b38544c6326c9dfc909e9f57767a0e8c Binary files /dev/null and b/2023_001_goldberg/record_2022_001.png differ diff --git a/2023_001_goldberg/record_2022_002.png b/2023_001_goldberg/record_2022_002.png new file mode 100644 index 0000000000000000000000000000000000000000..abaa6e054e1320ed177e9d3ef18e69e7f88d86bf Binary files /dev/null and b/2023_001_goldberg/record_2022_002.png differ diff --git a/2023_001_goldberg/record_2023_v1_0.pdf b/2023_001_goldberg/record_2023_v1_0.pdf new file mode 100644 index 0000000000000000000000000000000000000000..849c63bf49f6ed5e4b5f8c7167b17f02f73ab90c Binary files /dev/null and b/2023_001_goldberg/record_2023_v1_0.pdf differ diff --git a/2023_001_goldberg/record_2023_v1_0.xml b/2023_001_goldberg/record_2023_v1_0.xml new file mode 100644 index 0000000000000000000000000000000000000000..b17a5cca4b18c7f963099bb5bf374906fe277ccb --- /dev/null +++ b/2023_001_goldberg/record_2023_v1_0.xml @@ -0,0 +1,2145 @@ +<?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">Automatisiertes Record Linkage in prosopographischen + Datenbeständen am Beispiel historischer Quellen Leipzigs</title> + <respStmt> + <resp ref="http://id.loc.gov/vocabulary/relators/aut">Author</resp> + <persName> + <forename>Jan Michael</forename> + <surname>Goldberg</surname> + <email>jan.goldberg@wiwi.uni-halle.de</email> + <idno type="gnd">1240406630</idno> + <idno type="orcid">0000-0002-4817-4283</idno> + <affiliation>Martin-Luther-Universität Halle Wittenberg, Lehrstuhl für empirische Makroökonomik</affiliation> + </persName> + </respStmt> + <respStmt> + <resp ref="http://id.loc.gov/vocabulary/relators/aut">Author</resp> + <persName> + <forename>Marcel</forename> + <surname>Mernitz</surname> + <email>marcel.mernitz@informatik.uni-halle.de</email> + <idno type="gnd">1275436560</idno> + <idno type="orcid">0000-0001-6464-2844</idno> + <affiliation>Martin-Luther-Universität Halle Wittenberg, Institut für Informatik</affiliation> + </persName> + </respStmt> + <idno type="doi">10.17175/2023_001</idno> + <idno type="ppn">1819370283</idno> + <idno type="zfdg">2023.001</idno> + <idno type="url">https://www.zfdg.de/node/383</idno> + <date when="2023-01-26">26.01.2023</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 ref="http://id.loc.gov/vocabulary/relators/dtm">Transformation der + Word Vorlage nach TEI</resp> + <persName> + <surname>Baumgarten</surname> + <forename>Marcus</forename> + <idno type="gnd">1192832655</idno> + <idno type="orcid">0000-0003-0801-9462</idno> + </persName> + </respStmt> + <availability status="free"> + <p>Available at <ref target="https://www.zfdg.de">https://www.zfdg.de</ref> + </p> + </availability> + <biblScope unit="year">2023</biblScope> + <biblScope unit="artikel">01</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 + de la Iglesia</persName>.</p> + </editorialDecl> + <editorialDecl> + <p>Medienrechte liegen bei den Autor*innen</p> + </editorialDecl> + <editorialDecl> + <p>All links checked<date when="2023-01-12">12.01.2023</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>Duplikaterkennung<ref target="1263539092"/> + </term> + <term>Datenverknüpfung<ref target="4788710-2"/> + </term> + <term>Personenbezogene Daten<ref target="4173908-5"/> + </term> + <term>Algorithmus<ref target="4001183-5"/> + </term> + <term>Genealogie<ref target="4020097-"/> + </term> + <term>Geschichtswissenschaft<ref target="4020535-6"/> + </term> + </keywords> + </textClass> + </profileDesc> + <revisionDesc> + <change/> + </revisionDesc> + </teiHeader> + <text> + <body> + <div> + + <div type="abstract"> + <argument xml:lang="de"> + <p>In dieser Studie wird ein automatisierter Ansatz zum <term type="dh">Record Linkage</term> in + prosopographischen Datenbeständen vorgestellt. In ihm sind zahlreiche + genealogische Regeln zur Verknüpfung von Personen implementiert. Dadurch ist er + besonders für Datenbestände geeignet, die zu den abgebildeten Individuen viele + genealogisch relevante Informationen bereithalten. Dazu wird eine normierte + Datenstruktur definiert, in die die Eingangsdaten einzuordnen sind. Der + Algorithmus erkennt innerhalb dieser Datenstruktur Einträge zu gleichen + Personen und führt diese automatisch zusammen. In diesem Zuge wird eine + Formalisierung von genealogischen Heuristiken vorgenommen. Die + Funktionsfähigkeit des Algorithmus wird am Beispiel historischer Datenbestände + aus Leipzig erfolgreich dargestellt. Der Programmcode ist in Python realisiert + worden und frei verfügbar.</p> + </argument> + <argument xml:lang="en"> + <p>In this study, an automated approach to <term type="dh">record linkage</term> in prosopographic + datasets is presented. It implements numerous genealogical rules for linking + individuals. This makes it particularly suitable for datasets that contain a + lot of genealogically relevant information about the represented individuals. + For this purpose, a standardized data structure is defined into which the input + data is to be arranged. The algorithm recognizes entries pertaining to the same + persons within this data structure and merges them automatically. In this + process, a formalization of genealogical heuristics is performed. The + functionality of the algorithm is successfully demonstrated using historical + datasets from the city of Leipzig as an example. The program code has been + realized in Python and is freely available.</p> + </argument> + </div> + <div type="chapter"> + <head>1. Einleitung</head> + <p>Gleiches mit Gleichem zu verbinden, stellt überall dort eine besondere + Herausforderung dar, wo keine eindeutigen Identifikationsmerkmale vorliegen. + Dieses Problem tritt in wissenschaftlichen Untersuchungen insbesondere dann auf, + wenn historische Personendaten Forschungsgegenstand sind. Immer größere + Datenmengen sorgen zudem zunehmend dafür, dass eine manuelle Bearbeitung erschwert + wird. Dadurch besteht ein Bedarf an automatisierten <term type="dh" + >Record-Linkage</term>-Lösungen. Neben den klassischen wissenschaftlichen + Anwendungen betrifft das unter anderem auch Projekte wie <term type="dh" + >Time-Machine</term>-Anwendungen.<note type="footnote"> + <term type="dh">Time Machines</term> sind Konstrukte, in denen historische + Daten verschiedenster Quellen zusammengeführt werden. Dadurch werden + beispielsweise individuelle Biografien, politisch-städtische Dynamiken und die + Veränderung der Bausubstanz verknüpft auf einer Plattform sichtbar. Diese + werden öffentlich zur Verfügung gestellt und können zur Forschung und Bildung + genutzt werden. Vgl. <ref type="bibliography" target="#kaplan_venice_2015">Kaplan 2015</ref>, S. 73.</note> Im deutschen Sprachraum sind + derzeit beispielsweise die Projekte in Leipzig, Jena und Köln zu nennen.<note + type="footnote"> Vgl. <ref type="bibliography" target="#time_machine_2022">Time Machine Organisation 2022</ref>.</note> Perspektivisch ist denkbar, dass in vielen deutschsprachigen Städten solche Time Machines + initiiert werden. Eine besondere Herausforderung dabei ist es, viele + unterschiedliche Quellen zusammenzuführen. Aus dieser Perspektive heraus besteht ein erhöhter Bedarf an Record-Linkage-Lösungen, die die Besonderheiten der + deutschen Sprache berücksichtigen.</p> + <p>Um Lebensläufe von Individuen oder Familienentwicklungen nachvollziehen zu können, + greifen Historiker*innen sowie Wirtschafts- und Sozialwissenschaftler*innen auf + verschiedene Daten zur persönlichen Identifikation zurück. Hierfür gibt es eine + Vielzahl verschiedener Record-Linkage-Ansätze. Schon in der Antike wurde über die + Bevölkerung Buch geführt, beispielsweise zur Übersicht über die zur Musterung + heranzuziehende Bevölkerung, zur Wahlrechtverteilung oder zur Erhebung von + Steuern.<note type="footnote"> Vgl. <ref type="bibliography" target="#hin_roman_2016">Hin et al. 2016</ref>, S. 50.</note> Die meisten + historischen Informationen über Individuen der Neuzeit befinden sich in + prosopographischen Quellen wie Kirchenbüchern. Die historische Datenerhebung kennt + dabei zur eindeutigen Personenerkennung keine eindeutigen Identifikatoren wie + Steuer-, Personalausweis- oder Sozialversicherungsnummer. Daher muss auf andere + Daten einer Person zurückgegriffen werden, beispielsweise den Namen, Geburts- und + Sterbedaten oder die Namen der Eltern. Diese Daten allerdings sind nicht geschützt + vor Fehlern oder Verlust. Daraus ergibt sich eine enorme Ungenauigkeit ebendieser + Daten.<note type="footnote"> Vgl. <ref type="bibliography" target="#feigenbaum_census_2016">Feigenbaum 2016</ref>; + <ref type="bibliography" target="#hin_roman_2016">Hin et al. 2016</ref>, S. 50, 52; + <ref type="bibliography" target="#massey_playing_2017">Massey 2017</ref>, S. 129, 131.</note> Zudem sind große Datenbestände unübersichtlich + oder gar nicht überschaubar. Das zeigt sich beispielsweise, wenn Personen in einem + Zensus händisch im darauffolgenden Zensus anhand der Angaben zur Stadt oder Gegend + beziehungsweise zum Land gesucht werden.<note type="footnote"> Vgl. <ref type="bibliography" target="#massey_playing_2017">Massey 2017</ref>, + S. 130.</note> Problematisch an diesem Ansatz ist, dass verzogene Menschen in + dem folgenden Zensus aufgrund des Ortswechsels nicht gefunden werden. Die + Aussagekraft der Ergebnisse ist hierbei also durch die geografische Mobilität der + Bevölkerung gefährdet. Neben der Qualität der Quellen haben zudem knapp bemessene + personelle, finanzielle und zeitliche Ressourcen in der Forschung Einfluss auf die + Qualität der Record-Linkage-Ergebnisse.<note type="footnote"> Vgl. <ref type="bibliography" target="#massey_playing_2017">Massey 2017</ref>, S. + 129f.</note> Unter anderem aus diesem Umstand heraus wurden neben einer + händischen Verknüpfung halb- und vollautomatisierte Verfahren entwickelt.<note + type="footnote"> Bei einem halbautomatisierten Ansatz unterbreitet ein Programm + dem Forschungspersonal Vorschläge zu möglichen Treffern. Jedoch bestimmt das + Forschungspersonal und kein Algorithmus über die Verknüpfung.</note> Welche + Herangehensweise hierbei die richtige ist, ist abhängig vom Projektziel. Da es + oftmals keine offiziellen Regeln für das Verbinden der Records gibt, existieren + zahlreiche Heuristiken für die Verknüpfung der Daten. Eine Grundvoraussetzung für + ein automatisiertes Record Linkage ist die Formalisierung der Heuristiken, die dem + Verbinden der Daten zugrunde liegen.</p> + <p>Ziel des hier vorgestellten Ansatzes ist es, Heuristiken zum Record Linkage in + prosopographischen Datenbeständen mit vielen genealogisch relevanten Informationen + zu formalisieren und in einem automatisierten Algorithmus umzusetzen. Genealogisch + relevante Informationen sind dabei Lebensdaten wie Geburts- oder Sterbedatum, + Berufe oder Informationen über die Eltern einer Person. Dieser Algorithmus soll + dazu geeignet sein, ein Record Linkage in deutschsprachigen Datenbeständen zu + ermöglichen. Zu diesem Zweck wird im nächsten Abschnitt zunächst ein Überblick + über den Stand der Forschung gegeben. Darauffolgend findet die Beschreibung des + entwickelten Algorithmus statt, bevor sich dieser einer Validierung anhand von + historischen Leipziger Quellen unterzieht. Abschließend wird das Ergebnis + zusammengefasst. Der Algorithmus selbst wird in der Programmiersprache Python 3.6 + umgesetzt und ist im <ref + target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-record" + >Online-Repositorium</ref> zu finden.</p> + </div> + <div type="chapter"> + <head>2. Forschungsstand</head> + + <p>Zunächst wird auf verschiedene Methoden des Record Linkage eingegangen. Danach + findet eine Betrachtung der Besonderheiten prosopographischer Datenbestände mit + umfangreichen genealogisch relevanten Daten statt.</p> + <div type="subchapter"> + <head>2.1 Methoden des Record Linkage historischer Datenbestände</head> + + <p>Wie eingangs erwähnt, gibt es unterschiedliche Ansätze, wie Datensätze zusammengeführt werden können. Diese Darstellung fokussiert sich explizit + auf den Stand der Forschung bei der Anwendung auf historische Daten.<note + type="footnote"> Als Einführung in die Grundlagen des Themas vgl. <ref type="bibliography" target="#gu_record_2003">Gu et al. + 2003</ref>.</note> Zweck ist es, einen Überblick über verschiedene Verfahren und + Ideen zu geben, ohne dabei jedoch einen Anspruch auf Vollständigkeit zu + erheben. Das Record Linkage historischer Daten hat sich in den vergangenen + Jahrzehnten stetig verändert, wie beispielsweise Massey aufzeigt.<note + type="footnote"> Sie selbst prüft verschiedene Record-Linkage-Verfahren und + kommt beispielsweise zu dem Schluss, dass Ergebnisse besser werden, wenn die + Altersangaben zwischen zwei zeitlich auseinanderliegenden Quellen in Bezug + auf die zeitliche Differenz zwischen diesen umgerechnet werden. Die besten + Resultate erzielt sie mit probabilistischen Matching-Techniken. Vgl. <ref type="bibliography" target="#massey_playing_2017">Massey + 2017</ref>, S. 129, 140.</note> Übergreifend werden von Gellatly als wesentliche + Herausforderungen zum einen die Skalierbarkeit auf große Datenbestände, zum + anderen die Genauigkeit und Effizienz der Algorithmen identifiziert.<note + type="footnote"> Vgl. <ref type="bibliography" target="#gellatly_populations_2015">Gellatly 2015</ref>, S. 114, 122.</note> Als dritte große + Herausforderung werden Datenschutzaspekte genannt.<note type="footnote"> Vgl. + <ref type="bibliography" target="#christian_record_2015">Christen et al. 2015</ref>, S. 87.</note> Der Datenschutzaspekt wird im Weiteren + vernachlässigt, da der Algorithmus auf Daten ausgelegt werden soll, die + aufgrund ihres Alters vom deutschen Datenschutzrecht nicht tangiert werden. Die + Analyse von Daten aus verschiedenen Zeiträumen weist dabei unterschiedliche + Herausforderungen auf, beispielsweise in der Standardisierung von + Namensschreibweisen oder der generellen Datenerfassung.<note type="footnote"> + Vgl. <ref type="bibliography" target="#georgala_record_2015">Georgala et al. 2015</ref>, S. 173.</note> + </p> + <p>Zum Record Linkage können verschiedenste Variablen herangezogen werden. + Grundlegend dabei ist, dass Variablen / Attribute zur Verfügung stehen, die + einen identischen Schlüssel aufweisen.<note type="footnote"> Vgl. <ref type="bibliography" target="#baxter_methods_2003">Baxter et al. + 2003</ref>, S. 2.</note> Dies kann beispielsweise der Name, das Geburtsdatum + oder die Sozialversicherungsnummer sein. Auch können Graphen genutzt werden, um + die Ähnlichkeit der Records untereinander darzustellen.<note type="footnote"> + Die Qualität der Verknüpfungen wird dabei besser, wenn man zeitliche + Restriktionen einbeziehe, beispielsweise des möglichen + Schwangerschaftszeitraums der Frau. Vgl. <ref type="bibliography" target="#nanayakkara_clustering_2018">Nanayakkara et al. + 2018</ref>.</note> Um die Daten zu vergleichen, ist eine vorhergehende + Bereinigung notwendig.<note type="footnote"> Vgl. <ref type="bibliography" target="#gellatly_populations_2015">Gellatly 2015</ref>, S. 116.</note> + </p> + <p>Gellatly testet einen Ansatz, bei dem er verschiedene Variablen kombiniert und + im Folgenden analysiert, welche Kombinationen die besten Ergebnisse erzielen. + Diese erreicht er bei einer Kombination von Geburtsjahr (nicht das exakte + Datum), Geschlecht, Nachname, einer Variable, die sich aus der Anzahl von + Brüdern und Schwestern zusammensetzt, und den ersten drei Buchstaben des + Vornamens.<note type="footnote"> Vgl. <ref type="bibliography" target="#gellatly_populations_2015">Gellatly 2015</ref>, S. 122f.</note> + </p> + <p>Efremova et al. nutzen dahingegen ein ›disjunctive blocking‹.<note + type="footnote"> Vgl. <ref type="bibliography" target="#efremova_entity_2015">Efremova et al. 2015</ref>.</note> Darin werden die ersten + Buchstaben eines Namens einer phonetischen Analyse unterzogen. Nur, wenn diese + einen gewissen Grad an Ähnlichkeit aufweisen, wird das Record Linkage + fortgesetzt. Im folgenden Schritt wird die Similarität zwischen verschiedenen + Records berechnet. Die besten Ergebnisse erhalten sie unter Hinzuziehung der + Namenshäufigkeit innerhalb der untersuchten Datenbank sowie der geografischen + Distanz.</p> + <p>Statt einer binären Verknüpfung (Zuordnung / keine Zuordnung) gibt es auch + Systeme, die Abstufungen verwenden. Sichere Verknüpfungen werden darin anders + bewertet als unsichere.<note type="footnote"> Vgl. <ref type="bibliography" target="#thorvaldsen_record_2015">Thorvaldsen et al. 2015</ref>, S. + 163f.</note> Thorvaldsens automatisierte Anwendung auf norwegische Daten + nimmt viele Verknüpfungen aufgrund von Ungewissheit nicht automatisch vor und + lässt einen beträchtlichen Spielraum für die (nachfolgende) manuelle + Verknüpfung.<note type="footnote"> Vgl. <ref type="bibliography" target="#thorvaldsen_record_2015">Thorvaldsen et al. 2015</ref>, S. + 168.</note> + </p> + <p>Anhand englischer Daten zeigen Georgala et al., dass String-Metriken wie die + Levenshtein- oder Jaro-Winkler-Distanz besser als phonetische + Ähnlichkeitsanalysen funktionieren, diese jedoch wiederum deutlich bessere + Ergebnisse aufweisen als eine absolute Gleichheit der Namen.<note + type="footnote"> Vgl. <ref type="bibliography" target="#georgala_record_2015">Georgala et al. 2015</ref>, S. 187.</note> + </p> + <p>Zur Unterstützung des Record Linkage existieren verschiedene Programme. In + diese soll hier nicht im Detail eingeführt werden. Beispielhaft genannt wird + eine Lösung, die explizit auf das Record Linkage von genealogischen + GEDCOM-Dateien (GEnealogical Data COMmunication, siehe unten) ausgelegt ist: <bibl> + <title type="desc">GedTool</title> + </bibl>.<note type="footnote"> Vgl. <ref type="bibliography" target="#schulz_gedtool_2017">Schulz 2017</ref>.</note> Zur Verschmelzung + von Personen können darin bis zu acht Kriterien wie der Vorname, der Nachname + oder eine ID bestimmt werden, die übereinstimmen müssen, damit Personen + verschmolzen werden können. Die Einträge, auf die die Kriterien zutreffen, + werden gemeinsam angezeigt und können dann nachfolgend manuell zusammengeführt + werden. Eine phonetische Suche mit den Algorithmen Soundex, Kölner + Phonetik und Double Metaphone kann ebenfalls ausgeführt werden.<note type="footnote"> Die + Programmierung dieser Funktionen ist jedoch nicht nachvollziehbar, da es + sich um ein kommerzielles Produkt handelt und der Code des Programms (es + handelt sich um Excel-Makros) nicht einsehbar ist.</note> Hierbei handelt es + sich also um eine semi-automatisierte Lösung.</p> + <p>Ein weiteres Record-Linkage-Programm stellt <bibl> + <title type="desc">Demolink</title> + </bibl> dar. Fure evaluiert dieses anhand norwegischer Daten und kommt zu dem + Schluss, dass eine Vorstellung über den historischen Kontext einer Quelle + notwendig ist, um – im Vergleich mit einer automatisierten Lösung – gute + Ergebnisse zu erzielen. Damit meint sie, dass die Forschenden z. B. Wissen + darüber haben müssen, welche Namen im untersuchten Gebiet gleich sind, ohne + dass ein Algorithmus sie zuordnen kann. Ein Beispiel dafür ist, dass die Namen + Goldberg und Goldbrich in Nordböhmen und der südlichen Oberlausitz bis etwa zur + zweiten Hälfte des 18. Jahrhunderts synonym verwendet werden. Hierzu seien + menschliche Eigenschaften notwendig.<note type="footnote"> Vgl. <ref type="bibliography" target="#fure_record_2000">Fure + 2000</ref>.</note> + </p> + <p>Abramitzky et al. zeigen jedoch auf, dass auch automatisierte Vorgehensweisen + zufriedenstellende Ergebnisse erzielen können.<note type="footnote"> Vgl. + <ref type="bibliography" target="#abramitzky_linking_2021">Abramitzky et al. 2021</ref>.</note> Da nie mit Sicherheit bestimmt werden kann, + ob zwei Records tatsächlich dieselbe Entität beschreiben, sind solche Vorgehen + probabilistisch. Bei einem Vergleich verschiedener Methoden durch Abramitzky et al. erreichen auch automatisierte Ansätze Falschpositivraten von unter fünf Prozent. Zudem zeigen sie, dass auch Menschen nicht frei von Fehlern sind und ebenfalls falschpositive Ergebnisse erzeugen.<note + type="footnote"> Vgl. <ref type="bibliography" target="#abramitzky_linking_2021">Abramitzky et al. 2021</ref>, S. 865.</note> In ihrem + automatischen Ansatz demonstrieren Abramitzky et al. ein dreischrittiges + Verfahren: Zunächst sind (1.) Variablen für die Verknüpfung auszuwählen, dann + setzen sie (2.) mit dem Expections-Maximization-Algorithmus einen Algorithmus + zur Berechnung der Wahrscheinlichkeit der Übereinstimmung von zwei Datensätzen + ein, schließlich wird (3.) die Wahrscheinlichkeit der Übereinstimmung + bewertet.<note type="footnote"> Vgl. <ref type="bibliography" target="#abramitzky_linking_2020">Abramitzky et al. 2020</ref>, S. 94.</note> + Die hohe Verlässlichkeit ihrer Vorgehensweise zeigt sich darin, dass sie bei + der Berechnung der beruflichen und intergenerationalen Mobilität aus ihren + Verknüpfungen ihrer Daten ähnliche Resultate wie in bereits bestehenden, + manuellen Verknüpfungen erhalten.<note type="footnote"> Dieses stellt zugleich + ein geeignetes Beispiel für die Anwendung und den Nutzen von + Record-Linkage-Algorithmen in der ökonomischen Forschung dar. Vgl. + <ref type="bibliography" target="#abramitzky_linking_2020">Abramitzky et al. 2020</ref>, S. 106f.</note> + </p> + </div> + <div type="subchapter"> + <head>2.2 Format genealogisch-prosopographischer Datenbestände</head> + + <p>Besonders interessant erscheint die Anwendung eines automatisierten Record + Linkage auf große Datenbestände mit genealogisch relevanten Daten. Das Record + Linkage muss dabei jedoch immer auch die besondere Struktur der Daten + betrachten. Genealogisch relevante Datenbestände weisen andere Besonderheiten + auf als einfache Listen, beispielsweise Notenlisten von Schulen. Oftmals stehen + dabei in genealogischen Datenbeständen im deutschsprachigen Raum fünf + Lebensereignisse im Zentrum: Geburten, Taufen, Heiraten, Todesfälle und + Beerdigungen. Die Erfassung dieser Aspekte bildet ein Grundgerüst zur + Beschreibung eines individuellen Lebensverlaufs. Daneben werden oft weitere + Informationen wie Wohnorte oder Berufsangaben, vor allem aber die Verknüpfung + zu den Eltern und Kindern ergänzt.</p> + <p>Quellen, die genealogisch relevante Daten enthalten, sind sehr unterschiedlich + strukturiert. Die zugrundeliegenden Primärquellen sind oftmals Manuskripte. + Hier sind vorwiegend Kirchenbücher zu nennen. Verschiedene prosopographische + Quellen enthalten dabei unterschiedliche Informationen.<note type="footnote"> + Efremova et al. nennen beispielsweise Variablen, die sie aus der Analyse von + Geburts-, Todes- und Heiratsdokumenten erhalten. Vgl. <ref type="bibliography" target="#efremova_entity_2015">Efremova et al. 2015</ref>, + S. 132.</note> Allerdings existiert auch eine große Menge an + Sekundärquellen, die bereits aufgearbeitete Daten präsentieren. Solche Daten + können dabei unterschiedlich und höchst individuell strukturiert sein, + beispielsweise als Fließtext in Chroniken vorliegen oder in Stammtafeln + abgedruckt sein. Auch im digitalen Raum existieren mannigfaltige Formate. Hier + haben sich allerdings auch spezielle Austauschformate für genealogische Daten + entwickelt.</p> + <p>Für diese Studie wird davon ausgegangen, dass einzelne Quellen so aufgearbeitet + werden können, dass sie in einer Tabelle vorliegen. Jeder Eintrag der Quelle + entspricht einer Zeile (i. d. R. eine Person), jede Spalte hingegen einem + Datenfeld in der Quelle. Die in einer Zeile enthaltenen Informationen werden im + Weiteren als Record bezeichnet. Herausforderung hierbei ist, dass die + Datenfelder / Spalten tatsächlich vergleichbare Informationen enthalten müssen. Die + Zuordnung von Informationen aus einer Quelle in die korrekten Datenfelder ist + dadurch schwierig, dass trotz gleicher Bezeichnung in den Originalquellen + unterschiedliche Informationen gemeint sein können. Zum Beispiel kann mit dem + <quote>Stand</quote> in einer Quelle der Beruf (z. B. <quote>Müller</quote>) + gemeint sein oder aber der Familienstand (z. B. <quote>verheiratet</quote>). + Für ein Record Linkage zwischen verschiedenen Datenbeständen ist also die + Definition des Inhalts der Datenfelder unerlässlich.</p> + <p>Als wesentlicher Standard zum Austausch genealogischer Informationen hat sich + das GEDCOM-Format herausgebildet.<note type="footnote"> Vgl. <ref type="bibliography" target="#gellatly_populations_2015">Gellatly 2015</ref>, S. + 112; <ref type="bibliography" target="#harviainen_genealogy_2018">Harviainen / Björk 2018</ref>, S. 4.</note> In diesem werden einzelne + Informationen sogenannten Tags zugewiesen, die eine ähnliche Funktion wie + Datenfelder / Spalten haben (z. B. beschreibt der Tag OCCU eine Berufsangabe). + Aber auch aus GEDCOM-Daten ergeben sich Probleme: Zwar sind diese strukturiert, + doch gibt es nicht für alle Informationen eigene Tags. Auch wenn mit GEDCOM 5.5.1 ein Standard existiert,<note type="footnote"> Vgl. <ref type="bibliography" target="#church_gedcom_2019">The Church of Jesus + Christ of Latter-day Saints 2019</ref>.</note> legt dieser nicht immer fest, welcher Inhalt den Tags zugeordnet werden darf. Im Standard ist + beispielsweise für die Nennung von Ortsangaben eine Trennung der + administrativen Gliederungsebenen durch ein Komma vorgesehen. Nutzer*innen + jedoch müssen sich daran nicht halten, sondern können diese ›Freitextfelder‹ + ausfüllen, wie es ihnen beliebt und wie sie diese interpretieren.</p> + <p>Einen weiteren Standard stellt Gedbas4all dar.<note type="footnote"> Vgl. + <ref type="bibliography" target="#vfc_datenmodell_2016">Verein für Computergenealogie 2016a</ref>.</note> Anders als GEDCOM, in der die + einzelnen Informationen zu einer Person zwar zusammengeführt, die + zugrundeliegenden Quellen aber schlecht nachvollziehbar sind, basiert dieses + Modell auf einer Verknüpfung von Records, die im Nachhinein wieder voneinander + gelöst werden können. In dem Datenmodell gibt es einige Variablen, die auch + konkret definiert wurden. Besonders für die Zeitangaben gibt es eine + detaillierte Normierung.<note type="footnote"> Vgl. <ref type="bibliography" target="#vfc_datumsangaben_2016">Verein für + Computergenealogie 2016b</ref>.</note> Das Datenmodell enthält jedoch nicht zu + allen möglichen Variablen eine detaillierte Erläuterung. Zudem hat es noch + keine weite Verbreitung gefunden.</p> + <p>Es zeigt sich, dass kein allgemeingültiges und ausreichend detailliertes System + zur Definition vieler möglicher Schlüssel für ein Record Linkage auf Basis + zahlreicher Variablen existiert. Darum werden im Folgenden mögliche Datenfelder + im Rahmen der Entwicklung des Algorithmus definiert.</p> + </div> + </div> + <div type="chapter"> + <head>3. Algorithmus zum Record Linkage</head> + + <p>Die oben aufgeführten Algorithmen scheinen auf ihre jeweiligen Anwendungen bezogen + zwar effektiv zu sein, doch können sie nicht auf alle + prosopographischen Quellen übertragen werden. Eine allgemeingültige Lösung für + alle deutschsprachigen Quellen kann auch hier nicht entwickelt werden. Die + aufgezeigte Lösung aber bildet viele mögliche Fälle bereits ab und stellt eine + geeignete Grundlage zur weiteren Anpassung dar. Das Ergebnis ist also nicht nur auf eine einzelne Anwendung angepasst, sondern kann für verschiedene + prosopographische Quellen (speziell solche mit einer hohen Dichte genealogisch relevanter Informationen) adaptiert werden. Auch wird einem weiteren bestehenden + Nachteil der dargestellten Ansätze begegnet, welche vorwiegend auf + englischsprachige, norwegische oder niederländische Datensätze angewendet wurden: + Es gibt in jeder Sprache Besonderheiten, die es zu berücksichtigen gilt, auch die + deutsche Sprache stellt keine Ausnahme dar. Der im Folgenden vorgestellte + Algorithmus ist daher nur mit deutschsprachigen Daten kompatibel und nimmt + Rücksicht auf die phonetischen Besonderheiten der deutschen Sprache. Auch hier + kann jedoch eine Anpassung vorgenommen werden, indem Regeln weiterer Sprachen + integriert werden. Da es einen in dieser Art ausgestalteten Algorithmus bislang + nicht gab, wird hier eine Forschungslücke geschlossen. Aufbauend auf dem Forschungsstand verwendet dieser besonders solche Metriken und Verfahren, die sich in den dargestellten Lösungen als tauglich erwiesen haben.</p> + <p>Der Algorithmus wird im Folgenden textuell erklärt. Die Erläuterung orientiert + sich am Aufbau der programmtechnischen Umsetzung. Es ist insbesondere auch ein + Anspruch, den Quellcode zugänglich zu machen und so eine Anpassung an die + jeweilige Herausforderung zu ermöglichen. Hierzu wird der Algorithmus in der + Programmiersprache Python 3.8 umgesetzt. Dieser ist im <ref + target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-record" + >Online-Repositorium</ref> verfügbar.</p> + <p>Wesentliche Herausforderungen bestehen in der Normierung, Strukturierung und + Bereinigung von Eingangsdaten sowie der Prüfung einer Similarität zwischen + verschiedenen Records. Die Bereinigung der Daten ist eine Voraussetzung für die + Prüfung der Similarität der Datensätze; letztere wiederum stellt eine notwendige + Bedingung zur Verknüpfung im Zuge des Record Linkage dar. Im folgenden Abschnitt + wird zunächst eine detaillierte Übersicht über den Algorithmus gegeben. Danach + wird eine Normalform der Daten definiert (im Weiteren Normform), in die die + Eingangsdaten gebracht werden müssen. Dies geschieht, damit die Datenfelder / + Spalten gleichartige Daten enthalten. Daran anschließend wird die Datenbereinigung + und -strukturierung behandelt, bevor die genealogischen Heuristiken, die dem + Vergleich zweier Records dienen, formalisiert werden. Abschließend wird bestimmt, + in welcher Form die Zusammenführung der Records geschieht.</p> + <div type="subchapter"> + <head>3.1 Funktionsweise des Algorithmus</head> + <p>Der Algorithmus ist auf prosopographische Quellen angepasst, die genealogisch + relevante Daten enthalten. Es ist denkbar, dass es viele prosopographische + Quellen gibt, die Daten enthalten, welche durch die Normform nicht adäquat + abgebildet werden (z. B. Immatrikulationslisten). Hier wird deutlich, dass + nicht alle erdenklichen (und praktisch auch irgendwo vorkommenden) Attribute + prosopographischer Quellen Einbindung finden können. Nichtsdestotrotz wird mit + jeder Information, die nicht genutzt wird, eine Möglichkeit verworfen, das + Record Linkage positiv zu beeinflussen. In Fällen besonderer Relevanz + spezieller Variablen für eine Aufgabenstellung sollten diese im Algorithmus + ergänzt werden.</p> + <p>Der grundlegende Ablauf zur Verarbeitung der Daten ist in <ref type="graphic" + target="#record_2022_001">Abbildung 1</ref> ersichtlich. Um den Algorithmus + ausführen zu können, müssen die Daten aufbereitet werden. Das kann manuell, + aber auch durch ein gesondertes Programm geschehen.<note type="footnote"> In + vielen Fällen werden die Spaltenüberschriften anzupassen und deren Inhalt + entsprechend zuzuordnen sein. Mit tabellarisch vorliegenden Informationen + ist die Umsetzung dieses Schrittes vergleichsweise einfach durchführbar. + Liegen die Daten als Fließtext vor, so müssen diese zunächst in ein + tabellarisches Format überführt werden. Anders sieht das jedoch bei + GEDCOM-Dateien aus, die zwar auch Fließtext darstellen, jedoch gut genug + strukturiert sind, um sie in ein entsprechendes tabellarisches Format zu + überführen. Dazu bietet sich ein GEDCOM-Parser an, welcher in gängigen + Genealogieprogrammen enthalten ist.</note> Der Algorithmus ist darauf + ausgelegt, zwei in der Normform vorliegende Datensätze dem Record Linkage zu + unterziehen.<note type="footnote"> Sollten mehr als zwei Datensätze + verglichen werden, so sind zunächst zwei auszuwählen und zusammenzuführen. + Da das aus dem Record Linkage resultierende Ergebnis ebenfalls der Normform + entspricht, kann das Ergebnis mit weiteren Dateien verglichen werden. + Dadurch können theoretisch unendlich viele Datensätze miteinander verbunden + werden.</note> Nach der Zusammenführung kann der entstandene, verknüpfte + Datensatz dann in weitere, übliche Formate wie z. B. GEDCOM übertragen werden. + Zur Erstellung einer GEDCOM-Datei aus dem Ergebnis des Algorithmus kann + beispielsweise das bereits im Forschungsstand erwähnte Programm <bibl> + <title type="desc">GedTool</title> + </bibl> genutzt werden. Die konkrete Umwandlung des Ergebnisses in eine + GEDCOM-Datei findet hier jedoch keine weitere Erläuterung, sondern ist der + Bedienungsanleitung des Programms zu entnehmen.<note type="footnote"> Vgl. + <ref type="bibliography" target="#schulz_gedtool_2017">Schulz 2017</ref>.</note> + </p> + <figure> + <graphic xml:id="record_2022_001" url=".../medien/record_2022_001.png"> + <desc> + <ref type="graphic" target="#abb1">Abb. 1</ref>: Ablauf der + Datenverarbeitung. [Goldberg / Mernitz 2023]<ref type="graphic" + target="#record_2022_001"/> + </desc> + </graphic> + </figure> + <p>Nach der Transformation in die Normform wird eine Bereinigung und weitere + Strukturierung der Informationen vorgenommen. Dieser Schritt ist notwendig, + beispielsweise um Abkürzungen zu entfernen und Schreibfehler zu + korrigieren.</p> + <p>Nachfolgend wird ein Vergleich zwischen einzelnen Records erzeugt. Für jede + Zeile in der ersten Tabelle wird dazu geprüft, ob die einzelnen Records der + zweiten Tabelle disjunkt sind, also nicht dieselbe Person abbilden. Hierzu sind + verschiedene genealogische Regeln implementiert, die eine Zusammenführung + ausschließen sollen (z. B. ist eine Taufe nach dem Tod nicht möglich).</p> + <p>Danach wird für die nichtdisjunkten Records eine Similaritätsprüfung + durchgeführt. Hierdurch soll herausgefunden werden, ob die Personen similär + sind – also diese beiden Records dieselbe historisch existierende Person + beschreiben und die Informationen entsprechend zu verknüpfen sind. Hierzu + werden die Namen verglichen. Bei einem Wert von 1 wird eine vollständige + Similarität der verglichenen Personen indiziert, bei 0 eine Abwesenheit dieser. + Daneben können bei uneindeutiger Similarität auch Zwischenwerte erreicht + werden. Dadurch wird ein graphbasierter Ansatz implementiert, in dem jeder + Record im ersten Datensatz zu jedem im zweiten eine gewichtete Beziehung + aufweist. Zudem ist dieser Ansatz probabilistisch, da oftmals nicht mit + Sicherheit von einer Similarität ausgegangen werden kann.</p> + <p>Der grundlegende Ablauf ist in <ref type="graphic" target="#record_2022_002" + >Abbildung 2</ref> dargestellt. Eine ausführliche Erläuterung der einzelnen + Schritte findet in den folgenden Abschnitten statt.</p> + <figure> + <graphic xml:id="record_2022_002" url=".../medien/record_2022_002.png"> + <desc> + <ref type="graphic" target="#abb2">Abb. 2</ref>: Funktionsweise des + Algorithmus als Nassi-Shneiderman-Diagramm. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_002"/> + </desc> + </graphic> + </figure> + </div> + <div type="subchapter"> + <head>3.2 Definition der Normform</head> + <p>Um Daten in eine Normform zu überführen, ist die Definition einer solchen + notwendig. Das umfasst (1.) die Definition eines Formats und (2.) die + Definition des Inhalts (die möglichen Schlüssel der Variablen / Attribute). Zum + Format wird festgelegt, dass es sich bei der Normform um eine CSV-Datei + handelt. Dies stellt ein gängiges Format zur Darstellung von tabellarischen + Informationen dar. Als Trennzeichen wird der Tabstopp festgelegt. Jede Zeile + stellt einen Record dar. Bei der Definition des Spalteninhalts ist darauf zu + achten, dass sie bestmöglich einem intuitiven Verständnis entspricht (vgl. <ref type="intern" target="#tab01">Tabelle 1</ref>). Auch wenn der + Inhalt zwar definiert wird, ist nicht davon auszugehen, dass in jedem Fall vor + einer Eintragung von Daten zunächst die Beschreibung studiert wird.</p> + <table> + <row role="label"> + <cell>Bezeichnung</cell> + <cell>Inhalt</cell> + </row> + <row> + <cell>id</cell> + <cell>Diese Spalte enthält eine Abfolge von Zeichen, die innerhalb des + Datensatzes einmalig je Eintrag ist. Falls die Spalte in einem Datensatz + nicht vorhanden ist, so wird diese nachträglich erzeugt und allen + Einträgen wird eine eindeutige ID zugeordnet. Es ist darauf zu achten, + dass Tabellen aus unterschiedlichen Quellen auch unterschiedliche IDs + aufweisen.</cell> + </row> + <row> + <cell>firstnameGiven</cell> + <cell>Diese Spalte enthält die Vornamen. Sind mehrere Vornamen vorhanden, so + sind diese mit einem Leerzeichen voneinander zu trennen. </cell> + </row> + <row> + <cell>firstnameChange</cell> + <cell>Diese Spalte enthält Informationen über die Änderung des Vornamens. Es + handelt sich also um einen alternativen Vornamen.</cell> + </row> + <row> + <cell>sex</cell> + <cell>Diese Spalte enthält eine Information über das Geschlecht (›F‹ für + weiblich, ›M‹ für männlich und eine leere Zelle für unbestimmte + Geschlechter).</cell> + </row> + <row> + <cell>surnameGiven</cell> + <cell>Diese Spalte enthält die Information über den Nachnamen bei der + Geburt.</cell> + </row> + <row> + <cell>surnameChange</cell> + <cell>Diese Spalte enthält die Information über eine Änderung des Nachnamens + nach der Geburt, aber vor der Heirat. Das kann beispielsweise dadurch + erfolgen, dass eine Person adoptiert wird oder aber die Eltern nach der + Geburt heiraten.</cell> + </row> + <row> + <cell>surnameMarriage1, surnameMarriage2, surnameMarriage3</cell> + <cell>Diese Spalte enthält die Änderung des Nachnamens im Zuge einer ersten, + zweiten oder dritten Hochzeit. Wenn im Zuge der Heirat keine + Namensänderung stattgefunden hat, bleibt sie leer.</cell> + </row> + <row> + <cell>surnameUnknown</cell> + <cell>Diese Spalte enthält den Nachnamen, wenn nicht klar ist, zu welchem + Ereignis diesen jemand erlangt hat.</cell> + </row> + <row> + <cell>birthday</cell> + <cell>Diese Spalte enthält den Tag der Geburt. Hier ist nur der Tag in dem + Format DD.MM.YYYY einzutragen, ohne eine weitere Spezifikation der + Uhrzeit. Die GEDCOM-Systematik zur Beschreibung ungenauer Zeitpunkte ist + anzuwenden (z. B. ›BET … AND …‹ für ein Ereignis in einer + Zeitspanne).</cell> + </row> + <row> + <cell>birthplace</cell> + <cell>Diese Spalte enthält den Ort der Geburt. Hier ist nur die Stadt + anzugeben, keine weiteren Adressen.</cell> + </row> + <row> + <cell>birthplaceGOV</cell> + <cell>Diese Spalte enthält die GOV-Kennung (Geschichtliches + Orts-Verzeichnis, siehe unten) des Geburtsortes.</cell> + </row> + <row> + <cell>growthUpPlace</cell> + <cell>Diese Spalte enthält Informationen über die Herkunft einer Person, + wenn der Geburtsort nicht näher zu bestimmen ist. Beispielhaft dafür sind + Angaben wie »aus […]«. Auch kann der Geburtsort von dem Wohnort der + Eltern abweichen. Letzterer ist hier einzutragen.</cell> + </row> + <row> + <cell>growthUpPlaceGOV</cell> + <cell>Diese Spalte enthält die GOV-Kennung des Herkunftsortes.</cell> + </row> + <row> + <cell>baptismday</cell> + <cell>Diese Spalte enthält den Tag der Taufe. Hier ist nur der Tag in dem + Format DD.MM.YYYY einzutragen, ohne eine weitere Spezifikation der + Uhrzeit. Die GEDCOM-Systematik zur Beschreibung ungenauer Zeitpunkte ist + anzuwenden (z. B. ›BET … AND …‹ für ein Ereignis in einer + Zeitspanne).</cell> + </row> + <row> + <cell>baptismplace</cell> + <cell>Diese Spalte enthält den Ort der Geburt. Hier ist ein Ort einzutragen + und nicht die entsprechende Kirche. Hier ist nur die Stadt anzugeben, + keine weiteren Adressen.</cell> + </row> + <row> + <cell>baptismplaceGOV</cell> + <cell>Diese Spalte enthält die GOV-Kennung des Taufortes.</cell> + </row> + <row> + <cell>marriageday1, marriageday2, marriageday3</cell> + <cell>Diese Spalte enthält den Tag der ersten, zweiten oder dritten + Hochzeit. Hier ist nur der Tag in dem Format DD.MM.YYYY einzutragen, ohne + eine weitere Spezifikation der Uhrzeit. Die GEDCOM-Systematik zur + Beschreibung ungenauer Zeitpunkte ist anzuwenden (z. B. ›BET … AND …‹ für + ein Ereignis in einer Zeitspanne).</cell> + </row> + <row> + <cell>marriageplace1, marriageplace2, marriageplace3</cell> + <cell>Diese Spalte enthält den Ort der ersten, zweiten oder dritten Heirat. + Hier ist nur die Stadt anzugeben, keine weiteren Adressen.</cell> + </row> + <row> + <cell>marriageplaceGOV1, marriageplaceGOV2, marriageplaceGOV3</cell> + <cell>Diese Spalte enthält die GOV-Kennung des ersten, zweiten oder dritten + Heiratsorts. </cell> + </row> + <row> + <cell>ageAtMarriage1, ageAtMarriage2, ageAtMarriage3</cell> + <cell>Diese Spalte enthält Angaben zum Alter bei der ersten, zweiten oder + dritten Hochzeit in Jahren.</cell> + </row> + <row> + <cell>idSpouse1, idSpouse2, idSpouse3</cell> + <cell>Diese Spalte enthält die ID des*der ersten, zweiten oder dritten + Ehepartner*in in dem gleichen Datensatz.</cell> + </row> + <row> + <cell>divorceday1, divorceday2, divorceday3</cell> + <cell>Diese Spalte enthält den Tag der ersten, zweiten oder dritten + Scheidung. Hier ist nur der Tag in dem Format DD.MM.YYYY einzutragen, + ohne eine weitere Spezifikation der Uhrzeit. Die Gedbas4All-Systematik + zur Beschreibung ungenauer Zeitpunkte ist anzuwenden.</cell> + </row> + <row> + <cell>deathday</cell> + <cell>Diese Spalte enthält den Tag des Todes. Hier ist nur der Tag in dem + Format DD.MM.YYYY einzutragen, ohne eine weitere Spezifikation der + Uhrzeit. Die GEDCOM-Systematik zur Beschreibung ungenauer Zeitpunkte ist + anzuwenden (z. B. ›BET … AND …‹ für ein Ereignis in einer + Zeitspanne).</cell> + </row> + <row> + <cell>deathplace</cell> + <cell>Diese Spalte enthält den Ort des Todes. Hier ist nur die Stadt + anzugeben, keine weiteren Adressen.</cell> + </row> + <row> + <cell>deathplaceGOV</cell> + <cell>Diese Spalte enthält die GOV-Kennung des Todesorts.</cell> + </row> + <row> + <cell>causeOfDeath</cell> + <cell>Diese Spalte enthält die Todesursache. Verschiedene Todesursachen sind + mit Komma und nachfolgendem Leerzeichen oder einem ›und‹ mit vor- und + nachstehendem Leerzeichen abzugrenzen.</cell> + </row> + <row> + <cell>maritalStatusAtDeath</cell> + <cell>Diese Spalte enthält eine Information über den Familienstand beim Tod. + Eine Benennung als Witwer beispielsweise kann darauf hindeuten, dass die + Frau früher verstorben sein muss.</cell> + </row> + <row> + <cell>ageAtDeath</cell> + <cell>Diese Spalte enthält eine Information über das Lebensalter beim + Tod.</cell> + </row> + <row> + <cell>burialday</cell> + <cell>Diese Spalte enthält den Tag der Beerdigung. Hier ist nur der Tag in + dem Format DD.MM.YYYY einzutragen, ohne eine weitere Spezifikation der + Uhrzeit. Die GEDCOM-Systematik zur Beschreibung ungenauer Zeitpunkte ist + anzuwenden (z. B. ›BET … AND …‹ für ein Ereignis in einer + Zeitspanne).</cell> + </row> + <row> + <cell>burialplace</cell> + <cell>Diese Spalte enthält den Ort der Beerdigung. Hier ist nur die Stadt + anzugeben, keine weiteren Adressen.</cell> + </row> + <row> + <cell>burialplaceGOV</cell> + <cell>Diese Spalte enthält die GOV-Kennung des Beerdigungsortes.</cell> + </row> + <row> + <cell>occupation</cell> + <cell>Diese Spalte enthält Informationen zum Beruf. Verschiedene + Berufsangaben sind mit Komma und nachfolgendem Leerzeichen oder einem + ›und‹ mit vor- und nachstehendem Leerzeichen abzugrenzen.</cell> + </row> + <row> + <cell>idFather</cell> + <cell>Diese Spalte enthält die ID des Vaters innerhalb dieses + Datensatzes.</cell> + </row> + <row> + <cell>idMother</cell> + <cell>Diese Spalte enthält die ID der Mutter innerhalb dieses + Datensatzes.</cell> + </row> + <trailer xml:id="tab01"> + <ref type="intern" target="#tab1">Tab. 1</ref>: Definition von Datenfeldern. + [Goldberg / Mernitz 2023]<ref type="graphic" target="#record_2022_t1"/> + </trailer> + </table> + + <p>Die Normform enthält dabei nicht alle möglichen Bestandteile prosopographischer + Quellen. Daneben sind weitere Charakteristika denkbar, die sich auf das Leben + von Personen beziehen und in prosopographischen Quellen vorkommen (u. a. + Taufpaten, Trauzeugen, Täufer, weitere Bezugspersonen, Adressen zu bestimmten + Zeitpunkten, Quellenangaben, Angaben zu weiteren religiösen Feierlichkeiten wie + der Firmung oder Konfirmation). Da es hier aber unwahrscheinlich ist, dass + diese Informationen in zwei Datensätzen vorkommen, die auf verschiedenen + Quellen basieren und diese teilweise zudem automatisiert schwer zu vergleichen + wären, finden diese keinen Einzug. Es kann im Einzelfall jedoch essenziell + sein, diese Informationen zu ergänzen und den Algorithmus dahingehend zu + erweitern.</p> + </div> + <div type="subchapter"> + <head>3.3 Datenbereinigung und -strukturierung</head> + <p>Trotz der Normform können die Daten nicht immer direkt miteinander in einen + Vergleich gesetzt werden. Es ist eine weitere Bereinigung des Inhalts + notwendig. Darunter gehört z. B. die Veränderung des Datumsformats. Ferner + betrifft die Bereinigung insbesondere die Vornamen (siehe <ref type="intern" target="#hd9">Abschnitt 3.3.1</ref>, ›Aufbereitung der + Namen‹). Sind mehrere Vornamen vorhanden, so werden diese in einer Liste + voneinander separiert. Ebenso werden die Berufsangaben aufbereitet (siehe <ref type="intern" target="#hd10">Abschnitt 3.3.2</ref>, ›Aufbereitung der Berufsangaben‹). Auch hier werden mehrere Berufe voneinander + getrennt. In einem folgenden Schritt werden die Datumsfelder zur Geburt, Taufe, + Heirat, dem Tod oder der Beerdigung korrigiert (siehe <ref type="intern" target="#hd11">Abschnitt 3.3.3</ref>, ›Aufbereitung der + Zeitangaben‹). Die Bereinigung von Ortsangaben dahingegen ist derzeit nicht + implementiert, kann aber ergänzt werden.<note type="footnote"> Ortsangaben + unterliegen einer breit gefächerten Variation. Insbesondere, ob und wie + übergeordnete administrative Einheiten in die Angabe mit eingebunden werden, + ist in der Praxis uneinheitlich. Hierbei ist die Verwendung von eindeutigen + Identifikatoren für Orte sehr hilfreich. Als Identifikatoren für Orte sind + die IDs des Geschichtlichen Orts-Verzeichnis (GOV) zu empfehlen. Vgl. + <ref type="bibliography" target="#vfc_kartei_2019">Verein + für Computergenealogie 2021</ref>. Die Datenbank des Vereins für + Computergenealogie bildet hier insbesondere für den deutschen Sprachraum + eine geeignete Repräsentation tatsächlich (vormals) vorhandener Orte. + Aufgrund einer langen Zeit geringer Mobilität insbesondere der ländlichen + Bevölkerung ist es wahrscheinlicher, dass Lebensereignisse in einer + begrenzten geografischen Distanz stattgefunden haben. Vgl. <ref type="bibliography" target="#baehr_bevoelkerungsgeographie_1992">Bähr et al. + 1992</ref>; <ref type="bibliography" target="#kocka_familie_1980">Kocka et al. 1980</ref>. Für den Erfolg eines Record Linkage kann es also + auch relevant sein, ob Orte geografisch nah beieinander zu finden sind. + Vgl. <ref type="bibliography" target="#efremova_entity_2015">Efremova et al. 2015</ref>, S. 135, 139–141. Die Aufbereitung der Ortsangaben + kann an den von Goldberg definierten, auf den deutschen Sprachraum + abgestimmten Kriterien orientiert sein. Vgl. <ref type="bibliography" target="#goldberg_entscheidungsfindung_2022">Goldberg 2022</ref>. Über das von + Goldberg beschriebene Programm kann auch eine automatische Zuweisung der + GOV-IDs stattfinden.</note> + </p> + <div type="subchapter"> + <head>3.3.1 Aufbereitung der Namen</head> + <p>Namensbezeichnungen können verschiedene Eigenschaften besitzen, die ein + Record Linkage erschweren. Ein Beispiel dafür sind Abkürzungen + (unvollständige Bezeichnungen, die mit einem Punkt abschließen). Abkürzungen + können dabei sehr individuell ausgestaltet sein, aber auch eine große + Intersubjektivität besitzen. Der Algorithmus enthält eine Reihe üblicher + Abkürzungen für Namen. Hier zeigt sich ein weiterer Aspekt der Anpassung der + Lösung an die deutsche Sprache. Je nach zu bearbeitenden Quellen kann es der + Qualität des Ergebnisses dienlich sein, diese Liste zu erweitern oder + anzupassen. Zur weiteren Aufbereitung werden auch Klammern entfernt, die in + Vornamensnennungen vorkommen können, beispielsweise um Aliasnamen wie etwa + »Hans Joseph (Franz)« darzustellen. Mehrere + Vornamen werden durch Leerzeichen separiert als Liste gespeichert.</p> + <p>Um den Nutzen der Vornamen für das Record Linkage zu erhöhen, wird aus den + Angaben zum Vornamen das Geschlecht erkannt – sofern diese Information nicht + gesondert vorliegt. Hierzu werden die Vornamen, die auf ein A oder E enden, + als weiblich erkannt. Dazu wird jeweils der erste Vorname herangezogen.<note + type="footnote"> In der deutschen Sprache enden Frauennamen traditionell + auf A oder E. Zwar tragen auch vereinzelte Männer Frauennamen, häufig + Maria, diesen jedoch kaum als ersten Vornamen. Auf die moderne + Namensgebung passt dieses Muster nicht mehr. Da sich dieser Algorithmus + aber auf historische Daten bezieht, stellt das an dieser Stelle kein + entscheidendes Problem dar.</note> Etliche Ausnahmen sind gesondert + definiert (z. B. Ingeborg, Elisabeth).</p> + </div> + <div type="subchapter"> + <head>3.3.2 Aufbereitung der Berufsangaben</head> + <p>Ähnlich wie bei den Namen können auch Berufsangaben eine Abkürzung erfahren. + Auch diese werden mit Hilfe einer initial definierten Liste aufgelöst und + ausgeschrieben. Die uneindeutige Verwendung von Abkürzungen stellt hier im + Vergleich zu den Vornamen jedoch ein größeres Problem dar. Das betrifft + besonders sehr allgemeine Kürzel, beispielsweise die Abkürzung »K.«, die sowohl auf einen Knaben als auch einen + Kaufmann hindeuten oder möglicherweise auch eine andere Bedeutung haben + kann. Auch kann die Berufsangabe nicht nur Angaben zur beruflichen + Tätigkeit, sondern weitergehende Informationen über den Rechtsstatus, + Wohnsitz oder einen Zeitbezug enthalten.<note type="footnote"> Zur + Separierung solcher berufsfernen Angaben kann auf <ref type="bibliography" target="#goldberg_identifikation_2022">Goldberg / Moeller 2022</ref> hingewiesen werden, die Kriterien zur Bereinigung von Berufsangaben aufstellen.</note> Mehrere Berufsangaben werden + anhand des Kommas oder eines ›und‹ aufgesplittet als Liste gespeichert.</p> + </div> + <div type="subchapter"> + <head>3.3.3 Aufbereitung der Zeitangaben</head> + <p>Zeitangaben können verschiedene Formate aufweisen. Das liegt vor allem in + dem Umstand begründet, dass Zeitangaben nicht immer ein konkretes, + taggenaues Datum bezeichnen, sondern zum Beispiel auch einen Zeitraum + benennen können. Im Algorithmus wird davon ausgegangen, dass die + Datumsangaben bereits in die Normform umgewandelt und im Format DD.MM.YYYY + vorliegen. Eine Ausnahme betrifft Zeiträume, die im GEDCOM-Format ›BET … AND + …‹ formatiert werden. Hier wird die vordere Grenze des Zeitraumes für die + weitere Berechnung herangezogen.</p> + </div> + </div> + <div type="subchapter"> + <head>3.4 Formalisierung von Heuristiken zum Vergleich von Records</head> + <p>Genealogische Heuristiken helfen dabei, die Records zu identifizieren, die + dieselbe Entität beschreiben. Ihre Formalisierung führt zu Logikoperationen, + die programmtechnisch realisiert werden können. Dabei basieren diese Vergleiche + auf den vorhandenen Variablen. Jedoch können schon bei einem Datensatz mit 30 + verschiedenen zu vergleichenden Variablen (Variable vorhanden / nicht + vorhanden) insgesamt etwa eine Milliarde mögliche Kombinationen auftreten.<note + type="footnote"> 2<hi rend="super">30</hi> = 1.073.741.824.</note> Der + Vergleich von zwei Datensätzen erhöht diese Zahl der möglichen Kombinationen + auf mehr als eine Trillion.<note type="footnote"> 1.073.741.824<hi rend="super" + >2</hi> = 1.152.921.504.606.850.000.</note> Für diese Anzahl an + Kombinationen ist eine manuelle Definition von Verarbeitungsfolgen nicht + vorstellbar. Vielmehr muss diese sinnvoll reduziert werden. Dieses wird + erreicht, indem Kombinationen von Variablen ausgeschlossen werden. Beispielhaft + lässt ein Vergleich zwischen Sterbeort und Berufsangabe allein voraussichtlich + keinen Schluss auf den Zusammenhang von Records zu.</p> + <p>Hierzu können zunächst verschiedene Variablen zusammengefasst werden, die + ähnliche Merkmale aufweisen (z. B. Datumsangaben, Ortsangaben, Namen). + Vergleiche sind nur innerhalb dieser Gruppen sinnhaft. Diese Definition + geschieht im <ref type="intern" target="#hd13">ersten Unterabschnitt</ref> (›Definition zu vergleichender Variablen‹). + Im <ref type="intern" target="#hd14">zweiten Unterabschnitt</ref> (›Disjunktionen‹) werden Disjunktionsregeln + beschrieben: Wenn z. B. eine Taufe nach dem Tod stattfindet, dann ist eine + Similarität auszuschließen.<note type="footnote"> Sonderformen bei einzelnen + Glaubensgemeinschaften, z. B. die Totentaufe der Mormonen, bleiben + unberücksichtigt.</note> Es bleibt eine deutlich minimierte Anzahl an + Variablenkombinationen übrig, bei denen ein genauerer Vergleich sinnhaft + erscheint. Im <ref type="intern" target="#hd15">dritten Unterabschnitt</ref> + (›Similaritätsprüfung‹) wird dann der Similaritätsvergleich zwischen zwei + Records beschrieben, die nicht disjunkt sind.</p> + <div type="subchapter"> + <head>3.4.1 Definition zu vergleichender Variablen</head> + + <p>Eine Gruppe von Vergleichen kann vorgenommen werden, wenn in beiden Records + gleichartige Variablen vorliegen. Dazu ist ein Wissen über die Beziehungen + der Variablen untereinander relevant. Hiervon sind insbesondere Zeit- und + Nachnamensangaben betroffen. Bei Zeitangaben sind die zeitlichen Relationen + zwischen Geburts-, Tauf-, Heirats-, Sterbe- und Beerdigungsdatum relevant. + Hierbei ist auch ein Vergleich zu den Lebenszeitangaben der potenziellen + Eltern von Interesse. Nachnamen sind von der Schwierigkeit betroffen, dass + sie im Lebensverlauf starken Veränderungen unterliegen können. Besonders + Frauen wechselten häufig bei Hochzeiten ihre Namen, sodass es keine + Seltenheit darstellt, wenn Personen im Lebensverlauf mit drei oder vier + verschiedenen Nachnamen erscheinen. Deshalb ist ein Vergleich sowohl mit dem + Geburtsnamen als auch mit den Ehenamen relevant. Auch Ortsangaben können + relevant sein, weil es wahrscheinlicher ist, dass verschiedene + Lebensereignisse in einem begrenzten geografischen Radius stattfinden. Da + es sich hierbei jedoch um eine vergleichsweise ungenaue Bestimmung handelt, + ist diese im bisherigen Algorithmus nicht eingebunden. Sie ist dennoch + aufgeführt, um eine Hilfestellung für eine Erweiterung zu bieten. Im + Folgenden werden die Vergleichsgruppen dargestellt und grundsätzliche + Vergleiche eingegrenzt:</p> + <list type="unordered"> + <item>Vornamensvergleiche: firstnameGiven, firstnameChange<list + type="unordered"> + <item>Die (teilweise) Übereinstimmung von Vornamen kann Aufschluss + über die Zusammenführung der Personen liefern.<note type="footnote" + > Der Vergleich darf sich aber nicht nur auf einzelne Vornamen + oder die Reihenfolge der Vornamen beziehen. Beispielsweise + können <quote>Johann</quote> und <quote>Johann Christoph</quote> + dieselbe Person sein, <quote>Johann Christoph</quote> und + <quote>Christoph Johann</quote> können dieselbe Person sein, + <quote>Johann Christoph</quote> und <quote>Christoph + Heinrich</quote> sind aber eher unwahrscheinlich dieselbe + Person.</note> + </item> + </list> + </item> + <item>Geschlechtsvergleiche: sex<list type="unordered"> + <item>Gleiche Personen weisen das gleiche Geschlecht auf.</item> + </list> + </item> + <item>Nachnamensvergleiche: surnameUnknown, surnameGiven, surnameChange, + surnameMarriage1, surnameMarriage2, surnameMarriage3<list + type="unordered"> + <item>Die (teilweise) Übereinstimmung von Nachnamen kann Aufschluss + über die Zusammenführung von Personen liefern, wobei die + Übereinstimmung von Nachnamen in unterschiedlichen Kategorien nur + bei surnameUnknown ein Indiz für eine Übereinstimmung ist.<note + type="footnote"> Beispielsweise ist eine Person, die als + surnameGiven <quote>Schwarzenberg</quote> aufweist, nur in + seltenen Fällen mit einer Person übereinstimmend, die diesen + Namen durch die erste Heirat (surnameMarriage1) erhalten + hat.</note> + </item> + </list> + </item> + <item>Datumsvergleiche: birthday, baptismday, marriageday1, ageAtMarriage1, + divorceday1, marriageday2, ageAtMarriage2, divorceday2, marriageday3, + ageAtMarriage3, divorceday3, deathday, ageOfDeath, burialday<list + type="unordered"> + <item>birthday und baptismday: Taufdatum und Geburtsdatum liegen oft + nah beieinander.<note type="footnote"> Die hier definierten Regeln + passen nur auf solche Religionsgemeinschaften, die die + Kleinkindtaufe praktizieren.</note> Eine Person kann nicht vor + ihrer Geburt getauft werden.</item> + <item>ageAtMarriage1, ageAtMarriage2, ageAtMarriage3 und birthday, + marriageday1, marriageday2, marriageday3: Das Alter bei der Heirat + und das errechnete Alter sollten nahe beieinanderliegen.</item> + <item>marriageday1, marriageday2, marriageday3 und birthday: Eine + Person muss bei einer Heirat ein Mindestalter erreicht + haben.</item> + <item>divorceday1, divorceday2, divorceday3 und birthday: Eine Person + muss bei einer Scheidung ein Mindestalter erreicht haben.</item> + <item>ageAtDeath und birthday, deathday: Das beim Tod errechnete Alter + und das Geburtsdatum dürften nur endlich weit auseinanderliegen. + Eine Person kann nicht vor ihrer Geburt sterben. Totgeburten und + schnelle Todesfälle nach der Geburt können am Geburtstag + auftreten.</item> + <item>birthday, deathday und ageOfDeath: Die Differenz zwischen einem + errechneten Alter und dem angegebenen Alter bei Tod muss gering + sein.</item> + <item>birthday, burialday und ageOfDeath: Die Differenz zwischen einem + errechneten Alter und Berücksichtigung der Angabe des + Beerdigungsdatums und dem angegebenen Alter bei Tod muss gering + sein.</item> + <item>ageAtMarriage1, ageAtMarriage2, ageAtMarriage3 und baptismday, + marriageday1, marriageday2, marriageday3: Das Alter bei der Heirat + und das errechnete Alter sollten nahe beieinanderliegen.</item> + <item>marriageday1, marriageday2, marriageday3 und baptismday: Eine + Person muss bei einer Heirat ein Mindestalter erreicht + haben.</item> + <item>divorceday1, divorceday2, divorceday3 und baptismday: Eine + Person muss bei einer Scheidung ein Mindestalter erreicht + haben.</item> + <item>ageAtDeath und baptismday, deathday: Das beim Tod errechnete + Alter und das Taufdatum dürften nur endlich weit auseinanderliegen. + Eine Person kann nicht vor ihrer Taufe sterben. Allerdings sind + Nottaufen möglich, die am Todestag erfolgen.</item> + <item>baptismday, deathday und ageOfDeath: Die Differenz zwischen + einem errechneten Alter und dem angegebenen Alter bei Tod muss + gering sein.</item> + <item>baptismday, burialday und ageOfDeath: Die Differenz zwischen + einem errechneten Alter und Berücksichtigung der Angabe des + Beerdigungsdatums und dem angegebenen Alter bei Tod muss gering + sein.</item> + <item>marriageday1, marriageday2, marriageday3 und deathday: Die + Hochzeit erfolgt vor dem Tod.</item> + <item>divorceday1, divorceday2, divorceday3 und deathday: Die + Scheidung erfolgt vor dem Tod.</item> + <item>marriageday1, marriageday2, marriageday3 und burialday: Die + Hochzeit erfolgt vor der Beerdigung.</item> + <item>divorceday1, divorceday2, divorceday3 und burialday: Die + Scheidung erfolgt vor der Beerdigung.</item> + <item>divorceday1, divorceday2, divorceday3, deathday: Die Scheidung + erfolgt vor dem Tod.</item> + <item>deathday und burialday: Eine Person kann nicht vor ihrem Tod + beerdigt werden. Beerdigungsdatum und Todesdatum liegen nah + beieinander.</item> + </list> + </item> + <item>Ortsstringvergleiche: birthplace, growthUpPlace, baptismplace, + marriageplace1, marriageplace2, marriageplace3, deathplace, + burialplace<list type="unordered"> + <item>Gleiche oder ähnliche Ortsangaben weisen auf gleiche Personen + hin. Das kann durch eine exakte Übereinstimmung der Strings oder + eine starke Ähnlichkeit erkannt werden.</item> + <item>Die Wahrscheinlichkeit für ein Match ist höher, wenn + beispielsweise Geburtsort und Heiratsort der gleiche sind.</item> + </list> + </item> + <item>Ortsentfernungsvergleiche: birthplaceGOV, growthUpPlaceGOV, + baptismplaceGOV, marriageplaceGOV1, marriageplaceGOV2, marriageplaceGOV3, + deathplaceGOV, burialplaceGOV<list type="unordered"> + <item>growthUpPlaceGOV, birthplaceGOV: Wenn Herkunft und Geburtsort + nah beieinanderliegen, erhöht dieses die Wahrscheinlichkeit, dass + es sich um die gleiche Person handeln kann. Das wird über die + Koordinaten in den GOV-Elementen ermittelt.</item> + <item>growthUpPlaceGOV, baptismplaceGOV: Wenn Herkunft und Taufort nah + beieinander liegen erhöht dieses die Wahrscheinlichkeit, dass es + sich um die gleiche Person handeln kann. Das wird über die + Koordinaten in den GOV-Elementen ermittelt.</item> + </list> + </item> + <item>Variablen, die nur mit sich selbst verglichen werden können:<list + type="unordered"> + <item>causeOfDeath: Wenn in zwei Quellen die Todesursache angegeben + ist und diese gleich oder ähnlich ist, erhöht dieses die + Wahrscheinlichkeit, dass es sich um dieselbe Person handelt.</item> + <item>occupation: Wenn in zwei Quellen eine Berufsangabe gegeben ist + und diese gleich oder ähnlich ist, erhöht dieses die + Wahrscheinlichkeit, dass es sich um dieselbe Person handelt. + Berufsangaben können sich dabei im Verlauf eines Lebens jedoch + ändern. Auch kann derselbe Beruf unter Bezeichnungen angegeben + werden, die sich nicht ähnlich sind und dadurch nur schwer über + String-Matching-Methoden erkannt werden können (z. B. + <quote>Feuerwehrmann</quote> und + <quote>Hauptbrandmeister</quote>).</item> + </list> + </item> + <item>source: Wenn zwei Personen in derselben Quelle genannt werden, wird + hier angenommen, dass es sich nicht um dieselbe Person handelt. Dabei + sind detaillierte Quellen gemeint (z. B. ein konkreter Heiratseintrag mit + laufender Nummer in einem Heiratsregister).</item> + </list> + </div> + <div type="subchapter"> + <head>3.4.2 Disjunktionen</head> + <p>Sind im vorigen Abschnitt mögliche Vergleiche zwischen Variablen beschrieben + worden, findet nun eine Definition konkreter Kriterien statt, die ein + Record Linkage verhindern. Dazu wird zunächst erkannt, ob zwei Records + disjunkt sind, also nicht dieselbe Entität beschreiben. In dem Fall erhalten + sie einen Similaritätswert von 0. Disjunkte Einträge werden vom Algorithmus + nicht weiter behandelt. Die Disjunktionsregeln werden hier oberflächlich + textuell beschrieben und dann stärker formalisiert und übersichtlicher + dargestellt. In der programmtechnischen Umsetzung wird darauf geachtet, jene + Regeln, die besonders viele Kombinationen ausschließen, an den Beginn zu + setzen. Dies ändert zwar das Ergebnis nicht, führt jedoch zu einer + erheblichen Verbesserung der Laufzeit.</p> + <p>Die meisten hier vorgestellten Regeln sind in Hinblick auf die kulturelle + Praxis und den Ablauf von Lebensereignissen logisch. So kann eine Person + beispielsweise vor ihrer Geburt nicht sterben. Bisher wurden solche + Regeln für den deutschsprachigen Raum wissenschaftlich noch nicht + beschrieben. Vielmehr finden sich zahlreiche Publikationen zur Genealogie, + die insbesondere Privatpersonen einen Zugang ermöglichen, aber + wissenschaftlichen Standards nicht entsprechen und auf die deshalb hier kein + Bezug genommen wird. Die ›kulturelle Praxis‹ für den deutschsprachigen Raum + basiert dabei vielmehr auf der jahrelangen Erfahrung der Autoren im Umgang + mit genealogischen Daten.</p> + <p>Zunächst sind Records disjunkt, wenn sie auf demselben Eintrag in einer + Quelle basieren. Das kann beispielsweise in Taufeinträgen der Fall sein, bei + denen Vater und Sohn die gleichen Namen haben, niemals aber dieselbe Person + darstellen. Auch wenn bei einem Eintrag kein Vorname oder kein Nachname + vorhanden ist, wird für diesen Algorithmus definiert, dass kein Record + Linkage erfolgen kann und die Einträge werden so behandelt, als wären sie + disjunkt. Alle Kinder, die vor dem Alter von 13 Jahren verstorben sind, erhalten + ebenfalls eine 0. Hier besteht die Annahme, dass diese vor diesem Alter noch + nicht in anderen Einträgen vorkommen können und ein weiterer Vergleich aus + Laufzeitgründen deshalb nicht notwendig ist.<note type="footnote"> Wenn für + die zu vergleichenden Quellen jedoch insbesondere dieser Aspekt relevant + ist, kann die Altersgrenze auch variiert oder entfernt werden. Das kann + zum Beispiel der Fall sein, wenn Geburtsangaben aus Zeitungen mit denen + aus Kirchenbüchern verglichen werden sollen.</note> Wenn beide Records + ein Geschlecht aufweisen, dieses aber nicht dasselbe ist, so sind sie + disjunkt. Personen können nicht vor ihrer Geburt getauft oder beerdigt + werden, heiraten oder sterben. Sie können auch nicht vor ihrer Heirat + sterben oder beerdigt werden. Auch können sich Personen nicht scheiden + lassen, bevor sie geheiratet haben. In der programmtechnischen Umsetzung + existieren Variablen für bis zu drei Eheschließungen. Dies kann jedoch + beliebig erweitert werden. Eine Hochzeit kann nicht nach dem Tod oder der + Beerdigung stattfinden. Ebenso kann eine Person maximal ein Alter von 120 + Jahren erreichen. Wenn kein Geburtsdatum vorhanden ist, wird jeweils das + Taufdatum für den Vergleich herangezogen. Auch ersetzt das Beerdigungsdatum + den Sterbetag, sofern dieser fehlt. Im Übrigen muss eine Person erst + sterben, bevor sie beerdigt werden kann.</p> + <p>Wenn die Geburtsdaten beider Personen vorhanden und trotzdem unterschiedlich + sind, so beschreiben sie nicht dieselbe Person. Ebenso verhält es sich mit + den Sterbedaten. Bei den Taufzeitpunkten sind die Einträge nicht disjunkt, + solange die Taufdaten eine Differenz von drei Jahren nicht überschreiten. + Die drei Jahre stellen dabei eine Annahme dar, die genügend Platz für + Abweichungen lässt.</p> + <p>Aus dem Vergleich mit den Eltern ergeben sich einige Zustände, die ein + ausschließendes Kriterium darstellen. So kann der Tod des eigenen Vaters + maximal neun Monate vor der eigenen Geburt stattfinden, der Tod der Mutter + nicht vor der Geburt. Da die Taufen in den historischen Daten oftmals wenige + Tage nach der Geburt vollzogen worden sind, gilt die gleiche Regel auch für + die Taufdaten (der Tod der Mutter kann jedoch vor der Taufe des Kindes + eintreten, wenn sie bei der Geburt verstirbt). Es wird zudem ein + Mindestalter für eine Elternschaft von 13 Jahren angenommen. Diese Grenze + wird auch als Mindestalter für eine Hochzeit oder Scheidung gewählt. Zudem + wird definiert, dass Frauen maximal mit 60 Jahren noch Mutter werden + können.</p> + <p>Folgende Regeln führen zur Ungleichheit der Records (similarity = 0):</p> + <list type="unordered"> + <item>Wenn sex != sex</item> + <item>Wenn source == source</item> + <item>Wenn Differenz von birthday von id und deathday von idFather > 9 + Monate</item> + <item>Wenn Differenz von baptismday von id und deathday von idFather > 9 + Monate</item> + <item>Wenn Differenz von birthday von id und burialday von idFather > 9 + Monate</item> + <item>Wenn Differenz von baptismday von id und burialday von idFather > 9 + Monate</item> + <item>Wenn birthday von id > deathday von idMother<note type="footnote"> + Auf diese Regel unter Einbeziehung des Taufdatums wird hier + verzichtet, weil die Mutter bei der Geburt sterben und das Kind erst + danach getauft werden kann.</note> + </item> + <item>Wenn birthday von id > burialday von idMother</item> + <item>Wenn Differenz von birthday von id und birthday von idFather > 13 + Jahre</item> + <item>Wenn Differenz von baptismday von id und birthday von idFather > 13 + Jahre</item> + <item>Wenn Differenz von birthday von id und baptismday von idFather > 13 + Jahre</item> + <item>Wenn Differenz von baptismday von id und baptismday von idFather > + 13 Jahre</item> + <item>Wenn Differenz von birthday von id und birthday von idMother > 13 + Jahre</item> + <item>Wenn Differenz von baptismday von id und birthday von idMother > 13 + Jahre</item> + <item>Wenn Differenz von birthday von id und baptismday von idMother > 13 + Jahre</item> + <item>Wenn Differenz von baptismday von id und baptismday von idMother > + 13 Jahre</item> + <item>Wenn Vornamen vorhanden und kein Vorname mit einem anderen + übereinstimmt</item> + <item>Wenn Differenz baptismday und birthday > 3 Jahre</item> + <item>Wenn Differenz ageAtMarriage und errechnetes Alter durch birthday, + marriageday > 5 Jahre</item> + <item>Wenn Differenz ageAtMarriage und errechnetes Alter durch baptismday, + marriageday > 5</item> + <item>Wenn errechnetes Alter durch birthday, marriageday < 13 Jahre oder + > 100 Jahre</item> + <item>Wenn errechnetes Alter durch birthday, divorceday < 13 Jahre oder + > 100 Jahre</item> + <item>Wenn errechnetes Alter durch baptismday, marriageday < 13 Jahre + oder > 100 Jahre</item> + <item>Wenn errechnetes Alter durch baptismday, divorceday < 13 Jahre oder + > 100 Jahre</item> + <item>Wenn Differenz ageAtDeath und errechnetes Alter durch birthday, + deathday > 10</item> + <item>Wenn Differenz ageAtDeath und errechnetes Alter durch baptismday, + deathday > 10</item> + <item>Wenn Differenz ageAtDeath und errechnetes Alter durch birthday, + burialday > 10</item> + <item>Wenn Differenz ageAtDeath und errechnetes Alter durch baptismday, + burialday > 10</item> + <item>Wenn birthday > baptismday</item> + <item>Wenn birthday > marriageday1</item> + <item>Wenn birthday > divorceday1</item> + <item>Wenn birthday > marriageday2</item> + <item>Wenn birthday > divorceday2</item> + <item>Wenn birthday > marriageday3</item> + <item>Wenn birthday > divorceday3</item> + <item>Wenn birthday > deathday</item> + <item>Wenn birthday > burialday</item> + <item>Wenn baptismday > marriageday1</item> + <item>Wenn baptismday > divorceday1</item> + <item>Wenn baptismday > marriageday2</item> + <item>Wenn baptismday > divorceday2</item> + <item>Wenn baptismday > marriageday3</item> + <item>Wenn baptismday > divorceday3</item> + <item>Wenn baptismday > deathday</item> + <item>Wenn baptismday > burialday</item> + <item>Wenn marriageday1 > marriageday2</item> + <item>Wenn marriageday1 > marriageday3</item> + <item>Wenn marriageday1 > divorceday1</item> + <item>Wenn marriageday1 > deathday</item> + <item>Wenn marriageday1 > burialday</item> + <item>Wenn marriageday2 > marriageday3</item> + <item>Wenn marriageday2 > divorceday2</item> + <item>Wenn marriageday2 > deathday</item> + <item>Wenn marriageday2 > burialday</item> + <item>Wenn marriageday3 > divorceday3</item> + <item>Wenn marriageday3 > deathday</item> + <item>Wenn marriageday3 > burialday</item> + <item>Wenn divorceday1 > marriageday2</item> + <item>Wenn divorceday1 > marriageday3</item> + <item>Wenn divorceday1 > deathday</item> + <item>Wenn divorceday1 > burialday</item> + <item>Wenn divorceday2 > marriageday3</item> + <item>Wenn divorceday2 > deathday</item> + <item>Wenn divorceday2 > burialday</item> + <item>Wenn divorceday3 > deathday</item> + <item>Wenn divorceday3 > burialday</item> + <item>Wenn Differenz deathday und burialday > 1 Jahr</item> + <item>Wenn Differenz birthday und deathday > 120 Jahre</item> + <item>Wenn Differenz birthday und burialday > 120 Jahre</item> + <item>Wenn Differenz baptismday und deathday > 120 Jahre</item> + <item>Wenn Differenz baptismday und burialday > 120 Jahre</item> + <item>Wenn Differenz birthday und birthday > 1 Jahr</item> + <item>Wenn Differenz baptismday und baptismday > 1 Jahr</item> + <item>Wenn Differenz deathday und deathday > 1 Jahr</item> + <item>Wenn Differenz burialday und burialday > 1 Jahr</item> + <item>Wenn marriageday1 > deathday von idSpouse1</item> + <item>Wenn marriageday2 > deathday von idSpouse2</item> + <item>Wenn marriageday3 > deathday von idSpouse3</item> + <item>Wenn divorceday1 > deathday von idSpouse1</item> + <item>Wenn divorceday2 > deathday von idSpouse2</item> + <item>Wenn divorceday3 > deathday von idSpouse3</item> + </list> + <p>In der programmtechnischen Umsetzung ist ergänzend eine optionale Variable + (sortingBySurnameGiven) angelegt, mit der im Fall identischer zu + vergleichender Tabellen nur solche Personen zusammengeführt werden, deren + surnameGiven mit demselben Anfangsbuchstaben beginnt. Diese Implementierung + dieser optionalen Funktion erfolgt vorwiegend aus Laufzeitgründen für große + Tabellen mit hunderttausenden Datensätzen.</p> + </div> + <div type="subchapter"> + <head>3.4.3 Similaritätsprüfung</head> + <p>Kann nicht erkannt werden, dass zwei Records disjunkt sind, so wird die + Similarität dieser weiter geprüft. Dazu wird ein Fuzzy-Vergleich der Vor- + und Nachnamen vorgenommen. Zum Vergleich dieser Strings wird die + Jaro-Winkler-Distanz ausgewählt, weil diese bei Georgala et al. zu guten + Ergebnissen führt.<note type="footnote"> Vgl. <ref type="bibliography" target="#georgala_record_2015">Georgala et al. 2015</ref>, S. + 187.</note> Georgala et al. erzielen mittels einer ROC-Kurve<note + type="footnote"> Receiver Operating Characteristic, vgl. <ref type="bibliography" target="#fan_understanding_2006">Fan et al. + 2006</ref>.</note> ein optimales Ergebnis bei einem Grenzwert von 0,70.<note + type="footnote"> Vgl. <ref type="bibliography" target="#georgala_record_2015">Georgala et al. 2015</ref>, S. 185.</note> Um die Anzahl + der falschpositiven Zuordnungen zu verringern, wird in unserem Ansatz jedoch + ein Grenzwert von 0,95 definiert. Nur wenn der Wert für die Nachnamen höher + ist, wird davon ausgegangen, dass die Personen similär sind. Die Auswahl + dieses Maßes und dieser Grenze ist jedoch keineswegs alternativlos, sondern + kann im Programmcode verändert und ggf. auch an die Bedürfnisse der + jeweiligen Anwendung angepasst werden. Alternativ zur reinen + Jaro-Winkler-Distanz ist im Programmcode derzeit die phonetische + Übereinstimmung auf Basis der Kölner Phonetik in Kombination mit einem + anderen Grenzwert der Jaro-Winkler-Distanz implementiert. Diese wird + getestet, wenn die Jaro-Winkler-Distanz den gewählten Grenzwert nicht + überschreitet. Die Kölner Phonetik wird ausgewählt, da diese speziell auf + den deutschen Sprachraum ausgerichtet ist. Buchstaben werden dabei in Zahlen + codiert.<note type="footnote"> Vgl. <ref type="bibliography" target="#postel_phonetik_1969">Postel 1969</ref>, S. 928.</note> Ist der + Wert der Kölner Phonetik gleich und liegt die Jaro-Winkler-Distanz bei über + 0,60, wird hier ebenfalls von einer Similarität ausgegangen.</p> + <p>Nach dem Test der Nachnamen wird zudem die Similarität der Vornamen + überprüft. Überschreitet die Jaro-Winkler-Distanz auch bei einem Vergleich + der Vornamen einen Wert von 0,95, oder 0,60 in Kombination mit der + Gleichheit der phonetischen Werte, wird als Similarität der arithmetische + Mittelwert der Jaro-Winkler-Distanzen von Vor- und Nachnamen genutzt, um die + Ähnlichkeit beider Records auszudrücken. Anderenfalls wird die Hypothese, + dass die Records dieselbe Entität beschreiben, verworfen. Die Similarität + erhält dann einen Wert von 0.</p> + <p>Die Similaritätsprüfung stützt sich im Algorithmus damit nur auf die + Ähnlichkeit von Vor- und Nachnamen. Dabei können perspektivisch auch weitere + Vergleiche integriert werden. So ist es denkbar, die Ähnlichkeit der Zeiten, + der Ortsnamen, der Ortsentfernungen, der Berufe oder Todesursachen sowie + eine Kombination dieser zu implementieren.</p> + <p>Wenn mehrere Matches vorhanden sind, wird geprüft, welches über die größte + Übereinstimmung verfügt. Nur das passendste wird zusammengeführt. Es wird + das mit dem besten Similaritätswert ausgewählt. Bestehen mehrere Matches mit + dem gleichen Similaritätswert, so werden die Einträge ausgewählt, die zuerst + zusammengeführt worden sind. Für die nicht ausgewählten Matches werden + programmintern jedoch trotzdem globale IDs vergeben, weswegen nicht jede + globale ID nachher auch in der Ergebnistabelle erscheint. Sollen mehr als + zwei Matches zusammengeführt werden, muss das Programm mit der + Ergebnistabelle wiederholt ausgeführt werden.</p> + <p>Neben der Similaritätsprüfung gibt es noch einen sogenannten Prioritätswert. + Dieser wird ermittelt, um nicht nur Disjunktionsregeln und die Ähnlichkeit + der Namen in der Similaritätsprüfung zu integrieren. Nur, weil zwei Records + einen hohen Similaritätswert innehaben, bedeutet das nämlich noch nicht, + dass sie tatsächlich die gleiche Person abbilden. Wenn alle anderen + Variablen leer sind, reicht hier vielmehr die reine Namensgleichheit für + einen hohen Similaritätswert aus. Records nur auf dieser Basis + zusammenzuführen, ist nicht sinnvoll. Deswegen werden diese nur + zusammengeführt, wenn sie zugleich verschiedene Variablenkombinationen + aufweisen (z. B. beide ein Geburts- und Taufdatum), die die + Disjunktionsprüfung überstanden haben. Darunter fallen folgende + Ereignisse:</p> + <list type="unordered"> + <item>Eine gleiche Berufsangabe (ausgenommen die Angabe »Bürger«)</item> + <item>Einer der Hochzeitstage ist identisch</item> + <item>Geburtsdatum oder Taufdatum bei beiden vorhanden</item> + <item>Geburtsdatum oder Taufdatum und Todes- oder Beerdigungsdatum + vorhanden</item> + <item>Todesdatum oder Beerdigungsdatum bei beiden vorhanden</item> + </list> + </div> + </div> + <div type="subchapter"> + <head>3.5 Zusammenführung von Records</head> + <p>Wird erkannt, dass zwei Records dieselbe Entität beschreiben, sind diese + zusammenzuführen. Es wird ein neuer Record in einer neuen Tabelle kreiert, die + ebenfalls die Normform besitzt. Dazu ist festzulegen, wie Daten zusammengeführt + werden. Wenn jeweils gleiche Informationen vorhanden sind, wird die gemeinsame + Information übernommen. Ist eine Variable in nur einem bekannten Datensatz + beschrieben, so ist dieser Inhalt für den neuen Eintrag auszuwählen. Sind + unterschiedliche Informationen vorhanden, so ist entweder die Information mit + der höheren Aussagekraft zu übernehmen oder die Informationen ergänzen sich + gegenseitig. Eine höhere Aussagekraft wird angenommen, wenn es beispielsweise + statt einer Jahresangabe ein konkretes Datum gibt. Bei Namen oder Ortsangaben + stellt der längere String die weitergehende Information dar. Bei Berufen und + Quellenangaben werden beide Informationen beibehalten und mit einem Komma + separiert zusammengeführt.</p> + <p>Die neue Tabelle enthält neben allen (wie oben beschrieben zusammengeführten) + Variablen zudem die Spalte idGlobal. Diese globale ID stellt eine neu erzeugte + ID dar, auf die sich alle weiteren ID-Verweise des zusammengeführten + Datensatzes beziehen. Die Spalte ›id‹ der Normform wird ergo nicht + zusammengeführt, sondern in der neuen Tabelle jeweils als ›idSource1‹ und + ›idSource2‹ übernommen. Dies dient der erleichterten manuellen + Qualitätskontrolle des Record Linkage. <ref type="intern" target="#tab02">Tabelle 2</ref> enthält die Beschreibung + dieser Variablen.</p> + <p>Solche Records, zu denen kein Pendant im jeweils anderen Datensatz gefunden + wird, werden unverändert in die neue Tabelle überführt. Ausnahme ist allerdings + auch hierbei die Verwendung einer neuen ›globalId‹.</p> + <table> + <row role="label"> + <cell>Bezeichnung</cell> + <cell>Inhalt</cell> + </row> + <row> + <cell>globalId</cell> + <cell>Diese Spalte enthält eine eindeutige, globale ID. Jede natürliche + Person soll nur eine ID erhalten, die mit den einzelnen Einträgen der + Datensätze verknüpft ist.</cell> + </row> + <row> + <cell>idSource1</cell> + <cell>Diese Spalte enthält die Angabe über die ID des ersten Eintrags in der + ersten Quelle.</cell> + </row> + <row> + <cell>idSource2</cell> + <cell>Diese Spalte enthält die Angabe über die ID des zweiten Eintrags in + der zweiten Quelle.</cell> + </row> + <trailer xml:id="tab02"> + <ref type="intern" target="#tab2">Tab. 2</ref>: Zusätzliche Variablen eines + zusammengeführten Datensatzes. [Goldberg / Mernitz 2023]<ref type="graphic" + target="#record_2022_t2"/> + </trailer> + </table> + + </div> + </div> + <div type="chapter"> + <head>4. Validierung am Beispiel Leipzigs</head> + + <p>Leipzig ist eine Stadt, an der sich zwei große historische Handelsrouten Europas + kreuzen: die Via Regia von Ost nach West sowie die Via Imperii von Nord nach + Süd.<note type="footnote"> Vgl. <ref type="bibliography" target="#schoenfelder_grundlagen_2015">Schönfelder / Börngen 2015</ref>, S. 39.</note> Diese + geografische Lage bot für die Entwicklung Leipzigs, vor allem als Messe- und + Handelszentrum, lange Zeit eine fruchtbare Grundlage. Mit der wirtschaftlichen + Bedeutung Leipzigs ging auch ein Wachstum der Bevölkerung einher, zu dem noch + heute in verschiedenen Quellen Zeugnisse erhalten sind. Aufgrund der vorhandenen + prosopographischen Datenbestände mit umfangreichen genealogisch relevanten + Informationen bietet Leipzig ein geeignetes Beispiel zur Validierung des + beschriebenen Algorithmus. Innerhalb dieser Validierung werden zwei Quellen / + Datenbestände betrachtet: die Kartei Leipziger Familien (KLF) und die Kartei + Leipziger Kreisamtstestamente (KLK). Diese Datenquellen verbindet, dass sie + zumindest teilweise Daten über dieselben Personen enthalten. Aufgrund des + unterschiedlichen Gegenstands,<note type="footnote"> Bei der KLK ist vor allem + relevant, dass nur ein Teil der Bevölkerung überhaupt Testamente hinterlegt + hat.</note> vor allem aber wegen unterschiedlicher Zeiträume, sind nicht + alle Personen in beiden Datenbeständen zu finden. Zum Teil spielt auch eine + unterschiedliche geografische Reichweite eine Rolle. Während die KLF auf den + Innenstadtkern von Leipzig beschränkt ist, bezieht die KLK das Amt Leipzig mit + ein.</p> + <p>In dem folgenden Abschnitt wird zunächst die Struktur der hier verwendeten + Datenbestände beschrieben, bevor der Algorithmus auf sie angewendet wird. Die + Validierung geschieht zum einen zwischen den Datenbeständen, aber auch innerhalb + eines Datensatzes mit sich selbst. Das ist notwendig, da dieselben Personen auch + dort doppelt erscheinen können und zunächst zusammengeführt werden müssen. Danach + werden die Resultate dargestellt.</p> + <div type="subchapter"> + <head>4.1 Daten und Ermittlung der Normform</head> + + <p>Im Folgenden wird zunächst auf die KLF eingegangen. Danach folgt die KLK.</p> + <div type="subchapter"> + <head>4.1.1 Kartei Leipziger Familien (ca. 1550–1850)</head> + + <p>In der KLF sind viele Informationen über in Leipzig ansässige Familien + enthalten. Die Kartei wurde von einer Mitarbeiterin der Deutschen + Zentralstelle für Genealogie, Helga Moritz, ab den 1950er Jahren erstellt. + Als Grundlage nutzte sie die Leipziger Kirchen- und Bürgerbücher. Die Daten + umfassen in etwa den Zeitraum von der Mitte des 16. bis zur Mitte des 19. + Jahrhunderts. Auf 20.000 Karteikarten sind dort etwa 200.000 + Personen(einträge) dokumentiert.<note type="footnote"> <ref type="bibliography" target="#munke_citizen_2019">Munke 2019</ref>, S. 118. + Personen innerhalb der KLF können also doppelt vorkommen, indem sie auf + einer Karteikarte in der Rolle des Kindes erscheinen, auf einer anderen + als Familienoberhaupt oder Ehefrau. Auch Drittpersonen können in den + anderen Rollen vorkommen. Dadurch reduziert sich im Zuge eines Record + Linkage die Anzahl der Personeneinträge.</note> Die Karteikarten + enthalten jeweils Angaben zu einem Ehemann, seiner Ehefrau und deren + Kindern. Falls ein Mann zweimal heiratete, so sind beide Ehen auf einer + Karte verzeichnet. Die Karteikarten sind untereinander nicht über eindeutige + Identifikatoren wie Kartennummern verknüpft.<note type="footnote"> Für eine + detaillierte Erklärung des Aufbaus der Karteikarten vgl. <ref type="bibliography" target="#vfc_kartei_2018">Verein für + Computergenealogie 2018–2019</ref>.</note> + </p> + <p>Im Rahmen eines Datenerfassungsprojekts durch den Verein für + Computergenealogie wurde die Kartei digitalisiert.<note type="footnote"> + <ref + target="http://des.genealogy.net/karteiLeipzigerFamilien/search/index" + >Online durchsuchbar</ref>, vgl. <ref type="bibliography" target="#vfc_kartei_2018">Verein für Computergenealogie + 2018–2019</ref>.</note> Dazu wurden die Scans der Karteikarten manuell + abgetippt. Datenfelder im genutzten Datenerfassungssystem (DES) sind der + Nachname (mit akademischen Titeln), die Vornamen, der Beruf, der Ort samt + GOV-ID, das Geburtsdatum oder wahlweise Alter bei Tod, das Taufdatum, + Heiratsdatum, Sterbedatum, Beerdigungsdatum und eine Bemerkung sowie ein + Feld für weitere Ortsangaben und die ID der Karteikarte (die automatisch + vergeben wird). Des Weiteren existieren besondere, KLF-spezifische Angaben + zur Rolle, zur Bezugsperson und zur Art der Beziehung zur Bezugsperson.<note + type="footnote"> Erwähnenswert ist, dass nicht jedes Feld einen Eintrag + enthält, sondern vieles optional ist. Dadurch stehen im Zweifel bei jedem + Eintrag andere Daten zur Verfügung.</note> Es gibt die Rollen + Familienoberhaupt, Kind, Ehefrau und Drittperson. Ersteres beschreibt einen + Mann, der die Karteikarte begründet, die Ehefrau ist seine Frau. Kinder + einer Ehe sind als <quote>Kind</quote> klassifiziert. Drittpersonen können + Ehepartner*innen von Kindern darstellen. Auch können Eltern von Personen, die + nicht Kinder sind, als Drittpersonen auftauchen (insbesondere die Eltern der + Ehepartner*innen). Jede Drittperson ist jeweils einer Bezugsperson zugeordnet. Ein*e + Ehepartner*in eines Kindes beispielsweise ist diesem Kind zugeordnet. Die Art + der Beziehung beschreibt dahingegen das Verhältnis zur Drittperson (Ehemann + / Ehefrau / Vater). Damit sind die Felder nicht direkt der definierten + Normform zuzuordnen, sondern müssen zunächst umgewandelt werden. Dieses + wurde automatisiert durch ein Programm realisiert, das im <ref + target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-record" + >Online-Repositorium</ref> einsehbar ist. Es zeigt sich hier auch + beispielhaft, dass die Umwandlung in die Normform aufwendig sein kann.</p> + <p>Ein Schwerpunkt dieses Programms besteht dabei in der Umwandlung von + Altersangaben: Dabei wird im Algorithmus der Sonderfall abgedeckt, dass in + den Datumszellen Altersangaben stehen. So kann dort statt dem Geburtsdatum + eine Angabe zum Alter gemacht werden. Die hier enthaltenen Altersangaben + werden während der Bereinigung im Algorithmus erkannt und zu Datumsangaben + verarbeitet. Aus diesem Grunde findet an dieser Stelle keine Separierung in + die Normform-Variablen ›birthday‹ und ›ageAtDeath‹ statt. Eine solche + Separierung wäre ein alternativ mögliches Vorgehen.</p> + <p>Da Altersangaben nur in Beziehung mit anderen Variablen interpretiert werden + können, bezieht die Aufbereitung dieser Daten weitere Informationen eines + Records mit ein (z. B. das Alter bei Tod und das Todesdatum zur Berechnung + des Geburtszeitpunkts). Für die Aufbereitung ist aufgrund der relativen + Beziehung der Variablen untereinander eine Betrachtung sämtlicher + Datumsangaben des Records notwendig.</p> + <p>Es wird zunächst geprüft, ob die Zeitangabe einer normierten Schreibweise + entspricht. Diese wird hier als D.M.YYYY definiert und darüber ermittelt, ob + sich der String in ein datetime-Objekt umwandeln lässt. Wenn das der Fall + ist, ist die Zuordnung erfolgreich. In dem Fall, dass das Geburtsdatum nicht + der Schreibweise D.M.YYYY entspricht, soll die Art und Weise der Zeitangabe + identifiziert werden. Es sind verschiedene Ursachen möglich:</p> + <list type="unordered"> + <item>Das Datum enthält nur eine Jahresangabe.</item> + <item>Statt einem Datum wird eine Altersangabe in Jahren gemacht.</item> + <item>Statt einem Datum wird eine Altersangabe in Tagen gemacht.</item> + <item>Die Zeitangabe enthält nur eine Info darüber, dass das Ereignis + überhaupt eingetroffen ist (»ja«). Das deutet bei Todesangaben auf einen + frühen Tod des Kindes hin.</item> + <item>Die Zeitangabe enthält keine Information, die Rückschlüsse auf die + zeitliche Einordnung zulässt.</item> + </list> + <p>Bei den ersten vier der fünf Fälle kann eine Zeitangabe abgeleitet werden. + Im fünften Fall besteht die Herausforderung darin, zu erkennen, dass es sich + nicht um eine Angabe mit zeitlichem Bezug handelt. Zunächst werden solche + Angaben erkannt, die nur aus einer Jahreszahl bestehen. Hier wird zunächst + geprüft, ob das zu prüfende Datum in einen Integerwert umgewandelt werden + kann. Das ist der Fall, wenn es sich um eine reine Jahresangabe handelt. Ist + nicht nur eine Jahreszahl Inhalt der Angabe, so wird geprüft, ob sie ein + <quote>J.</quote> (für Jahr), ein <quote>T.</quote> (für Tag) oder ein + <quote>ja</quote> (für das generelle Eintreten des Ereignisses) enthält. + Je nach Typ des Datums werden darauffolgend unterschiedliche + Berechnungsschritte durchgeführt. Beispielsweise wird bei einer Angabe + <quote>64 J.</quote> in einem Feld zum Sterbedatum versucht, das + Sterbedatum anhand der Geburts- oder Taufangabe zu ermitteln. Diese + Verarbeitungsschritte haben zur Folge, dass am Ende ein Gedbas4all-konformes + Datumsformat vorliegt.</p> + <p>Die grundsätzliche Zuordnung der KLF zu den Datenfeldern der Normform wird + wie in <ref type="intern" target="#tab03">Tabelle 3</ref> + ersichtlich realisiert. Dabei werden die Datumsangaben wie zuvor beschrieben + behandelt.</p> + <table> + <row role="label"> + <cell>Variable KLF</cell> + <cell>Variable der Normform</cell> + </row> + <row> + <cell>page [ID der Karteikarte]</cell> + <cell>source</cell> + </row> + <row> + <cell>lastname</cell> + <cell>lastnameGiven</cell> + </row> + <row> + <cell>firstname</cell> + <cell>firstnameGiven</cell> + </row> + <row> + <cell>Beruf</cell> + <cell>occupation</cell> + </row> + <row> + <cell>Rolle</cell> + <cell>---</cell> + </row> + <row> + <cell>Ort</cell> + <cell>---</cell> + </row> + <row> + <cell>GOV-Id</cell> + <cell>---</cell> + </row> + <row> + <cell>Bezugsperson</cell> + <cell>---</cell> + </row> + <row> + <cell>Art der Beziehung</cell> + <cell>---</cell> + </row> + <row> + <cell>Geburtsdatum/Alter</cell> + <cell>birthday</cell> + </row> + <row> + <cell>Taufdatum</cell> + <cell>baptismday</cell> + </row> + <row> + <cell>Heiratsdatum</cell> + <cell>marriageday1</cell> + </row> + <row> + <cell>Sterbedatum</cell> + <cell>deathday</cell> + </row> + <row> + <cell>Beerd.Datum</cell> + <cell>burialday</cell> + </row> + <row> + <cell>Bemerkung</cell> + <cell>---</cell> + </row> + <row> + <cell>weiterer Ort</cell> + <cell>---</cell> + </row> + <trailer xml:id="tab03"> + <ref type="intern" target="#tab3">Tab. 3</ref>: Direkte Umwandlung der + KLF-Struktur in die Normform. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_t3"/> + </trailer> + </table> + + <p>Die KLF-Variablen Rolle, Bezugsperson, Art der Beziehung und ID werden zudem + herangezogen, um weitere Variablen der Normform zu füllen (vgl. <ref type="intern" target="#tab04">Tabelle 4</ref>).</p> + <table> + <row role="label"> + <cell>Variable der Normform</cell> + <cell>Verknüpfung der KLF-Variablen</cell> + </row> + <row> + <cell>idSpouse1, idSpouse2, idSpouse3</cell> + <cell>Ein Familienoberhaupt erhält die ID der Ehefrau auf derselben + Karteikarte. Eine Ehefrau erhält die ID des Familienoberhauptes auf + derselben Karteikarte. Eine Drittperson vom Typ Ehefrau / Ehemann + führt dazu, dass bei der Drittperson wie auch bei der Bezugsperson + eine ID für den*die Ehepartner*in ergänzt wird.</cell> + </row> + <row> + <cell>idFather, idMother</cell> + <cell>Bei Kindern werden die IDs der Eltern jeweils ergänzt. Tritt eine + Drittperson als Vater auf, so wird diese bei dem Kind ergänzt.</cell> + </row> + <row> + <cell>idGlobal</cell> + <cell>Wird ohne Bezug zur KLF fortlaufend vergeben.</cell> + </row> + <trailer xml:id="tab04"> + <ref type="intern" target="#tab4">Tab. 4</ref>: Indirekte Umwandlung der + KLF-Struktur in die Normform. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_t4"/> + </trailer> + </table> + + </div> + <div type="subchapter"> + <head>4.1.2 Kartei Leipziger Kreisamtstestamente (1696–1829)</head> + <p>Für das Amt Leipzig liegen für die Zeit von 1696 bis 1829 Testamente + innerhalb von 120 Bänden im Sächsischen Staatsarchiv vor.<note + type="footnote"> Sächsisches Staatsarchiv. Bestand 20009 Amt + Leipzig.</note> Zum Auffinden von Testamentsvorgängen existiert eine + Kartei – die KLK. Auch die KLK ist im Rahmen eines Datenerfassungsprojektes + des Vereins für Computergenealogie mit Hilfe des DES erfasst worden und <ref + target="https://des.genealogy.net/leipzig_testamente/search/index" + >online</ref> einsehbar.<note type="footnote"><ref type="bibliography" target="#vfc_kartei_2019">Verein für Computergenealogie 2019–2021</ref>.</note> Sie umfasst 4.800 + Karteikarten, auf denen jeweils zu einer Person die entsprechenden Vorgänge + zum Testament erfasst sind. Ehepartner*innen erhalten jeweils eigene Karten. + Jedoch können auch Drittpersonen auf den Karten erscheinen. Dazu gibt es in + der KLK die Variable ›Rolle‹, in der zwischen Erblasser*innen und Drittpersonen / + Verwandten unterschieden wird. Dies führt dazu, dass ca. 6.500 + Personendatensätze entstehen. Zu den Erblasser*innen sind jeweils entsprechende + Informationen über die Testierung vorhanden. Bei einer Drittperson + dahingegen ist die Art der Beziehung zur testierenden Person + dokumentiert.</p> + <p>Auch die Variablen der KLK-Erfassung lassen sich in die Normform umwandeln. + Wie bei der KLF gibt es dabei Variablen, die sich direkt auf die Normform + übertragen lassen (vgl. <ref type="intern" target="#tab05">Tabelle + 5</ref>) oder auch indirekt hergeleitet werden können (vgl. <ref type="intern" target="#tab06">Tabelle 6</ref>).</p> + <table> + <row role="label"> + <cell>Variable KLK</cell> + <cell>Variable der Normform</cell> + </row> + <row> + <cell>page</cell> + <cell>---</cell> + </row> + <row> + <cell>firstname</cell> + <cell>firstnameGiven</cell> + </row> + <row> + <cell>Stand/Beruf</cell> + <cell>occupation</cell> + </row> + <row> + <cell>Rolle</cell> + <cell>---</cell> + </row> + <row> + <cell>Ort</cell> + <cell>---</cell> + </row> + <row> + <cell>Band und Blatt</cell> + <cell>source</cell> + </row> + <row> + <cell>Familienstand</cell> + <cell>---</cell> + </row> + <row> + <cell>Ereignis 1, …, Ereignis 8</cell> + <cell>---</cell> + </row> + <row> + <cell>Geschlecht</cell> + <cell>sex</cell> + </row> + <row> + <cell>Bezugsperson ID</cell> + <cell>---</cell> + </row> + <row> + <cell>Bezugsperson Name</cell> + <cell>---</cell> + </row> + <row> + <cell>Art der Beziehung</cell> + <cell>---</cell> + </row> + <row> + <cell>Sterbedatum</cell> + <cell>deathday</cell> + </row> + <row> + <cell>Datum von [erster Vorgang]</cell> + <cell>---</cell> + </row> + <row> + <cell>Datum bis [letzter Vorgang]</cell> + <cell>---</cell> + </row> + <row> + <cell>idGlobal</cell> + <cell>›A‹ + id, bzw. neue ID bei zusammengeführten Personen.</cell> + </row> + <trailer xml:id="tab05"> + <ref type="intern" target="#tab5">Tab. 5</ref>: Direkte Umwandlung der + KLK-Struktur in die Normform. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_t5"/> + </trailer> + </table> + + <p>Die indirekte Herleitung betrifft vor allem die Nachnamen. In der KLK sind + nämlich die vorherigen Nachnamen mit abgebildet. Wenn der Teilstring + <quote>geb.</quote> im Nachnamen vorhanden ist, dann ist der Name danach + der Geburtsname, der Name davor ist ein Heiratsname. Bei dem Teilstring + <quote>verw.</quote> dahingegen ist der folgende Name der Ehename einer + früheren Verbindung, der davorstehende der aktuelle Ehename. Wird im + Nachnamen dahingegen der Begriff <quote>verehel.</quote> verwendet, ist der + erste Teil der Geburtsname, der letztere der Heiratsname. Sind bei einer + Frau keine Hinweise enthalten, von wem der Nachname stammt, wird dieser der + Variable ›surnameUnknown‹ zugeordnet. Bei Männern wird angenommen, dass der + angegebene Nachname immer der Geburtsname ist.</p> + <p>Auch bei den IDs findet eine indirekte Zuordnung statt. Wenn eine + Drittperson definiert ist und diese den Typ ›Ehemann‹ oder ›Ehefrau‹ + aufweist, dann wird die ID des Ehepartners / der Ehepartnerin hinzugefügt. Gleiches erfolgt bei + Müttern und Vätern, Söhnen und Töchtern bei den Variablen ›idFather‹ und + ›idMother‹. Bei der eigenen ID einer Person wird die ID der KLK + grundsätzlich übernommen. Ihr wird ein ›A‹ vorangestellt, um die IDs + eindeutig von den IDs der KLF zu unterscheiden. Die ID wird jedoch + überschrieben, wenn Dubletten in der KLK vorhanden sind. Das kommt vor, wenn + Ehepartner*innen jeweils eigene Karteikarten haben. Schlüssel zur Erkennung von + Dubletten ist hierbei die Quellenangabe (Band und Blatt) der Testamente. + Wenn nur die ID eines Ehepartners / einer Ehepartnerin verändert wird, deutet es darauf hin, dass + in einem Eintrag der*die Ehepartner*in der Verweis auf den*die andere*n Ehepartner*in als + Drittperson fehlt.</p> + <p>Des Weiteren wird angenommen, dass die Testamentseröffnung kurz nach dem Tod + vorgenommen wird. Liegt also kein Todestag vor, so wird das Jahr der + Testamentsöffnung auch als Todesjahr verwendet. Die Umwandlung in die + Normform wurde automatisiert durch ein Programm realisiert, das im <ref + target="https://git.hab.de/forschungsdaten/zeitschrift-fuer-digitale-geisteswissenschaften/goldberg-record" + >Online-Repositorium</ref> einsehbar ist.</p> + <table> + <row role="label"> + <cell>Variable der Normform</cell> + <cell>Verknüpfung der KLF-Variablen</cell> + </row> + <row> + <cell>idSpouse1, idSpouse2, idSpouse3</cell> + <cell>Wenn eine Drittperson (›Rolle‹ == Drittperson / Verwandter) vom Typ + Ehefrau oder Ehemann vorhanden ist (›Art der Beziehung‹), dann wird + ihre ID (›Bezugsperson ID‹) entsprechend ergänzt.</cell> + </row> + <row> + <cell>idFather, idMother</cell> + <cell>Wenn eine Drittperson vom Typ Vater / Mutter / Sohn / Tochter + vorhanden ist, dann wird die ID entsprechend ergänzt.</cell> + </row> + <row> + <cell>idGlobal</cell> + <cell>id</cell> + </row> + <row> + <cell>lastname</cell> + <cell>surnamenGiven, surnameUnkown, surnameMarriage1, surnameMarriage2, + surnameMarriage3</cell> + </row> + <row> + <cell>deathday</cell> + <cell>Eröffnung</cell> + </row> + <trailer xml:id="tab06"> + <ref type="intern" target="#tab6">Tab. 6</ref>: Indirekte Umwandlung der + KLK-Struktur in die Normform. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_t6"/> + </trailer> + </table> + + </div> + </div> + <div type="subchapter"> + <head>4.2 Resultate des Record Linkage</head> + <p>Da sowohl in der KLK und KLF Personen mehrfach genannt werden können, ist + zunächst ein Vergleich der beiden normformatierten Datentabellen mit sich + selbst sinnvoll. Erst darauffolgend werden die Ergebnisse miteinander + verglichen und zusammengeführt. Dabei stellt sich die Frage nach der Qualität + der Zusammenführung. Zur Validierung der Resultate bietet sich eine + Identifizierung von falschpositiven und falschnegativen Ergebnissen an. Eine + solche Identifizierung ist an dieser Stelle nur begrenzt möglich, da auch mit + einer manuellen Überprüfung nicht zweifelsfrei festgestellt werden kann, ob + eine Verknüpfung nun richtig oder falsch ist. Diese Einschätzung nämlich + basiert vielmehr auf den Heuristiken, die zuvor definiert, formalisiert und + auch umgesetzt worden sind.</p> + <p>Dennoch wird eine manuelle Überprüfung der zusammengeführten Records + vorgenommen. Da nicht alle Records überprüft werden können, werden nur die + Personen behandelt, deren Geburtsname mit ›A‹ beginnt.<note type="footnote"> + Hierdurch werden nicht alle Aspekte des Algorithmus in gleicher Weise + geprüft. Insbesondere die intergenerationalen Elemente der + Plausibilitätsprüfung entfallen, da insbesondere Mütter Geburtsnamen mit + anderen Anfangsbuchstaben haben.</note> Von diesen 4.251 Records werden 651 + zusammengeführt (15,3 Prozent). Dabei konnten einige falschpositive Ergebnisse + identifiziert werden: 1585 und 1586 sind zwei Elisabeth Albrechts in Leipzig + getauft worden (IDs 14505990 und 14506456). Hier liegt das Taufdatum weniger als + ein Jahr auseinander. Da zu beiden die Angabe des Vaters vorliegt, hätte über + den Vergleich der Väter erkannt werden können, dass es sich nicht um dieselbe + Person handelt. Hier ist Potenzial für eine Erweiterung des Algorithmus. + Gleiches trifft auf Maria Arnoldt (14558811 und 14558853), Maria Albrecht + (14499274 und 14505976), Barbara Abitzsch (14457480 und 14458315), Thomas + Abitzsch (14457495 und 14458366), Maria Arnst (14556375 und 14556424) und Paul + Arnst (14556496 und 14560610). Bei dem / den Bäcker(n) Anton Arnoldt (14554173 und 14554184) wird es sich + möglicherweise um unterschiedliche Personen handeln. Helga Moritz hat diese + beiden auch nicht auf derselben Karteikarte erfasst; die Heiratsdaten liegen 28 + Jahre auseinander. Möglicherweise ist die Implementierung einer maximalen + Distanz von Heiratsdaten notwendig, wenngleich diese dann jedoch nicht bei 28 Jahren, sondern deutlich höher liegen sollte. Andere Beispiele für weit auseinander liegende Heiratsdaten stellen Joachim Arnst (14556335 und 14560573) oder zwei weitere Personen namens Thomas Abitzsch + (14457397 und 14458332) dar. Wird angenommen, dass es sich bei diesen elf + Fällen tatsächlich um falschpositive Ergebnisse handelt, liegt die Rate an + Falschpositiven bei 1,7 Prozent.</p> + <p>Weiterhin ist auffällig, dass bei vielen Personen ein positiver Prioritätswert + aufgrund gleicher Heiratsdaten oder gleicher Berufsangaben zustande kommt. + Gleiche Berufsangaben sind in solchen Orten problematisch, in denen es viele + namensgleiche Personen gibt und bestimmte Berufe aufgrund der + nichtdiversifizierten Wirtschaftsstruktur dominant sind. In diesen Fällen + scheint eine Anwendung des Algorithmus nur sinnvoll, wenn weitere Lebensdaten + vorhanden sind. In Leipzig gibt es bis auf wenige Ausnahmen im von den Daten abgedeckten Zeitraum eine große Diversität an Namen und Berufen, sodass dieser Umstand hier kein Problem + darstellt.</p> + <p>Die Relevanz von Berufsangaben für den Prioritätswert führt auch dazu, dass + etwas mehr Männer (58,7 Prozent) als Frauen zusammengeführt werden. Um mehr + Frauen zusammenzuführen, kann es eine Option sein, über die Übereinstimmung + einer seltenen Kombination aus Vornamen einen positiven Prioritätswert zu + erreichen: Die Übereinstimmung von zwei Personen namens <quote>Maria</quote> + ist weniger wahrscheinlich als die von zwei Personen namens <quote>Johanna + Maria Henriette Friederike</quote>, die von <quote>Johann</quote> anders als + die von <quote>Immanuel Friedlieb</quote>. Auch die Seltenheit der Namen kann + hier integriert werden. Ebenso kann die Übereinstimmung seltener Berufe + priorisiert werden.</p> + <p>Bemerkenswert ist auch, dass Vor- und Nachname bei den zusammengeführten + Personen in 90,6 Prozent der Fälle exakt übereinstimmen. Das liegt auch darin + begründet, dass die Erstellerin der KLF die Namensschreibweise normiert hat. + Für eine Bewertung der Ähnlichkeitsanalyse der Namensstrings sind die Daten + darum nicht besonders gut geeignet. Es kann zudem sinnvoll sein, eine + Synonymerkennung der Namen zu implementieren (<quote>Hans</quote> und + <quote>Johann</quote>, <quote>Xine</quote> als schriftliche Abkürzung für + <quote>Christine</quote> etc.).</p> + <p>Zudem ist zu vermuten, dass es im gesamten Datensatz eine nicht näher bekannte + Anzahl von falschnegativen Zuordnungen gibt – also Records, die zusammengeführt + werden müssten, es aber nicht wurden. Für diesen Abgleich wäre eine + genealogische Übersicht der Leipziger Familien als Goldstandard notwendig, die + jedoch nicht existiert. Darum kann dieser Abgleich nicht vorgenommen werden. + Auffällig bei der manuellen Überprüfung ist, dass es einige wenige Fälle gibt, + in denen eine Person sogar vier Mal im Datensatz auftaucht (und dann zweimal + zusammengeführt wird). Um die Anzahl an Falschnegativen zu verringern, kann + eine mehrfache Iteration also hilfreich sein.</p><p>Dass mit dem hier vorgestellten Algorithmus jedoch ein + erheblicher Teil der tatsächlich zusammenzuführenden Records auch + zusammengeführt wird, zeigt ein Vergleich mit der Personenzusammenführung des + Genealogie-Programms <bibl><title type="desc">Ahnenblatt</title></bibl> 2.99<note type="footnote"> Vgl. <ref type="bibliography" target="#boettcher_ahnenblatt_2018">Böttcher + 2018</ref>.</note>: Wird die GEDCOM-Datei dort hineingeladen und werden die + Vorschläge zur Zusammenführung der Personen ohne weiteren manuellen Eingriff + ausgeführt, werden 25.329 von 241.466 Personen zusammengeführt.<note + type="footnote"> Die Zusammenführung basiert hierbei auf gleichen Namen und + einem gleichen Ereignisdatum (z. B. das Taufdatum) und betrifft auch die + nähere Verwandtschaft der betreffenden Personen wie die Eltern, Kinder oder + Geschwister. Vgl. <ref type="bibliography" target="#boettcher_ahnenblatt_2018">Böttcher 2018</ref>, S. 17.</note> Das entspricht mit 10,5 + Prozent einem deutlich geringeren Anteil als im Test der mit »A« beginnenden + Personen mit dem hier entwickelten Algorithmus (15,3 Prozent). Über alle Daten + ist mit dem Algorithmus eine Erkennung von 13,2 Prozent zu erkennen (vgl. <ref type="intern" target="#tab07">Tabelle 7</ref>). Bei der KLK werden + mit 0,7 Prozent erwartungsgemäß wenige Personen verknüpft, da die Normform hier + bereits wenige Duplikate enthält. Von den Testamentsdatensätzen konnten mit dem + Algorithmus 413 Einträge einer Person zugeordnet werden, auf 5.348 Personen + traf das nicht zu.</p> + <table> + <row> + <cell/> + <cell role="label">KLF</cell> + <cell role="label">KLK</cell> + </row> + <row> + <cell role="label">KLF</cell> + <cell>31.791 von 241.465 Records zusammengeführt (Anteil: 13,2 + Prozent)</cell> + <cell>---</cell> + </row> + <row> + <cell role="label">KLK</cell> + <cell>413 zusammengeführt bei 5.761 Personen (Anteil: 7,2 Prozent)<note + type="footnote"> Hier werden die Daten genutzt, nachdem die KLF und + KLK jeweils mit sich selbst abgeglichen worden sind. Von den 5.761 + übrig gebliebenen Personen in der KLK konnten 413 in der KLF gefunden + werden.</note> + </cell> + <cell>41 zusammengeführt bei 5.802 Personen (Anteil: 0,7 Prozent)<note + type="footnote"> Die KLK enthält zwar 6.524 Personendatensätze. Die + Überführung in die Normform sorgt jedoch dafür, dass bereits Personen + zusammengeführt werden, sodass hier 5.802 Personendatensätze übrig + bleiben.</note> + </cell> + </row> + <trailer xml:id="tab07"> + <ref type="intern" target="#tab7">Tab. 7</ref>: Übersicht über die Anzahl + der verknüpften Personen aus den Normformen. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_t7"/> + </trailer> + </table> + + <p>Insgesamt sind die Ergebnisse des Algorithmus also gut: Ein nicht näher zu + quantifizierender, aber erheblicher Teil der tatsächlich zusammenzuführenden + Records konnte auch zusammengeführt werden. Etwa 98 Prozent dieser + zusammengeführten Records sind korrekt. Überall dort, wo Personen klar + zusammengeführt werden können, wird dieses gemacht. Das spart besonders bei + großen Datensätzen viele Ressourcen. Zugleich ist die Lösung nicht perfekt, + vielmehr ist sie ein erster Ansatz, auf den aufzubauen es sich lohnt. Besonders + die Formalisierung und Automatisierung genealogischer Heuristiken kann + erweitert und das Record Linkage somit verbessert werden.<note type="footnote"> + Es gibt weitere, noch nicht in die Normform integrierte Informationen, die + eine hohe praktische Relevanz für genealogische Verknüpfungen haben, deren + maschinelle Interpretation aber sehr schwer erscheint. Dazu gehören + insbesondere Angaben zu den Taufpaten.</note> + </p> + </div> + </div> + <div type="chapter"> + <head>5. Zusammenfassung</head> + <p>Gleiches mit Gleichem zu verbinden – darin besteht eine Herausforderung im Umgang + mit historischen Personendaten. Der vorgestellte Ansatz leistet einen Beitrag, + diese Herausforderung in der praktischen Forschung zu bewältigen. Im Unterschied + zu vorhergehenden Studien nutzt der vorgestellte Algorithmus dafür eine Vielzahl + von genealogisch relevanten Informationen eines Records, vom Beerdigungsdatum über + den Beruf bis hin zu den Lebensdaten der Eltern. Die Besonderheit hier ist, dass + verschiedene Variablen in Beziehung zueinander gesetzt werden. So werden + zahlreiche genealogische Regeln genutzt, um zu erkennen, dass Records disjunkt + sind. Die letztendliche Übereinstimmung (Similarität der Records) wird dahingegen + über die Jaro-Winkler-Distanz und die Kölner Phonetik ermittelt und ist aufgrund + des letzteren Aspekts vor allem an den deutschen Sprachraum angepasst. Auch die + implementierten genealogischen Heuristiken sind an den deutschen historischen + Sprach- und Kulturraum und die evangelische bzw. römisch-katholische + Religionspraxis angepasst; so kennen diese beispielsweise keine Erwachsenentaufen + oder Ehen mit mehreren Personen. Eine vergleichbare Lösung in diesem Umfang zur + Automatisierung genealogischer Heuristiken existiert bisher nicht. Die Umsetzung + in der Programmiersprache Python bietet die Möglichkeit der Veränderung und + Anpassung an die jeweiligen Herausforderungen.</p> + <p>Hierbei zeigt sich sowohl ein großer Vorteil als auch ein großer Nachteil der + vorgestellten Lösung: Der Vorteil besteht darin, dass der Algorithmus besonders + gut ist, wenn viele Informationen (vor allem Datumsangaben) zu einer Person + bekannt sind. Somit ist die Lösung sehr gut geeignet für Quellen mit vielen + genealogisch relevanten Daten. Das ist beispielsweise bei dem zur Validierung + genutzten Beispiel Leipziger Quellen der Fall. Hilfreich ist sie vor allem bei der + Bearbeitung großer Datenbestände, die manuell nicht mehr mit vertretbarem Aufwand + zu verarbeiten sind. Neben dem Einsatz in der Wissenschaft oder in + Time-Machine-Projekten ist es dadurch vorstellbar, Daten aus Kirchenbüchern mit + dem Algorithmus zu verknüpfen. Durch den Algorithmus ist nämlich die + automatisierte genealogische Verknüpfung über mehr als zwei Generationen hinweg möglich. Der Algorithmus kann hier beispielsweise bei der Erstellung von + Ortsfamilienbüchern ein nützliches Werkzeug sein.</p> + <p>Nachteilig ist der Algorithmus dahingegen, wenn nur wenige Informationen über die + durch die Records beschriebenen Personen vorhanden sind. Sind beispielsweise nur + Namen vorhanden, ist es sicherlich angebrachter, verschiedene + String-Matching-Algorithmen an den jeweiligen Daten zu testen. Allerdings kann das + erstellte Programm auch beliebig verändert, erweitert und an die eigenen + Bedürfnisse angepasst werden. Dass das Programm für verschiedene Zwecke angepasst + werden muss, liegt aufgrund der Validierung mittels der Leipziger Daten nahe. + Insbesondere die Herstellung der normalisierten Form (Normform) bedarf einer + solchen Aufmerksamkeit. Es ist zudem eine Illusion zu glauben, dass es zurzeit + eine Lösung geben kann, in der zwei völlig verschiedene Quellen ohne große + Vorarbeit einem automatisierten Record Linkage zugeführt werden können. + Nichtsdestotrotz stellt das entwickelte Programm ein geeignetes Grundgerüst für + die Anpassung dar.</p> + <p/> + </div> + <div type="bibliography"> + <head>Bibliografische Angaben</head> + <listBibl> + <bibl xml:id="abramitzky_linking_2021">Ran Abramitzky / Leah Boustan / Katherine Eriksson / James Feigenbaum / + Santiago Pérez: Automated Linking of Historical Data. In: Journal of Economic + Literature 59 (2021), H. 3, S. 865–918. DOI: 10.1257/jel.20201599 + <ptr type="gbv" cRef="129078794"/></bibl> + <bibl xml:id="abramitzky_linking_2020">Ran Abramitzky / Roy Mill / Santiago Pérez: Linking individuals across + historical sources: A fully automated approach. In: Historical Methods: A Journal + of Quantitative and Interdisciplinary History 53 (2020), H. 2, S. 94–111. DOI: 10.1080/01615440.2018.1543034 <ptr type="gbv" cRef="166715824"/></bibl> + <bibl xml:id="baehr_bevoelkerungsgeographie_1992">Jürgen Bähr / Christoph Jentsch / Wolfgang Kuls: Bevölkerungsgeographie. Berlin + u. a. 1992. (= Lehrbuch der allgemeinen Geographie, 9). <ptr type="gbv" cRef="028380339"/></bibl> + <bibl xml:id="baxter_methods_2003">Rohan Baxter / Peter Christen / Tim Churches: A Comparison of Fast Blocking + Methods for Record Linkage. 2003. PDF. [<ref + target="https://www.researchgate.net/publication/2838209">online</ref>]</bibl> + <bibl xml:id="boettcher_ahnenblatt_2018">Dirk Böttcher: Ahnenblatt Handbuch. 2018. PDF. [<ref + target="https://www.ahnenblatt.de/downloads/Ahnenblatt-Handbuch.pdf" + >online</ref>]</bibl> + <bibl xml:id="christian_record_2015">Peter Christen / Dinusha Vatsalan / Zhichun Fu: Advanced Record Linkage Methods + and Privacy Aspects for Population Reconstruction. A Survey and Case Studies. In: + Population Reconstruction. Hg. von Gerrit Bloothooft / Peter Christen / Kees + Mandemakers / Marijn Schraagen. Cham u. a. 2015, S. 87–110. DOI: 10.1007/978-3-319-19884-2_5 <ptr type="gbv" cRef="833549804"/></bibl> + <bibl xml:id="church_gedcom_2019">The Church of Jesus Christ of Latter-day Saints: The GEDCOM Standard. Salt Lake City 2019. Release + 5.5.1. vom 15.11.2019. PDF. [<ref + target="https://edge.fscdn.org/assets/img/documents/ged551-5bac5e57fe88dd37df0e153d9c515335.pdf" + >online</ref>]</bibl> + <bibl xml:id="efremova_entity_2015">Julia Efremova / Bijan Ranjbar-Sahraei / Hossein Rahmani / Frans A. Oliehoek / + Toon Calders / Karl Tuyls / Gerhard Weiss: Multi-Source Entity Resolution for + Genealogical Data. In: Population Reconstruction. Hg. von Gerrit Bloothooft / + Peter Christen / Kees Mandemakers / Marijn Schraagen. Cham u. a. 2015, S. 129–154. + DOI: 10.1007/978-3-319-19884-2_7 <ptr type="gbv" cRef="833549804"/></bibl> + <bibl xml:id="fan_understanding_2006">Jerome Fan / Suneel Upadhye / Andrew Worster: Understanding receiver operating + characteristic (ROC) curves. In: Canadian Journal of Emergency Medicine 8 (2006), + H. 1, S. 19–20. DOI: <ref target="https://doi.org/10.1017/S1481803500013336" + >10.1017/S1481803500013336</ref> <ptr type="gbv" cRef="776629255"/></bibl> + <bibl xml:id="feigenbaum_census_2016">James J. Feigenbaum: Automated census record linking: a machine learning + approach. 2016. Handle: <ref target="https://hdl.handle.net/2144/27526" + >2144/27526</ref></bibl> + <bibl xml:id="fure_record_2000">Eli Fure: Interactive Record Linkage: The Cumulative Construction of Life + Courses. In: Demographic Research 3 (2000). 12.12.2000. DOI: <ref + target="https://doi.org/10.4054/DemRes.2000.3.11" + >10.4054/DemRes.2000.3.11</ref></bibl> + <bibl xml:id="gellatly_populations_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. DOI: 10.1007/978-3-319-19884-2_6 <ptr type="gbv" cRef="833549804"/></bibl> + <bibl xml:id="georgala_record_2015">Kleanthi Georgala / Benjamin van der Burgh / Marvin Meeng / Arno Knobbe: Record + Linkage in Medieval and Early Modern Text. In: Population Reconstruction. Hg. von + Gerrit Bloothooft / Peter Christen / Kees Mandemakers / Marijn Schraagen. Cham u. + a. 2015, S. 173–195. DOI: 10.1007/978-3-319-19884-2_9 <ptr type="gbv" cRef="833549804"/></bibl> + <bibl xml:id="goldberg_entscheidungsfindung_2022">Jan Michael Goldberg: Kontextsensitive Entscheidungsfindung zur automatisierten + Identifizierung und Clusterung deutschsprachiger Urbanonyme. In: Zeitschrift für + digitale Geisteswissenschaften 7 (2022). 10.10.2022. DOI: <ref + target="https://doi.org/10.17175/2022_005">10.17175/2022_005</ref></bibl> + <bibl xml:id="goldberg_identifikation_2022">Jan Michael Goldberg / Katrin Moeller: Automatisierte Identifikation und + Lemmatisierung historischer Berufsbezeichnungen in deutschsprachigen + Datenbeständen. In: Zeitschrift für digitale Geisteswissenschaften 7 (2022). 08.03.2022. DOI: <ref target="https://doi.org/10.17175/2022_002" + >10.17175/2022_002</ref></bibl> + <bibl xml:id="gu_record_2003">Lifang Gu / Rohan Baxter / Deanne Vickers / Chris Rainsford: Record Linkage: + Current Practice and Future Directions. In: CMIS Technical Report 03/83 (2003). + PDF. [<ref + target="https://citeseerx.ist.psu.edu/pdf/a2c4dec86a96a99adc00cb664b703e8407216183" + >online</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> + <ptr type="gbv" cRef="366701630"/></bibl> + <bibl xml:id="hin_roman_2016">Saskia Hin / Dalia A. Conde / Adam Lenart: New light on Roman census papyri + through semi-automated record linkage. In: Historical Methods: A Journal of + Quantitative and Interdisciplinary History 49 (2016), H. 1, S. 50–65. DOI: 10.1080/01615440.2015.1071226 <ptr type="gbv" cRef="166715824"/></bibl> + <bibl xml:id="kaplan_venice_2015">Frédéric Kaplan: The Venice Time Machine. In: DocEng ’15: Proceedings of the + 2015 ACM Symposium on Document Engineering (DocEng, Lausanne, 08.–11.09.2015). New + York 2015, S. 73. DOI: 10.1145/2682571.2797071</bibl> + <bibl xml:id="kocka_familie_1980">Jürgen Kocka / Karl Ditt / Josef Mooser / Heinz Reif / Reinhard Schüren: + Familie und soziale Platzierung. Studien zum Verhältnis von Familie, sozialer + Mobilität und Heiratsverhalten an westfälischen Beispielen im späten 18. und 19. + Jahrhundert. Wiesbaden 1980 (= Forschungsberichte des Landes Nordrhein-Westfalen, + 2953). DOI: 10.1007/978-3-322-87746-8</bibl> + <bibl xml:id="massey_playing_2017">Catherine G. Massey: Playing with matches: An assessment of accuracy in linked + historical data. In: Historical Methods: A Journal of Quantitative and + Interdisciplinary History 50 (2017), H. 3, S. 129–143. DOI: 10.1080/01615440.2017.1288598 <ptr type="gbv" cRef="166715824"/></bibl> + <bibl xml:id="munke_citizen_2019">Martin Munke: Citizen Science / Bürgerwissenschaft. Projekte, Probleme, + Perspektiven am Beispiel Sachsen. In: Forschungsdesign 4.0. Datengenerierung und + Wissenstransfer in interdisziplinärer Perspektive. Hg. von Jens Klingner / Merve + Lühr (Dresden, 19.–21.04.2018). Dresden 2019, S. 107–124. DOI: <ref + target="https://doi.org/10.25366/2019.11">10.25366/2019.11</ref> + </bibl> + <bibl xml:id="nanayakkara_clustering_2018">Charini Nanayakkara / Peter Christen / Thilina Ranbaduge: Temporal graph-based + clustering for historical record linkage. In: Proceedings of 14th International + Workshop on Mining and Learning with Graphs (MLG 14, London, 20.08.2018). New York + 2018. PDF. [<ref + target="https://www.mlgworkshop.org/2018/papers/MLG2018_paper_14.pdf" + >online</ref>]</bibl> + <bibl xml:id="postel_phonetik_1969">Hans Joachim Postel: Die Kölner Phonetik. Ein Verfahren zur Identifizierung von + Personennamen auf der Grundlage der Gestaltanalyse. In: IBM-Nachrichten 19 (1969), + S. 925–931. <ptr type="gbv" cRef="129076759"/></bibl> + <bibl xml:id="schoenfelder_grundlagen_2015">Günther Schönfelder / Michael Börngen: Naturräumliche Grundlagen. Landschaft + und Klima. In: Geschichte der Stadt Leipzig. Hg. von Uwe John / Enno Bünz. 4 Bde. + Leipzig 2015–2019. Bd. 1 (2015): Von den Anfängen bis zur Reformation, S. 33–47. + <ptr type="gbv" cRef="774827831"/></bibl> + <bibl xml:id="schulz_gedtool_2017">Peter Schulz: GEDTOOL. Makrosammlung für GEDCOM-Dateien. V. 2.7 vom 14.09.2017. + PDF. [<ref target="https://gedtool.de/resources/GedTool_2_7.pdf" + >online</ref>] </bibl> + <bibl xml:id="thorvaldsen_record_2015">Gunnar Thorvaldsen / Andersen Trygve / Hilde L. Sommerseth: Record Linkage in + the Historical Population Register for Norway. In: Population Reconstruction. + Hg. von Gerrit Bloothooft / Peter Christen / Kees Mandemakers / Marijn Schraagen. + Cham u. a. 2015, S. 155–171. DOI: 10.1007/978-3-319-19884-2_8 <ptr type="gbv" cRef="833549804"/></bibl> + <bibl xml:id="time_machine_2022">Time Machine Organisation: Local Time Machines. 2022. HTML. [<ref + target="https://www.timemachine.eu/ltms/">online</ref>]</bibl> + <bibl xml:id="vfc_datenmodell_2016">Verein für Computergenealogie (2016a): Gedbas4all / Datenmodell. In: GenWiki. + Das Genealogie-Wiki. 2016. HTML. [<ref + target="http://wiki-de.genealogy.net/Gedbas4all/Datenmodell">online</ref>] </bibl> + <bibl xml:id="vfc_datumsangaben_2016">Verein für Computergenealogie (2016b): Gedbas4all / Datumsangaben. In: GenWiki. + Das Genealogie-Wiki. 2016. HTML. [<ref + target="http://wiki-de.genealogy.net/Gedbas4all/Datumsangaben" + >online</ref>]</bibl> + <bibl xml:id="vfc_kartei_2018">Verein für Computergenealogie: Kartei Leipziger Familien. In: GenWiki. Das + Genealogie-Wiki. 2018–2019. HTML. [<ref + target="http://wiki-de.genealogy.net/Kartei_Leipziger_Familien" + >online</ref>]</bibl> + <bibl xml:id="vfc_kartei_2019">Verein für Computergenealogie: Kartei Leipziger Kreisamtstestamente. 2019–2021. + HTML. [<ref target="https://des.genealogy.net/leipzig_testamente/search/index" + >online</ref>]</bibl> + <bibl xml:id="vfc_historic_2016">Verein für Computergenealogie: The Historic Gazetteer. 2021. HTML. [<ref + target="http://gov.genealogy.net/search/index">online</ref>]</bibl> + </listBibl> + </div> + <div type="abbildungsnachweis"> + <head>Abbildungs- und Tabellenverzeichnis</head> + <desc type="graphic" xml:id="abb1"> + Ablauf der Datenverarbeitung. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_001"/></desc> + <desc type="graphic" xml:id="abb2"> + Funktionsweise des Algorithmus als Nassi-Shneiderman-Diagramm. [Goldberg / Mernitz 2023]<ref + type="graphic" target="#record_2022_002"/></desc> + <desc type="table" xml:id="tab1"><ref target="#tab01">Tab. 1</ref>: + Definition von Datenfeldern. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab2"><ref target="#tab02">Tab. 2</ref>: + Zusätzliche Variablen eines zusammengeführten Datensatzes. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab3"><ref target="#tab03">Tab. 3</ref>: + Direkte Umwandlung der KLF-Struktur in die Normform. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab4"><ref target="#tab04">Tab. 4</ref>: + Indirekte Umwandlung der KLF-Struktur in die Normform. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab5"><ref target="#tab05">Tab. 5</ref>: + Direkte Umwandlung der KLK-Struktur in die Normform. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab6"><ref target="#tab06">Tab. 6</ref>: + Indirekte Umwandlung der KLK-Struktur in die Normform. [Goldberg / Mernitz 2023]</desc> + <desc type="table" xml:id="tab7"><ref target="#tab07">Tab. 7</ref>: + Übersicht über die Anzahl der verknüpften Personen aus den Normformen. [Goldberg / Mernitz 2023]</desc> + </div> + </div> + </body> + </text> +</TEI>