Das FreiDi-Datenmodell
Juli 2014
Einleitung
Der folgende Text bietet eine erste Übersicht über das gegenwärtig in der Umsetzung befindliche Datenmodell von Freischütz Digital. Im vorliegenden ersten Release finden sich noch keine entsprechend ausgezeichneten Daten. Um etwaigen Änderungen am Konzept besser Rechnung tragen zu können, wurde auf die Berücksichtigung von Beispielen in dieser Einführung verzichtet. Dieser Text richtet sich ausdrücklich an Personen mit weitreichenden Kenntnissen im Bereich der Datenmodellierung bzw. Musikcodierung. Obwohl eine endgültige Evaluierung des gewählten Modells sicherlich erst mit Fertigstellung weiterer Codierungen möglich ist, soll dieser Text bereits einen Austausch über die zugrunde gelegten Konzepte ermöglichen.
Das Datenmodell von Freischütz Digital soll eine angemessene Codierung sowohl der Entwicklung des Werktextes in den überlieferten Quellen, aber auch der Ausprägungen des überlieferten Textes erlauben. Als angemessen ist dabei eine zumindest teilweise diplomatische Erfassung der Handschriftendetails zu verstehen: Während auf die Erfassung der präzisen Position einzelner Zeichen verzichtet wird, sollen vor allem unpräzise gesetzte Bögen, crescendo-Gabeln und ähnliche Zeichen, die individuelle Schreibart von Dynamikangaben sowie Artikulationszeichen wie Punkte und Striche möglichst getreu erfasst werden, um nachgelagerten Fragestellungen ein ausreichend detailliertes Datenmaterial zur Verfügung stellen zu können. MEI bietet grundsätzlich alle dafür erforderlichen Möglichkeiten. Angesichts der Vielzahl der zu kollationierenden Quellen erweist sich allerdings die regulär vorgesehene Verzeichnung von quellenübergreifender Varianz als unpraktisch, da bereits marginale Unterschiede etwa in der Platzierung eines Bogens zu einer „Verzweigung“ der Codierung im Sinne der parallel segmentationführen würde Die Umsetzung des formulierten Anspruchs der Quellentreue würde somit zu stark redundanten Daten führen, deren Lesbarkeit zumindest für eine manuelle Bearbeitung erheblich eingeschränkt wäre. Die alternative Möglichkeit, alle Quellen nur für sich zu betrachten und in jeweils eigenen Dateien zu erfassen, bietet den Vorteil, in einer diplomatischen Codierung nur die Unsicherheiten eines einzigen Dokuments berücksichtigen zu müssen. Allerdings vergrößert sich bei diesem Ansatz das Problem der Redundanz, da alle gleichbleibenden Anteile für jede Quelle separat hinterlegt werden müssen. Da diese Daten erst über eine separate Konkordanz von außen inhaltlich verknüpft werden könnten
Dagegen nutzt das im Rahmen des Projekts entwickelte Core -Modell die jeweiligen Vorteile beider Verfahren und sucht durch die Aufteilung des gesamten Datensatzes in mehrere Dateien zugleich Redundanzen weitgehend zu umgehen. Zusätzlich integriert es durch eine – großenteils automatisierbare – Verlinkung eine Konkordanz der Daten, so dass eine Synopse von Differenzen im Werktext vor dem Hintergrund der gemeinsamen Codierung identischer Teile verbunden werden kann mit der Erfassung diplomatischer Aspekte der Einzelquellen. Im nachfolgenden Kapitel wird dieses Core -Modell ausführlich beschrieben und anschließend werden die im Rahmen von Freischütz Digital genutzten Arbeitsabläufe zur Umsetzung des Modells dokumentiert.
Das Core-Modell
Das Core-Modell sieht eine Aufteilung der Codierungen in mehrere Dateien vor:
1. In der eigentlichen Core-Datei wird der "wesentliche" Notentext des betrachteten Werkes – hier Webers Freischütz – hinterlegt. Sie umfasst die gesamte Bandbreite der Überlieferung über alle betrachteten Quellen hinweg und ist insofern nicht mit einem herkömmlichen Edierten Text zu vergleichen. Die Core-Datei stellt die Summe aller – den jeweiligen Quellen zugeordneten – Lesarten und Varianten dar. Durch die strukturierte Erfassung der Unterschiede mittels des MEI-Moduls critApp hat die Core-Datei bereits editorischen Charakter.
Im Core werden dabei nur die wichtigsten Parameter des Notentextes hinterlegt, d.h. Tondauern und -höhen, aber auch Bögen und Artikulationsbezeichnungen. Allerdings werden diese in normalisierter bzw. nicht-diplomatischer Form codiert, d.h. es werden keine Angaben zu Halsrichtungen, individuellen Schreibweisen oder unpräzise gesetzten Zeichen hinterlegt.
2. Für jede betrachtete Quelle wird zusätzlich eine separate Source-Datei angelegt, die sowohl das Dokument als solches (das Faksimile) als auch den zugehörigen und damit verknüpften codierten Werktext erfasst. Grundsätzlich wird zu jedem mei:staff-Element des codierten Werktextes der entsprechende Ausschnitt im Faksimile mit einem zugehörigen mei:zone-Element referenziert. Weitere Elemente wie Satzbezeichnungen oder andere textuelle Eintragungen (mei:dir etc.) können nach Bedarf mit entsprechenden Ausschnitten verknüpft werden.
Der Notentext selbst wird so wiedergegeben, wie er in der jeweils vorliegenden Quelle zu finden ist, d.h. es werden nur deren Varianten bzw. Lesarten codiert. Ziel dieser Codierung ist es, die Quelle möglichst getreu wiederzugeben, d.h. inklusive diplomatischer Details. Wie erwähnt, wird dabei zwar auf exakte graphische Platzierungen der Zeichen verzichtet, Positionierungen werden aber dann in der Codierung erfasst, wenn sie Unsicherheiten in der Interpretation hervorrufen – etwa im Fall von Bögen, die zwischen zwei denkbaren Noten beginnen bzw. enden (s.u.).
Damit liegen zunächst zwei, aus XML-Sicht vollständige MEI-Bäume vor, die
jeweils komplette Codierungen einer Fassung bzw. der Gesamtsumme aller Fassungen
enthalten. Um nun eine Redundanz der Daten zwischen Core und
Sources zu vermeiden, werden in den Sources lediglich die
diplomatisch bzw. typografisch relevanten Informationen abgelegt, also
Halsrichtungen, Ausrichtung von Bögen etc., während die "wesentlichen" Bestandteile
zunächst unberücksichtigt bleiben. Zusätzlich wird für jedesElement ein
Verweis auf das jeweils entsprechende Objekt in der Core-Datei angelegt.
Dazu wird das MEI-Attribut @sameasgenutzt, es wird also eine
Gleichheit der beiden Elemente konstatiert. In den MEI-Guidelines heisst es
zu @sameas: „[it] points to an element that is the same as the current
element but is not a literal copy of the current element.“
Wesentliche Unterschiede der erfassten Texte lassen sich unmittelbar über mei:app-Elemente und ihre Kindknoten in der Core-Datei ablesen, während sich Unterschiede in den typographischen Details durch einen Abgleich der auf die gleiche Note verweisenden Elemente in den Source-Dateien untersuchen lassen. Die vorgenommene Differenzierung führt damit lediglich zu einer Priorisierung der wesentlichen Unterschiede, nicht zum Verzicht auf die Erfassung von in der Regel nachrangigen Unterschieden.
Eine Besonderheit ergibt sich dabei durch die häufig alternierende Notation von mehrfach besetzten Holzbläsern und anderen Instrumenten, die innerhalb eines Systems teils als zwei separate Stimmen, teils aber auch akkordisch notiert werden. Die Schreibweise dieser Systeme variiert häufig zwischen verschiedenen Quellen, ohne dass damit tatsächlich ein Bedeutungsunterschied zu konstatieren wäre. Im Rahmen von Freischütz Digital wird in den Source-Dateien der jeweilige Befund der Quelle wiedergegeben. In der Core-Datei wird dagegen eine normalisierte Form vorgehalten, bei der alle mehrfach besetzten Instrumente vollständig in einzelne Stimmen aufgeteilt sind, d.h. jede akkordische Schreibweise aufgelöst wird. Die Noten der einzelnen Quellen verweisen dann jeweils auf die ihnen zugehörige Töne, unabhängig vom in der Quelle zugeordneten mei:layer. Diese Form der Codierung, die u.U. keiner der vorhandenen Quellen entspricht, eignet sich aber als Vorlage für potentielle Stimmenauszüge. Dieser Zusatznutzen ist allerdings in erster Linie als Vorbereitung für spätere Projektphasen bzw. eine weiterführende Nutzung der Daten anzusehen.
Behandlung von Korrekturen und anderen textgenetischen Prozessen
Editorische Sachverhalten werden in den Core- und Source-Dateien durch die MEI-Module editTrans und critApp erfasst. Dabei können doppelte Codierungen entstehen, die aber durch ihre verschiedenen Perspektiven nicht als redundant zu verstehen sind.
Eine Korrektur wird innerhalb einer Quelle als mei:subst erfasst, mit den beiden Kindelementen mei:del und mei:add. In der Core-Datei wird derselbe Sachverhalt ebenfalls aufgeteilt, dort aber nicht in einem mei:subst, sondern in einem mei:app mit zwei mei:rdg-Kindelementen hinterlegt. Während in den Quellen so der prozesshafte Charakter der Ersetzung im Vordergrund steht, werden im Core alle Textschichten unabhängig von ihrer Herkunft aus einer bestimmten Quelle gleichartig behandelt. Im Falle solcher Eingriffe wird im Rahmen von Freischütz Digital abweichend von der gängigen editorischen Praxis versucht, zwei Stadien möglichst durchgängig für alle betrachteten Kopien zu erfassen: einerseits – wie gewohnt – die von Weber autorisierte Version des Textes (d.h. inklusive der von ihm vorgenommenen Änderungen am Text, die selbstverständlich als solche erfasst werden), andererseits aber auch der aktuelle Zustand der jeweiligen Quelle, dass heißt inklusive aller im Zuge von späteren Aufführungen oder anderen Gelegenheiten vorgenommenen Eintragungen, Streichungen oder sonstigen Anpassungen. Eine Binnen-Differenzierung dieser letztgenannten Eingriffe wird aufgrund der Zielsetzung von Freischütz Digital nicht vorgenommen; lediglich die genutzten Schreibmittel (und wo erfassbar Schreiber) werden separat erfasst. Eine Ausnahme bildet hier die Abschrift KA2, deren teils mehrfache Umarbeitungsprozesse gut nachvollziehbar sind und die deshalb exemplarisch in einigen Sätzen nachgezeichnet werden sollen. Darüber hinaus ist für Freischütz Digital keine Erfassung von späteren Texteingriffen und -änderungen vorgesehen.
Handhabung von ControlEvents, d.h. Bindebögen, Dynamikangaben etc.
Während die Aufteilung der Informationen auf Core- und Source-Dateien im Fall von Events, also Noten, Pausen, Akkorden etc., meist zu einer einfachen 1:1-Entsprechung der jeweiligen Elemente führt, ist die Handhabung sogenannter ControlEvents je nach Situation deutlich komplexer und erfordert eine etwas andere Handhabung. Im einfachsten Fall handelt es sich z.B. um einen Bingebogen, dessen Anfang und Ende jeweils eindeutig und zweifelsfrei einer Note zugewiesen werden kann. In diesem Fall wird sowohl im Core als auch in den betreffenden Source-Dateien ein mei:slur-Element angelegt. In der Core-Datei werden nun Start- und Endnote des Bogens über Referenzen mittels der Attribute @startid und @endid hinterlegt, die jeweils die @xml:id der entsprechenden Note (bzw. des entsprechenden Akkords) referenzieren. In den Sources, welche wiederum über @sameas den Bezug zum Core herstellen, werden nun mit @place und @curvedir die Position des Bogens über bzw. unter dem System sowie dessen Richtung hinterlegt. Komplexer wird die Situation bei Bindebögen, deren Enden unpräzise platziert sind. Der Anspruch von Freischütz Digital ist es, die in den Quellen vorhandenen Unsicherheiten zu bewahren, also sowohl die exakte Position des Zeichens als auch sämtliche (unabhängig von der Berücksichtigung weiterer Quellen) daraus resultierenden denkbaren Interpretationen der Zuordnung, da sich nur unter Berücksichtigung dieser Unsicherheiten Kopierfehler auch auf ihre Ursachen hin untersuchen lassen.
In diesem Fall werden in der Source-Datei zunächst die Attribute @tstamp und / oder @tstamp2 zugefügt, welche eine Zählzeit für Bogenanfang bzw. -ende angeben. Die dort einzutragenden Werte sind nicht absolut zu sehen und sollten gerade nicht den Zählzeiten vorhandener Noten entsprechen (in diesem Fall wäre ihre Erfassung obsolet), können aber z.B. eine Zuordnung des Bogens zum Taktstrich zwischen zwei Takten andeuten. Zusätzlich wird das entsprechend ausgezeichnete mei:slur-Element in ein mei:orig geschachtelt, welches wiederum durch ein mei:choice umschlossen wird. Dieses bekommt nun für jede gültige Interpretation des Bogens (also auch wenn der Befund lediglich eine einzige Interpretation zulässt) ein weiteres mei:reg-Kindelement, welches ein entsprechendes mei:slur enthält. Das den Befund wiedergebende mei:slur innerhalb des mei:orig enthält in diesem Fall keinen Verweis auf ein entsprechendes mei:slur-Element innerhalb der Core-Datei mittels @sameas. Vielmehr verweisen die in mei:reg hinterlegten mei:slur auf entsprechende Bindebögen in der Core-Datei, die dann wiederum über @startid und @endid eindeutige Zuordnungen zu den jeweiligen Noten herstellen.
Eine Gewichtung dieser Alternativen hinsichtlich ihrer Wahrscheinlichkeit erfolgt dabei nicht in der Core-Datei, sondern in der mei:choice innerhalb der zugehörigen Source-Datei. Die dort vorgehaltenen mei:reg-Elemente werden um das Element @cert (certainty) angereichert, für welches MEI die Werte „high“, „medium“, „low“ und „unknown“ vorgibt. Eine inhaltlich gerade noch zu vertretende Interpretation bekommt dabei den Wert „low“ zugewiesen. Ab dieser Wahrscheinlichkeit werden alle Interpretationen in gleicher Weise in den Core übernommen. Es können mehrere Interpretationen mit gleicher Wahrscheinlichkeit hinterlegt werden, also z.B. zwei als in gleicher Weise @cert=„medium“.
Allerdings führt dieses Modell dazu, dass in der Core-Datei ggf. zwei oder mehr unterschiedliche Interpretationen hinterlegt werden müssen, die aus nur einer Quelle stammen. In der Core-Datei werden solche Unterschiede grundsätzlich immer mittels mei:app bzw. darin liegender mei:rdg-Elemente erfasst. Diese mei:rdg-Elemente referenzieren über @source die Quelle, deren Text sie wiedergeben. Üblicherweise sieht MEI vor, dass jede Quelle in nur einem dieser mei:rdg-Elemente thematisiert wird. Eine weitere Binnendifferenzierung wird dann über mei:choice-Elemente innerhalb dieses einen mei:rdg vorgenommen. Allerdings würde die Anwendung dieses Modells das gesamte Core-Modell von Freischütz Digital ad absurdum führen, da auf diese Weise nicht mehr die Gemeinsamkeiten in der Core-Datei zusammengefasst werden, sondern eine exakte Wiedergabe der einzelnen Quellen bereits hier stattfinden müsste. Inhaltlich ist das oben skizzierte Verhalten – es gibt bei Bedarf mehrere mei:rdg pro Quelle – durchaus korrekt: Die Überlieferung des Freischütz bietet zwei Lesarten des Bogens, die aufgrund einer unpräzisen Schreibweise beide aus einer Quelle gelesen werden können. Selbstverständlich schließen sich diese gegenseitig aus (wie es für mei:rdg ohnehin definiert ist). Allerdings kann über diese Doppelerfassung gerade im Bezug zu anderen Quellen nachvollzogen werden, wie solche unpräzisen Schreibweisen zu Textfehlern (im weitesten Sinne des Wortes) führen, und damit letztlich die Filiation der Quellen besser nachvollzogen werden. Dennoch sei nochmals ausdrücklich darauf verwiesen, dass im Falle von mehreren mei:rdg, die (u.a.) auf die gleiche Quelle verweisen, sich diese Lesarten gegenseitig ausschließen und immer nur genau eine als gültig betrachtet werden kann. Nur so wird die wechselseitige Schachtelung von mei:choice bzw. mei:app-Elementen vermieden, wodurch die vorhandenen Textfassungen besser sichtbar bleiben, unabhängig von der sie jeweils enthaltenden Quelle.