Editionen von Rechnungsbüchern publizieren – DEPCHA und die Bookkeeping Ontology

Rechnungsbücher scheinen auf den ersten Blick zu einem eher öderen Typus von historischen Quellen zu gehören, allerdings lassen sich mit ihnen viele sozial-, wirtschafts- und alltagshistorische Fragestellungen beantworten. DEPCHA (Digital Edition Publishing Cooperative for Historical Accounts) hat zum Ziel, eine Plattform zu bieten auf der Editionen solcher Rechnungsbücher standardisiert veröffentlicht werden können. Es ist ein Projekt verschiedener Universitäten, in dem auch  Christopher Pollin  vom Zentrum für Informationsmodellierung (ZIM) Graz mitarbeitet, der am 22.4.2021 im Rahmen des Kolloquiums Digital Humanities – Aktuelle Forschungsprojekte zu Gast war. In seinem auch auf Youtube verfügbaren Vortrag ging es vor allem um die Erstellung und den Aufbau der Bookkeeping Ontology, die die Basis für die entstehende Publikationsplattform bildet, aber auch um den Workflow der Datenübernahme aus bestehenden Editionen und die Visualisierung dieser Daten.

Was ist überhaupt eine Ontologie?

Modellierung  ist nach Christopher Pollin ein Kernelement der Digital Humanities. Er versteht darunter den Vorgang der Spezifizierung und Beschreibung einer Domäne, so dass auch andere sie verstehen können. Die theoretischen Digital Humanities widmen sich hierbei der Erforschung der Methoden für die Erstellung von formalen Modellen, während die angewandten Digital Humanities diese anwenden. Christina Feilmayr und Wolfram Wöß führten in ihrem Aufsatz An analysis of ontologies and their success factors for application to business die Definition einer Ontologie wie folgt auf: „An ontology is a formal, explicit specification of a shared conceptualization that is characterized by high semantic expressiveness required for increased complexity.“. In seinem Vortrag schlüsselte Christopher Pollin diese Definition auf: 

Eine Ontologie ist formal, da sie maschinenlesbar bzw. in Algorithmen abbildbar ist. Sie ist explicit, weil alles definiert wird und dabei nichts ausgelassen wird (im Falle der Rechnungsbücher z.B. Was definiert eine Transaktion?). Eine Ontologie ist eine specification of a shared conceptualization, also eine Community-basierte Abstraktion einer Domäne. Die high semantic expressiveness, die ausgedrückt werden soll, ist nötig für die increased complexity. Letzere ist laut Christopher Pollin eines der Entscheidungsmerkmale, ob eine Domäne gut durch eine Ontologie beschrieben werden kann. Wenn diese nicht gegeben ist, ist eventuell keine Ontologie nötig. Ontologien sind zudem nie abgeschlossen und vielmehr als Momentaufnahmen eines laufenden Prozesses zu sehen.


Abbildung 1: Vorteile einer Ontologie. Quelle

Doch wieso benötigt man eine Ontologie? Christopher Pollin hat in seinem Vortrag immer wieder betont, wie wichtig die Rolle einer Ontologie für den Austausch von Informationen und für die Kommunikation mit anderen Forschenden ist. Durch den Bezug auf eine gemeinsame Ontologie kann unter anderem sichergestellt werden, dass Konzepte oder Begriffe exakt gleich identifiziert werden, es also eine Standardisierung gibt. Außerdem können aus Ontologien, in denen logische Schlussfolgerungen implementiert werden (wie z.B. die Klassifikation einer Transaktion zwischen Person und Staat als „Steuer“), neue Erkenntnisse gewonnen werden. Auch trägt die Formalisierung einer Domäne insgesamt einfach zu einem besseren Verständnis dieser bei. 

Christopher Pollin hat in seinem Vortrag eine einfache Methode der Ontologieerstellung bzw. des ontology engineering nach Natalya F. Noy und Deborah L. McGuinness vorgestellt, die aus folgenden Arbeitsschritten besteht.

  1. determine scope: Was wollen wir ausdrücken und für wen?
  2. consider reuse: Gibt es sowas schon, bzw. existieren Teilaspekte? Wenn ja, dann wiederverwenden
  3. enumerate terms: Was befindet sich in der Domäne?
  4. define classes: Was verstehe ich unter den Klassen?
  5. define properties: Was verstehe ich unter deren Attributen?
  6. define constraints: Was sind logische Zusammenhänge?
  7. create instances: Erstellen von Instanzen (z.B. in RDF)

Dieser Prozess gilt aber nicht als abgeschlossen, sobald er einmal durchlaufen ist, da man Ontologien als „Momentaufnahmen eines iterativen Prozesses“ verstehen kann. 

Rechnungsbücher – sind das nicht nur Zahlen?

Die Verschriftlichung von Ein- und Ausgaben und Schulden ist ein essentieller Bestandteil der Menschheitsgeschichte und ist auch noch heute im Alltag sehr präsent. Schon für 3000 v. Chr. (siehe Abbildung 3) liegen Wissenschaftler:innen Dokumentationen von Schulden auf Tontafeln vor, für alle Epochen folgte die Dokumentation von Ein – und Ausgaben einem ähnlichen Schema, z.B. auch in der in der Abbildung 2 abgebildeten Jahresrechnung der Stadt Basel aus dem 16. Jahrhundert.

Abbildung 2: Jahresrechnung Stadt Basel, 1540/1541. Quelle: Präsentation von Christopher Pollin

Für die historische Forschung ist die Arbeit mit diesem Quellentyp aus verschiedenen Gründen interessant. Aus wirtschaftshistorischer Sicht können gerade die breitflächige Erhebung, Annotation und Verfügbarmachung von Rechnungsunterlagen zur Erstellung neuer Datensätze über die Entwicklung von Preisen, Löhnen und Produktion führen. Sozialhistoriker:innen können aus Rechnungsbüchern Beziehungen und Abhängigkeiten zwischen Menschen ablesen oder die Ein- und Ausgaben von Institutionen wie Klöstern oder Hospitälern erforschen. Diese und andere historische Disziplinen könnten mit DEPCHA eine gute Datengrundlage für ihre Forschung erhalten. Gerade,  da der Wert von Rechnungsbüchern für die historische Forschung vor allem im Zusammenhang mit anderen Rechnungsbüchern groß ist, bietet sich eine Ontologie als gemeinsame Grundlage für die Publikation von Rechnungsbuch-Editionen an.

Abbildung 3: Tontafel, ~3000 v. Chr., Uruk (Mesopotamian). Quelle: Präsentation von Christopher Pollin

Christopher Pollin führte besonders das Beispiel der „Stagville-Accounts“ aus. Das transkribierte Beispiel in Abbildung 4 ist aus dem Jahr 1808 und ist ein Ausschnitt aus den Rechnungsbüchern der Familie Cameron, die in Stagville, North Carolina eine Tabakplantage betrieben. Die Transkription ist von https://fromthepage.com/, einer community-basierten Transkriptionswebseite, aus der auch Daten für DEPCHA übernommen werden können.

Abbildung 4: Scan und Transkription eines Ausschnitts der Stagville-Accounts. Quelle: Präsentation von Christopher Pollin

Wie sieht die Bookkeeping Ontology nun aus?

Eine Ontologie für die Domäne der Rechnungsbücher ist dann also „Ein Modell zur formalen Beschreibung von Transaktionen in historischen Rechnungsunterlagen“ (Prof. Georg Vogeler), die mit dem DEPCHA-Projekt umgesetzt werden soll. 

Die verschiedenen Varianten der Domäne der Rechnungen (z.B. hinsichtlich des Types, der Regionen und Kontexte) lassen sich  alle auf die Struktur der „Transaktion“ zurückführen. Diese bezeichnet nach Christopher Pollin die „Übertragung von Wirtschaftsobjekten zwischen Wirtschaftssubjekten“. Die Grundstruktur einer Transaktion in der Bookkeeping Ontology ist in Abbildung 5 zu sehen. Anhand des Beispiels der Stagville Accounts können hier die Beziehungen der einzelnen Klassen und Properties gut abgelesen werden. Einige Properties werden semantisch durch Bezüge auf WikiData angereichert. So kann besser mit historischen Währungen und Maßeinheiten umgegangen werden, die sich regional häufig unterscheiden. Auch können durch andere in WikiData aufgeführte Referenzierungen (z.B. des Konzeptes „Zucker“) leichter Zusammenhänge zu anderen Daten erstellt werden.

Abbildung 5: Die Grundstruktur einer Transaktion in der bookkeeping-ontology. Quelle: Präsentation von Christopher Pollin

Die Bookkeeping-Ontology ist eine domain-ontology, die eine Domäne beschreibt. Eine top-level-ontology wäre hingegen CIDOC CRM, welche für die Beschreibung von Kulturerbedaten entwickelt wurde, und auch bei DEPCHA genutzt wird. Zum Beispiel übernimmt die Klasse der Transaktion Eigenschaften der CIDOC CRM-Klasse „E7 activity“, die Ereignisse beschreibt. Somit hat die Transaktion die gleiche semantische Metaklasse wie andere Kulturerbedaten.

Wie kommen die Daten in DEPCHA?

Die Daten liegen in DEPCHA in RDF (Resource Description Framework) vor (siehe Abbildung 6). Der Vorteil von RDF gegenüber einer relationalen Datenbank ist, dass das Modell einfacher im Schema erweitert werden kann, was, wie schon erläutert, für eine Ontologie von essentieller Bedeutung ist. Es gibt zwei Pipelines, über die Daten in dieses Zielformat überführt werden. Zunächst kann für Daten von FromThePage oder aus Drupal der Weg über digitale Editionen und das Format TEI gegangen werden. Hier wird die Zugehörigkeit zu Klassen oder Properties in DEPCHA mit dem Attribut ana=”bk:entry” in der TEI-Datei markiert und diese anschließend in das RDF-Format konvertiert. 

Ein anderer Weg ist der über csv-Dateien, die häufig von Historiker:innen im Rahmen ihrer Forschung produziert werden. Diese Daten werden dann direkt auf die RDF-Klassen und -Properties gemappt.

Abbildung 6: Die Grundstruktur einer Transaktion in der bookkeeping-ontology. Quelle: Präsentation von Christopher Pollin

Was für Funktionen soll die Publikationsplattform haben?

Die Publikationsplattform für digitale Editionen von historischen Rechnungsbüchern, die das Ziel von DEPCHA ist, basiert auf dieser Bookkeeping-Ontology. Sie soll verschiedene Suchfunktionen (z.B. eine Volltextsuche oder die Suche über Indizes) beinhalten und die Möglichkeit zum Export von Daten geben. Die Funktion zur Visualisierung der Daten soll nächstes Jahr implementiert werden. In Abbildung 7 sieht man eine der verschiedenen Möglichkeiten, wie diese Visualisierung aussehen könnte, die Christopher Pollin in seinem Vortrag vorgestellt hat. Diese legt hier den Schwerpunkt auf die statistische Verteilung der Ausgaben unter hierarchischen Aspekten. Aber auch „klassische“ Visualisierungsstrategien anhand von Säulendiagrammen wären möglich. Christopher Pollin untermalte die Vorstellung der möglichen Visualisierungen zusätzlich mit dem Referenzmodell der Informationsvisualisierung nach Card et al.

Abbildung 7: Idee einer Visualisierung der Daten in DEPCHA. Quelle: Präsentation von Christopher Pollin

Fazit

Der Vortrag hat gut demonstriert, wie viele Gedanken sich um die Modellierung einer Domäne durch eine Ontologie gemacht werden müssen. Gerade für den Bereich der Rechnungsbücher ist durch DEPCHA vermutlich eine grundlegende Veränderung für die Forschung mit diesen zu erwarten, da diese, wie Christopher Pollin es ausgeführt hat, sehr von einer Aggregation mit anderen Rechnungsbüchern profitieren. Auch die in seinem Vortrag aufgeführten Möglichkeiten zur Visualisierung der Daten lassen gespannt auf den Launch der fertigen Webseite warten. Wer sich das Projekt bis dahin schon einmal anschauen möchte: Momentan existiert bereits ein Prototyp der Plattform, auch ist das Projekt auf Github zu finden. 

Zum Vortragenden: Christopher Pollin  ist wissenschaftlicher Mitarbeiter und Doktorand am Institut für Informationsmodellierung  in Graz. Er hat einen Master in Geschichte und einen Joint Master’s Degree in Digital Cultural Heritage Studies (EuroMACHS), in dessen Kontext er auch ein Auslandssemester in Köln absolviert hat. Die Schwerpunkte seiner Arbeit liegen in den Bereichen Semantic Web Technologien, Linked Data, Datenmodellierung, Webentwicklung und digitale Edition.

Zur Autorin: Sara Saleh studiert nach ihrem Bachelorabschluss in Geschichte und Informationsverarbeitung nun Informationsverarbeitung im Master. Sie arbeitet momentan am Data Center for the Humanities der Universität zu Köln.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.