Title
Contents
In der Einleitung wurde bereits erwähnt, daß die hier vorgestellte Planung zunächst die Realisierung einer in der Praxis testbaren Rumpfversion eines COGET-Prototypen vorsah, die dann sukzessive durch Realisierung weiterer Module ergänzt werden kann. Dementsprechend erfolgt hier zunächst die Beschreibung des Umfangs der Rumpfversion, daran anschließend werden mögliche Erweiterungen dieses Basissystems vorgestellt. In diesem Kapitel erfolgt eine allgemeine Beschreibung der inhaltlichen Umfänge der einzelnen Arbeitspakete, das nächste Kapitel geht genauer auf die jeweils anfallenden Einzelaufgaben und den dabei erwarteten Zeitaufwand ein.
Zunächst soll jedoch zum Abstecken eines Zielrahmens eine aus arbeitsorganisatorischer Sicht "ideale Vorgehensweise" bei der soFid-Produktion bzw. der ideale Leistungsumfang der hierbei verwendeten Software vorgestellt werden.
Eine Software zur soFid-Redaktion würde idealerweise die folgenden Anforderungen erfüllen:
1. Die Recherche zur Bestimmung der Grundmenge an soFid-relevanten DE wird komfortabel unterstützt (hohe Precision, einfache Formulierungsmöglichkeiten)
2. Ein Ausdruck der ermittelten Grundmenge an DE wird überflüssig, damit Verringerung des Papierverbrauchs
3. Eine manuelle Erfassung von Daten (z.B. ISN-Nummern und vergebenen Kapitelnummern) ist nicht nötig
4. Die Zuordnungen von DE zu soFid und Sachgebiet werden automatisch in aDIS vermerkt und stehen somit auch für andere Zwecke zur Verfügung
5. Die Produktion findet weitgehend am Arbeitsplatz des Redakteurs statt, sofern dabei gewährleistet werden kann, daß der entstehende Output eine einheitliche Gestaltung und entsprechende inhaltliche Qualität aufweist.
Punkt 1 führt vor allem zur Unterstützung eines iterativen Retrievals bis Umfang und Qualität der Grundmenge vom Rechercheur als ausreichend angesehen werden. In diesem Zusammenhang wäre auch das Testen und Vergleichen verschiedener bereits eingesetzter und weiterer denkbarer Recherche-Strategien sinnvoll.
Punkt 2 und 3 stehen in enger Verbindung miteinander und sind nur zu erreichen, wenn der Ersteller des soFids die inhaltliche Selektion aus der DE-Grundmenge durch die Software unterstützt am Bildschirm vornimmt. Kritisch ist hier vor allem, daß zur Relevanzbeurteilung und Einordnung am Bildschirm längere Texte gelesen werden müssen (Abstracts), was bekanntermaßen gegenüber dem Lesen von gedruckten Texten Nachteile mit sich bringt (schnellere Ermüdung durch geringeren Kontrast und geringere Schärfe, kleinerer Textausschnitt gegenüber Betrachtung von A4-Seiten etc.). Denkbar zur Entlastung von der reinen Bildschirmarbeit sind hier Mischformen der Arbeit, wobei etwa das Lesen der Texte in einem Ausdruck erfolgt, eine Zuordnung der DE jedoch am parallel verwendeten Bildschirm durchgeführt wird. Aber auch diese Art der Arbeitsgestaltung ist ergonomisch nicht unbedenklich, da sie zu einer vermehrten Augenbelastung durch häufiges Wechseln der Blickebene (Papier vs. Bildschirm) führt. Die Auswirkungen einer entsprechenden Arbeitsweise wären im Einzelfall zu testen.
Im Fall einer bildschirmorientierten Bearbeitung kann die Kapitelzuordnung der DE ebenfalls sofort erfaßt und abgespeichert werden. Dabei können die jeweils aktuellen Zahlen und Titel der DE pro Kapitel angezeigt werden, so daß hier ohne die bisher nötige manuelle Arbeit eine stets aktuelle Übersicht über die Umfänge bestehen würde.
Punkt 4 kann grundsätzlich auch unabhängig von der Erstellung eines COGET-Prototypen realisiert werden. Hier ist als Grundvoraussetzung eine Ergänzung der aDIS-Tabellenstrukturen zur Aufnahme der soFid-Verwei-sungen nötig. Die Realisierung in einem Prototypen könnte hier die Referenzen direkt im Online-Verfahren speichern, während die Übernahme bei Beibehaltung der alten Arbeitsabläufe die Ausführung eines weiteren Programms im Batch-Betrieb erfordern würde.
In der Grundstufe der COGET-Prototyp-Realisierung würde am Anfang der soFid-Redaktion wie bisher die Recherche nach relevanten DE in aDIS ausgeführt. Die Ausgabe der Ergebnismenge an DE würde in eine Token-Datei erfolgen und diese in eine PC-LAN-Version von Oracle übernommen werden.
Zur Funktionalität der Rumpfversion würde somit eine Import-Möglichkeit für aDIS-Daten im Tokenformat gehören müssen. Vorversionen entsprechender Konvertierroutinen zu diesem Zweck sind bereits vorhanden.
Hauptfunktionalität des ersten Prototypen wäre die Unterstützung der inhaltlichen Selektion und Zuordnung. Zur Übernahme in den weiteren Produktionsprozeß würde eine Datei erstellt, die die Schlüsselangaben zu DE und ihren Zuordnungen im heute gängigen Format enthält. Dies ist die sogenannte Argumentedatei, die von der EDV-Abteilung zum Abzug der entsprechenden Daten aus aDIS verwendet wird.
Durch den Einsatz einer Version mit diesem Leistungsumfang würde hauptsächlich der momentan hohe Aufwand bei der manuellen Erfassung der Angaben zu den ausgewählten DE entfallen. Aber auch für den einzelnen Redakteur ergeben sich beim Einsatz eines solchen Prototypen bereits einige Vorteile durch den Wegfall manueller Tätigkeiten wie etwa dem Umsortieren und Auszählen von "Kapitelhaufen". Eine fortlaufende Statistik zu Kapiteln und zugeordneten DE kann einfach implementiert werden, damit ist ein kontinuierlicher Überblick über die momentanen Kapitelumfänge möglich.
Für die Akzeptanz der Basisversion bei den Redakteuren ist es von zentraler Wichtigkeit, ob bereits der Einsatz dieser Software für die einzelnen Mitarbeiter eine spürbare Arbeitserleichterung bzw. Zugang zu gewünschter bislang nicht vorhandener Funktionalität bietet.
Im Folgenden werden Ausbaumöglichkeiten nach dem Vorliegen einer Rumpfversion des Prototypen vorgestellt. Die Behandlung erfolgt dabei im Hinblick auf eine mögliche bzw. sinnvolle Reihenfolge der Realisierung. Die Reihenfolge ist dabei nicht fest vorgegeben, sondern kann in Teilen an die jeweiligen Erfordernisse angepaßt werden. Auch müssen nicht alle Teilpakete realisiert werden, damit ein einsetzbares bzw. in der Praxis testbares System entsteht. An dieser Stelle werden zunächst nur Vorschläge für entsprechende Komponenten unterbreitet und die entstehenden Aufwände geschätzt.
Die getrennte Realisierbarkeit eines Funktionsbereichs war für die Gliederung das grundlegende Kriterium für seine Formulierung als separate Ausbaustufe bzw. eigenes Modul. Dabei sind jedoch einige Interdependenzen zwischen den Paketen zu beachten, die jeweils im Einzelfall angesprochen werden.
Ein sinnvoll auf die Rumpfversion folgender Ausbau wäre die Realisierung von Ausdruckfunktionen in einer dem endgültigen Produkt angenäherten oder möglichst identischen Form. Hier wäre neben dem Komplettausdruck des gesamten soFids auch der probeweise Ausdruck des aktuellen Standes einzelner Kapitel vorstellbar. Auch der Druck von Kurzformen wie z.B. ein Ausdruck ohne Abstract oder der Druck von wenigen, inhaltlich zentralen Feldern wie Titel, Deskriptoren und Abstract sollte möglich sein. Hier ist es von den Wünschen der soFid-Redakteure abhängig, was realisiert werden sollte. Von der verfügbaren Zeit und den technischen Möglichkeiten ist es dagegen abhängig, wie weit dabei individuelle Vorlieben durch Konfigurierbarkeit des Ausdrucks entgegengekommen werden kann.
Die Integration der Druckaufbereitung in Richtung auf die Erstellung des vollständigen soFid am Arbeitsplatz des Redakteurs verspricht Vorteile, da dadurch bislang zentral mit dieser Aufgabe befaßte Mitarbeiter entlastet werden könnten. Bei Verwendung einer datenbankbasierten Anwendung und bei Erstellung der Ausgabe durch entsprechende Reporting-Funktionalitäten ist ein Output mit einheitlichem Aussehen wesentlich einfacher zu gewährleisten als dies bei Verwendung einer Lösung auf der Basis eines Textverarbeitungs-Programms gegeben wäre.
Die Erstellung des Registers bei der soFid-Produktion zieht keinen besonders hohen manuellen Aufwand nach sich, da hier im Unterschied zur Erstellung von anderen Themendokumentationen weder ein zweistufiges Register erzeugt wird, noch werden die verwendeten Registerbegriffe intellektuell bestimmt. Statt dessen erhält jede DE automatisch einen Registereintrag für jeden zu ihr vergebenen Deskriptor. Aufgeweicht wird diese Regelung lediglich durch eine soFid-spezifische Deskriptoren-Ausschlußliste. Hierin werden diejenigen Deskriptoren vermerkt, die wegen ihrer großen Häufigkeit im jeweiligen soFid keine sinnvollen Registereinträge darstellen.
Eine Registererstellung innerhalb des COGET-Prototypen dient daher vordringlich der Ergänzung der Druckfunktionalitäten. Dadurch soll mittelfristig die nachträgliche Bearbeitung in einer Textverarbeitung möglichst überflüssig werden und der Druck der gesamten Publikation dezentral durch den Redakteur möglich sein.
Eine zusätzliche Unterstützungsmöglichkeit ergibt sich hier bei der Verwaltung der Liste von aus dem Register auszuschließenden Deskriptoren. Eine bereits angesprochene einfache Deskriptorenstatistik zur aktuellen soFid-Ausgabe könnte hier zur Anzeige der häufigsten und somit wenig aussagekräftigen Deskriptoren führen. Auf dieser Basis könnte eine einfach handhabbare und flexible Möglichkeit zum Register-Ausschluß der gewünschten Deskriptoren realisiert werden.
Bei den jetzigen Arbeitsabläufen müssen gefundene Fehler entweder noch in einem Ausdruck markiert und zur Änderung weitergegeben werden oder vom Redakteur direkt in aDIS korrigiert werden. Wegen der möglichen Verwendung von DE in verschiedenen soFids wird dabei ein Fehler oftmals von mehreren Redakteuren angestrichen und weitergegeben. Der für die Korrekturen zuständige Bearbeiter muß hier in der Regel jedesmal neu prüfen, ob die Änderung nicht schon erfolgt ist.
Ein fortgeschrittener Prototyp könnte mit direkter Anbindung an die aDIS-Daten arbeiten. Die Ergebnismenge der Ausgangsrecherche würde dann innerhalb der Datenbank als Menge von Dokumentschlüsseln gespeichert werden. Bei jeder Bearbeitung würde dabei der aktuelle Stand der entsprechenden DE am Bildschirm zur Verfügung stehen. Mittels dieser direkten Anbindung könnten gegebenenfalls auch die nach dem Entdecken von Fehlern notwendigen Korrekturen online vorgenommen werden und würden somit sofort für alle Beteiligten sichtbar sein. Die dabei auftretenden Fragen der Zugangskontrolle (z.B.: Welche Felder sind zur Korrektur zugelassen, welche nicht) und der technischen Realisierung sind nach Einführung der neuen, auf Oracle aufsetzenden aDIS-Version zu klären.
In Kapitel wurde bereits angeführt, daß die bei der soFid-Produktion geleistete Arbeit einer zusätzlichen inhaltlichen Erschließung der DE bislang nicht gespeichert wird und somit nicht für andere Zwecke (z.B. inhaltliche Recherchen nach soFid-Kapitelbezeichnungen in aDIS) zur Verfügung steht. Ist eine direkte aDIS-Anbindung bei der soFid-Erstellung realisiert, so könnten auch die Zuordnungen von DE zu den jeweiligen soFid-Ausgaben und Kapiteln dauerhaft in der Datenbank festgehalten werden. Neben der bereits erwähnten zusätzlichen Recherchemöglichkeit ergeben sich auch innerhalb der soFid-Produktion noch weitere Verwendungsmöglichkeiten für diese Daten. Diese erweiterten Möglichkeiten werden in Kapitel angesprochen. Für diesen zweiten Verwendungsbereich ist eine zentrale Speicherung der Zuordnungen in aDIS nicht unbedingt notwendig, die benötigen Daten könnten für eine prototypische Realisierung auch in einer lokalen Datenbank gehalten werden. Sie stünden dann jedoch nur dem jeweiligen Bearbeiter und nicht zu allgemeinen Recherchezwecken zur Verfügung.
Was in Kapitel über die Fehlerkorrektur in den DE-Angaben im Allgemeinen gesagt wurde, gilt auch für die Korrektur von Rechtschreibfehlern im Besonderen. Dabei stellt zwar die Korrektur von Schreibfehlern in den DE-Angaben (v.a. Abstract und Titel) nicht unbedingt eine zentrale Arbeitsaufgabe der soFid-Produktion dar, beim Lesen gefundene Fehler werden aber durchaus vermerkt und bislang an andere Mitarbeiter zur Ausbesserung in aDIS weitergeleitet. Sobald jedoch eine direkte aDIS-Anbindung bei der soFid-Produktion zur Verfügung steht, macht die sofortige und direkte Korrektur gefundener Fehler durch den Redakteur mehr Sinn als eine aufwendige Weiterleitung der Aufgabe. Das Korrekturlesen der Texte könnte dabei durch eine automatische Rechtschreibprüfung unterstützt werden. Grundvoraussetzung hierfür ist das Vorliegen eines möglichst umfassenden Wörterbuchs mit allgemeinem und speziell sozialwissenschaftlichem Vokabular. Eine eingekaufte Komponente zur Integration von Rechtschreibprüfungen in PowerBuilder-Anwendungen ist im Haus bereits vorhanden. Diese wird mit einem deutschen Standardwörterbuch ausgeliefert. Notwendige Erweiterungen dieses Wörterbuchs für IZ-Zwecke sind beispielsweise durch Übernahme der Thesaurusbegriffe (über 6.000 Deskriptoren in geprüfter Schreibweise) zu bewerkstelligen. Eine Mehrfachnutzung dieses erweiterten Wörterbuchs ist möglich, da es sich nach einer entsprechenden Konvertierung u.a. auch für die Verwendung bei der Textverarbeitung im Haus heranziehen ließe.
Längerfristig ist eine automatische Rechtschreibprüfung von Angaben zu DE jedoch sinnvollerweise in den Arbeitsbereich der Neuerfassung bzw. dem Import von DE zu verlagern, damit von Anfang an und durchgängig (nicht alle DE tauchen in soFids auf) mit möglichst fehlerfreien Texten gearbeitet werden kann. Für eine prototypische Realisierung ist eine entsprechende, später generalisierbare Komponente bei der soFid-Produktion jedoch durchaus denkbar.
Bei der Betrachtung des Arbeitsbereiches soFid-Erstellung lassen sich einige Anwendungsgebiete für eine automatische Ermittlung von Ähnlichkeiten zwischen verschiedenen DE bzw. DE-Mengen feststellen. Wichtige Grundlage für einen Vergleich von DE sind die zu ihnen vergebenen Deskriptoren. Durch entsprechende statistische Verfahren könnten Ähnlichkeiten zwischen DE aus der Ähnlichkeit der zugeordneten Deskriptorenmengen deduziert werden. Ganz allgemein ist hier eine Sichtung der in der Literatur zu findenden Algorithmen und ihre Bewertung hinsichlich eines Einsatzes mit den IZ-Datenbanken durchzuführen. Diese Aufgabe kann unabhängig von der Erstellung des COGET-Prototypen allgemeiner angegangen werden und geht nicht in die Aufwandsabschätzung für dieses Projekt ein.
Im Folgenden soll kurz vorgestellt werden, wo sich die Bestimmung von DE-Ähnlichkeiten im soFid-Bereich sinnvoll einsetzen läßt. Innerhalb des COGET-Prototypen könnten dabei die Gestaltungsaspekte von entsprechenden Ähnlichkeits-Komponenten schon realisiert werden, auch wenn eine umfassende Evaluation verschiedener Ähnlichkeitsmaße noch nicht durchgeführt wurde. Hierzu bietet sich die "provisorische" Implementation entsprechender Komponenten mit einem einfachen statistischen Ähnlichkeitsmaß an. Nach Evaluation verschiedener Ähnlichkeitsmaße ließe sich dieses ad hoc-Verfahren vermutlich auf relativ einfache Weise durch den geeignetsten Algorithmus ersetzen, ohne daß dabei die Gestaltung der Oberflächenfunktionalität in größerem Umfang zu ändern wäre.
Während der soFid-Erstellung ordnet der Redakteur einzelnen Kapiteln bestimmte DE zu. Liegen die Informationen über die Zuordnungen in Zukunft in elektronischer Form vor (z.B. von den vorangegangenen soFid-Ausgaben), so lassen sich hieraus unter anderem Statistiken über die Häufigkeit, Zielgenauigkeit und Kombinationen von Deskriptoren für bestimmte Kapitel erstellen, die unter anderem zur automatischen Erstellung von Zuordnungsvorschlägen zu DE eingesetzt werden könnten.
Ein solches Verfahren würde dann Sinn machen, wenn dadurch Arbeitsaufwand beim Redakteur einzusparen wäre. Dazu müßte eine solche Komponente als Grundvoraussetzung relativ treffsicher sein, d.h. die meisten der vorgeschlagenen Zuordnungen müßten den intellektuell gewählten entsprechen. Weiterhin müßte die Übernahme der richtigen automatischen Zuordnungen plus das Korrigieren der falschen weniger aufwendig sein als eine rein intellektuelle Arbeitsweise. Da jedoch auch zur Überprüfung der Vorschläge die wichtigen Inhaltsfelder gelesen werden müssen und der erwartete Aufwand für die reine Herstellung der Zuordnung gering ist, könnte es sich herausstellen, daß die Nutzeffekte einer Vorschlagskomponente ebenfalls gering ausfallen.
An dieser Stelle werden dennoch Grundüberlegungen zur Realisierung einer solchen Komponente ausgeführt, da die Bestimmung von DE-Ähnlichkeiten auch in anderen Arbeitszusammenhängen (z.B. für intelligente Retrievalverfahren) von großem Interesse ist. Auch hier ergibt sich somit ähnlich wie bei der automatischen Rechtschreibprüfung die Situation, daß im COGET-Prototypen Funktionsbereiche testweise realisiert werden können, die später für andere Arbeitsgebiete zentral werden könnten.
In einer ersten möglichen Realisierung einer Vorschlagskomponente zur Kapitelzuordnung könnte der Redakteur eine einfache Häufigkeitsstatistik der Deskriptoren je Kapitel bekommen, er wählt daraus ihm sinnvoll erscheinende, "prototypische" Deskriptoren bzw. -mengen. Das Vorhandensein entsprechender Deskriptoren für noch nicht zugeordnete DE würde dann bei der Bearbeitung zu einem entsprechenden Systemvorschlag für eine Kapitelzuordnung führen.
Elaboriertere Verfahren würden z.B. die "prototypischen" Deskriptoren automatisch ermitteln, in einer ersten Näherung beispielsweise durch Betrachtung der Häufigkeit eines Deskriptors für ein bestimmtes Kapitel im Vergleich zu seiner Häufigkeit für andere Kapitel.
Eine einfache Häufigkeitsstatistik für Deskriptoren ist leicht zu realisieren. Auf dieser Basis könnten bereits erste Überprüfungen dahingehend erfolgen, ob eine darauf aubauende Vorschlagskomponente zufriedenstellend (treffsicher) arbeiten würde und wie sie in den Arbeitsprozeß zu integrieren wäre. Reicht die Treffsicherheit einfacher Verfahren für einen Einsatz in der Praxis nicht aus, so muß die Wirksamkeit komplexerer statistischer Verfahren untersucht werden. Ihre Wirksamkeit sollte aber in Hinblick auf noch mögliche Verbesserungen auch getestet werden, wenn schon mit einfachen Verfahren ein positives Resultat erzielt wurde.
Die im letzten Abschnitt beschriebene Vorschlagskomponente zur Zuordnung auf der Basis von DE-Ähnlichkeiten hat wahrscheinlich wenig Auswirkungen auf den bei der Zuordnung von DE zu betreibenden Aufwand, da sie erst nach der eigentlichen Recherche ansetzen würde, somit bleiben Größe und Precision der Recherchenmenge unverändert. Schon beim Recherchieren für die soFid-Erstellung eingesetzt, könnten DE-Ähnlichkeiten viel eher mit positiven Resultaten verwendet werden, da sich durch entsprechende Verfahren die Precision in der Ergebnismenge vermutlich deutlich erhöhen ließe. Grundlage für eine ähnlichkeitsbasierte soFid-Recherche ist das Vorliegen der Kapitelzuordnungen aus mindestens einer vorangegangenen Ausgabe. Anhand dieser vorliegenden Zuordnungen würden Deskriptorenmengen gebildet, die für eine kapitelspezifische aDIS-Recherche nach neu aufgenommenen, ähnlichen DE verwendet werden könnten. Diese Art der Recherche hätte damit eine Doppelfunktion, neben der reinen Bestimmung der DE-Grundmenge würde dabei sofort auch eine vorgeschlagene Kapitelzuordnung für jede enthaltene DE "abfallen".
Bei diesem Grundansatz ist zunächst fraglich, ob alle Dokumente innerhalb eines soFid-Kapitels einander so ähnlich sind, daß sie sich über ihre Deskriptoren sinnvoll in einer Gruppe zusammenfassen lassen. Nur in diesem Fall wäre das einfache Schema der Durchführung genau einer Recherche nach einer ausgewählten Deskriptorenmenge pro Kapitel tragfähig. Da dies nicht zu erwarten ist, sind hier generalisierte Lösungsansätze in Betracht zu ziehen. Eventuell ist es möglich, DE zu einem Kapitel automatisch in mehrere Gruppen oder Cluster großer Ähnlichkeit zu gliedern, deren Merkmale dann jeweils in einer eigenen Recherche abgebildet werden können.
Zu berücksichtigen ist bei dem vorgestellten Verfahren, daß die empirische Basis, d.h. die zum "Anlernen" des Systems herangezogenen intellektuellen Zuordnungen, groß genug sein muß, um bei zukünftigen Recherchen nicht Themenbereiche auszuschließen, die nur gelegentlich in einem Kapitel auftauchen.
Eine potentielle Gefahr eines solchen Verfahrens besteht auch darin, daß die auf diese Weise entstehenden Recherchemuster durch ihre Spezifität auftretende Schwerpunktverlagerungen innerhalb eines Themengebietes ignorieren könnten. Bei größeren thematischen Veränderungen fielen entsprechende neue DE nicht in eine der vorhandenen inhaltlichen Gruppen, sie würden somit aus der Recherche insgesamt herausfallen. Um das Ausmaß dieses angenommenen Effekts beurteilen zu können sind jedoch genauere Betrachtungen notwendig. Dazu gehört unter anderen eine Untersuchung, in welchem Ausmaß sich die Vergabe von bestimmten Deskriptoren zu übergeordneten Themenbereichen verändert bzw. in welchem Ausmaß hier neue Deskriptoren auftauchen.
Sind thematische Schwerpunktänderungen nicht zu gravierend bzw. rasant, so könnte eine kontinuierliche Adaptierung des Systems dadurch erfolgen, daß nach dem Abschluß jeder soFid-Ausgabe die Aufteilung der Kapitel-DE in inhaltliche Gruppen neu "gelernt" bzw. angepaßt wird.
Sofern entsprechende allgemeine Werkzeuge zur Durchführung von Recherchen zur Verfügung stehen, könnten diese auch in einem COGET-Prototypen zur Anwendung kommen. Die im vorigen Kapitel angedeuteten Recherchemöglichkeiten über DE-Ähnlichkeiten ließen sich zum Teil sicherlich auch dann schon realisieren, wenn noch keine komplette Recherche-Umgebung zur Verfügung steht. Im Sinne umfangreicher Recherchemöglichkeiten und einer Vereinheitlichung der Oberfläche wäre die Integration entsprechender Werkzeuge jedoch sehr wünschenswert. Ist dies gegeben, dann wäre eine komplette Erstellung von soFids von der Recherche bis zur Druckausgabe mit nur einem Werkzeug grundsätzlich möglich. Die Realisierung eines allgemeinen Recherche-Werkzeuges stellt jedoch eine umfangreiche Aufgabe dar, die als separates Projekt angegangen werden sollte und daher hier nicht in die Planung eingeht.
Title
Contents