Es besteht eine offensichtliche Beziehung zwischen Formen/Denotatoren und den Datenmodellen der Datenbank-Theorie. Ich will das hier kurz streifen, damit man sieht, wie eng die Themenkreise verwandt sind. Es geht mir aber auch darum zu zeigen, was man überhaupt unter "Datenbank" (=DB) zu verstehen hat. Dieser Begriff kommt ja überall vor heute.
| Man kann Forschung ohne (eigene oder fremde) Datenbanken nicht mehr ausüben. Es ist für angehende MusikwissenschaftlerInnen am Anfang des 21. Jarhhunderts unverzichtbar, Datenformate von informationstechnologischen Datenbanksystemen lesen und schreiben zu können. Dies gilt uneingeschränkt für alle Bereiche, insbesondere aber auch für die historische und ethnologische Arbeit, welche ja beide massiv auf virtuosem Quellen-Surfen basieren (sollten). |
Bemerkung für Philosophen
Es geht mir aber auch darum zu zeigen, dass sogenannte universelle Konstruktionen aus der modernen Mathematik (wie etwa Produkte, Coprodukte, Potenzobjekte) der Datenbank-Theorie Pate stehen, und dass evtl. eine Einbindung dieser Perspektive in die DB-Theorie nützlich wäre. Ich möchte dabei betonen, dass die hier vorgestellten Begriffe ganz harmlose, aber "typische" Spezialfälle sind einer mathematisch viel anspruchsvolleren Theorie der Formen, welche auf der mathematischen Theorie der Kategorien und der Moduln aufbaut. Sie hat in den letzten Jahren zu vereinheitlichten Theorien der Logik und Geometrie geführt, die den Namen Topos-Theorie trägt. Sie wird in der modernen Datenbank-Theorie verwendet. Wir wollen dies hier nur nebenbei erwähnen, ohne Abschreckung zu provozieren!
Ende Bemerkung für Philosophen
Es ist sicher kein Zufall, dass gerade diese tiefliegenden Strukturfragen in der Musik auftreten; dies belegt unsere anfängliche These, dass Musik in ihrer Komplexität eine herausragende Rolle spielt. Dies sollte aber nicht vor allem als Anregung zur Datenbank-Theorie oder Mathematik verstanden werden, sondern zur Selbstreflexion:
| Die Musikwissenschafter müssen sich bewusst werden, dass sie ihre eigene Wissenschaft nicht mehr ohne ernsthafte Schäden an den Knowledge Sciences vorbei treiben können. |
Wir erinnern daran, dass Datenbanken klassisch bei Bibliotheken auftreten. Bild 68 zeigt eine relationale Datenbank mit Büchern, Lesern und der Relation der Ausleihe: Welches Buch (durch die Inventarnummer gekennzeichnet) wurde von welchem Leser (durch die Lesernummer gekennzeichnet) bis wann ausgeliehen.
Bild 68: Relationale Datenbank mit Büchern, Lesern und Ausleihen. (Aus: G. Vossen: Datenmodelle, Datenbanksprachen und Datenbank-Management-Systeme. Addison-Wesley, Bonn 1994)
In der Datenbank-Theorie wird diese Situation auch graphisch dargestellt, siehe Bild 69
Bild 69: Abb. 5.2 und 5.3 und 5.5 bei Vossen
Diese Schematik entspricht einer "Entity-Relation-Deklaration". Abbildungen 5.2 und 5.3 in Bild 69 zeigen die Entity-Deklarationen für Leser und Buch. Es handelt sich um eine Art Charakterisierung der Begriffe "Leser" und "Buch" (in Rechtecken) durch eine Reihe von Attributen (in Kreisen). Ein doppelter Kreis wie bei Buch, "Atr" = Autoren, bezeichnet ein mehrwertiges Attribut. Das heisst, dass ein Buch mehrere Autoren haben kann, während es z.B. nur einen Titel hat. Das Attribut "Verlage" verweist wieder auf Attribute "Name" und "Orte" und heisst deshalb zusammengesetztes Attribut.
Ein Entity ist dann einfach eine bestimmte Belegung dieser Attribute mit entsprechenden Werten, Bild 68 zeigt eine Liste von Leser- und Buch-Entities.
Die Relation (Relationship) der Ausleihe ist dann eine Kollektion von Entity-Tripeln des Types (Buch, Leser, Rückgabedatum (=RDat)), welche -- wie in Bild 68 gezeigt -- den Zustand der Bibliothek zu einem bestimmten Zeitpunkt angeben.
Bemerkung für Informatiker
Formal wird der Begriff "Buch" als Entity-Deklaration aufgefasst.X = Menge von Attributen Ai, die verschieden notiert werden:
(K ist eine Teilmenge von X, die als Schlüssel fungiert und uns hier nicht weiter interessiert.)
Unser Beispiel in Bild 68 und Bild 69:
Buch = ({InvNr, {Autor},Titel, Verlag(Name,Ort),Jahr}, {InvNr})
Was heisst diese Kategorisierung?
- einwertige Attribute Ai: eine Wertemenge W(Ai) an
- mehrwertige Attribute {Ai}: eine Wertemenge W(Ai) an
- zusammengesetzte Attribute Ai(B1,B2,...,Bk) für jedes Bj eine Wertemenge W(Bj) an.
Dann setzt man fest, dass die "Domains" der Deklaration das sind:
- einwertige Attribute: dom(Ai) = W(Ai)
- mehrwertige Attribute: dom(Ai) = 2^W(Ai) (= Potenzmenge von W(Ai))
- zusammengesetzte Attribute: dom(Ai) = W(B1) x ... W(Bk)
W(InvNr) = int(15) (bis max 15 stellige natürliche Zahl); dom(InvNr) = W(InvNr).
W(Autor) = char(20) (bis max 20 stellige Character-Strings); dom(Autor) = 2^char(20) .
W(Name) = char(20), W(Ort) = char(10), dom(Verlag) = char(20) x char(10).
Wir sehen jetzt, dass im wesentlichen die mehrwertigen Attribute unserem Powerset-Typ entsprechen, die zusammengesetzten Attribute dem Product-Typ, die einwertigen Attribute den Simple-Typen, aber die Synonym und die Coproduct-Typen treten nicht auf.
Ein Entity ist in der Entity-Relationship-Theorie ein Element des kartesischen Produktes dom(A1)x....dom(An).
Ein Entity-Set E_t ist dann eine Menge von Entities, wobei man jeweils noch die Zeit t angibt, zu der das Repertoire statthat.
Ein Relationship ist ein Tripel, (E_Buch, E_Leser, rd) bestehend aus je einem Entity E_Buch, E_Leser der Entity-Sets für die Entity-Deklarationen "Buch" und "Leser", sowie einem Attribut rd für das Rückgabedatum RDat.
In der Entity-Relationship-Theorie ist eine Datenbank zu den vorgegebenen Deklarationen eine Menge von Relationships.
Alle Strukturen der Entity-Relationship-Theorie treten auch auf in der Denotator-Formen-Sprache. Aber man sieht, dass die Entity-Relationship-Theorie einen mathematisch unfertigen Formalismus aufweist: Eine Entity-Deklaration erscheint nicht als zusammengesetztes Attribut, und ein Entity-Set erscheint nicht als mehrwertiges Attribut, obwohl es das formal könnte und sollte, d.h., das System ist formal nicht fertiggedacht, und die rekursive Struktur ist auch nicht sauber und explizit deklariert. Das ist zwar aus der praktischen Ausrichtung der Datenbank-Theorie erklärbar, aber eine begriffliche Aufbereitung wäre nützlich. Wir haben dies ja gerade bei der Entwicklung musikalischer Datenmodelle beobachten können.
Ende Bemerkung für Informatiker
Datenbanken sind also durchaus Gefässe, wie wir sie mit den Formen und Denotatoren kennengelernt haben, letztere werden in der Tat auch im Datenbanksystem PrediBase in der Plattform RUBATO realisiert. Wichtig dabei ist aber, dass Denotatoren und Formen äusserst flexibel sind gegenüber normalen Datenbanken. Die Benutzer und Benutzerinnen können in PrediBase jederzeit neue Formen einführen, eine Möglichkeit, die bei normalen Datenbanksystemen nicht gegeben ist. In einem Bibliotheks-Datenbanksystem etwa darf man ja nur fest definierte Formate "ausfüllen". Die Musik fordert aber genau hier uneingeschränkte Offenheit.
Das MuseData-Projekt: Sonne oder Satellit?
Ein interessantes Beispiel dazu ist MuseData. Seit 1984 wird am CCARH ( = Center for Computer Assisted Research in the Humanities) an der Standford-University durch Eleanor Selfridge-Field und Walter B. Hewlett versucht, eine umfassende Sprache für die Beschreibung von Musik auf den Ebenen: Partitur, Sound, Analyse zu entwickeln. Siehe unter
Die Sprache heisst MuseData und ist nicht plattformabhängig, sondern als ASCII-Format (normale Text) implementiert. Es ist die Politik, die Übersetzung dieses Formats in spezifische Plattformen zu fördern oder selber zu entwickeln.
In einem Artikel der CCARH-Zeitschrift Computing in Musicology (vol.9, 1994) wurde das MuseData-System von Eleanor Selfridge-Field vorgestellt. Darin ist eine Reihe von Mängeln anderer Systeme aufgezählt. MuseData stellt sich dar als Sonne, um die diverse grössere oder kleiner Planeten kreisen. Nach einem Selektionsverfahren hat die MuseData-Redaktion die Formate DARMS, SCORE, MIDI und Kern als Planeten ausgewählt.
MIDI haben wir eben angeschaut, Score ist eher auf der Ebene der graphischen Partitur-Darstellung von Noten spezialisiert, und Kern unterstützt auch analytische Belange. Wir wollen aber nicht auf all diese Formate eingehen.
Hier sind einige Vergleichstabellen (Bilder 70-73) zwischen der "Sonne" und den "Planeten": es werden jeweils die Eigenschaften in der linken Kolonne untersucht und auf den diversen Formaten ausgewertet.
Bild 70: Vergleich MuseData und andere Formate I
Bild 71: Vergleich MuseData und andere Formate II
Bild 72: Vergleich MuseData und andere Formate III
Bild 73: Vergleich MuseData und andere Formate IV
Man sieht sofort, wie schlecht MIDI als universelles Format (was es ja nie sein wollte) wegkommt.
Hier ein Beispiel (Bild 74) der Codierung von Musikdaten mit MuseData, ein Ausschnitt aus einer Mozart-Klaviersonate KV331:
Bild 74: MuseData von Mozart-Sonate
Man erkennt hier die umständliche Art der Notation, falls Töne gleichzeitig anfangen (back!).
Wie auch immer diese Darstellung Allgemeinheit beansprucht, sie hat den Nachteil, dass sie zu jenen Formaten gehört, die eine definitive Auswahlmenge an Objekt-Typen anbietet. Wenn man hier etwa die Utai und Fushi des Noh-Theaters einfügen wollte, wäre man verlegen, zumindest in der expliziten Namensgebung für die entsprechenden Prädikate (siehe Bild 75).
Bild 75: Fushi-Zeichen im Utai-Gesang des Noh-Theaters
Und es wäre definitiv unmöglich, die umfassende Partiturvernetzung im bipolaren Konzept der Nohgaku-Kunstform in MuseData zu erfassen, welche besteht aus Noh und Kyogen (Noh als die ernste, tragende Seite, Kyogen die hellere Seite eines "Intermezzo"; siehe Kunio Komparu: Noh. Weatherhill/Tankosha, NY 1983), wie in Bild 76 schematisch gezeigt,
Bild 76: Der bipolare Organismus des Nohgaku
Das denoteX-Format für ASCII-Kommunikation, Beispiele und Übungen
Das Folgende ist zwar äusserlich eine formale Angelegenheit, es ist aber wesentlich, die exakten Begriffe auch exakt zu notieren. Wir wollen dies hier einfach einüben, auch wenn man in vielen Fällen von der formalen Explikation absehen wird. Aber man muss, wenn es darauf ankommt, imstande sein, die geforderte Präzision an Begriffsbildung zu liefern. Denn ein wissenschaftlicher Dialog kann nicht ernsthaft geführt werden, wenn man die Details nicht im Griff hat.Und es sollte eine angemessene Formalisierung nicht als Verzicht auf Inhalte gedeutet werden, sondern als Präzisierung des Ortes und der Art und Weise, wo und wie Inhalte auftreten. Aus der Gewohnheit, mit dem Formalismus der Partitur-Notation umzugehen, dürfte diese Arbeit eigentlich keine Mühe bereiten.
Wir schreiben von jetzt an die Formen und Denotatoren als Texte auf wie folgt. Dieser Standard heisst denoteX und ist aus der aktuellen Forschungsarbeit, die in Zusammenarbeit mit der Forschungsgruppe Mathematische Musiktheorie an der TU Berlin betrieben wird, entstanden. Download von hier. Wir werden auf den Zusammenhang mit der Software-Plattform RUBATO weiter eingehen im nächsten Abschnitt.
Eine Form wird in denoteX so definiert:
| Name:.Typ(Koordinator); |
(Das Semikolon am Schluss der Definition ist praktisch, damit man immer weiss, wann die Definition beendet ist, denn oft zieht sie sich bei langen Namen über mehrere Zeilen hinweg.)
- ihr Name ein ASCII-String (anschaulich gesagt: ein gewöhnliches Wort)
- ihr Typ eines der folgenden Symbole
Simple, Syn, Product, Coprodut, Powerset
Typ = Simple; dann ist der Koordinator eine der folgenden vier Mengen: Boole, <ASCII>, Z, R;
Typ = Syn oder Powerset; dann ist der Koordinator der Name F einer anderen Form;
Typ = Product (Limit) oder Coproduct (Colimit); dann ist der Koordinator eine Folge F1,F2,...Fn von Namen von Formen.
Ein Beispiel für die Form einer Klaviernote:
Einsatzzeit,
Tonhöhe,
Lautstärke,
Tondauer
Übung 1: FM-Object
Wir haben früher die FM-Darstellung von Sound-Objekten diskutiert. Man übersetze diese Darstellung, welche wir graphisch in Bild 67 dargestellt haben, nach denoteX; es steht dabei f für "Float", d.h. für den Koordinator R.
Übung 2: Buch
Man schreibe "Buch" als Form in denoteX hin, wobei ein Buch eine Menge von Autoren, einen Titel, einen Verlag, ein Erscheinungsdatum hat, ferner soll es eine Menge von Kapiteln haben, die die Form "Kapitel" haben, welche aber beliebig wieder aus Unterkapiteln bestehen können. Ein Kapitel soll ferner einen Titel, einen Nummer, einen Text haben.
Denotatoren sind in denoteX wie folgt definiert:
| Name:@FORM(Koordinaten); |
- Name = ASCII-String
- FORM = der Name einer definierten Form
- Koordinaten = x, wobei x je nach Form so aussieht:
FORM :.Simple(F), dann ist x ein Element von F
FORM:.Syn(F), dann ist x ein Denotator von F
FORM:.Powerset(F), dann ist x = {x1,x2,...,xk}, xi = Denotator von F
FORM:.Product(F1,...,Fn), dann ist x = (x1,x2,...,xn), xi= Denotator von Fi
FORM:.Coproduct(F1,...,Fn), dann ist x ein Denotator von einem Fi
1. Um bei Coprodukten zu sagen, von welchem Cofaktor eine Koordinate x stammt, schreibt man auch i>x.
2. Oft ersetzt man die Koordinaten durch ihre Namen, wenn das möglich ist, und schreibt dann x:, um zu sagen, dass x nur der Name und nicht ein ganzer Denotator ist.
Übung:
Man schreibe explizit einen FM-Object-Denotator hin.
Der RUBATO-Kontext
Die Formen und Denotatoren sind insbesondere im Kontext der Software-Plattform RUBATO unabdingbar. Die Software-Plattform RUBATO lief anfänglich auf dem OS NEXTSTEP 3.3, ist auf Mac OS X portiert worden und ist über das Internet frei verfügbar unter
RUBATO® ist eine modulare Software, siehe Bild 77 für dessen Flussdiagramm, welches die Implementierungsphase bis 2003 mit einschliesst; vergleiche Bild 15 für den Stand von 1996. RUBATO besteht aus einer Rahmen-Applikation, der dynamisch (also während die Rahmensoftware schon geladen ist) Plug-Ins, sogenannte Rubetten, zugeladen werden können für Analyse, Performance, Komposition und andere Aufgaben.
Bild 77: RUBATO-Schema der Implementierungsphase 2003
Es existieren gegenwärtig drei Rubetten für motivische, rhythmische und harmonische Analysen sowie eine PerformanceRUBETTE mit fünf Performance-Operatoren zur Gestaltung von Aufführungsinterpretationen (=Performances). Das RUBATO-interne Datenbanksystem PrediBase sollte via eine PapaRUBETTE mit anderen wichtigen Musik-Formaten kommunizieren (Papa: der Papst, na ja, Konvertieren war ja mal seine Stärke). Kommunikation mit MIDI und Scorefile ist seit 1996 implementiert. Das PrediBase-System kommuniziert wie die für die Naturwissenschaftler inzwischen allgemein akzeptierte TeX-Sprache auf ASCII-Text-Basis im Format denoteX.
Die RUBATO-Rahmen-Applikation dient hauptsächlich der internen Kommunikation und Verwaltung zwischen den diversen Rubetten und ihren Outputs (insbesondere Gewichts- und Stemma-Dateien, siehe mehr dazu in Kapitel 8). Daher ist die gemeinsame Datenbanksprache essentiell. Nur so kann garantiert werden, dass der Dialog zwischen allen bestehenden oder künftigen Moduln konsistent geführt werden kann.
RUBATO wurde von 1998 bis 2003 an der Technischen Universität Berlin in einem grossen Projekt der VW-Stiftung weiterentwickelt, neben anderen Entwicklungs- und Forschungsgruppen am IRCAM in Paris, an der Forschungsstelle für Musik- und Medientechnologie der Universität Osnabrück, am Mathematischen Institut der UNAM in Mexico City. Für Anbindung an direkte Internet-Kommunikation über Java-gestützte Browser wurde am Multimedia Lab von Stefan Göller in seiner Dissertation der PrimaVista-Browser entwickelt. Am mathematischen Institut an der Universität Zürich befasste sich Chantal Buteau mit der Theorie der Motive, welche für neuen analytischen Rubetten die Grundlage bilden wird. Und am Multimedia Lab haben Stefan Müller und Gérard Milmeister sich mit RMI-Verteilungen befasst und ein "Distributed RUBATO" implementiert, siehe auch deren paper "Distributed RUBATO".
Bild 77a: Distributed RUBATO 2004
Im Sommer 2006 wurde eine neue Version von RUBATO als "RUBATO Composer" von Milmeister in seiner Dissertation implementiert, worin Rubetten im Stil des Visual Programming gebaut und verbunden werden können.
Bild 77b: RUBATO Composer der aktuellen Implementierungsphase
Die Arbeit auf der RUBATO-Plattform ist typisch hypermedial, d.h. eine Kombination von Hypertext-Verknüpfung und Multimedia-Darstellung, siehe dazu Bild 78. Hypermedien sind also Hypertexte, welche durch beliebige Medientypen in den "Knotenpunkten" angereichert sind. Entscheidend kommt dazu, dass die Daten dieses Typs nicht einfach passive "Datenfriedhöfe" sind, die man nur anschauen kann, sondern man kann sie jederzeit "editieren", d.h. verändern, eingreifen und so das "Wissen" gestalten. So ist ein Fax mit einem Text drauf ein Datenfriedhof gegenüber einem e-mail mit demselben Text, denn die Bestandteile des gemailten Textes, die Buchstaben und die daraus gebauten Text-Teile sind jederzeit wiederverwendbar durch Kopieren, einbauen, etc., während das Fax keine Buchstaben, sondern nur schwarze Pixel enthält, die sich auch nicht rekombinieren lassen und schon gar nicht Buchtsaben sind, sondern erst als solche Zeichen durch uns rekonstruiert werden müssen.
Bild 78: Hypermedien und Datenfriedhöfe
Bild 79 zeigt eine typische Hypermedia-Fahrt auf der existierenden RUBATO-Umgebung. Auch ohne näher ausgeführte Details erkennt man aber die Einlesephase links oben, welche als Resultat Denotatoren (hier auch "Prädikate" genannt) liefern, die als Hypertext navigierbar sind (rechts oben). Neben einer graphischen Darstellung der Denotatoren kann man dieselben durch Intelligent Query (=IQ) analytischen Fragestellungen unterziehen, hier eine metrisch-rhythmische Analyse. Das Resultat ist als Text-System (links, Mitte) oder als Graphik-Reihe (rechts, Mitte) erkennbar und kann auch als animierte Graphik (rechts unten) oder dann bei der Erstellung von Performances benutzt werden. Die Performances selber sind als Pianola-Graphik (unten, Mitte) erkennbar und können aber als MIDI-File auch zum Erklingen gebracht werden.
Bild 79: Hypermediale Kommunikation
Wir schauen ein Beispiel eines Denotators an in RUBATO, Version 1996 (siehe Bild 80 ff). Damals war die allgemeine Implementierung von Formen aus terminlichen Gründen auf ein Minimum reduziert worden, so dass hier nicht alle Formen-Typen implementiert sind. Aber das soll nicht weiter stören, das Prinzip ist auch mit dieser Einschränkung erkennbar.
Bild 80: Predicate-Browser mit Denotator
Man erkennt in der linken Spalte einen Denotator mit Namen List, rechts davon sieben Denotatoren mit Namen E, H, L, D, C, Midi Channel, Note. Die ersten sechs haben alle dieselbe Form
wo in RUBATO das Synonym "MKValueForm" benutzt wird (wir ignorieren das aber hier).
Dahingegen hat der Denotator mit Namen "List" und der mit Namen "Note" die Form predLIST. Sie erfüllt inhaltlich die Bedingung, dass sie eine Liste repräsentiert, deren Items entweder Denotatoren der Form predSTRING sind oder dann wieder Listen der Form predLIST, wobei in RUBATO das Synonym "MKValueListForm" benutzt wird, wir ignorieren das hier wieder. Die Definition ist diese:
predLIST:.Coproduct(Item, Length);
Item:.Product(Selector, predLIST);
Selector:.Coproduct(predSTRING, predLIST);
also eine zirkuläre Form, die ziemlich allgemeine Listen ermöglicht. Die Alternative "Length" wird angesprochen, sobald in einem Denotator die Liste fertig ist und man deren Länge angeben will. Ist die Liste leer, so geht man gleich zu Anfang zur Länge und setzt diese gleich Null.
Man erkennt in unserem Beispiel, dass etwa die Denotor-Namen "H" oder "Note" Homonyme sind, aber das ist erlaubt nach unseren Konventionen über denoteX, solange die Namen nicht isoliert auftreten, denn das würde zu Vieldeutigkeiten führen. Hier aber sind die entsprechenden Denotatoren immer ganz ausgeführt, und so entstehen keine Miss-verständnisse aufgrund von vieldeutiger Repräsentation.
Man kann solche Hypertexte für Denotatoren an jeder Stellen editieren, inklusive Neubenennung oder "Copy and Paste" (Kopieren und Einfügen) von Denotatoren. Die diversen Rubetten benutzen die Möglichkeit, eine Selektion von bestimmten Teilsystemen in einem Denotator durchzuführen. Dieses "Retrieval" (gezieltes Suchen) ist ganz zentral die Aufgabe von Datenbanksystemen. Dazu benutzt man in RUBATO die Find-Window, siehe Bild 81. Man wählt z.B. zuerst den obersten Denotator "List" im Browser (im Browser anleuchten). Dann wählt man im Finder des Pop-Up-Menu "Contains" oder "Has", und dann schreibt man unten einen Denotator-Namen hinein. Oben haben wir bei "Contains/Note" hineingeschrieben, unten "Has/H". Klicken auf die Lupe ergibt eine Selektion aller Denotatoren (im List-Denotator), die im ersten Fall im Baum der Koordinaten den Namen "Note" enthalten und im zweiten Fall den Namen "H" haben
Bild 81: Selektion von bestimmten Denotatoren im Find-Window
Ergänzung
Man erkennt die Detail-Struktur solcher Selektionen vielleicht besser in der Darstellung als Tabulator-versetzter Text.
Bild 82: Selektionen als Text-File
Ende Ergänzung
Übung: Konstruktion der PianoScore-Form
Dieser Abschnitt ist einer grösseren Übung gewidmet: Wir nehmen eine klassische Musikpartitur, hier Schumanns Kinderszene 7: Träumerei, und versuchen, eine Form zu konstruieren, die alle ihre Elemente hinreichend allgemein darstellt. Diese Aufgabe wurde von Mariana Montiel an der UNAM Mexico City gelöst, wir diskutieren unsere und Montiels Vorschläge.
Bild 83: Partitur Träumerei
Bild 84 zeigt einen denoteX-Text, wie er typisch hier auftritt.
Bild 84: Exzerpt eines denoteX-Files zur Träumerei
