Categories
Artikel

ODRAlighthouse – Das Redaktionsdeck für #projektODRA

Das im Oktober 2019 gestartete #projektODRA (Ordnen, Deuten, Richtigstellen, Annähern) hat die Entwicklung einer Infrastruktur zum Ziel, auf deren Basis auf aktuelle geschichtspolitische Debattenbeiträge zum deutsch-polnischen Verhältnis reagiert und digital interveniert werden kann. Wichtigster Bestandteil dieser Infrastruktur ist eine zweisprachige (deutsch-polnische) Redaktion, die sich gerade im Aufbau befindet. Die Aufgabe unserer Gruppe am Institut für Digital Humanities (IDH) ist die Entwicklung eines webbasierten Tools, das die Redaktion sowohl zur Identifikation von relevanten Debattenbeiträgen, als auch zur internen Kommunikation verwenden kann. Der Arbeitstitel dieses Tools, dessen Entwurf und Entwicklung ich hier vorstellen möchte, ist ODRAlighthouse.

#projektODRA ist ein polnisch-deutsch-schweizer Kooperationsprojekt, das von der Stiftung EVZ (Erinnerung – Verantwortung – Zukunft, Berlin) gefördert wird. Das Team besteht aus Marko Demantowsky, Björn Klein und Marvin Rees (FHNW und Universität Basel), Krzysztof Ruchniewicz und Dominika Uczkiewicz (Centrum Willy Brandta, Uniwersytet Wrocławski), Moritz Hoffmann (freier Historiker, Walldorf) sowie schließlich Dennis Demmer und mir (IDH Köln). Während es die Aufgabe unserer Partner ist, das Redaktionsteam zu bilden und dabei Themen zu recherchieren, in Videos aufzuarbeiten und diese aktiv zu bewerben, arbeiten wir in Köln das Redaktionstool ODRAlighthouse aus, das in einer Alpha-Version bereits zur Mitte der Projektlaufzeit ab März von der Redaktion erprobt werden soll.

[Beitragsbild: Neue Oderbrücke bei Frankfurt – Stähler und Knoppik GmbH – CC BY-SA 3.0 ]

Projekttreffen am Campus Muttenz. Foto: Krzysztof Ruchniewicz

In der Projektfindungsphase stand die Idee, ein Monitoring-Tool zu entwickeln, das in der Lage ist, vollautomatisch Diskurse in den Weiten des Internets, die das deutsch-polnische Verhältnis betreffen, zu identifizieren und im besten Fall auch noch den Grad des toxischen Gehalts von Wortmeldungen in diesen Diskursen zu ermitteln. Eine intelligente Maschine quasi, die in der Lage ist, das gesamte Internet zu lesen, nach Relevanz zu ordnen und in diesem Zuge direkt zu bewerten. Natürlich ist ein solches Tool nicht innerhalb eines Jahres und mit dem Budget, über das wir verfügen können, zu bauen. Wahrscheinlich würde ein wirklich für diese Aufgaben hilfreiches Tool selbst von einer großen Firma des Silicon Valley nicht binnen Jahresfrist entwickelt werden können. Aus diesem Grund überlegten wir erst einmal, welche Funktionalitäten überhaupt erreichbar sind und ordneten sie nach ihrer Wichtigkeit.

Sammeln: Eine Armee von Scrapern

Zunächst ging es uns darum, für die Redaktion potentiell relevante Informationen erst einmal zu sammeln. Dabei wollten wir Webseiten von großen Medienerzeugnissen genau so einbeziehen wie Blogs und Social Media Posts. Für Facebook und Twitter gibt es APIs, die man für den Zugriff nutzen kann. Blogs und Nachrichtenseiten bieten meist einen RSS-Feed an, auf dem man zumindest lauschen kann, ob und wann es neue Veröffentlichungen auf diesen Plattformen gibt. Um an die Volltexte zu gelangen, muss man dann noch etwas bauen, was diese von den Webseiten einsammelt – sogenannte Scraper. Der Aufwand der Scraperprogrammierung ist für jedes Webportal einzeln zu leisten und sie funktionieren tun die nur so lange, wie sich das Seitendesign oder die verwendeten Gliederungselemente nicht ändern. Es ist also ein einigermaßen hoher Aufwand, Content im Web einzusammeln. Dieser lässt sich allerdings in viele kleine, abgeschlossene und nicht uninteressante Aufgaben zerlegen. Da traf es sich ganz gut, dass ich im Wintersemester eine Lehrveranstaltung zum Thema „(Fake) News Detection“ angeboten habe, in der sich als eine der Programmierübungen für die Studierenden die Implementation eines Scrapers mehr als anbot.

Auf diese Weise kamen bisher 28 Scraper für Webseiten polnischer und deutscher Medien zusammen, die meisten davon in Python oder Java, aber auch zwei, die in Node.js programmiert wurden. Da stellt sich natürlich die Frage, wie so verschiedene Scraper orchestriert werden können. Die Antwort darauf ist „Microservices + Docker“ und Dennis hat das entsprechende Framework dazu gebaut. Die Studierenden mussten ihre eigenen Scraper als Webservice verpacken und dann in einen Docker-Container stecken. Was jetzt wahrscheinlich nur IT-Kennern etwas sagt, ist tatsächlich eine feine Architektur, mit der man quasi mehrere Maschinen (mit unterschiedlichen Laufzeitumgebungen und verwendeten Bibliotheken) über eine zentrale Instanz – hier den von Dennis entworfenen ScraperController, der als eigener Webservice in einem eigenen Docker-Container läuft – ansteuern kann (das wird auch alles noch ausführlicher dokumentiert, versprochen). Ergänzt werden diese Webseitenscraper schon von einem Twitter-Interface, über das man Tweets mit Suchtermen speichern kann. In Arbeit sind ein Reddit-Interface und der Facebook-Zugriff.

Sortieren: Ein Client für die Übersicht

Bisher sind schon gigabyteweise Daten zusammengekommen (nur Text!), die in Form der Datenbank, in der sie landen nun niemandem wirklich nutzen können und auf irgendeine Weise sortiert werden müssen. Wir haben uns entschlossen, diese Sortierung mehrstufig zu implementieren. Der erste Schritt ist, jedem Redakteur und jeder Redakteurin eine übersichtliche Arbeitsoberfläche zur Verfügung stellen, die nach den eigenen Vorstellungen befüllt werden kann. Weil die Zusammenstellungen der Informationen dabei sehr unterschiedlichen Prämissen folgen kann (bestimmte Medien, bestimmte Themen, bestimmte Schlagwörter, bestimmte Twitter-Feeds etc.) fühlten wir uns an TweetDeck erinnert. TweetDeck ist ein Twitter-Client, bei dem man mehrere Timelines nebeneinander stellen kann, um die eigenen Notifications, Direct Messages, Likes, ausgewählte Nutzer|innen etc. auf einen Blick wahrnehmen zu können. Dieses Design, das vor allem auf Spalten beruht, die beliebig sortiert und durch neue Spalten ergänzt werden können, erschien uns auch für unseren ODRA-Client sinnvoll.

Screenshot von ODRAlighthouse – man sieht dem Client das TweetDeck-Vorbild an.

Das ODRAlighthouse, wie Dennis den Client nannte, bietet verschiedene Sichten auf den von den Scrapern gesammelten Datensatz. Die Sortierung erfolgt also erst einmal nur optisch bzw. anhand der regulären Ausdrücke, welche die Redaktionsmitglieder bei der Anlage ihrer Spalten auswählen. Was hier noch ergänzt werden soll, ist eine Vorauswahl des Contents über Relevanzkriterien. Hierfür haben wir uns zwei Strategien überlegt – Kommunikation und Maschinelles Lernen. Diese sind bisher allerdings noch nicht implementiert (schließlich läuft das Projekt auch erst seit knapp 4 Monaten).

Kommunizieren: Austausch über Relevantes

ODRAlighthouse wurde nicht nur als Darstellungstool für einzelne Mitglieder entworfen, sondern soll auch der Ort sein, an dem sich Redaktionsmitglieder über Artikel und Themen austauschen können (schließlich liegen diese ja genau dort vor). Das soll einerseits über Chatgruppen, vor allem aber durch Annotation der gespeicherten Informationen ermöglicht werden. So können Artikel oder Posts als besonders relevant markiert oder gleich spezifischen Themenbereichen oder anderen Redaktionsmitgliedern zugewiesen werden. Diese Funktionalitäten sind erst angedacht, sollen aber in engem Austausch mit der Redaktion entworfen und umgesetzt werden. Ziel unseres Tool ist es nicht zuletzt, auch über den Horizont unseres Projektes hinaus zu ähnlichen Zwecken eingesetzt werden zu können. Deshalb entwickeln wir (wie gewohnt) auch wieder Open Source. Den Code der derzeitigen Version des React-Clients findet man auf GitHub unter DH-Cologne.

Delegieren: Maschinen lernen lassen

Ein wenig Zukunftsmusik ist auch noch der Einsatz von maschinellen Lernverfahren zum Ranking bzw. zur Auswahl potentiell relevanter Posts und Artikel. In meiner oben erwähnten Übung haben wir zwar unterschiedliche Ansätze zur automatischen Erkennung von Fake News und spezifischen Verbreitungspatterns thematisiert, meiner Ansicht nach ist die Forschung auf dem Gebiet aber einerseits relativ jung, andererseits aber durch dauernd neue Randbedingungen (z.B. Zugriffs-Policies sozialer Medien) schon wieder veraltet, bevor sie veröffentlicht wird. Oder sie läuft gleich ganz in Bereiche, die auf Grundlage meines wissenschaftlichen Sachverstands so überhaupt nicht nachvollziehbar finde (Stichwort Botforschung). Gleichviel, in Maschinellen Lernverfahren, vor allem in Deep Learning Ansätzen, steckt Potential, das man nicht einfach so liegen lassen kann. Unsere Strategie ist nun, dieses Potential für die bei uns anstehenden Aufgaben in studentischen Projektarbeiten evaluieren zu lassen. Das hilft nicht nur uns im Projekt, sondern auch den Studierenden, die ihre Skills in dem Bereich (an denen hohe Nachfrage besteht) anhand echter Daten und echter Problemstellungen weiterentwickeln können. Diese enge Verzahnung von praktischer Arbeit, Forschung und Lehre versuche ich so oft wie möglich zu realisieren.

Komponieren: Wie bringt man das zusammen?

Die Grundarchitektur des Projektes ist, wie schon oben erwähnt, auf Docker und Microservices aufgebaut. Viele verschiedene Scraper werden über einen zentralen ScraperController angesteuert, der ihre gescrapten Inhalte in eine Datenbank speichert. Auf diese Datenbank haben die Clients der einzelnen Redaktionsmitglieder Zugriff, die sich ihre Rechercheoberfläche selbst zusammenstellen können und die Möglichkeit bekommen, sich innerhalb dieser mit den anderen Mitgliedern auszutauschen. Sehr zeitraubend war unter anderem auch die Implementation zahlreicher Sicherheitsaspekte in der Nutzerverwaltung (Code hier), die Dennis bravourös gemeistert hat. Alles ist nun so gekapselt, dass nach außen nur der Client sichtbar ist, für den man allerdings einen Login braucht. Dieser ist nötig, da man vom Client nicht nur Lesezugriff auf unsere Datenbank hat, sondern auch neue Scraper registrieren kann oder die Speicherung von ausgewählten Tweets veranlassen kann. Gegebenenfalls veröffentlichen wir zu einem späteren Zeitpunkt auch noch eine Spielversion ohne die Daten-verändernden Funktionalitäten, bis dahin müssen sich nicht-Redaktionsmitglieder mit Screenshots begnügen.

Gesamtarchitektur von ODRAlighthouse. Bild: Dennis Demmer.

Dennis und ich hoffen, dass dieser Beitrag einigermaßen verständlich machen konnte, woran wir hier in Köln die letzten 4 Monate gearbeitet haben (Dennis mehr, ich weniger) und dass das #projektODRA auch mit unserer Hilfe ein erfolgreiches wird. Wir halten euch auf dem Laufenden.

Cite this article as: Jürgen Hermes: "ODRAlighthouse – Das Redaktionsdeck für #projektODRA", in TEXperimenTales, 04/02/2020, https://texperimentales.hypotheses.org/3940.

By Jürgen Hermes

Arbeitet als Wissenschaftler und Geschäftsführer am Institut für Digital Humanities an der Universität zu Köln.

One reply on “ODRAlighthouse – Das Redaktionsdeck für #projektODRA”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.