FactGrid talk:Leipzig

From FactGrid
Jump to navigation Jump to search

To Do

  • die Differenzierung von natürlicher Person und Alleinunternehmen bedarf der Klärung => Informationen über ein Unternehmen müssten auf das Unternehmens-Item gelegt werden, Personeninformationen auf das andere Item, beide können über "Eigentümerschaft" verbunden werden. Laurenz Stapf (talk) 21:48, 27 March 2024 (CET)
Bsp. item:Q892119 der Verlag und item:Q544434 die natürliche Person Robert Crayen (Verleger)
Bsp. item:Q539685 die Modefirma und item:Q895495 die natürliche Person Gismunde Herzberg (geb. Rosenlaub)
Ein wichtiges Merkmal kann hierbei der Rechtsübergang (einer Firma, einer Wohnung) sein, die Annahme eines Namens, oder die Auflösung einer Firma. Vgl. Münchner Buchhandelslizenzen
Siehe auch: staatliche Lizenzen in Sachsen
  • Record Linkage zusätzlicher Datenbanken: Online Informationen dienen zur Notation, wo Personen und Objekte in anderen Datenbanken Entsprechungen finden. !Achtung – Bei Treffern in anderen Datenbanken ist die Konsistenz der Identität zu prüfen und gegebenenfalls zu notieren!

Ausgehend von diesen Datenbank-Treffern können Informationen in dem Datensatz ergänzt und mit der jeweiligen Fundstelle versehen werden. Hierzu gehören bspw. Lebensdaten, Berufsangaben, Familien- und Verwandschaftsverhältnisse (nicht abschließend).

Leipzig

Mustersuchen, die auf Leipzig übertragbar sind/ wären

Anwendungsbeispiele in den Leipzig-Daten

Benutzbar ist die Factgrid-Datenbank über sog. "SPARQL"-Abfragen. (Siehe Query Service, links im Menü)

Die Navigation kann über das "i"-Feld per Auswahl vorgenommen werden, oder in Sparql-Befehlen angegeben werden. Im folgenden sollen einige Anwendungsbeispiele gegeben werden, die vgl. zu den obigen Datenbeispielen Abfragen auf den Leipzig Daten anwenden. Zur eigenen Modifizierung: Die Items codieren eine Eigenschaft des Objekts, beispielsweise den Beruf derHebamme (Q38388). In dem Sparql-Befehl kann dieser, um eine andere Personengruppe ersetzt werden durch eine neue, zu filternde Eigenschaft.

  • Miete Hebammen in Leipzig? die letzte Spalte gibt für die Währungseinheit das Silberäquivalent an. Wahrscheinlich könnte man mit SPARQL auf den Betrag mit den Gramm-Angaben multiplizieren, um in einer Spalte die ausgerechneten Silber-Äquivalente zu haben. --Olaf Simons (talk) 19:24, 8 September 2023 (CEST)

Arbeits-Pad für das Blockseminar

Detailkarten und Angaben zur Historischen Bausubstanz

  • Cornelius Gurlitt: Beschreibende Darstellung der älteren Bau- und Kunstdenkmäler des Königreichs Sachsen. Achtzehntes Heft: Stadt Leipzig, Dresden, 1896, SLUB-Digitalisat.
  • Sebastian Ringel: Wie Leipzigs Innenstadt verschwunden ist. 150 verlorene Bauten aus 150 Jahren, Leipzig 2022.
  • Nadja Horsch und Simone Tübbecke (Hg): Bürger, Gärten, Promenaden. Leipziger Gartenkultur im 18. und 19. Jahrhundert, Leipzig 2019, S. 170, Abb. 6, Plan der Stadt Leipzig mit der Röhrenfahrt aus denen beiden Wasser Künsten, 1782, StadtAL RRA(F) Nr 323.
  • Leipziger Wassergeschichte Themenheft
  • Übersicht Bauliche und Archäologische Befunde am "Matthäiikirchhof"

Quellenmaterialien

Grundlage: Leipziger Mieterverzeichnisse (1807-1858) – Sämtliche Quellenbücher der hier ausgewerteten "Mietabgabe" werden zurzeit im Wikicommons bereitgestellt, sodass sie sich als Quellenbeleg mithilfe der property:P1089 verlinken lassen. Der Abgleich mit den Brandkatasternummern (neu/alt) erfolgt dabei optisch und benötigt der Zuarbeiten.

Error creating thumbnail: Unable to save thumbnail to destination
Übersicht Transkriptionsmerkmale
Transkriptionstabelle Mieterbücher
lfd. Nr. Permalink zur CommonsQuelle Brandkasternummer Position Wohneinheit (- Innerhalb der Seite, von oben nach unten) Position Mietverhältnis (zeitliche Abfolge) qid Person (falls vorhanden) Nachname (Transkription) Vornamen (Transkription, unaufgelöst) Beruf/Status (Transkrition, unaufgelöst) Art_Mietobjekt (räumliche Beschreibung, Transkription) Log_Gew (Transkription) Einzug (Datum oder Bezeichnung) Auszug (Datum oder Bezeichnung) siehe_vorige_Wohnung (Brandkatasternr. falls vorhanden) Monat_erster_Zahlungstermin Jahr_erster_Zahlungstermin Mietzins Abgabensatz (Abgabe pro Taler) siehe_nachfolgende_Wohnung (Brandkatasternr. falls vorhanden) Weitere_Kommentare
1 commons.wikimedia.org/…_0008_Nr_3191_Seite_230.jpg 199 (hier item:Q482912) 3 (hier item:Q546992) 1 –– Jendersky –– Frau verw. Schneider –– Log. –– aufgegeben -– Oktober 1854 64 XX,06 –– ––
2 https://commons.wikimedia.org/…_0008_Nr_3191_Seite_230.jpg 199 (hier item:Q482912) 3 (hier item:Q546992) 2 –– Fromm Karl Werkführer b. Harkort -- Log. –– Mich. 58 –– Januar 1857 70 XX,06 514 item:Q482812
3 https://commons.wikimedia.org/…_0008_Nr_3191_Seite_230.jpg 199 (hier item:Q482912) 3 (hier item:Q546992) 3 –– Böttcher Glob. Bahnh. Beamt. –– Log. Mich. 58 –– 882 item:Q482540 Januar 1859 80 XX,06 –– ––
Katasterkonkordanz von 1842 item:Q481490 (offline: Fotos der "Konkordanz"): Nachweis aller Katasternummern nach der alten (1797-1842) und neuen Nummerierung (ab 1842) – für das Leipzig Projekt wichtigster Verknüpfungspunkt zwischen (Straßen-)Hausnummern (Orientierung im Stadtplan) und Katasternummer (Orientierung im Mieterverzeichnis) Vermessung des Merzdorf-Modells, Datei (offline) Historisches3DStadtmodell_normalGEB_300922_profiles.svg
Zum Merzdorf-Modell hier ein Artikel aus dem Leipziger Tagblatt und Anzeiger, 30.5.1876, Titel "Ein Ehren-Gedächtniß", Autor ist Otto Moser: http://digital.slub-dresden.de/id453042023-18760530

Adressbuch 1851

Transkriptionstabelle Adressbücher
lfd. Nr. Permalink Seite Adressbuch Firma Name Firma Qid (Falls bereits vorhanden) Firma Adresse (Nur transkribieren, nicht abgleichen) Eigentumsverhältnisse (kurze Beschreibung, ob mehrere, oder ein Eigentümer) Eigentümer Name (Nur exakt Transkribieren, Abkürzungen nicht auflösen. "Hr." für Herr nicht übernehmen) Eigentümer Qid (Falls vorhanden) Eigentümer Wohnadresse (nur transkribieren, nicht abgleichen)
1 http://digital.slub-dresden.de/id359480586-18450000/132 F. A. Brockhaus item:Q248323 Leipzig, Querstraße 8 Eigentümer
Eigentümer
Prokurist 		Friedrich Brockhaus
Heinrich Brockhaus
Carl Ferdinand Bochmann 		Querstraße 8

Weitere Quellen zu Personenangaben – Record Linkage

  • Kartei Leipziger Familien – Genealogischer Datensatz des Staatsarchivs Leipzig. Über den Abgleich von Namen und Beruf lassen sich hiermit Verwandschaftsverhältnisse rekonstruieren und in FacGrid dokumentieren – Interessant für die Untersuchung von Mobilität nach und Peer groups innerhalb der Stadt
  • Hartmut Zwahr: Zur Konstituierung des Proletariats als Klasse. Strukturuntersuchung über das Leipziger Proletariat während der industriellen Revolution, München 1981. – Für ein Record-Linkage eignen sich das Personenverzeichnis auf den Seiten 345-364, sowie die enstprechenden Textfundstellen. => Forschungsgegenstand für Zwahr ist die Verbindung von proletarischen Familien auf der Ebene der Arbeitsplatz- und Alltagsinteraktion. Analoge Datensammlung aus den Tauf- und Kirchenbüchern in Leipzig, Vorlass im Archiv der FES in Bonn einsehbar. (Mittelfrist: Prof. Fertig)
  • "Eheklagesachen" – Vmt. Ehevertragsklagen und Scheidungssachen im Projektzeitraum, geeignet für einen Abgleich von Personennamen und Auswertung mit einzelner Akteneinsicht beim Staatsarchiv Leipzig. Bsp. item:Q895495#P185 – Klage Gismunde Rosenlaub gegen Kurt Herzberg.
  • item:Q947180 Werbe- Familien- und Wohnungsanzeigen im Leipziger Tageblatt (1833-). Digitalisate stellt die Sächs. Landes- und Universitätsbibliothek Dresden bereit. Eine Transkriptionsmaske mit Transkribus ist in Erprobung. ––Laurenz Stapf (talk)

Anwendung

Gute Orts- und Objektnamen

behaltet im Blick, dass Euer Projekt sich in einer wachsenden Masse an Projekten entfaltet. Ich setzte da bei den Labels nach, die Ihr auf Dinge wie das "Stadtmodell" legtet. Wir werden ganz viele "Poststraßen" bekommen und stellen darum den Ortsnamen voran - so wie hier

Meist weiß man bei der Suche, in welchem Ort man eine Poststraße sucht und bei Listenausgaben (etwa von Adressen einer Person, erscheinen dann brauchbare Informationen, selbst wenn man nicht die Stadt mit abfragte. Grüße --Olaf Simons (talk) 12:49, 3 February 2023 (CET)

Jahresmieten und Steuerangaben

Text mit Erklärung, am besten mit Abbildung aus Dokument und Screenshot des FactGrid-Eintrags mit Erklärung, wie die Zahlen umgesetzt wurden.

Im folgenden soll kurz dargestellt werden, wie im letzten Schritt der Einpflegung der Mietdaten im Projekt die Miethöhe und die für die Quelle konstitutiven Abgaben eingepflegt worden sind. Hierbei sind Schwierigkeiten bei der Interpretation und Aussagekraft des Wertes zu beachten.

Gegeben ist aus der Quelle die Angabe der:s Mieter:in, sowie in roter Tinte erkennbar Informationen zum Ein- und Auszug, sowie zu Änderungen der Nutzung.
Error creating thumbnail: Unable to save thumbnail to destination
Quellenbeispiel: "Großberger und Kühl", Q544744
In den Spalten "Miethzins" (sic!)ff. findet sich festgehalten, welche jährliche Mietzahlung (In Reichstalern nach dem 14-Taler-Fuß) der:die Mieter:in zu leisten hat. An der Höhe der Miete bestimmt sich die Festlegung eines von vier Hebesätzen, die in den Spalten "jährlicher Beitrag, vom Thaler" (sic!) nach Neugroschen und Pfennig angegeben ist. Das gegebene Beispiel "Großberger und Kühl" (angegeben als "Gastwirthsch. Pächter" (sic!)) ist dabei die höchste, in den bisherigen Daten, verzeichnete Mietsumme. Fällig wird hierbei der höchste von vier Hebesätzen à 3 Neugroschen und 8 Pfennig je Taler. Von dem hierdurch ermittelbaren prozentuale Satz von anzunehmenden etwa 13% "Jährlichem Beitrag, Zum vollen Satze." (sic!) wird allerdings nur ein Viertel als tatsächliche jährliche Abgabe in der nächsten Spalte erhoben. Diese ist anteilig halbjährig fällig, normalerweise im Mai und November. Diese Operation zur Ermittlung eines Steuersatzes auf das Mietverhältnis wurde in der Tabelle (s.u.) nachvollzogen, die die Grundlage für den Datenupload bildete.

Werfen wir aber wieder einen Blick in das Quellendigitalisat und vergleichen die angegebenen Werte in der Datentabelle und der historischen Quelle: es fällt auf, dass bereits der tatsächliche "volle Satz" von 219 Talern, 16 Neugroschen und 7 Pfennig deutlich von dem ermittelten "vollen Satz" von etwa 329 Talern abweicht.

Ursachen

Mit roter Tinte vermerkt ist unterhalb der Mietsumme "mit 1/3 Erlaß" (hinsichtlich des vollen Beitrags). Die Begründung für diesen Erlaß fehlt allerdings und wurde bei der Transkription auch nicht erfasst. Hieraus ergibt sich im Umgang mit der Abgabenhöhe (neben kleineren Rundungsunregelmäßigkeiten) ein bisher nur über Stichproben feststellbares Auseinanderfallen von Hebesatzklasse und tatsächlicher Steuerklasse. Wie stark letztere in der Erhebung im Vergleich zur progressiven Bemessung der ersteren abweicht, wäre noch zu ermitteln. Auch mögliche Ermäßigungsvorgaben können aus der Quelle selbst nicht geschlossen werden.

Vermutung 1: Gaststätten u.ä. genießen einen Steuervorteil von 1/3 des Abgabensatzes. Andere Abschreibungsmöglichkeiten bestehen darüber hinaus.

Stichproben: Johanne Gausche Wilhelm Ratsch Kaffeehaus Klassig Witwe Klassig– Sonderkonditionen

Umgang mit sich ändernden Mietsummen

Error creating thumbnail: Unable to save thumbnail to destination
Screenshot, Dokumentation der Vorgehensweise zur Berechnung der Steuer (jährlich) auf Mieten im Projekt "Das alte Leipzig"

Berufsangaben

Durch die Einspeisung in Q-Items treten (inhaltlich ungewollte) Abweichungen zur Transkription auf. Als solche entdeckte Transkriptions- und Verdatungsfehler können laufend nachbearbeitet werden. Eine Lücke zwischen Quellenaussage und Interpretation im Factgrid bleibt zur Zeit aber vorhanden (siehe Bsp.). Wäre es möglich und sinnvoll, die Bearbeitung im Prozess durch hinzufügen einer String-Eigenschaft (Wiedergabe der Transkription als Notiz) zu ergänzen? --Laurenz Stapf (talk) 21:07, 22 September 2023 (CEST)

Ergänzt wurde zuletzt über die P35-Property (wörtliche Aussage) die im Rahmen des Projekts ermittelte Transkription der Berufe. Diese ermöglichen, die Angabe laut der Berufsklassifikation abzugleichen. --Laurenz Stapf (talk) 15:05, 26 September 2023 (CEST)

Brühl-Adressen

Die Georeferenzierung der Häuser (und damit verbundenen Mietobjekte) wurde noch einmal überprüft und angepasst. – inklusive der Angaben zu den Brandkatasternummern. Netter Seiteneffekt: viele Häuser tragen klingende Zunamen, die Orte innerhalb der Altstadt eventuell sogar nachhaltiger identifizierbar machen als die (neuzeitlich noch recht schwankungsanfällige) Hausnummerierung. Können wir die bei den nächsten Erschließungsrunden mit erfassen, oder bei Gelegenheit nachtragen? Bzw. wie können wir noch die unterschiedlichen Nummerierungsregime zwischen 1800 und Heute markieren? --Laurenz Stapf (talk) 14:32, 20 October 2023 (CEST)

ˑGenau das habe ich auch gemacht - im Gotha Datensatz; Bruno Belhoste im Paris Datensatz nicht minder. Ich glaube wir machten es nicht exakt gleich. Du magst nachdenken, was passt, was nicht, und wie es sich entwickeln sollte. --Olaf Simons (talk) 14:41, 20 October 2023 (CEST)


Theoretisch könnte man auch Properties (definiert als "Externe Identifier") definieren und eine Liegenschaft damit nach unterschiedlichen System notieren. Im Gotha Fall stand ich vor der Lage, dass Namen sich wandelten, Nummern eher mal so gewechselt wurden, insbesondere geteilt wurden... der Systemumbruch kommt dann zudem noch von totaler Hausnummerierung zu straßenweiser. Also habe ich eine Property für Adressnennungen geschaffen und Quellen gesetzt. --Olaf Simons (talk) 15:15, 20 October 2023 (CEST)

Update: Geokoordinaten

Die Georeferenzierung der Hauskataster wird auf Basis der item:Q704507 (Kanitz-Pläne) überarbeitet. Dabei sollen für Abfragen die Geokoordinaten über die Liegenschaft, statt über das einzelne Mietobjekt (die darin befindliche Wohneinheit) abgerufen werden. Die generischen Abfragen wurden dementsprechend angepasst. Mittelfristig können die Geokoordinaten auf den Mietobjekten wieder gelöscht werden. --Laurenz Stapf (talk) 13:13, 23 January 2024 (CET)


Verfahren zum Record Linkage bei Umzügen

Der aktuelle Datenbestand enthält 5.497 Mietverhältnisse von 415 Adressen in 23 Straßen, in der Regel beginnend in den Jahren 1842 bis 1853. Die Mieter sind häufig – Größenordnung: gefühlt jährlich – umgezogen, ein Teil innerhalb des hier erfassten Innenstadtbereichs.

Zunächst hatten die Adressen Q-Nummern bekommen, noch nicht aber die Wohnungen innerhalb der Häuser sowie die Mieter als Person. Es stellte sich also die Herausforderung, die Mieter über mehrere Mietverhältnisse hinweg zu identifizieren, trotz Schreibvarianten (incl. Lesefehlern) der Namen und Berufe. Hilfreich hierfür ist die Tatsache, dass in der Quelle die Brandkatasternummer der vorherigen und die der nachfolgenden Wohnung beide angegeben sind. Aber damit allein, ohne den Namen, ist die konkrete Person noch nicht auffindbar, da es ja pro Adresse durchschnittlich etwa ein Dutzend Mietverhältnisse und meist auch mehrere Wohnungen gibt.

Den Namensbezeichnungen waren vorgängig von Katrin Moeller mit einem Skript Geschlechtsangaben zugeordnet worden. Hierfür hatte sie allerdings die Berufsbezeichnungen, die in der Originalschreibweise oft Hinweise auf das Geschlecht geben, nicht genutzt. Ich habe die Geschlechtsangaben daher manuell in 1.018 Fällen korrigiert, überwiegend (in 910 Fällen) indem ich von Katrin als „unsicher/unbekannt“ eingestufte Fälle einem Geschlecht zuweisen konnte. Meine Einstufung beruhte dabei auch auf einem Abgleich der Vornamen, für die ich vorgängig zahlreiche Abkürzungen und Schreibvarianten aufgelöst hatte (beim ersten Vornamen betrifft das 1.202 Mietereinträge). Ich verwende abweichend von Katrin auch die Kategorie „juristische Person“ als Geschlechtsangabe, das betrifft auch Firmen, die von männlichen Personen gemeinsam geführt werden. Die Abgrenzung zwischen juristischen Personen (Firmen) und natürlichen Personen (mit dem entsprechenden Beruf) ist dabei schwierig und vielleicht noch korrekturbedürftig.

Voraussetzung für den Abgleich von Namensähnlichkeiten ist es, zunächst phonetisch irrelevante Schreibvariationen zu vereinheitlichen. Hierfür habe ich die Kölner Phonetik verwendet. Diese wandelt gleich klingende Namen in identische Zahlencodes um, z.B. haben die Namen Brauer, Bräuer, Pierer und Prior alle den Code 177. Dabei entspricht jede Ziffer einer Gruppe von Buchstaben, sodass der von Brauer nur leicht abweichende Name Dröher den Code 277 bekommt. Für diese Codierung habe ich ein SAS-Skript verwendet: Redscope.org-Forenbeitrag "Soundex und Kölner Phonetik" von Hans Kneilmann, 9.2.2009, https://communities.sas.com/kntur85557/attachments/kntur85557/code_sas/928/1/983_Soundex_und_K%C3%B6lner_Phonetik.pdf. SAS ist für Lehr- und Lernzwecke gratis nutzbar. Es handelt sich um eine seit langem etablierte sehr leistungsfähige Software, die ich selbst gut beherrsche, und die in ihrem Anwendungsbereich etwa mit R oder Python vergleichbar ist. Die Codierung habe ich für alle Nachnamen und auch Vornamen vorgenommen (im Folgenden aber nur die Codierung der Nachnamen weiter genutzt). Das verwendete Skript geht mit dem Buchstaben ß nicht richtig um, hier gibt es also noch etwas Korrekturbedarf.

Eine paarweise Zusammenführung von allen Personennennungen aus Mietverhältnissen, für die gilt, dass sowohl der Verweis auf die vorherige (oder spätere) Katasternummer übereinstimmt als auch der nach der Kölner Phonetik standardisierte Nachname, führt noch nicht zu fehlerlosen Ergebnissen. Ich habe daher die Daten nicht nur anhand der exakt identischen Kölner-Phonetik-Nachnamen zusammengeführt und dann manuell überprüft, sondern auch die Levenshtein-Distanz genutzt und Kombinationen manuell überprüft, für die eine Levenshtein-Distanz von 1 zwischen Kölner Phonetik des Nachnamens im einen und im anderen Mietereintrag bestand. Für die manuelle Korrektur galt dabei: Was ich suchte, war die Identität von Personen, nicht ein familiärer Nachfolgekonnex. Die Unterscheidung war nicht immer eindeutig zu treffen. Als nicht-identisch habe ich Personen z.B. dann betrachtet, wenn die Vornamen klar unterschiedlich waren, oder wenn die Vornamen nur partiell gleich, die Berufe aber unterschiedlich waren. Passend sind z.B. Kombinationen, bei denen Vornamen zumindest teilweise gleich sind oder auf der einen Seite kein Vorname steht und zugleich die Berufe zumindest ähnlich sind.

An dieser Stelle, also bei der manuellen Überprüfung, hat sich die Notwendigkeit mehrerer Durchgänge ergeben, zwei durch mich und ein weiterer durch Laurenz Stapf. Dieser hat dann vorgeschlagen, dass wir die algorithmisch vorgeschlagenen Verknüpfungen nach folgendem Schema bewerten: B => Bestätigte eindeutige Identität B2 => Vermutlich übereinstimmende Identität B3 => geprüft, vermutliche Identität bestätigt N => Eindeutig keine Identität, inklusive Sichtung und Prüfung. N2 => Vermutlich keine Identität N3 => geprüft, vermutliche Identität verneint, teilweise Verwandtschaft möglich U => Unklar, weiter zu prüfen U2 => Unklar, Beruf uneindeutig U3 => Unklar, Person uneindeutig

Die unklaren Fälle wurden im Zuge der Bearbeitung komplett geklärt. Für die aufgrund von Quelleneinträgen zur vorherigen Hausnummer möglichen Links mit einer Levenshtein-Distanz (zwischen den nach Kölner Phonetik codierten Nachnamen) von 0 ergeben sich nach diesem System 760 bestätigte Links (und 163 abgelehnte); bei einer Distanz von 1 kommen noch 9 bestätigte hinzu. Für die aufgrund der nachfolgenden Hausnummer möglichen Links finden wir 522 bestätigte bei Distanz 0 und 16 bei Distanz 1 (und 137 abgelehnte bei Distanz 0). Die abgelehnten Verknüfungen werden bei der Weiterarbeit durchaus eine nähere Betrachtung lohnen, es handelt sich hier oft um den Umzug der Witwe in eine neue Wohnung oder um die Übernahme des Geschäfts durch die Nachfolger an einer neuen Adresse. Übrig blieben 859 Zusammenführungen, davon 641 aufgrund der Verweise auf die vorige und 538 aufgrund der Verweise auf die nächste Wohnung (dabei in 640 Fällen aufgrund beider Verweistypen). Ein nächstes Ziel bestand darin, die Daten weiter zu kondensieren, indem wir aus den Paaren von zusammenpassenden Kennungen (also immer Herkunftswohnungseintrag – Zielwohnungeintrag) Gruppen bilden, die jeweils eine Person bezeichnen.

Strategie 1: Access-Abfragen. Folgende Fälle bereiteten dabei Problem: (1) Paare, die dieselbe ID zusammenführen, also einen Umzug in dieselbe Wohnung bezeichnen. Es gibt 5 solche Fälle: 8751b5, 8266b4, 133657b1, 133507c2, 133231b1, zustandegekommen dadurch, dass z.B. jemand eine Wohnung vom Vater übernommen hatte oder vom Haus 36a in Haus 36 umgezogen war. Die entsprechenden Paare sind für die weitere Zusammenführung zunächst zu löschen (danach wäre hier inhaltlich nachzukorrigieren). (2) Paare, die sowohl in die eine als auch in die andere Richtung umziehen. Diese scheinen auf entsprechenden falschen Zahlenverweisen in der Quelle zu beruhen. Allein für den Fall des direkten hin-und-her-Umzugs sehe ich über 100 solche Verbindungen. Für den Zweck der Zusammenführung ist jeweils eine der Verbindungen beizubehalten (wieder abgesehen davon, dass hier inhaltlich die Quelle neu zu lesen ist). (3) Für etliche Mietverhältnisse gilt, dass sie auf anderem Wege in hin und her führenden Pfaden auftauchen, hier entferne ich zunächst alle Paare, in denen diese als Ziel vorkommen. Nach diesen Bereinigungen führen die längsten Umzugspfade innerhalb der hier untersuchten Kernstadt über 5 Stationen. (4) Da wir zwei unterschiedliche Informationsquellen zur Zusammengehörigkeit haben (Verweis auf frühere und auf spätere Wohnungen), ergeben sich immer noch für zahlreiche Fälle mehrfache Reihenfolgen. Ich brach diese Strategie daher ab.

Strategie 2: Daten mit einer Netzwerkanalyse zusammenfassen. Hierfür sind die eben benannten Bereinigungsschritte (1) bis (3) überflüssig, es reichen die Kennungen der „Kanten“ Herkunftseintrag – Zieleintrag. Gesucht sind „weakly connected components“, also Gruppen aus denjenigen Knoten, für die gilt, dass sie ohne Berücksichtung der Richtung direkt oder indirekt verbunden sind. Ich habe die Paar-Daten daher in Pajek eingelesen, hierfür mussten die alphanumerischen Ids in Zahlen umgewandelt werden. Hierzu sind einige Schritte mit Pivottabellen und SQL-Abfragen erforderlich: (a) Herstellen einer Liste aller Paar-Datensätze („Kanten“, „arcs“) ohne Doubletten (idkombi.csv), (b) Ermitteln aller einzelnen Datenpunkte („Knoten“, „vertices“) ohne Doubletten, die in diesen Paar-Datensätzen vorkommen, und Zuweisen einer Laufnummer (idkombipajekcode.csv), (c) Zuweisen dieser Laufnummern („Knoten“) an die Elemente der Paar-Datensätze („Kanten“); eine Fehlerquelle besteht in Ids, die den Buchstaben e enthalten. Diese Zahlencodes müssen dabei nach Korrekturen (also z.B. nach weiteren Streichungen von Umzugs-Kombinationen) jeweils neu angelegt werden. In Pajek - http://mrvar.fdv.uni-lj.si/pajek/ - erhält man die weak components über das Menü mit Network – Create Partition – Components – Weak – Minimum Size: 2. Hierdurch wurden die 1.452 mehrfach vorkommenden Personenbenennungen („Personas“) auf 649 weak components reduziert. Die 5.497 Mietverhältnisse konnten somit 4.694 Personen zugeordnet werden.

Error creating thumbnail: Unable to save thumbnail to destination
Screenshot, Vorgehensweise zum Zusammenführen von Personen bei Umzügen im Projekt "Das alte Leipzig"


Da nunmehr nicht nur die Adressen über Q-Nummern verfügen, sondern auch Personen identifiziert sind, stand dem nächsten Schritt nichts mehr im Wege, nämlich die Personen ebenso wie die Mietverhältnisse dieser Personen an diesen Adressen und in den (ebenfalls bereits mit Kennungen versehenen) Wohnungen in FactGrid anzulegen. Hierfür waren nunmehr Namens-Label für den Import ins FactGrid zu vergeben, und in diesem Zuge konnten auch Fälle noch einmal korrekturgelesen werden, bei denen sich aus der Record Linkage Widersprüche bei Geschlecht oder Beruf ergeben. In nachfolgenden Record-Linkage-Schritten sollten dann auch für die als nicht identisch, aber verwandt identifizierten Verbindungen Kennungen vergeben werden. Stand Mitte August ist das nunmehr geschehen. Es liegen also vor: 5.497 Mietverhältnisse, mit ID „QuellenID“ 4.694 Personen, mit ID „PersonenID“, Geschlecht „sex Korrektur LS“, Label „Labelvorschlag“.

2 Properties für Arbeitsstände

Da wir eine Forschungsinstanz betreiben, zwei Properties mit der Projekte Items markieren können, an denen ein bestimmter Arbeitsschritt noch vorzunehmen ist:

P17 ist die häufigere, mit der wir notieren, was noch an Einem Datenbankobjekt zu tun ist. --Olaf Simons (talk) 12:05, 23 October 2023 (CEST)

Häuserbuch und Adresskonkordanz

Ich bin gerade über diese ziemlich interessante Quelle gestolpert, die für die Erfassung der Grundstücke in historischer Dimension noch einmal ganz andere Möglichkeiten bietet (falls noch nicht bekannt) da sie eine Konkordanz der Hausnummern von 1793 und 1885 bietet:

https://api.pageplace.de/preview/DT0400.9783050073835_A36072183/preview-9783050073835_A36072183.pdf (Link leider nur Auszug)

Nach einem ersten Blick scheinen beide hier genutzten Nummerierungssysteme unterschiedlich zum ins Factgrid gebrachte System zu sein?


Mit besten Grüßen, David Löblich (talk) 12:42, 10 December 2023 (CET)

Um Verwirrungen zu vermeiden, muss sowieso eine transparente Property dazu, die die "Zeitlichkeit" der Nummerierungregime kennzeichnet. Gerade sind die Daten noch innerhalb eines Regimes. – Außerhalb des Hist. Rings ist da um 1850 schon viel im Fluss und die Deckung zwischen den Konkordanzen und Katasterkarten schwankt. Hier überlegen wir uns was Fesches (siehe die Beispiele aus Paris und Gotha, oder Deine Projekte in Aschersleben.) :D -- Laurenz Stapf (talk) 13:12, 23 January 2024 (CET)
Retrieved from "https://database.factgrid.de/w/index.php?title=FactGrid_talk:Leipzig&oldid=8769679"