Fakultät Technik und Informatik Department Informatik
Faculty of Engineering and Computer Science Department of Computer Science
Harald Kirschenmann
Untersuchung einer Second Screen Anwendung mit
automatisierter Generierung von Content
Untersuchung einer Second Screen Anwendung mit automatisierter Generierung von Content
Abgegeben am 18. September 2020
Inhaltsverzeichnis
1 Einleitung ... 4
2 Design und Realisierung ... 5
2.1 Schichtenmodell ... 5
2.1.1 Präsentationsschicht ... 6
2.1.2 Logikschicht ... 7
2.1.3 Datenhaltungsschicht ... 8
2.2 Flussdiagramm ... 8
2.2.1 First Screen ... 8
2.2.2 Second Screen ... 10
2.3 Representational State Transfer (REST) ... 11
2.3.1 Prinzipien von REST ... 11
2.4 Message Broker ... 12
2.4.1 Producer/Consumer ... 13
2.4.2 Publish/Subscribe ... 13
3 Untersuchungen ... 14
3.1 Vorverarbeitung ... 15
3.2 Geocoding ... 16
3.3 Named Entity Linking ... 18
3.4 Diskussion ... 20
4 Fazit und Ausblick ... 21
5 Literatur ... 23
1 Einleitung
Smartphones sind zu einem ständigen Begleiter der Menschen geworden. Die Geräte gehören zum Alltag und werden häufig begleitend zu anderen Aktivitäten verwendet, sei es zum Nachschlagen von Fakten während einer Diskussion, zur Messung der eigenen Leistung während des Sports oder als begleitendes Medium. In den letzten Jahrzehnten haben sich Digitale Medien und deren Nutzung verändert und sind zu einem alltäglichen Begleiter mit großer Bedeutung geworden.
Die begleitende Nutzung von Digitalen Medien hat auch in der Unterhaltung ihren festen Platz gefunden. Statt der exklusiven Nutzung eines Fernsehgeräts werden parallel zum Fernsehen heutzutage Smartphones, Tablets und weitere Medien genutzt. Dieses Phänomen wird als Second Screen bezeichnet. Das Fernsehgerät wird als First Screen und die begleitenden Medien als Second Screen betrachtet. In Zeiten von Corona erhält das Thema der Digitalisierung des Lernens besonderes Augenmerk. Der Unterricht wurde für einige Zeit ins Digitale verlegt und beispielsweise über Videokonferenzen bewältigt. Dies zeigt einen benötigten Wandel des Lernens auf, das durch digitale Medien unterstützt wird. Die Nutzung des Second Screen-Phänomens in der Bildung lohnt eine nähere Betrachtung.
Zum Phänomen des Second Screen wurde mit dem Grundprojekt [1] eine erste Ausarbeitung für eine Software erstellt, die Hintergrundinformationen zu Videos generiert und auf dem Second Screen darstellt. Eine erste Untersuchung anhand eines ausgewählten Videos wurde durchgeführt. In dieser Ausarbeitung wird die Arbeit des Grundprojekts erweitert. In der Software ergaben sich Änderungen. In Abschnitt 2 werden die Änderungen näher betrachtet.
Mit dem Hinzufügen der Frontends für den First- und den Second Screen ergaben sich, im Besonderen an die Kommunikation zwischen den Modulen, neue Anforderungen an die Software. Die erweiterte Architektur und neu eingeführten Technologien, wie REST und Message Broker, werden hier aufgezeigt.
Im Rahmen dieser Ausarbeitung soll gezeigt werden, dass das entwickelte System generalisierbar ist. Im Grundprojekt wurde gezeigt, dass die Software mit einer ausgewählten Dokumentation umgehen kann. In dieser Arbeit werden die Messungen an einem zweiten Video durchgeführt und die Messergebnisse analysiert. In Abschnitt 3 werden die Untersuchungen dargestellt und gezeigt, dass das System auf weitere Videos übertragbar ist.
Das verwendete Video ist der zweite Teil der Dokumentation „Der große Umbruch“.
2 Design und Realisierung
Die im Grundprojekt entwickelte Software zur Generierung von Content für eine Second Screen Anwendung wurde im Rahmen dieser Arbeit erweitert. Für die Software wurden ein neues Frontend und die dazugehörigen Schnittstellen zur Kommunikation zwischen dem Frontend und dem Backend entwickelt. Das Frontend besteht aus dem First Screen und dem Second Screen.
In diesem Abschnitt werden das Design und die Realisierung dieser Erweiterungen beschrieben. Mit Hilfe des Schichtenmodells 2.1 wird der Aufbau des Systems aufgezeigt und mit den Flussdiagrammen für den First Screen 2.2.1 und Second Screen 2.2.2 dargestellt. Für die Kommunikation zwischen den Modulen der Software wurde REST und ein Message Broker verwendet. Nachfolgend werden REST (Abschnitt 2.3) und Message Broker (Abschnitt 2.4) beschrieben.
2.1 Schichtenmodell
Die entwickelte Software ist ein verteiltes System, welches sich aus verschiedenen Komponenten zusammensetzt. In Fig. 1 ist das Schichtenmodell abgebildet. Hier ist die Kommunikation zwischen den Komponenten und die Einordnung der Komponenten in die Kategorien der Präsentations-, Logik- und Datenhaltungsschicht zu sehen. Die Schichten sind logisch voneinander getrennt.
Fig. 1: Schichtenmodell der Second Screen Software
In Abschnitt 2.1.1 wird die Präsentationsschicht mit den Komponenten First Screen und Second Screen, in Abschnitt 2.1.2 die Logikschicht und in Abschnitt 2.1.3 die Datenhaltungsschicht näher beschrieben.
2.1.1 Präsentationsschicht
In der Präsentationsschicht sind die Komponenten enthalten, mit denen der Anwender interagieren kann und mit denen die Daten dargestellt werden. Die Präsentationsschicht besteht hier aus zwei Komponenten, dem First Screen und dem Second Screen. Beide Komponenten wurden als Webseiten geschrieben.
Der First Screen ist für die Auswahl und das Abspielen von Videos gedacht. Der Nutzer wählt ein Video aus und dieses kann anschließend abgespielt, pausiert und gestoppt werden. Damit die Second Screens synchronisiert werden können, wird die aktuelle Laufzeit des Videos über
REST (Abschnitt 2.3) an die Logikschicht übertragen. Der detaillierte Ablauf des First Screen ist in Abschnitt 2.2.1 als Flussdiagramm zu sehen.
Der Second Screen stellt die Zusatzinformationen synchronisiert zum First Screen dar. Die Second Screen Komponente wird über die Logikschicht mit dem First Screen verbunden. Die Kommunikation zwischen dem Second Screen und der Logikschicht erfolgt über REST und einen Message Broker (Abschnitt2.4). Der detaillierte Ablauf des Second Screen ist in Abschnitt 2.2.2 als Flussdiagramm zu sehen.
2.1.2 Logikschicht
In der Logikschicht befinden sich vier Komponenten, die für die Anwendungslogik zuständig sind. Der funktionale Kern der Anwendung besteht aus den Komponenten Kommunikation, Screen Handler, Movie Handler und Content Generator.
Die Komponente Kommunikation bildet die Schnittstelle zwischen der Präsentationsschicht und der Logikschicht. Es wird eine REST-Schnittstelle angeboten, die vom First Screen und vom Second Screen verwendet wird. Zur Kommunikation mit dem Second Screen wird zusätzlich ein Message Broker genutzt. Über den Message Broker werden nach einer Änderung der Laufzeit des Videos die neuen Nachrichten an die entsprechenden Second Screens gesendet. Entsprechend der REST-Schnittstellen werden der Screen Handler oder der Movie Handler zur weiteren Verarbeitung der Anfragen aufgerufen.
Der Screen Handler ist zuständig für die Verwaltung der First Screens. Zu den Aufgaben gehört die Verwaltung der Laufzeiten der Videos der First Screens und der Bereitstellung der entsprechenden Nachrichten eines First Screens. Der Screen Handler ruft die Database- Komponente der Datenhaltungsschicht auf.
Der Movie Handler verwaltet die Videos, die für die Software zur Verfügung gestellt werden.
Zu den Aufgaben gehört die transparente Weitergabe der Metadaten der bestehenden Videos. Des Weiteren werden neue Videos über den Movie Handler in das System eingepflegt. Für die Generierung des Contents bzw. der Zusatzinformationen aus den Untertiteln wird die Content Generator Komponente genutzt.
Der Content Generator verarbeitet die Untertitel der Videos und generiert den zugehörigen Content für die Second Screen Anwendung. Die detaillierte Funktionsweise wurde im Grundprojekt [1] dargestellt. Der generierte Content wird über die Database-Komponente in der Datenbank des Systems gespeichert.
2.1.3 Datenhaltungsschicht
Die Komponenten der Datenhaltungsschicht speichern, verwalten und laden die Daten der Anwendung. Die Videos und die dazugehörigen Metadaten werden bereitgestellt. Über die Database-Komponente werden die Metadaten der Videos, die generierten Zusatzinformationen und die Daten der First Screens gespeichert und bereitgestellt.
Die GeoNames Datenbank [2] wurde lokal eingerichtet. Die Nutzung als externe API (application programming interface) wäre ebenfalls möglich. Das System greift zusätzlich auf externe APIs, wie Nominatim [3] für OpenStreetMap [4], Wikipedia [5] und DBPedia Spotlight [6] über REST (Abschnitt 2.3) zu.
2.2 Flussdiagramm
Die Umsetzung der Anwendung wurde im Rahmen des Hauptprojekts um die Präsentationsschicht erweitert. Der Ablauf des First Screen und Second Screen werden in diesem Kapitel dargestellt.
2.2.1 First Screen
In Fig. 2 ist der Ablauf des First Screen als Flussdiagramm dargestellt. Das Backend stellt eine REST-Schnittstelle zur Verfügung, über die die Kommunikation des First Screen stattfindet.
Nachfolgend wird der Ablauf des First Screen näher beschrieben.
Fig. 2: Ablauf des First Screen als Flussdiagramm
Wird die Webseite des First Screen aufgerufen, so erfolgen nacheinander zwei REST-Anfragen an das Backend. Mit der ersten Abfrage wird die ScreenID vom Backend zugewiesen und anschließend auf der Webseite angezeigt. Mit der zweiten Abfrage wird die Liste der verfügbaren Videos abgerufen. Wenn die Videoliste nicht leer ist, werden die verfügbaren Videos auf der Webseite dargestellt. Der Anwender kann ein Video aus dieser Liste auswählen, um dieses auf dem First Screen darzustellen. Wurde ein Video ausgewählt, so wird die Auswahl über REST an das Backend gesendet. Die Darstellung der Videoliste wird entfernt und stattdessen das ausgewählte Video im Videoplayer angezeigt. Der Nutzer kann mit dem Videoplayer interagieren, um das Video zu starten, zu pausieren oder zu bestimmten Zeitpunkten des Videos zu springen. Während des Abspielens ändert sich die Laufzeit des Videos kontinuierlich. Diese Änderungen werden über REST an das Backend weitergegeben.
2.2.2 Second Screen
In Fig. 3 ist der Ablauf des Second Screen als Flussdiagramm dargestellt. Das Backend und der Second Screen kommunizieren miteinander über REST und über einen Message Broker.
Nachfolgend wird der Ablauf des Second Screen näher beschrieben.
Fig. 3: Ablauf des Second Screen als Flussdiagramm
Wird die Webseite des Second Screen aufgerufen, so wird erst eine REST-Anfrage an das Backend gestellt, um eine Liste der vorhandenen First Screens zu erhalten. Wenn die Abfrage First Screens enthält, werden diese auf der Webseite dargestellt. Der Anwender hat mehrere Möglichkeiten, den Second Screen mit dem passenden First Screen zu verbinden. Dies kann über die Liste der First Screen geschehen oder über eine Eingabe der ScreenID des First
Screens. Wurde ein First Screen ausgewählt, so wird die Anzeige der möglichen First Screens entfernt und über REST werden alle Nachrichten, die für den ausgewählten First Screen versendet wurden, abgerufen. Falls bereits einige Nachrichten versendet wurden, so werden diese direkt auf dem Second Screen angezeigt. Anschließend wird das Topic des Message Broker zum spezifischen First Screen abonniert. Neue Nachrichten werden über das passende Topic vom Backend zu den Second Screens, entsprechend der Laufzeitänderung beim First Screen, gesendet. Der Second Screen empfängt die Nachrichten des Message Broker asynchron, sobald neue Nachrichten in dem Topic erscheinen. Die empfangenen Nachrichten des Topics werden auf dem Display dargestellt.
2.3 Representational State Transfer (REST)
Im Jahr 2000 beschrieb Roy Fielding den zustandslosen Architekturstil des Representational State Transfer (REST) erstmals in seiner Dissertation [7]. Basierend auf dem Hypertext Transfer Protocol (HTTP) [8] ermöglicht REST die Maschine-zu-Maschine Kommunikation.
Eine nähere Beschreibung der Design-Prinzipien findet sich in Abschnitt 2.3.1.
Viele Anwendungen sind mit dem Internet verbunden und bieten Schnittstellen wie REST- APIs an. Die Kommunikation findet über das weit verbreitete HTTP statt und ermöglicht so eine leichte, aber mächtige Umsetzung. Die Anwendung der Prinzipien von REST führen zu einer hohen Interoperabilität der Anwendung. In der entwickelten Software wird REST an mehreren Stellen verwendet. Hierzu gehören die externen REST-APIs und die Kommunikation zwischen dem Backend und dem First Screen und Second Screen.
2.3.1 Prinzipien von REST
Fielding verweist auf mehrere Prinzipien, die für REST erfüllt sein müssen [7], von denen einige nachfolgend beschrieben werden.
REST erfüllt die Eigenschaften einer Client-Server-Architektur. Der Server stellt Ressourcen über HTTP bereit. Ressourcen sind in REST wichtige Elemente, die einfachen Informationen, Sammlungen von Entitäten oder komplexeren Daten, wie Bilder und Dokumenten, entsprechen können. Von Clients können Anfragen an den Server gestellt werden. Hiermit wird eine Trennung geschaffen, die die Portabilität erhöht und eine unabhängige Entwicklung ermöglicht.
Jede Anfrage enthält alle notwendigen Informationen, um diese zu verarbeiten. Es werden keine Informationen zum Kontext von Anfragen gespeichert, auf die später zugegriffen werden könnte. REST ist somit zustandslos. Die Zustandslosigkeit führt zur Verbesserung der Eigenschaften der Sichtbarkeit, Zuverlässigkeit und Skalierbarkeit.
Das Prinzip der Einheitlichen Schnittstelle wird durch vier Eigenschaften definiert:
• Ressourcen werden über Identifier adressiert. In der HTTP-Welt geschieht dies über Uniform Resource Identifier (URI).
• Ressourcen werden über sogenannte Repräsentationen aufgerufen und manipuliert.
Repräsentationen enthalten Daten in Form von beispielsweise XML- und JSON- Objekten. Diese werden entsprechend der HTTP-Methoden, wie GET, POST, PUT und DELETE, vom Server verarbeitet. Der Server verwaltet die Ressourcen und entscheidet über die Ausführung der Anfrage.
• Nachrichten sind selbstbeschreibend und enthalten alle Informationen, die zur Verarbeitung benötigt werden.
• Antworten des Servers enthalten Informationen, welche weiteren Aktionen durchgeführt werden können. Dies geschieht über die Bereitstellung von URIs in der Antwort und wird als Hypermedia bezeichnet.
Das System kann über mehrere hierarchische Schichten verfügen. Der Anwender kann mit der Schnittstelle interagieren, hat aber keine Kenntnis darüber, wie viele Schichten sich hinter der Schnittstelle befinden. Ohne die Veränderung der Schnittstellen des Clients und des Servers können Schichten, wie Proxies, Firewalls, Gateways und Load Balancer zwischen dem Client und dem Server hinzugefügt werden und somit die Skalierung des Systems verbessern.
2.4 Message Broker
In verteilten Systemen kommunizieren die Module einer Anwendung miteinander, dies kann über verschiedene Arten erfolgen. Neben dem in Kapitel 2.3 besprochenen REST sind Message Broker Systeme eine weitere Möglichkeit zur Kommunikation. Zur Vermittlung von Nachrichten, die zwischen den Modulen versendet werden, übernehmen Message Broker (MB) das Routing und die Verwaltung der Nachrichten. Mit MBs werden zwei grundlegende Prinzipien der asynchronen Nachrichtenverteilung ermöglicht. Das Producer/Consumer- Prinzip wird in Abschnitt 2.4.1 und das Publish/Subscribe-Prinzip in Abschnitt 2.4.2 näher erläutert.
Die Nachrichten, die als Hintergrundinformationen auf dem Second Screen angezeigt werden sollen, werden, abhängig von der Laufzeit der Videos auf dem First Screen, an alle Second Screens versendet. Für das Versenden dieser Nachrichten wurde ActiveMQ [9] im Rahmen dieser Arbeit als MB genutzt. ActiveMQ unterstützt zahlreiche Protokolle und ermöglicht die Verwendung vieler unterschiedlicher Programmiersprachen.
2.4.1 Producer/Consumer
Das Producer/Consumer-Prinzip verbindet Producer mit Consumern über eine Message Queue. Producer erzeugen Nachrichten, die über die Message Queue (MQ) an die Consumer gesendet werden. Die Consumer empfangen die Nachrichten aus der Message Queue. In Fig.
4 wird das Producer/Consumer-Prinzip schematisch dargestellt.
Fig. 4.: Schematische Darstellung des Producer/Consumer-Prinzips
Für jede Message Queue können mehrere Producer Nachrichten versenden. Die Message Queue empfängt diese Nachrichten und hält diese in einer MQ nach dem „First In – First Out“- Prinzip vor. Die Nachrichten in der MQ werden gespeichert, bis diese von den Consumern abgerufen werden. Für jede MQ kann es mehrere Consumer geben, doch jede Nachricht der MQ wird nur an einen Consumer weitergeleitet und anschließend aus der MQ entfernt. Die Nachrichten werden nur an jeweils einen Consumer weitergeleitet, der zum Empfangen der Nachrichten bereit ist. Dieses Prinzip kann beispielsweise für das Loadbalancing verwendet werden.
2.4.2 Publish/Subscribe
Das Publish/Subscribe-Prinzip hat Ähnlichkeiten zum zuvor beschriebenen Producer/Consumer-Prinzip. Es unterscheidet sich in der Art der Speicherung und Verteilung der Nachrichten. In Fig. 5 wird das Publish/Subscribe-Prinzip schematisch dargestellt.
Fig. 5.: Schematische Darstellung des Publish/Subscribe-Prinzips
Publisher erzeugen Nachrichten, die an ein sogenanntes Topic gesendet werden. Es können mehrere Publisher Nachrichten an ein Topic senden. Topics speichern die Nachrichten und verteilen diese an die Subscriber. Subscriber sind die Empfänger dieser Nachrichten, sobald sie ein Topic abonnieren. Topics senden Kopien der empfangenen Nachrichten an alle Subscriber, die zum Zeitpunkt des Empfangs der Nachricht das Topic abonniert haben. Die Publisher und Subscriber stehen in einer n:m-Beziehung. In der Software, die im Rahmen dieser Ausarbeitung entwickelt wurde, wurden Topics von ActiveMQ zum Versenden der Hintergrundinformationen verwendet.
3 Untersuchungen
In diesem Kapitel wird die Dokumentation “Der große Umbruch – Wie Künstliche Intelligenz unsere Gesellschaft verändert”1 von Tilman Wolff und Ranga Yogeshwar einer genaueren Betrachtung unterzogen. Der 2019 veröffentlichte zweite Teil der Dokumentation “Der große Umbruch” hat eine Länge von 43:33 Minuten und betrachtet Forschung und Entwicklung der Künstlichen Intelligenz in Europa, China und den USA und ihren Einfluss auf die Gesellschaft.
In der Ausarbeitung des Grundprojekts [1] wurde die Weltspiegel Reportage „Unsere digitale Zukunft? – China und die künstliche Intelligenz“ untersucht. Die beiden Videos haben Gemeinsamkeiten und Unterschiede. Beide Videos behandeln den Themenbereich der Künstlichen Intelligenz. Die Weltspiegel Reportage behandelt das Themenfeld in China, wohingegen die Dokumentation das Thema in Europa, China und den USA betrachtet. Beide Videos sind auf Deutsch und verfügen über Untertitel in deutscher Sprache. Das Video der Dokumentation „der große Umbruch“ und die Weltspiegel Reportage unterscheiden sich neben dem Format auch in der Darstellungsform, den behandelten Orten und der Länge.
Nach Christian Hißnauer gehören Reportagen und Dokumentationen zur Kategorie des Fernsehdokumentarismus. Während Dokumentationen sich durch „inhaltliche und formale Offenheit“ auszeichnen, fokussiere die Reportage den Einzelfall und gelte als eine „subjektive Darstellungsform“, wobei Beobachtungen, Beschreibungen und situative Interviews die Reportagen dominierten [10].
Im Folgenden wird die Untersuchung in drei Abschnitte unterteilt. In Kapitel 3.1 wird die Vorverarbeitung der Untertitel betrachtet. Die Ergebnisse der Vorverarbeitung werden für die Untersuchungen des Geocoding in Kapitel 3.2 und des Named Entity Linking in Kapitel 3.3
1 https://www1.wdr.de/mediathek/video/sendungen/quarks-und-co/video-der-grosse-umbruch- wie-kuenstliche-intelligenz-unsere-gesellschaft-veraendert-100.html
weiterverwendet. Die Algorithmen und Messverfahren, die in dieser Ausarbeitung verwendet werden, entsprechen denen des Grundprojekts.
3.1 Vorverarbeitung
In diesem Abschnitt werden die Messungen zum Arbeitsschritt der Vorverarbeitung besprochen. Dieser Schritt erfolgt vor dem Geocoding und dem Named Entity Linking. Für die Vorverarbeitung werden die Algorithmen des StopWord Removal und SpaCy auf die Untertitel des zweiten Teils der Dokumentation „Der große Umbruch“ angewendet. Als Referenzwert wurden die Untertitel händisch verarbeitet. Die Vorverarbeitung erfolgt, um den Textkorpus zu verkleinern und für eine effektivere anschließende Verarbeitung zu sorgen.
Für das StopWord Removal werden die Untertitel in Tokens unterteilt. Hauptsächlich entsprechen die Tokens den ganzen Wörtern und Zahlen im Text. Die Untertitel der Dokumentation enthalten 5417 Tokens. Anschließend wird das StopWord Removal angewendet, bei dem alle Stoppwörter aus der extrahierten Token-Liste entfernt werden.
Hier wird die Stoppwort-Liste der Natural Language Toolkit (NLTK)2-Bibliothek verwendet, die aus 232 Wörtern besteht.
Für die Name Entity Recognition wird SpaCy auf die Untertitel angewendet. Hierbei analysiert SpaCy die Untertitel und ordnet einige Entitäten den Kategorien Person (PER), Organisation (ORG), Location (LOC) und Verschiedenes (MISC) zu. Die Einteilung erfolgt mit Hilfe trainierter Modelle. In dieser Messung wurde das vortrainierte „de_core_news_md“-Model verwendet.
Dieses Neuronale Netz wurde mit dem TIGER3- und dem WikiNER4-Datensatz trainiert.
Für den händischen Referenz-Wert werden die Untertitel nach Named Entities untersucht, die eine gewisse Relevanz für weitergehende Informationen zum Video haben. Die Einteilung der Named Entities erfolgt in die oben genannten Kategorien.
PER ORG MISC LOC Summe Summe ohne
doppelte
händisch 12 13 74 22 121 121
SpaCy 27 0 73 34 134 127
StopWord - - - - 3526 1500
Tab. 1: Vorverarbeitung der Entitäten. Named Entities werden in Kategorien eingeteilt.
2 https://www.nltk.org/ (Abgerufen am 4. Sept. 2020)
3 https://www.ims.uni-stuttgart.de/forschung/ressourcen/korpora/tiger/ (Aufgerufen am 4. Sept.
2020)
4 https://doi.org/10.6084/m9.figshare.5462500.v1 (Aufgerufen am 4. Sept. 2020)
Die Ergebnisse der Vorverarbeitung des Untertitelts sind in Tab. 1 dargestellt. Als Referenzwerte wurden händisch 12 Personen, 13 Organisationen, 22 Orte und 74 Entitäten in die Kategorie „Verschiedenes“ einsortiert. Insgesamt wurden 121 einzigartige Entitäten aus den Untertiteln extrahiert.
Mit SpaCy wurde eine ähnliche Anzahl an Entitäten extrahiert. Nach dem Abzug der doppelten Entitäten, wurden 127 Entitäten extrahiert. Hierbei wurden keine Organisationen erkannt. Mit 73 Entitäten in der Kategorie „Verschiedenes“ wurden beinahe so viele Entitäten gefunden wie beim Referenzwert. In die Kategorie „Person“ wurden mit 27 Einträgen mehr als doppelt so viele Entitäten eingeordnet. In die Kategorie „Location“
wurden mit 34 Einträgen etwa 1,5 mal mehr als beim Referenzwert eingeordnet. Einige Entitäten wurden in mehrere Kategorien einsortiert, so dass sich insgesamt 134 Einträge in den Kategorien finden, die 127 einzigartigen Entitäten entsprechen.
Beim StopWord Removal wurde die Anzahl der Tokens durch das Entfernen von Stoppwörten von 5417 auf 3526 reduziert. Nach Entfernung aller doppelten Einträge blieben 1500 einzigartige Tokens über. Somit konnten über 2/3 der Tokens aus dem Korpus entfernt werden. Es findet keine Einordnung in die Kategorien PER, ORG, LOC oder MISC, statt.
Verglichen mit Referenzwert und SpaCy verbleiben beim Stopword Removal jedoch deutlich mehr Tokens.
3.2 Geocoding
In diesem Abschnitt werden die Messungen zum Arbeitsschritt des Geocodings besprochen.
Beim Geocoding werden Texte verarbeitet und in Koordinaten umgewandelt. Die Texte können beispielsweise Länder, Städte, Ortsgebiete und vollständige Adressen sein. Mit Hilfe des Geocodings werden den Tokens aus Abschnitt 3.1 geographische Koordinaten zugeordnet. So können zusätzliche Informationen, wie eine Kartendarstellung, zu Ortsangaben generiert werden.
Für das Geocoding werden die Tokens der jeweiligen Verfahren aus Abschnitt 3.1 verwendet.
Mit der Nominatim-API [11] für OpenStreetMap (OSM) [12] und der GeoNames-Datenbank [13] werden die Tokens verarbeitet und es wird versucht den Tokens die entsprechenden geographischen Koordinaten zuzuordnen. Von SpaCy und der Referenz werden die Tokens gewählt, die in die Kategorie „Location“ einsortiert wurden.
Für den händischen Referenz-Wert dieser Messung wurden die Location-Tokens der Referenz des Abschnitts 3.1 genutzt. Anschließend wurden diesen Tokens entsprechende geographische Koordinaten händisch zugeordnet.
Kandidaten richtig erkannt
nicht erkannt
falsch erkannt
richtig erkannt in %
Erkannt / Referenz in %
Referenz 22 22 0 0 100,00% 100,00%
Spacy +
OSM 30 19 3 11 63,33% 86,36%
SpaCy +
GeoNames 13 12 10 1 92,31% 54,55%
StopWord +
OSM 1050 19 3 1031 1,81% 86,36%
StopWord +
GeoNames 77 11 11 66 14,29% 50,00%
Tab. 2: Geocoding mit unterschiedlichen Verfahren und Vorverarbeitungsschritten
Die Ergebnisse der Messungen des Geocodings sind in Tab. 2 dargestellt. Als Referenz wurden die 22 Entities verwendet, die in der Vorverarbeitung in die Kategorie „Location“ einsortiert wurden. Allen Entities konnten geographische Koordinaten zugeordnet werden.
Die Anzahl der Tokens wurde durch die Vorverarbeitung durch SpaCy bereits stark reduziert.
Von den 34 Entitäten, die als Location einsortiert wurden, wurden 30 von OpenStreetMap als Orte erkannt. Von diesen sind 11 als falsch erkannt und 19 korrekt zugeordnet worden. Somit wurden 63,33 % der Kandidaten richtig erkannt. Von den Referenz-Orten wurden 86,36 % erkannt. In der Kombination mit GeoNames wurden 13 Kandidaten als Orte erkannt, hiervon wurde ein Kandidat falsch erkannt, so dass 92,31 % richtig erkannt wurden. Mit 54,55 % wurden knapp über die Hälfte der Referenz-Orte erkannt.
Mit der Vorverarbeitung durch das StopWord Removal wurde die Anzahl der Tokens der Untertitel auf 1500 reduziert. Durch die Kombination mit OpenStreetMap wurden 1050 der Tokens als Orte erkannt. Nur 19 dieser Kandidaten wurden richtig erkannt, so dass sich ein Wert von 1,81 % richtig erkannter Kandidaten ergibt. Von den Referenz-Orten wurden 3 nicht erkannt, so dass 86,36 % dieser Orte erkannt wurden. In der Kombination mit der GeoNames- Datenbank wurden 77 Kandidaten identifiziert, wovon nur 14,29 % richtig erkannt wurden.
Von den Referenz-Orten wurden 11 Orte nicht erkannt, so dass 50% der Orte gefunden wurden.
Durch die Verarbeitung der Tokens durch OpenStreetMap werden mit jeweils 86,36 % die meisten Referenz-Orte gefunden. Verglichen mit der Verarbeitung durch die GeoNames- Datenbank werden hier allerdings mehr Kandidaten falsch erkannt. Im Hinblick auf das Verhältnis zwischen falsch und richtig erkannten Kandidaten erzielen die Messungen, bei denen SpaCy zur Vorverarbeitung genutzt wurde, die besten Ergebnisse.
3.3 Named Entity Linking
In diesem Abschnitt werden die Messungen zum Arbeitsschritt des Named Entity Linking dargestellt. Die Entitäten aus der Vorverarbeitung in Kapitel 3.1 werden auch hier verwendet.
Im Named Entity Linking werden alle gefundenen Entitäten verarbeitet und mit Einträgen aus Wissensbasen verknüpft. Durch das Verknüpfen mit Einträgen aus einer Wissensbasis werden weitere Informationen zu den Entitäten gefunden, mit denen die Second Screen- Anwendung angereichert werden kann.
Für die folgenden Messungen wurden zwei Wissensbasen verwendet. Wikipedia [14] ist eine umfangreiche enzyklopädische Wissensbasis, die zurzeit über 54,6 Millionen Artikel in verschiedenen Sprachen verfügt5. Der Zugriff erfolgt über die API von Wikipedia. In den Messungen wird unterschieden, ob die Namen der gefundenen Einträge der Wikipedia dem Namen der gesuchten Entität entsprechen (KeyWord = Link). Andernfalls wird der Eintrag der Wikipedia verwendet, der dem Namen des Keywords entspricht, oder der Eintrag mit der höchsten Confidence ausgewählt. DBPedia [15] ist eine Wissensbasis, für die strukturierte Daten aus Wikipedia extrahiert wurden. Das Named Entity Linking zu DBPedia erfolgt über die API von DBPedia Spotlight [16]. Für die Messungen mit DBPedia Spotlight wurde ein Confidence-Parameter von 0,7 und 0,9 gewählt.
Der Referenz-Wert dieser Messung wurde händisch ermittelt. Die Entitäten der Referenz des Abschnitts 3.1 wurden mit Einträgen der Wikipedia verknüpft.
Anzahl
Entities
gefundene Matches
gewollte Matches
gewollte / gefunden
in %
gewollte / Referenz- Matches in %
Referenz 121 102 102 100,00% 100,00%
SpaCy + Wiki -
(KeyWord = Link) 127 44 31 70,45% 30,39%
SpaCy + Wiki 127 106 48 45,28% 47,06%
StopWord + Wiki -
(KeyWord = Link) 1500 330 39 11,82% 38,24%
StopWord + Wiki 1500 1092 62,5 5,72% 61,27%
DBPedia Spotlight, 0.7 - 116 50 43,10% 49,02%
DBPedia Spotlight, 0.9 - 71 40 56,34% 39,22%
Tab. 3: Named Entity Linking mit Wikipedia und DBPedia nach unterschiedlichen Vorverarbeitungsschritten
5 https://en.wikipedia.org/wiki/List_of_Wikipedias#Grand_total (Aufgerufen am 8. September 2020)
Die Ergebnisse des Named Entity Linking sind in Tab. 3 dargestellt. Für den Referenz-Wert sind alle 121 Referenz-Entities aus Kapitel 3.1 verarbeitet worden. Davon konnten 102 Entitäten einem Eintrag der Wissensbasis Wikipedia zugeordnet werden.
Durch die Vorverarbeitung mit dem StopWord Removal blieben 1500 Tokens, die hier mit Wikipedia verknüpft werden. Entspricht der Name der Entität dem Namen des Wikipedia- Eintrags wurden 330 Matches gefunden, wovon 11,82 % gewollt waren. Die gewollten Matches entsprechen einem Anteil von 38,24% der gewollten Referenz-Matches. In der weiteren Messung mit dem StopWord Removal, bei denen der Name der gesuchten Entität dem Namen des Wikipedia-Eintrags entspricht oder der Eintrag mit dem höchsten Confidence-Wert gewählt wird, wurden 1092 Matches gefunden, wovon nur 5,72% gewollt waren. Mit 61,27 % wurde hier jedoch der höchste Anteil der gewollten Referenz-Matches gefunden.
Die Messungen mit SpaCy als Vorverarbeitungsschritt schneiden in vielen Punkten besser ab als die mit dem StopWord Removal. Durch die Vorverarbeitung mit SpaCy wurden 127 Entitäten identifiziert, die beim Named Entity Linking verarbeitet werden. Durch das Named Entity Linking mit Wikipedia wurden 44 Matches gefunden, bei denen der Name der Entität und des Wikipedia-Eintrags übereinstimmten. Diese Kombination erreichte mit 70,45 % den höchsten Wert der gewollten Matches. Von den Referenz-Matches wurden 30,39 % gefunden. Wenn der Name der Entität dem Wikipedia-Eintrag entsprach oder der Eintrag mit dem höchsten Confidence-Wert gewählt wurde, wurden 106 Matches gefunden. Von diesen waren 45,28 % gewollt und 47,06 % der Referenz-Matches wurden gefunden.
Im Gegensatz zu den vorherigen Verfahren benötigt DBPedia Spotlight keine Vorverarbeitung, denn es werden die gesamten Untertitel verarbeitet. Mit dem Confidence- Wert von 0,7 wurden 116 Matches gefunden, von denen 43,10 % gewollt waren. Mit dem Confidence-Wert von 0.9 wurden 71 Matches gefunden, von denen 56,34 % gewollt waren.
Mit 49,02 % und 39,22 % der gefundenen Referenz-Matches kann DBPedia Spotlight nicht die Werte der Messungen des Grundprojekts erreichen.
Die Beobachtung aus dem Grundprojekt, dass bei einfachen Methoden des Named Entity Linkings eine höhere Rate an erkannten Referenz-Matches mit einer höheren Anzahl an falsch erkannten oder ungewollten Matches einhergeht, kann in dieser Messreihe nicht pauschalisiert werden. Diese Beobachtung trifft nur auf die Werte der Messungen zu, die mit dem gleichen Vorverarbeitungsschritts verarbeitet wurden. Die komplexeren Mechanismen von DBPedia Spotlight, wie die Einbeziehung des Kontexts der Entitäten zur Disambiguierung, führten nicht dazu, dass DBPedia Spotlight wie im Grundprojekt im Gesamtbild am besten abschnitt. In dieser Messreihe trifft dies auf die Kombination von der Vorverarbeitung mit SpaCy und Wikipedia zu.
3.4 Diskussion
Anhand der Messungen in den Abschnitten zur Vorverarbeitung (Abschnitt 3.1), dem Geocoding (Abschnitt 3.2) und dem Named Entity Linking (Abschnitt 3.3) ist zu erkennen, dass das entwickelte System die Dokumentation “Der große Umbruch – Wie Künstliche Intelligenz unsere Gesellschaft verändert” verarbeitet und sinnvolle Ergebnisse erzeugt. Die verwendeten Algorithmen und Messverfahren entsprechen denen des Grundprojekts. Daher sind die Messungen des Grundprojekts und dieser Ausarbeitung miteinander vergleichbar.
Beim Geocoding ähneln sich die Ergebnisse des Grundprojekts und dieser Ausarbeitung. Mit 86,36% konnten in dieser Messreihe nicht alle Referenz-Orte mit OpenStreetMap gefunden werden. Mit diesem Wert konnte OpenStreetMap auch hier den höchsten Wert erreichen.
Die Messergebnisse dieser Ausarbeitung sind ähnlich verteilt, wie im Grundprojekt. Das Verhältnis zwischen den richtig und falsch zugeordneten Orten und der Erkennungsrate der Referenz-Orte unterscheidet sich in vielen Punkten nur geringfügig. Die größte Ausnahme findet sich in der Kombination des StopWord Removal und der GeoNames-Datenbank. Hier wurden nur 14,29 % der Kandidaten richtig erkannt. Beim Grundprojekt lag dieser Wert dagegen bei 46,15 %.
Beim Named Entity Linking unterscheiden sich die Messwerte zwischen dem Grundprojekt und dieser Auswertung deutlicher. Hervorzuheben sind hier DBPedia Spotlight und SpaCy.
Während die Ergebnisse von DBPedia Spotlight mit diesem Video schlechter abschneiden, haben sich die Werte beider Verfahren von SpaCy mit Wikipedia verbessert. Das Verfahren von SpaCy mit Wikipedia (KeyWord = Link) erzielt mit 70,45 % den höchsten Anteil der gewollten Matches von den gefundenen Matches. Der maximale Wert im Grundprojekt kam von DBPedia Spotlight mit knapp 12% weniger. In der Kategorie „Gewollte/Referenz- Matches“ ist der Wert im Grundprojekt der Kombination des StopWord Removal mit Wikipedia mit 76,09 % am höchsten. In dieser Ausarbeitung erzielt das gleiche Verfahren ebenfalls den höchsten Wert. Dieser liegt mit 61,27% um knapp 15 % niedriger. Es ist festzustellen, dass in dieser Messreihe die Verfahren einen geringeren Anteil der Referenz- Matches finden, aber das Verhältnis der gewollten Matches deutlich höher liegt als beim Grundprojekt.
Trotz der Unterschiede in den Messergebnissen wird deutlich, dass sich das System auf die zweite Dokumentation übertragen lässt. Es ist davon auszugehen, dass dies auf weitere Videos zutrifft. Die Übertragbarkeit wurde jedoch nur in einem begrenzten Rahmen gezeigt.
Beide Videos haben die Form einer Dokumentation und behandeln den Themenbereich der Künstlichen Intelligenz. In der Ausgestaltung und dem Wortschatz gibt es Unterschiede zwischen den Videos.
Die Ergebnisse der Messungen im Grundprojekt und in dieser Ausarbeitung zeigen, dass keines der genutzten Verfahren ideal ist, aber Verbesserungen möglich sind. Keines der Verfahren kommt an die Qualität der Referenz-Messungen heran. Die Verfahren zeigen ihre Stärken. In der Regel jedoch kommen diese Stärken mit Schwächen in anderen Aspekten.
4 Fazit und Ausblick
In dieser Arbeit wurde das System zur automatisierten Generierung von Content für eine Second Screen Anwendung erweitert und einer genaueren Untersuchung unterzogen. Mit dem System werden weitergehende Informationen zu Videos automatisch generiert und für die Nutzer auf dem Second Screen zur Verfügung gestellt. Die Software des Grundprojekts wurde um das Frontend, bestehend aus dem First Screen und dem Second Screen, ergänzt.
Zur Erläuterung der Änderungen wurden die erweiterte Architektur und die neu verwendeten Technologien vorgestellt. Die Kommunikation zwischen den Modulen erfolgt über REST und einen Message Broker. Für die Verteilung der Nachrichten an die Second Screens wurden die Eigenschaften der Topics eines Message Brokers ausgenutzt.
Anschließend wurden die Untersuchungen des entwickelten Systems durchgeführt. Das Ziel der Untersuchungen war es festzustellen, ob das entwickelte System generalisierbar ist. Im Grundprojekt wurde die Software anhand einer Dokumentation gezeigt. In dieser Ausarbeitung wurde eine weitere Dokumentation gewählt, mit der die Messungen durchgeführt wurden. Die Untersuchungsergebnisse dieser Ausarbeitung weisen Unterschiede zum Grundprojekt auf, aber auch viele Parallelen. In der Vorverarbeitung und dem Geocoding ähneln sich die Messergebnisse. Im Verarbeitungsschritt des Named Entity Linking sind Unterschiede zwischen den Messungen dieser Ausarbeitung und des Grundprojekts zu erkennen. Während die Verfahren im Grundprojekt mehr Referenz- Matches gefunden haben, ist in dieser Messreihe der Anteil der gewollten Matches an den gefundenen Matches höher. Somit werden dem Anwender weniger ungewollte Matches präsentiert. Die Messungen zeigen, dass sich das System auf die gewählte Dokumentation übertragen lässt.
In weiteren Arbeiten können die Untersuchungen ausgeweitet werden. Mit einem weiteren Video, dass sich in einem anderen Themenbereich als die bisherigen Dokumentationen befindet, lassen sich genauere Aussagen zur Generalisierbarkeit des Systems treffen und die Ergebnisse aller Messreihen miteinander vergleichen. Als zusätzlicher Faktor der Untersuchungen können die Zeiten betrachtet werden, die zur Berechnung der Ergebnisse benötigt werden. Zur weiteren Betrachtung der Messergebnisse kann der F1-Score eingeführt
werden. Der F1-Score ist ein Maß, welches die Metriken Precision und Recall miteinander kombiniert und als Maß im Information Retrieval Anwendung findet.
In den bisherigen Ausarbeitungen zu diesem System wurden die technischen Aspekte durch Messungen näher betrachtet. Mit empirischen Untersuchungen können weitere Aspekte untersucht werden. Durch die Einbeziehung von Probanden in den Evaluationsprozess können Benutzererfahrungen in Bezug auf die Usability der Software analysiert werden und Erkenntnisse auf zusätzliche sich zu stellenden Fragen bieten.
5 Literatur
[1] KIRSCHENMANN, HARALD.: Automatisierte Generierung von Content für Second Screen Anwendungen. In: Grundprojekt Ausarbeitung an HAW-Hamburg (2020) – URL https://users.informatik.haw-hamburg.de/~ubicomp/projekte/master2020-
proj/kirschenmann.pdf (Aufgerufen am 9. August 2020)
[2] GEONAMES. GeoNames. http://geonames.org/. (Aufgerufen am 18. August 2020) [3] NOMINATIM. Nominatim. https://nominatim.org/. (Aufgerufen am 5. August 2020) [4] OPENSTREETMAP. OpenStreetMap. https://www.openstreetmap.de/. (Aufgerufen am 5.
August 2020)
[5] WIKIPEDIA. Wikipedia. https://www.wikipedia.de/. (Aufgerufen am 5. August 2020) [6] MENDES,P.N.;JAKOB,M.;GARCA-SILVA,A.&BIZER,C.: DBpedia Spotlight: Shedding Light on
the Web of Documents. In: Association for Computing Machinery. : Proceedings of the 7th International Conference on Semantic Systems., 2011, S. 1-8
[7] FIELDING,R. T.& TAYLOR, R.N.: Architectural Styles and the Design of Network-Based Software Architectures: University of California, Irvine., 2000
[8] BELSHE,M.;PEON,R.&THOMSON,M.: Hypertext Transfer Protocol Version 2 (HTTP/2), RFC 7540: RFC Editor., Nr. 7540, 2015
[9] ACTIVEMQ. ActiveMQ. http://activemq.apache.org/. (Aufgerufen am 24. August 2020) [10] HIßSNAUER,C.: Fernsehdokumentarismus. In: GEIMER,A.;HEINZE,C.&WINTER,R. (Hrsg.),
Wiesbaden: Springer Fachmedien Wiesbaden. : Handbuch Filmsoziologie., 2019, S. 1-20 [11] NOMINATIM. Nominatim. https://nominatim.org/. (Aufgerufen am 06. September
2020)
[12] OPENSTREETMAP. OpenStreetMap. http://www.openstreetmap.org. (Aufgerufen am 06. September 2020)
[13]GEONAMES. GeoNames. http://geonames.org/. (Aufgerufen am 06. September 2020) [14] Wikipedia. Wikipedia. https://www.wikipedia.org/. (Aufgerufen am 7. September 2020) [15] AUER, S.; BIZER, C.; KOBILAROV, G.: DBpedia: A Nucleus for a Web of Open Data. In:
Springer
Berlin Heidelberg (Hrsg.): The Semantic Web., 2007, S. 722-735
[16] MENDES, P. N.; JAKOB, M.; GARCA-SILVA, A. & BIZER, C.: DBpedia Spotlight: Shedding Light on the Web of Documents. In: Association for Computing Machinery.: Proceedings of the 7th International Conference on Semantic Systems., 2011, S. 1-8
