Dokumentation

Grundlegendes

Die Dokumentation des erarbeiteten Modells untergliedert sich in zwei Teile. Einerseits wird das Framework vorgestellt, das erarbeitet wurde, um die Daten aus der Edition zu speichern. Andererseits erfolgt eine Dokumentation der erarbeiteten Ontologie. Diese Übersicht soll ein tieferes Verständnis des erarbeiteten Modells ermöglichen. Anders als beispielsweise bei der MEDEA-Ontologie geht es bei dem hier vorgestellten Modell weniger um das Darstellen von wirtschaftlichen Aspekten (wobei hier natürlich Überschneidungen bestehen), sondern vielmehr um die semantischen Bezüge zwischen den Registerbegriffen und den dahinterstehenden Phänomenen in der Quelle an sich.

Das Framework

Datenmodell

Für das Framework zum Speichern der Daten aus der Edition der Augsburger Baumeisterbücher wurde ein Datenmodell erstellt, dass als eine Art Framework für die Ontologie dienen sollte. Es ermöglicht, die Index-Informationen möglichst stark mit dem Quellenmaterial zu verzahnen, indem es das Konzept des graphbasierten Edierens aufgreift (Kuczera, Graphentechnologien, S. 188-192). Dabei werden einzelne Wörter als Knoten (Tokens) dargestellt, die über eine NEXT-Kante miteinander verkettet werden. Annotationen können über entsprechende Kanten daran angehängt werden.
Im Fall des Frameworks werden beispielsweise die einzelnen Index-Knoten, die im folgenden als Keyword-Knoten bezeichnet werden, über die Kante “References” mit den entsprechenden Token in Beziehung gestellt. Dadurch lassen sich beispielsweise die Schreibweisen der einzelnen Begriffe in der Quelle nachvollziehen und darstellen.

Daneben existiert eine Belegstrutkur, die es ermöglicht, die untersuchten Einträge in der bestehenden Edition zu verorten. Ein Root-Knoten bietet dabei einen Einstiegspunkt. An ihn sind alle erfassten Bände über eine Child-Beziehung angehängt. Jeder Band verfügt über eine Zahl von Folios, die wiederum mit Knoten verbunden sind, die die einzelnen Einträge repräsentieren. An sie sind die einzelnen Token angehängt. Die Datierung erfolgt bisher lediglich über eine Kette von Jahresknoten, die jeweils mit einer entsprechenden Kante mit den einzelnen Folios in Beziehung stehen. Die eigentlichen Daten werden in den Attributen der Knoten gespeichert. Eine Übersicht findet sich in der untenstehenden Tabelle.

Knoten	Attribute
Root	-
Volume	volume
Folio	id, folio
Year	year
Entry	folio, volume
Token	token
Keyword	keyword, certainty, comment

Möglichkeiten & Probleme

Der derzeitige Stand des Modells ermöglicht auch ohne Einbezug der Ontologie, Aussagen über das erschlossene Material zu treffen. Neo4j ermöglicht die Visualisierung der Daten im Neo4j-Browser. Beispielsweise lassen sich so die Zahlen der Einträge pro Band darstellen und zueinander ins Verhältnis setzen. Demonstriert werden soll dies anhand der Folios des Bandes, die auf das Jahr 1400 datieren. Der Ausschnitt des Graphen lässt sich durch die folgende Cypher-Abfrage visualisieren.

MATCH (y:Year)-[]-(f:Folio)-[]-(e:Entry)
WHERE y.year = 1400
RETURN y,f,e

Bei dem blauen Knoten im Zentrum handelt es sich dabei um den Jahres-Knoten für das Jahr 1400. Die einzelnen Folios (in hellgrün) sind über eine Kante mit dem Jahres-Knoten verbunden. Die für die Betrachtung interessanten Knoten bilden die roten Eintags-Knoten. Ihre Anzahl entspricht der Summe der verzeichneten Einträge in diesem Band.

Da alle verzeichneten Einträge im Kontext des Versorgungswesens der Findel- und Waisenkinder stehen, bildet die Summe der Eintrags-Knoten gleichzeitig die Zahl der im Rahmen der Baumeisterbücher dokumentierten erbrachten Leistungen an die Kinder. Daraus können Rückschlüsse auf die Relevanz des Themas im jeweiligen Band oder auf die Versorgung der Findel- und Waisenkinder an sich geschlossen werden. Am obigen Beispiel sehen wir, dass für das Jahr 1400 nur 11 Einträge verzeichnet sind, die das Versorgungswesen der Findel- und Waisenkinder betreffen.

Obwohl das erarbeitete Framework bereits Ansätze für die Erschließung des Materials liefert, muss erwähnt werden, dass die derzeitige Datengrundlage die 130 untersuchten Einträge aus ihren jeweiligen Kontexten löst. Dadurch können unter Umständen Informationen fehlen, die für eine Deutung der Quelle wichtig wären. Auch können die wie oben generierten Zahlen nicht im Verhältnis zu allen Folios oder Einträgen betrachtet werden. Die Datierung der Einträge bzw. Folios erfolgt bisher lediglich über die Jahreszahlen. Eine feinere Datierung über die aufgeschlüsselten Fesstage konnte nicht vorgenommen werden. Für weitere Untersuchungen in diesem Feld wäre also eine Ausweitung der untersuchten Einträge und eine damit einhergehende Erweiterung des Modells sinnvoll.

Die Ontologie

Das komplexe Gefüge der semantischen Beziehungen wird bei der Betrachtung der erstellten Ontologie deutlich. Sie dient in erster Linie als Erschließungswerkzeug. Eine Klassenhierarchie dient zur Annotierung und Einordnung der Knoten in abstrakte Kategorien. Die semantischen Beziehungen beschreiben das Verhältnis zweier Knoten zueinander. Bei allen Knoten handelt es sich um Keyword-Knoten, die durch verschiedene Klassen weiter ausdifferenziert wurden.

Klassenhierarchie

Für eine grobe Kategorisierung wurden sieben Klassen geschaffen, denen die Keyword-Knoten zugewiesen wurden. Die Kategorisierung ergab sich dabei aus den Inhalten und der Deutung der Quelle. In Neo4j erfolgt diese Zuweisung in Form von sogenannten Labels. Problematisch ist, dass es sich bei einem Label in Neo4j lediglich um Tags handelt, die eine Gruppe von Knoten als solche ansprechbar machen. Dabei wird dem Nutzer auch ein gewisser Bedeutungsgehalt mitgeliefert, jedoch ist eine Strukturierung auf diese Weise hierarchielos. Eine Hierarchie müsste über einen Subgraphen erzeugt werden, der die Hierarchie in einer Art Baumstruktur darstellt. Das derzeitige Modell beinhaltet keinen Subgraphen, sodass die Einteilung in Klassen hierarchielos ist. Eine Auflistung der Klassen findet sich in der untenstehenden Tabelle.

Klasse	Beschreibung
Item	Fasst alle materiellen Gegenstände
Service	Fasst alle Dienstleistungen
Person	Fasst alle explizit und implizit genannten Personen
Group	Fasst alle Gruppen von Personen
Entity	Fasst alle Körperschaften
Role	Fasst alle Aufgaben, die von einer Person ausgeführt werden
Payment	Fasst alle Zahlungen (nicht Transaktionen)

Um die geschaffenen Katergorien weiter auszudifferenzieren, wurden für manche der Klassen Subklassen definiert. Es ist der Menge der untersuchten Einträge geschuldet, dass manche Klassen nicht weiter ausdifferenziert werden konnten.

Klasse	Subklasse(n)
Item	Food (Nahrungsmittel), Clothing (Kleidung), Fuel (Brennstoffe), Material (Rohmaterial, Rohprodukt), Other (nicht Kategorisiert)
Service	Social (Sozialwesen)
Person	Anonymous (nicht namentlich auftretende Personen)
Role	Task (nicht näher definierte Aufgabe), Trade (Handwerk), Profession (Beruf)

Auf Grund seiner Flexibilität kann eine Kategorisierung in Neo4j beliebig stark ausdifferenziert werden. Bei der hier vorgestellten Kategorisierung handelt es sich um einen ersten Vorschlag, der beliebig und ohne großen Aufwand erweitert werden kann. Für zukünftige Arbeiten in diesem Feld wäre es denkbar, die Klassen bzw. Kategorien stärker an bestehenden Forschungsdiskursen zu orientieren, sodass bestehende Termini (und unter Umständen auch verschiedene Forschungsmeinungen) in das Modell einfließen können.

Semantische Beziehungen

Die semantischen Bezüge bilden den zentralen Bestandteil der Ontologie. Sie wurden anhand der erarbeiteten Klassen und der hermeneutischen Untersuchung des Quellenmaterials herausgearbeitet. Die semantischen Bezüge wurden dann in Form von Kanten im Graph umgesetzt. Wie bei den Klassen beschreibt ein Label die Art der Beziehung.

Beziehung	Ausgangsknoten	Gerichtet auf	Definition
PROVIDE_PAYMENT_FOR	Entity	Person oder Group	Transaktion aus einem bestimmten Anlass
ACT_AS	Person	Role	Person agiert in bestimmter Funktion
RECEIVE_PAYMENT	Role	Payment	Funktionsträger tritt als Empfänger dieser Zahlung auf
PRODUCE_ITEM	Role	Item	Funktionsträger tritt als Hersteller dieses Gegenstandes auf
PROVIDE_SERVICE	Role oder Person	Service	Funktionsträger tritt als Anbieter der Dienstleistung auf
RECEIVE_SERVICE	Person oder Group	Service	Person oder Gruppe tritt als Empfänger der Dienstleistung auf
RECEIVE_ITEM	Person oder Group	Item	Person oder Gruppe tritt als Empfänger dieses Gegenstandes auf
MEMBER_OF_GROUP	Person	Group	Person tritt als Mitglied einer Gruppe auf
SAME_AS_PERSON	Person	Person	Person wird unter anderer Bezeichnung genannt

Die definierten Beziehungen zielen nicht darauf ab, jeden einzelnen Eintrag im Graphen abzubilden. Vielmehr geht es darum abzubilden, welche Beziehung(en) zwischen zwei Knoten auftreten können. Jede Kante verfügt im Graph über Attribute um Kommentare (comment) zu vermerken und Unsicherheiten (certainty) auszudrücken. Wie auch der Bestand der Klassen kann das Modell um weitere Kanten erweitert werden.

Schlussbemerkungen

Bei der Konzipierung und Modellierung war die Nutzung von Neo4j durchaus von Vorteil. Auch in fortgeschrittenen Stadien des Workflows konnten ohne große Probleme Änderungen am Modell vorgenommen werden, ohne die gesamte Struktur des Graphen verändern zu müssen. Auch kann die Ontologie bei einer Ausweitung der Untersuchungsmenge um neue Kanten und Kategorien erweitert werden. Trotzdem kann die fehlende Hierarchie als Problem gesehen werden, da eine Klassenhierarchie einen wesentlichen Bestandteil einer Ontologie bildet. Hinzu kommt, dass durch die Etabliertheit von RDF mehr Tools und Technologien vorhanden sind, um eine Ontologie damit zu realisiseren. Im Endeffekt muss bei jedem Anwendungsfall entschieden werden, welche Technologie man verwendet, da jede Domäne ihre eigenen Vorrausetzungen mit sich bringt.

Unter dem Menüpunkt Use Cases werden einige Beispielanalysen und Möglichkeiten der Anwendung der Ontologie vorgestellt.

Verweise

Andreas Kuczera: Graphentechnologien in den Digitalen Geisteswissenschaften. In: ABI Technik 37/3 (2017), S. 179-196. URL: https://www.degruyter.com/downloadpdf/j/abitech.2017.37.issue-3/abitech-2017-0042/abitech-2017-0042.pdf (Zuletzt aufgerufen am 11.01.2019).