Abstract

• 1. Das Semantic Web und die Annotations- und Registerpraxis digitaler Editionen
• 2. Karl Kraus: Eine dicht besiedelte Forschungslandschaft
• 3. SemanticKraus: Ziele und Voraussetzungen
• 4. Workflow, Datenformat, technisches Setup und Datenprovenienz
• 5. Das Datenmodell
• 6. Differierende Modellierungen bibliographischer Angaben
  • 6.1 Anreicherung als Strukturierung
  • 6.2 Ausdifferenzierung der ontologischen Ebenen von ›Text‹
  • 6.3 URI-Sourcing
• 7. Abschließende Überlegungen
• Einbezogene Editionsprojekte
• Bibliografische Angaben
• Abbildungsverzeichnis

1. Das Semantic Web und die Annotations- und Registerpraxis digitaler Editionen

[1]‍[1]Der Eindruck, den Interessierte aus der Durchsicht digitaler Editionen gewinnen können, ist der einer großen Vielfalt: an inhaltlichen und methodologischen Ansätzen ebenso wie an das Design und die technische Umsetzung betreffenden Lösungen. Zugleich fallen jedoch große Überschneidungen zwischen digitalen Editionen ins Auge. Dies betrifft vor allem die Aufmerksamkeit, die Editionen bestimmten Klassen von Entitäten widmen – ihrer Identifikation, ihrer Annotation im Text und ihrer Aufnahme in Register. Gleich nach der Bereitstellung des Textes in Form von Umschrift und Faksimile zählen Personen-, Orts- und Werkregister erfahrungsgemäß zu den am häufigsten anzutreffenden Modulen digitaler Editionen. Sie stellen Projekterträge dar, die mit großem Aufwand gesammelt und integriert werden. Die Ziele dabei variieren: In einigen Fällen mag die Möglichkeit im Vordergrund stehen, Nutzer:innen neben der linearen Textlektüre auch andere Wege in den Text zu erschließen, ihnen also die Möglichkeit zu bieten, über die Nennungen von Personen, Werken oder anderen Entitäten in den Text einzusteigen; damit bindet die Annotation den Text an die außertextuelle Realität an und hat damit, wie ein Kommentar, eine vermittelnde Funktion inne.‍[2] In anderen Fällen mag es umgekehrt darum gehen, die historische Wirklichkeit aus den Entitäten des Textes, den in ihm genannten Ereignissen, Personen, Orten heraus überhaupt erst zu erschließen.‍[3]

[2]Seit Jahren wird immer wieder die Forderung nach der Verknüpfbarkeit und Interoperabilität solcher Registerdaten gestellt. Ein wichtiger Schritt in diese Richtung ist die vielgeübte Praxis der Verlinkung auf Normdatensätze wie etwa die der Gemeinsamen Normdatei, was die eindeutige Identifikation der Entitäten gewährleistet. Der vom Großteil der Forschungsgemeinschaft getragene Annotationsstandard TEI schafft hinsichtlich eines anderen Aspekts des Problems Abhilfe: Durch die Nutzung weitgehend derselben und natürlichsprachlich benannter Kategorien (<person>, <persName>, etc.) stellen die abgelegten Datensätze auch für Außenstehende in der Regel keine ›black box‹ mehr dar.

[3]Das Semantic Web‍[4] jedoch bietet darüber weit hinausreichende Möglichkeiten – deren Realisierung dabei von einigen Bedingungen abhängt. Die Kombination von RDF-Graphen‍[5] und maschinenlesbaren Vokabularen (Ontologien) ermöglicht eine umfassend ›erläuterte‹ Speicherung von Aussagen: RDF-Triples (Subjekt-Prädikat-Objekt) zerlegen jede Information in atomare Einheiten, deren Glieder in den verwendeten Ontologien ausführlich beschrieben und deren Klassenhierarchie und andere Eigenschaften ebendort menschen- und maschinenlesbar hinterlegt sind. So lassen sich, die entsprechenden Vokabulare vorausgesetzt, Informationen inferieren, die gar nicht expressis verbis in den Daten angelegt sind. Die eindeutige Identifikation von Entitäten durch URIs (Uniform Resource Identifier) sowie durch die Verlinkung mit externen Identifiern trägt weiters zur Anbindung der Daten an die Linked Data Cloud bei. Die technischen Grundlagen (die notwendigen Schnittstellen) vorausgesetzt, ist so die kombinierte Abfrage über mehrere Datensets möglich – neben der Generierung inferierten Wissens wahrscheinlich der Goldstandard der Semantic-Web-Nutzung.

[4]Die Möglichkeiten von Semantic Web und Graphentechnologien im Zusammenhang mit digitalen Editionen wurden schon mehrfach angemerkt, eingefordert, kritisch reflektiert.‍[6] Ein rezenter Sammelband widmet sich ausschließlich dieser Thematik.‍[7] In methodisch-theoretischer Hinsicht liegt für die digitalen Geisteswissenschaften großes Potenzial in den Möglichkeiten des Semantic Web – immer die bestmögliche Übertragung fachspezifischer Begrifflichkeiten in den Kontext von Semantic-Web-Ontologien vorausgesetzt.‍[8]

[5]Die Möglichkeiten des Semantic Web können jedoch unter den Voraussetzungen, unter denen Editionsprojekte geplant und umgesetzt wurden (und vielfach noch werden), oft nicht genutzt werden. Das hat unter anderem mit dem Aufwand der Implementierung bzw. der Prioritätenreihung zu tun. Dem stehen Projekte gegenüber, die sich die Nutzung dieser Technologie von Beginn an auf die Fahnen schreiben, die also in ihrer Umsetzung stets schon RDF und Co. nutzen.‍[9] Andernfalls kann man den Schritt ins Semantic Web auch nachträglich machen. So ein Unterfangen hat seine Hürden, aber auch seine Erkenntnispotenziale, und ist Gegenstand der folgenden Ausführungen. Dabei wird zuerst die Ausgangslage erläutert – die digitalen Editionen zum Werk von Karl Kraus, deren Projektdaten Anlass für das Projekt SemanticKraus: Connecting Kraus-Scholarship to the Semantic Web waren. SemanticKraus hat sich zum Ziel gesetzt, diese Daten nachzunutzen, indem sie transformiert, in einen gemeinsamen Wissensgraphen eingespeist und menschen- sowie maschinenlesbar publiziert werden. Nach einigen Anmerkungen zur technischen Umsetzung und zum Workflow wende ich mich dem Schwerpunkt der Projektvorstellung zu: der Behandlung der ›konzeptionellen Distanz‹, die zwischen den Ausgangsprojekten selbst sowie zwischen diesen und dem Ziel-Datenformat unter anderem hinsichtlich Datenmodell, Datengranularität und Referenzierbarkeit der Entitäten bestand und die auf dem Weg vom Ausgangsmaterial zum angestrebten RDF-Datensatz überwunden werden musste.

2. Karl Kraus: Eine dicht besiedelte Forschungslandschaft

[6]Karl Kraus’ Schriften gehören wahrscheinlich zu den im Web schon am längsten und umfassendsten zur Verfügung gestellten Werkbeständen deutscher Sprache: Schon 2007 ging die Edition der gesamten Fackel‍[10] online, der Zeitschrift, die Kraus von 1899 bis zu seinem Tod 1936 herausgab und die er für den größten Teil dieser 37 Jahrgänge alleine verfasste. Die Edition umfasst 415 Hefte mit insgesamt über 22.000 Seiten; seit 2019 wird sie um ein umfangreiches Personenregister mit Verlinkungen auf ca. 130.000 Textstellen ergänzt.‍[11] Im Jahr 2018 wurden auf Karl Kraus online Materialien u. a. zu den Rechtsstreitigkeiten des Autors publiziert; 2022 publizierte das Karl Kraus Rechtsakten-Projekt eine Edition dieser umfangreichen Aktenbestände der für Kraus tätigen Kanzlei Samek.‍[12] Die digitale Edition seines Spätwerks Dritte Walpurgisnacht ging 2021 mit einem ersten, zum Jahreswechsel 2023/2024 mit einem zweiten Publikationsschritt online.‍[13] Weitere Projekte zu diesem Autor, der die Wiener und deutschsprachige Kulturlandschaft von der Jahrhundertwende bis in die letzten Jahre der österreichischen Ersten Republik kommentierte, kritisierte, maßgeblich mitgestaltete, sind in Planung.

[7]Für die bereits abgeschlossenen bzw. in weit fortgeschrittenem Stadium befindlichen drei genannten Editionen jedoch gilt: Die Möglichkeiten des Semantic Web waren in der Planung unberücksichtigt geblieben, was teils schlicht mit dem Alter der Editionen, andernteils mit methodischer Ausrichtung oder erwähnter Prioritätenreihung zu tun hatte. In allen drei Projekten wurde beispielsweise auf Normdatensätze verlinkt (im Fall der Fackel-Personendatenbank nachträglich im Zuge der laufenden Aktualisierungsschritte), wobei unter anderem die GND berücksichtigt wurde sowie über die PMB,‍[14] eine thematisch stärker spezialisierte Datenbank, auch die Verlinkung vom Normdatensatz zurück ins Projekt stattfand. Eine Abfrage über die gesamten Bestände war dennoch nicht möglich – und das, obwohl die Schnittmengen der drei Projekte enorm waren, sein mussten: Karl Kraus befehdete sich in seinen Rechtsfällen vielfach mit denselben Personen, die auch in seiner Zeitschrift Die Fackel Ziel seiner Angriffe wurden; die Fackel-Texte, auf die er in seinem Spätwerk Dritte Walpurgisnacht zurückverweist, werden auch in den Schriften seiner Anwaltskanzlei vielfach genannt. Die inhaltlichen Überschneidungen waren also offensichtlich groß, bloß: technisch nicht ausreichend realisiert.

3. SemanticKraus: Ziele und Voraussetzungen

[8]Diesem Desiderat widmete sich SemanticKraus.‍[15] Zu den Zielen des Projekts zählte u. a.,

• die entsprechenden Register- und Textdaten der drei Ausgangsprojekte in ein und dasselbe, CIDOC-CRM-basierte‍[16] RDF-Datenmodell zu übertragen,
• die resultierenden Datensets gesammelt in einem Triplestore abzulegen,
• diesem ein Userinterface vorzulagern, um die individuelle Erkundung der Daten zu ermöglichen, und
• eine (SPARQL-)Schnittstelle für die maschinelle Abfrage der Daten bereitzustellen.

• im Fall der Fackel online die ca. 14.000 Texte der 37 Fackel-Jahrgänge, die knapp 130.000 Textpassagen mit Personen-Nennungen und die von dort aus referenzierten ca. 15.000 Einträge der Personendatenbank;
• im Fall der Rechtsakten die annähernd 4.000 juristischen Dokumente inklusive ihrer Bezüge auf 3 Registerdateien, die 1.700 biographische und 850 bibliographische Entitäten verzeichnen;
• im Fall der Dritten Walpurgisnacht den Text des Werkes selbst sowie seine ca. 3.000 Bezüge auf ca. 400 Personen und 1.100 Intertexte.

• Der Volltext der Fackel online liegt in einem älteren, hauseigenen XML-Standard vor, der nur entfernte Ähnlichkeit mit TEI aufweist.
• Die dazugehörige Personendaten liegen in einer SQL-Datenbank (aus der sie als TEI-XML ausgeworfen wurden).
• Die Texte sowie die Register der Rechtsakten und der Dritten Walpurgisnacht liegen als TEI-XML vor, jedoch in unterschiedlichen Modellierungen.

[9]Bei all den Anforderungen, die diese Voraussetzungen an die Erstellung eines übergreifenden Datenmodells sowie an die technische Transformation der Daten stellten, war SemanticKraus dennoch ein Projekt von sehr kompaktem Zuschnitt. Hingegen waren die institutionellen Voraussetzungen sehr gut: Sämtliche Projekte waren auf die eine oder andere Weise ans ACDH-CH, die ausführende Institution von SemanticKraus, angebunden bzw. liefen noch ebendort. Das sei hier angemerkt, um die ansonsten oft signifikanten Schwierigkeiten, sich in ›fremde‹ Projektdaten einzuarbeiten, durch den Kontrast zu beleuchten: Offene Fragen, dunkle Stellen im jeweiligen Projekt-Datenmodell konnten auf die einfachst mögliche Weise erhellt werden (oft durch den Gang ins benachbarte Büro). Darüber hinaus begrüßten die Stakeholder der verschiedenen Projekte die Unternehmung, vielfach konnte zudem auf vorhandenes Know-How der technischen Säule des ACDH-CH zurückgegriffen werden.‍[17] Außerdem ermöglichte es die für die Webapplikation genutzte Softwarelösung – ResearchSpace – mit verhältnismäßig niedrigem Aufwand, die erforderlichen Templates für das User-Interface zu erstellen.‍[18]

[10]Die SemanticKraus Exploration Platform als zentrales Ergebnis des Projekts bietet neben Paratexten zum Projekt und zu den Ausgangsprojekten eine Suchfunktion über die gesamten Daten sowie ein ›show case‹ an Beispiel-Entitäten, das zentrale Personen und Texte von besonderem Interesse als Einstiegspunkte vorschlägt. Durch die Aggregation der Daten lässt sich nun etwa Kraus’ Behandlung von historischen Personen durch die Fackel, die Rechtsakten sowie das Spätwerk der Walpurgisnacht verfolgen. Das Datenmodell wird mittels einer detaillierten Visualisierung vorgestellt. Das auf ResearchSpace aufbauende Userinterface setzt sich aus ca. 20 für die wichtigsten Klassen individuell angepassten Templates zusammen, die verschiedene Visualisierungsmöglichkeiten bieten (vgl. Abbildung 1). Das SPARQL-Interface ermöglicht die Exploration der Daten noch über die Grenzen der Templates hinaus.

[11]Die Modellierung der Daten als RDF erlaubt verhältnismäßig einfach die zukünftige modulare Erweiterung der Plattform durch die Integration weiterer Forschungs- und Editionsdaten. Die aktuellen Projektdaten sowie die Projektontologie liegen in öffentlichen Git-Repositorien, von wo aus Transformation und Daten-Ingest in den der Web-Applikation zugrundeliegenden GraphDB-Triplestore mittels CI/CD-Workflows‍[19] automatisiert erfolgen. Die Daten umfassen derzeit u. a. 15.900 Personen (konsolidiert von insgesamt 16.600 Personendatensätzen in den Ausgangsdaten) sowie 19.700 Texte mit 18.900 intertextuellen Relationen und 145.800 Personennennungen.

Abb. 1: Eine Visualisierung des Erscheinungsverlaufs der Fackel, basierend auf dem transformierten Text-Index der Fackel online, erstellt mittels einer ResearchSpace-Komponente und abrufbar unter der URI der Fackel in SemanticKraus. [Screenshot: Bernhard Oberreither 2025]

[12]Diese Projektvorstellung widmet sich im Folgenden vorrangig der eingangs erwähnten ›konzeptionellen Distanz‹ zwischen den TEI-XML-Daten, die am Anfang standen, und dem resultierenden RDF: RDF bzw. Linked Data zeichnet sich ja prinzipiell durch einen großen Grad an Eindeutigkeit aus (alle Entitäten sind eindeutig identifiziert); darüber hinaus – jedenfalls innerhalb der CIDOC-CRM-Familie – durch einen großen Grad an Feinkörnigkeit und damit einhergehend an Explizitheit (durch die präzisen Definitionen der Klassen und Relationen in den Ontologien). Ausgangspunkt meiner Überlegungen ist die recht basale Beobachtung, dass das bei (TEI-)XML nicht in diesem Maß der Fall ist, nicht in der üblichen Praxis, nicht in unseren konkreten Ausgangsprojekten. Vorerst lässt sich das Problemfeld der Konversion von TEI-XML in RDF / CIDOC CRM wohl mit diesen – zugegeben: stark vereinfachenden – Befunden umreißen:

• Ungenaue Daten: Den Daten, die das TEI-XML enthält, mangelt es im Vergleich zum Zieldatenmodell oft an differenzierten Klassifikationen für die Entitäten.
• Zu wenige Daten: Das TEI-XML enthält meist weniger explizite Information (weniger ›Datenfelder‹), als das Ziel-Datenmodell voraussetzt.
• Uneindeutige Daten: Den Entitäten der Ausgangsdaten fehlen oftmals eindeutige Identifier.
• Die falschen Daten: Die Daten, die das Ausgangs-XML annotiert, entsprechen nicht exakt denen, die man extrahieren und in das Ziel-Datenmodell übertragen will.

[13]Der vierte Punkt ist womöglich weniger verallgemeinerbar als die anderen, er spielte jedoch im Projektkontext eine große Rolle (vgl. Abschnitt 6.2 zum Fackel-Textindex) und wird deshalb hier berücksichtigt. In den kommenden Abschnitten werden exemplarisch Ausgangslage und Arbeitsschritte vorgestellt, die manchmal einen, meist mehrere dieser Befunde betreffen. Es versteht sich übrigens von selbst, dass diese Liste keinerlei Kritik impliziert – weder an der gängigen TEI-Praxis noch an unseren drei Ausgangsprojekten (von denen ich selbst eines verantworte). Die Differenz zwischen TEI und CIDOC CRM liegt schlicht in der Natur der Sache, im Unterschied nämlich zwischen einer Text-Auszeichnungssprache und einer ursprünglich dem Museumskontext entstammenden, ereigniszentrierten Ontologie.‍[20]

[14]Am Beispiel der Transformation intertextueller Verweise und bibliographischer Daten lassen sich die Erkenntnispotenziale solch eines Projekts am besten illustrieren. Dies liegt zum Teil daran, dass hier die Modellierungsunterschiede in unseren Ausgangsprojekten relativ groß waren. Darüber hinaus war die Modellierung solcher Daten in unserem RDF-Datenmodell deutlich komplexer als beispielsweise die biografischen Daten. Zudem traten in diesem Bereich die Folgen des, wie man es nennen kann, ›analogen Erbes‹ der verschiedenen Standards, nach denen solche Daten strukturiert sein können, auf interessante Weise zu Tage. Im Rückblick lässt sich jedenfalls feststellen: Datentransformation ist der beste Weg, Daten – und zwar auch die eigenen – noch einmal ganz neu kennenzulernen.

[15]Zunächst jedoch ein paar Worte zu den anderen Eckpfeilern des Projekts: zu Workflow und technischem Setup sowie – was in einem Projekt, das fremde Daten akkumuliert, von besonderer Bedeutung ist – zur Darstellung der Datenprovenienz.

4. Workflow, Datenformat, technisches Setup und Datenprovenienz

[16]Die zentralen Work Packages des Projekts umfassten:

• Datensichtung
• Erstellung des Datenmodells
• Erstellung des Test-Datensatzes
• Einrichtung der GraphDB-Instanz
• Datenanreicherung / Erstellung von Hilfsdateien
• Datentransformation (Python, XSLT)
• Erstellung des Userinterfaces
• Qualitätskontrolle in mehreren Iterationen

[17]Einige der Work Packages liefen parallel, um enge Feedbackschleifen zu ermöglichen. Zeitgleich mit der Erstellung und Verfeinerung des Datenmodells begann die Erstellung des Test-Datensatzes, einer RDF-Datei im Turtle-Format (.ttl), die das gesamte Datenmodell mit jeweils ein bis zwei Entitäten abdeckte.‍[21] Auf Grundlage dieses Test-Datensatzes wurde schon sehr früh im Projekt mit der Erstellung der Web-Applikation begonnen. Zugleich ermöglichte dieser Testdatensatz das Auffinden von Verbesserungsmöglichkeiten im ursprünglichen Datenmodell. Die frühe Erstellung der grundlegenden ResearchSpace-Applikation erleichterte auch im Folgenden die laufende Qualitätskontrolle der Daten, umso mehr, als dort sowohl die händische Datenexploration als auch SPARQL-Abfragen komfortabel möglich sind. Im Weiteren erfolgten Datentransformation und -Ingest nach jedem Korrekturdurchgang automatisch mittels CI/CD-Workflows; parallel zu den letzten Korrekturdurchgängen in den RDF-Daten wurde auch das User-Interface fertiggestellt.

[18]Weil SemanticKraus die Daten dreier Ausgangsprojekte akkumuliert und diese Ausgangsprojekte wiederum selbst teils Quellen für die bereitgestellten Informationen angeben, wurde die Frage der Datenprovenienz auf zwei Ebenen behandelt: auf der Ebene individueller (etwa Personen-)Einträge und auf der übergeordneten Ebene des Projektdatensatzes. Um für individuelle Einträge die Datenherkunft anzugeben, bieten sich unterschiedliche Methoden an: Am feinkörnigsten ist sicherlich die Angabe der Quelle zur jeweils einzelnen Aussage, zum einzelnen RDF-Triple (was u. a. durch dessen Reifizierung‍[22] erreicht werden kann‍[23]). Einen mittleren Grad an Feinkörnigkeit stellt die Angabe einer Quelle zur (gesamten) betreffenden Entität dar, womit sich die Quellenangabe auf sämtliche Informationen z. B. zur Person bezieht. Am wenigsten exakt wäre eine Angabe auf Höhe des gesamten Registers, die klärt, welche Quellen insgesamt für die Erhebung biographischer Angaben genutzt wurden, ohne genauere Zuordnung. In SemanticKraus wurde für Daten dieser Art der zweitgenannte Weg gewählt: Beispielsweise geben drei Viertel der <person>-Elemente des Registers der Dritten Walpurgisnacht eine Quelle an; diese Quellenangabe wurde mit PROV-O‍[24] modelliert und mit der jeweiligen Person verknüpft.

[19]Auf Ebene der Projekte hat die Angabe der Datenprovenienz zusätzlich zum Modellierungs- auch einen technischen Aspekt: Als Datenformat für SemanticKraus wurde TriG (.trig) gewählt, eine Syntax zur Darstellung von Named Graphs. Dabei handelt es sich um RDF-Datensätze, die in ihrer Gesamtheit ebenfalls durch eine URI vertreten werden, sodass der Datensatz mit Metadaten ausgestattet werden kann – etwa zur Datenprovenienz. Diese Methode wurde im Projekt SemanticKraus angewendet, unter Einbeziehung von Angaben in Prosa zum Ausgangsprojekt und zur Konvertierung (vgl. Abbildung 2).

Abb. 2: Datenprovenienz in SemanticKraus, auf Ebene des Projektdatensatzes (als Named Graph im TriG-Format innerhalb von geschwungenen Klammern) sowie auf Ebene einzelner Entities (unten, die Person wird durch prov:wasDerivedFrom mit der Quelle verbunden). [Grafik: Bernhard Oberreither 2025]

5. Das Datenmodell

[20]Im Bereich der Datenmodellierung fiel die Wahl eines Metamodells schnell auf CIDOC CRM und die damit kompatiblen Modelle – da CIDOC CRM hinsichtlich der Größe seiner Domäne, seiner Verbreitung in der Forschungsgemeinschaft sowie seiner Flexibilität die beste Option darstellt, zudem ausreichend Klassen für die Modellierung der biographischen Daten bereitstellt und das kompatible Modell FRBRoo‍[25] auch die Modellierung von bibliographischen Daten in großer Trennschärfe ermöglicht. Wo FRBRoo aufhörte, dort nämlich, wo es um die Modellierung einzelner Textpassagen mit intertextuellen Verweisen bzw. Personennennungen ging, schloss das ebenfalls CIDOC-kompatible INTRO‍[26] an. CIDOC CRM ist event-zentriert, das heißt: Personen, Objekte etc. werden um die sie verbindenden Ereignisse herum gruppiert; diese Ausrichtung wurde dort, wo es um bibliographische Daten ging, beibehalten: Auch FRBRoo modelliert zum Beispiel das Verhältnis zwischen einem Text und einem Autor als Ereignis (nämlich als Schaffung des Texts). Wo es um (etwa: semantische) Textmerkmale ging, trat die ereigniszentrierte Sichtweise in den Hintergrund zugunsten einer Modellierung, in deren Zentrum das aus INTRO bezogene konzeptuelle Objekt ›Intertextueller Verweis‹ (bzw. im Fall der Personennennung: ›Referenz‹) steht.

[21]Die Modellierung von Personennennungen und intertextuellen Verweisen berührt aufgrund der Nähe zur Textannotation das Thema des Verhältnisses von TEI zu CIDOC CRM. SemanticKraus baut auf einer komplementären Ergänzung von TEI-XML und RDF auf: So werden die TEI-Elemente aus den Registern in RDF rekonstruiert und diese Rekonstruktionen mit Textpassagen im publizierten TEI verlinkt. Letzteres geschieht über IDs, die von TEI grundsätzlich unabhängig sind. Die Wiedergabe der Textstruktur durch TEI bleibt unangetastet, unberücksichtigt bleiben auch die Unterschiede zwischen inline-Elementen im TEI-XML (<quote> und <rs> etwa wurden beide schlicht als ›Textpassage‹ erfasst), etc. Diese Form der gegenseitigen Agnostik zwischen TEI-XML und RDF hat sich als durchaus praktikabel erwiesen.‍[27]

6. Differierende Modellierungen bibliographischer Angaben

6.2 Ausdifferenzierung der ontologischen Ebenen von ›Text‹

[23]Grundsätzlich erwies sich die Repräsentation textbezogener – bibliographischer und intertextueller – Daten als die deutlich komplexere Aufgabe als die Modellierung der biographischen Daten. Dies liegt vor allem daran, dass annotierte Personennennungen meist schlicht eine reale Person referenzieren: »Martin Heidegger« bezieht sich meist auf exakt ein reales Objekt. Bei Sein und Zeit beispielsweise sieht das schon ganz anders aus: Dieser Gegenstand lässt sich ganz unterschiedlich kategorisieren, unter Heranziehung von Begriffen wie Werk, Text, Ausgabe, etc. In Hinblick auf diese Ebenen bibliographischer ›Seinsweisen‹ griff SemanticKraus unter anderem auf die FRBRoo-Klassen ›F22 Self-Contained Expression‹ und ›F24 Publication Expression‹ (in etwa: Text und publizierte Fassung des Texts) zurück.‍[28]

Abb. 3: Das Datenmodell im Großen; ausgespart sind Zeit- und Ortsangaben zu sämtlichen Ereignissen, die als E52 Time-Span bzw. E53 Place modelliert wurden, sowie E42 Identifier, E33 Linguistic Object, E41 Appellation, rdfs:label und rdf:value; zur Datenprovenienz siehe auch Abbildung 2. [Grafik: Bernhard Oberreither 2025]

[24]Die Differenz zwischen traditionellem Anspruch und den Anforderungen der RDF-Konvertierung zeigt sich hier auf recht subtile Art: Verweist etwa eine Textpassage auf eine (auch: strukturierte) bibliographische Angabe, ist den User:innen intuitiv oder aus dem Kontext klar, was gar nicht zwangsläufig spezifiziert ist: ob diese Angabe sich auf einen Text in einer spezifischen Fassung (einer Publikation) oder bloß den Text ›im weiteren Sinn‹ (z. B. als ›Werk‹) bezieht; oder ob mit dem Verweis auf eine Zeitschrift eine Ausgabe der Zeitschrift, einen Artikel daraus oder die Zeitschrift als das der einzelnen Ausgabe hierarchisch übergeordnete ›Werk‹ referenziert wird. Alles dies lässt sich mit TEI explizieren, in der Praxis wird es aber mitunter offen bleiben: vielleicht aus Gründen der Effizienz, oder weil die Datengrundlage nicht ergiebig genug ist, um solche Fragen abschließend zu klären, oder weil der dazu oft nötige Interpretationsschritt im Editionskontext aufgrund methodologischer Überlegungen bewusst vermieden wird.

[25]Im Zuge unserer Datenanreicherung mussten bibliographische Einträge dementsprechend verschiedentlich kategorisiert werden, je nachdem, wie die resultierenden RDF-Entitäten zu klassifizieren waren. Abhängig von Aufwand und Machbarkeit geschah dies entweder im Rahmen der Transformation oder schon im Vorhinein als Anreicherung der Ausgangsdaten mit entsprechenden Attributen. <bibl>-Elemente aus den Rechtsakten wurden beispielsweise im @subtype grob in Texte, publizierte Texte, Periodika, Periodika-Ausgaben und Texte in Periodika ausdifferenziert. Diese Unterscheidungen explizieren, dass die bibliographische Angabe ganz unterschiedliche Modellierungen unter Einbezug ganz unterschiedlicher ontologischer Ebenen von Text und damit in Zusammenhang ganz unterschiedlicher Ereignisse erfordert, die wiederum unterschiedlichen Möglichkeiten der Anbindung an Personen, Orte und Zeitpunkte bieten (vgl. Abbildung 4).

Abb. 4: Die in TEI modellierte bibliographische Angabe eines publizierten Textes und seine ereigniszentrierte RDF-Modellierung darüber (letztere als Visualisierung in ResearchSpace). Der Text selbst ›hat‹ nur Titel und Identifier, die übrigen bibliographischen Angaben liegen in seiner Peripherie, je nach Art des Textes verbunden durch in der TEI-Codierung implizite Ereignisse, aus denen der Text sowie seine publizierte Fassung hervorgegangen sind. [Grafik: Bernhard Oberreither 2025]

[26]Eine andere Ausformung der Differenz zwischen verschiedenen Präsentationsformen bibliographischer Daten abhängig von ihrem Verwendungszweck stellten die ca. 13.000 Texte der Fackel dar. Diese waren nicht als solche erfasst. Was vorlag, war ein umfangreiches XML-File, das ein Inhaltsverzeichnis der gesamten 37 Jahrgänge beinhaltete. Die Ähnlichkeiten zwischen einem Inhaltsverzeichnis und einem Textverzeichnis sind groß, die Unterschiede subtil, aber folgenreich. Dazu gehören allgemeine Merkmale von Inhaltsverzeichnissen wie die Tatsache, dass ihre Einträge zwar mit Von-, nicht aber mit Bis-Seitenzahlen ausgestattet sind: Inhaltsverzeichnisse geben Wegmarken an, ›Pfade‹ zu einem Text, ohne damit notwendigerweise dessen Ausdehnung zu beschreiben (was hingegen ein Textverzeichnis leisten soll). Darüber hinaus mussten die Textgrenzen nicht nur seiten-, sondern absatzgenau erhoben werden, da die Personennennungen sonst nicht treffsicher den jeweiligen Texten zugeordnet werden konnten. Spezifisch für das Fackel-Inhaltsverzeichnis war zudem die Tatsache, dass Autor:innen nicht erfasst (sondern ggf., wenn auch unregelmäßig, Teil des Titels) waren. Wenn man darüber hinaus berücksichtigt, dass der Aufbau der Fackel sich im Lauf der Jahrgänge wiederholt änderte, wie es auch die inhaltliche Ausrichtung der Zeitschrift tat,‍[29] dass die Relationen zwischen den einzelnen Texten dieser Publikation über die bloße Aufeinanderfolge hinaus vielfache Verschachtelungen aufweisen, dass die Texte sich gegenseitig kommentieren und rahmen, was in typographisch nicht einheitlich markierten Hierarchien resultiert – dann wird der Aufwand bei der Überarbeitung dieses XML-Inhaltsverzeichnisses in ein Textverzeichnis deutlich. Er erschien uns insofern gerechtfertigt, als dieses Textregister im Zentrum des Transformationsprojekts SemanticKraus steht: Sowohl die Dritte Walpurgisnacht als auch die Rechtsakten beziehen sich in unzähligen Fällen auf die Texte dieser Zeitschrift.

6.3 URI-Sourcing

[27]Die Abbildung von Daten im Semantic Web zeichnet sich, wie erwähnt, auch noch durch eine weitere Anforderung aus: Jede modellierte Entität muss durch eine URI repräsentiert werden. Das Design dieser URIs kann verschiedenen Maßgaben folgen.‍[30] Im Fall von SemanticKraus waren die folgenden Überlegungen richtungsweisend:

• Eine URI sollte bei jeder Iteration der Datentransformation identisch wiederhergestellt werden können. So kann theoretisch über verschiedene Versionen des Datensatzes hinweg die Verbindung zwischen identischen Entitäten erhalten bleiben. Zufällig generierte URIs‍[31] waren damit ausgeschlossen.
• Eine URI soll möglichst auch dem bloßen Auge ein Mindestmaß an Informationen über die betreffende Entität liefern. Das erleichtert die Lesbarkeit nicht nur während der zahlreichen Datenkontrolldurchgänge, sondern auch danach in der Nutzung. Idealerweise beinhaltet dieses Mindestmaß zum Beispiel einen Hinweis auf die nächstgelegene / -zentralere Entität im Datenmodell (im Fall von SemanticKraus: auf eine Person bzw. einen Text).
• Dennoch sollte die URI keine konkreten Informationen über das angewendete Klassifizierungsschema (die Ontologie) beinhalten – etwa für den Fall des Wechsels des Referenzmodells oder der doppelten Klassifizierung einer Entität.
• Die URIs sollten möglichst ohne großen Aufwand und unabhängig vom Ausgangsdatensatz nach gleichbleibendem Muster erstellt werden.

[28]Ausgangspunkt für das Design der URIs war stets die projekteigene @xml:id der jeweiligen Entität. Zur ›best practice‹ in TEI gehört ohnehin die Ausstattung möglichst jeder Entität mit einer einzigartigen ID. Dabei stellt sich allerdings die Frage: Wo beginnt, wo endet der Begriff ›Entität‹? Eine Person, ein Ort, ein Text – hier ist die Sache einfach, hier handelt es sich jeweils um eine Entität, die jeweils eine ID erhält, dazu nach Möglichkeit Verweise auf Identifier in Normdatensätzen. Die Namen bzw. Titel dieser Personen / Orte / Texte hingegen – handelt es sich auch dabei um eigenständige Entitäten? Die entsprechenden Elemente erhalten in TEI-XML jedenfalls meist keine IDs, auf denen eine URI aufbauen könnte. Auch in RDF ist ihre Eigenständigkeit (d. h.: die Darstellung über eine eigene URI) optional, weil dort Namen und dergleichen theoretisch auch über Datenproperties (wie rdfs:label), also als bloße Datenstrings angegeben werden können. In Normdatensätzen erhalten sie oft keine eigenständige URI.‍[32]

[29]Das Datenmodell von SemanticKraus schrieb im Regelfall die Kreierung einer eigenständigen Entität vor. In vielen Fällen mussten also Entitäten URIs erhalten, die in der üblichen TEI-Modellierung oft implizit bleiben und / oder selbst keine ID haben. Ob eine URI nun durch die nachträgliche Anreicherung der XML-Daten um weitere IDs oder durch die mehrfache Nutzung vorhandener IDs erstellt wurde, hing vom jeweiligen Ort im Datenmodell ab: beispielsweise davon, ob auch anderswo in den Ausgangsdaten auf die betreffende Entität verwiesen wurde. Die Datumsangabe (<date>) eines Zeitungsartikels etwa repräsentiert in TEI den Zeitpunkt des Erscheinens und hat keine eigene ID. Impliziert ist hier jedoch oft die Ausgabe dieses Datums, in der zudem auch andere Zeitungstexte des Datensatzes erschienen sein können. Das RDF benötigt darum eine URI – in unserem Datenmodell: für die ›Ausgabe als Text‹ sowie die ›Ausgabe als Publikation‹, ebenso für das Publikationsereignis und zuletzt für den Zeitpunkt dieses Ereignisses. Zuerst wurde also das entsprechende <date>-Element um ein @key angereichert, dessen Wert für die implizierte Ausgabe der Zeitung stand und aus dem dann die URIs für all die genannten Entitäten generiert wurden – eine gelinde Form des ›tag abuse‹, wenn man so will. Konkret erhielt die ›Ausgabe als Text‹ die URI auf Grundlage des Attributwertes, während die der anderen genannten Entitäten durch entsprechende Erweiterungen erstellt wurden (z. B. »/published-expression«; vgl. Abbildung 5). So ergab sich die oben erwähnte angestrebte Lesbarkeit der URIs und deren Bezugnahme auf benachbarte, zentralere Entitäten ganz von selbst. Zudem wurden so diejenigen <bibl>-Elemente, die Zeitungstexte aus derselben Ausgabe repräsentierten, verbunden – über die aus dem <date> neu geschaffene Ausgabe. (Ähnlich wird bei der Modellierung des Periodikums vorgegangen, das durch den @key im <title>-Element mit @level »j« repräsentiert wird.)

Abb. 5: Die TEI-Modellierung der bibliographischen Angabe eines Zeitungstextes und die Entsprechungen der IDs zu den URIs in der RDF-Modellierung. Gut ersichtlich ist die Generierung zahlreicher Entitäten aus dem @key in <date> zur Repräsentation der Ausgabe eines Periodikums. [Grafik: Bernhard Oberreither 2025]

7. Abschließende Überlegungen

[30]Die bisher angesprochenen Punkte aus dem Projektkontext von SemanticKraus illustrieren auf die eine oder andere Art die eingangs etwas salopp angeführten Problemfelder bei der Transformation von TEI-XML zu RDF. Abschließend können wir das nun – etwas stärker strukturiert – zu einer kurzen Liste von Merkmalen zusammenfassen, Parametern, die für so ein Transformationsvorhaben relevant sind. Diese Liste ist weder vollständig noch allgemeingültig, sie beschränkt sich (zumeist) auf die Ebene der Datenmodelle und setzt zudem ein feinkörniges Ziel-Datenmodell (das etwa auf CIDOC CRM basiert) voraus. Einiges von dem, was nun folgt, ist zudem durch die best practice in der TEI- bzw. der Editor:innen-Community ohnehin abgedeckt; anderes scheint spezifischer für Datentransformations-Vorhaben zu sein. Zu lesen sind diese abschließenden Beobachtungen und Überlegungen als Orientierungshilfe bei der Aufwandsabschätzung vor einer Transformation; womöglich auch als Anregung für Projekte, die sowohl TEI-XML als auch RDF publizieren und dabei Letzteres aus Ersterem gewinnen wollen.‍[33]

[31]Granularität der Modellierung. Der Weg vom XML zum tendenziell feinkörnigeren CIDOC-CRM-Modell umfasst in der Regel ohnehin die Erschaffung zusätzlicher Entitäten in zusätzlichen Klassen; dieser Weg ist umso kürzer – und die Transformation in der Regel umso einfacher –, je feinkörniger die Ausgangsdaten strukturiert sind.

[32]Flache vs. verschachtelte Datenstruktur. Die hierarchische Baumstruktur in XML ist nicht von sich aus geeignet zur Abbildung von n-zu-n-Relationen (beispielsweise: mehrere Texte in einer Publikation, mehrere Publikationen desselben Texts). Nicht, dass TEI nicht Möglichkeiten bieten würde, dieses Problem zu umgehen: Verschiedene Attribute können Verbindungen über die Elementhierarchie hinweg herstellen. Es ist allerdings zu vermuten, dass die hierarchische Struktur in ihrer Anwendung die Praxis der Anwender:innen prägt, sodass eine bibliographische Angabe viel eher als Hierarchie ausgehend von einem Text konzeptualisiert wird denn als Netzwerk gleichberechtigter Entitäten. Im Zusammenspiel mit traditionellen Zitierstandards führt das dazu, dass vermeintlich ›untergeordnete‹ Entitäten – wie die Ausgabe eines Periodikums, die den in Frage stehenden Text enthält – als bloße Anhängsel betrachtet und in der Modellierung vernachlässigt werden. Hierarchischen Verhältnissen dieser Art muss in der Transformation irgendwie begegnet werden. Um dem abzuhelfen, bietet TEI selbst das <relation>-Element, in dem eine Triple-Struktur mithilfe von Pointern, die auf anderswo deklarierte Elemente verweisen, nachgeahmt werden kann. Eine Alternative als gewissermaßen ›entitätenbewusste‹ Modellierung läge in einer verflachten Datenstruktur aufbauend auf der Verknüpfung von hierarchisch nebengeordneten Elementen mittels @corresp oder ähnlichen Attributen. Die Aufteilung beispielsweise der Angabe eines Zeitungsartikels auf drei Geschwister-(<bibl>-)Elemente, die jeweils Text, Ausgabe und Periodikum repräsentieren, würde das Hierarchieproblem entschärfen.

[33]Differenziertheit der Datenfelder. Dieser Punkt beleuchtet die Frage der Granularität noch aus einer anderen Perspektive: Während man in TEI nicht immer veranlasst ist, die im selben Element – etwa <bibl> – angelegten Informationen noch weiter auszudifferenzieren, ist gerade das eine gute Voraussetzung für Transformationsszenarien; @type und @subtype bieten hierfür ausreichend Möglichkeiten.

[34]Identifizierbarkeit der Entitäten. Für die eindeutige Identifikation von Entitäten wird in TEI-XML die Vergabe von eindeutigen Projekt-IDs empfohlen. Aus SemanticKraus-Perspektive ist zu ergänzen: je großzügiger, desto besser. Diese Maßnahme trägt zukünftigen Möglichkeiten Rechnung, auf Grundlage dieser IDs URIs zu vergeben. Darüber hinaus hat sich schon lange die Einbindung von Normdaten-Identifiern durchgesetzt. Diese erleichtern es, auch im Nachhinein die inhaltlichen Schnittmengen zwischen verschiedenen Projektdatensätzen zu erfassen und doppelt vorkommende Entitäten beispielsweise über owl:sameAs zu kennzeichnen (wie das in SemanticKraus gehandhabt wurde). Eine Orientierung an thematisch benachbarten Projekten kann bei der Vergabe von Normdaten-Identifiern darüber hinaus auch dazu anleiten, neben den weitverbreiteten ggf. auch themenspezifischere Normdatensätze zu referenzieren. In Hinsicht auf zukünftige Interoperabilität ist dies besonders ratsam (im Fall von SemanticKraus war es vor allem die PMB, deren Identifier im Zuge der Datenanreicherung ausgegeben und dann bei der Aggregation berücksichtigt wurden).

[35]Referenzierbarkeit der Entitäten. Zu den Benchmarks eines RDF-Datensatzes gehören resolvende URIs. Gerade bei der Transformation von Projektdaten, die auch eine andere Repräsentation als RDF haben, stellt sich darüber hinaus die Frage nach der Möglichkeit, aus dem RDF auf diese Repräsentation zurück zu verweisen, idealerweise via Permalinks. Die Existenz solcher Permalinks entscheidet letztlich darüber, ob die RDF-Datensätze auch Links etwa zu Einträgen in Personen- oder Textregistern des Ausgangsprojekts anbieten können. Im Fall von SemanticKraus war von Vorteil, dass ein Teil der Applikationen (konkret: Dritte Walpurgisnacht) noch in Arbeit war, eine andere (Fackel online) regelmäßige Updates erhält, sodass die nachträgliche Einführung von Permalinks für Register-, aber auch inline-Elemente keine Hürde darstellte. So konnten fast alle Entitäten der zentralen Klassen mit E42 Identifiern ausgestattet werden, deren rdf:value einen Link ins Ausgangsprojekt beinhaltete.