Die Matrikel der Universität Halle (1690-1730) in FactGrid

Fritz Junkte (1886-1984) , Bibliothekar und Historiker in Halle, war der erste, der sich die Herausgabe einer Matrikeledition der Universität Halle vornahm. Er bearbeitete in den 1950ern die Matrikel der Universität von ihrer Gründung bis 1730, so dass 1960 der erste Matrikelband erscheinen konnte. Dieser Band enthält jedoch nicht nur die Informationen aus den Matrikelbänden des Universitätsarchivs, Juntke machte es sich zur Aufgabe darüber hinaus noch weitere Quellen heranzuziehen, um seinen Datenbestand anzureichern.

Dabei lassen sich drei größere Quellenkomplexe ausmachen: die Auswertung zeitgenössisch aktueller Forschungsliteratur, wie etwa Eduard Winters “Halle als Ausgangspunkt der deutschen Russlandkunde im 18. Jh. (Berlin, 1953)“; die Auswertung und der Verweis auf Quellen im Archiv der Franckeschen Stiftungen, so etwa Informatorenverzeichnisse oder Freitischlerlisten; sowie weitere Quellen aus dem Universitätsarchiv, die über die Matrikelbände hinausgehen. Hier wäre später eine Rückvernetzung auf die Originalquellen sinnvoll und wünschenswert.

Diese Informationen wurden nun in den letzten zwei Jahren erstmals systematisch erfasst und in einen Datensatz von mehr als 20.000 Studenten in FactGrid überführt:

Liste aller erfassten Studenten mit Seitenangabe bei Juntke

Das Gesamtziel dieses Projektes ist dabei, ähnlich dem Vorgehen Juntkes, die großen Datenbestände zur Halleschen Bildungsgeschichte im 18. Jahrhundert auf einer Plattform zusammenzuführen, nutzbar und auswertbar zu machen. So erfolgt beispielsweise schrittweise auch eine Zusammenführung der Datenbestände mit den Informationen aus dem Bio-Bibliographischen Register des Archivs der Franckeschen Stiftungen oder der Datenbank des Projekts “Franckes Schulen” in dem vor über 20 Jahren Schüler-, Informatoren- und Waisenmatrikel erfasst wurden.

Darüber hinaus soll dieser Datensatz auch in einem größeren Kontext dazu anzustoßen in weiteren Projekten den Bestand an Informationen zu erweitern und zu vernetzen durch Matrikel anderer Schulen und Universitäten, und FactGrid so zu einer zentralen Plattform zu machen, auf der die Daten aus allen verfügbaren Matrikeln zusammengeführt und vernetzt werden können.

Aus den bereits erfassten Daten aus Juntkes Matrikelband sowie anderen Projekten und Quellen ergeben sich dabei bereits erste interessante Befunde und Möglichkeiten, diese Daten auszuwerten:

Abb.1: Indentifizierte Geburtsorte der Studenten.

Abb. 2: Statistische Übersicht der Immatrikulationszahlen pro Jahr.

Abb. 3: Entwicklung der Studienfachverteilung pro Jahrzehnt.

Abb. 4: Altersverteilung bei Einschreibung an die Universität (soweit Geburtsdaten bekannt).

Eine weitere Quelle, die im Kontext der Matrikel im Zuge des Projektes erschlossen wurde, findet sich in der 1709 veröffentlichten “Kurze Nachricht von der Stadt Halle und absonderlich von der Universität daselbst” von Caspar Gottschling (1679-1739). Am Ende dieser Veröffentlichung, die sich im wesentlichen der Geschichte der Universität widmet, findet sich eine Liste, die alle bis 1709 verliehenen Studienabschlüsse auflistet. Diese wurden mit Angaben zu Art des Abschlusses (Promotion, Magister, Licentiat, Verleihung anderer akademischer Ehren), Datum, Fach und betreuendem Professor mit den Daten der Matrikel in FactGrid zusammengeführt, sodass sich für diese ersten ca. 20 Jahre auch ein intellektuelles Netzwerk von Professoren und deren Schülern rekonstruieren lässt (Siehe Abb. 5).

Abb. 5: Netzwerk von Betreuungsverhältnissen bei Studienabschlüssen (1694-1709).

Weitere Informationen: FactGrid:Die Matrikel der Universität Halle

Kontakt: David Löblich

2024-12-20

Beam-me-up: A Tool for Importing Wikidata Entities to FactGrid

The WikibaseMigrator, also known as the Beam-me-up tool, automates the complex process of transferring data from Wikidata to FactGrid. Traditional methods such as manual creation or imports through QuickStatements and OpenRefine often prove to be time-consuming and error-prone. This new tool simplifies the entire process by automatically mapping properties and items between the two Wikibase instances, having already performed over 18,000 successful edits.

How to Migrate Entities

Starting the migration requires to select the entities to migrate. Here the input of the single ID or a list of ID is possible

The migration process requires only Wikidata IDs as input and offers three flexible input methods: you can enter a single ID, provide a comma-separated list of IDs (make sure you do not end with a comma), or use a SPARQL query. After entering the IDs in the input field, a preview table displays the selected entities with their English labels, allowing you to verify your selection before proceeding.

When you click “Run matching!”, the tool queries the selected entities’ data from Wikidata and begins the translation process. It extracts all properties and items from the dataset and searches for corresponding mappings in FactGrid. Using these mappings, the tool translates the entities to FactGrid entities. If an entity already exists in FactGrid, the tool will augment it with the new statements from Wikidata. This process may take several seconds, depending on the number of entities selected and the complexity of their statements.

Here the translation can be checked before starting the migration. Additionally a summary or the project ID can be provided.

Once the translation is complete, you will see the results for each entity, indicating whether the process will create a new entry or augment existing ones. At this stage, you can add a research project ID (P131) if the entities belong to your research project, which adds a corresponding statement to each migrated entity. As with any wiki edit, you can provide a summary explaining the reason for the migration—this is particularly recommended for large imports.

Queried mappings that are used for the translation

Overview table of the missing items and properties that are missing for a complete migration

Selecting entities is also possible with a SPARQL query. The query is executed against the source Wikibase instance, thus Wikidata.

The query result is shown for visual validation. The entities are only selected from the variable ?item.

The Migration Process

After reviewing the translation and clicking Beam me up!, the actual migration begins. A progress bar keeps you informed of the process. Upon completion, you receive a comprehensive overview table of the created or augmented entities, which you can download for your records or further additions of new statements you want to make. This table includes both the Wikidata and FactGrid IDs, along with detailed migration information.

The tool handles property type mismatches between Wikidata and FactGrid through automatic type casting where possible. For instance, it can convert string values to quantities and manage monolingual text to string conversions and vice versa. Any such transformations are documented in the migration details column of the results table.

The migration result is shown as table with the IDs of Wikidata and FactGrid.

If a migration fails, the tool provides a separate table showing the affected Wikidata ID and the reason for the failure. During testing, most failures were related to existing sitelinks, as Wikidata supports defining sitelinks to redirects, which FactGrid does not.

Entity Augmentation and Advanced Features

The tool employs a sophisticated approach to augmenting existing entities, optimized for multiple augmentation cycles. Statements are considered equal if their main values match and either has no qualifiers or their qualifier sets are identical or one qualifier set is empty. In such cases, the tool merges references and qualifiers intelligently, preventing duplicate statements that might occur with the default merging strategy.

This feature proves particularly valuable when migrating interconnected data, such as family relationships. For example, when migrating a group of related persons with Mother (P142), Father (P141) and Child (P150) relationships, the tool can handle the circular dependencies effectively through multiple migration passes.

For example when migrating the list of Q81642270, Q81642507, Q28085 (assuming that they are not already in FactGrid) the statements with property mother (P25) and father (P22) will not be migrated as the target entities do not exist at the time of translation and thus do not have a FactGrid ID yet. But applying the migration a second time to the same list of entities leads to the augmentation of the now existing FactGrid entities allowing to migrate the statements with the properties mother (P25) and father (P22).

Technical Implementation and Additional Tools

All migrations are performed under the user’s account credentials, with each edit tagged to indicate it was made using the tool.

The Wikidata ID of the original entity is automatically added as a sitelink to newly created entities, ensuring proper linking between the two databases and facilitating future augmentations. It should be noted that the back reference is also configurable and can also be configured as external id with a property which would be a cleaner solution.

To complement the WikibaseMigrator, a Wikidata bot called FactGridSync periodically queries FactGrid’s latest edits and updates the corresponding Wikidata entries with FactGrid IDs. This synchronization covers all FactGrid entities, not just those migrated using the Beam-me-up tool.

Example of the FactGridLinker annotations — FactGridLinker adds the FactGrid ID to each Wikidata entity page or a link to the Beam-me-up tool if the entity does not exist

For those interested in enhanced Wikidata functionality, I implemented the UI extension FactGridLinker, initially for debugging, that simplifies checking whether Wikidata entities exist in FactGrid. This user script can be enabled through your commons.js configuration (see here for details).

The WikibaseMigrator’s versatility extends beyond the Wikidata→FactGrid

relationship—it can be configured to work between any Wikibase instances with proper configuration.

It was successfully used for subsetting the CEUR-WS data into its own wikibase instance with just a few queries that defined entities of the subset and was performed in under two hours.

Should you encounter any issues while using the tool, you can report them on the my talk page or by opening a issue on GitHub.

Image Maniere universelle de M. Desargues, pour pratiquer la perspective par petit-pied… Planche 4 Gallica France

2024-12-10

Job advertisement in new FactGrid project on Polish-Ukrainian history

Dear Colleagues,

As part of our Research Project „Modelling Premodern Ambivalences“ (VAMOD) at the GWZO in Leipzig we are offering a 10month position until end of December 2025. The project is funded by NFDI4Memory and will offer plenty of possibilities to build up expertise and networks within the field of Digital Humanities.

The goal of the project is to transfer research data from my first book into the Wikibase instance FactGrid in accordance with the FAIR principles. The dataset comprises approximately 800 charters with about 1,600 place names and 5,000 personal names for the present-day Polish-Ukrainian border region (“Crown Ruthenia” or “Red Ruthenia”) between 1340 and 1434. During the transfer, innovative approaches to modelling premodern political configurations will be explored, which will be documented through guidelines and best-practice recommendations, thereby making them sustainably available to the historical research community.

If you can, please share widely!

https://www.leibniz-gwzo.de/sites/default/files/dateien/Stellenausschreibung_Wiss.%20MA_DB2_VAMOD_BS_10.01.2025.pdf

Any questions can be directed to me.
Thank you in advance for sharing.
All the best,

Sven (Jaros)

—
Dr. Sven Jaros
sven.jaros@geschichte.uni-halle.de
Martin-Luther Universität Halle/Wittenberg
Institut für Geschichte
Professur für Osteuropäische Geschichte
Emil-Abderhalden-Str. 26/27
Raum 2.06.0
06108 Halle (Saale)

2024-11-17

Jüdisches Leben in Sachsen-Anhalt – ein kollaboratives Forschungsprojekt

Die Erforschung und Erhebung von Mikrodaten zu jüdischen Gemeinden erfolgt oft nicht flächendeckend für größere Räume und oftmals nur punktuell durch lokale Gruppen, Initiativen und einzelne Forscher. Eine Ausnahme bildet hier die Familiendatenbank “Juden im Deutschen Reich” von Ingo Paul, die einen großflächigeren Ansatz verfolgt, aber nur genealogische Forschungsdaten erschließt.

Das hier beschriebene Projekt auf FactGrid zielt hingegen darauf ab, für den Raum des heutigen Sachsen-Anhalts, epochenübergreifend und über reine Personendaten hinausgehend, umfassende Forschungsdaten zu jüdischen Gemeinden zu sammeln; ausgehend von genealogischen Daten bis hin zu Informationen über Gemeindestrukturen, weitere jüdische Organisationen, Gebäude, die Dokumentation von Friedhöfen, die Erschließung von Quellen, bis hin zur Kartierung von Stolpersteinen etc. Langfristig soll FactGrid dabei sowohl als zentrale Sammelplattform für die entsprechenden Forschungsdaten fungieren, als auch Vernetzungsmöglichkeiten für alle Akteure bieten, die zur vielfältigen Landschaft jüdischer Gemeinden in Sachsen-Anhalt forschen.

Abb. 1: Übersichtskarte bisher im Projekt erfasster Jüdischer Gemeinden.

In einer ersten Projektphase wurden dazu aus gängiger Forschungsliteratur und zeitgenössischen Überblickswerken alle Gemeinden auf dem Gebiet des heutigen Sachsen-Anhalt und teilweise darüber hinaus erfasst, in denen jüdisches Leben stattfand oder bis heute stattfindet. Dazu wurden bereits Angaben zur Ausrichtung der Gemeinden und statistische Angaben zu Mitgliederzahlen ergänzt, soweit bereits zugänglich, wie für folgendes Beispiel anhand der Gemeinde in Oschersleben bereits visualisierbar ist:

Abb. 2: Mitgliederzahlen der jüdischen Gemeinde Oschersleben nach Jahren.

Hierauf aufbauend sollen langfristig zu allen jüdischen Gemeinden detaillierte Forschungsdaten erhoben, zusammengeführt und für neue und komplexere Fragestellungen nutzbar gemacht werden. Bisher für verschiedene Orte bereits detailliertere Datensätze erhoben worden, insbesondere Aschersleben, Quedlinburg, Tangermünde oder Göttingen. Erweitert wird dieser Datensatz durch eine geschlossene Übernahme und Verlinkung aller Personeneinträge im Gedenkbuch des Bundesarchivs mit Bezug zum heutigen Sachsen-Anhalt. Diese Forschungsdaten sollen in einem nächsten Schritt mit der kompletten Erschließung der Abstammungsergänzungskarten der Volkszählung 1939 zusammengeführt werden, deren Erhebung zur Zeit läuft.

Lokale Forscher und Initiativen, die zu jüdischen Gemeinden in Sachsen-Anhalt forschen und bereit sind, sich mit anderen Gruppen zu vernetzen und gemeinsam an einem großen Forschungsdatenpool zu arbeiten, sind jederzeit dazu eingeladen und finden weitere Informationen zu bereits vorhandenen Projekten und Kontaktdaten auf folgender Projektseite:

https://database.factgrid.de/wiki/FactGrid:Jüdisches_Sachsen-Anhalt

2024-07-22

Von Sozialisten, Shoah-Überlebenden und dem American Dream. Das Potential von Social Philately für die Geschichtswissenschaft

Social Philately ist eine philatelistische Bewegung, die in den 1980er Jahren in Australien und Neuseeland entstand und Anfang der 2000er Jahre Europa erreichte. Diese Bewegung zielt darauf ab, traditionelle philatelistische Fragestellungen zur Analyse postalischer Belege mit einer breiteren kulturellen und sozialgeschichtlichen Kontextualisierung zu verbinden. Dabei werden nicht nur die reinen Postbelege untersucht, sondern auch die Absender und Empfänger der Briefe, der Text der Briefe oder Postkarten sowie der historische Kontext, in dem diese entstanden sind, berücksichtigt.

Für die Philatelie ist dieser Blick über den eigenen Tellerrand äußerst bereichernd. Aber auch umgekehrt bietet der Blick auf scheinbar einfache und oft irrelevant erscheinende Quellen wie Briefumschläge oder Postkarten ein enormes Potenzial für die Geschichtswissenschaft. Diese Quellen bieten einen leichten Zugang zu einer riesigen und unerschöpflichen Menge an Daten zur Alltagsgeschichte von Menschen aller Gesellschaftsschichten seit der Mitte des 19. Jahrhunderts, die im privaten Raum entstanden sind. Das Potenzial für Fragestellungen in diesem Bereich ist nahezu unbegrenzt. Es bieten sich Ansätze für die post- und kommunikationsgeschichtliche Forschung, Forschung zu Propaganda und Werbung (bspw. zur Verwendung und Verbreitung von Werbeklischees oder Ganzsachen), biographische Fragestellungen oder Hinweise auf persönliche Netzwerke, die sonst über keine andere Quelle greifbar wären, um nur einige Möglichkeiten zu nennen. Dadurch könnten Zugänge und Methoden genutzt werden, wie sie auch für archivisch überlieferte Korpora üblich sind, wie das folgende Beispiel des Korrespondenznetzwerks der Illuminaten in FactGrid zeigt, welches mögliche Potenziale für Analysen eröffnet:

Korrespondenznetzwerk des Illuminatenordens: Wer schreibt wem, von wo nach wo.

Neben der schieren Masse an zugänglichen Quellen besteht das Problem oder Potenzial der fehlenden Systematisierung und Erschließung solcher Quellen. Die Suche nach bestimmten Briefen oder Themen ist nahezu unmöglich, und Wissenschaftler müssen sich auf den Zufall einlassen, da man beispielsweise vor einem Flohmarktbesuch nie wissen kann, welche Art von Material man finden wird. Einzelne, zufällig entdeckte Dokumente mögen ohne Kontext keine große Relevanz besitzen. Wenn man jedoch diese Daten in großer Menge sammelt, kontextualisiert und miteinander verbindet, eröffnen sich spannende Möglichkeiten zur Erforschung der oben genannten Fragestellungen. Plattformen wie FactGrid bieten für ein solches Unterfangen großes Vernetzungspotenzial. Die Offenheit der Datenbank ermöglicht es, einzelne Belege zu dokumentieren, mit vorhandenen Datensätzen zu verbinden und so persönliche Netzwerke, Biographien etc. nach und nach zu rekonstruieren. Auf diese Weise können aus der zufälligen Erwerbung eines alten Briefes oder einer alten Postkarte wissenschaftlich nutzbare Daten gewonnen werden. Dies soll im Folgenden an zwei Beispielen veranschaulicht werden:

Der erste Beleg stammt aus dem Jahr 1950 und wurde per Luftpost von Montevideo nach Deutschland geschickt. Der Absender des Briefes, Ernesto Schoenthal wurde 1907 in Marienhafe im Landkreis Aurich als Ernst Schönthal in eine jüdische Familie geboren. Er hatte zwei Schwestern und war in Deutschland als Kaufmann tätig. Nach der Machtübernahme der Nationalsozialisten 1933 war er das einzige Mitglied seiner Familie, das rechtzeitig das Land verlassen und 1936 nach Montevideo fliehen konnte. Seine Mutter Bertha Schönthal (geb. Steinberg) war bereits 1937 verstorben und sowohl sein Vater als auch beide Schwestern, die 1940 noch zusammen nach Rinteln gezogen waren, wurden im März 1942 ins Warschauer Ghetto deportiert, wo sich ihre Spuren verlieren. Ernst Schoenthal hingegen scheint es gelungen zu sein, in Uruguay erneut ein Handelsgeschäft aufzubauen und ebenso eine Familie zu gründen.

Nach dem Krieg ist er nie wieder dauerhaft nach Deutschland zurückgekehrt (er verstarb 1987 in Montevideo); scheint sich aber dennoch um das Schicksal seiner Familie und deren Wiedergutmachungsansprüche gekümmert zu haben. In diesem Kontext ist oben abgebildeter Brief aller Wahrscheinlichkeit nach auch zu erklären. Adressat des Briefes war der Rechtsanwalt und Notar Gerhard Obuch. Dieser war 1884 als Sohn eines Richters in Lauenburg/Pommern geboren und hatte in Leipzig, Berlin und Königsberg Rechtswissenschaften studiert. Vor 1933 war er als Anwalt in Düsseldorf und Berlin tätig, seit 1906 Mitglied der SPD, seit 1917 der USPD und seit 1922 der KPD. Er war im Vorstand der Roten Hilfe Deutschlands, vertrat bei Gerichtsprozessen Angeklagte aus dem Kontext des Spartakusaufstandes und war bis 1933 Abgeordneter im preußischen Landtag für die KPD. Auch er wurde Opfer des NS-Regimes, wurde 1933 verhaftet und ins KZ Sonnenburg verbracht und arbeitete nach seiner Freilassung zunächst nur noch im Straßenbau und ab 1935 als Buchhalter. Nach 1945 war er nicht mehr politisch tätig und darüber hinaus gibt es keine gesicherten Informationen zu seinem Leben nach 1945 bis auf seinen Tod 1960 in Rauenthal.

Über die Verbindung zwischen Schoenthal und Obuch können hier nur Vermutungen angestellt werden, da der genaue Inhalt des Briefes unbekannt ist. Nahe liegt, das Obuch nach dem Krieg wieder als Anwalt tätig war und sich in der Region in der er lebte (wie der Brief zeigt, muss er 1950 von Norderney nach Norden verzogen sein; die Information hatte Schoenthal nicht und muss nachträglich im Prozess der Zustellung durch einen Postbeamten ergänzt worden sein), für Wiedergutmachungsansprüche von Opfern der NS-Herrschaft einsetzte und so zum Ansprechpartner für Schoenthal wurde, der sich um Rückerstattung von enteignetem Vermögen seiner Schwestern und seines Vaters bemühte. Dadurch bietet dieser philatelistische Beleg einen Nachweis über diese mögliche Verbindung der beiden Personen und einen Ausgangspunkt für weitere mögliche Recherchen, beispielsweise in evtl. noch vorhandenen Wiedergutmachungsakten, um oben beschriebene These möglicherweise erhärten oder widerlegen zu können. Dabei bildet dieser Brief einen interessanten Hinweis auf eine Verbindung zwischen unterschiedliche Opfergruppen des NS in ihrer hier möglicherweise gemeinsamen Bemühung um Wiedergutmachung.

Der zweite Beleg, seine Geschichte könnte nicht unterschiedlicher sein, überquerte etwa 25 Jahre früher im Dezember 1925 den Atlantik von Indianapolis nach Esslingen am Neckar. Die Ganzsache wurde im Dezember 1925 von Chris Bernloehr in Indianapolis als R-Brief (Einschreiben) aufgegeben, durchquerte am 10. Dezember die Registry Division der Post in Indianapolis, erreichte zwei Tage später das Auslandspostamt in New York und ein dritter Stempel auf der Briefrückseite bestätigt eine Zustellung mit der württembergischen Bahnpost bereits am 23. Dezember 1925. Der Brief benötigte demzufolge etwa zwei Wochen von Indianapolis bis nach Esslingen in Württemberg:

Neben diesen direkt ablesbaren Informationen zu Briefart und Reiseweg stellt sich nun die Frage nach dem Kontext und der möglichen Geschichte hinter diesem Brief. Christian Bernloehr wurde am 6. Januar 1866 in Adelmannsfelden in Württemberg als eines mehrerer Kinder eines Tagelöhners geboren. Er besuchte in Deutschland keine Schule und vermutlich der Armut geschuldet wanderte die Familie bereits 1876 nach Amerika aus. Dies vermerkte der zuständige Pfarrer nachträglich selbst in Christian Bernloehrs Taufregistereintrag:

Dort heißt es in der Spalte unter seinem Vornamen: “ist mit seinen Eltern nach Amerika ausgewandert”. Über Bernloehr selbst erfährt man aus Zensus-Unterlagen und einem Reisepassantrag, das er recht schnell die englische Sprache gelernt haben muss, seine Körpergröße wird mit 5 Fuß und 7 Inches angegeben (etwa 1,70m), sowie das er schwarze Haare und braune Augen hatte. Die Volkszählungen ab 1900 belegen, das Bernloehr zeitlebens immer in Indianapolis verblieb und sich über die Jahre nach seinem Schulbesuch vom einfachen Zeitungsjungen zu einem angesehenen Juwelier und Uhrmacher hochgearbeitet hatte. Ihm war es also in Amerika (seit 1901 amerikanischer Staatsbürger) gelungen der Armut seiner Heimat zu entkommen. Über sein Leben in Indianapolis erfährt man darüber hinaus mehr in zahlreichen anekdotischen Beiträgen, die der Journalist Anton Scherrer 1938 in einer Rubrik mit dem Titel “Our Town”, nur ein Jahr bevor Bernloehr im September 1939 starb, in der Indianapolis Times veröffentlichte. Aus dem letzten dieser Artikel, seiner Todesanzeige, ist auch zu erfahren, dass Bernloehr trotz seiner Auswanderung zeitlebens seiner Heimat verbunden geblieben sein muss. So wird beispielsweise von seiner Mitgliedschaft in der Schwaben Society in Indianapolis, einem der seinerzeit weit verbreiteten Heimatvereine in den USA, berichtet. Auch der Brief, der den Ausgangspunkt dieser Betrachtungen darstellt, kann vermutlich in diesem Kontext interpretiert werden: Knapp 50 Jahre nach seiner Auswanderung schreibt er einen Brief an einen Kinderhilfsverein in Esslingen am Neckar in seiner alten Heimat. Dies geschah möglicherweise in Erinnerung an seine eigene Kindheit in Armut und dem Bedürfnis Kinder vor Ort, die sich in ähnlichen Verhältnissen befanden, zu unterstützen. Aber auch bei diesem Beispiel kann der Inhalt des Briefes, der nicht überliefert ist, nur durch oben beschriebene Indizien ansatzweise näher rekonstruiert werden.

Ein besonderer Fund für die Zusammenführung von Brief und archivalisch überlieferten Quellen bildete jedoch der 1905 eingereichte Antrag auf einen Reisepass, da Bernloehr für einige Zeit aus geschäftlichen Gründen nach Europa zu reisen plante. Die dort überlieferte Unterschrift Bernloehrs (folgend abgebildet) ist mit der handschriftlichen Notiz des Absenders im dazu vorgefertigten Feld auf dem hier betrachteten Brief nahezu identisch obwohl etwa 20 Jahre zwischen ihnen liegen:

Somit kann, obwohl der genaue Inhalt des Briefes weiterhin unklar bleibt, zweifelsohne bestätigt werden, das Briefschreiber und Person der archivalischen Überlieferung identisch sind.

Diese beiden Beispiele zeigen letztlich, wie groß das Potenzial ist, das in dieser Quellengattung (selbst wenn nur ein Briefumschlag erhalten und der Inhalt längst verloren ist) und der Social Philately-Bewegung auch für die Geschichtswissenschaft, insbesondere für mikrohistorische Fragestellungen, steckt. Bisher (Stand 22.07.2024) gibt es in FactGrid einen Bestand von 3790 Dokumenten, denen der Werktyp “Brief” zugeordnet ist, dazu kommen weniger als 10 Postkarten. Der Großteil dieser Dokumente stammt aus archivalischen Überlieferungen und Projekten, wie dem oben genannten Beispiel zu den Korrespondenznetzwerken der Illuminaten. Mit der Erfassung auch “einfacher Alltagskorrespondenz” jenseits dessen, was von Archivaren für überlieferungswürdig erklärt und gesammelt wird, könnte dieser Bereich ungemein wachsen, Lücken schließen und neue Verbindungen schaffen, insbesondere mit Blick auf die zahlreichen mittlerweile existierenden Projekte, die ganze Stadtbevölkerungen erfassen (beispielsweise Gotha, Leipzig oder Aschersleben).

Dementsprechend ist dieser Beitrag ein Plädoyer, die Alltagskorrespondenz des 19. und 20. Jahrhunderts, wie man sie zu Tausenden in philatelistischen Sammlungen überliefert findet, nicht in die Bedeutungslosigkeit versinken zu lassen. Gleichzeitig sollten diese Daten gezielt gesammelt sowie zentral erfasst und dokumentiert werden. Dazu bietet FactGrid eine ideale Plattform.

Ihr Potenzial liegt auch in der Zufälligkeit des Zugangs oder der Entdeckung entsprechenden Materials. Hier kann Großes gehoben werden und aus kleinen, zunächst unbedeutend erscheinenden Bausteinen ein neuer und ergänzender Blick auf die Geschichte im Großen gelingen. Dies könnte sich auf die kommunistische Bewegung der 1920er Jahre, die Biographien von Schoah-Überlebenden oder die transatlantische Migration im 19. Jahrhundert beziehen, um nur einige der oben beschriebenen Beispiele zusammenzufassen.

2024-06-17

Accessing the Sessions of the Bamberg Cathedral Chapter

Conservative estimates assume that towards the end of the early modern period, more than a tenth of the population of the Holy Roman Empire lived in ecclesiastical states.¹ In Franconia, the proportion was even higher.² Almost half of the inhabitants of the Franconian Imperial District belonged to an ecclesiastical dominion, i.e. were ruled by prince-bishops or abbots. While their functions in the Germania Sacra can already be considered well researched, less is known about their co-rulers, the cathedral chapters. The Bamberg DFG project “Governance, transition management and memory of an ecclesiastical corporation. Scriptuality of the Bamberg cathedral chapter” has therefore dedicated itself to this corporation – starting with the sessions that formed the centre of the chapter’s decision making. For the project, they were collated in a database by Alissa L’Abbé and Oliver Kruk.

What the Cathedral Chapter was

The Bamberg Cathedral Chapter was a corporation of 34 clerics, all of whom came from the nobility, mostly from the (imperial) knighthood. The group was divided into (essentially) two classes: 20 canons with full rights had a seat in the choir, received a full income and were allowed to vote at chapter meetings as well as in bishop elections. The up to 14 “junior canons” (domicellaries) did not yet have full rights, but had a candidate status. When a canon left due to death or resignation, they could take over his vacant seat. Who succeeded to the cathedral chapter was decided by the other canons in a rotation system.

The duties of the cathedral chapter could change slightly from time to time, but consisted of three core elements (over and above the canons’ spiritual duties): Firstly, the cathedral chapters are best known for their function as the electoral body of the prince-bishops. When a bishop died, they took over the government of the prince-bishopric during the vacancy, prepared the next episcopal election and ultimately decided who the next bishop would be. The prince-bishops of the early modern period therefore all originated from the corporation itself. After the election, the chapter swore the elected bishop to a collection of rights and duties, the so-called electoral capitulation. In this way, secondly, the cathedral chapter gained some central rights in the government of the prince-bishopric as early as the Middle Ages. For example, the prince-bishop was not allowed to levy taxes, pass laws or appoint officials without the consent of the cathedral chapter. Thirdly, the cathedral chapter was a largely independent sovereign in parts of the prince-bishopric, for example in Staffelstein and (until the 18th century) in parts of Bamberg, the so-called immunities. Here it could levy its own taxes, issue mandates and dispense justice itself. In addition, it had its own property from which it generated income.³

Decision-making in the Cathedral Chapter

At its sessions, the cathedral chapter made joint decisions on the issues of territorial rule and the co-government of the prince-bishopric as outlined above, as well as on matters of finance and property management. These meetings were initially held on two fixed sessions days per week (Tuesdays and Fridays). In the 18th century, however, meetings tended to be convened as required. In addition to the ordinary and extraordinary meetings, the dean, as chairman of the cathedral chapter, could also convene peremptorial sessions. At these sessions, the chapter discussed particularly important issues. Usually, all sessions took place in the chapter’s house next to the Bamberg cathedral. Only in times of war, and, later in the 18th century, for informal discussions, the canons met outside the usual framework to be able to continue consulting.

Ordinary sessions were generally only sparsely attended. This was related to the fact that most canons were prebended in several cathedral chapters and thus were absent. Moreover, they carried out tasks in the government of the prince-bishopric, e.g. in diplomatic missions. Therefore, only six out of 20 canons attended the ordinary sessions on average. For the peremptorial sessions, this number is way higher.

The canons present made decisions collectively. As there was a flat hierarchy within the chapter without a strong enforcement authority, the canons could either come to an amicable agreement or hold a vote. Especially in the 16th century, the canons endeavoured to reach a joint decision. This decision was seen as especially binding and produced strong legitimacy. Thus, the protocolls hide signs of political debate and contradiction. This changed over time: In 18th century, open discussions and combative voting took place far more often. We even find voting lists in the corresponding minute books, providing information about voting behaviour and conflict within the chapter. This difference indicates changed patterns of decision-making, but also new perceptions of honor.

The Minute Books as Historical Source

Since the chapter’s decisions were legally binding, they have been written down in the so-called “Rezessbücher” (minute books), starting in the mid-15th century. The entries are sorted by date and held in German language from their start. While they tend to be very short early in the 16th century (most decision are recorded in just one or two sentences), they become more detailed over time. As early as 1600, individual entries sometimes took up several pages of space. They include not just the decision itself, but also additional material, such as reports from officials, incoming letters or counselling content, providing further information on the corresponding topics. Since 1566, attendance lists have been added to the minute books.

Concerning written records, the cathedral chapter was far ahead of the prince-bishop in Bamberg: A continuous and serial tradition in his administration only began in the late 17th century. This is why the cathedral chapter’s minute books are the most important records of the prince-bishopric for the 16th and 17th centuries. Even beyond that time, they depict large parts of the chapter’s activities and, thus, contain details about several aspects of early modern society as well as the prince-bishoprics governmental, religious, administration and cultural history.

By making the minute books (and, by that, the sessions) of the cathedral chapter available, our data can help to access these sources from different perspectives and concerning various research questions and topics. The data thus is not just relevant for regional historians of Franconia or research topics related to the prince-bishoprics and the Imperial Church. Instead, it can be used for research on corporate decision-making, on the knighthood, on poverty, crafts and food supply, as well as on administration, reformation, military and university history – to name just a few use cases.

What’s the Data?

The data collected focusses primarily on the sessions of the Bamberg Cathedral Chapter. It includes more than 1500 sessions between 1505 and 1803, their dates, their form (i.e. if one session is ordinary, extraordinary or a peremptorial session), their attendance lists, as well as short summaries of the discussed subjects. In order to be able to find specific sessions, we have also recorded references to places (P434), persons (P33) and topics (P256), which can be queried via the Query Service. Moreover, the inventory position and a link to the corresponding online digitisation make the original sources easily accessible.

By that, users can easily find and visualise references – e.g. to places mentioned in the minute books. A map depicting these references shows the geographical focus of the chapter in the Franconian area, while indicating supra-regional references to other princely courts, dioceses, universities or the papal state.

When looking for certain topics, users can browse a list of keywords linked to one or multiple sessions of the cathedral chapter. The variety of topics indicates the broad range of contents contained in the minute books.

Going on from a special keyword, users can generate queries that help to navigate to the relevant information. For example, they can create lists that itemise sessions to certain topics. In the following, one can find sessions in which the episcopal elections have been discussed (as a timeline).

What’s missing?

Over 300 years of administrative activity and more than 120 volumes of books are a life’s work. However, since we could not devote our entire lives to it, the data remains incomplete so far. Since we worked on the period from 1522 to 1623, on the one hand, and the second half of the 18th century on the other, the period in between remains almost completely unilluminated. We also had to make a selection for the time periods of our PhD-projects. On the one hand, the selection of sessions involved cross-sections, i.e. individual years or time periods that were chosen more or less at random in order to gain a representative insight into the administrative and governmental activities of the cathedral chapter. In addition, we have analysed individual sessions in more detail, which have been thematically integrated into our PhD-projects. This is why the timeline of sessions included in our data set looks somewhat full of holes.

That said, the timeline not only shows what we were unable to compile, but also what other researchers can still explore. The sources are available online, and we are looking forward to what is yet to come.

2024-05-21

Modelling Premodern Political Entities – Case Studies from Eastern Europe

Words shape our understanding of the world. Especially in times of Disinformation, we as scholars need to be sensitive about the framing in which we put the knowledge we would like to share. The obstacles of this task become even higher in Digital Humanities. When we write a paper, we might come up with lengthy explanations why something might not be that simple. But a Graph Database such as FactGrid confronts us with the challenge of describing complex, sometimes ambivalent, sometimes contradictory historical realities in a simple statement about certain objects and the relationship between them. In the following, I would like to present some problems, that came across me during a recent research Seminar at Halle University. I will present solutions, that we came up with; hopefully offering a model for others as well. While doing so, I argue that we as scholars should emphasize the importance of a qualitative sensibility for historical realities, even and especially in times, when our discipline is changing towards digital tools and Big Data.

Competing Claims and Composite Rulership

Let’s start with some facts¹: Around the beginning of 1254, Danylo Romanovych was crowned King of Rus’ by a Papal Legate. Danylo was the Duke of Halych-Volhynia, a political entity that came into being after his father Roman Mtislavich in 1199 united the two western principalities (Halych and Volhynia) within the Kyvian Rus (map 1). The Romanovych family would rule over Halych-Volhynia until the beginning of the 14th century. After several decades of power struggles, the region would finally been divided between the Kingdom of Poland and the Grand Duchy of Lithuania around 1366 (map 2). The southwestern parts of the former principality would later (1430/1434) become the Voivodship of Ruthenia within the Kingdom of Poland (map 3).

Map 1: Western Rus’ at the end of the 12th century (Wikimedia Commons)

But how would this story look like if we describe it within certain objects (items) and the relationship (properties) between them? We have two principalities, that were united in 1199. The new entity would then become a kingdom in 1254 and this kingdom would then be divided between the Kingdom of Poland and the Grand Duchy of Lithuania. The Polish parts would become the Voivodship of Ruthenia.

Map 2: The Struggle over the Rus’ian Principalities between the Kingdom of Poland and the Grand Duchy of Lithuania in the 14th century (Herder-Institut)

There are certain challenges to this linear narrative: Firstly, the two principalities weren’t united for good in 1199. In fact, when Roman Mtislavich died in 1205, several decades of struggle over the succession within the principalities followed. Secondly, when his son Danylo finally managed to stabilize his rulership and was crowned king, it would not transform the whole principality into a kingdom. The title of “King” was ad personam, as it was with his cotemporary Mindaugas in Lithuania in 1253. So Danylo was practically king, but not over a kingdom and none of his successors would later be called king as well. Thirdly, which date should we give for the transformation of this principality into the Polish voivodship? The area was conquered mostly between 1340 and 1366. It was briefly ruled by the Kingdom of Hungary, whose ruler Louis I would also be crowned King of Poland in 1370. The region was re-integrated into the kingdom of Poland in 1387/89 but it was only almost 50 years later, that the regular voivodship was established.

Map 3: The Polish Lithuanian Commonwealth in the 17th century (Wikimedia Commons)

To complicate matters even further, there was another ruler, who claimed to be king of this area. When the Hungarian King Andrew II secured the principality of Halych-Volhynia for the underaged Danylo, he began to add Rex Galiciae et Lodomeriae (Latin form of Halych-Volhynia) to his royal title. His son Coloman would even be crowned King of Halych-Volhynia in 1216. Even though he was only able to rule in Halych for a couple of years, the title Rex Galiciae et Lodomeriae would be claimed by Hungarian rulers until the early 15th century.

This claim was dormant for centuries but then was brought forth again in the late 18th century when the Polish-Lithuanian Commonwealth was divided between the Empires of Russia, Habsburg, and Prussia. The former voivodship of Ruthenia as well as the southern parts of Lesser Poland reaching until Cracow would be annexed by the Habsburg Monarchy (map 4).

Map 4: The Partitions of Poland-Lithuania 1772–1795 (Wikimedia Commons)

In search of a justification, Austrian legal historians came up with the old Hungarian claims towards Halych-Volhynia, given the fact, that the Empress Maria Theresia was Queen of Hungary as well. Therefore, the annexed territory would be transformed into the so called “Kingdom of Galicia and Lodomeria” (map 5). Ironically, this territory would now include areas, that where never a Rus’ian principality (Lesser Poland with Cracow) but would at the same time miss the whole area of Volhynia, which was never a part of the Polish voivodship of Ruthenia.

Map 5: The Kingdom of Galicia and Lodomeria within the Habsburg Monarchy 1897 (Wikimedia Commons)

To model this complex web of competing claims and composite rules properly poses quite a challenge. Obviously, you can’t describe the relationship between the Principality of Halych to the Principality of Halych-Volhynia with a mere P6 or P7 Property (“Continuation of” / “Continued by”) since it was no stable incorporation. After consulting with Olaf Simons, we agreed on applying the property “Linking back to” (P233 germ. “Entstehungsgeschichtlicher Zusammenhang”) that might be followed by a qualifier to describe this connection to the predecessor (P234), e. g. conquest or merging of rulership (Q704817), a personal union (Q220551) or a mere argumentative recourse (tba). This rather soft description can be used for many cases. To give another example: It would be wrong to say that the Personal Union of Poland and Lithuania after 1385 was succeeding the Kingdom of Poland and the Grand Duchy of Lithuania as both parts would remain distinct political entities at least until the real Union of Lublin 1569. And even afterwards, it was still formally two political bodies under one king with a joint foreign policy.
Following the current approach in FactGrid to avoid reciprocity, the property P233 should only be applied retrospectively, so from the younger backwards to the older entity. As much as I understand the importance of data contingency, I still think, it would also be very helpful to link certain political entities to later ones. In WikiData, this is done through the property P3842 “located in the present-day administrative territorial entity”. In FactGrid, this is sometimes done through the property P742 “Historical continuum”. Here, we should come up with a decision, whether to give this kind of information or not.

Another aspect mentioned was the differentiation between a royal title and a kingdom. It would be misleading to describe the Hungarian King Andrew II as King of Halych-Volhynia. There are some mentions of the so-called Regnum Russiae in the 13th and 14th century in Hungarian sources, but – despite the brief episode of 1370-1387 – there never was a stable Hungarian rulership over the area. The title, that was established during the reign of Andrew II must be characterized as a claim, that he tried to intensify with the coronation of his son but that would ultimately become only a diplomatic leverage. If we use the property “Career Statement” to connect a person with a certain title or office, we should work with a qualifier as well that would describe the usage of this title. I propose to create the property “Legal Character” (Rechtscharakter) to describe the quality behind a certain title. We could then create an item for royal titles, that are merely titular in nature, just as we already have for titular bishops (Q164311).

Bias towards Eastern Europe?

Eastern Europe seems to be particular rewarding for such reflexions since it offers many political entities that wouldn’t correspond to nowadays national states. On the contrary, one and the same premodern political entity can form an important part of different national historical narratives. This is especially visible for the Kyvian Rus’, which forms a contested source of historical identity both in the Russian Federation and Ukraine. But it’s also true for the Polish-Lithuanian Commonwealth, which would be a source of national narratives in Poland and Lithuania, but also in Belarus and Ukraine.²

But one does not need to stay in Eastern Europe. Speaking of Sweden in the 18th century would mean to refer to an empire that comprised most of the surrounding areas of the Baltic Sea, including Finland, Latvia, parts of Estonia and even Russia.

Map 6: The Swedish Empire 1560 to 1815 (Wikimedia Commons)

But somehow, countries in Western or Northern Europe are considered to correspond much easier with contemporary states than in the East. Whereas the FactGrid item for Sweden (Q140553) simply uses the P2-Statement “Country” (Q21925), Ukraine is referred to as “state”, also with the respective P2-Statement “Sovereign State” (Q94416).

Instead of following Putin’s and other’s dark path towards a narrative of more or less “natural” states, we should use these examples as a reminder to differentiate – in analogue writing and in databases – between the different political entities we are describing. Are we talking about the contemporary sovereign state of Poland, are we talking about the Kingdom of Poland as a historical state or are we using the term more broadly to refer to a somehow blurry region? FactGrid already offers such a differentiation for the case of Germany, with different items for the “German Reich”, the “Weimar Republic” or the current “Federal Republic” but also with the item “Germany”, described as “German territories in the longer perspective” (Q140530). Following this model, I created an item for “Russia” to “describe the Russian territories that belonged to different states in a longer temporal perspective” (Q883327). Following the German example, I added the property “Subclass” (P420) to list the distinct political entities (historical and contemporary) that might be described as “Russia”. Here, it is important to stress, that those political entities were never only Russian. Since the expansion of the Grand Duchy of Moscow, this later Tsardom would include various people.³ It’s so tragic that it took this ongoing war in Ukraine for the German and international public to realise the plurality of the Russian Federation or the Soviet Union. In Russian and German, there is the possibility to differentiate between русский/russkii (germ. russisch) for Russian and российский/rossiiskii (germ. russländisch) for the larger political entity that would include various people.

Summary

In this paper, I raised more questions instead of presenting answers. Premodern political entities are very difficult to describe. That is probably the reason, why FactGrid is still missing a distinct item for the Holy Roman Empire or the Habsburg Monarchy. It’s takes time to develop an idea, how to model these messy and fluid entities. But we should take the time to do it. The shift of Humanities towards Digital Methods is not only about collecting and analysing Big Data. We also must face the challenge of finding a new language to describe historical realities with the same historical accuracy that we would expect from a written paper. Over a hundred years ago, legal scholars of the Habsburg Empire faced similar problems, when they tried to transfer the dynamic political entity of the Habsburg composite rule into a sovereign state and a constitution. Scholars like Georg Jellinek and Hans Kelsen redefined legal theory in order to invent an accurate language to describe the states they lived in.⁴

Now, we face a similar challenge to transfer historical realities into digital platforms such as FactGrid. One approach I discussed in this paper would be, to define properties, that offer enough flexibility to be applied to various cases and then describe them more precisely through qualifiers. The exchange over such decision in Item Discussions but also through articles like this is crucial. We need come up with a coherent digital language to describe incoherent historical realities.

2024-03-21

At least a make shift solution: The “Julian calendar stabiliser”

My last blog post triggered a couple of responses on Twitter. It seems I touched a problem that will not be solved that easily.

Save dates as Julian on your Wikibase (manually or, with the /J switch, in your QuickStatements mass input) and your Wikibase will be able to handle these dates correctly in any mixed bag of Julian and Gregorian dates. It is nice that the Query Service is able to produce straight timelines out of any such mixed bag, but immensely problematic that you will be quite unable to get the original Julian dates back in regular Query Service downloads. Blazegraph, the tool that is working behind the Query Service, does its job on normalisations of dates, and these are, of course, performed in the superior Gregorian calendar. Wikibase Query Services are hence on their way to produce loads of unprecedented arithmetical Gregorian dates in environments that have been solely Julian so far. We will first be puzzled by dates that strangely differ from those we fed into these machines — we will have to understand that they have silently added days on them to reach their Gregorian equivalents. Handle these artefacts as correct Gregorian dates, though they are without evidence in the historical records — do not feed them as Julian into any Wikibase because that will immediately expose them to the next round of Julian to Gregorian conversions wherever a Query Service will spot them.

SPARQL queries can actually produce the complexity of the Wikibase they are accessing, but that requires quite some scripting skills. Tagishsimon gave the following script that helped him to get well informed dates from Wikidata in this Twitter response:

Per Bruno, SPARQL/WDQS will give you all of the data required to convert a Gregorian date back to a Julian date, it's just a bit of a clart. pic.twitter.com/S3gBpO93cp

— Tagishsimon (@Tagishsimon) March 20, 2024

Bruno Belhoste applied this script in the following FactGrid query, which will be extremely useful in all future searches on our database. The table gives you the birthdays of members of the French Academy — a typical “mixed bag” of dates that shows all imaginable challenges of different calendars and the various precision statements:

The members of the French academy, their dates of births with precise information, including calendar statements

Change the parameters and you will get the dates you are interested in with all the information you will need to process a mixed bag of historical dates from the Wikibase of your choice.

A make shift solution: The “Julian Calendar Stabiliser”

We agreed that we have to stabilise Julian dates on FactGrid under these conditions. All Julian dates will be translated to Gregorian sooner or later on our Query Service. Users must, hence, remain able to get the original Julian information side by side with their (secretly Gregorianised) searches. The simple solution is a string repetition of the Julian statement you want to make. The Query Service does not touch strings, chains of characters and numbers; it will give you the original Julian statement which you can use in other contexts as the very dates you saw in your documents:

Johann Sebastian Bach’s birthday with the “Julian date stabiliser” (see it in the data set)

This is not the ideal solution. One would rather like to have a calendar sensitive Query Service that produces dates as stated on your Wikibase; but it is at least a pragmatic stabilisation to keep Julian dates intact in the waves of transformations and deformations which we are likely to witness in the new world of data processing.

2024-03-18

Are our Wikibase QueryServices about to mess up two millennia of historical dates?

It was in February 2019 at a conference dinner of medievalists in Jena when I was first confronted with the calendar problem which Wikibase had been posing ever since it had digested its first Julian calendar dates. I had given a Wikibase demonstration earlier that day and now I was sitting next to a medievalist who was ready to destroy me: “Wikibase”, he stated, “is a genuine disaster without anyone understanding it.”

I demanded to hear why that should be the case and the man asked me to show him just one medieval date from Wikidata. I had activated my phone and landed on biography c. 1500.

“See that small print?” he asked, “these dates are all noted as Gregorian before 1584.”

The qualifier was indeed peculiar. Why would they set a Gregorian date before 1582 and then mark it as such? “Well, you know, that the Gregorian calendar was only introduced in 1582, do you?!”

Of course I knew. I am an 18th-century person and Britain had introduced this calendar as late as 1752. The reform had by that time to close a gap of 11 days. But I could also point out that Wikibase allowed the fast correction: “You can easily switch between the calendars, and the machine will actually understand the implications on any timeline” I showed him my screen:

The man was in agony: “Too late. Wikidata is already in big shit”. I realised that I was lacking the full astronomical background and that I did not know the story of these peculiar Wikidata redactions.

Why we needed the Gregorian calendar in the first place

Both, the Julian calendar of 46 BC and the superior Gregorian calendar first introduced in 1582, are approximations. A solar year is one circle around the sun whilst the globe is spinning at about 365.2422 revolutions per year — year after year our planet ends its tour with a different slice pointing towards the sun. We are, in fact slowing down, thanks to the friction which the moon’s gravitation is generating in a constant movement of ebbs and tides, but that is another story. 365.2422 turns per year is our present spin more or less exactly but difficult to generate in a procedural long term pattern of constant adaptations.

The Julian calendar, as it was introduced under Julius Caesar in 46 BC, added one day every four years — in the so called leap years — a rule that boiled down to an additional quarter of a day per year. The approximation of 0.25 days against 0.2422 missed its mark just by 0.0078 days per year, less than a hundredth of a day — negligible one might think — but that one hundredth of a day is a day in a hundred years. In a millennium this discrepancy is piling up to 7.8 days, in two millennia to half a month, moving Christmas further and further away from the longest night until we can finally celebrate Christmas and Easter on the same day; and that was why the Gregorian calendar was finally introduced in 1582 with its far more complex regime of leap years:

add one day every four years (as you did under the Julian calendar to create a year of 365.25 days)
omit every leap year that is divisible by 100 to get a lower number
let this leap year, however, happen if it is divisibly by 400 in order to get a year of 365.2425 days.

The Gregorian calendar reduced the aberration to a surplus of 0.0003 days per year — it will now take 3333 years until we need an additional day to be back in tune with the solar year. The Vatican in Rome adopted the calendar on the 4th of October 1582 — jumping over night into Friday the 15th of that year. Christianity, however, was at that point no longer ready to obey a Papal decree. Eastern Orthodox churches stayed on the Julian calendar right into the the 20th century; Protestant territories and realms would decide one by one. Prussia (with its complex ties into catholic Poland adopted the new calendar in 1612 whilst most of the other Protestant territories stayed Julian for the next 88 years. The United Kingdom took the step in 1752. Lithuania, Russia, and Greece were to switch as late as 1915, 1918 and 1923 respectively.

The following map is from reddit:

When Europe switched from Julian to Gregorian calendar.
byu/coneyislandimgur ineurope

…and it is far from getting the full complexity. The following list gives the growing FactGrid table:

Europe was fragmented. Travelling across Germany in 1699, you could date your letters switching back and forth at every customs house on your tour:

Map of the Holy Roman Empire 1648. Wikimedia Commons

How we solved the problem — and created an even bigger one

Wikibase is a bright software. The tools — the QueryService and QuickStatements — are (or were) not immediately that bright, and that caused the mess the medievalist had noted. QuickStatemens, the tool for mass imports, simply did not offer a Julian calendar switch before February 2023. Instead it would mark all dates as Gregorian without asking — which, looking backwards, was not all that bad…

…why could we all live with the erroneous labelling of Julian dates as Gregorian on Wikidata? Because Wikidata was with this negligence basically doing what we all had been doing up to that point.

Johann Sebastian Bach was born on the 21st of March 1685. Germany’s central database, the GND, is stating this date up until now without the slightest remark on the calendar. The date is Julian because Eisenach’s church register was keeping records in the Julian calendar for another 15 years. The composer himself will not have shifted his birthday to the 31st of March in 1700, the year of the great reset. We all ignore the shift and keep copying dates from documents without any interference. Calendar experts might be interested in the “real” day and they can create Julian/Gregorian calendar matches in those rare cases in which they have to create an exact timeline of events with dates of both calendars.

The Wikidata community had been unaware of the problem. The Gregorian label on all the Julian days was foolish, but the input was actually stabilising our historical tradition as the QueryService will not do anything odd with dates that are entered as Gregorian.

I was far from seeing these advantages after my conversation of 2019 and that was why I warned the PhiloBiblon team in 2022 that QuickStatements would label all their Julian dates as Gregorian against all better intentions once they were imported to FactGrid. Charles Faulhaber immediately asked their programer, Josep Maria Formentí, whether he could not take a look into QuickStatements to solve that little problem. Weeks later Josep introduced the /J-switch that is now available to mark any date as Julian in mass inputs:

+ 1751-06-16T00:00:00Z/11/J

You can now feed thousands of medieval or early-18th-century British dates into your Wikibase and your machine will present all these dates in timelines in perfect synchrony with Gregorian dates. This is extremely nice if you are editing a correspondence whose partners were signing their letters under various calendars. Your machine will give you the exchange of letters in their true course.

So why the alarm?

Wikibase is an intelligent software; it brings objectivity into your statements. Feed a Julian date into your Wikibase and that day will be noted as Julian on the Wikibase itself.

Things get messy wherever we retrieve Julian dates from the QueryService, since this is where the production of funny (and eventually of erroneous) dates will be begin. The QueryService will convert all Julian dates into mathematically correct Gregorian dates.

Martin Luther is known to have died on the 18th of February 1546 — under the Julian calendar, that needs not to be stated, and our Wikibase is giving that date without any calendar stamp on it. But ask the QueryService for Luther’s birthday and it will tell you that the church reformer actually died on the 28th of March, 10 days later — a Gregorian calendar date (without indication) (no big issue you might think, now that you know).

And now think of masses of data which we will be moving between Wikibases in the brave new world of “federates Wikibases”. If there are “Julian” dates among them, then these will get secret additional days wherever they are extracted with the help of a regular SPARQL-Query on the QueryService.

This is what will happen to Luther’s date of death as it is now no longer a subject of safe copying. We will see it in an increasing number of variants — namely as:

18 February 1546 (Greg.) — mistaken QuickStatements input artefact
18 February 1546 (Jul.) — the historically correct date
28 February 1546 (Greg.) — unorthodox but correct Wikibase QueryService output
28 February 1546 (Jul.) — Wikibase output mistakenly saved as Julian
10 March 1546 — the previous converted to Gregorian
20 March 1546 — the previous after the next im- and export

and so on and so on.

Can we stop the wave of uncontrolled additions of days on Julian calendar dates?

I am not quite sure how. We need a QueryService that will never ever offer a historical date without the corresponding calendar statement (now that we have a machine that does both calendars).

But not only the QueryService is posing a problem here. Our Wikibases should have a third option, because our documentary evidence is usually lacking calendar information. Eisenach’s church register of 1685 is using the Julian Calendar (without further notice), that is something we can determine — but we cannot say what calendar an author of a typical letter was using in 1685 if that date comes without a localisation. Our documents do not tend to have calendar statements on them.

What we need here is a third — a “calendar format unknown” — option. It’s complicated, I am afraid.

Links and more

Header image from Ολυμπία δώματα, or, An almanack for the year of our Lord God 1752 (London: Printed by T. Parker, for the Company of Stationers, 1752), from the digitisation at Archive.org
English Wikipedia List of adoption dates of the Gregorian calendar by country https://en.wikipedia.org/
See also: Maniphest T207705, Implement the Extended Date/Time Format Specification, https://phabricator.wikimedia.org/T207705
Lydia Pintscher, calendar model screwup, 30 Jun 2015. [https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/thread/Y7OEHUYV66DHRVZ6JCSODWAYZ25SLUHM/ https://lists.wikimedia.org/hyperkitty]
Julian and Gregorian dates from Wikidata, question asked on https://opendata.stackexchange.com/, Apr 18, 2018 at 0:33 [https://opendata.stackexchange.com/questions/12723/julian-and-gregorian-dates-from-wikidata https://opendata.stackexchange.com/]

2023-12-11

Roscher’s Lexikon of Mythology as Linked Open Data: Starting a Project on FactGrid

In the age of Linked Open Data, the humanities have increasingly turned their attention from the mere collection of data to its modelling with ontologies and data models. In the field of Greek mythology, these approaches have started in very recent times. Alongside the creation of new databases like MANTO [1], Mythoskop [2], Theoi.com [3] and ToposText [4] (to name but a few), at least three attempts have been made to create an ontology for Greek mythology. In 2018, C. Syamili and R. V. Rekha outlined an ontology for mythical heroes with reference to Wikipedia and the Theoi project [5]. From a classicist’s point of view, R. Scott Smith of the MythLab team has written a series of blogposts with great scholarly detail, which not only address the modelling of mythical characters but also of events, objects and locations [6]. Another team of computer and information scientists have tried their hand at creating an ontology based on Theoi.com and Wikidata in 2021; they built on Syamili & Rekha’s study but significantly expanded its scope [7].

However, none of these projects have worked with the most copious source on Ancient Mythology which has been produced to date: Wilhelm Heinrich Roscher’s Ausführliches Lexikon der griechischen und römischen Mythologie [8]. Published from 1884 to 1937 in more than 100 fascicles which make up 6 volumes, it reports on individual deities, characters, creatures and (to a lesser extent) concepts, events, objects and places from Greek and Roman mythology. The result is an unparalleled collection of records and source material on more than 15,000 subjects, a number larger than that of any of the databases listed above. This vast knowledge base has to this day not been used to its full potential aside from serving as a reference work. While a full digitisation of the 14,000 colums of text interwoven with illustrations and tables is a daunting project (pending approval by De Gruyter, the publishing company which holds the rights to this work), it is certainly worth considering.

To pave the way for such a project, I have created an index file for Roscher’s Lexikon (to be published on Zenodo) featuring headwords, location (volume, fascicle, column extent), date of publication, author name(s) and subject classification – hence the tangent on ontologies for Greek mythology. This file can be not only be used as a reference in and of itself, but also to create basic items for more than 15,000 mythical entities which can then become part of a Linked Open Data hub for mythology. As a venue to create this dataset I have chosen FactGrid.

What is FactGrid?

FactGrid is a public research environment founded by Olaf Simons in 2018. Hosted by the Gotha Research Centre, it runs on MediaWiki with the Wikibase extension, which was developed by Wikimedia Deutschland in its creation of Wikidata, the RDF-based hub which connects all Wikimedia projects. Both Wikidata and FactGrid are licensed under CC-0, meaning data can be shared between the two platforms without running into legal issues. But aside from the identical licensing and familiar User Interface (which can be enhanced by using the custom FactGrid Viewer [9]), there are some striking differences between the two websites.

First of all, FactGrid not only allows original research (which is forbidden or at least strongly discouraged across Wikipedia and Wikidata) but presents itself especially to this sort of use. Second, it can only be edited by registered users, and signing up for an account is not possible without former approval. Third, users are required to use their real names (whereas in Wikidata and its sister projects, pseudonyms are the norm). Points #2 and #3 means FactGrid can afford to allow original research without risking being swamped by unsolicited data input (to avoid the term ‘spam’). The result is Linked Open Data from various genealogical and other research projects which are not only visible to the public but also widely reusable thanks to liberal licensing.

Integration with Wikidata is achieved in two ways: On FactGrid, sitelinks to the Wikimedia projects (including Wikidata) can be set to items; and like with Wikidata, these sitelinks need to be unique and distinct, meaning one and the same sitelink cannot be present in two items at the same time, and each item can have exactly one link to the German Wikipedia, the French Wikisource and so on. This feature is hard-coded in the Wikibase structure and it prevents data duplication. Wikidata on the other hand links to FactGrid Items and Properties with two custom properties (P8186 and P10787).

Goals for a mythical dataset on FactGrid

What can hoped to be achieved by bringing data from Roscher’s Lexikon to FactGrid? Many things come to mind, but I want to highlight two, one achievable in short-term, the other a long-term goal.

Without too much effort, a Knowledge Base of entities (predominantly characters, but also events, objects, places and concepts), which exist or have existed in Greek and Roman (and neighbouring) mythologies, can be created on FactGrid. These items can then be checked against their source (Roscher’s Lexikon) which will be linked in every item.

In the long term, this dataset can be enriched by creating additional entries not covered by Roscher’s Lexikon (as well as marking pseudo-entities which have been disproven by later scholarship), and more importantly, by adding custom statements to the individual items about (including, but not limited to): name variants, genealogy, primary sources, depictions, reception, participation in events. In theory, anyone could contribute to this process, and it would be an ideal playground for students who want to learn about LOD or mythology (or both).

While such datasets in mythology already have been or are being created (MANTO is the most ambitious project in this regard), Roscher’s data may provide a useful corrective. And by matching the dataset against external databases like MANTO, Mythoskop, Theoi.com, ToposText and Wikidata, all these projects can partake in the information provided by Roscher. And while Wikidata has great potential in creating a rich well of LOD on mythology, it is prone to interventions due to its being non-restrictive in who can edit it. This is where FactGrid comes in handy: It is customisable and freely licensed, yet contained enough to provide stability for such a project.

Why use Roscher’s Lexikon for that?

Even though research in classical scholarship tends to have a longer half-life than STEM, using an encyclopedia that was for the most part published more than a century ago will raise some eyebrows. But Roscher’s Lexikon not only still useful as repository of primary sources and outdated literature, it is a unique and valuable resource and merits the attention of our age. The argument for this can be made from three aspects:

First, scope. Although Roscher’s Lexikon mainly deals with Greek and Roman mythology (as its title suggests), it also reports on the neighbouring cultures (Assyrians, Babylonians, Celts, Egyptians, Etruscans …). While it is by no means the only encyclopedia on mythology doing so, it was the first that could make use of the advances made by Cuneiform Studies, Egyptology, Epigraphy and Religious Studies which had seen an unparalleled surge in the 19^th century.

Second, scale. While complete coverage is unlikely to ever be achieved, Roscher’s Lexikon came closer to it than any previous or later encyclopedia. Its more than 15,000 headwords not only take into account nearly all mythical characters featured in Greek and Latin literature, but also named characters and deities from inscriptions (votives) or artifacts (like mosaics, vases, statues). When compared to Pauly-Wissowa, the second installment of Pauly’s Realencyclopädie der classischen Altertumswissenschaft started seven years after Roscher’s Lexikon, Roscher almost always has more homonyms (characters with the same name) than Pauly-Wissowa. And as a mention of a character is enough to warrant recognition, Roscher has far more articles overall than the Lexicon Iconographicum Mythologiae Classicae (LIMC), its successor project published between 1981–1999 (with a supplement in 2009), even though the latter is more up to date, especially on artifacts.

Third, plurality of scholarship. As already mentioned, Roscher’s Lexikon was not limited to classical Greek and Latin literature for its sources. It also relied on epigraphic and papyrological finds as well as art history and archaeology; in the latter department, the authors and editor often explicitly expressed dissatisfaction with their ability to do justice to their ambition: Scholarship in these areas was widely dispersed and had in many cases never been assembled. Considering their time and circumstances, the authors did a good job, even publishing some depictions for the first time in print; but in regards to depictions of myths, Roscher is most outdated and the LIMC should always be preferred as a reference work.

As any scholar who has researched literary sources for ancient myths will admit, Roscher’s Lexikon is still worth consulting. If this can be facilitated by shaping it into a LOD dataset, such an effort should be welcome to the scientific community.

References

[1] https://manto.unh.edu/

[2] https://mythoskop.de/

[3] https://www.theoi.com/

[4] https://topostext.org/

[5] C. Syamili, R. V. Rekha, “Developing an ontology for Greek mythology”. The Electronic Library 36.1 (2018), 119–132, https://doi.org/10.1108/EL-02-2017-0030.

[6] R. Scott Smith, “The Ontology of Mythical Entites: Part 1”. MANTO June 11, 2020: https://www.manto-myth.org/blog/the-ontology-of-mythical-entities-part-1; id., “The Ontology of Mythical Entites: Part 2”. MANTO June 24, 2020: https://www.manto-myth.org/blog/the-ontology-of-mythical-entities-part-2.

[7] Juan-Antonio Pastor-Sánchez, Efstratios Kontopoulos, Tomás Saorína, Thomas Bebisc and Sándor Darányi, “Greek Mythology as Knowledge Graph: From Chaos to Zeus and Beyond”. Semantic Web Journal November 3, 2021: https://www.semantic-web-journal.net/content/greek-mythology-knowledge-graph-chaos-zeus-and-beyond.

[8] On Roscher’s Lexikon see most recently Udo G. Reinhardt, Hundert Jahre Forschungen zum antiken Mythos (1918/20–2018/20). Mythological Studies (MythoS) 5, Berlin/Boston: de Gruyter 2022, 19 sq. More information can be found on Wikipedia: https://de.wikipedia.org/wiki/Ausf%C3%BChrliches_Lexikon_der_griechischen_und_r%C3%B6mischen_Mythologie.

[9] https://database.factgrid.de/viewer/