Von impliziten zu expliziten Strukturen: Ein historisches Adressbuch in TEI #dhmasterclass

Adressensammlungen können aus ganz verschiedenen Gründen ein wahrer Schatz sein. Datensammler verwenden Anschriften beispielsweise dazu, mithilfe von Geoscoring einen Indikator für Kreditwürdigkeit zu erzeugen. Datenschützer gehen deshalb aus gutem Grund auf die Barrikaden, wenn es um die Weitergabe von Adressen geht oder setzen sich für höhere Transparenz der Einsatzzwecke ein. Aber nicht nur Datenhändler sehen in Adressen eine Ressource, denn auch für Geschichtsforscher sind historische Adressbücher als Spiegel sozialgeschichtlicher Zustände und Entwicklungen von großem Interesse.

Der Eintrag zu Heinrich Heine im historischen Adressbuch – und in TEI-XML

Im Rahmen der #dhmasterclass haben wir uns (neben vielen anderen Dingen) mit dem “Adreßbuch der Deutschen in Paris für das Jahr 1854” beschäftigt. Adressbücher wie dieses enthalten aus der Sicht der Datenverarbeitung biographische Momentaufnahmen. In einer einzeiligen Kurzgeschichte führen sie Namen, Wohnorte und manchmal auch Berufstätigkeiten zusammen. In dieser stark komprimierten Form entfalten sie sich als Biographien der Möglichkeiten: Namen geben manchmal Hinweise auf den sozialen Stand (Adelsprädikate), auf eheliche Verbindungen (Doppelnamen) und auf kulturelle Wurzeln (Sprache). Straßennamen oder Bezirke zeigen möglicherweise Wohlstand oder Armut an. Berufsbezeichnungen entfalten Genrebilder vor dem inneren Auge des Lesers und lassen ihn über alltägliche Tätigkeiten und Lebensumstände von Polizeidienern, Kästchenmachern, Harmonikafabrikanten oder Speckhändlern nachdenken.

In dem Adressbuch finden sich auch Persönlichkeiten wie Heinrich Heine (siehe Abbildung), Adolphe Sax, der Erfinder des Saxophons (der aber Belgier war), und die Komponistin Julie Massenet, die als Klavierlehrerin arbeitete (ihre Familie stammte teilweise aus dem Elsaß, und ihr jüngster Bruder war der Opernkomponist Jules Massenet).

Implizit beinhalten diese Adressbücher ganze Netzwerke von Berufsgruppen und Nachbarschaften. Personen könnten sich gekannt haben, insbesondere wenn sie im selben Haus wohnten, oder wenn sie innerhalb eines Stadtteils einen Beruf innerhalb desselben Branche ausübten. Schon aus logistischen Gründen ist es naheliegend, dass sich Betriebe eines Geschäftszweiges akkumulieren, wie beispielsweise Tuchmacher und Färber. Sophie Schneider visualisierte den Inhalt des Adressbuches auf einer Karte mithilfe von Georeferenzierung und konnte dadurch aufzeigen, welche Branchen in welchen Stadtteilen verbreitet waren.

Derzeit liegt das Adressbuch in einer Tabelle vor. Im Nachgang der #dhmasterclass fragte ich mich, ob eine Tabelle die inhaltlich angemessene Form der Datenrepräsentation ist (Spoiler: jein). Tabellen sind praktisch und gefürchtet, unterschätzt und überbewertet zugleich. Warum? Eine Tabelle kann als Grundstruktur zunächst ganz hilfreich sein: Eine Einheit pro Zeile, im Adressbuch also ein im Layout abgrenzbarer Eintrag. Pro Zeile dann mehrere Eigenschaften. Im Adressbuch ganz klar: Name, Anschrift, Beruf. Die Eigenschaften sind in jeder Zeile einheitlich. In dieser streng schematischen Segmentierung von Sinneinheiten besteht die erste Annäherung des Forschers an die Daten. Mit hoher Wahrscheinlichkeit trifft man früher oder später auf einen Eintrag, an dem das Tabellenprinzip an seine Grenzen kommt. Die Klassifikation der Namen und die Differenzierung der Namensteile wird beispielsweise in den folgenden Fällen schon grenzwertig:

In Zeile (1) ist unklar, ob “von” ein Teil des Nachnamens und “Gräfin” nicht eher als Titel klassifiziert werden sollte. In Zeile (2) ist zu fragen, ob “Fr[äu]l[ein].” nicht eher eine Statusangabe als ein Namenszusatz ist (auch wenn es natürlich so gebraucht wurde). In Zeile (3) scheint es weniger um Personen, sondern mehr um Firmen zu gehen, und in Zeile (4) liegen gleich zwei Namen (möglicherweise auch ein Gewerbename) mit einer Herkunftsangabe vor. Diese Haarspalterei ist relevant, wenn man mit den Daten differenzierte Forschung betreiben möchte: So wäre es viel leichter, die Gesamtanteile von Adelspersonen oder Firmen zu errechnen, wenn man eine eigene Kategorie “Adelstitel” oder “Firmenname” festlegen könnte, oder die Eigenschaften je nach Eintragstyp differenzieren könnte (Person: Vorname, Nachname, Titel, zusätzliche Angaben / Firma: Name, Rechtsform etc.). Bleibt man bei dem Tabellenmodell, würde dies bald in eine unüberschaubare Menge von Spalten ausarten. Weitere Besonderheiten (hier nicht am Beispiel erklärt) sind Einträge, die zwei Anschriften, z. B. Wohn- und Geschäftsort enthalten. Berufsbezeichnungen enthalten in einigen Fällen eine Beschreibung von Patenten. Schwierig erscheint außerdem die Handhabung von Normalisierungen, beispielsweise der Abkürzungen “Frl.” und “Fräul.” zu “Fräulein” durch den Bearbeiter. Zusätze in eckigen Klammern kontaminieren den maschinenlesbaren Text, da diese nicht auf der Kodierungsebene angelegt sind; andererseits ist die Dokumentation von Normalisierungen wissenschaftlich notwendig.

Es lag nahe, die Tabelle nach TEI zu konvertieren. Informationen, die von dem strengen tabellarischen Schema abweichen, können mit TEI differenziert und sinntragend beschrieben werden, und Abkürzungen in Original- und Normalform dokumentiert werden. Die Rückführung in eine tabellarische Präsentation bleibt leicht zu bewerkstelligen. Ein “TEIsierter” Eintrag könnte dann etwa so aussehen:

<person xml:id=“row_1718”>
<persName>
<forename>Lina</forename> <surname>Weigel</surname> <addName>Frl.</addName>
</persName>
<sex>weiblich</sex>
<occupation ana=“#trade”>Modehändlerin</occupation>
<residence>
<address>
<street corresp=“#rue-des-petits-champs”>
<num>56</num>
<name><supplied>rue</supplied> Neuve-des-Petits-Champs</name>
</street>
<district corresp=“#arrondissement_2”>2</district>
</address>
</residence>
</person>

Ein Firmeneintrag könnte indessen so ausschauen:

<org xml:id=“row_1930”>
<orgName><surname>Köchlin</surname> <addName>Gebrüder</addName></orgName>
<desc>
<origPlace>aus <placeName>Mühlhausen</placeName></origPlace>
<affiliation ana=“#trade”>Gedruckte Stoffe</affiliation>
<address>
<street corresp=“#rue-du-sentier”>
<num>33</num>
<name><supplied>rue du</supplied> Sentier</name>
</street>
<district corresp=“#arrondissement_2”>3</district>
</address>
</desc>
</org>

Der Nutzer kann die XML-Elemente wie Annotationen des Textes lesen und sie gleichzeitig als technische Struktur nutzen. Die hierarchischen Strukturen sind ihrem jeweiligen Inhalt sehr stark angepasst und deshalb sehr unterschiedlich. Bei der Verarbeitung sind dann entsprechend flexible XPath-Angaben anzuwenden, um beispielsweise Adressangaben unabhängig vom Datentyp herausziehen zu können (etwa org//address|person//address).

Die Datenqualität kann noch weiter gesteigert werden, indem beispielsweise Normdaten zu Personennamen oder auch Standardbezeichnungen bei Berufsangaben hinterlegt werden. Als kleines Experiment nutzte ich einen (inzwischen etwas älteren) Webservice, der Normdaten-Vorschläge anhand basaler Angaben macht (z.B. Name, Zeit, Wirkungsort). Dies war für den Großteil der Daten leider wenig erfolgreich, da die meisten Personen wegen ihrer geringen Bekanntheit noch nie in einem Normdatensystem erfasst wurden (und es bleibt in vielen Fällen fraglich, dass dies jemals geschehen wird). Interessante Vorschläge generierte das System hingegen bei Adeligen sowie bei bekannten Künstlern und Politikern, also Personen des öffentlichen Lebens.

Aus einer Tabelle ein TEI-Dokument zu machen ist übrigens schwieriger als gedacht. Mit einer “character (sic) separated list” gibt es schnell Probleme, wenn man Kommas oder Anführungszeichen innerhalb einzelner Zellen verwendet hat, denn Escape-Zeichen oder Entities arbeiten leider nicht immer sofort so, wie man es wünscht. Konvertierungsroutinen überspringen außerdem gerne leere Tabellenzeilen aus Speicherplatzgründen und drücken dies beispielsweise als @number-repeated-cells="2" aus. Wenn man dies nicht berücksichtigt, läuft die Umbenennung der Spalten erstmal schief.

Insgesamt stellte sich die Beschäftigung mit dem vorliegenden Adressbuch bereits als komplexe Aufgabe heraus, die zahlreiche Herausforderungen auf inhaltlicher, struktureller und technischer Ebene bereithält. Die Arbeit daran ist noch nicht abgeschlossen. Und dies ist nur eines von vielen historischen Adressbüchern, die mit ihren geballten Mengen an Informationen in TEI-kodierter Form eine immens wertvolle Quelle für die digitale Geschichtsforschung darstellen, und die weitere Synergien im Verbund oder auch in Kombination mit anderen Ressourcen (Fremdenlisten, Gerichtsprotokolle etc.) entfalten dürften.