Arbeiten mit den EDI-Formaten der CISAC

Zusammenfassung

Neben den kreativen Teilen der Wertschöpfungskette in der Musikindustrie geht die Digitalisierung auch an den verwaltungstechnischen Prozessschritten nicht spurlos vorüber. Spannungspunkte entstehen dabei zumeist dort, wo Ambitionen, Innovationen und neue Marktakteure auf etablierte, vorgeprägte und wenig dynamische Strukturen der Musikindustrie treffen. Beispielhaft sei hier das Ende der Aktivitäten zur Global Repertoire Database 2014 genannt – ein aus technischer Sicht wertvoller Baustein zur Erreichung von Transparenz, Rechtssicherheit und Effizienz in der Musikwirtschaft, bei dem die Kosten für die Implementierung jedoch zu hoch waren.

Und das Problem ist ja auch einfach bei dieser CWR-Geschichte: es heißt zwar Common Works Registration aber das ist nirgendswo „common“. Weil egal wo du es machst, es stimmt ja nie für das jeweilige Land. Du musst immer manuell noch was einbauen oder wegnehmen (P4, Absatz 113).

Neben den kreativen Teilen der Wertschöpfungskette in der Musikindustrie geht die Digitalisierung auch an den verwaltungstechnischen Prozessschritten nicht spurlos vorüber. Spannungspunkte entstehen dabei zumeist dort, wo Ambitionen, Innovationen und neue Marktakteure auf etablierte, vorgeprägte und wenig dynamische Strukturen der Musikindustrie treffen. Beispielhaft sei hier das Ende der Aktivitäten zur Global Repertoire Database 2014 genannt – ein aus technischer Sicht wertvoller Baustein zur Erreichung von Transparenz, Rechtssicherheit und Effizienz in der Musikwirtschaft, bei dem die Kosten für die Implementierung jedoch zu hoch waren (Kling 2017, S. 246–247).

Aus diesem Grund ist die Arbeit in der Musikindustrie aus IT-Sicht geprägt von geografischen, technischen und rechtlichen Fragmentierungen durch Insellösungen. Insbesondere das immer wichtiger werdende Thema des Datenmanagements stellt ein großes Problem dar, da die Nutzung vieler, unterschiedlicher und teilweise nicht standardisierter Datenformate insbesondere international tätige Verlage vor große Herausforderungen stellt (Lyons et al. 2019).

In diesem Kontext soll das folgende Kapitel einen Blick aus IT-Perspektive auf die Herausforderungen bei der Datenverarbeitung mit Fokus auf Datenformate werfen, verschiedene Lösungsansätze vorstellen, Anregungen geben und Verständnis für die Problematiken fördern.

7.1 Arbeiten mit den EDI-Formaten der CISAC

Der Austausch von Daten in der Musikwirtschaft geht auf die Anfänge der elektronischen Datenverarbeitung Ende des letzten Jahrhunderts zurück. Dabei legen die an dem Austausch Beteiligten das Format und die Struktur der auszutauschenden Daten fest. Es gibt unterschiedliche Arten und Weisen der Strukturierung der Daten, beispielsweise die Verwendung von Trennzeichen, durch welche die einzelnen Datenfelder voneinander getrennt werden. Die CISAC ist einen anderen Weg gegangen und hat das sogenannte Fixed-Length-Format zugrunde gelegt, welches die genaue Position eines Datenfeldes in der Zeile (dem Daten-Record) festlegt.

Es wurde ein Basisformat geschaffen, das CISAC-EDI-Format, von welchem zumindest ein Teil der weithin in der Musikwirtschaft verwendeten Formate abgeleitet wurden, so beispielsweise das Format zum Austausch von Werkanmeldungsdaten, CWR, oder der Abrechnung von Tantiemen, CRD.

Nach allgemeinen Erläuterungen zur CIS-EDI-Spezifikation (siehe Abschn. 7.1.1) werden im Folgenden zwei konkrete Implementierungen betrachtet, die sich aus unterschiedlichen Richtungen der Verarbeitung der CIS-EDI-Formate nähern. Zunächst wird ein Ansatz vorgestellt, welcher Wege aufzeigt, wie Parser, also Programme zur Verarbeitung von Datenformaten, für die CIS-EDI-Formate anhand von strukturierten Grammatik-Beschreibungen generiert werden können. Dieser Ansatz ermöglicht ein schnelles, komfortables und automatisiertes Erstellen von Programmen zur Analyse und Verarbeitung der Datenformate, bringt aber auch einige Einschränkungen mit sich (siehe Abschn. 7.1.1). Diese Betrachtungen zielen insbesondere auf Softwareentwickler*innen oder Lesende mit hoher IT-Affinität ab.

Als zweiter, alternativer Ansatz zur Verarbeitung der CIS-EDI-Formate wird die Entwicklung zweier Desktopapplikationen vorgestellt. Diese fokussieren im Gegensatz zu dem Parsergenerator als Zielgruppe weniger Softwareentwickler*innen als vielmehr Endanwender*innen. Gleichwohl wird bei der Vorstellung in Abschn. 7.1.3 auch darauf eingegangen, wie aus den Ähnlichkeiten der beiden Datenformate, CRD und CWR, Synergien bei der Implementierung erschlossen werden können, um doppelte Implementierungsaufwände zu vermeiden.

7.1.1 CIS-EDI Spezifikation

CIS ist die Abkürzung für Common Information System, welches 1994 von der CISAC eingeführt wurde. Es ist: „Ein gemeinsames Informationssystem, das von allen CISAC-Mitgliedern genutzt wird, um den Wert der vertretenen Rechte zu erhöhen“¹. Über das CIS veröffentlicht und aktualisiert die CISAC seitdem Richtlinien und Spezifikationen für verschiedene Formate für den Datenaustausch in der Musikwirtschaft.

Die grundlegende Struktur der EDI-Daten ist dabei ähnlich, unabhängig davon, ob nun Werkanmeldungen (CWR) oder Tantiemenabrechnungen (CRD) beschrieben werden. Diese Gemeinsamkeiten werden im Folgenden dargestellt, für eine detaillierte Betrachtung der Eigenschaften und Eigenheiten der beiden Formate sei auf die Abschn. 4.1.2 und 5.2 verwiesen.

In der EDI-Spezifikation wird beispielsweise festgelegt, dass die zu verwendenden Zeichen dem ASCII-Format entsprechen müssen, bzw. genau genommen auch nur einer bestimmten Teilmenge dieser Zeichen. Diese Teilmenge umfasst bspw. nur Großbuchstaben². Die CISAC hat eine Tabelle speziell dafür erstellt, welche Zeichen in welchem Kontext zu verwenden sind³. Hier finden sich auch Inkonsistenzen: so existiert das Euro-Zeichen (€) eigentlich nicht im ASCII-Zeichensatz, jedoch wird dessen Verwendung in Titel-Feldern zugelassen.

Des Weiteren wird der Rahmen einer Transmission, also der Übertragung von Daten per Datei, festgelegt (siehe auch Abschn. 4.1.2). Er besteht aus einem umschließenden Transmission-Header und Trailer und legt die Struktur dieser Records fest. Darin sollen generelle Daten über den Sender und den Zeitpunkt der Erstellung gespeichert werden. Dazwischen gibt es eine Anzahl (1…n) Gruppen, die wiederum durch einen Header und einen Trailer definiert sind und die schließlich die einzelnen Transaktionen beinhalten. Die Struktur der Transaktionen wird dabei von dem jeweiligen Anwendungsfall definiert, besteht jedoch immer aus einem Transaktionsheader sowie einer zu definierenden Anzahl von Transaktionsrecords.

Ein Record umfasst eine Zeile, die Art des Records wird jeweils durch die ersten drei Zeichen definiert. Anhand dieser drei Zeichen kann das verarbeitende System den Typ des Records eindeutig identifizieren. So beginnen die Transmission-Header-Records immer mit den Zeichen „HDR“. Bei Transactions-Records folgen diesen drei Zeichen dann noch acht numerische Zeichen, welche die Nummer der Transaktion innerhalb einer Gruppe definieren. So können zu einer Transaktion gehörende Records leicht identifiziert werden. Dem folgen acht numerische Zeichen, welche die Reihenfolge der Records in der Transaktion darstellen. Eine Übersicht der gesamten Struktur einer CIS-EDI-Datei zeigt Abb. 7.1.

Abb. 7.1

Struktur einer Datei im CIS-EDI Format

Außerdem werden die möglichen Feldtypen sowie deren Standardwerte definiert, die von den jeweilig abgeleiteten Spezifikationen zur Beschreibung der Daten verwendet werden können. Weiterhin muss eine abgeleitete Spezifikation die folgenden Angaben zu einem verwendeten Datenfeld vornehmen: Den Namen des Feldes, die Startposition, die Anzahl der Zeichen (wir erinnern uns: Fixed-Length!), das Format, ob Angaben in dem Feld verpflichtend (mandatory), freiwillig (optional) oder bedingt (conditional) erfolgen sollen, sowie die Beschreibung des Feldes.

Abschließend gibt die Spezifikation die genaue Struktur zur Zusammensetzung des Dateinamens an, in welchen ebenfalls, zusätzlich zum Transmission-Header, Informationen kodiert werden. Diese werden jedoch häufig von den jeweiligen Implementierungen, beispielsweise bei den Verwertungsgesellschaften, nicht berücksichtigt.

Diesem allgemeinen Rahmen folgen, wie bereits erwähnt, etliche Datenformatspezifikationen der CISAC für verschiedene Anwendungsfälle (Werkanmeldung, Tantiemenabrechnungen etc.). Wie Softwarelösungen für diese verschiedenen, aber auf der gleichen Basis fußenden Formate ohne große Redundanz implementiert werden können, wird nachfolgendend diskutiert.

7.1.2 Entwicklersicht: Umsetzung eines Parsergenerators

Während im nachfolgenden Abschn. 7.1.3 eine Software für Endanwender*innen mit grafischer Benutzeroberfläche vorgestellt wird, wird in diesem Abschnitt eine Lösung gezeigt, welche einen stärker technischen Ansatz zur Verarbeitung von CIS-EDI-Formaten verfolgt.

Aufgrund der im vorigen Abschnitt erläuterten strukturellen Ähnlichkeiten dieser Formate bietet sich ein grammatikbasierter Ansatz zur Generierung von Parsern an. Das Vorgehen bzw. sowie auch der Anwendungsfall unterscheidet sich dabei deutlich von Software mit Benutzeroberfläche (siehe Abb. 7.2) und wird im Folgenden genauer erläutert. Zur Illustration wird dabei beispielhaft auf die CWR-Spezifikation zurückgegriffen, obgleich der Ansatz ebenso für CRD-Dateien umsetzbar ist.

Abb. 7.2

Anwendung des Parsergenerators

7.1.2.1 Voraussetzungen und Zielsetzung

Die genannten Eigenschaften der EDI-Formate sowie die weit verbreitete Nutzung des CWR-Standards sind ein guter Ausgangspunkt für die Automatisierung verschiedener Verarbeitungsschritte. Ein erster Schritt dazu ist die Validierung von CWR-Werkanmeldungen hinsichtlich der durch den Standard vorgegebenen Syntax und Semantik. Entsprechend der Heterogenität und Schnelllebigkeit der Musikindustrie sollte die zu entwickelnde Software möglichst flexibel einsetzbar und anpassbar sein. Dazu muss sie folgenden Anforderungen genügen:

• Plattform- und Systemunabhängigkeit: Die Lösung soll weder von einer bestimmten Plattform wie Windows oder Linux noch von einer eventuell vorhandenen Verlagsverwaltungssoftware abhängig sein. Stattdessen soll eine Lösung angeboten werden, die bei Bedarf auch in andere Software integriert werden kann.

• Schnelle Anpassbarkeit: Die CIS-EDI-Formate unterliegen einer ständigen Überarbeitung und Anpassung. Um die Zukunftsfähigkeit der Parser-Lösung zu gewährleisten, muss sie mit geringem Aufwand an neue Spezifikationen angepasst werden können.

• Änderbar ohne Programmierkenntnisse: Um einen möglichst niedrigschwelligen Einstieg zu ermöglichen, sollen Änderungen der Validierungsregeln auch ohne bzw. nur mit geringen Programmierkenntnissen möglich sein. Dies erlaubt die flexible Weiterentwicklung auch von Fachabteilungen mit geringen IT-Kenntnissen.

Mit Blick auf die inhärente Struktur des EDI-Formats wurde eine Parser-basierte Lösung gewählt. Diese erlaubt die schrittweise Verarbeitung der Einträge einer CWR-Datei. Um der Anforderung zu genügen, plattform- und systemunabhängig zu sein, wurde ein Generator-getriebener Ansatz gewählt. Dieser ermöglicht die Generierung von Parsern für verschiedene Plattformen und Zielprogrammiersprachen und ist nach einer initialen Konfiguration leicht erweiterbar. Im Folgenden wird zunächst die grundlegende Funktionsweise eines Parsers vorgestellt sowie anschließend die Entwicklungsschritte hin zu dem Parser-Generator dargestellt. Im Zuge dessen wird auch auf die Erweiterbarkeit eingegangen. Abschließend werden Möglichkeiten und Grenzen des Ansatzes diskutiert.

7.1.2.2 Parser und Grammatik

Parser sind in der Informatik ein bekanntes Mittel, um strukturierte Texte zu analysieren und für die Weiterverarbeitung vorzubereiten. Ein Parser arbeitet einen Text zeichenweise ab und erstellt aus diesem Text einen sogenannten Syntaxbaum, der die Elemente des Textes enthält. Ein bekanntes Beispiel dafür sind HTML⁴-Parser, welche in allen Browsern vorhanden sind. Diese analysieren den Text einer HTML-Datei, leiten daraus die HTML-Struktur einer Webseite ab und formatieren die Ausgabe entsprechend der vorhandenen Elemente (siehe Abb. 7.3).

Abb. 7.3

Vereinfachte Darstellung des Parsings von HTML

Ziel der Verarbeitung einer CWR-Datei mit einem Parser ist die Validierung der Syntax, d. h. die Prüfung, ob ein gegebener Text den Anforderungen an das CWR-Format entspricht. Um dies zu prüfen ist es notwendig, die textuellen Vorgaben des CWR-Formats aus der Spezifikation in ein maschinenlesbares, automatisiert verarbeitbares Format zu übertragen – die sogenannte Grammatik. Ganz allgemein besteht eine Grammatik aus verschiedenen Regeln, die vorgeben, wie eine valide Kombination von Zeichen aussieht. Ein einfaches Beispiel für eine solche Regel ist die Definition einer Ziffer. Diese kann formal z. B. wie folgt kodiert werden:

• Ziffer <- ´0´ | ´1´ | ´2´ | ´3´ | ´4´ | ´5´ | ´6´ | ´7´ | ´8´ | ´9´

Der linke Teil der Regel enthält den Namen des zu definierenden Elements – das sogenannte Nichtterminalsymbol; in diesem Fall Ziffer. Der rechte Teil der Regel enthält die Zeichen, aus denen das Symbol gebildet wird (die Terminalsymbole). Im gegebenen Fall sind dies die möglichen Ziffern, getrennt durch einen senkrechten Strich, der eine ODER-Verknüpfung darstellt. In komplexeren Grammatiken existieren auch Regeln, die auf der rechten Seite Nichtterminalsymbole enthalten, z. B. die folgende Definition von Zahlen:

• Zahl <- + Ziffer

• Postleitzahl <- Ziffer Ziffer Ziffer Ziffer Ziffer

Hier wird festgelegt, dass eine Zahl aus einer Verknüpfung mehrerer Ziffern besteht, dargestellt durch das Plus-Symbol. Entsprechend der Definition besteht eine Postleitzahl aus genau fünf Ziffern.

Die Grammatik, welche aus der CWR-Spezifikation abgeleitet wurde, enthält eine Vielzahl dieser einzelnen Regeln⁵. Ein beispielhaftes Set von Regeln ist die Definition der ersten Zeile einer CWR, dem sogenannten Header. Dieser ist in der CWR-Spezifikation wie in Tab. 7.1 definiert.

Tab. 7.1 Auszug von Angaben zum Record Format aus der CWR Spezifikation v2.1 Revision 8Footnote

https://members.cisac.org/CisacPortal/consulterDocument.do?id=37079, zuletzt geprüft am 10.05.2022.

Die darauf basierende Umsetzung dieser natürlichsprachlichen Definition in eine formale Grammatik sieht wie folgt aus:

Im Beispiel wird das Nichtterminalsymbol „TransmissionBegin“ definiert, welches immer mit der Zeichenkette „HDR“ beginnt, anschließend folgt entweder der „SenderType“ und eine neunstellige Zahl oder eine elfstellige Zahl (die „SenderId“). Als nächstes folgt der „SenderName“ (45 Zeichen) und die fixe Zeichenkette „02.00“ (EDI-Versionsnummer). Dem folgen das Erstellungsdatum, die Erstellungszeit der CWR-Datei und das Übertragungsdatum sowie die Definition der genutzten Zeichenkodierung (15 Zeichen).

Das Beispiel zeigt, dass die Grammatik durch die Nutzung sprechender Namen auch von Menschen ohne IT-Hintergrund mit nur wenig Einarbeitungsaufwand verstanden werden kann.

7.1.2.3 Verarbeitung der Grammatik

Die Verarbeitung einer Eingabe mittels des Parsers erfolgt unter Nutzung eines endlichen Automaten. Der Automat ist durch die Regeln der Grammatik definiert und verarbeitet die Eingabe zeichenweise. In der folgenden Abb. 7.4 ist die oben gezeigte Regel zur Definition der ersten Zeile als Automat visualisiert:

Abb. 7.4

Darstellung der Regel als Automat

Die Zustände des Automaten (Kreise in der Abbildung) sind die Nichtterminale der EDI-Daten, also z. B. „SenderType“ und „SenderName“. Zustandsübergänge – dargestellt durch einen gerichteten Pfeil zwischen zwei Zuständen – sind die Daten, die aus der Eingabedatei gelesen werden. Eine beispielhafte Abarbeitung der Zeile „HDRSO000000080SUISA[…]02.0020200629“ sieht wie folgt aus:

Zunächst wird die Zeichenkette „HDR“ gelesen, welche den Automaten in den Zustand „TransmissionBegin“ bringt (Abb. 7.5).

Abb. 7.5

Schritt 1 – Einlesen von „HDR“

Anschließend versucht der Parser das Nichtterminalsymbol „SenderIdLong“ aufzulösen, welches aus elf Ziffern besteht. Dies schlägt fehl, da im Eingabetext die Zeichenkette „SO“ folgt (Abb. 7.6).

Abb. 7.6

Schritt 2 – Fehler beim Einlesen der SenderIdLong

Die zweite Möglichkeit für den Parser an dieser Stelle ist es, die Abfolge „SenderType“ und „SenderIdShort“ zu prüfen. Dies ist erfolgreich, sodass beide Regeln ausgeführt werden können und der Parser nun die 45 Zeichen des Symbols „SenderName“ erwartet (Abb. 7.7).

Abb. 7.7

Schritt 3 – Einlesen von SenderType sowie der SenderIdShort

Als Abschluss in diesem Beispiel wird der „SenderName“ und die „EDIVersionNumber“ verarbeitet, sodass der Automat erfolgreich abschließt (Abb. 7.8). Dies bedeutet, dass die entsprechende Eingabe erfolgreich geparst wurde und valides CWR enthält.

Abb. 7.8

Schritt 4 – Einlesen von SenderName und EDIVersionNumber

Anhand des Beispiels lassen sich die groben Arbeitsschritte des Parsers nachvollziehen. Dabei wird deutlich, dass beim Fehlschlag eines Parser-Schrittes eine andere Regel gesucht wird, die angewendet werden kann. Gibt es keine andere mögliche Regel, endet der Parsing-Vorgang mit einem Fehler, z. B. bei einer falschen EDI-Versionsnummer. Im Beispiel in Abb. 7.9 ist in der Eingabe die Zeichenfolge „02.01“ vorhanden, es wird aber „02.00“ erwartet, sodass der Parser keine weiteren Auswertungsschritte vornehmen kann.

Abb. 7.9

Fehler beim Parsing

7.1.2.4 Generator-Ansatz

Im vorigen Abschnitt wurde die Theorie hinter einer Abarbeitung einer Eingabe mittels eines Parsers gezeigt. Zur Umsetzung dieses Ansatzes wurde eine Softwarelösung entwickelt, die in der Lage ist, Parser auf Basis der CWR-Grammatik zu generieren. Aufgrund der Anforderungen Schnelle Anpassbarkeit und Plattform- und Systemunabhängigkeit, musste eine Lösung gefunden werden, die flexibel an die jeweiligen Einsatzbereiche angepasst werden kann. Dies umfasst neben der verwendeten Programmiersprache auch Änderungen an der Grammatik, z. B. durch neue CWR-Versionen oder die Implementierung von Parsern für andere CIS-EDI-Formate. Die Art und Weise wie die Spezifikation der Parser vorgenommen wird setzt dabei auch die Anforderung Änderbar ohne Programmierkenntnisse um, da die Regeln ähnlich natürlicher Sprache beschrieben werden können.

Um diesen Anforderungen zu genügen, wurde ein generatorbasierter Ansatz verwendet, d. h. es wurde kein spezifischer Parser implementiert, der genau eine Grammatik umsetzt. Stattdessen wurde die Grammatik als Text definiert, aus der mittels des Generators ein Parser für die entsprechende Zielplattform gebaut wird. Als Grundlage dafür wurde der quelloffene Parser-Generator waxeye⁷ mit eigenen Anpassungen⁸ verwendet. Damit wird die Generierung von Parsern für die Programmiersprachen PHP, Java und JavaScript unterstützt.

Der Generator stellt grundlegende Funktionalitäten wie z. B. die Abarbeitung des endlichen Automaten und Ein-/Ausgaben bereit. Darüber hinaus enthält der Generator ein Modul, welches aus der Grammatik einen Parser in der entsprechenden Programmiersprache erzeugt. Dieser kann dann entweder als alleinstehende Anwendung verwendet oder in eine vorhandene Umgebung integriert werden, z. B. als Webservice oder im Verwaltungssystem des Verlages.

7.1.2.5 Möglichkeiten und Grenzen des Parser-Ansatzes

Durch den modularen Aufbau und die Möglichkeit, Parser für verschiedene CWR-Versionen sowie generell für unterschiedliche CIS-EDI-Formate zu generieren, kann der Generator schnell und einfach an jeweils individuelle Bedürfnisse angepasst werden. Dies umfasst neben einem Wechsel der CWR-Version auch die Integration weiterer EDI-basierter Formate wie z. B. CRD. Hierzu sind nur die Regeln der Grammatik zu aktualisieren, sodass je nach Größe der Änderungen teilweise nur wenige Minuten Zeitaufwand dafür notwendig sind.

Der Parser liefert als Ergebnis eine strukturierte Darstellung der eingelesenen CWR-Datei (sogenannter Abstract Syntax Tree, AST). Dieser kann einfach in andere Formate umgewandelt werden, um z. B. eine fixed-length CWR-Datei als JSON auszugeben. Dies ist insbesondere in webbasierten Anwendungen relevant, da diese oftmals JSON schon von Haus aus verarbeiten können, sodass keine weiteren Änderungen notwendig sind.

Die Nutzung des generatorgetriebenen Ansatzes ist allerdings mit einigen Herausforderungen verbunden. Im Gegensatz zu einer Lösung, die direkt auf das CWR-Format angepasst ist, wird mit dem Generator ein generischer Ansatz verfolgt. Dieser kann daher die Performance spezifischer Lösungen nicht erreichen. Insbesondere bei einer großen Grammatik mit vielen Verzweigungen müssen viele Regeln überprüft werden, sodass Performanceverluste zu erwarten sind. Dies hat sich auch bei Tests gezeigt, bei denen die Verarbeitung eines sehr großen CWR-Dokuments (ca. 82.000 Zeilen mit insgesamt 14.146 Werkregistrierungen) etwa 20 min in Anspruch genommen hat.

Wie in Abschn. 7.1.2.3 dargestellt werden die Regeln der Grammatik nacheinander geprüft und die erste passende Regel ausgeführt. Daraus ergibt sich ein erster Optimierungsansatz in der Änderung der Reihenfolge der Regeln, sodass vermutlich oft genutzte Regeln eher geprüft werden. Um die Leistung zu verbessern, kann der Parser weiterhin alle Zeilen eines CWR-Dokuments unabhängig voneinander lesen. Damit lassen sich statt einer großen Grammatik viele kleine Grammatiken nutzen, welche die jeweilige Zeile repräsentieren, z. B. eine Grammatik für den Transaktionsheader; also Zeilen, die mit „HDR“ beginnen. Da die Grammatik weitaus kleiner ist, müssen weniger Regeln geprüft werden. Durch Anwendung dieses Verfahrens wurde die Verarbeitungszeit auf etwa 160 s deutlich gesenkt. Darüber hinaus lässt sich dieses Vorgehen parallelisieren, sodass mehrere Zeilen auf einmal geprüft werden können, was zu einer weiteren Reduzierung der Abarbeitungszeit führt.

Entsprechend der Darstellung der Funktionsweise bricht der Parser ab, wenn keine weiteren anwendbaren Regeln gefunden werden können. Daher kann bei der Prüfung einer gesamten Datei nur der erste Fehler angezeigt werden. Auch diesem Problem kann durch zeilenweises Einlesen entgegengewirkt werden, sodass zumindest der erste Fehler jeder Zeile identifiziert werden kann.

Mit dem zeilenweisen Einlesen geht einher, dass der Parser zeilenübergreifende Bedingungen nicht prüfen, sondern nur die Syntax einer einzelnen Zeile analysieren kann. Dementsprechend liegt der Anwendungsbereich des Parsers eher in einer ersten Kontrolle der Daten anstatt in einer tiefer gehenden Analyse sowie in der Überführung formal korrekter Daten in andere Datenformate.

7.1.3 Anwendersicht: Umsetzung als Desktopapplikation

Während im vorigen Abschnitt die Erstellung von Parsern und somit eher für generische, die Softwareentwicklung relevante Thematiken besprochen wurden, fokussiert dieser Abschnitt die Entwicklung spezifischer Lösungen für Endanwender*innen. Ebenso wird auch ein anderer technischer Ansatz verfolgt, weshalb auch keine technischen Komponenten wiederverwendet wurden.

Die adressierten Datenformate waren ebenfalls CWR und CRD. Dazu wurden zwei Softwaretools entwickelt. Zum einen ist dies der CWR-Validator⁹, welcher die CWR-Dateien zur Werkanmeldung auf Korrektheit überprüft. Zum anderen ist dies der CRD-Viewer¹⁰, mit welchem Abrechnungsdaten aus CRD-Dateien dargestellt und analysiert werden können.

Neben Vorstellung der Funktionalität der Tools (siehe Abschn. 7.1.3.3 sowie 7.1.3.4) und der Darstellung deren Nutzen für Endanwender*innen wird ebenso auf die Frage eingegangen, wie diese zwei Anwendungen mit unterschiedlichem Aufgabenbereichen (Werkanmeldung und Tantiemenabrechnung) technisch so umgesetzt werden können, dass möglichst viele Synergien aus den Ähnlichkeiten der beiden CIS-EDI-Datenformate CWR und CRD gewonnen werden können, auch ohne dabei auf Ansätze wie Grammatiken zurückzugreifen.

7.1.3.1 Technische Umsetzung

Die Umsetzung beider Applikationen wurde unter Verwendung des von Microsoft entwickelten .NET-Frameworks¹¹ durchgeführt. Dies ermöglicht eine modulare Umsetzung einzelner Bausteine und eine Verwendung dieser in unterschiedlichen Kontexten, sei es einer Web-API¹² oder einer Windows Desktop-Anwendung.

So wurde eine auf WPF, einem XML-basierten UI-Framework, basierende Desktopanwendung zur Validierung von CWR-Dateien (CWR-Validator) und eine Anwendung zur Darstellung und Analyse von CRD-Dateien (CRD-Viewer) entwickelt. Ebenso wurden auch zugehörige Web-APIs implementiert, über welche die Funktionalitäten webbasiert und programmatisch zugreifbar sind.

Die Architektur wurde derart gewählt, dass sich die entwickelten Programme direkt in das an der Universität Leipzig entwickelte prototypische Framework zur Arbeit mit Daten aus der Musikwirtschaft (Music Business Data Manager) einbinden lassen und dieses damit um die Funktionalität des Imports der entsprechenden Daten (CWR, CRD, IWA-XML…) erweitert wird. Ebenso sollte auf funktionaler Ebene eine Wiederverwendung ermöglicht werden, um redundante Implementierungsaufwände für ähnliche Aufgaben zu vermeiden. Abb. 7.10 gibt eine Übersicht aller Komponenten, deren Funktionen sowie deren Zusammenspiel.

Abb. 7.10

Architektur der Softwarekomponenten

7.1.3.2 Generelle Herangehensweise

Um die Tatsache, dass die einzelnen Datenübertragungsformate (CWR, CRD etc.) von der Grunddefinition des CIS-EDI-Formates abgeleitet wurden, abzubilden, wurde eine Basisbibliothek entwickelt, welche diese grundlegenden Strukturen abbildet, sowie die sich daraus ergebenden funktionellen Abläufe festlegt. Es werden außerdem Basisklassen geschaffen, die von der Implementierung der jeweiligen Spezifikation verwendet werden können, um die Funktionalitäten der entwickelten Basisbibliothek zu nutzen.

Eine wichtige Funktion ist dabei die Abbildung zusätzlicher Informationsquellen der CISAC, wie zum Beispiel die Liste der Sender-IDs, die Codes für die Zuordnung der Territorien oder die Lookup-Tabellen, in denen der Wertebereich für bestimmte Datenfelder angegeben ist¹³. Diese Daten wurden einheitlich repräsentiert und über Schnittstellen für Implementierungen der jeweiligen Spezifikationen verfügbar gemacht.

Es wird weiterhin ein Datentyp zur Verfügung gestellt, in dem die Ergebnisse des Parsens einer CISAC-EDI Datei intern gespeichert werden kann. Dies hat den Vorteil, dass weitere, unspezifische Funktionalitäten, wie bspw. die Validierung der Datenformate, generalisiert und für alle folgenden Implementierungen zur Verfügung gestellt werden können. Darin werden unter anderem Informationen zur geparsten Datei, eine sequentielle Liste aller Records oder eine Liste aller beim Parsen aufgetretenen Fehler oder Warnungen gespeichert. Da die Struktur der CIS-EDI Formate „quasi-hierarchisch“ ist¹⁴, wird außerdem die Struktur einer verschachtelten Hierarchie angelegt, auf welche ebenso im Ergebnisdatentyp verwiesen wird.

Um bei der Form der Eingabe der Daten flexibel zu sein, wird ein mehrschichtiger synchroner und asynchroner Parser zur Verfügung gestellt, dem man die Daten entweder in Form eines vollständigen Dateinamens, eines Datenstreams oder einer Liste aller Zeilen dieser Datei übergeben kann. Davon abhängig werden die Daten aufbereitet und schließlich als Liste von Zeichenketten, welche die einzelnen Zeilen der Datei repräsentieren, dem generalisierten Parser übergeben.

Im ersten Schritt wandelt dieser jede der Zeilen in den entsprechenden Datentypen, der dem Recordtypen der Zeile entspricht, um. Dies wird möglich, da die Grundstruktur eines Records in der Basisbibliothek definiert wird. Die Implementierung der Spezifikation muss lediglich von dieser definierten Basisklasse ableiten und so den Datentypen für jeden Recordtypen zu erstellen. Der generalisierte Parser kann über eine Reflection¹⁵ die in der Spezifikationsimplementierung erstellten Klassen ermitteln und anhand der ersten drei Zeichen der Zeile ein Objekt der passenden Klasse initialisieren. Jede Eigenschaft einer Klasse wird einem Record-Feld zugeordnet. Weiterhin muss jede Eigenschaft der Klasse mit Attributen¹⁶ versehen werden, aus denen der Datentyp, die Position, sowie Pflicht/Optionalität des zugehörigen Feldes des Records hervorgeht. Mit diesen Informationen kann der generalisierte Parser aus den als Zeichenkette vorliegenden Records die Instanz des dazugehörigen Datentypen automatisch generieren.

Im Anschluss werden Transmission- und Group-Records geparst und damit die untersten Hierarchieebenen der Transformation erstellt. In diese werden dann die einzelnen Transaktionen eingefügt. In diesem Zuge wird die Aufgabe des Parsens für das spezielle Format in der Implementierung der Spezifikation aufgerufen. Damit kann jede Transaktion als hierarchische Struktur im Ergebnisdatentypen abgelegt werden.

Zum Abschluss wird die Validierung der geparsten Daten vorgenommen und gefundene Verstöße gegen die Spezifikation in einem entsprechenden Datenobjekt abgelegt. Dabei werden zum einen die Korrektheit des Datentypen, bzw. des Datenbereiches überprüft, zum anderen wird die von jedem abgeleiteten Datentypen, der einen Record darstellt, zu implementierende abstrakte Funktion aufgerufen, in der dann die individuelle, Record-spezifische Validierung anhand der in der jeweiligen Spezifikation angegebenen Validierungskriterien vorgenommen wird.

Der Ergebnisdatentyp, der alle prozessierten Daten enthält wird daraufhin weitergegeben und kann je nach Anwendungsfall individuell weiterverarbeitet werden.

7.1.3.3 Praxisbeispiel 1 – Der CWR-Validator

Das CWR-Format wird verwendet, um die Registrierung bzw. Änderung der Daten eines musikalischen Werkes zwischen den beteiligten Verlagen und den Verwertungsgesellschaften abzubilden (siehe auch Abschn. 4.1.1). Dazu müssen die Verlage, die neue Werke anmelden oder bestehende ändern wollen, eine entsprechende CWR-Datei erstellen und diese an die gewünschte Verwertungsgesellschaft schicken. Fehler in diesen Dateien können negative Folgen, beginnend von Verzögerungen im Ablauf bis hin zu fehlerhaften Werkanmeldungen haben – mit damit jeweils verbundenen wirtschaftlichen Einbußen. Es ist für die Verlage also unerlässlich sicherzustellen, dass eine reibungslose Verarbeitung der gesendeten CWR-Dateien stattfindet. Ein naheliegender Ansatz ist dabei die Konformität zur vorgegebenen Spezifikation sicherzustellen.

Zu diesem Zweck wurde der CWR-Validator entwickelt, welcher mit Hilfe der von der Basisbibliothek zur Verfügung gestellten Funktionalitäten eine CWR-Datei einlesen kann und anschließend die gefundenen Validierungsmeldungen in übersichtlicher Form anzeigt und es Nutzer*innen ermöglicht, sich direkt zum betroffenen Datensatz zu navigieren. Dieser wird dann mithilfe einer ebenfalls generalisierten, selbstentwickelten Bibliothek zur deutlicheren Visualisierung von Transaktionen und der darin enthaltenen Records dargestellt, um den Benutzer*innen direkt das oder die problematischen Felder zu visualisieren (siehe auch Abb. 7.12).

Abb. 7.11

Anzeige der Validierungsergebnisse

Wie in Abb. 7.11 dargestellt, werden die Validierungsergebnisse dabei nach der Typ der Validierungsmeldung zusammengefasst, um die Übersichtlichkeit zu erhöhen. Für jeden Validationsmeldungstyp wird auf die Validation-ID der Vorgabe verwiesen, die verletzt wurde und eine kurze Erläuterung angezeigt (Rule). Ebenso können dann die spezifischen Transaktionen, die die jeweilige Meldung produziert haben, angezeigt und es kann direkt zur Detailanzeige der jeweiligen Transaktion gesprungen werden.

Die Transaktion wird in Form von aufklappbaren Zeilen, die den jeweiligen Record enthalten, dargestellt (siehe Abb. 7.12). Wenn für einen Record eine Validierungsmeldung vorliegt, wird diese ebenfalls unterhalb der Kopfzeile des Records dargestellt. Die einzelnen Felder des Records werden aufgeteilt und mit Feldnamen und Feldinhalt dargestellt, wobei zur besseren Übersichtlichkeit Leerzeichen durch Punkte ersetzt werden¹⁷. In der Validierungsmeldung wird zum einen die verletzte Regel dargestellt und zum anderen der Grund der Verletzung. Außerdem werden beim Bewegen des Mauszeigers auf die Validierungsmeldung das oder die betroffenen Felder, soweit eine eindeutige Zuordnung der Validierungsmeldung zu einem Feld möglich ist, hervorgehoben. Auf diese Art und Weise wird es den Benutzer*innen ermöglicht, ein genaues Bild des Auslösers der Validierungsmeldung zu bekommen und diesen in seinen Daten zu beheben (siehe Abb. 7.13).

Abb. 7.12

Darstellung einer Transaktion

Abb. 7.13

Anzeige einer Validierungsmeldung

Ein Problem, welches in der praktischen Anwendung des Validators aufgefallen ist, ist der Umstand, dass sich Verwertungsgesellschaften und andere Akteure nicht in jedem Fall vollständig an die Spezifikation halten. So meldet der Validator sehr häufig Verstöße gegen die Spezifikation, die aber im praktischen Einsatz nicht relevant sind, weil sie von den Verwertungsgesellschaften ignoriert, bzw. die Daten nicht der Spezifikation entsprechend behandelt werden. Hinzu kommt, dass jede Verwertungsgesellschaft andere Regeln ignoriert bzw. Ausnahmen zulässt. Aus diesem Grunde wurden individuelle Filter implementiert, durch welche die akzeptierten Verstöße ausgeblendet werden können. Diese Filter können je Empfänger*in, wie z. B. pro Verwertungsgesellschaft, individuell konfiguriert werden.

Über den in Abb. 7.14 gezeigten Dialog können einzelne Validierungsmeldungen ausgeblendet werden. Diese erscheinen dann weder in der Liste aller Validierungsmeldungen noch bei den betroffenen Records. Es wird jedoch ein Hinweis eingeblendet, wenn der Record eine ausgeblendete Validierungsmeldung enthält. Damit wird die Übersichtlichkeit und Nutzbarkeit wesentlich erhöht, da man sich dadurch nur relevante Meldungen anzeigen lassen kann.

Abb. 7.14

Dialog zur Filterung der Validierungsnachrichten

Da, wie schon erwähnt, die Art der akzeptierten Verstöße bezüglich der Spezifikation von Verwertungsgesellschaft zu Verwertungsgesellschaft unterschiedlich ist, wurde zusätzlich die Einrichtung von Filter-Presets ermöglicht, um die Besonderheiten der einzelnen Verwertungsgesellschaft oder anderer Datenempfänger abspeichern und einfach wieder abrufen zu können (siehe Abb. 7.15). Zum einen wurde begonnen, aus gesammelten Erfahrungen sogenannte Factory-Presets anzulegen, in denen die bekannten, von der jeweiligen Verwertungsgesellschaft ignorierten, Validierungsregeln abgespeichert sind. Ebenso können aber auch eigene Presets angelegt und Preset-Einstellungen kopiert werden. Dadurch ist es möglich, dynamisch auf eventuelle zukünftige Änderungen oder bislang unbekannte Datenempfänger mit eigenen Interpretationen der Spezifikation zu reagieren.

Abb. 7.15

Erstellung von Filter-Presets

7.1.3.4 Praxisbeispiel 2 – Der CRD-Viewer

Das ebenfalls auf der CIS-EDI-Spezifikation basierende CRD-Format wird von den Verwertungsgesellschaften u. a. dafür genutzt, um Verlagen die für die von ihnen vertretenen Urheber*innen ausgeschütteten Tantiemen zu melden. Im Gegensatz zum CWR-Format werden Redundanzen in den Informationen zu den beteiligten Parteien durch referenzierbare Datensätze vermieden, dies verringert jedoch die Lesbarkeit des Formates. Da es für das CRD-Format (siehe auch Abschn. 5.2) bisher keinen allgemein verfügbaren Viewer gibt, wurde aufbauend auf der Basisbibliothek zum Parsen von CIS-EDI-Formaten mit dem CRD-Viewer ein entsprechendes Programm als Desktop-Anwendung entwickelt.

Dazu wurde zunächst ein Modul entwickelt, welches die datentechnischen Aufgabenstellungen abdeckt. Durch die bestehende Struktur war es ausreichend, die Beschreibung der Records aus der Spezifikation in Klassen, Eigenschaften und Attribute zu übersetzen, sowie die Parse-Funktion für die speziellen Hierarchieebenen umzusetzen. Des Weiteren wurden für das CRD-Format spezifische Lookup-Tables eingebunden, sowie der Validation-Manager aus der CISAC-Library (siehe Abb. 7.10) leicht angepasst, da das Ziel der Anwendung nicht die Validierung der Daten war.

Darauf aufbauend wurde eine Visualisierung umgesetzt, die so weit wie möglich an Design und Usability des CWR-Validators angelehnt wurde. Dadurch ließen sich zum einen einige UI-Elemente wiederverwenden, zum anderen stellt dies eine gute Grundlage zur potenziellen Entwicklung weiterer Programme, die sich mit CIS-EDI-Formaten befassen, dar.

Nachdem die CRD-Datei bzw. Dateien – es kann vorkommen, dass zu einer Abrechnung mehr als eine CRD-Datei verschickt wird – erfolgreich eingelesen wurden, wird als erstes eine allgemeine Übersicht der grundlegenden Daten der Datei(en) angezeigt (siehe Abb. 7.16). Zusätzlich können

Abb. 7.16

Allgemeine Informationen zur CRD-Datei

• a) Informationen zu den beteiligten Künstlern bzw. Verlagen (Interested Party),

• b) Informationen zu den verschiedenen Quellen, aus denen die Tantiemenzahlungen erzielt wurden (Exploitation Source),

• c) sowie eine Übersicht der Werke, für die eine Auszahlung in der geladenen Datei vorliegt (Reported Work)

angesehen, die Tantiemenzahlungen nach diesen gefiltert und in der Detailansicht analysiert werden.

In der Detailansicht der Tantiemen (siehe Abb. 7.17) werden nun Informationen zu den einzelnen Tantiemenzahlungen aufgeführt. Dabei werden die über ein halbes Dutzend unterschiedlichen Tantiemenarten (Performance, Verkäufe, usw.) in einer Tabelle zusammengefasst. In den CRD-Daten ist eine Vielzahl von Details enthalten, woraus eine sehr große Anzahl möglicher Spalten resultiert mit entsprechenden Herausforderungen bezüglich Darstellbarkeit. Aus diesem Grund wurde ein zweischichtiges Filtersystem entwickelt. Zum einen werden automatisch alle Spalten ausgeblendet, in denen für die angezeigten Datensätze keine Werte stehen, zum anderen können Nutzende über einen Dialog auswählen, welche Spalten (nicht) angezeigt werden sollen (siehe Abb. 7.18).

Abb. 7.17

Detailansicht der Tantiemen

Abb. 7.18

Filterung der Datensätze

Weiterhin können die angezeigten Datensätze nach verschiedenen Kriterien gefiltert werden (siehe Abb. 7.19). Es können auch mehrere Werte für die gleiche Kategorie ausgewählt werden, diese werden dann mit einer ODER-Verknüpfung kombiniert. Zusätzlich dazu lässt sich über „Start date“ und „End date“ der Zeitraum angeben, für den die Datensätze angezeigt werden sollen.

Abb. 7.19

Filterdialog

Für alle gefilterten Datensätze erfolgt eine Summierung der Tantiemen, deren Ergebnis über der Tabelle angezeigt wird. Dabei soll einfach abzulesen sein, wie hoch die Gesamtsumme der auszuschüttenden Tantiemen für die Filtereinstellungen ist, wie viel Steuern und Kommission von der ausschüttenden Verwertungsgesellschaft sowie der Ursprungsgesellschaft¹⁸ einbehalten wurden und wie hoch die Summe ist, die schließlich an die Berechtigten ausgezahlt wurde.

Um die Weiterverarbeitung der Daten, beispielsweise in Excel, zu ermöglichen, können die gefilterten Detaildaten über einen Export als kommaseparierte Textdatei (CSV) gespeichert werden.

Ist der Filter auf ein Werk gesetzt, werden zusätzlich die Informationen zur Aufteilung der Urheber- bzw. Verlagsrechte angezeigt, auf deren Basis die Aufteilung der Tantiemen erfolgt ist. Für Verlage ist dies ein wichtiges Kriterium, da teilweise nicht erkennbar ist, ob die Verwertungsgesellschaft dem Verlag nur die ihm zustehenden Tantiemen oder aber ebenfalls die Tantiemen der von ihm vertretenen Urheber*innen überwiesen hat, welche dann ggf. weiterzuleiten wären. Anhand der Verteilung der Anteile des gefilterten Werkes wird jedoch ersichtlich, auf welcher Basis die Verwertungsgesellschaft die Abrechnung durchgeführt hat (siehe Abb. 7.20).

Abb. 7.20

Anzeige der Werkbeteiligungen, auf deren Grundlage die Tantiemenaufteilung berechnet wurde

7.1.3.5 Fazit

Gemein ist beiden beschrieben Programmen, dass die Rohdaten in einer semantisch unabhängigen, strukturierten Form dargestellt werden können. Die oberste Ebene stellt dabei die Darstellung des „Envelope“ der Transaktionen dar, welcher durch die Definition in der CIS-EDI-Spezifikation bei allen darauf basierenden Daten gleich ist.

Neben der strukturierten Darstellung der den Envelope betreffenden Records (in Abb. 7.21 wird der Inhalt des ersten Group-Header angezeigt), können auch die in der jeweiligen Gruppe vorhandenen Transaktionen ausgewählt und dargestellt werden.

Abb. 7.21

Envelope von CIS-EDI Daten

Aus dieser Liste kann nun eine Transaktion ausgewählt und alle zugehörigen Records betrachtet werden. In dem in Abb. 7.22 dargestellten Beispiel handelt es sich um die „MWN“-Gruppe, welche alle Werke der Abrechnung einer CRD-Datei enthält.

Abb. 7.22

Liste der Transaktionen einer Gruppe

In der Detailansicht werden schließlich alle zur Transaktion zugehörigen Records angezeigt (Abb. 7.23). Dabei kann jeweils ein Record „aufgeklappt“ werden, sodass die nach Datenfeldern aufgeteilten Feldinhalte angezeigt werden. Dies kann im Falle technischer Fragestellungen interessant sein, bspw. wenn Unklarheiten über Detaildaten bestehen, die anhand der Zusammenfassung nicht geklärt werden können. Diese Ansicht kann automatisch aus der Definition der Klassen und Eigenschaften, die von der jeweiligen Spezifikation abgeleitet werden, generiert werden und steht damit so für jedes weitere eventuell in der Zukunft hinzukommende Programm zur Verarbeitung von CIS-EDI-Formaten zur Verfügung.

Abb. 7.23

Detailansicht einer Transaktion

Die beiden vorgestellten Programme geben ein weiteres Beispiel, wie mit den CIS-EDI-Formaten softwareseitig umgegangen werden kann. Gegenüber dem Ansatz der grammatikbasierten Parsergeneratoren (siehe Abschn. 7.1.1) lag den hier vorgestellten Applikationen ein stärker anwendungsorientierter Fokus zugrunde.