Thomas Wilhelm-Stein

Information Retrieval in der Lehre

Wissenschaftliche SchriftenreiheDissertationen der MedieninformatikBand 5

Prof. Dr. Maximilian Eibl (Hrsg.)

Thomas Wilhelm-Stein

Information Retrieval in der Lehre

Unterstützung des Erwerbs von Praxiswissen zu Information Retrieval Komponenten mittels realer

Experimente und Spielemechaniken

Universitätsverlag Chemnitz2016

Impressum

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Angaben sind im Internet über http://dnb.d-nb.de abrufbar.

Coverfoto: Thomas Wilhelm-Stein, Bearbeitung: Stefanie Stein

Technische Universität Chemnitz/Universitätsbibliothek Universitätsverlag Chemnitz 09107 Chemnitz http://www.tu-chemnitz.de/ub/univerlag

Herstellung und Auslieferung Verlagshaus Monsenstein und Vannerdat OHG Am Hawerkamp 31 48155 Münster http://www.mv-verlag.de

ISSN 2195-2574 print; ISSN 2195-2582 online ISBN 978-3-944640-82-2

http://nbn-resolving.de/urn:nbn:de:bsz:ch1-qucosa-199778

Dissertationzur Erlangung des akademischen Grades

Doktoringenieur(Dr.-Ing.)

Herr Dipl.-Inf. Thomas Wilhelm-Steingeboren am 5. April 1982 in Annaberg-Buchholz

Fakultät für Informatikan der Technischen Universität Chemnitz

Gutachter:Prof. Dr. Maximilian Eibl (Technische Universität Chemnitz)Prof. Dr. Thomas Mandl (Universität Hildesheim)

Tag der Verteidigung:17. März 2016

Information Retrieval in der Lehre

Unterstützung des Erwerbs von Praxiswissen zu Information Retrieval Komponenten mittels realer

Experimente und Spielemechaniken

Kurzfassung

Das Thema Information Retrieval hat insbesondere in der Form von Internetsuchmaschinen eine große Bedeutung erlangt. Retrievalsysteme werden für eine Vielzahl unterschiedlicher Rechercheszenarien eingesetzt, unter anderem für firmeninterne Supportdatenbanken, aber auch für die Organisation persönlicher E-Mails.

Eine aktuelle Herausforderung besteht in der Bestimmung und Vorhersage der Leistungsfähigkeit einzelner Komponenten dieser Retrievalsysteme, insbesondere der komplexen Wechselwirkungen zwischen ihnen. Für die Implementierung und Konfiguration der Retrievalsysteme und der Retrievalkomponenten werden Fachleute benötigt. In diversen Studiengängen, wie Informatik, Bibliotheks- und Informationswissenschaft, Web Engineering und Business Intelligence & Analytics, werden Information Retrieval Konzepte und Techniken gelehrt. Auch wenn diese Vielfalt eine Bereicherung für das Themengebiet ist, so bringen die Studierenden unterschiedliches Vorwissen mit. Die für eine praktische Umsetzung notwendigen Programmierkenntnisse sind nicht Vorraussetzung oder Bestandteil aller relevanten Studiengänge.

Mithilfe der webbasierten Lernanwendung Xtrieval Web Lab können alle Studierenden praktisches Wissen über den Information Retrieval Prozess erwerben, indem sie Retrievalkomponenten zu einem Retrievalsystem zusammenstellen und evaluieren, ohne dafür eine Programmiersprache einsetzen zu müssen. Spielemechaniken leiten die Lernenden bei ihrem Entdeckungsprozess an, motivieren und verhindern eine Informationsüberladung durch eine Aufteilung der Lerninhalte.

Das Xtrieval Web Lab wurde Im Rahmen einer Studie mit 50 Teilnehmern evaluiert. Nach der Druchführung mehrere Experimente durch die Teilnehmer wurde ihr Lernfortschritt mittels eines Fragebogens überprüft.

Dabei konnte ein verbessertes Verständnis bezüglich der verwendeten Retrievalkomponenten nachgewiesen werden, d.h. nach der Verwendung des Xtrieval Web Labs wurden signifikant mehr korrekte Antworten gegeben als davor. Alle Teilnehmer werteten die Lernanwendung als sinnvolle Ergänzung zur Vorlesung und zogen ein überwiegend positives Fazit hinsichtlich ihrer Erfahrungen damit.

Inhaltsverzeichnis

1 Einleitung �����������������������������������������������������������������������������������������������11.1 Wissenschaftlicher Beitrag ..........................................................................31.2 Aufbau der Arbeit ..........................................................................................4

2 Grundlagen ���������������������������������������������������������������������������������������������72.1 Information Retrieval ....................................................................................72.1.1 Systeme und Komponenten ................................................................... 102.1.2 Evaluation ................................................................................................ 262.1.3 Evaluationsmetriken ............................................................................... 322.1.4 Evaluationskampagnen .......................................................................... 442.2 E-Learning .................................................................................................. 482.2.1 Interaktivität ............................................................................................ 492.2.2 Gestaltung ............................................................................................... 512.2.3 Motivation ............................................................................................... 532.2.4 Spielemechaniken .................................................................................. 55

3 Stand der Technik ���������������������������������������������������������������������������������593.1 Information Retrieval Systeme.................................................................. 593.1.1 SMART ..................................................................................................... 593.1.2 Apache Lucene ....................................................................................... 603.1.3 Terrier ...................................................................................................... 623.1.4 Lemur / Indri / Galago ............................................................................ 643.2 Information Retrieval Systeme in der Lehre ............................................. 643.2.1 Apache Lucene in der Lehre ................................................................... 653.2.2 Galago in der Lehre ................................................................................. 713.2.3 Fazit ......................................................................................................... 723.3 Information Retrieval Lernsoftware .......................................................... 723.3.1 INSTRUCT................................................................................................ 733.3.2 IR Game / QPA ........................................................................................ 763.3.3 IR-Toolbox ............................................................................................... 81

3.3.4 IR-BASE.................................................................................................... 833.3.5 IR-Components ....................................................................................... 853.3.6 SulaIR ...................................................................................................... 873.3.7 VIRLab ..................................................................................................... 883.3.8 Soekia ...................................................................................................... 923.3.9 Fazit ......................................................................................................... 95

4 Implementierung ����������������������������������������������������������������������������������974.1 Xtrieval Framework .................................................................................... 974.1.1 Entwicklungsabschnitte ......................................................................... 984.1.2 Anwendungsfälle .................................................................................. 1064.1.3 Fazit ....................................................................................................... 1264.2 Xtrieval Web Lab ...................................................................................... 1274.2.1 Basistechnologien ................................................................................ 1294.2.2 Verarbeitungskette ............................................................................... 1364.2.3 Flexible Komponenten durch JavaScript ............................................ 1394.2.4 Spielemechaniken ................................................................................ 1414.2.5 Prototypen und Gestaltung .................................................................. 145

5 Evaluation �������������������������������������������������������������������������������������������1535.1 Zielstellung und Zielgruppe ..................................................................... 1535.2 Aufbau und Lerninhalte ........................................................................... 1545.2.1 Komponenten........................................................................................ 1545.2.2 Assignments ......................................................................................... 1575.2.3 Achievements ....................................................................................... 1615.3 Fragebogen .............................................................................................. 1635.4 Durchführung ........................................................................................... 1645.5 Ergebnisse ................................................................................................ 166

6 Fazit ���������������������������������������������������������������������������������������������������1756.1 Diskussion ................................................................................................ 1756.2 Ausblick .................................................................................................... 177

Literaturverzeichnis �������������������������������������������������������������������������������179

Anhang A: Assignments ������������������������������������������������������������������������201Ein einfaches Experiment .............................................................................. 201Felder & Filter ................................................................................................. 203Stemming (1).................................................................................................. 205Stemming (2).................................................................................................. 207Stoppwörter .................................................................................................... 208

Anhang B: Fragebogen ��������������������������������������������������������������������������211

Anhang C: Auswertung ��������������������������������������������������������������������������219

Abbildungsverzeichnis

Abbildung 2.1: Übersicht über das Zusammenspiel von Testkollektion, Information Retrieval System und Evaluation ........ 10

Abbildung 2.2: Vektorraummodell für drei Terme als 2-dimensionale Darstellung .............................................................. 25

Abbildung 2.3: Mengen zur Berechnung von Precision und Recall .............. 34Abbildung 2.4: Precision-Recall-Diagramm mit typischer Sägezahn-Form .. 36Abbildung 3.1: Suchverlauf mit INSTRUCT .................................................... 75Abbildung 3.2: IR Game - Ansicht einer Ergebnisliste ................................... 77Abbildung 3.3: IR Toolbox - Ansicht zur Untersuchung eines Index ............. 82Abbildung 3.4: Ansicht der Indexerstellung.................................................... 87Abbildung 3.5: VIRLab - Rangliste mit verschiedenen

Korpora und Retrieval-Funktionen .................................................... 89Abbildung 3.6: VIRLab - Eingabemaske für eine Retrieval-Funktion ............. 91Abbildung 3.7: VIRLab - Ergebnislistenvergleich mit

Dokumententiteln, die durch neutrale Bezeichner ersetzt wurden . 92Abbildung 3.8: Soekia - Links: Hauptfenster mit den

verschiedenen Einstellungsmöglichkeiten; Rechts: Ausgabe der Indexdetails als HTML-Seite ....................................... 93

Abbildung 4.1: Übersicht Xtrieval Framework - Testkollektion und Integration von Apache Lucene & Terrier ......... 98

Abbildung 4.2: Compeval - Oben: Selektion der Komponenten; Unten: Anzeige der Ergebnisse als Parallele Koordinaten ...................................................................... 103

Abbildung 4.3: Interne Zustände bzw. Ansichten der Weboberfläche und deren Vererbungshierarchie .......................... 134

Abbildung 4.4: Übersicht zum Aufbau der Verarbeitungsketten für ein Experiment im Xtrieval Web Lab ...... 136

Abbildung 4.5: Sequenzdiagramm - Nutzer nimmt eine Änderung an einem Experiment vor ............................................... 139

Abbildung 4.6: Xtrieval Web Lab - Experimentieroberfläche mit aktivem Assignment ................................................................. 142

Abbildung 4.7: Xtrieval Web Lab - Leaderboard: Top 100 User ................... 145Abbildung 4.8: Xtrieval Web Lab - Ansicht der Ergebnisse

eines Experiments ........................................................................... 149Abbildung 4.9: Xtrieval Web Lab (Prototyp) - Ansicht eines

Experiments mit Komponenten und Preview ................................. 150Abbildung 4.10: Xtrieval Web Lab (Wireframe) - Ansicht

eines Experiments mit Assignment, Komponenten und Preview . 150Abbildung 4.11: Xtrieval Web Lab (Prototyp) - Ansicht der

Ergebnisse eines Experiments ........................................................ 151Abbildung 4.12: Xtrieval Web Lab (Wireframe) - Ansicht

eines Experiments und der Ergebnisse zusammen mit den Komponenten ..................................................................... 151

Abbildung 5.1: Diagramm über den Anteil richtig beantworteter Fragen vor und nach der Benutzung des Systems nach Studiengang ..................................................... 166

Abbildung 5.2: Histogramm der Differenz der Anzahl richtig beantworteter Fragen vor und nach der Benutzung des Systems 167

Abbildung 5.3: Geschätzte Anzahl notwendiger Stoppwörter für ein gutes Ergebnis gegenüber der Anzahl tatsächlich gewusster und eingegebener Stoppwörter vor und nach der Benutzung des Systems ............... 169

Tabellenverzeichnis

Tabelle 4.1: Korpusgrößen von TREC Disc 4 & 5, CLEF TEL-BL und CLEF GIRT-4 ................................................................. 102

Tabelle 4.2: Übersicht Anzahl Interfaces und Klassen in den Xtrieval Framework Versionen ................................................. 106

Tabelle 4.3: Übersicht der Ergebnisse bei ImageCLEF 2006....................... 108Tabelle 4.4: Monolinguale Experimente ohne Feedback bei

ImageCLEF 2007 ............................................................................. 110Tabelle 4.5: Monolinguale Experimente in Englisch mit und

ohne Feedback bei ImageCLEF 2007 ............................................. 111Tabelle 4.6: Bilinguale Experimente bei ImageCLEF 2007 .......................... 112Tabelle 4.7: Ergebnisse ImageCLEF 2008 Photographic Retrieval Task .... 114Tabelle 4.8: Ergebnisse ImageCLEF 2008 Wikipedia MM Task .................. 115 Tabelle 4.9: Ergebnisse CLEF-IP 2011 Prior Art Candidate Search Task ... 119Tabelle 4.10: Ergebnisse CLEF-IP 2012 Claims to Passage Task ............... 122Tabelle 4.11: Ergebnisse der zusätzliche Experimente CHiC

2013 Multilingual Task .................................................................... 124Tabelle 5.1: Signifikanztests zur Anzahl richtiger Antworten

vor und nach der Benutzung des Systems..................................... 168Tabelle 5.2: Einschätzung der Komponenten bezüglich

deren Verbesserung des Retrieval-Ergebnisses durch die Teilnehmer ....................................................................... 170

Listingsverzeichnis

Listing 2.1: Unverarbeitetes Beispieldokument (XML) aus dem IAPR TC-12 Benchmark ............................................................ 11

Listing 2.2: Beispieldokument nach dem Einlesen durch einen Parser ........ 13Listing 2.3: Beispieldokument nach der Zerlegung in

Tokens durch einen Tokenizer .......................................................... 14Listing 2.4: Beispieldokument nach der Entfernung der

Stoppwörter: the, of, a, on, with, and, it, in ........................................ 15Listing 2.5: Beispieldokument nach der Anwendung des Porter-Stemmers 17Listing 2.6: Beispieldokument nach der Anwendung des

Krovetz-Stemmers ............................................................................. 18Listing 2.7: Beispieldokument nach der Anwendung des

4-Gram-Stemmers ............................................................................. 19

1

1 Einleitung

Die Suche nach benötigten Informationen in einer digitalen Datensammlung ist vor allem in der Form von Internetsuchmaschinen in der breiten Öffent-lichkeit angekommen. Das Bedürfnis nach relevanten Informationen ist allgegenwärtig. Modernes Information Retrieval geht dabei weit über die klassische Suche in Textdokumenten hinaus. In nahezu allen Lebensberei-chen entstehen digitale Informationen, die zu einem späteren Zeitpunkt für die Durchführung einer Tätigkeit nützlich sein könnten. Dazu gehören auch Mitteilungen innerhalb eines Instant-Messaging-Dienstes oder Textein-blendungen in einer Videoproduktion. Diese Informationen zugänglich und nutzbar zu machen, ist eine Herausforderung für die Information Retrieval Forschung und Praxis.

Dank zahlreicher Open-Source-Projekte ist es mittlerweile vergleichsweise einfach, ein Information Retrieval System aufzusetzen. Eine Vielzahl von Komponenten und Einstellungen ermöglichen eine Anpassung an die unter-schiedlichsten Szenarien. Dank der konzentrierten Rechenleistung moderner Rechner können sehr viele Konfigurationen in kurzer Zeit getestet werden, so wie dies Kürsten (2012) anhand von mehr als 13.000 Konfigurationen durchgeführt hat. Jedoch ist eine automatische Bestimmung einer optima-len Konfiguration für eine neue Dokumentensammlung schwierig, sodass ein Experte die Beschaffenheit der Dokumente und wenn möglich der potentiel-len Suchanfragen untersuchen sollte, um schnell eine gute Konfiguration zu bestimmen.

Eine Konfiguration ist dabei vergleichbar mit einem Rezept. Sie hängt von der Art der Dokumente (Zutaten) und den potentiellen Suchanfragen (persönli-che Vorlieben) ab. Nur eine Konfiguration, die beide Aspekte berücksichtigt, liefert am Ende für den Suchende befriedigende Ergebnisse. So wie ein Koch durch praktische Erfahrung und zahlreiche Experimente ein Gefühl für eine stimmige Zubereitung von Zutaten zu einem Gericht benötigt, so sollten

2

Information Retrieval Experten auf ihrem Gebiet experimentieren und ein Gespür für eine passende Konfiguration für eine bestimmte Art von Doku-menten entwickeln. Um bei dieser Analogie zu verbleiben: Ein Koch experi-mentiert in seiner Küche, aber wo experimentiert ein Information Retrieval Experte bzw. jemand, der es werden will?

Einige Kurse nutzen existierende Information Retrieval Systeme, um die Lernenden mit den Konzepten und Komponenten vertraut zu machen. Zum anderen haben mehrere Forschergruppen Lösungen entwickelt, die sich dieses Problems annehmen, z.B. sind IR-BASE (siehe Kapitel 3.3.4) und IR-Components (siehe Kapitel 3.3.5) Lösungen, die ein Grundgerüst bieten, um den Einrichtungsaufwand zu reduzieren.

In der vorliegenden Arbeit wird im ersten Schritt das Xtrieval Framework als ein flexibles Grundgerüst für Information Retrieval Systeme ausgearbeitet. Es erlaubt die Kombination von Komponenten unterschiedlicher Retrieval-systeme, wie z.B. Apache Lucene und Terrier. Durch Teilnahmen an mehre-ren Evaluationskampagnen konnte die Leistungsfähigkeit des Frameworks gezeigt werden. Im zweiten Schritt wird die webbasierte Lernumgebung Xtrieval Web Lab1 auf der Basis dieses Frameworks entwickelt. Die Verwen-dung des Xtrieval Frameworks ermöglicht es den Lernenden, Experimente mit realen Daten durchzuführen. Infolge der hohen Verarbeitungsgeschwin-digkeit werden für jedes Experiment die beiden Stufen Indizierung und Suche ausgeführt. Mittels Spielemechaniken werden die Lernenden Schritt für Schritt mit der Benutzungsoberfläche vertraut gemacht und an die Verwen-dung der verfügbaren Komponenten herangeführt.

1 http://www.tu-chemnitz.de/informatik/mi/demo/weblab (28. Januar 2016)

3

1.1 Wissenschaftlicher Beitrag

Durch mehrjährige, praktische Versuche im Rahmen diverser Evaluations-kampagnen wurde in Zusammenarbeit mit Kürsten (2012) das Xtrieval Framework kontinuierlich weiterentwickelt, um den spezifischen Anfor-derungen der unterschiedlichen Evaluationsszenarien gerecht zu werden. Insbesondere die Beschleunigung der Dokumentenverarbeitung und neue Möglichkeiten zur Generierung umfangreicher Experimente mit vielen verschiedenen Komponentenkonfigurationen ermöglichen den Einsatz des Frameworks für die komponentenbasierte Evaluation.

Diese auf vielen Experimenten basierende Vorgehensweise stößt durch die zunehmende Anzahl verfügbarer Komponenten und Parameter an ihre Grenzen. Kürsten (2012) testete insgesamt über 13.000 Konfigurationen, um für verschiedene Kollektionstypen optimale Konfiguration zu bestimmen. Um die Anzahl durchzuführender Experimente zu reduzieren, können zum einen Heuristiken eingesetzt werden, die jedoch ebenfalls eine hohe Min-destanzahl von Experimenten benötigen, um zuverlässig zu funktionieren. Zum anderen kann ein fachkundiger Beobachter, dank seiner Erfahrung und seines Wissens über die eingesetzten Komponenten, früh Trends mutmaßen und die Konfigurationen so in eine Erfolg versprechende Richtung lenken.

Mittels der webbasierten Lernumgebung Xtrieval Web Lab können Lernende eigenständig Experimente erstellen, verändern und durchführen. Dabei kön-nen sie praktische Erfahrungen mit den verfügbaren Komponenten und deren Parametern sammeln. Diese Lernumgebung eignet sich jedoch nicht nur zur Ausbildung neuer Information Retrieval Fachleute, sondern kann auch zur Untersuchung von sinnvollen Eigenschaften für eben solche Lernumgebun-gen angepasst und verwendet werden. Aktuell sind einige Merkmale, wie z.B. die Achievements oder die Leaderboards, standardmäßig aktiviert und wur-den nicht explizit auf ihre Effekte für den Lernerfolg untersucht. Die konkrete Anwendung des Xtrieval Web Labs für die Vorlesung Medienretrieval und potentielle Anwendungen für verschiedene Kurse an anderen Universitäten

4

bilden eine nützliche Plattform für die Erforschung unterschiedlicher Ein-flussfaktoren auf den Lernerfolg.

Die im Rahmen des Xtrieval Web Labs entwickelte Verarbeitungskette ba-sierend auf Komponenten, die in JavaScript programmiert werden können, eignet sich neben der Abbildung des Information Retrieval Prozesses auch für andere Anwendungsfälle, wie z.B. die Bildverarbeitung. Auch hier wurde eine Grundlage für weitere Versuche im Bereich des E-Learnings mittels fachspezifischer Simulationen gelegt.

1.2 Aufbau der Arbeit

Die vorliegende Arbeit ist in sechs Kapitel aufgeteilt und ist wie folgt aufgebaut:

Im zweiten Kapitel werden die Grundlagen für ein System zur effizienten Durchführung von Information Retrieval Evaluationen auf Komponentene-bene erläutert. Dazu werden wichtige Konzepte des Information Retrievals vorgestellt. Insbesondere wird auf den Stellenwert von Relevanz, Evaluation und ausgewählten Evaluationsmetriken eingegangen. Abschließend wer-den in einem Exkurs die Themen E-Learning, Motivation und Gamification behandelt.

Das dritte Kapitel gibt den Stand der Technik bezüglich Information Retrieval Systeme, deren Anwendung in der Lehre und speziell für die Lehre entwi-ckelter Information Retrieval Software wieder. Zuerst werden Information Retrieval Systeme vorgestellt, die vorrangig in der Forschung, aber auch in Unternehmen zum Einsatz kommen. Anknüpfend werden Erfahrungsberich-te über deren Einsatz in der Lehre besprochen. Danach werden spezielle Lernumgebungen vorgestellt, die durch eine Reduzierung der technischen Komplexität versuchen, die Lehre von Information Retrieval Konzepten und Techniken auch in nicht-technischen Studiengängen zu ermöglichen.

5

Im vierten Kapitel wird das Xtrieval Framework und dessen Weiterentwick-lung vorgestellt. Die Erhöhung der Geschwindigkeit und die Verbesserung der Konfigurationsmöglichkeiten standen hierbei im Vordergrund. Durch mehrere Teilnahmen an internationalen Evaluationskampagnen wurde die Eignung des Frameworks für verschiedenartige Experimente und deren Evaluation gezeigt. Das Xtrieval Framework bildet die Grundlage für eine neu-entwickelte Webanwendung zur Durchführung von Retrievalexperimenten mit realen Daten. Das Ziel der Webanwendung ist jedoch nicht, den vollstän-digen Funktionsumfang des Xtrieval Frameworks abzubilden, sondern den Retrievalprozess anschaulich darzustellen und eine effiziente Evaluation einzelner Komponenten zu ermöglichen. Im Zuge dessen eignet sich das Xtrieval Web Lab für den Einsatz in der Lehre als Experimentierumgebung für Studierende. Der Einsatz von Spielemechaniken unterstützt den Lernprozess und motiviert die Studierenden.

Das fünfte Kapitel ist der Überprüfung der Wirksamkeit des Xtrieval Web Labs gewidmet. Eine Gruppe von 50 Studierenden führte mit der Webanwendung mehrere Experimente durch. In eine Befragung vor und nach der Nutzung des Xtrieval Web Labs konnte ein besseres Verständnis der Studierenden bezüglich der verwendeten Retrievalkomponenten nachgewiesen werden. Trotz einiger Startschwierigkeiten einzelner Teilnehmer zogen alle ein über-wiegend positives Fazit hinsichtlich ihrer Erfahrungen mit der Anwendung.

Das letzte Kapitel schließt die vorliegende Arbeit mit einer Zusammenfas-sung der Ergebnisse ab und gibt einen Ausblick auf Verbesserungsmöglich-keiten und weitere Forschungsvorhaben, die sich anschließen könnten.

7

2 Grundlagen

In diesem Kapitel werden die theoretischen Grundlagen für die nachfolgen-den Kapitel gelegt. Zentrale Konzepte des Information Retrievals und der Evaluation werden vorgestellt. Neben einigen Retrievalkomponenten und -modellen werden verschiedene Evaluationsmetriken behandelt. Das Kapitel schließt mit dem Themen E-Learning und Motivation mittels Spielemechani-ken ab.

2.1 Information Retrieval

Information Retrieval befasst sich mit der Repräsentation, der Ablage bzw. Speicherung und der Organisation von Informationen und dem Zugriff auf diese (vgl. Salton & McGill, 1983, S. 1 und Baeza-Yates & Ribeiro-Neto, 1999, S. 1). Salton et al. (1983) heben hierbei die Freiheitsgrade bezüglich der be-handelten Informationsarten hervor:

Information Retrieval (IR) is concerned with the representation, storage, organization, and accessing of information items. In principle no restriction is placed on the type of item handled in information retrieval. (Salton et al., 1983, S. 1)

Für Baeza-Yates et al. (1999) ist dagegen ein möglichst einfacher Zugriff auf die Informationen, die den Nutzer interessieren, wichtig.

Information retrieval (IR) deals with the representation, storage, organization of, and access to information items. The representa-tion and organization of the information items should provide the user with easy access to the information in which he is interested. (Baeza-Yates et al., 1999, S. 1)

8

Der Begriff des Informationsbedürfnisses ist für Manning, Raghavan und Schütze (2008) bei ihrer Definition von Information Retrieval ebenso zentral, wie eine große Dokumentensammlung, die für die Befriedigung des Informa-tionsbedürfnisses herangezogen werden muss:

Information retrieval (IR) is finding material (usually documents) of an unstructured nature (usually text) that satisfies an information need from within large collections (usually stored on computers). (Manning, Raghavan & Schütze, 2008, S. 1)

Spärck Jones und Willett (1997) unterteilen das Dokumentretrieval, das ein Teilaspekt des Information Retrievals ist, in die beiden Aktivitäten Indizieren und Suchen:

Document retrieval subsumes two related, but different, activities: indexing and searching. Indexing refers to the way documents […] and requests […] are represented for retrieval purposes. Searching refers to the way the file is examined and the items in it are taken as related to a search query. (Spärck Jones et al., 1997, S. 1)

Salton und Harman (2003) sehen die Hauptfunktion in der Erschließung von Informationen für eine größere Nutzergruppe:

An IR system is designed to make a given stored collection of infor-mation items available to a user population. (Salton et al., 2003, S. 858)

Information Retrieval Systeme unterstützen diesen Prozess mit technischen Hilfsmitteln. Fuhr und Klas (2014) von der Fachgruppe Information Retrieval der Gesellschaft für Informatik heben hierbei die Unterstützung des Wissen-stransfers zwischen Menschen hervor:

9

Im Information Retrieval (IR) werden Informationssysteme in Bezug auf ihre Rolle im Prozeß des Wissenstransfers vom menschlichen Wissensproduzenten zum Informations-Nachfragenden betrachtet. (Fuhr & Klas, 2014)

Nach Kuhlen (2013, S. 4) ist Information „Wissen in Aktion und Kontext“. Information ist also abhängig von einer konkreten Anwendung und dem Kontext, in dem sie angewendet wird. Wichtige Eigenschaften von Informati-onen, die besonders für Information Retrieval Systeme relevant sind, werden von Kuhlen (1990) in folgenden beiden Zitaten zusammenfasst:

Danach ist Information […] die Teilmenge von Wissen, die von einer bestimmten Person oder einer Gruppe in einer konkreten Situation zur Lösung von Problemen benötigt wird und häufig nicht vorhan-den ist. (Kuhlen, 1990, S. 13)

Information […] ist wiederverwendbar, wiederaufarbeitbar, entweder durch den gleichen Benutzer in einem anderen Kontext oder auch von neuen Benutzern. (Kuhlen, 1990, S. 15)

In diesem Sinne unterstützen Information Retrieval Systeme den Benutzer bei der Suche nach relevanten Informationen, die aktuell bei ihm nicht vorhanden sind, aber dank der Wiederverwendbarkeit durch ein Information Retrieval System wiedergefunden werden können. Um diese Systeme wissenschaft-lich, d.h. in erster Linie nachvollziehbar, untersuchen zu können, führten Cleverdon, Mills und Keen (1966) erste standardisierte Untersuchungen, die Cranfield-Experimente, durch. Sie entwickelten dabei eine Evaluationsmetho-dik, die als Cranfield-Paradigma in die Wissenschaft Einzug gehalten hat.

Für eine Evaluation nach dem Cranfield-Paradigma ist eine gemeinsame Testkollektion von wesentlicher Bedeutung. Sie besteht aus einer Menge von Dokumenten und Suchanfragen sowie Relevanzbewertungen, die relevante Dokumente und Suchanfragen miteinander verbinden (siehe Abbildung 2.1).

10

Nachdem ein Information Retrieval System die Dokumente der Testkollekti-on indiziert hat, werden die Suchanfragen in diesem Index gesucht. Anhand der Ergebnisse können mithilfe von Kennzahlen die Ergebnisse unterschied-licher Information Retrieval Systeme miteinander verglichen werden. Diese Systeme bestehen hierbei immer weniger aus monolithischer Software, sondern zunehmend aus einzelnen Komponenten, die ihren Beitrag zum Gesamtergebnis leisten. Eine aktuelle Herausforderung besteht darin, die Leistungsfähigkeit dieser Komponenten zu bestimmen und vorherzusagen (vgl. Kürsten, 2012 und Kürsten, Wilhelm & Eibl, 2011).

Abbildung 2.1: Übersicht über das Zusammenspiel von Testkollektion, Information Retrieval System und Evaluation

2.1.1 Systeme und Komponenten

Ein System kann als eine Anordnung von Komponenten betrachtet werden, die in einer spezifischen Anordnung und Ausprägung ein charakteristisches Ergebnis liefern, das mittels Evaluationsmetriken bewertet werden kann. Wird eine Komponente in diesem System deaktiviert oder entfernt, so kann deren Einfluss auf das Gesamtergebnis des Systems bestimmt werden. Ebenso können weitere Abhängigkeiten zwischen einzelnen Komponenten

11

durch gezieltes Ein- und Ausschalten entdeckt und/oder überprüft werden. Komponenten im Sinne dieser Arbeit sind alle Aspekte eines Systems, die aktiviert, deaktiviert oder ausgetauscht werden können. Dazu zählen vor al-lem die Vorverarbeitung von Dokumenten, Indizierungs- und Suchverfahren.

Klassische Komponenten für die Vorverarbeitung sind:

– Transformation von Daten in eine interne Repräsentation (Parser)– Zerlegung von Zeichenketten in Tokens (Tokenizer)– Eliminierung von Stoppwörtern– Stemming bzw. Wortstammbestimmung– Thesauri bzw. die Verwendung von Synonymen

Die Auswirkungen dieser Verarbeitungsschritte sollen anhand eines Beispiels verdeutlicht werden. Die XML-Datei in Listing 2.1 entstammt aus dem IAPR TC-12 Benchmark (vgl. Grubinger, Clough, Müller & Deselaers, 2006), das aus 20.000 annotierten Fotografien mit einem touristischen Hintergrund besteht und bei mehreren ImageCLEF Tracks zum Einsatz kam (siehe Kapitel 4.1.2.1 bis 4.1.2.3). Sie ist der Ausgangspunkt für die folgenden Beschreibungen einiger wichtiger Retrievalkomponenten.

<DOC><DOCNO>40/40000</DOCNO><TITLE>The Chairlift of Stanley (Doppelmair)</TITLE><DESCRIPTION>the mountain station of a chairlift on a hill with brown grass; a small village with houses, roads, trees and brown meadows behind it; the sea and grey clouds in a blue sky in the background;</DESCRIPTION><LOCATION>Stanley, Australia</LOCATION><DATE>April 2002</DATE></DOC>

Listing 2.1: Unverarbeitetes Beispieldokument (XML) aus dem IAPR TC-12 Benchmark

12

2.1.1.1 Parser

Daten können in vielen verschiedenen Formaten vorliegen. Die Varianten an Dateiformaten reichen von Plain-Text über XML (Extensible Markup Language) bis zu PDF-Dateien (Portable Document Format). Jedes Format hat hierbei seine Existenzberechtigung. So sind Plain-Text-Dateien einfach einzulesen, aber können nur indirekt semantische Daten transportieren. XML-Dateien sind hier besser geeignet. Sie sind einfach und flexibel struktu-riert und können, vorrausgesetzt die Semantik ist bekannt, eben solche Da-ten besser trennen. Die Zielstellung bei PDF-Dateien ist eher eine konsistente Darstellung, als eine maschinenlesbare Repräsentation der Daten. Jedoch kann diese durch eingebettete Metadaten sichergestellt werden.

Jedes dieser Dateiformate ist potentiell dazu geeignet, durchsuchbare In-formationen zu enthalten, und muss deshalb eingelesen und in eine interne Repräsentation, also ein Dokument, überführt werden können. Diese Aufga-be übernehmen Parser. Ein Parser liest eine Datei ein und erstellt ein ent-sprechendes Dokument. Ein Dokument besteht hier aus einem eindeutigen Identifikator (Dokument-ID) und einem oder mehreren benannten Feldern. Jedes Feld kann Daten, z.B. Text, aus der Ursprungsdatei enthalten, die im weiteren Verlauf modifiziert und letztendlich indiziert werden.

Aus der Beispieldatei im XML-Format (Listing 2.1) wird eine interne Reprä-sentation erstellt. Sie basiert auf Feldern, die sich aus einem Namen und dem Inhalt zusammensetzen:

13

id : 40/40000title : The Chairlift of Stanley (Doppelmair)description : the mountain station of a chairlift on a hill with brown grass; a small village with houses, roads, trees and brown meadows behind it; the sea and grey clouds in a blue sky in the background; location : Stanley, Australiadate : April 2002

Listing 2.2: Beispieldokument nach dem Einlesen durch einen Parser

2.1.1.2 Tokenizer

Ohne weitere Verarbeitung kann ein Programm bei einem Text lediglich auf einzelne Zeichen zugreifen. Diese Zeichen aus einem Text sind individuell und ohne weiteren Kontext nicht von Nutzen. Sie müssen zu logisch zusam-menhängenden Texteinheiten, so genannten Tokens, aggregiert werden. Ge-wöhnlich sind Tokens einzelne Wörter oder Terme. Komplexe Strukturen, wie E-Mail-Adressen, Internetadressen (URLs), Phrasen oder Emoticons, können ebenso ein Token sein.

Einfache Tokenizer trennen Tokens an Leerzeichen oder Zeichen, die keine Buchstaben sind, ab. Dieser Ansatz schlägt jedoch bei komplexeren Spra-chen fehl, wie z.B. beim Chinesischen. Weiterentwickelte Tokenizer setzen deshalb auf grammatik- bzw. regelbasierte Verfahren. Folgendes Resultat (Listing 2.3) entsteht nach Anwendung des Standard-Tokenizers von Apache Lucene auf das Beispieldokument, nachdem es vom Parser eingelesen wurde:

14

id : 40/40000title“ : [ „The“, „Chairlift“, „of“, „Stanley“, „Doppelmair“ ]description : [ „the“, „mountain“, „station“, „of“, „a“, „chairlift“, „on“, „a“, „hill“, „with“, „brown“, „grass“, „a“, „small“, „village“, „with“, „houses“, „roads“, „trees“, „and“, „brown“, „meadows“, „behind“, „it“, „the“, „sea“, „and“, „grey“, „clouds“, „in“, „a“, „blue“, „sky“, „in“, „the“, „background“ ]location : [ „Stanley“, „Australia“ ]date : [ „April“, „2002“ ]

Listing 2.3: Beispieldokument nach der Zerlegung in Tokens durch einen Tokenizer

2.1.1.3 Stoppwort-Filter

Luhn (1958) beschrieb ein Verfahren, um die „signifikanten Wörter“ eines Textes zu bestimmen. Je häufiger ein Wort auftritt, desto signifikanter bzw. aussagekräftiger ist es im Bezug auf das Dokument. Stoppwörter haben wie-derum nur die Funktion, diese signifikanten Wörter miteinander zu verbinden. Sie haben meist keine lexikalische Bedeutung und tragen keine Information, sondern sind vor allem für die Konstruktion vollständiger Sätze notwendig.

Zu der Klasse der Stoppwörter gehören typischerweise:

– Artikel („der“, „die“, „das“, „ein“, „einer“, „eine“, …)– Konjunktionen („und“, „oder“, „als“, „damit“, …)– Modal- und Hilfsverben („müssen“, „wollen“, „haben“, „sein“, …)– Partikel („nicht“, „fast“, „nur“, „nein“, …)– Präpositionen („auf“, „neben“, „hinter“, …)– Pronomen („ich“, „du“, „er“, „sie“, „es“, „wir“, …)

Neben diesen allgemeinen Stoppwörtern gibt es auch solche, die abhängig von der Kollektion sind, z.B. sind die Wörter „Patent“ oder „Erfindung“ in nahezu allen Patenten enthalten und tragen nicht zu einer Diskriminierung zwischen verschiedenen Patenten bei. Bei der Indizierung und nachfolgen-den Suchen kann es hilfreich sein, diese Stoppwörter zu entfernen.

15

In der Vergangenheit war die Größe des Index ein sehr wichtiger Faktor, da Speicher nur in sehr begrenzter Größe vorhanden war. Durch die Entfernung der Stoppwörter aus dem Index kann dieser verkleinert werden. Man stelle sich ein Buch vor, in dessen Index das Wort „und“ enthalten ist. Der Eintrag würde zum einen eine Auflistung fast aller Seiten des Buches umfassen und zum anderen mehrere Seiten in Anspruch nehmen. Die Geschwindigkeit der Suche profitiert ebenfalls von einem kleineren Index. Diese Einschränkungen gelten für moderne Systeme nur noch in geringem Maße. Die Entfernung von Stoppwörtern ist dennoch sinnvoll, da sie durch ihre Häufigkeit zu einem Grundrauschen bei der Suche beitragen. Wenn z.B. in einer Suchanfrage das Wort „der“ enthalten ist, so werden aufgrund dieses Wortes nahezu alle Do-kumente vom System als relevant eingestuft und zurückgeliefert.

Das Entfernen von Stoppwörtern kann unter bestimmten Bedingungen auch nachteilig sein. So wird die Suche nach Phrasen erschwert oder gar un-möglich. Das bekannte Zitat „To be or not to be“ aus Shakespeares Hamlet besteht ausschließlich aus Stoppwörtern und wäre weder im Index repräsen-tiert, noch auffindbar.

id : 40/40000title : [ „The“, „Chairlift“, „Stanley“, „Doppelmair“ ]description : [ „mountain“, „station“, „chairlift“, „hill“, „brown“, „grass“, „small“, „village“, „houses“, „roads“, „trees“, „brown“, „meadows“, „behind“, „sea“, „grey“, „clouds“, „blue“, „sky“, „background“ ]location : [ „Stanley“, „Australia“ ]date : [ „April“, „2002“ ]

Listing 2.4: Beispieldokument nach der Entfernung der Stoppwörter: the, of, a, on, with, and, it, in

Ein Stoppwort-Filter arbeitet meist mit einer vordefinierten Liste von Wör-tern, die bei der Vorverarbeitung entfernt und deshalb nicht indiziert wer-den. Für viele Sprachen gibt es allgemeine Stoppwortlisten, die auch ohne eine Anpassung an das Dokumentenkorpus gute Ergebnisse liefern. Eine

16

korpusspezifische Stoppwortliste ist im Regelfall einer allgemeinen Liste überlegen. Es gibt außerdem Ansätze, diese Listen automatisch anhand von Worthäufigkeiten in einem Dokumentenkorpus zu erstellen. Hierzu werden in einem ersten Durchlauf alle Worthäufigkeiten bestimmt und anhand von Verteilungsmustern Rückschlüsse auf potentielle Stoppwörter gezogen. Savoy (2014) unterhält eine umfangreiche Sammlung von Stoppwortlisten für verschiedene Sprachen, darunter viele europäische Sprachen, aber auch Arabisch, Russisch und Hindi.

2.1.1.4 Stemming

In der deutschen Sprache können sich Wörter durch ihren Kontext verändern. So werden aus einem „Baum“ mehrere „Bäume“ oder jemand „sang“ gestern und „singt“ heute. Diese Flexionen sind oft durch Suffixe gekennzeichnet, können ein Wort aber auch tiefgreifend verändern. Andere Sprachen nutzen ebenso Flexionen. So wird zum Beispiel im Englischen aus „you do“ bei ei-nem Wechsel der Person „he does“.

Im Information Retrieval können Flexionen jedoch beim Vergleich von Suchanfrage und Dokumenten hinderlich sein. Das Stemming ist ein Verfah-ren, um Wörter, die durch Flexion verändert wurden, auf eine Stammform zu reduzieren. Wenn nun nach „Baum“ gesucht wird, werden auch Dokumente mit „Bäumen“ gefunden.

Stemmingverfahren können in folgende Gruppen eingeteilt werden:

– Wörterbuchbasiertes Stemming– Regelbasiertes Stemming– Statistisches Stemming

Bei einem wörterbuchbasierten Stemming ist das Ergebnis vor allem vom Umfang und der Qualität des verwendeten Wörterbuches abhängig. Wörter,

17

die nicht im benutzten Wörterbuch enthalten sind, können nicht korrekt reduziert werden. Jedoch nimmt die Geschwindigkeit dieser Verfahren mit zunehmender Größe des Wörterbuches rasch ab.

Der Porter-Stemmer zählt zu den bekanntesten Vertretern der regelbasierten Stemmingverfahren für die englische Sprache (vgl. Porter, 1980). Im Ge-gensatz zu anderen verbreiteten Verfahren, die durch komplexe Regelwerke versucht haben, alle Suffixe zu entfernen, setzt er auf das wiederholte Ent-fernen von einfachen Suffixen. Suffixe werden jedoch nur entfernt, solange das verbleibende Wort bestimmte Kriterien erfüllt. Porter ging davon aus, dass unregelmäßige Flexionen selten auftreten und deshalb keinen großen Einfluss auf die Retrievalergebnisse haben.

Im Rahmen des Snowball-Projekts2 wurde auf der Basis des Porter-Stem-mers eine Sprache (Snowball) zur Implementierung regelbasierter Stemmer entwickelt. Mittels der Snowball-Sprache entstanden Stemmer für insgesamt 13 Sprachen, darunter Englisch, Deutsch, Französisch, Norwegisch und Rus-sisch. Porter nutzte das Snowball-Projekt auch für die Veröffentlichung des Quellcodes des originalen Porter-Stemmers, um fehlerhafte Implementierun-gen zu vermeiden, die bei einem Vergleich mit anderen Stemmingverfahren zu fehlerhaften Vergleichen der Ergebnisse führten (vgl. Porter, 2006).

id : 40/40000title : [ „The“, „Chairlift“, „Stanlei“, „Doppelmair“ ]description : [ „mountain“, „station“, „chairlift“, „hill“, „brown“, „grass“, „small“, „villag“, „hous“, „road“, „tree“, „brown“, „meadow“, „behind“, „sea“, „grei“, „cloud“, „blue“, „sky“, „background“ ]location : [ „Stanlei“, „Australia“ ]date : [ „April“, „2002“ ]

Listing 2.5: Beispieldokument nach der Anwendung des Porter-Stemmers

2 http://snowball.tartarus.org/ (21. Januar 2015)

18

In diesem Beispiel (Listing 2.5) wird der Porter-Stemmer aus dem Snow-ball-Projekt angewendet. Bei den Wörtern „road“ und „tree“ wird hierbei die Endung „s“ entfernt, sodass aus den Pluralformen die Singularformen gebil-det werden. Andere Wörter wie „houses“ (hous) oder „grey“ (grei) werden so verändert, dass nicht der erwartete englische Wortstamm entsteht.

Der Krovetz-Stemmer (Krovetz, 1993) ist ein hybrider Ansatz und verbindet ein regelbasiertes Verfahren mit einem Wörterbuch. Im ersten Schritt werden alle Pluralformen eines Wortes in die Singularform transformiert. Der zweite Schritt überführt alle Wörter aus der Vergangenheitsform in die Gegenwarts-form. Beide Schritte werden durch ein Wörterbuch unterstützt, sodass stets korrekte, englische Wörter entstehen. Im letzten Schritt wird der Suffix „ing“ entfernt. Da der Krovetz-Stemmer immer morphologisch korrekte Wörter liefert, könnte in einem weiteren Schritt ein anderer Stemmer angewendet werden, um auch Wörter, die nicht im Wörterbuch des Krovetz-Stemmers enthalten sind, zu reduzieren.

id : 40/40000title : [ „Chairlift“, „Stanley“, „Doppelmair“ ]description : [ „mountain“, „station“, „chairlift“, „hill“, „brown“, „grass“, „small“, „village“, „house“, „road“, „tree“, „brown“, „meadow“, „behind“, „sea“, „grey“, „cloud“, „blue“, „sky“, „background“ ]location : [ „Stanley“, „Australia“ ]date : [ „April“, „2002“ ]

Listing 2.6: Beispieldokument nach der Anwendung des Krovetz-Stemmers

N-Gram-Stemmer zählen zu den statistischen Stemmern, nehmen aber eine Sonderrolle ein, da sie sprachunabhängig funktionieren. Ein n-Gram-Stem-mer entfernt keine Prefixe oder Suffixe, sondern zerlegt ein Wort in sich überlappende Teilwörter mit der Länge n. So werden zum Beispiel aus dem Wort „Bauer“ von einem 3-Gram-Stemmer folgende Teilwörter erzeugt: „__B“, „_Ba“, „Bau“, „aue“, „uer“, „er_“, „r__“. Je länger ein Wort ist, desto mehr Teilwörter entstehen, was zu einem sehr großen Index und einer erhöhten

19

Verarbeitungszeit führt. Kleine Veränderungen in einem Wort führen so zu Treffern, wenn weiterhin genügend übereinstimmende Teilwörter vorhanden sind. Dieses Verfahren eignet sich besonders für Komposita, da das aus mehreren Wörtern zusammengesetzte Wort zerlegt wird und alle Teilwörter gesucht werden. Bei der Suche nach einem „Bauernhof“ würde eine Zerle-gung in 3-Gramme auch bei den Wörtern „Bauer“ und „Hof“ Treffer liefern.

id : 40/40000title : [ „Chai“, „hair“, „airl“, „irli“, „rlif“, „lift“, „Stan“, „tanl“, „anle“, „nley“, „Dopp“, „oppe“, „ppel“, „pelm“, „elma“, „lmai“, „mair“ ]description : [ „moun“, „ount“, „unta“, „ntai“, „tain“, „stat“, „tati“, „atio“, „tion“, „chai“, „hair“, „airl“, „irli“, „rlif“, „lift“, „hill“, „brow“, „rown“, „gras“, „rass“, „smal“, „mall“, „vill“, „illa“, „llag“, „lage“, „hous“, „ouse“, „uses“, „road“, „oads“, „tree“, „rees“, „brow“, „rown“, „mead“, „eado“, „adow“, „dows“, „behi“, „ehin“, „hind“, „grey“, „clou“, „loud“, „ouds“, „blue“, „back“, „ackg“, „ckgr“, „kgro“, „grou“, „roun“, „ound“ ]location : [ „Stan“, „tanl“, „anle“, „nley“, „Aust“, „ustr“, „stra“, „tral“, „rali“, „alia“ ]date : [ „Apri“, „pril“, „2002“ ]

Listing 2.7: Beispieldokument nach der Anwendung des 4-Gram-Stemmers

In diesem Beispiel wurde ein 4-Gram-Stemmer angewendet. Das Anwach-sen der Größe des Dokuments wird im Vergleich zum Porter-Stemmer gut sichtbar.

Wie bereits für Stoppwortlisten, stellt Savoy (2014) eine Vielzahl von Stem-mern für verschiedene Sprachen bereit. Die Stemmer für die europäischen Sprachen sind meist in C implementiert, für andere Sprachen wie Persisch oder Hindi sind sie in Java implementiert.

20

2.1.1.5 Indizierung

Im Kontext dieser Arbeit wird ausschließlich das Konzept des invertierten Index betrachtet. Der invertierte Index, auch invertierte Datei genannt, ist das dominierende Konzept zur Indizierung. Weitere Arten von Indizes, wie z.B. Suffix-Trees und Suffix-Arrays, werden u.a. von Baeza-Yates und Ribeiro-Neto (1999, S. 199ff.) beschrieben.

Die Grundidee des invertierten Index ist die Herstellung einer Zuordnung von Wörtern bzw. Termen zu Dokumenten. Ähnlich wie bei einem Index in einem Buch werden Terme in einer sortierten Liste organisiert. Zu jedem Term existiert eine weitere Liste mit allen Vorkommen des Terms – im Fall eines Buches wären das die Seiten und für ein Korpus die Dokumente. Über diese Zuordnung können schnell alle Dokumente identifiziert werden, die ein bestimmtes Wort enthalten.

Der Vorteil eines invertierten Index ist der geringere Zeitaufwand, der für das Auffinden von Dokumenten, die einen bestimmten Term enthalten, benötigt wird. Die natürliche Alternative wäre ein sequenzielles Durchsuchen der Dokumente, das deutlich mehr Zeit benötigt als das Nachschlagen in einem Index.

Zusätzlich zur Speicherung der Vorkommen ist es für die Suche nützlich, weitere Daten in einem invertierten Index zu hinterlegen. Vor allem statis-tische Daten, z.B. über die Gesamtzahl von Wörtern in einem Korpus oder die Gesamthäufigkeit eines Terms, sind für verschiedene Retrievalmodelle notwendig und müssten andernfalls bei der Suche aufwendig berechnet werden. Ebenso können Positionsdaten für bestimmte Arten von Suchanfra-gen, wie z.B. die Suche nach Phrasen, notwendig sein. (vgl. Baeza-Yates & Ribeiro-Neto, 1999, S. 192-198)

21

2.1.1.6 Suche und Retrievalmodelle

Bei der Suche werden Suchanfragen mit den Dokumenten eines Korpus ver-glichen und alle vom System als relevant eingestuften Dokumente zurück-gegeben. Eine Suche kann durch die Verwendung eines invertierten Index beschleunigt werden, ähnlich der Suche nach einem Fachbegriff im Index eines Buches. Dies erscheint auf den ersten Blick durchaus trivial, jedoch enthält ein Buch im Vergleich zu Tausenden von Dokumenten vergleichswei-se wenige unterschiedliche Wörter und dessen Index wird meist intellektuell angelegt, d.h. eine mit der Thematik vertraute Person entscheidet, welche Wörter in den Index gehören und welche nicht. Der Suchraum ist deshalb bei einem Buch oft kleiner als bei einem Korpus aus vielen Dokumenten.

Eine Herausforderung stellt hierbei die Suche nach mehreren Wörtern dar. Diese können in einem Index nachgeschlagen werden und die entsprechen-den Vorkommen miteinander verglichen werden. Bei mehreren tausend Dokumenten kommt so aber eine beachtliche Menge an Dokumenten, die relevant sein könnten, zusammen. Hier wird ein Ranking nötig, das die Do-kumente in eine Reihenfolge bringt, wobei das wahrscheinlich am meisten relevante Dokument am Anfang der Reihe steht.

Für die Auswahl relevanter Dokumente und ggf. für die Erstellung eines Rank-ings dieser Dokumente kommen spezielle Retrievalmodelle zum Einsatz. In den folgenden Abschnitten werden einige klassischen Retrievalmodelle kurz vorgestellt. Einen umfassenderen Einblick in diese Thematik geben z.B. Hiemstra (2009) oder Manning, Raghavan und Schütze (2008, S. 201ff.)

Boolesches Modell

Auf der Basis der Booleschen Operatoren (vgl. Boole, 1854) und der Men-genlehre werden Dokumente in Form von Mengen von Termen repräsentiert. Wenn ein Term in einem Dokument enthalten ist, dann hat er für dieses

22

Dokument den Wert true/wahr, sonst false/falsch. Eine Suchanfrage ent-spricht dabei einem Booleschen Ausdruck, der Terme aus den Dokumenten enthält, die durch Boolesche Operatoren miteinander verbunden sind, z.B. „romeo AND juliett“ oder „january OR february“ usw. Durch das Ersetzen der Terme durch deren Wahrheitswerte in einem Dokument kann auf einfache Art und Weise ermittelt werden, ob ein Dokument zu einer Suchanfrage passt.

Diese Art von Matching wird auch als „Exact-match“ bezeichnet, da die Suchanfragen sehr genau mit den Dokumenten abgeglichen werden. Auf der einen Seite hat das den Vorteil, dass eine präzise Suchanfrage genau die gesuchten Dokumente liefert, jedoch ist die Formulierung einer solchen Suchanfrage auf der anderen Seite nicht trivial. Es eignet sich also vor allem, wenn das gesuchte Dokument bzw. dessen Inhalt exakt beschrieben werden kann oder muss, wie es z.B. beim Patentretrieval notwendig ist.

Für jedes Dokument wird lediglich bestimmt, ob es zur Suchanfrage passt oder nicht. Es findet kein Ranking statt. Abhilfe schafft hier das Erweiterte Boolesche Retrieval (vgl. Salton, Fox & Wu, 1983), welches die Werte false und true auf den Wertebereich [0, 1] ausweitet und damit das Boolesche Modell um die Möglichkeit der Gewichtung von Termen und Dokumenten erweitert.

TF/IDF

Die Termfrequenz/Inverse Dokumentfrequenz, kurz TF/IDF, ist ein Maß zur Termgewichtung, die wiederum zur Erstellung einer Reihenfolge von Such-ergebnissen genutzt werden kann. Die Termfrequenz stellt die Wichtigkeit eines Terms im Kontext eines Dokumentes dar. Sie entspricht einem Häufig-keitsmaß des Terms innerhalb des Dokuments. Hierbei hat sich eine Form der relativen Termhäufigkeit nach Salton (1968, S. 359) etabliert:

23

TF(t, d) =freq(t, d)

L

t steht für einen Term und d für ein Dokumentfreq(t, d) ist die Häufigkeit von t in d

L ist die Länge des Dokuments d

Um das Gewicht von besonders häufigen Wörtern zu reduzieren, entwickel-te Harman (1986, S. 190) eine logarithmische Variante, da ein Wort, das zehnmal häufiger auftritt, nicht zehnmal mehr Bedeutung für das Dokument besitzt.

TF(t, d) =log (freq(t, d) + 1)

logL

Die inverse Dokumentfrequenz (IDF) basiert ebenfalls auf den Beobachtun-gen von Luhn (1958), die schon für die Entfernung von Stoppwörtern heran-gezogen wurden (vgl. Kapitel 2.1.1.3). Die IDF ist ein Maß für die Spezifität eines Terms, d.h. besonders häufig auftretende Wörter innerhalb eines Kor-pus diskriminieren dessen Dokumente nur schlecht oder gar nicht. Für die Termgewichtung heißt das, je unspezifischer ein Term ist, desto geringer fällt seine Gewichtung aus. (vgl. Spärck Jones, 1973)

IDF(t) = logN

n

N ist die Anzahl Dokumente im Korpusn ist die Anzahl Dokumente, die den Term t enthalten

(vgl. Robertson, 2004, S. 504)

24

Der Vorteil von TF/IDF ist die einfache Berechenbarkeit, wenn alle notwen-digen Kenngrößen bekannt sind. Diese können z.B. während der Indizierung erfasst und gespeichert werden, was eine schnelle Berechnung ermöglicht. Ein Nachteil von TF/IDF ist jedoch die Reduktion der Aussagekraft eines Terms auf seine Häufigkeit. Andere Aspekte, wie z.B. die Semantik, bleiben wie beim Boolschen Modell und dem Vektorraummodell unbeachtet.

Vektorraummodell

Im Vektorraummodell (engl. Vector Space Model) nach Salton und MacGill (1984) spannen die Terme einen Vektorraum auf, in dem Dokumente und Suchanfragen in Form von Vektoren repräsentiert werden. Zwei Vektoren werden anhand des Winkels zwischen ihnen verglichen. Je kleiner der Winkel, desto ähnlicher sind sich die Vektoren bzw. Dokumente. Im Beispiel aus Abbildung 2.2 ist der Winkel zwischen Suchanfrage und Dokument 2 am geringsten, d.h. dieses Dokument ist zur Suchanfrage am ähnlichsten. Dieses Modell eignet sich vor allem für einen Vergleich von Dokumenten, sodass ähnliche Dokumente zu einem bekannten Dokument gesucht werden können. Der strukturelle Aufbau von Vektoren für kurze Suchanfragen kann sich stark von echten Dokumenten unterscheiden. Deshalb argumentieren Bollmann-Sdorra und Raghavan (1993) für eine Unterscheidung zwischen Dokument- und Suchanfragenraum.

Ein weiteres Problem ist die Unabhängigkeit der Terme. Diese ist durch die Orthogonalität der Termvektoren, die den Raum aufspannen, gefordert, aber nicht immer in der Realität gegeben. Durch Stemming, die Verwendung von Thesauri oder die Bildung von Wortklassen können Abhängigkeiten reduziert, aber nicht vollständig ausgeschlossen werden. Die Verwendung von Opera-toren, wie sie beim Booleschen Retrieval erfolgt, ist beim Vektorraummodell nicht möglich, da es im Vektorraummodell u. a. keine Repräsentation des NOT-Operators gibt.

25

Abbildung 2.2: Vektorraummodell für drei Terme als 2-dimensionale Darstellung

Probabilistische Modelle

Probabilistische Modelle basieren auf der Wahrscheinlichkeitstheorie und der Mengenlehre. Mittels der Wahrscheinlichkeitstheorie werden die zahl-reichen Unsicherheiten im Retrieval Prozess modelliert, d.h. insbesondere der Übergang vom Informationsbedürfnis zur Suchanfrage und die Reprä-sentation von Dokumenten im Index. Grundlegend für alle probabilistischen Modelle ist die Annahme, dass ein Dokument d unter der Bedingung der Suchanfrage q eine Wahrscheinlichkeit P(R|q,d) besitzt, relevant zu sein. Entsprechend dieser Wahrscheinlichkeit werden die Dokumente in die Ergeb-nisliste einsortiert.

Binary Independece Model und BM25

Das Binary Independence Model nach Robertson und Spärck Jones basie-rend auf Maron und Kuhns (1960) und nachfolgend Yu und Salton (1976)

26

repräsentiert Dokumente als binäre Vektoren, die das Auftreten bzw. Nicht-Auftreten aller Terme beschreiben. Wie im Vektorraummodell wird die Annahme getroffen, dass alle Terme unabhängig voneinander sind. Als Ver-gleichsmaß wird das Skalarprodukt aus Dokument- und Suchanfragenvektor eingesetzt, wobei die Verwendung von Termgewichten (vgl. TF/IDF) für gute Ergebnisse essentiell ist.

Das Retrievalmodell BM25 basiert auf dem Binary Independence Model und erweitert dieses um Termgewichte für Dokument- und Suchanfragenterme. Spärck Jones, Walker und Robertson (2000) diskutieren das Modell und dessen Verbesserungen gegenüber dem Binary Independence Model aus-führlich. Es wurde erfolgreich bei zahlreichen TREC Experimenten eingesetzt und zählt auch bei CLEF zu den am häufigsten verwendeten Modellen (vgl. Wihelm-Stein & Eibl, 2013).

2.1.2 Evaluation

Um die Leistungsfähigkeit von Information Retrieval Systemen bewerten zu können, müssen sie in einem kontrollierten Experiment unter vergleichbaren Bedingungen getestet und verglichen werden. Ein Information Retrieval System produziert eine Ergebnismenge für ein vorgegebenes Informations-bedürfnis. Diese Ergebnismenge kann mithilfe von Relevanzbewertungen und Evaluations-Metriken zu einem Ergebnis für das Information Retrieval System verrechnet werden.

Ein Information Retrieval System kann auf zwei Ebenen evaluiert werden: nutzerorientiert und systemorientiert. Bei der nutzerorientierten Evaluation liegt der Schwerpunkt auf der Zufriedenheit des Nutzers mit dem System und dessen Ergebnissen. Nutzerorientierte Evaluationen neigen dazu, kom-plex und langwierig zu sein, weswegen sie nur allmählich in der Information Retrieval Forschung Fuß fassen.

27

Die systemorientierte Evaluation versucht, den Faktor Mensch und dessen Subjektivität weitestgehend zu eliminieren, und konzentriert sich auf die Be-wertung von Algorithmen und Methoden. Hier kann die Leistungsfähigkeit ei-nes Systems auf zwei Gebieten bestimmt werden: Effizienz und Effektivität.

Effizienzkriterien können objektiv gemessen und bewertet werden. So ist die Größe eines Index oder die Geschwindigkeit der Indizierung und der Suche einfach zu bestimmen und zu vergleichen. Wie so oft in der Informatik ver-halten sich Größe und Geschwindigkeit umgekehrt proportional zueinander. Durch Technologien zum verteilten Rechnen lassen sich Indizes auf viele Rechenknoten verteilen und können so die Suchanfragen parallel bearbeiten, was sich in einer höheren Geschwindigkeit widerspiegelt. Dabei nehmen die Indizes wiederum mehr Speicherplatz in Anspruch,

Die Bestimmung der Effektivität und deren Vergleich lässt sich nicht mehr auf ein objektives Maß zurückführen. Die Begriffe Informationsbedürfnis und Relevanz spielen für die Effektivität eine zentrale Rolle. Ohne Relevanz könnten verschiedene Experimente nur anhand ihrer Eingaben und Ausga-ben verglichen werden. D.h. mit vergleichbaren Eingaben sollten Ausgaben entstehen, die ebenso vergleichbar sind. Jedoch kann man natürlich die Aus-gaben, also die Ergebnislisten, direkt miteinander vergleichen, aber ohne das Konzept der Relevanz kann keine Aussage über die bessere oder schlechtere Eignung der Ergebnislisten getroffen werden.

2.1.2.1 Informationsbedürfnis und Suchanfrage

Auf der Nutzerseite beginnt die Verwendung eines Information Retrieval Systems mit einem Problem (real information need), für dessen Lösung In-formation notwendig ist. Basierend auf diesem Problem nimmt der Nutzer ein Informationsbedürfnis (perceived information need) bewusst wahr. Das Informationsbedürfnis ist also die vom Nutzer gedachte Repräsentation des Problems und der für dessen Lösung möglicherweise notwendigen

28

Informationen. Der nächste Schritt ist die Formulierung eines Anliegens (re-quest) in natürlicher Sprache aufbauend auf dem Informationsbedürfnis. Im letzten Schritt wird das Anliegen in eine Suchanfrage (query) überführt, die in der Anfragesprache des Information Retrieval Systems formuliert ist und von diesem verarbeitet werden kann. Bei jedem dieser Schritte wird für den vor-herigen Schritt eine Repräsentation gebildet, sodass das Ergebnis, also die Suchanfrage, nach dreimaliger Repräsentation aus dem ursprünglichen Pro-blem hervorgegangen ist. Durch jeden dieser Repräsentationschritte nimmt die Ungenauigkeit zu, sodass letztendlich die Suchanfrage und die daraus resultierenden Ergebnisse nur noch bedingt für die Lösung des ursprüngli-chen Problems geeignet sind. (Mizzaro, 1997, S. 811f.; Mizzaro, 1998, S. 4)

Schon Cooper (1971, S. 21) stellte fest, dass jede externe Repräsentation eines Informationsbedürfnisses, z.B. in der Form einer in Wörter gefassten Suchanfrage, stets unvollständig und deshalb ungenau ist.

Derr (1983, S. 276) führte ein Informationsbedürfnis auf ein bestimmtes Ziel zurück, das unter Zuhilfenahme von Informationen erreicht werden kann. Ein elementares Problem sah er vor allem bei der Formulierung von Suchanfra-gen, da diese im besten Fall genau die Information enthalten müsste, die der Nutzer zu finden versucht, obwohl er eben diese noch nicht kennt. Weiterhin kann ein Informationsbedürfnis nicht als statisch angesehen werden. Wäh-rend ein Nutzer versucht, es zu befriedigen, können neue Informationen auf das ursprüngliche Informationsbedürfnis einwirken, es abwandeln und in eine andere Richtung lenken (vgl. Derr, 1983, S. 277).

2.1.2.2 Testkollektion

Eine Testkollektion besteht aus einer Sammlung von Dokumenten (Korpus) und Suchanfragen (Topics) mit dazugehörigen Relevanzbewertungen. Dieser Aufbau wurde erstmals im Rahmen des Cranfield Research Project von Cleverdon, Mills und Keen (1966) beschrieben und wird bis heute als

29

Standardtestaufbau angesehen. Die Bedeutung von Testkollektionen für das Information Retrieval wird bereits durch die Anzahl von internationalen Kampagnen, die sich deren Erstellung und Nutzung widmen, unterstrichen. Im Kapitel 2.1.4 werden die Evaluationskampagnen TREC, CLEF und weitere ausführlicher behandelt.

Ein Korpus besteht aus einer Menge von Dokumenten, die anhand einer ein-deutigen ID (meist DOCID oder DOCNO) identifiziert werden. Die Dokumente können unterschiedliche Formen haben: Die ersten verwendeten Korpora basierten oftmals auf Literaturkatalogen aus bestimmten Fachrichtungen. Moderne Korpora beinhalten im Gegensatz dazu häufiger die Volltexte. Korpora auf Katalogbasis enthalten somit kürzere Dokumente und haben in Folge dessen eine geringere Datenmenge als solche auf Volltextbasis. Auch die Dokumentenanzahl ist über die Jahre kontinuierlich angestiegen. Die Spannweite reicht von Cleverdon und Keen (1966) mit ihren 1.400 Ka-talogbeschreibungen bis zum ClueWeb09 Dataset3 mit etwa einer Milliarde Webseiten (Volltext) in 10 Sprachen und einer Datenmenge von insgesamt 25 Terabyte (unkomprimiert).

Suchanfragen (topics) sind die Repräsentationen von Informationsbedürf-nissen. Sie enthalten stets eine eindeutige ID (meist QID) und einen Titel. Der Titel entspricht hierbei der Suchanfrage und wird als Eingabe für das System verwendet. Es kann eine einfache Beschreibung enthalten sein, die weitere Informationen zur Suchanfrage beinhaltet und ggf. als zusätzliche Eingabe für das System verwendet werden kann. Außerdem gibt es, speziell zur Unterstützung der Juroren, bei der Relevanzbewertung eine erweiterte Beschreibung (narrative) der Aufgabe oder des Kontextes, die der Suchan-frage zugrunde liegen. Diese darf nicht als Eingabe für das System genutzt werden. Theoretisch sollte es für jedes Paar aus Suchanfrage und Dokument eine Relevanzbewertung geben, jedoch wird in der Praxis versucht, vor allem

3 http://lemurproject.org/clueweb09/ (20. September 2015)

30

relevante Paare zu bewerten, sodass für alle nicht bewerteten Paare ange-nommen wird, dass diese nicht relevant sind.

Sanderson (2010) gibt in „Test Collection Based Evaluation of Information Retrieval Systems“ eine Zusammenfassung der Entwicklung von Testkollek-tionen in den letzten 60 Jahren. Dabei untersucht er historische sowie aktuel-le Testkollektionen und befasst sich mit ihrer Aussagekraft. Trotz nützlicher Alternativen zur Erstellung von Testkollektionen, kommt Sanderson am Ende zum Schluss, dass Testkollektionen, bestehend aus Dokumenten, Suchanfra-gen und Relevanzbewertungen, nach wie vor essentiell für die Validierung einer neuen Methodik im Information Retrieval sind.

2.1.2.3 Relevanz

Die Relevanz beschreibt die Beziehung zwischen einem Informationsbedürf-nis, repräsentiert durch die Suchanfrage, und einer Information, repräsentiert durch ein Dokument in einer Testkollektion. Auf einer binären Relevanzskala kann ein Dokument also für eine bestimmte Suchanfrage relevant oder nicht relevant sein. Sormunen (2002) verwendete eine Relevanzskala mit vier Stufen: nicht relevant, gering (marginal) relevant, relevant und sehr (highly) relevant. Dabei stellte er (Sormunen, 2002, S. 328) fest, dass etwa 50% aller als relevant gewerteten Dokumente nur gering bzw. kaum relevant waren. Lediglich 16% der relevanten Dokumente waren sehr relevant.

Bereits Cooper (1972) bescheinigt der Relevanz eine zentrale Bedeutung im Information Retrieval, weist aber sogleich auf die Uneinigkeit bei der Definiti-on und der Verwendung des Begriffes hin:

The concept of ‘relevance’ […] is central to the theory of information retrieval. Unfortunately, however, there is at present no consensus as to how this notion should be defined. (S. 19)

31

Auch Saracevic (1975) beschreibt die fundamentalen Eigenschaften der Relevanz, weiß aber um die vielen anderen Ansichten:

Relevance is considered as a measure of the effectiveness of a contact between a source and a destination in a communication process. […] Different views arose because relevance was consi-dered at a number of different points in the process of knowledge communication. (S. 321)

Selbst im Jahr 2010 sieht Hjørland (2010) noch Diskussionsbedarf und ar-gumentiert, dass die „subject knowledge view of relevance“ von Saracevic (1975) die Grundlage für alle anderen Sichtweisen von Relevanz ist. Einen umfassenderen Überblick über Relevanz und ihren Werdegang in der Wissen-schaft gibt Mizzaro (1997). Darüber hinaus ordnet er die verschiedenen Inter-pretationen von Relevanz in Kategorien ein und wagt eine Systematisierung.

Schon die einfach anmutende Suche nach dem Bild eines Baumes beinhaltet eine große Komplexität. Der Kontext spielt hier eine wichtige Rolle. So könnte jeder beliebige Baum passend sein. Es könnten aber ebenso ausschließlich Laubbäume oder, wenn im Kontext der kanarischen Inseln nach einem Baum gesucht wird, eine Palme gemeint sein. Außerordentlich viele Variationen sind möglich: Nadelbäume, grüne Bäume, herbstlich rote oder gelbe Bäume, Bonsaibäume und viele andere mehr.

Relevanz ist also, aufgrund ihrer Abhängigkeit von einem Informationsbe-dürfnis und dessen Befriedigung, stets subjektiv und deshalb potentiell ungeeignet für eine objektive Messung. In Ermangelung einer Alternative wird sie dennoch angewendet. Es gibt jedoch auch Ansätze diese Subjekti-vität zu reduzieren. So kann eine Relevanzbewertung durch mehrere Juroren durchgeführt werden. Hierbei entstehen jedoch weitere Schwierigkeiten bei der Berechnung der Relevanzbewertung, denn welche Relevanz besitzt ein Dokument für eine Suchanfrage, wenn diese Kombination von den Juroren unterschiedlich bewertet wurde?

32

In Zeiten von immer größeren Datenmengen tritt ein weiteres Problem der Relevanz zu Tage: Sie ist zunehmend unvollständig bestimmt für größere Kollektionen. Ein Beispiel: Für eine Kollektion mit 100 Dokumenten und 10 Suchanfragen müssen 1.000 Relevanzbewertungen vorliegen, damit jede Kombination aus Suchanfrage und Dokument abgedeckt ist. Kollektionen bewegen sich aber inzwischen in ganz anderen Regionen. Z.B. die Kollektion IAPR TC-12 der ImageCLEF Kampagnen 2006 bis 2008 (siehe Kapitel 4.1.2.1 bis 4.1.2.3) umfasst 20.000 Dokumente und 60 Suchanfragen. Es wären also 1.200.000 Relevanzbewertungen für alle möglichen Kombinationen aus Do-kument und Suchanfrage notwendig. Dies ist durch manuelle Bewertungen nur schwer zu erreichen, sodass Relevanzbewertungen für große Kollektio-nen stets unvollständig sind.

2.1.3 Evaluationsmetriken

Zur Bewertung der Leistungsfähigkeit eines Information Retrieval Systems werden im Rahmen einer Evaluation so genannte Metriken verwendet. Met-riken basieren stets auf den Ergebnissen, die ein System für eine bestimmte Suchanfrage liefert, und den entsprechenden Relevanzbewertungen. Mithilfe von Metriken können ganze Systeme bzw. unterschiedliche Konfiguratio-nen miteinander verglichen werden. Eine zentrale Voraussetzung für einen aussagekräftigen Vergleich ist die Verwendung derselben Testkollektion, bestehend aus Dokumenten, Suchanfragen und Relevanzbewertungen. Dies erlaubt einen Vergleich, ohne die Experimente mit dem ursprünglichen Sys-tem wiederholen zu müssen, und ist somit die Grundlage für einen wissen-schaftlichen Diskurs.

Demartini (2006) gibt einen kurzen Überblick über die große Menge an Metriken, die im Laufe der Jahre entwickelt und vorgeschlagen wurden. Nur wenige dieser Metriken kamen jedoch bei den großen Evaluationskampag-nen (siehe auch Kapitel 2.1.4) zum Einsatz. Die Vielzahl an unterschiedlichen

33

Metriken hängt vor allem mit der unterschiedlich bewerteten Eignung für die angedachten Szenarien zusammen.

Im Rahmen des ersten Information Retrieval Experiments von Cleverdon und Keen (1966) waren die Ergebnisse einfache Listen mit vom System als relevant eingestuften Dokumenten. Es gab dabei kein Ranking, welches Dokument am wahrscheinlichsten die benötigte Information enthält. Genau das Gleiche fand sich auf der Seite der Relevanzbewertungen wieder. Hier wurden Dokumente entweder als relevant oder als nicht relevant eingestuft. Deshalb waren die Metriken Precision und Recall sowohl geeignet als auch ausreichend, um die Ergebnisse zusammenzufassen.

Im weiteren Verlauf entstanden Information Retrieval Systeme, die ein Rank-ing vornahmen, was durch Precision und Recall nicht berücksichtigt wurde. Neu oder weiter entwickelte Metriken, wie Mean Average Precision, Precision at n oder Rank-Biased Precision, beziehen das Ranking in ihre Berechnungen mit ein und können so spezifische Benutzungsszenarien modellieren. Viele Metriken, die über die Jahre vorgeschlagen wurden, haben keine weite Ver-breitung erlangt. Die Vielzahl verfügbarer Metriken im Bereich des Ad-hoc Retrievals kann verwirrend sein, zumal einige von ihnen eine hohe Korrela-tion aufweisen (vgl. Baccini, Dejean, Lafage & Mothe 2012). Obwohl einige Metriken beliebter als andere sind, gibt es dennoch keine einzelne Metrik, die allen anderen Metriken überlegen ist.

Verschiedene Metriken beziehen sich auf unterschiedliche Eigenschaften der zugrundeliegenden Testkollektionen und Retrievalverfahren. Z.B. ist es bei Patentretrieval außerordentlich wichtig, dass wirklich alle relevanten Patente gefunden werden, auch wenn das bedeutet, das viele nicht relevante Patente in den Ergebnissen zu finden sind. Der Fokus liegt hier also vorrangig auf dem Recall. Im Gegensatz dazu reicht bei einer Faktenfrage eine richtige Antwort aus, um das Informationsbedürfnis des Nutzers zu befriedigen. Die Precision sollte hier maximal sein.

34

2.1.3.1 Precision und Recall

Precision und Recall zählen zu den frühen Metriken, die bereits von Cleverdon und Keen (1966) im Rahmen der Cranfield Experimente verwendet wurden und bis heute einen hohen Stellenwert haben.

Zur Berechnung werden folgende Mengen definiert:

Abbildung 2.3: Mengen zur Berechnung von Precision und Recall

N ist die Menge aller Dokumente im KorpusR ist die Menge aller relevanten Dokumente

S ist die Menge der vom System gefundenen Dokumentet sind alle vom System gefundene und relevante Dokumente

Precision

Die Precision beschreibt die Genauigkeit der Ergebnismenge bzw. den Anteil relevanter und gefundener Dokumente an der Menge aller gefundenen Doku-mente. Sie beschreibt gewissermaßen die Effizienz der Suche. Ihr Wertebe-reich liegt zwischen 0 und 1 bzw. 0% und 100%.

35

p =

|R ∩ S|

|S|=

|t|

|S|

Recall

Der Recall gibt die Vollständigkeit der Ergebnismenge an bzw. den Anteil relevanter und gefundener Dokumente an der Menge aller relevanten Doku-mente. Er hat ebenso einen Wertebereich von 0 bis 1 bzw. 0% bis 100%.

r =|R ∩ S|

|R|=

|t|

|R|

Precision und Recall werden stets gemeinsam betrachtet, da sie nur ge-meinsam aussagekräftig sind. So wäre der maximale Recall relativ einfach zu erreichen, indem alle Dokumente des Korpus als Ergebnis zurückgeliefert werden. Jedoch wäre die Precision hierbei minimal. Umgedreht reicht ein einziges gefundenes, relevantes Ergebnis aus, um die maximale Precision zu erzielen. Wenn es in diesem Fall jedoch sehr viele relevante Dokumente gibt, dann wäre der Recall wiederum minimal. Es gilt also, dass bei steigendem Recall im Allgemeinen die Precision abnimmt. Das Ziel ist es also, beide Werte gemeinsam auf ein Maximum zu bringen.

Precision-Recall-Diagramm

Recall und Precision eignen sich für gerankte Ergebnislisten nur bedingt, da sie die Reihenfolge der Ergebnisse nicht berücksichtigen. Precision-Re-call-Diagramme schaffen hier Abhilfe. Für jedes relevante Dokument aus der Ergebnisliste werden die Precision und der Recall an dieser Stelle berechnet und deren Werte in das Diagramm eingetragen. Das resultierende Diagramm (Abbildung 2.4, durchgezogene Linie) fasst die Qualität der Ergebnisse

36

anschaulich zusammen. Je höher die Kurve verläuft, desto höher ist die Pre-cision, d.h. der Anteil relevanter Dokumente an den zurückgelieferten Doku-menten ist höher. Und je weiter nach rechts die Kurve reicht, desto höher ist der Recall, d.h. es wurde ein größerer Anteil relevanter Dokumente gefunden.

Abbildung 2.4: Precision-Recall-Diagramm mit typischer Sägezahn-Form

Typisch für Precision-Recall-Diagramme ist die in Abbildung 2.4 sichtbare Sägezahn-Form. Diese Form entsteht wenn die Werte für Precision und Recall für jedes einzelne Ergebnis berechnet und eingetragen werden. Bei nicht-relevanten Ergebnissen sinkt die Precision, ohne dass sich der Recall verändert. Es entstehen senkrecht abfallende Kanten. Im Falle relevanter Ergebnisse steigen Precision und Recall gleichzeitig an. Das Resultat sind schräg ansteigende Kanten. Durch die Kombination beider Effekte entsteht die typische Sägezahn-Form. Bei einer vereinfachten Darstellung des Precision-Recall-Diagramms werden Precision und Recall nur für relevante Ergebnisse eingetragen, sodass hier ein kontinuierlich abfallender Graph (Abbildung 2.4, gestrichelte Linie) entsteht.

37

Precision at n (P@n)

Eine weitere Methode, die sich für geordnete Ergebnislisten eignet, ist Pre-cision at n. Dabei wird die Precision für eine bestimmte Position n in der Ergebnisliste berechnet. Dieses Vorgehen basiert auf der Annahme, das ein Nutzer lediglich die ersten n Dokumente einer Ergebnisliste betrachtet und nur dort relevante Dokumente berücksichtigt werden.

P@n =1

n

n∑

i=1

rel(i)

mit rel(i)=1, wenn das i-te Dokument relevant ist, sonst rel(i)=0

Gängige Werte für n sind:

n=1 Wenn das erste Ergebnis relevant ist, dann ist die P@1=1, sonst P@1=0. Diese Variante entspricht z.B. der Funktion „Auf gut Glück!“ bei Google und ist vor allem beim Question-Answering geeignet.

n=10 Dieser Wert orientiert sich an den Ergebnisseiten bekannter Internet-suchmaschinen, wie z.B. Google oder Bing. In ungünstigen Fällen, in denen es weniger als zehn relevante Dokumente für eine Suchanfra-ge gibt, eignet sich n=10 nicht, da hier kein optimales Ergebnis von P@10=1 erreicht werden kann.

n=|R| Hier entspricht n der Anzahl der bekannten, relevanten Dokumente, d.h. die maximale Precision von P@R=1 ist stets erreichbar.

Nach Buckley und Voorhees (2000) eignet sich Precision at n vor allem für Webretrieval, da hier die genaue Anzahl von relevanten Dokumenten unbekannt ist. Um aber eine belastbare Aussage über die bessere Eignung eines Systems gegenüber einem anderen System zu treffen, müssen weit

38

mehr Suchanfragen evaluiert werden, als bei der Verwendung der Average Precision als Vergleichsmetrik. Buchley (2000) vermutet hierbei, dass 100 Suchanfragen ausreichend sind.

Average Precision

Im Zusammenhang mit TREC (vgl. Kapitel 2.1.4.1) wurden weitere Metriken entwickelt, die für geordnete Ergebnislisten geeignet waren. Ausgangspunkt hierbei war vor allem die Average Precision (vgl. Harman 1995). Diese be-rechnet sich aus dem arithmetischen Mittel der Precision an den Fundstellen der relevanten Dokumente bezogen auf alle relevanten Dokumente. Nicht gefundene relevante Dokumente gehen mit einer Precision von 0 in die Be-rechnung ein.

AP =

∑n

i=1P@i · rel(i)

|R|

Die Average Precision ist nach Buckley et al. (2000) sehr gut geeignet, um verschiedene Retrieval Systeme (bzw. Ansätze) miteinander zu vergleichen. Bei einer Differenz von mindestens 5% zwischen zwei Systemen gibt er die Fehlerwahrscheinlichkeit mit etwa 2% an.

Mean Average Precision

Um statistisch aussagekräftige Resultate zu erhalten, werden bei Evaluati-onen im Allgemeinen mehrere Suchanfragen verwendet. Außerdem lassen sich mehrere Systeme effizienter vergleichen, wenn auf eine einzelne Metrik zurückgegriffen werden kann, die die Average Precision für alle einzelnen Suchanfragen kombiniert. Eine mögliche Umsetzung dessen ist die Mean

39

Average Precision, die wiederum das arithmetische Mittel der Average Preci-sion über alle Suchanfragen darstellt.

MAP =

1

|Q|

∑

q∈Q

APq

Q ist die Menge der Suchanfragenq ist eine einzelne Suchanfrage aus der Menge Q

Die Aussagekraft der Mean Average Precision hängt vor allem von der Anzahl und der Diversität der einzelnen Suchanfragen ab. Für einen belast-baren Vergleich von Information Retrieval Systemen empfehlen Buckley et al. (2000) hierbei ein Minimum von 50 Suchanfragen und die Verwendung mehrerer Testkollektionen. Die Bedeutung der Mean Average Precision wird ebenfalls durch die Auswertungen von Wilhelm-Stein und Eibl (2013) belegt, da sie im Rahmen der CLEF Kampagnen von 2000 bis 2012 die mit Abstand am häufigsten erwähnte – und im Zuge dessen mit hoher Wahrscheinlichkeit auch genutzte – Metrik ist.

Geometric Mean Average Precision

Eine andere Möglichkeit zur Bündelung der Ergebnisse aller Suchanfragen ist das geometrische Mittel, wie es für die Geometric Mean Average Preci-sion (GMAP) angewendet wird. Bei der Mean Average Precision kann eine schlechte Average Precision durch gute Ergebnisse kaschiert werden. Im Gegensatz dazu verleiht die Geometric Mean Average Precision Ergebnissen mit niedriger Average Precision eine höhere Wirkung auf den kumulierten Wert für ein Information Retrieval System.

GMAP = |Q|

√∏

q∈Q

APq

40

Robertson (2006) beschreibt den Unterschied zwischen Mean Average Precision und Geometric Mean Average Precision zusammenfassend als Fokussierung auf unterschiedliche Bereiche der Skala der Average Precision.

2.1.3.2 Binary Preference

Die Aussagekraft aller Metriken, die auf Precision und Recall basieren, hängt stark vom Umfang der Relevanzbewertungen ab. Angesichts der Tatsache, dass nur ein kleiner Teil der Dokumente tatsächlich bezüglich einer bestimm-ten Suchanfrage bewertet wird, kann die Annahme, dass alle nicht bewerte-ten Dokumente zugleich nicht relevant sind, trügerisch sein.

Buckley und Voorhees (2004) schlagen deshalb eine Metrik vor, die diesem Umstand Rechnung trägt und nur auf den vorliegenden Relevanzbewertungen beruht. Anhand von Experimenten mit den Korpora TREC-8, TREC-10 und TREC-12 zeigen Buckley et al. (2004), wie instabil sich die Metriken basie-rend auf Precision und Recall bei einer Reduktion der Relevanzbewertungen verhalten. Dies zeigt, wie wichtig hierbei eine möglichst umfassende Rele-vanzbewertung wäre, die sogar entsprechend dem Cranfield Paradigma vollständig sein sollte. Die von ihnen vorgeschlagene Metrik Binary Prefer-ence (bpref) verhält sich in diesem Zusammenhang robuster und zeigt eine geringere Variabilität.

Die Binary Preference berechnet sich aus der Anzahl aller relevanten Doku-mente R, den relevanten Dokumenten r und den nicht-relevanten Dokumen-ten n, wobei diese explizit als nicht-relevant bewertet sind:

bpref =1

R

∑

r

(1−

|n ranked higher than r|

R

)

(Buckley et al., 2004, S. 27)

41

Problematisch hierbei ist, dass die Anzahl der relevanten Dokumente im Nenner verwendet wird und bei einer niedrigen Anzahl den Zähler nicht hinreichend reguliert. Um einer daraus folgenden Verzerrung vorzubeugen, geben Buckley et al. (2004, S. 27) eine Anpassung der vorherigen Formel an, bei der von mindestens zehn relevanten Dokumenten ausgegangen wird:

bpref-10 =1

R

∑

r

(1−

|n ranked higher than r|

10 +R

)

(Buckley et al., 2004, S. 27)

2.1.3.3 Normalised Discounted Cumulative Gain

Die bisher vorgestellten Evaluationsmetriken setzen eine zweiwertige Rele-vanz vorraus. Die in Kapitel 2.1.2.3 vorgestellte vierwertige Relevanz nach Sormunen (2002) erlaubt jedoch eine genauere Einteilung. Järvelin und Kekäläinen (2000) zeigen, das Cumulative Gain bzw. Discounted Cumulative Gain diese Problematik adressieren. Beide Metriken können mit mehrstufi-gen Relevanzbewertungen verwendet werden, z.B. mit Werten von 0 bis 3, wobei 3 einer hohen und 0 keiner Relevanz entspricht (vgl. Sormunen, 2002).

CG[i] =

{G[1], if i = 1

CG[i− 1] + G[i], otherwise

DCG[i] =

{G[1], if i < b

DCG[i− 1] + G[i]logb i

, if i ≥ b

(Järvelin et al., 2000)

42

Cumulative Gain und Discounted Cumulative Gain haben dabei nach Järvelin und Kekäläinen (2002) folgende Stärken: Das Ranking und der Grad der Relevanz beeinflussen das Ergebnis. Weiterhin ist die Gesamtanzahl von re-levanten Dokumenten für eine Suchanfrage nicht zur Berechnung notwendig. Durch eine Veränderung der Basis b des Logarithmus kann der Discountfak-tor an verschiedene Nutzermodelle angepasst werden.

Ein Vergleich zwischen verschiedenen Suchanfragen ist jedoch nicht mög-lich, da für jede Suchanfrage unterschiedliche Maximalwerte erreicht werden können. Dieser theoretische Maximalwert wird für die Berechnung des Nor-malised Discounted Cumulative Gains (Järvelin & Kekäläinen, 2002, S. 426-427) herangezogen, setzt jedoch für seine Korrektheit wieder eine möglichst vollständige Relevanzbewertung vorraus. Die Relevanzbewertungen werden dabei absteigend nach ihrer Relevanz sortiert und anschließend wird der Normalisierungsfaktor iDCG auf der Basis der sortierten Relevanzbewertun-gen analog zu einer normalen Ergebnisliste berechnet. Damit liegt der Werte-bereich des Normalized Discounted Cumulative Gain zwischen 0 und 1, d.h. er stellt nicht nur eine Vergleichbarkeit zwischen einzelnen Suchanfragen her, sondern ebenfalls zwischen ganzen Systemen.

nDCG =DCG

iDCG

(vgl. Järvelin et al., 2002)

2.1.3.4 Weitere Metriken

Yet Another Average Precision

Die von Robertson (2012) definierte Yet Another Average Precision soll diverse Schwächen der Average Precision beheben. So haben z.B. die gelegentlich auftretenden Extremwerte 1 und 0 bei der Average Precision

43

einen schwerwiegenden Einfluss auf die Mean Average Precision. Außerdem werden durch die Durchschnittsbildung bei der Mean Average Precision be-sonders schwere Suchanfragen verborgen.

yaAP = logit

(1 +

∑n

i=1P@i · rel(i)

2 +R

)

mit rel(i)=1, wenn das i-te Dokument relevant ist, sonst rel(i)=0 und

logit(x) = logx

1− x

(vgl. Robertson, 2012, S. 162)

Rank-Biased Precision

Bei der Entwicklung der Rank-Biased Precision durch Moffat und Zobel (2008) spielt die Beharrlichkeit des Nutzers eine zentrale Rolle. Sie gehen da-bei von einem Modell aus, nach dem ein Nutzer sich das erste Ergebnis aus der Ergebnisliste anschaut und mit einer Wahrscheinlichkeit p entscheidet, das nächste Ergebnis zu betrachten. Diese Entscheidung wird für jedes wei-tere Ergebnis getroffen, sodass die Wahrscheinlichkeit für das Betrachten des i-ten Ergebnisses pi-1 entspricht. Eine Wahrscheinlichkeit von p=0 steht für einen Nutzer, der lediglich das erste Ergebnis betrachtet. Umgekehrt steht eine Wahrscheinlichkeit von p nahe 1 für einen sehr ausdauernden Nutzer, der sich sehr viele Ergebnisse anschaut.

RBP = (1− p) ·n∑

i=1

rel(i) · pi−1

p ist die Wahrscheinlichkeit, dass der Nutzer das nächste Ergebnis betrachtet (vgl. Moffat et al., 2008, S. 2:14)

44

2.1.4 Evaluationskampagnen

Die Cranfield-Experimente von Cleverdon, Mills und Keen (1966) waren gewissermaßen die Vorläufer moderner Evaluationskampagnen für das Information Retrieval. Sie dienten vor allem der Erstellung von einheitlichen Korpora, Suchanfragen und dazugehörigen Relevanzbewertungen, die für wiederholbare Experimente und einen nachfolgenden wissenschaftlichen Diskurs unabdingbar sind.

Evaluationskampagnen verfolgen hierbei meist mehrere Ziele:

– Erstellung von Testkollektionen (für bestimmte Anwendungsfälle)Meist liegen ein oder mehrere Forschungsfragen zugrunde, die anhand der Experimente beantwortet oder weiterentwickelt werden sollen.

– Entwicklung und Erprobung neuer Retrieval-MetrikenDa Retrieval-Metriken nicht unumstritten sind und darüber hinaus manche Metriken für spezielle Testkollektionen bzw. Anwendungs-fälle nicht geeignet sind, werden stets neue Metriken entwickelt und überprüft.

– Diskussion der Ergebnisse und Austausch von ErfahrungenDurch eine Verknüpfung mit einer Konferenz, die nach jedem Evalua-tionsdurchlauf stattfindet, werden Diskussionen der Ergebnisse gefördert und wissenschaftliche Veröffentlichungen konzentriert publiziert.

2.1.4.1 TREC

Die größte und bekannteste Evaluationskampagne ist die Text Retrieval Conference (TREC). Sie wird jährlich seit 1992 vom National Institute of

45

Standards and Technology (NIST) organisiert und durchgeführt. Das selbst-erklärte Ziel der Konferenz ist laut Harman (1993): „Forschungsgruppen zusammenzubringen, um deren Arbeit an einer neuen großen Testsammlung zu diskutieren.“

Aus den anfangs zwei Aufgabenstellungen „Adhoc“ und „Routing“ (vgl. Harman 1995) entwickelte sich eine Initiative mit acht Tracks im Jahr 2015. Jeder Track widmet sich einem speziellen Forschungsgebiet im Bereich Information Retrieval und teilt sich ggf. nochmals in einzelne Tasks auf. Von 1995 bis 2015 entstanden insgesamt 28 verschiedene Tracks, die teilweise über mehrere Jahre hinweg durchgeführt wurden4.

Einige dieser Tracks wurden später sogar in eigenständige Kampagnen bzw. Konferenzen ausgegliedert. Der Cross-Language Track fand 2002 das letzte Mal im Rahmen von TREC statt. Nachfolgend wurde das Thema „Cross-Language Retrieval“ vor allem bei CLEF (damals Cross-Language Evaluation Forum) und bei NTCIR (NII Test Collection for IR Systems) bear-beitet. Auch der „Video Track“ wurde 2003 in die eigenständige Evaluations-kampagne TRECVID5 ausgelagert.

2.1.4.2 CLEF

Das Cross-Language Evaluation Forum (CLEF) wird seit 2000 als europäi-scher Ableger des Cross-Language Tracks von TREC durchgeführt. Es findet ebenfalls jährlich statt und nimmt vor allem europäische Sprachen in den Fokus. Ab 2010 wurde der Modus verändert und die Evaluationen und de-ren Diskussion werden in Verbindung mit einer eigenständigen Konferenz durchgeführt.

4 http://trec.nist.gov/tracks.html (5. Oktober 2015)5 http://www.itl.nist.gov/iaui/894.02/projects/trecvid/ (6. Oktober 2015)

46

Das Ziel des Cross-Language Evaluation Forums, das auch heute noch ver-folgt wird, war laut Peters (2000):

[…] to develop and maintain an infrastructure for the testing and evaluation of information retrieval systems operating on European languages, in both monolingual and cross-language contexts, and to create test-suites of reusable data that can be employed by sys-tem developers for benchmarking purposes.

Im Jahr 2013 haben Wilhelm-Stein und Eibl rückblickend alle Working Notes, die im Rahmen von CLEF von 2000 bis 2012 erschienen sind, auf die Häufig-keit der Verwendung verschiedener Schlagwörter untersucht. Es sollte vor allem die Veränderung der Häufigkeit der verwendeten Wörter über die Jahre hinweg erfasst und untersucht werden, um letztendlich auf die Anwendung verschiedener Techniken bei den durchgeführten Experimenten zu schließen.

Die untersuchten Schlagwörter wurden dabei in vier Kategorien eingeteilt:

– Evaluationsmaße– Information Retrieval Systeme– Retrievalmodelle– Allgemeine Konzepte und Techniken

Bezüglich der Evaluationsmaße ist die Mean Average Precision die vorherr-schende Metrik. Sie wird bei weitem am häufigsten erwähnt und demzufolge wahrscheinlich auch am häufigsten verwendet. Alle anderen untersuchten Metriken schwanken stark in ihrer Verwendung. Ein Beispiel ist hier die Geo-metric Mean Average Precision (GMAP), die vor allem im Robust Track in den Jahren 2006 bis 2009 verwendet wurde und sonst gar nicht bzw. sehr selten vertreten ist.

Anhand der Schlagwörter für Information Retrieval Systeme lässt sich sehr gut deren Entwicklung ablesen. So betritt 2002 Lucene erstmals die Bühne

47

und gewinnt vor allem nach der Überführung in ein Apache Top-Level Projekt in den Jahren 2005 und 2006 an Bedeutung. Im Jahr 2006 wurde Apache Lucene bei etwa 30% der durchgeführten Experimenten eingesetzt. Auch Terrier wird nach dessen Veröffentlichung unter einer Open-Source-Lizenz immer wieder verwendet. Am bemerkenswertesten erscheint jedoch die kontinuierliche Erwähnung von SMART, dessen Entwicklung 1961 an der Havard University begann. Jedoch zeigte eine nähere Betrachtung der Fundstellen, dass nicht ausschließlich die Software selbst gemeint war, son-dern auch deren Teile, die in anderen Lösungen weiter existierten, wie z.B. Stoppwortlisten.

Bei den Retrievalmodellen zählen TF/IDF, BM25 und das Vektorraummodell zu den Spitzenreitern. Auch das Latent Semantic Indexing ist nahezu jedes Jahr vertreten, jedoch mit einer geringeren Häufigkeit. Das Auftreten und die Verteilung von Divergence from Randomness lässt einen Zusammenhang mit der Verwendung von Terrier vermuten, da es eines der wenigen Systeme ist, die diese Modelle bereits seit geraumer Zeit unterstützen.

Im ersten Jahr wurden zwei Tracks6 durchgeführt: „Mono-, Bi- and Multilin-gual Document Retrieval (Ad-hoc)“ und „Mono- and Cross-Language IR for Scientific Collections (Domain-Specific)“. In den folgenden Jahren wurde eine Vielzahl verschiedener Tracks, später in Labs umbenannt, entwickelt und durchgeführt. Im aktuellen Jahr (2015) wurden acht Labs mit insgesamt 21 Tasks durchgeführt.7

2.1.4.3 Andere Kampagnen

Das 1999 ins Leben gerufene NTCIR (NII Testbed and Community for Infor-mation Access Research) Projekt ist die asiatische Variante von TREC und

6 http://www.clef-initiative.eu/edition/clef2000/agenda (9. Oktober 2015)7 http://clef2015.clef-initiative.eu/CLEF2015/labs.php (7. November 2015)

48

läuft jeweils in einem Zeitraum von 18 Monaten. Am Ende dieses Zyklus steht eine Konferenz in Tokyo, wo alle Teilnehmer ihre Ergebnisse präsen-tieren und über neue Herausforderungen diskutieren. Der Schwerpunkt von NTCIR liegt auf asiatischen Sprachen.

MediaEval ist 2010 aus dem VideoCLEF Track von CLEF hervorgegangen und befasst sich mit der Evaluation von Versuchen aus dem Bereich Mul-timedia Retrieval. Soziale Gesichtspunkte spielen ebenso eine große Rolle. Die folgende Auswahl von Tasks zeigt den breit aufgestellten Charakter dieser Kampagne:

– Emotion in Music– Affective Impact of Movies– Synchronization of Multi-User Event Media– QUESST: Query by Example Search on Speech Task

2.1.4.4 Fazit

Aufgrund zahlreicher Evaluationskampagnen existiert nunmehr ein enormer Fundus von Testkollektionen für die verschiedensten Anwendungsfälle. Diese Entwicklung ist noch lange nicht am Ende und wird kontinuierlich fortgeführt. All diese existierenden und zukünftigen Testkollektionen sind unentbehrlich für die Entwicklung und Evaluation neuer, besserer Retrievalkomponenten.

2.2 E-Learning

Das Experimentieren in einer künstlichen Umgebung mithilfe eines Com-puters oder eines vergleichbaren mobilen Endgeräts wird im Kontext des E-Learnings als Simulation bezeichnet. In diesem Kapitel werden einige Grundlagen zum E-Learning, zur Motivation und zu Spielemechaniken, die motivierend wirken, beschrieben.

49

Rey (2009, S. 15) fasst unter dem Begriff E-Learning jedes „Lehren und Ler-nen mittels verschiedener elektronischer Medien“ zusammen. Darüber hinaus gibt es viele weitere Definitionen von E-Learning und ebenso viele weitere Begriffe, die synonym dafür stehen. Im E-Learning geht es vor allem um die multimediale, multicodale, multimodale und interaktive Gestaltung und Umsetzung von Lernmaterialien. Die Multimedialität bezieht sich hierbei auf verschiedene Objekte bzw. Geräte, die für die Speicherung und Übermittlung von Informationen eingesetzt werden, z.B. Bücher, Radio und Computer, aber auch DVDs und USB-Sticks. Die Codierung beschreibt die Art der Informati-onen, z.B. Text, Bild, Animation und Simulation. Mit Multimodalität wird auf die Sinne des Menschen Bezug genommen, mit denen er die Informationen aufnimmt. (Rey, 2009, S. 16-21)

2.2.1 Interaktivität

Die Interaktivität ist innerhalb dieser Arbeit von besonderer Bedeutung, da das entwickelte System als Simulation im Sinne des E-Learning fungiert, auch wenn mit Daten aus der Praxis authentische Experimente durchgeführt werden. Schulmeister (2002) stellt eine sechsstufige Taxonomie auf, die für ebensolche Simulationen gilt. Mit zunehmender Stufe nehmen dabei auch die Möglichkeiten zur Interaktion bzw. zur Beeinflussung des Ablaufs und des Ergebnisses zu. Die ersten Stufen folgen einer behavioristischen Auffas-sung, wogegen sich die höheren Stufen mehr und mehr auf ein konstruktivis-tisches Lernen beziehen.

Stufe I: Automatischen Programmablauf ausführenDer Programmablauf läuft nach dem Start automatisch ab und der Lernende hat keinen weiteren Einfluss auf den Ablauf. Er ist nur ein Zuschauer. (vgl. Schulmeister, 2002)

50

Stufe II: Mehrfache optionale Programmabläufe veranlassenDer Lernende kann zwischen verschiedenen Programmabläufen auswählen und diese wiederholt wiedergeben. Er hat darüber hinaus keine Kontrolle über den tatsächlichen Inhalt des Programmablaufs. (vgl. Schulmeister, 2002)

Stufe III: Variation der Darstellung durch Eingriff in ein ProgrammDie Darstellung und/oder die Darstellungsform des Inhaltes kann vom Nut-zer verändert werden, z.B. ein Wechsel zwischen einer tabellarischen und einer grafischen Darstellung. Nach wie vor hat er aber keine Kontrolle über den Inhalt. (vgl. Schulmeister, 2002)

Stufe IV: Variation durch Parameter- oder DatenvariationDurch die Veränderung von Parametern oder die Verwendung von anderen Daten kann der Inhalt des Programms beeinflusst werden. Das Ergebnis ist also abhängig von den Eingaben des Lernenden. (vgl. Schulmeister, 2002)

Stufe V: Objekte konstruieren und Prozesse generierenDer Lernende kann den Inhalt des Programms selbst modellieren, indem er z.B. eigene Prozesse zusammenstellt. Nach der Durchführung wird das Ergebnis angezeigt, das den Lernenden zur aktiven Konstruktion von Wissen befähigt. (vgl. Schulmeister, 2002)

Stufe VI: Prozesse und Programme mit RückmeldungZusätzlich zu den Eigenschaften aus Stufe V wird in Stufe VI der Lernen-de bei der Konstruktion von Wissen mit „intelligenten Rückmeldungen“ (Schulmeister, 2002, S. 198) unterstützt. Das schließt z.B. eine Bewertung des Ergebnisses ein, sodass der Lernende in die Lage versetzt wird, gute von schlechten Ergebnissen zu trennen und sein Modell weiter zu entwickeln. (vgl. Schulmeister, 2002)

51

2.2.2 Gestaltung

Aus der Cognitive Load Theory nach Sweller (1988) ergeben sich bestimmte Gestaltungsempfehlungen, die für ein positives Lernumfeld sorgen. De Jong und Van Joolingen (1998) entwickelten auf der Basis verschiedener Studien einen Katalog von Gestaltungshinweisen, der speziell auf Simulationen aus-gerichtet ist.

Direkter Zugang zu Fachwissen (Direct Access to Domain Knowledge)Für die effektive Nutzung einer Simulation wird oft ein gewisses Vorwissen bei den Lernenden vorausgesetzt. Verschiedene Techniken können diese Anforderung vermindern. Durch die Verwendung von verlinkten Medien kann beispielsweise der Zugriff auf Fachwissen erleichtert werden. Der Zeitpunkt für die Präsentation von Informationen hat ebenfalls einen Einfluss auf den Lernerfolg. Informationen, die während der Nutzung einer Simulation präsen-tiert wurden, waren wirkungsvoller als jene, die davor angezeigt wurden. (vgl. de Jong et al., 1998, S. 187)

Unterstützung bei der Hypothesenentwicklung (Support for Hypothesis Generation)Die Entwicklung von validen Hypothesen ist eines der Kernprobleme bei der Anwendung von Simulationen für die Lehre. Es fällt Lernenden nicht nur schwer, eigene korrekte Hypothesen zu formulieren, sondern auch wi-dersprüchliche Ergebnisse richtig zu interpretieren. Mithilfe eines digitalen Notizblocks können vom Programm die Bestandteile einer Hypothese abge-fragt und später für die Auswertung der Ergebnisse herangezogen werden. Ein anderes Vorgehen ist die Formulierung von Vorhersagen durch den Ler-nenden, bevor ein Experiment durchgeführt wird. Nach dessen Durchführung kann dann die Vorhersage mit dem tatsächlichen Ergebnissen verglichen werden. Schließlich kann die Simulation selbst die Hypothesen formulieren, die dann durch den Lernenden zu überprüfen sind. (vgl. de Jong et al., 1998, S. 188)

52

Unterstützung beim Experimententwurf (Support for the Design of Experiments)Im Vorfeld an die Lernenden gegebene Hinweise führten zwar zu einem besseren Experimentierverhalten, aber nicht zu einem besseren Lernerfolg. Ein adaptives Verfahren, das Hinweise erst nach einem Fehlverhalten des Lernenden anzeigte, führte zu besserem Fachwissen, hatte aber nur einen geringeren Effekt auf die Entwicklung von Praxiswissen oder erschwerte diese sogar. (vgl. de Jong et al., 1998, S. 188)

Unterstützung beim Treffen von Vorhersagen (Support for Making Predictions)Hierbei sollen die Lernenden bei der Vorhersage von konkreten Werten unterstützt werden, die durch die Simulation getestet werden können. Das Beispiel von de Jong et al. (1998, S. 198) beschreibt ein Diagramm, in das die Lernenden zuerst die Kurve einzeichnen sollten. Nach der Ausführung der Simulation wurden im selben Diagramm das Ergebnis der Simulation und die Vorhersage der Lernenden angezeigt. (vgl. de Jong et al., 1998, S. 189)

Unterstützung bei der Regulierung des Lernprozesses (Support for Regula-tive Learning Processes)Durch eine Regulierung des Lernprozesses wird dafür gesorgt, das der Lernende nicht über- oder unterfordert wird. Hierfür sind eine Planung, d.h. das Setzen von Zielen, und eine Überwachung für die Bewertung des Lern-fortschritts notwendig. Die folgenden vier Punkte tragen zur Regulierung des Lernprozesses bei:

– Weiterentwickelndes Modell (Model progression)Zu Beginn wird dem Lernenden eine einfache Simulation präsentiert, die z.B. wenige Parameter bereitstellt. Mit zunehmenden Lernfort-schritt nimmt die Komplexität der Simulation zu. Am Beispiel der Parameter bedeutet dies, dass entweder die Anzahl der Parameter oder deren Einstellungsoptionen zunehmen. (vgl. de Jong et al., 1998, S. 189)

53

– Unterstützung bei der Planung von Experimenten (Planning support)Die Aufmerksamkeit der Lernenden kann z.B. durch Fragestellungen gezielt auf Aspekte der Simulation gelenkt werden. Die Verwendung von Assignments hatte bei Studien mit unterschiedlichen Simu-lationen eine positive Wirkung auf die Entwicklung von „intuitive knowledge“. (vgl. de Jong et al., 1998, S. 190)

– Unterstützung zur Kontrolle des eigenen Fortschritts (Monitoring support)Durchgeführte Versuche werden innerhalb der Simulation gesichert, damit diese später von den Lernenden erneut aufgegriffen werden können. Bestimmte Filterfunktionen nach Parametern und Ergeb-nissen unterstützen das Wiederfinden. Ziel ist vor allem eine Bewer-tung des eigenen Fortschritts durch den Vergleich mit vorherigen Versuchen. (vgl. de Jong et al., 1998, S. 191)

– Strukturierung des Entdeckungsprozesses (Structuring the discov-ery process)Durch eine ausgeprägte Strukturierung können Lernende effektiver durch den Entdeckungsprozess geführt werden und so signifikant bessere Ergebnisse erzielen. Dies kann z.B. durch eine Einteilung des Lehrmaterials in unterschiedliche Stufen geschehen. Bevor die nächste Stufe und die darin enthaltenen Materialien genutzt werden können, muss die aktuelle Stufe gemeistert werden. (vgl. de Jong et al., 1998, S. 191)

2.2.3 Motivation

Die Motivation der Lernenden ist laut Martens, Gulikers und Bastiaens (2004) ein entscheidender Faktor für die erfolgreiche Vermittlung von Lehrin-halten. Ryan und Deci (2000) unterscheiden dabei zwischen intrisischer

54

und extrinsischer Motivation. Eine extrinsische Motivation wirkt außerhalb einer Tätigkeit, deren Durchführung sie fördert. Bei der intrinsischen Motiva-tion liegt der Antrieb in der Durchführung der Tätigkeit selbst. Obwohl die intrinsische Motivation eine sehr wichtige Art der Motivation ist, so sind viele Tätigkeiten vor allem im Bereich des E-Learnings nicht zwingend intrinsisch motivierend.

Folgende Faktoren wirken Blumenfeld, Kempler und Krajcik (2005) zufolge auf die Motivation und letztendlich auf das „Cognitive Engagement“ der Lernenden ein und stellen deshalb spezifische Herausforderungen für die Lehrenden und die Lernumgebung dar:

– Nutzen kann immanent sein, d.h. es ist für den Lernenden interes-sant, oder instrumental sein, bezüglich des Nutzens für die weitere Laufbahn. Ebenso kann eine erfolgreiche Bearbeitung als persönli-che Errungenschaft wahrgenommen werden.

– Kompetenz beschreibt die Wahrnehmung der eigenen Fähigkeit des Lernenden, das Lernziel zu erreichen oder das Projekt erfolgreich ab-zuschließen. Die Vermittlung von wichtigen Grundlagen oder konst-ruktives Feedback fördern das Bewusstsein der Selbstwirksamkeit.

– Verbundenheit folgt aus positiven Interaktionen (Anerkennung und Fürsorge) mit Lehrern und anderen Lernenden. Gemeinsame Projek-te fördern zusätzlich das Zusammengehörigkeitsgefühl.

– Autonomie spiegelt sich in der Möglichkeit wider, dass Lernende ei-gene Entscheidungen treffen können und Einfluss auf ihre Aufgaben ausüben.

Laut Blumenfeld et al. (2005) ist es ebenso wichtig demotivierende Faktoren zu vermeiden, wie motivierende Faktoren zu verstärken. Lernende sollten nicht durch eine zu hohe Komplexität oder technische Probleme bei der

55

Bearbeitung der Aufgaben demotiviert werden. Aufgrund dessen ist es für Lehrende wichtig, mögliche Probleme zu antizipieren, die für Lernende in Verbindung mit der Lernumgebung auftreten könnten, um sie letztendlich zu vermeiden.

2.2.4 Spielemechaniken

Spielemechaniken und Belohnungssysteme dienen der extrinsischen Moti-vation. Zichermann und Cunningham (2011) stellen verschiedene Spieleme-chaniken vor, von denen in den folgenden Unterkapiteln einige ausgewählte Mechaniken wiedergebeben werden. Sie basieren auf dem Konzept der Gamification, die von Zichermann et al. kurz und knapp so definiert wird:

The process of game-thinking and game mechanics to engage users and solve problems. (Zichermann et al., 2011, S. xiv)

Deterding, Dixon, Khaled und Nacke (2011) stellen eine enger gefasste De-finition auf, indem sie echte Spiele und ein echtes Spielen durch den Nutzer ausschließen:

– the use (rather than the extension) of– design (rather than game-based technolo-

gy or other game-related practices)– elements (rather than full-fledged games)– characteristic for games (rather than play or playfulness)– in non-game contexts (regardless of specific usage inten-

tions, contexts, or media of implementation). (S. 13)

Gamification findet also in einem Nicht-Spiele-Kontext statt und setzt die Nutzung von Spieledesign, -elementen und/oder -charakteristiken voraus. Problematisch hierbei ist, wenn diese Ansätze auf ein vorhandenes System aufgesetzt werden und deshalb nicht die notwendige Verbindung zum Inhalt

56

besteht bzw. geschaffen wird. Vor allem bei der Vermittlung von Lehrinhalten sollten die Motivatoren mit diesen verbunden sein, damit sie nicht selbst im Mittelpunkt stehen und die Lehrinhalte in den Hintergrund treten.

2.2.3.1 Punkte

Punkte (engl. Points) sind ein zentrales Element vieler Spiele. Sie müssen nicht zwingend für den Spieler sichbar sein, jedoch erfordern gamifizierte Systeme eine interne Erfassung und Verfolgung des Fortschritts der Benut-zer. Dies geschieht meist in Form von Punkten. Verschiedene Punktesys-teme eignen sich für unterschiedliche Anwendungen. Sie können einzeln angewendet werden oder in Kombinationen. Diese Punktesysteme und die damit verbundenen Punkte müssen nicht immer direkt dem Spieler präsen-tiert werden, manche Anwendungen arbeiten im Hintergrund mit Punkten und repräsentieren diese auf eine abstraktere Art und Weise dem Spieler. (vgl. Zichermann et al., 2011, S. 36ff.)

Folgende Punktesysteme werden von Zichermann et al. (2011, S. 36ff.) unterschieden:

– Erfahrungspunkt (Experience points)Erfahrungspunkte gehören zur wichtigsten Art von Punkten. Sie werden durch Aktionen innerhalb des Spiels bzw. der Anwendung erworben, können nicht ausgegeben werden und haben keine obere Grenze.

– Einlösbare Punkte (Redeemable points)Einlösbare Punkte sind vergleichbar mit Bonusmeilen, wie sie von Fluggesellschaften angeboten werden. Sie werden durch bestimmte Aktionen innerhalb des Spiels bzw. der Anwendung er-worben und können für verschiedene Gegenstände oder Fähigkeiten

57

eingetauscht werden. Diese Punkte können als Basis für eine Öko-nomie innerhalb der Anwendung dienen.

– Fähigkeitspunkte (Skill points)Fähigkeitspunkte sind ebenfalls mit bestimmten Aktionen im Spiel verbunden und stehen meist in einem Zusammenhang mit Erfahrungspunkten oder einlösbaren Punkten. Durch die gezielte Zu-weisung von Fähigkeitspunkten zu bestimmten Aktionen kann der Spieler motiviert werden, diese Aktionen bevorzugt auszuführen.

– Karmapunkte (Karma points)Karmapunkte werden ebenfalls für bestimmte Aktionen vergeben, können jedoch nicht eingelöst oder für irgendeinen anderen Vorteil verwendet werden. Sie dienen in erster Linie zur Selbsteinschätzung der eigenen Aktionen und können zwischen mehreren Spielern zu deren Vergleich herangezogen werden.

– Reputationspunkte (Reputation points)Reputationspunkte spielen bei Interaktionen zwischen Spielern eine Rolle. Sie sind vergleichbar mit den Verkäufer- und Käuferbewer-tungen bei eBay, die stellvertretend für die Vertrauenswürdigkeit des anderen stehen. Die Umsetzung von Reputationspunkten ist besonders schwierig, da Spieler versuchen werden, das System zu überlisten.

2.2.3.2 Leaderboards

Leaderboards (deutsch: Ranglisten) dienen dem Vergleich von Spielern anhand von Punkten. Sie bestehen aus sortierten, nummerierten Listen von Spielernamen oder Pseudonymen und den jeweiligen Punkteständen. Die Auswirkung von Leaderboards auf die Spieler soll vor allem motivierend sein, jedoch können zu hohe Highscores auch einen gegenteiligen Effekt erzielen

58

und Spieler entmutigen, das Spiel längerfristig zu spielen. (vgl. Zichermann et al., 2011, S. 50ff.)

2.2.3.3 Achievements

Achievements und Badges (detusch: Erfolg und Abzeichen) sprechen Spieler auf unterschiedlichen Ebenen an. Sie dienen als Statussymbol, aktivieren den Sammeltrieb eines Spielers oder werden aufgrund ihres stilvollen Aus-sehens erspielt. Um ein Achievement zu erhalten, muss ein bestimmtes Ziel erreicht werden. Dabei gibt es Achievements, für die dieses Ziel bekannt ist, und andere Achievements, die dem Spieler mehr oder weniger überraschend verliehen werden. Achievements können auch einen Rang besitzen, mit dem unterschiedliche Zielvorgaben auf einem bestimmten Gebiet verbunden sind, wie z.B. Gold-, Silber- und Bronze-Medaillen bei vielen Sportarten. (vgl. Zichermann et al., 2011, S. 55ff.)

2.2.3.4 Assignments

Assignments (deutsch: Aufträge oder auch Herausforderungen) und Quests sind Aufgaben, die ein Spieler erfüllen muss, um das Spielgeschehen voran-zutreiben. Es gibt aber ebenso Assignments, die zusätzlich zur eigentlichen Spielhandlung gemeistert werden können. Sie geben Einsteigern ein Ziel, das sie verfolgen können, oder führen in die Spielwelt und ihre Mechaniken ein, damit sich die Spieler zurechtfinden. Achievements können als vorzeigbare Erfolge bei der Abarbeitung von Assignments dienen und fördern daneben soziale Aspekte, wie z.B. den Vergleich zwischen Spielern. Assignments soll-ten sich am Erfahrungsstand des Spielers orientieren und nicht zu schwer, aber auch nicht zu leicht sein. Es kann ebenfalls nützlich sein, wenn der Spieler zwischen verschiedenen Assignments entsprechend seinem Können und seinen Vorlieben auswählen kann. (vgl. Zichermann et al., 2011, S. 64ff.)

59

3 Stand der Technik

Dieses Kapitel widmet sich zuerst den Information Retrieval Systemen, die sowohl in der Forschung, als auch in Unternehmen eingesetzt werden. Im Anschluss werden Erfahrungsberichte über den Einsatz dieser Systeme in der Lehre wiedergegeben und besprochen. Abschließend werden diverse Lösungen für die Lehre beleuchtet und analysiert.

3.1 Information Retrieval Systeme

In diesem Kapitel werden Information Retrieval Systeme und Bibliotheken betrachtet, d.h. Software, die nicht mit dem primären Ziel entwickelt wurde, in der Lehre eingesetzt zu werden. Bei diesen Systemen stand entweder die Forschung im Vordergrund oder der Einsatz innerhalb eines Unternehmens und in anderen Softwareprodukten.

3.1.1 SMART

Das SMART (System for the Mechanical Analysis and Retrieval of Text) Auto-matic Document Retrieval System ist wohl das älteste, am längsten genutzte und weiterentwickelte Retrieval System. Es wurde ab 1961 an der Harvard University entwickelt und später an der Cornell University fortgeführt (Salton, 1991). Viele der im Rahmen von SMART entwickelten Techniken werden noch in aktuellen System angewendet. Selbst im Jahr 2012 wurde es noch in den CLEF Working Notes referenziert (vgl. Wilhelm-Stein & Eibl, 2013).

Saltons (1991) ursprüngliches Ziel für die Entwicklung von SMART war eine vollständig automatische Analyse und Verarbeitung von Dokumenten und Suchanfragen. Es sollten vor allem die Schwächen existierender Systeme

60

durch statistische und syntaktische Analysen überwunden werden. SMART sollte nach Salton und Lesk (1965) folgende Kriterien erfüllen:

– Die Informationsanalyse ist dazu fähig, für die meisten Suchanfra-gen relevante Dokumente zu liefern.

– Nutzer können das System an ihre Bedürfnisse anpassen, indem sie aus unterschiedlichen Verfahren auswählen und deren Reihenfolge festlegen können.

– Das System dient als Plattform, um neue Verfahren zu evaluieren. Zwischenschritte und Ergebnisse sind überprüfbar und vergleichbar.

Durch zahlreiche Experimente konnten verschiedene Thesen bestätigt oder widerlegt werden. So erwies sich die Nutzung von Thesauri zur Erweiterung von Suchanfragen mit allgemeineren oder spezielleren Begriffen als unvor-teilhaft. Andere im Rahmen von SMART entwickelte Verfahren, wie z.B. das Relevance Feedback, waren außerordentlich erfolgreich und fanden bald darauf Anwendung in vielen anderen Information Retrieval Systemen. (vgl. Salton, 1991)

3.1.2 Apache Lucene

Apache Lucene ist ein Open-Source-Framework, mit dessen Hilfe ein Index erstellt und effizient durchsucht werden kann. Ursprünglich als Bibliothek für Java gestartet, ist Apache Lucene inzwischen für viele weitere Programmier-sprachen und Entwicklungsumgebungen verfügbar, darunter C/C++, .NET, Python und PHP.8 Es kommt in einer Vielzahl von Anwendungen und unzäh-ligen Webangeboten zum Einsatz. Zahlreiche international aufgestellte Un-ternehmen, darunter auch namhafte Größen wie Twitter, LinkedIn, IBM und

8 siehe http://wiki.apache.org/lucene-java/LuceneImplementations (27. Mai 2015)

61

Apple, setzen es in einer breiten Vielfalt ein.9 Auch im wissenschaftlichen Umfeld kommt Lucene häufig zur Anwendung. Im Rahmen der CLEF Evalua-tions Kampagnen ist Lucene seit 2005 eines der am häufigsten eingesetzten Retrieval Frameworks. (vgl. Wilhelm-Stein & Eibl, 2013)

Als Softwarebibliothek kann Apache Lucene ausschließlich Text verarbeiten. Um andere Formate, wie HTML, XML, Microsoft Word-Dokumente oder PDF-Dateien, zu indizieren, müssen diese erst durch die Anwendung in Text umgewandelt werden. Dieser Text wird durch einen Tokenizer in einen TokenStream, also eine Folge von Tokens, umgewandelt. In Apache Lucene besteht ein Token aus einer Menge von Attributen. Das elementare Attribut ist der Textbaustein, der zur Erzeugung des Tokens geführt hat. Weitere Attri-bute sind die Position des Textbausteins im gesamten Text, die Wortart oder die Gewichtung des Tokens.

Ein TokenStream kann im weiteren Verlauf durch Filter weiterverarbeitet werden. Apache Lucene umfasst bereits eine Vielzahl an Filtern für verschie-dene Bereiche. So gibt es verschiedene Filter für das Stemming, die Entfer-nung von Stoppwörtern, die Erweiterung durch Synonyme und die Textnor-malisierung, d.h. die Entfernung von Akzenten oder die Kleinschreibung aller Wörter. Auch eigene Filter können hier ohne großen Aufwand implementiert und angewendet werden. Jeder Filter kann alle einem Token zugeordneten Attribute für seine Verarbeitung nutzen oder neue Attribute zu einem Token hinzufügen.

Aus einem Tokenizer und verschiedenen Filtern wird dann ein Analyzer kon-struiert, der in Apache Lucene für die komplette Vorverarbeitung zuständig ist. Für die Vorverarbeitung von Dokumenten und Suchanfragen können auch verschiedene Analyzer verwendet werden. So ist es z.B. zielführend, wenn Synonyme nur bei der Verarbeitung der Suchanfrage oder der Dokumente angewendet werden und nicht bei beiden Schritten gleichzeitig. Nach der

9 siehe http://wiki.apache.org/lucene-java/PoweredBy (27. Mai 2015)

62

Vorverarbeitung werden alle Teile eines Dokumentes in Feldern organisiert. Jedes Feld kann bestimmte Eigenschaften besitzen, die definieren, ob und wie der Inhalt des Feldes im Index gespeichert wird.

Apache Solr ist die Erweiterung von Apache Lucene zu einer eigenständigen Enterprise-Suche. Indizes müssen nicht mehr durch ein separates Pro-gramm, das die Apache Lucene API nutzt, erstellt werden, sondern werden anhand von XML Konfigurationsdateien definiert und entweder direkt vom Server oder von einem externen Programm mittels der REST API mit Doku-menten gefüllt. Über die REST API können ebenso Suchanfragen auf dem Index ausgeführt werden. Apache Solr zielt mit seiner REST API vor allem auf Webanwendungen und bietet deshalb praktische Methoden und erweiterte Features, wie Pagination, Facettierung oder Highlighting.

3.1.3 Terrier

Das Terrier-Projekt begann im Jahr 2000 an der University of Glasgow mit dem Ziel, eine besonders flexible und moderne Plattform für die Forschung an unterschiedlichen Aspekten im Bereich Information Retrieval zu schaffen (vgl. Ounis, Amati, Plachouras, He, Macdonald & Lioma, 2006). Durch die hohe Flexibilität sollten vor allem neue Retrievalmodelle unterstützt und erforscht werden. So wurden von Terrier bereits 2006 verschiedene Modelle auf der Basis von Divergence-from-Randomness und später unterschiedliche Modelle basierend auf Language-Models bereitgestellt. Es soll weiterhin als nützliches Werkzeug für die Entwicklung von Anwendungen mit Informati-on Retrieval Funktionalitäten dienen. Insoweit kann es als Nachfolger von SMART verstanden werden. Seit 2004 ist Terrier unter einer Open-Source-Li-zenz, der Mozilla Public Licence10, für die Öffentlichkeit zugänglich.11 In folge

10 https://www.mozilla.org/MPL/ (27. Juni 2015)11 http://terrier.org/docs/v1.1.1/whats_new.html (27. Juni 2015)

63

dessen hat es sich auch zu einer Konstante in den CLEF Labs entwickelt, wo es immer wieder zum Einsatz kommt. (vgl. Wilhelm-Stein & Eibl, 2013)

Im Gegensatz zu Apache Lucene umfasst Terrier bereits verschiedene Par-ser um HTML, PDF oder Word-Dokumente einzulesen. Parser für nicht-un-terstützte Dokumentformate können durch die Implementierung eines pas-senden Dokument-Plugins hinzugefügt werden. Im nachfolgenden Schritt werden Dokumente in Terme zerlegt, die durch eine Term-Pipeline verarbeitet werden, um letztendlich indiziert zu werden. Terme besitzen in Terrier stets drei grundlegende Eigenschaften: Die textuelle Repräsentation des Terms, die Position des Terms im ursprünglichen Dokument und die Felder, in denen der Term im Dokument enthalten ist. Felder werden hier ähnlich zu Apache Lucene zur Unterscheidung von Dokumentteilen eingesetzt. So kann z.B. bei HTML-Dokumenten eine Unterscheidung zwischen Wörtern im Titel oder im Hauptteil sinnvoll sein.

Die Term Pipeline setzt sich aus verschiedenen Plugins zusammen, die ver-gleichbar mit den Filtern in Apache Lucene die extrahierten Terme modifizie-ren. Bereits in Terrier enthalten sind das Plugin für das Porter-Stemming und die Entfernung von Stoppwörtern. Die Reihenfolge der Plugins wird durch eine Konfiguration festgelegt. Fehlende Plugins können wieder durch die Implementierung der entsprechenden APIs hinzugefügt werden.

Am Ende der Term Pipeline steht ein Indexer. Der Indexer ist, wie der Name bereits andeutet, für die Erstellung des Index verantwortlich. Er legt alle notwendigen Datenstrukturen an, die für eine spätere Suche notwendig sind. Es gibt in Terrier unterschiedliche Indexer, die je nach Retrievalmodell und Datenmenge ausgewählt werden können. So speichert der BlockIndexer die Termposition. Die konfigurierte Blockgröße gibt dabei an, wie viele Terme zu einem Block zusammengefasst werden, also wie genau später der Abstand zwischen einzelnen Termen in die Berechnungen für das Matching einfließen kann.

64

3.1.4 Lemur / Indri / Galago

Als Forschungsplattform im Jahr 2000 gestartet, deckt das Open-Source-Pro-jekt Lemur viele Bereiche des Information Retrieval ab. Das System wurde so konzipiert, das es sich für das klassische Ad hoc Retrieval ebenso eignet, wie für Cross-Language Retrieval, Summarization (Zusammenfassungen) und Klassifizierung. Es ist in C++ implementiert, bietet jedoch Schnittstellen für C++, Java und C# an. Seit 2010 wird das Lemur Toolkit nach einigen größe-ren Veränderungen an der API unter dem Namen Indri weitergeführt. Ähnlich wie bei Terrier sind bereits Parser für die Dateiformate PDF, HTML, XML und verschiedene TREC-Formate enthalten. Zur Formulierung der Suchanfragen können einige bekannte INQUERY Operatoren verwendet werden.

Nach Wilhelm-Stein und Eibl (2013, S. 15) trat Lemur bei CLEF Experiment erstmals 2003 in Erscheinung. In den folgenden Jahren hat es sich als das am zweithäufigsten verwendete System nach Apache Lucene etabliert.

Galago ist eine auf Java basierende Open-Source Suchmaschine, die speziell für das Buch „Search Engines - Information Retrieval in Practice“ von Croft, Metzler und Strohman (2010) entwickelt wurde. Als Weiterentwicklung von Lemur und Indri sind bei der Entwicklung von Galago viele Erfahrungen aus der Umsetzung dieser Projekte eingeflossen. Es umfasst verschiedene, ef-fektive Retrievaltechniken und sollte vor allem schnell, flexibel und einfach zu verstehen sein. (vgl. Croft et al., 2010, S. 8)

3.2 Information Retrieval Systeme in der Lehre

In den folgenden Kapiteln werden Erfahrungsberichte aus der Lehre mit den eben vorgestellten Retrievalsystemen betrachtet. Obwohl einige Systeme, wie z.B. SMART oder Terrier, im Forschungskontext entstanden sind und ein Einsatz in der Lehre nahe liegt, ist dies nur selten der Fall. Vor allem Apache Lucene wird häufig in entsprechenden, praktisch ausgerichteten

65

Lehrveranstaltungen eingesetzt. Lemur, das ebenfalls seinen Ursprung in der Forschung fand, ist in der Form von Galago auch in der Lehre angekommen.

3.2.1 Apache Lucene in der Lehre

Information Retrieval, University of Strathclyde

Ruthven, Elsweiler und Nicol (2008) verwendeten Apache Lucene im Kurs Information Retrieval an der University of Strathclyde zur Realisierung einer webbasierten Suche für Dokumente aus unterschiedlichen Domänen. Die Teilnehmer sollten sich vordergründig mit den Anforderungen der Nutzer-gruppen an die Suchmaschine und die Benutzerschnittstelle auseinander-setzen. So war es bei der Suche in E-Mails wichtig, dass nach dem Datum gesucht werden konnte. Für die Shakespeare-Stücke war die Suche nach be-stimmten Phrasen oder Rollen zu beachten. Ruthven et al. (2008) begründen den Einsatz von Apache Lucene als Such-Bibliothek durch den starken Fokus auf die Nutzer und deren Interaktionen mit dem System:

The use of Lucene meant that the group did not have to invest time in implementing low-level retrieval and indexing code but could concentrate on appropriate design decisions for their documents, e.g. whether to use stemming, to use index fields or whole texts, etc. (Ruthven et al., 2008, S. 2)

Die Problematik der Evaluation von Information Retrieval Systemen war für die Teilnehmer von großer Bedeutung. Sie führten sowohl Usability Studien durch, als auch klassische Information Retrieval Evaluationen. Hier stießen sie auch auf das Problem der Relevanz, die stets subjektiv und in wenigen Fällen vollständig ist. Im Ergebnis spiegelte sich dieses Problembewusstein auch in den Prüfungsantworten wider, was in den vorherigen Jahren weniger ausgeprägt war.

66

Search Engine Development, Harding University

Im Rahmen des Kurses Search Engine Development an der Harding Universi-ty hat McCown (2010) zwei verschiedene Methoden getestet, um Studenten mit dem Thema vertraut zu machen. Eine erste Gruppe hatte 2008 die Aufga-be, eine Suchmaschine von Grund auf zu entwerfen und zu implementieren. Ein Jahr später (2009) hatte eine weitere Gruppe die Aufgabe, die bereits existierende Websuchmaschine Apache Nutch12, die auf Apache Lucene basiert, zu erweitern.

Die Kursergebnisse waren in beiden Jahren gleichwertig, jedoch kann das Ergebnis nicht als signifikant bewertet werden, da es im ersten Jahr acht und im zweiten Jahr nur drei Teilnehmer gab. Die Teilnehmer des ersten Jahres glaubten, eher die internen Abläufe einer Suchmaschine verstanden zu haben, bedauerten es aber, dass ihre Programme wahrscheinlich nicht weiterverwendet und weiterentwickelt werden. Im zweiten Jahr herrschte vor allem Unmut durch die hohe Komplexität von Apache Nutch vor. Zum einen hatte die Dokumentation nicht den von den Teilnehmern erhofften Umfang, zum anderen war das System auch für den Tutor neu, sodass auch er das System erst kennenlernen musste.

In einem semesterbegleitenden Projekt über 10 Wochen sollten Studenten des Bachelor-Studiengangs Informatics an der University of Washington ein System unter dem Titel „History Places“ (vgl. Hendry, 2007, S. 3) entwerfen und implementieren. Mit diesem System sollten verschiedene Medien zu historischen Plätzen abgelegt und durchsuchbar gemacht werden. Ein Bestandteil des Systems war eine Suchfunktion, die auf Basis von Apache Lucene implementiert werden sollte. Durch den Einsatz von Apache Lucene sollte laut Hendry (2007) die Komplexität reduziert werden:

12 http://nutch.apache.org/ (26. Juni 2015)

67

To implement this approach requires about 150 lines of Java code. In summary, with the appropriate introduction, which is done in Labs 7-8, incorporating best-match search capability is feasable in the History Places project. (Hendry, 2007, S. 15)

Obwohl Apache Lucene nicht für den Kontext der Lehre entwickelt wurde, wird es dennoch in unterschiedlichen Formen dafür eingesetzt. Der vorwiegende Beweggrund ist häufig die Reduktion der Komplexität zur Implementierung eines leistungsfähigen Information Retrieval Systems. Viele Fehler, die den Lernenden bei einer solchen Implementierung wahrscheinlich unterlaufen würden, können so vermieden werden und sie können sich ausführlicher mit den Konzepten und den Daten auseinander setzen.

Medienretrieval, Technische Universität Chemnitz

Für die Übung Medienretrieval an der Technischen Universität Chemnitz wur-den in den Wintersemestern 2007 bis 2009 mehrere praktische Übungen mit Apache Lucene realisiert. Die Übungen begannen mit einer kurzen Wiederho-lung des relevanten Vorlesungsstoffes, gefolgt von einer Vorstellung der da-mit verbundenen Klassen und Konzepte aus Apache Lucene. Im Anschluss wurden die Studierenden vom Tutor angeleitet, verschiedene praktische Aufgaben zu lösen.

In der ersten Übung wurde ein einfacher Index mit der Hilfe folgender Klassen erstellt: IndexWriter, Analyzer, Document, Field, IndexSearcher, IndexReader, Query, QueryParser und Hits. All diese Klassen wurden anhand eines konkre-ten Beispiels erklärt und eingesetzt. Der erstellte Index wurde am Ende der Übung mithilfe von Luke13, einem Werkzeug zur Analyse von Apache Lucene Indizes, untersucht.

13 http://www.getopt.org/luke/ (28. Dezember 2015)

68

Ein Analyzer in Apache Lucene setzt sich aus zwei Arten von Klassen zusam-men: einem Tokenizer und mehreren TokenFiltern. Der Tokenizer zerlegt eine Zeichenkette in Tokens (vgl. Kapitel 2.1.1.2). Die TokenFilter verarbeiten an-schließend diese Tokens (vgl. Kapitel 2.1.1.3 und 2.1.1.4). Beide Klassen und die damit verbundenen Konzepte wurden in der zweiten Übung eingeführt und praktisch angewendet.

In der dritten Übung wurde das Thema Evaluation aus der Vorlesung aufge-griffen und anhand einer kleinen Dokumentensammlung am Beispiel von Precision und Recall umgesetzt. Diese Möglichkeit zur Bewertung von Sys-temen bzw. Veränderungen an einem System wurde in der folgenden Übung anhand einer Erweiterung der Suchanfragen durch Synonyme angewendet. Die für die Synonymbestimmung notwendigen Funktionen zum Einlesen und Durchsuchen des Thesaurus mussten von den Studierenden so angewendet werden, dass die Synonyme in einer mit Apache Lucene kompatiblen Form vorlagen.

Um den Studierenden die Thematik des Content Based Image Retrivals durch ein praktisches Beispiel näher zu bringen, wurde ein einfaches Farb-histogramm in Textform codiert und in einem Lucene Index abgelegt. Die Konzepte der Fuzzy Bins und der Nutzung eines speziellen Farbraums, der mehr dem menschlichen Sehen entspricht als der RGB-Farbraum, wurden ebenfalls kurz ausprobiert.

Die Durchführung der Übung Medienretrieval stellte die Studierenden vor mehrere Herausforderungen:

– Die objektorientierte Programmierung, insbesondere Java, war nicht im Stundenplan enthalten und deshalb Neuland für einige Studierende.

69

– Damit die Studierenden selbstständig mit Apache Lucene ar-beiten konnten, mussten sie sehr viele Klassen und Konzepte kennenlernen.

– Das Einlesen von Dokumenten ist explizit nicht Bestandteil von Apache Lucene und musste separat behandelt und implementiert werden.

Studierende, die mit Java bereits in Kontakt gekommen waren, konnten sich viel besser auf die Inhalte konzentrieren und hatten insgesamt auch weni-ger Probleme bei der Umsetzung der gestellten Aufgaben. Im letzten Jahr (2009) der Durchführung dieses Übungsprogramms zeichnete sich jedoch eine zunehmender Anteil an Studierenden ohne Programmierkenntnisse ab, da die Veranstaltung auch für andere Studiengänge (u.a. Master Medien-kommunikation) angeboten wurde. Für den Studiengang Master Informatik für Geistes- und Sozialwissenschaftler war eine Übung mit weniger Program-mieraufgaben zweckmäßiger, vor allem da diese in ihren ersten Semestern bereits den Einstieg in C und C++ finden müssen und durch eine zusätzliche Sprache, die sich konzeptuell stark von C und C++ unterscheidet, zusätzlich abgelenkt werden würden.

Development of Search Engines, Universiti Kebangsaan Malaysia

Mohd (2011) beschreibt Durchführung und Ergebnisse des Kurses „Devel-opment of Search Engines“ an der Universiti Kebangsaan Malaysia. Ein Be-standteil des Kurses war ein Projekt zur Erstellung eines Information Retriev-al Systems bzw. einer Suchmaschine auf der Basis von Apache Lucene. Es nahmen 28 Studierende im ersten Semester des Studiengangs Information Science (Informationswissenschaft) teil.

70

Es wurden fünf Lernziele definiert, zu denen die Studierenden am Ende des Kurses eine Selbsteinschätzung über ihren Erfolg abgaben:

1. Konzepte aus den Bereichen Informati-on Retrieval und Suchmaschinen

2. Identifikation von Komponenten, Techniken und Modellen3. Erklären des Information Retrieval Prozesses4. Analyse und Evaluation der Effektivität von Suchmaschinen5. Entwicklung einer Suchmaschine bzw. eines Information Retrieval

Systems mithilfe der gelernten Konzepte und Techniken

Die Mehrheit der Studierenden gab für die ersten vier Lernziele an, dass diese erreicht wurden. Für das fünfte Lernziel waren die Antworten gemischt. Etwa 15% gaben an, das Lernziel nicht erreicht zu haben. Der Hauptgrund dafür waren Probleme mit der Programmiersprache Java und bei der Anwendung von Apache Lucene. Um diese Probleme zu beheben, wurden zusätzliche Termine mit detaillierten Anleitungen und ausführlichen Demonstrationen angeboten.

Die resultierenden Suchmaschinen lieferten Ergebnisse von durchschnittli-cher Qualität. Viele Implementierungen blieben hinter den Erwartungen des Kursleiters zurück. Es wurden z.B. keine Stemmingverfahren eingesetzt, was nach Mohd (2011) zu einem besseren Index und in folge dessen zu besseren Ergebnissen geführt hätte.

Für das folgende Jahr sollte laut Mohd (2011) der Java-Kurs, der im ent-sprechenden Studiengang vorhanden ist, aber erst später im Zeitplan steht, als Voraussetzung für eine Teilnahme gelten. Nur so können sich die Stu-dierenden auf das Thema Information Retrieval und dessen Konzepte und Anwendungen konzentrieren.

71

3.2.2 Galago in der Lehre

Jung und Lawrance (2011) führten einen Kurs für Informatikstudierende an der Bridgewater State University, MA in den Vereinigten Staaten durch. Die Inhalte des Kurses basierten auf dem Buch „Search engines - Information Retrieval in Practice“ von Croft, Metzler und Strohman (2010), in dem eine Weiterentwicklung der Indri Suchbibliothek (siehe Kapitel 3.1.4) Schritt für Schritt vorgestellt wird. Die einzige Vorraussetzung für eine Teilnahme war der vorherige Besuch einer Einführung in Java.

Zu Beginn des Kurses richteten die Studierenden die Galago Suchmaschine in einer Vituellen Machine unter Linux ein. Laut Jung et al. (2011) sammelten viele Studierende hierbei erste Erfahrungen mit Linux. Nachdem diverse Information Retrieval Konzepte vorgestellt wurden, arbeiteten die Studie-renden direkt mit dem Quellcode von Galago. Obwohl sie keine eigenen Komponenten selbstständig entwickelten, begrüßten die Studierenden die Einblicke in den Quellcode von Galago. Einige Studierende hatten jedoch große Schwierigkeiten bei der Implementierung ihrer Projekte, obwohl Jung et al. (2011) einen Großteil der Implementierung bereits vorgaben und nur kleine Anpassungen von den Studierenden verlangten.

Das Fazit von Jung et al. (2011) ist ernüchternd. Die Vorbereitung und die Anpassung von Galago an die Fähigkeiten der Studierenden nahm viel Zeit in Anspruch. Ebenso war die Recherche nach Komponenten, die dem Lehrstoff entsprachen, sehr aufwendig. Ob die Einrichtung einer Virtuellen Maschine als Entwicklungs- und Testumgebung notwendig war bleibt offen. Dennoch hinterließ der Kurs bei den Studierenden einen positiven Eindruck, was vor allem mit der praktischen Arbeit zusammenhing.

72

3.2.3 Fazit

Die Ausbildung anhand von Open-Source-Bibliotheken eignet sich in erster Linie für Studierende der Informatik, da für sie die Wahrscheinlichkeit, dass sie mit einer der notwendigen Programmiersprachen in Kontakt gekommen sind, am größten ist. Für Studierende ohne einen informatischen Hintergrund eignet sich keine der vorgestellten Herangehensweisen. Ohne Vorkenntnisse in der Programmierung werden die Information Retrieval Konzepte schnell in eine Nebenrolle gedrängt und die Studierenden lernen vielmehr das Pro-grammieren, als die Konzepte und Techniken des Information Retrievals.

Martínez-Comeche bringt diesen Umstand auf den Punkt:

This union between technical and user aspects already exists in some courses for CS students and also for LIS students, but always with a focus on the technical approach. (Martínez-Comeche & Cacheda, 2011, S. 125)

Die technischen Aspekte stehen bei Information Retrieval Systemen in der Lehre unbeabsichtigt im Mittelpunkt. Im folgenden Kapitel wird spezielle Lernsoftware behandelt, mit deren Hilfe der Fokus auf diese technischen Aspekte verringert werden kann.

3.3 Information Retrieval Lernsoftware

Dieses Unterkapitel behandelt Lernsoftware für Information Retrieval, d.h. Software, die speziell für Lehrzwecke entwickelt wurde und Aspekte des Information Retrieval vermittelt. Die untersuchten Realisierungen unterschei-den sich sowohl thematisch, als auch substantiell.

73

3.3.1 INSTRUCT

Bereits 1986 stellten Hendry, Willett und Wood (1986a; 1986b) INSTRUCT (INteractive System for Teaching Retrieval Using Computational Techniques) vor. Es richtete sich vor allem an Bildungseinrichtungen für Bibliotheks- und Informationswissenschaft um Studenten und Schülern neue Entwicklungen im Bereich der Information Retrieval Systeme aufzuzeigen und zu demons-trieren. Die bisherige Ausbildung fand stets anhand von existierenden, kommerziellen Systemen statt, die zwar bei einem zeitnahen Eintritt in das Berufsleben vorlagen, aber dennoch nicht dem aktuellen Stand der For-schung entsprachen. Durch INSTRUCT sollten die Lernenden auf eine neue Generation von Information Retrieval Systemen vorbereitet werden.

Die Anwendung nutzte eine zeichenorientierte, menügesteuerte Benutzungs-schnittstelle. Durch verschiedene Auswahlmenüs wurden verfügbare Funk-tionen und Optionen aufgezeigt, erläutert und durch die Eingabe von Zahlen und Buchstaben ausgewählt. Neben den damals üblichen Boolschen Retriev-al konnten Suchanfragen auch in natürlicher Sprache formuliert werden. So war es möglich, Sätze oder Listen von Wörtern bzw. Schlüsselwörtern als Suchanfrage zu verwenden.

In der Vorverarbeitung wurden zunächst etwa 300 Stoppwörter entfernt. Neben klassischen Funktionswörtern wurden auch häufig auftretende An-fragephrasen, wie z.B. „anything on“ oder „have you got“, eliminiert. Nach-folgend wurden alle verbleibenden Wörter mit dem Porter-Stemmer auf ihre Stammform reduziert.

Das Ergebnis der Vorverarbeitung der Suchanfrage wurde dem Nutzer zur Kontrolle und zur weiteren Verfeinerung präsentiert. Zu jedem Term wurde die Anzahl der Dokumente, die diesen Term enthalten, angezeigt. Der Nut-zer konnte weitere Wörter bzw. Terme zur Suchanfrage hinzufügen oder seltene Terme entfernen. Ein zusätzlicher Mechanismus erlaubte es dem Nutzer, ähnliche Terme zu den bereits angezeigten Termen zu finden und

74

zur Suchanfrage hinzuzufügen. Die Ähnlichkeit zweier Terme wurde anhand von übereinstimmenden Trigrammen bestimmt. Nach der Anzeige der zehn ähnlichsten Terme konnten diese in die Suchanfrage übernommen werden.

Als Testkollektion kam die Library and Information Science Abstract (LISA) Datenbank aus dem Jahr 1982 zum Einsatz. Sie setzt sich aus 6.004 Do-kumenten bestehend aus Titel, Zusammenfassung (Abstract), Literaturan-gaben und Identifikationsnummer zusammen. Um Speicherplatz zu sparen, wurden die Literaturangeben jedoch nicht verwendet. Nach Anwendung der gleichen Vorverarbeitungsschritte und der Entfernung von Dopplungen wur-den alle verbliebenen Terme in einer invertierten Liste gespeichert.

Das Ergebnis des Nearest-Neighbour-Matchings (vgl. Hendry et al., 1986b) zwischen Suchanfrage und Dokumenten ist eine gerankte Ergebnisliste. Das damals vorwiegend eingesetzte Boolsche Retrieval liefert als Ergebnis ledig-lich, ob ein Dokument zur Suchanfrage passt oder ob nicht, aber es erlaubt keine Gewichtung, die für ein Ranking notwendig ist. Nach der Präsentation der Ergebnisliste sind weitere Verfeinerungen der Suchanfrage möglich. Da-rüber hinaus gab es die Möglichkeit für ein Relevance Feedback. Das heißt anhand der Ergebnisliste konnten relevante Dokumente ausgewählt wer-den, um zusätzlich Einfluss auf die Gewichtung der Terme für ein weiteres Matching zu nehmen.

Auch ein Boolsches Matching konnte durchgeführt werden. Dafür konnten die aus der Suchanfrage extrahierten Terme durch die Boolschen Operato-ren AND, OR und NOT miteinander kombiniert werden, um so komplexere Beziehungen zwischen den Termen zu formulieren. Nach Anfragen von Nutzern wurde die Möglichkeit der Kombination beider Matching-Verfahren umgesetzt.

Die ausführliche Dokumentation eines Beispiel-Suchablaufs ist im Original-paper von Hendry et al. (1986a, S. 254-258) zu finden (siehe auch Abbildung 3.1). Besonders hilfreich erscheinen das schrittweise Vorgehen und die sehr

75

ausführlichen Erläuterungen zu den einzelnen Schritten. Nachdem ein Nutzer sich mit dem Ablauf und den Verfahren vertraut gemacht hat, kann er sich entscheiden, diese Erläuterungen nicht mehr angezeigt zu bekommen. Um den Einstieg weiter zu vereinfachen, standen den Nutzern zwei kommentier-te Beispielsuchanfragen zur Verfügung, die den Ablauf genau beschrieben.

Abbildung 3.1: Suchverlauf mit INSTRUCT (Hendry et al., 1986a, S. 254-258)

Alle Studenten des Jahrgangs 1984-1985 im Master of Arts Libarianship und im Master of Science Information Studies der Universität Sheffield nutzten INSTRUCT, um verschiedene Suchen durchzuführen. Die Einschätzung der Anwendung durch die Studenten fiel positiv aus, wurde jedoch nicht näher beziffert. Da mehrere Studenten die Anwendung auch für Haus- und

76

Abschlussarbeiten nutzten, bemängelten sie den Umfang der Datenbank, die aus dem Jahr 1982 stammte. Die Nutzung für eben diese Arbeiten verdeut-licht noch einmal auf besondere Art und Weise die Benutzerfreundlichkeit der Anwendung.

Mittels INSTRUCT konnten komplexe Suchanfragen entwickelt und angewen-det werden. Die Nutzer hatten darüber hinaus keinen direkten Einfluss auf die zugrundeliegenden Vorverarbeitungs-, Indizierungs- und Suchalgorith-men. Eine Evaluation der Ergebnisse fand nicht statt, sodass die Bewertung der Suchergebnisse auf den subjektiven Beobachtungen der Nutzer oder der Tutoren basierte.

3.3.2 IR Game / QPA

Das von Sormunen et al. (1998) vorgestellte IR Game, auch bekannt als Query Performance Analyser (QPA), ist eine Webanwendung zur Untersuchung des Einflusses unterschiedlicher Formulierungen von Suchanfragen vor allem in einem multilingualen Kontext. Als Information Retrieval Systeme kommen InQuery (vgl. Callan, Croft & Harding, 1992) für das probabilistische Retriev-al und Tieto TRIP14 für das Boolsche Retrieval zum Einsatz. Das IR Game konnte sowohl für die Forschung als auch die Lehre eingesetzt werden (vgl. Sormunen, Hokkanen, Kangaslampi, Pyy & Sepponen, 2002).

Im ersten Schritt musste der Nutzer eine Testkollektion auswählen, die sich je nach Anwendungsgebiet unterscheiden konnte. Vor allem für die For-schung wurden die Testkollektionen oft den Bedürfnissen angepasst. Diese häufigen Änderungen waren für die Lehre nicht erwünscht.

Der Nutzer konnte nun aus einer Liste von Suchanfragen eine Suchan-frage zur Bearbeitung auswählen. Nachdem er die Suchanfrage in der

14 https://trip.service.tieto.com/wiki/dashboard.action (11. Januar 2015)

77

Anfragesprache von InQuery formuliert hatte, wurde diese durch das System verarbeitet und mit Übersetzungen und Synonymen angereichert. Die resul-tierende Suchanfrage konnte vom Nutzer nochmal verändert werden, bevor sie an das System zur Verarbeitung durch die Suchmaschine gegeben wurde.

Abbildung 3.2: IR Game - Ansicht einer Ergebnisliste (Sormunen et al., 1998)

Die Ergebnisse wurden zum einen als Recall-Precision-Diagramm angezeigt, das anhand der vorhandenen Relevanzbewertungen erstellt werden konnte. Im gleichen Diagramm wurde auch das bis dahin beste Ergebnis (bezüglich der Average Precision) angezeigt, um den Nutzer bei der Einschätzung der Qualität seiner Suchanfrage zu unterstützen. Zum anderen gab es eine Liste mit den ersten zehn gefunden Dokumenten, ihrer tatsächlichen Relevanz, den Bewertungen durch das System und ihren Titeln. Ein Balken zeigte eine hilfreiche Übersicht über die ersten 100 Dokumente und deren Relevanz. Über den Balken konnten weitere Dokumente in die Ergebnisliste geladen

78

werden. Außerdem wurde der Nutzer über die Anzahl relevanter Dokumente, gefundener Dokumente und relevanter, gefundener Dokumente informiert.

In einer Studie von Halttunen und Sormunen (2000) wurde die Eignung des Systems für die Lehre weiter untersucht. Den Rahmen bildete 1999 die Vor-lesung „Basics of Information Retrieval“ an der Universität Tampere. Das IR Game wurde in der Vorlesung eingeführt und zur Vorstellung von Precision und Recall und zur Demonstration von Image Retrieval genutzt. Außerdem kam es während der Übung zum Einsatz.

In vier Übungen haben sich jeweils zehn Studierende in kleinen Gruppen mit ein bis drei Personen mit dem System auseinandergesetzt. Jede Gruppe wurde während der Übung gefilmt. Dabei sollten vor allem Diskussionen während der Vorbereitung, Durchführung und Evaluation der Suchanfragen aufgezeichnet werden.

Eine Woche nach der Übung sollten die Studierenden einen Aufsatz über ihre Lernerfahrungen schreiben. Die Aufsätze wurden nach der Methodik des Non-Active Role-Playing (vgl. Eskola, 1988) verfasst. Dabei wird dem Verfas-ser ein Skript vorgelegt, das eine Situation beschreibt und damit die grobe Richtung des Aufsatzes vorgibt. Der Verfasser kann nun in seinem Aufsatz die Situation des Skriptes in einer Geschichte fortsetzen oder die Umstände, wie es zu dieser Situation gekommen ist, beschreiben. Für das Skript einer positiven Lernerfahrung entstanden 32 Geschichten, für das Skript einer negativen Lernerfahrung waren es 31 Geschichten.

Das Feedback über die Effektivität der Suchanfrage wurde als signifikant für das Lernen eingestuft. Auch die Möglichkeit, die eigene Suchanfrage weiter zu verfeinern und zu evaluieren, war für die Motivation und das Lernen förderlich. Im Gegensatz zu den sonst üblichen Datenbanksystemen konnte der Fokus von der Auswertung einzelner Suchergebnisse hin zu einer tiefge-henden Analyse verschoben werden. Mehrere Studenten berichteten, dass

79

die grafische Präsentation der Suchergebnisse aufschlussreicher war, als Zahlenwerte.

Andererseits wurden das Feedback und die grafische Präsentation auch negativ bewertet. Die Inspektion der Ergebnisdokumente wäre manchmal hilfreicher gewesen, als sich auf das Optimieren des Precision-Recall-Dia-gramms zu konzentrieren. Das reflexartige Anpassen der Suchanfragen, ohne eine tatsächliche Auswertung der Ergebnisse, lässt die Studierenden nur an der Oberfläche kratzen und verhindert eine tiefgründige Auseinan-dersetzung mit dem Thema. Als Verbesserung für eine zukünftige Version wurde überlegt, die Reihenfolge der Darstellungen zu verändern.

Ein weiteres Feature, das in den Übungen nicht direkt beworben wurde, aber durchweg positiv bewertet wurde, ist die „Hall of fame“. In ihr wurden die besten Suchanfragen gesammelt, was dazu führte, dass die Teams versuch-ten, ihre Ergebnisse zu verbessern, um besser als die Konkurrenz zu sein.

Die Funktionalität, Dokumente anzuzeigen, wurde nicht so häufig eingesetzt, wie von den Autoren antizipiert. Relevante Dokumente wurden nur kurz unter-sucht, um vereinzelt neue Suchbegriffe auszuwählen. Eine intensive Analyse langer Dokumente fand sehr selten statt. Durch den Spielaspekt angetrieben, versuchten die Studierenden vielmehr neue Suchbegriffe zu konstruieren (vgl. Downs, Holbrook, Sheng & Cranor, 2010).

Das Ergebnis einer weiteren, größer angelegten Studie von Halttunen und Järvelin (2005), die zwei verschiedene Lernumgebungen untersuchte, ist dagegen uneinheitlicher. Die Probanden wurden in zwei Gruppen eingeteilt: eine Gruppe, die mit einer experimentellen Lernumgebung mit dem IR Game arbeitete, und eine Gruppe, die in einer traditionellen Lernumgebung ohne das IR Game arbeitete. Alle Probanden mussten wieder verschiedene Es-says verfassen, die mit unterschiedlichen Methoden ausgewertet wurden. Zusammengefasst kamen die Autoren zu folgenden Ergebnissen: Beide Gruppen hoben die gelernten Information Retrieval Methoden hervor. Die

80

Beschreibungen der Evaluation, linguistischer Aspekte und der Informations-beschaffung, die Probanden der experimentellen Lernumgebung verfassten, waren ausführlicher, als die der Probanden der traditionellen Lernumgebung. Dagegen legten die Probanden der traditionellen Lernumgebung mehr Wert auf Allgemeinwissen und Informationsspeicherung.

Bei einem abschließenden Test schnitten die Probanden der experimentellen Lernumgebung besser ab. Beide Gruppen sollten hierbei Suchanfragen für ein neues, beiden Gruppen unbekanntes Korpus formulieren, deren Ergebnis-se ausgewertet wurden. Den Probanden der experimentellen Lernumgebung unterliefen weniger semantische Fehler. Syntaktische Fehler waren in beiden Gruppen ähnlich verteilt, konnten jedoch von beiden Gruppen durch aktive Exploration bewältigt werden. Die häufigen semantischen Fehler der Proban-den der traditionellen Lernumgebung führten zu einem besseren Abschnei-den der Probanden der experimentellen Lernumgebung.

Weiterhin wurde festgestellt, dass unterschiedliche Studiengänge unter-schiedliche Schlussfolgerungen und Ergebnisse erzielten und die Varianz zwischen den Studiengängen teilweise sehr hoch war. Insbesondere entwi-ckelten sich die Konzepte von Geisteswissenschaftlern und Naturwissen-schaftlern sehr unterschiedlich. Die Geisteswissenschaftler formulierten anfangs die wenigsten Konzepte, entwickelten aber im Laufe des Tests viele neue Konzepte zu Information Retrieval. In dieser Gruppe kamen neue Konzepte häufiger als bei allen anderen Studiengängen hinzu. Jedoch wur-den von ihnen Computerkenntnisse als weniger wichtig eingestuft als von Naturwissenschaftlern.

Zusammenfassend wurde das IR Game ausführlich untersucht, besonders im Hinblick auf eine bessere Ausbildung. Die tiefgehende Auseinandersetzung mit der Suchanfrage und die Förderung explorativen Vorgehens unterstützen die Lernenden bei der Entwicklung konzeptueller und mentaler Modelle für die Funktionsweise von Suchmaschinen. Ein wichtiger Aspekt bei allen Test

81

waren stets anleitende Übungen, die den Lernenden beim Umgang mit dem IR Game halfen, da das System nicht selbsterklärend war.

Das IR Game stellte, wie auch INSTRUCT von Hendry et al. (1986a; 1986b), die Formulierung qualitativ hochwertiger Suchanfragen in den Mittelpunkt. Es werden also in erster Linie die von den Lernenden formulierten Suchan-fragen evaluiert, jedoch nicht die verwendeten Retrievalkomponenten oder Algorithmen. Zwar konnten einige wenige Eigenschaften des verwendeten Index ausgewählt werden, jedoch hatten die Lernenden keinen direkten Ein-fluss auf das eingesetzte Information Retrieval System und dessen Einstel-lungen. Dank innovativer Darstellungen wurde den Studierenden der Zugang zu den Ergebnissen vereinfacht, jedoch bleiben viele Evaluationsmetriken verborgen oder wurden nur in aggregierter Form wiedergegeben. Die Interak-tivität des IR Games beschränkt sich auf die Formulierung der Suchanfragen und die Exploration der Ergebnisse, andere Aspekte eines Information Re-trieval Systems bleiben den Lernenden verborgen.

3.3.3 IR-Toolbox

IR-Toolbox (Efthimiadis & Freier, 2007) war ein webbasiertes Lernwerkzeug mit dem Ziel, Studenten den Information Retrieval Prozess zu vermitteln. Durch praktisches Experimentieren ohne den Einsatz einer Programmier-sprache sollten die Studenten ein reichhaltigeres konzeptuelles Modell entwickeln und somit den Information Retrieval Prozess und die damit ver-bundene Algorithmen besser verstehen. Das System setzte Apache Lucene als Suchmaschine ein. Technisch versierte Studenten konnten auf konkrete Implementierungsdetails zugreifen. (Efthimiadis, Callan & Larson, 2007)

Die Nutzer konnte die folgenden Prozessschritte anpassen und konfigurieren:

– Dokumentanalyse (Tokenising, Stemming und Stoppwörter-Entfernung)

82

– Indizierung (mit der Möglichkeit, den Index zu durchsuchen)– Suche (durch Eingabe eigener Suchanfragen und die Wahl zwischen

verschiedenen Gewichtungsalgorithmen wie TF-IDF und BM25)– Evaluation (anhand von TREC Kollektionen und

Recall-Precision-Diagrammen und Tabellen)

Abbildung 3.3: IR Toolbox - Ansicht zur Untersuchung

eines Index (Adcock et al., 2007, S. 18)

Adcock, Haberfelde und Szydlowski (2007) führten eine Usability Studie durch jedoch wurden dazu keine Ergebnisse veröffentlicht. Das Dokument zur Durchführung der Usability Studie gibt jedoch einen Einblick, wie die Benutzungsoberfläche des Systems beschaffen war und welche potentiellen Schwachstellen die Autoren vermuteten. In der Usability Studie wurde vor allem hinterfragt, in wie weit die Oberfläche ausreichend gut beschrieben ist und an welchen Stellen fehlerhafte Eingaben gemacht wurden.

83

Die IR-Toolbox ermöglichte die Konfiguration bestimmter, vorgegebener Komponenten des Information Retrieval Prozesses. Jedoch konnten die Komponenten nicht frei von den Lernenden zusammengestellt werden, so-dass der Spielraum sehr eingeschränkt war. Die Benutzungsoberfläche war sehr minimalistisch gehalten, was die Verständlichkeit für neue Nutzer stark einschränkt. Zusätzliche erklärende Texte enthalten häufig Verweise auf an-dere Medien oder Aktionen, die einen Medienbruch nach sich ziehen, sodass die Lernumgebung verlassen werden muss, um detaillierte Informationen zu erhalten.

3.3.4 IR-BASE

Auch das von Calado, Cardoso-Cachopo und Oliveira (2007a) vorgestellte IR-BASE sollte Forschung und Lehre unterstützen. Es sollte vor allem ein Grundgerüst für die Implementierung neuer Information Retrieval Kompo-nenten bieten. Richtlinien und Dokumentationen sollten die Kompatibilität zwischen den Komponenten gewährleisten, damit diese zusammen verwen-det werden können. Es sollte ein Fundus an Komponenten entstehen, der durch neue Komponenten vom Nutzer ausgebaut werden kann. Durch das Zusammenschalten mehrerer Komponenten sollte ein vollständiges, funktio-nierendes Information Retrieval System entstehen.

Dank der auf Komponenten basierenden Architektur erhofften sich die Au-toren eine einfache Wiederverwendbarkeit und damit einfache und schnelle Tests neuer Komponenten für Forscher und Entwickler. Durch unterschied-liche Detailgrade soll Lehrern und Lernenden die Möglichkeit gegeben werden, die für den vorliegenden Kenntnisstand passende Ansicht auf die Komponenten und gegebenenfalls auf die internen Abläufe zu wählen.

84

Die für IR-BASE zentralen Komponenten bestehen stets aus einer Schnitt-stelle zum Steuern und Konfigurieren der Komponente (ControlInterface). Weitere Schnittstellen, die implementiert werden können, sind:

– InputInterface: Nimmt Daten von einer an-deren Komponente entgegen.

– OutputInterface: Gibt Daten an eine andere Komponente weiter– ProbingInterface: Zur Überwachung des Zustandes der

Komponente bzw. Beobachtung der internen Abläufe.

Die für die Forschung und Lehre wichtigste Schnittstelle ist das ProbingInterface. Es erlaubt einen Einblick in die sonst als Blackbox konzi-pierten Komponenten. Durch einen gemeinsamen Vorrat an Komponenten, der über eine Webseite abgerufen werden kann, profitieren Forscher und Ler-nende, die gemeinsam Komponenten entwickeln können und daraus einfach Systeme zum Test eigener Komponenten zusammenstellen können.

Laut den Präsentationsfolien (Calado et al., 2007b) zu dieser Veröffentli-chung wurden bereits einfache Komponenten von verschiedenen Studenten entwickelt. Es existiert jedoch noch keine Umsetzung der geplanten Web-seite zum Austausch der Komponenten. Das Projekt war zum Zeitpunkt der Präsentation „behind schedule“, also hinter dem Zeitplan, und litt unter mangelndem Zuspruch durch die Studierenden.

Der Entwurf von IR-BASE als Framework für die Entwicklung von Information Retrieval Komponenten erfordert entsprechende Programmierkenntnisse bei den Lernenden. Durch die Richtlinien und die Dokumentation sollten be-stimmte, bekannte Fehler bei der Erstellung neuer Komponenten vermieden werden. Dieser Ansatz eignet sich deshalb nur für bereits gut ausgebildete Studierende aus dem Bereich Informatik und nicht für Studierende ohne vor-herige Programmierkenntnisse. Ebenfalls fehlen Möglichkeiten zur Evalua-tion dieser neuen Komponenten, sodass nicht nur deren Leistungsfähigkeit

85

nicht bestimmt werden kann, sondern auch eventuelle Fehler in der Imple-mentierung unentdeckt bleiben könnten (vgl. Kürsten, 2012, S. 299ff.).

3.3.5 IR-Components

Das von López-Garcia und Cacheda (2011) vorgestellte IR-Components ist ein Java-Framework zur Entwicklung von Information Rretrieval Anwendun-gen. Für jeden Schritt des Information Retrieval Prozesses enthält IR-Compo-nents bereits eine Komponente, die für einfache Experimente genutzt werden kann. Die Lernenden werden jedoch dazu angehalten, eigene Komponenten zu entwickeln, die die Ergebnisse des Basissystems verbessern.

Das System ist speziell auf Webretrieval ausgerichtet, weshalb auch im-mer ein Webcrawler zu den zu verwendenden Komponenten zählt. Um erste Versuche mit dem System zu unternehmen, müssen die Lernenden vor allem Java beherrschen und die wichtigen Interfaces und Klassen von IR-Components kennen. Die Benutzungsoberfläche für den Suchenden und eine verteilte Ausführungsumgebung waren vorgegeben und mussten nicht selbst erstellt werden. Ausgangspunkt für die Zusammenstellung eines ei-genen Systems und die Erstellung eigener Komponenten war eine Dokumen-tation der Module. In einem ersten Schritt mussten die Lernenden sich mit dieser auseinandersetzen und lernen, wie das Framework einzusetzen ist.

In einem Kurs über „Internet Information Retrieval“ an der University of A Coruña in Spanien wurden die teilnehmenden Studierenden zweier aufein-ander folgender Jahrgänge zu ihren Erfahrungen befragt. Der erste, frühere Jahregang musste den Kurs ohne IR-Components bewältigen, der folgende Jahrgang konnte das Framework einsetzen, um die gestellten Aufgaben zu erfüllen. Außer dem Framework hatten die Studierenden beider Jahrgänge Zugriff auf ein Diskussionsforum zum Kurs.

86

Der Zugang zu all diesen Ressourcen wurde von den Studierenden als wich-tig und notwendig für den erfolgreichen Abschluss des Kurses bewertet. Das Framework half den Studierenden sich auf die Inhalte des Kurses zu konzentrieren. Die vorgegebenen Modelle führten insgesamt zu einer bes-seren Architektur der Anwendungen. Letztlich argumentieren die Autoren, dass der Einsatz des Frameworks half, die Variabilität der Lösungen im Kurs zu reduzieren. So gab es weniger Studierende, die die Aufgaben zu schwer oder zu einfach empfanden oder die das vermittelte Wissen als zu gering für eine Umsetzung der Aufgaben einschätzten. Durch die geringere Variabilität sahen die Lehrkräfte einen geringeren Aufwand bei der Auswertung der stu-dentischen Beiträge. Jedoch wird die Vermittlung einer neuen API in Bezug auf den inhaltlichen Umfang des Kurses als kritisch betrachtet.

Für eine Weiterentwicklung von IR-Components werden zwei Richtungen aufgezeigt: Zum einen kann IR-Components auf die Anforderungen von For-schern ausgerichtet werden und so für einen einfacheren Einstieg für Nach-wuchsforscher in die Thematik dienen. Zum anderen ist eine Ausrichtung auf weniger technische Studiengänge und Kurse möglich. Das Projekt scheint jedoch nicht fortgeführt zu werden, da die letzte Veröffentlichung aus dem Jahr 2012 stammt. Auch die letzte Aktualisierung des Quellcodes, der über die Projekt-Homepage15 abrufbar ist, war im Jahr 2012.

Wie auch bei IR-BASE benötigen die Lernenden für die Verwendung der IR-Components Programmierkenntnisse. Ohne gute Grundlagen in der Java-Programmierung, insbesondere der Objektorientierung, können sich die Lernenden nicht auf das tatsächliche Thema des Kurses bzw. des Frame-works konzentrieren. Trotz Dokumentation und verschiedener Anleitungen würde die Programmierung im Vordergrund stehen und die Information Re-trieval Aspekte in den Hintergrund treten. Hinzu kommen noch mögliche Pro-bleme bei der Einrichtung der Entwicklungsumgebung. Die IR-Components

15 http://www.dl.kuis.kyoto-u.ac.jp/~rafael.lopez/software/ir-components/ (28. Mai 2015)

87

bieten ebenfalls keine Unterstützung zur Evaluation der erstellten Kompo-nenten, was im Umfeld des Web Information Retrievals ohnehin problema-tisch ist. Das und die möglichen Probleme mit der Programmierumgebung erlauben den Lernenden nur eine oberflächliche Auseinandersetzung mit dem Information Retrieval Prozess.

3.3.6 SulaIR

Fernández-Lune, Huete, Rodríguez-Cano und Rodríguez (2012) greifen mit SulaIR die Idee hinter der IR Toolbox auf und entwickelten sie weiter. Das Ergebnis ist eine Desktop-Anwendung (Java), die ebenso wie IR Toolbox die grundsätzlichen Schritte des Information Retrieval Prozesses abbildet. Zu je-dem der Schritte (Vorverarbeitung, Indizierung: siehe Abbildung 3.4, Retrieval und Relevance Feedback) gibt es Visualisierungen, die beim Verständnis der internen Abläufe unterstützen sollen.

Abbildung 3.4: Ansicht der Indexerstellung (Fernández-Lune et al., 2012)

88

Laut Fernández-Lune et al. (2012) wurde das System im Rahmen eines In-formation Retrieval Kurses an der University of Holguín in Kuba getestet und die Ergebnisse sind positiv ausgefallen. Die Art des Tests und die tatsäch-lichen Ergebnisse liegen jedoch nicht vor. Das Projekt scheint nicht weiter geführt zu werden, da trotz einer Open-Source-Ankündigung kein passendes Open-Source-Projekt auffindbar ist und weitere Veröffentlichungen nicht stattgefunden haben.

Die Umsetzung als Desktopanwendung ist für das Jahr 2012 nicht zeitgemäß, vor allem da der Ideengeber, die IR Toolbox, bereits eine Webanwendung war. Die Gestaltung der Benutzungsoberfläche erscheint nicht besonders benut-zerfreundlich, z.B. sind in Abbildung 3.4 im oberen, linken Abschnitt Tabs innerhalb weiterer Tabs angeordnet. Die überaus ausladende Tabellendar-stellung benötigt trotz der überaus großen Ausführung Scrollbalken, wobei deren vertikale Ausdehnung die Dimension der tatsächlichen Tabelle erah-nen lässt. Hier sinnvolle Daten zu entdecken, erscheint aussichtslos. Ohne eine Anleitung durch einen Tutor erscheint die Benutzungsoberfläche nicht bedienbar. Wie bereits bei IR-BASE und IR-Components kann auch mit SulaIR keine Evaluation durchgeführt werden. Die Qualität einer Suchanfrage muss von jedem Nutzer selbst anhand der Ergebnisdokumente bestimmt werden, wobei es keine Unterstützung zur Berechnung von Evaluationsmetriken gibt.

3.3.7 VIRLab

Die Webanwendung VIRLab von Fang, Wu, Yang und Zhai (2014) ist auf Ex-perimente mit Information Retrievalmodellen spezialisiert. Lernende erstel-len eigene IR Modelle und können deren Ergebnisse mit anderen Modellen vergleichen. Die IR Modelle werden in C/C++ erstellt und können auf um-fangreiche Schnittstellen zu Dokument- und Term-Statistiken zugreifen. Der Lernende kann das Retrievalmodell mit eigenen Suchanfragen oder vorge-gebene Testkollektionen inklusive Suchanfragen und Relevanzbewertungen

89

testen. Für den direkten Vergleich mit anderen Modellen stehen Metriken und Diagramme auf Experiment- und Query-Ebene zur Verfügung.

Auf der Webseite von VIRLab (Yang, 2015) wird die Webanwendung wie folgt angepriesen:

Virtual Information Retrieval Lab (VIRLab) is a web-based virtual laboratory for Information Retrieval. It is a unique and novel tool that can help teaching IR models, improving the productivity for doing IR model research, as well as promoting controlled experimental study of IR models. (Yang, 2015)

Laut Yang (2015) wurde die Webanwendung bereits an fünf Universitäten in den Vereinigten Staaten eingesetzt. Der Fokus auf Retrievalmodelle senkt die Komplexität eines solchen Systems enorm. Damit sollte den Lernenden der Einstieg leichter fallen als bei Systemen wie IR-Components, die den kompletten Retrieval Prozess abbilden und deshalb auch die Kenntnisse mehrerer Schnittstellen vorraussetzen. Außerdem werden alle Experimente auf Server-Seite durchgeführt, was den Aufwand der Lernenden für die Ein-richtung erheblich reduziert. Für jede Testkollektion existiert eine Rangliste (siehe Abbildung 3.5) mit den zehn besten Retrievalmodellen. Die Nutzer können ihre eigenen Retrievalmodelle mit diesen vergleichen.

Abbildung 3.5: VIRLab - Rangliste mit verschiedenen Korpora und Retrieval-Funktionen (Yang, 2015)

90

Ein weiterer Aspekt, der durch VIRLab adressiert wird, ist das schwierige Um-feld zur Nutzung von Testkollektionen. Viele Kollektionen bzw. deren Doku-mente sind urheberrechtlich geschützt und können nicht frei verwendet oder weitergegeben werden. Meist ist eine Vereinbarung zwischen Herausgeber und Nutzer zu schließen, die die Nutzung auf bestimmte Personen bzw. Bereiche und Nutzungsarten einschränkt. Darüber hinaus können für eine Nutzung auch Bearbeitungsentgelte, Versandkosten oder weitere Kosten anfallen.16

Durch die „Privacy-Preserving Evaluation“, also eine Evaluation, die im Ein-klang mit den Datennutzungslizenzen steht, wird das klassische Modell der Evaluation im Information Retrieval angepasst. Die Testkollektion bzw. die Daten werden nicht mehr zum Standort des Algorithmus transportiert, sondern der Algorithmus wird am Standort der Daten ausgeführt. Dadurch ergeben sich zwei Vorteile: Die Datenmenge für den Algorithmus ist im All-gemeinen kleiner als die einer Testkollektion, sodass die Übertragungszeit stark reduziert werden kann. Außerdem wird damit ein direkter Zugriff auf die Inhalte unterbunden. (Fang & Zhai, 2014)

Daraus ergaben sich drei Problemfelder: Die Algorithmen müssen auf dem Evaluationssystem, mit dem ein Zugriff auf die Daten gewährleistet wird, ausführbar sein. Die Autoren stellen hier den Fall, dass die Verantwortung für die Ausführbarkeit ausschließlich beim Nutzer liegt, dem Fall, dass diese vollständig beim System und deren Administratoren liegt, gegenüber. Das Optimum ist eine faire Verteilung der Verantwortung auf beide Parteien. VIRLab arbeitet deshalb mit einem angepassten Verfahren basierend auf der „Dynamic Code Generation“ von Engler und Proebsting (1994). Dabei wird der übermittelte C-ähnliche Quellcode (siehe Abbildung 3.6) in nativen C/C++ Code übersetzt, kompiliert und ausgeführt. Durch das eingesetzte Ver-fahren wird eine erheblich höhere Geschwindigkeit erreicht, als dies bei einer Interpretersprache der Fall wäre.

16 http://www.nist.gov/tac/data/forms/index.html (24. Juni 2015)

91

Abbildung 3.6: VIRLab - Eingabemaske für eine Retrieval-Funktion (Yang, 2015)

Durch die Verschiebung des Schwerpunktes vom Retrievalmodell hin zu nicht-öffentlichen Testkollektionen rücken zudem alle Komponenten eines Information Retrieval Systems in den Fokus. So ist es nicht mehr ausrei-chend, dass lediglich das Retrievalmodell angepasst werden kann, sondern auch alle anderen Komponenten, wie z.B. die Vorverarbeitung und die Indi-zierung, müssen anpassbar und vor allem auch evaluierbar sein. Dies soll in zukünftigen Versionen durch eine verstärkte Modularisierung von VIRLab realisiert werden.

Das dritte und letzte Problemfeld betrifft die Präsentation der Ergebnisse. Evaluationsmetriken und deren Durchschnittswerte geben ggf. zu wenige Informationen preis, die für eine Verbesserung einer Retrievalkomponente notwendig wären. Deshalb ist auch hier eine Ausgewogenheit der Interessen des Nutzers und der Interessen der Rechteinhaber der Testkollektion zu verfolgen. Insbesondere der Umfang und die Detailtreue der Ergebnislisten (siehe Abbildung 3.7), die dem Nutzer präsentiert werden können, sind zu berücksichtigen. Neben den Ranglisten der zehn besten Retrievalmodelle pro Testkollektion existiert auch eine Baseline, die gewissermaßen eine un-tere Schranke darstellt. Darüber hinaus kann der Umfang des notwendigen Datenschutzes von Kollektion zu Kollektion angepasst werden. So ist es bei einigen Kollektionen möglich, einzelne Terme anzuzeigen, sofern die Doku-mente daraus nicht rekonstruiert werden können. Wenn dies nicht gestattet ist, dann ist eine Ersetzung durch Platzhalter möglich. Weiterhin könnten spezielle Testkollektionen zur diagnostischen Evaluation zum Offenlegen von Problemen eines Retrievalmodells genutzt werden.

92

Abbildung 3.7: VIRLab - Ergebnislistenvergleich mit Dokumententiteln, die durch neutrale Bezeichner ersetzt wurden (Yang, 2015)

Die Verwendung einer an C angelehnten Sprache zur Implementierung der Retrievalmodelle kann für C-Einsteiger problematisch sein, da Konzepte enthalten sind, die im reinen C so nicht existieren. Allgemein richtet sich dieses System wahrscheinlich an Informatiker, da vorrausgesetzt wird, dass die Algorithmen programmiert werden müssen. Aus den Publikationen ist nicht ersichtlich, in welchem Maße eine zusätzliche Betreuung der Lernen-den notwendig ist. Obwohl eine Evaluation durchgeführt werden kann, ist die gewählte Darstellung zum Vergleich verschiedener Retrievalmodelle nur für kleine Kollektionen geeignet, da lediglich die Ergebnislisten verglichen werden. Hier wäre eine zusätzliche Visualisierung, z.B. in Form eines Preci-sion-Recall-Diagramms, hilfreich.

3.3.8 Soekia

Die Lernumgebung Soekia17 ist ein eigenständiges Java-Programm, das Schülern die Funktionsweise von Suchmaschinen näher bringen soll. Die Software erlaubt den Nutzern das Indizieren von HTML-Dateien, eine

17 http://www.swisseduc.ch/informatik/soekia/ (4. Dezember 2015)

93

Inspektion des entstandenen Index und die Suche darin. Neben der Software gibt es auf der dazugehörigen Webseite Unterrichtsmaterialien, welche einen Leitfaden für Lehrpersonal, verschiedene Aufgaben und Test-Korpora um-fassen. Die Aufgaben enthalten Arbeitsschritte und anknüpfende Fragen, die durch das Explorieren und Verändern der Arbeitsschritte beantwortet werden können.

Abbildung 3.8: Soekia - Links: Hauptfenster mit den verschiedenen Einstellungsmöglichkeiten (SwissEduc, 2014); Rechts: Ausgabe

der Indexdetails als HTML-Seite (SwissEduc, 2014)

Die Indizierung selbst kann durch Einstellungen im Hauptfenster angepasst werden. Für die beiden Sprachen Deutsch und Englisch steht jeweils eine mitgelieferte Stoppwortliste zur Verfügung, die jedoch nicht eingesehen werden kann. Der Nutzer kann ebenso eigene Stoppwörter ausprobieren. Die Einstellung Wortstamm-Reduktion dient zur Konfiguration des Stemmings und bietet als Optionen „deaktiviert“ und „pseudo-linguistisch“. Im Fall von Englisch entspricht dies dem Porter-Stemmer und für das Deutsche wird eine einfache Entfernung von Suffixen vorgenommen. Nach der Erstellung des Index kann dieser in Form einer generierten HTML-Seite detailliert

94

betrachtet werden. Auf der HTML-Seite sind alle Terme mit den Dokumenten, die diese Terme enthalten, und der Häufigkeit in den einzelnen Dokumenten aufgelistet.

Laut Jurjevic, Stöcklin und Hartmann (2009) wurde die Lernumgebung in ver-schiedenen Klassen der Sekundarstufe bis zur Fachhochschule eingesetzt und hat in Tests gezeigt, dass sie das Verständnis der Funktionsweise von Suchmaschinen steigert. In einer Unterrichtseinheit wurden vier bis sechs Aufgaben nach einer kurzen Erläuterung durch den Lehrer selbstständig von den Lernenden bearbeitet.

Suchanfragen werden nach einer Unterrichtssequenz mit Soekia besser und zielgerichteter formuliert und die Effizienz und Effektivi-tät bei Recherchen steigt merklich. (Jurevic et al., 2009, S. 323)

Soekia zeigt den Information Retrieval Prozess im Kleinen. Die Lernumge-bung eignet sich nur für kleine Kollektionen und die Auswahl an möglichen Einstellungen ist gering. Werkzeuge zur Evaluation der Retrievalergebnisse fehlen vollständig. Die Suchanfragen können nur einzeln und manuell einge-ben werden. Die Ergebnisse werden in Form einer sehr einfach formatierten HTML-Seite ausgegeben. Eine Visualisierung zur Unterstützung des Ent-deckungsprozesses fehlt ebenfalls. Es wird vielmehr auf die Beobachtung einzelner Aspekte der Retrievalergebnisse und der erzeugten Indizes Wert gelegt, z.B. wie verändert sich der Index durch den Einsatz des Stemmings (Wortstamm-Reduktion), d.h. es wird im Begleitmaterial explizit darauf hin-gewiesen, bestimmte Worthäufigkeiten zu kontrollieren. Diese Fokussierung auf einzelne Aspekte und die Reduktion des Information Retrieval Prozesses auf sehr wenige Komponenten sind durch die Eignung für den Schulunter-richt jedoch ausreichend begründet.

95

3.3.9 Fazit

Verschiedene Lernumgebungen legen den Fokus auf unterschiedliche As-pekte des Information Retrievals. INSTRUCT (Kapitel 3.3.1) und IR Game (Ka-pitel 3.3.2) stellen die Formulierung hochwertiger Suchanfragen in den Mit-telpunkt. IR-Toolbox (Kapitel 3.3.3), IR-BASE (Kapitel 3.3.4), IR-Components (Kapitel 3.3.5) und SulaIR (Kapitel 3.3.6) sind den Retrievalkomponenten gewidmet. VIRLab (Kapitel 3.3.7) erlaubt die Implementierung eigener Retrie-valmodelle und Soekia (Kapitel 3.3.8) kombiniert einige Retrievalkomponen-ten und die Formulierung von Suchanfragen auf einem einfachen Niveau.

Obwohl viele Lernumgebungen sich mit Retrievalkomponenten auseinan-dersetzen, fehlt jedoch die Evaluation. Lediglich IR Game, IR-Toolbox und VIRLab enthalten Möglichkeiten, um die Ergebnisse der Experimente objektiv zu bewerten. Weiterhin stellen einige Lernumgebungen hohe Anforderungen an die Nutzer, da hier Programmierkenntnisse vorausgesetzt werden. Damit sind diese Lernumgebungen nur für den Einsatz in Informatik-Studiengängen geeignet.

97

4 Implementierung

Im ersten Teil dieses Kapitels wird das Xtrieval Framework vorgestellt. Dessen stetige Weiterentwicklung ermöglichte die Teilnahmen an mehreren Evaluationskampagnen mit wechselnden Schwerpunkten. Basierend auf dem Xtrieval Framework wird im zweiten Teil eine webbasierte Lernumge-bung, das Xtrieval Web Lab, entwickelt. Es erlaubt die Konstruktion von Re-trievalexperimenten durch eine individuelle Anordnung von vorhandenen Re-trievalkomponenten. Evaluationsmetriken und Visualisierungen helfen, das Zusammenwirken der Komponenten sichbar zu machen und zu verstehen.

4.1 Xtrieval Framework

Um die Teilnahme an unterschiedlichen CLEF-Tracks effizienter zu gestalten, wurde an der Professur Medieninformatik der Technischen Universität Chem-nitz ein Retrievalframework mit dem Namen Xtrieval Framework entwickelt, das diesen wechselnden Anforderungen gerecht wird. Das Xtrieval Frame-work ist kein eigenständiges Information Retrieval System, sondern es inte-griert existierende Systeme, wie Apache Lucene (Kapitel 3.1.2) und Terrier (Kapitel 3.1.3). Es stellt jedoch eine Infrastruktur (siehe Abbildung 4.1) zum effizienten Einlesen von Dokumenten, zur Durchführung von Experimenten und deren Evaluation zur Verfügung. Darüber hinaus können Lösungen aus den unterstützten System so kombiniert werden, dass die Schwächen eines Systems durch eine entsprechende Komponente eines anderen Systems ausgeglichen werden können. (vgl. Kürsten & Wilhelm, 2008)

98

Abbildung 4.1: Übersicht Xtrieval Framework - Testkollektion und Integration von Apache Lucene & Terrier

4.1.1 Entwicklungsabschnitte

Die Entwicklung des Xtrieval Frameworks kann in vier Abschnitte unterteilt werden, die jeweils durch die in diesem Zeitraum durchgeführten Experi-mente und die daraus resultierenden Anforderungen geprägt sind. Nach den ersten Experimenten war die Notwendigkeit eines wiederverwendbaren, flexiblen Frameworks ersichtlich. In den folgenden Jahren kamen neue Funk-tionen hinzu und Schnittstellen wurden vereinfacht, um eine breite Verwend-barkeit sicherzustellen. Schließlich standen Komponenten und hilfreiche Visualisierungen der Evaluationsergebnisse im Vordergrund.

99

4.1.1.1 Die ersten Versuche

Im Jahr 2006 nahm die Professur Medieninformatik der Technischen Univer-sität Chemnitz erstmalig am Cross Language Evaluation Forum (CLEF) teil. Zwei Tracks wurden bearbeitet: Das Domain Specific Adhoc Retrieval und die ImageCLEF Bildersuche unterstützt durch Metadaten. Für die Teilnahme an beiden Tracks wurde ein gemeinsames Programm entwickelt, das auf Basis von Apache Lucene die Durchführung und eine einfache Evaluation ermöglichte.

Es entstanden zwei wichtige Werkzeuge: Ein hochgradig flexibler Lucene Analyzer, der für die Textvorverarbeitung und Normalisierung genutzt wird, und eine grafische Benutzungsoberfläche zur Evaluation der Ergebnisse. Die hohe Flexibilität des Analyzers für Lucene erlaubte es, ihn für beide Tracks anzupassen und zu verwenden. Er unterstützte die Auswahl des Snow-ball-Stemmers und der Stoppwörter und setzte darüber hinaus bewährte Lucene-Techniken wie den StandardTokenizer und den LowerCaseFilter ein.

Für das Domain-Specific Adhoc Retrieval war die Ausgangssituation in dem Sinne vorteilhafter, da bereits Relevanzbewertungen für Suchanfragen aus dem Vorjahr vorlagen und so das System bereits vorab entsprechend eva-luiert werden konnte. Obwohl es für 2006 neue Suchanfragen gab, konnte dennoch die Funktionsfähigkeit des Systems überprüft und die Güte der ausgewählten Ansätze abgeschätzt werden.

Der ImageCLEF Track zur Bildersuche setzte dagegen eine neue Kollektion ein, für die zu diesem Zeitpunkt keine Relevanzbewertungen vorlagen. Deshalb war die Entwicklung der grafischen Benutzungsoberfläche für diesen Track ein zentrales Element, da sie insbesondere Werkzeuge zur Verfügung stellte, die eine schnelle Relevanzbewertung von Bildern und Textdokumenten ermöglichten. Mithilfe der Benutzungsoberfläche konn-ten die bekannten Suchanfragen genutzt werden, um aus den möglichen

100

Systemkonfigurationen die besten, aber auch die unterschiedlichsten, für die Einreichung auszuwählen.

4.1.1.2 Vom Programm zum Framework

Auf der Grundlage der Erfahrungen aus der Teilnahme an CLEF 2006 wur-de die Benutzungsoberfläche weiterentwickelt. Außerdem sollte Apache Lucene seine zentrale Rolle im System verlieren, damit das System auch auf andere Retrieval Systeme zurückgreifen kann. Im Rahmen der Diplomarbeit von Wilhelm (2008) entstand die erste Version des Frameworks, jedoch war Apache Lucene noch das einzige unterstützte Information Retrieval System.

Unter der Leitung von Jens Kürsten entwickelten zwei Studenten prototypi-sche Implementierungen für Terrier und Lemur. Beide Umsetzungen waren jedoch nicht von hoher Qualität, was vor allem an den stark unterschiedli-chen Konzepten von Apache Lucene, Terrier und Lemur lag. Deshalb war die erste Integration von Terrier noch mit vielen Behelfslösungen durchzogen. Die Integration von Lemur krankte vor allem an der schlechten Java API, die für das in C++ implementierte Lemur nur einen beschränkten Zugriff ermög-lichte und eine parallele und damit schnelle Verarbeitung verhinderte.

Beide Integrationen führten zu einer Besonderheit des Xtrieval Framework: Durch die Trennung von Indizierung und Suche von der Vorverarbeitung war es nun möglich, Lucene Tokenizer und TokenFilter in Verbindung mit Terrier zu verwenden. So können die besten Komponenten aus beiden System mit-einander kombiniert werden.

Durch die erste Integration von Terrier wurden jedoch Schwächen im Frame-work sichtbar, die in der darauffolgenden Version behoben werden konnten. Die Geschwindigkeit sowie die Einstellungsmöglichkeiten für Terrier wurden erheblich verbessert und ermöglichten es, auf die Vielzahl an Retrievalmo-dellen, die Terrier von Apache Lucene absetzen, zuzugreifen.

101

4.1.1.3 Komponentenbasierte Evaluation

In seiner Dissertation „A Generic Approach to Component-Level Evaluation in Information Retrieval“ von Kürsten (2012) war die Verwendung und die Erweiterung des Xtrieval Frameworks ein zentraler Aspekt. Er argumentiert für eine Verlagerung des Untersuchungsgegenstandes von kompletten Sys-temen, wie es durch das Cranfield-Paradigma etabliert wurde, zu einzelnen Komponenten, um die Wirkungsweisen und Zusammenhänge dieser Kompo-nenten besser untersuchen und verstehen zu können.

Ein Vergleich auf Systemebene ist aufgrund der Vielzahl an Komponenten, die seit Beginn von TREC und anderen Evaluationskampagnen entstanden sind, überholt. Ein direkter Vergleich von Komponenten ist wegen der oft sehr unterschiedlichen Ausgangssituationen bei den eingesetzten Systemen schwer oder gar nicht möglich. Zwar werden bei konkreten Evaluationssze-narien die gleichen Daten verwendet, jedoch ist ein tatsächlicher Vergleich zweier Komponenten nicht möglich, wenn ein System auf der Basis von Apache Lucene arbeitet und ein anderes mit Terrier. Die entwickelten Kom-ponenten können zwar jeweils messbare Verbesserungen bewirken, jedoch gelten diese nur für die entsprechenden Ausgangssituationen. Eine Generali-sierung dieser Verbesserung auf andere Systeme muss nicht gegeben sein.

Die Teilnahme an Grid@CLEF 2009 (Eibl & Kürsten, 2009) lieferte erste Ein-blicke in die komplexen Zusammenhänge zwischen Stemmern und Gewich-tungsmodellen. Insbesondere die Unterschiede zwischen deutschen, engli-schen und französischen Dokumenten sind hervorzuheben. Leider führte die mangelnde Beteiligung zur Einstellung des Grid@CLEF Tracks.

Im Rahmen seiner Dissertation führte Kürsten (2012) diese Ansätze fort und entwickelte ein groß angelegtes Szenario, um die Zusammenhänge und Wechselwirkungen zwischen bestimmten Komponenten zu untersuchen. Neben den Komponenten wurden auch die Evaluationskorpora variiert, um

102

eventuell Abhängigkeiten zwischen Art des Korpus und Performance der Komponenten zu bestimmen.

Folgende Komponenten wurden untersucht:

– Stemming: 4-Gram, 5-Gram, Porter, Krovetz und UeaLite18

– Feedback: Bo219 und KLCorrect– Retrievalmodelle: Lucene, TF/IDF, BM25, Dirichlet, Hiemstra,

BB2, IFB2, In_expB2, DPH, DLH12, LGD und DFI0

Einige Komponenten waren darüber hinaus parametrierbar. Vor allem die Feedback-Komponenten waren auf eine Angabe zur zu untersuchenden Anzahl von Dokumenten und zur Menge der zurückzuliefernden Dokumente angewiesen. Diese Parameter erhöhten die Komplexität in hohem Maße.

Es kamen folgende Korpora zum Einsatz (vgl. auch Tabelle 4.1):

– TREC Disk 4 & 520, ohne Congressional Record– CLEF TEL-BL (vgl. Larson, 2010)– CLEF GIRT-4 (vgl. Kluck, 2002)

Korpus Anzahl Dokumente

Durchschnittliche Dokumentlänge

TREC Disc 4 & 5 (bestehend aus Financial Times, Federal Register, Foreign Broadcast IS, LA Times)

528.155 498

CLEF TEL-BL 1.000.100 31

CLEF GIRT-4 151.319 50

Tabelle 4.1: Korpusgrößen von TREC Disc 4 & 5, CLEF TEL-BL und CLEF GIRT-4 (Kürsten, 2012)

18 vgl. Jenkins und Smith (2005)19 vgl. Amati und Rijsbergen (2002)20 vgl. http://trec.nist.gov/data/qa/T8_QAdata/disks4_5.html (1. Januar 2016)

103

Durch diese Vielzahl von Variablen, die letztendlich das Systemergebnis beeinflussen, entstanden 13.176 individuelle Systemkonfigurationen, die mithilfe der existierenden Testkollektionen getestet werden konnten. Zur Durchführung dieser Menge von Experimenten war es zwingend erforderlich, dass die Experimente mit dem Xtrieval Framework automatisiert konfiguriert und durchgeführt werden konnten.

Abbildung 4.2: Compeval - Oben: Selektion der Komponenten; Unten: Anzeige der Ergebnisse als Parallele Koordinaten

Das Werkzeug Compeval (Wilhelm, Kürsten & Eibl, 2011 und Kürsten, Wilhelm & Eibl, 2011) ermöglicht eine explorative Auseinandersetzung mit den Parametern und den daraus resultierenden Ergebnissen (vgl. Abbildung 4.2). Durch die Kombination von Komponenten bzw. Komponentenklassen, Parametern und Ergebniswerten in einen Vektor und die Darstellung mithilfe

104

von parallel Koordinaten können Abhängigkeiten beobachtet werden. Weite-re interaktive Elemente, wie die Selektion von Komponenten und Einfärbung entsprechend der ausgewählten Metrik, unterstützen bei der Erkundung der Daten. Compeval bietet hierfür eine umfangreiche Importfunktion, die teils automatisiert, teils durch manuelle Ergänzungen die Daten für die Darstel-lung aufbereitet. Beim Importieren kann die Reihenfolge der Achsen verän-dert werden. Dies ist ein besonders wichtiges Feature, da die Exploration der Daten stark von der Reihenfolge der ausgewählten Achsen abhängig ist. Selektierte Datensätze können ebenfalls exportiert und mithilfe von anderen Werkzeugen weiter untersucht werden.

4.1.1.4 Parallele Verarbeitung und Vereinfachung der API

Die wichtigsten Ziele für diese Phase des Xtrieval Frameworks waren höhere Indizier- und Suchgeschwindigkeiten, die vor allem durch Verbesserungen bei der parallelen Verarbeitung der Daten erreicht werden sollten, und eine Vereinfachung der API, um den Einstieg leichter zu gestalten und die Lesbar-keit der Programme und Funktionen zu verbessern. Da der Indizierungs- und Suchprozess weitestgehend von externen Bibliotheken, wie Apache Lucene oder Terrier, durchgeführt wird, konzentrierten sich die Parallelisierungsbe-mühungen auf das effiziente Einlesen und Parsen von XML-Dokumenten. Es entstand ein Parser-Framework auf der Basis der Java-Klasse Path. Die Path-Klasse ermöglichte vor allem eine transparente Verarbeitung von ZIP-Dateien, wodurch diese nicht mehr gesondert behandelt werden muss-ten, sondern wie normale Verzeichnisse traversiert werden konnten.

Der vorhandene XML-Parser, der die Dokumente und deren Felder bereits mithilfe von XPath-Ausdrücken in die interne Document-Klasse umwandelte, wurde nochmals einer Revision unterzogen. Außerdem wurden verschiede-ne XPath-Frameworks bezüglich ihrer Geschwindigkeit und Flexibilität hin

105

untersucht. Letztendlich wurde Jaxen21 ausgewählt, da es schnell und kom-patibel zum Standard-Java DOM-Parser war. Andere Implementierungen für XPath in Java, die in Betracht gezogen wurden, jedoch vor allem unter dem Gesichtspunkt der Flexibilität ausgeschieden sind, waren JAXP22, VTD XML23 und JXPath24.

Zusätzliche Parser, die im Zuge der Einführung des Parser-Frameworks implementiert wurden, waren ein HTML-Parser und ein PDF-Parser. Der HTML-Parser setzt mit Jsoup25 auf eine Mischung aus DOM, CSS- und JQuery-Selektoren zur Auswahl von zu indizierenden Inhalten. Beim PDF-Par-ser kommt PDFBox26 zum Einsatz, das leider nicht immer die gewünschte Stabilität und Ergebnisse lieferte. Gründe dafür sind die überaus hohen Varianzen an PDF-Versionen, Formaten und Eigenschaften, wie z.B. die Verschlüsselung.

Als Retrieval Engines standen Apache Lucene 4.3, Terrier 3.0 und Apache Solr27 zur Verfügung. Die Kommunikation zwischen dem Xtrieval Framework und Apache Solr lief über das HTTP-Protokoll mittels JSON. Die Indizierung und die Suche durch Apache Solr war jedoch nicht so flexibel konfigurierbar, wie bei Apache Lucene und Terrier. Die Einstellungen für die Komponenten zur Indizierung und zur Suche konnten ausschließlich in der Apache Solr Konfiguration verändert werden und konnten nicht mithilfe des Xtrieval Frameworks automatisiert werden. Letztendlich war die Anbindung von Apache Solr nur ein Beispiel für die Flexibilität des Xtrieval Frameworks und hatte nur einen geringen praktischen Wert, da Apache Solr selbst Apache Lucene als Retrieval Engine einsetzt.

21 http://jaxen.org/ (10. Januar 2016)22 https://xml.apache.org/xalan-j/xpath_apis.html (17. November 2015)23 http://vtd-xml.sourceforge.net/ (17. November 2015)24 https://commons.apache.org/proper/commons-jxpath/ (17. November 2015)25 http://jsoup.org/ (17. November 2015)26 https://pdfbox.apache.org/ (17. November 2015)27 http://lucene.apache.org/solr/ (19. November 2015)

106

Die Komplexität des Frameworks wurde im Vergleich zu den vorhergehen-den Versionen stark reduziert (siehe Tabelle 4.2). Zur besseren Wartbarkeit wurden die Evaluationsmetriken in eigenständige Klassen ausgelagert. Das Experiment entwickelte sich zur Steuerzentrale für die Indizierung, Suche und Evaluation. Korpora, Topics, verschiedene Indizierungs- und Suchmodu-le, Evaluationmetriken und Exportmodule (z.B. für treceval) werden in einem Experiment zusammengefasst und können durch einen Funktionsaufruf in Gang gesetzt werden.

Version / Jahr

Basis-Framework Hilfsklassen & -interfaces

Interfaces Klassen Interfaces Klassen

2007 1 14 - -

2008 8 12 1 9

2011 10 12 1 4

2014 6 3 4 6

Tabelle 4.2: Übersicht Anzahl Interfaces und Klassen in den Xtrieval Framework Versionen

4.1.2 Anwendungsfälle

Im Folgenden werden Anwendungen des Xtrieval Frameworks in unter-schiedlichen Evaluationskampagnen dokumentiert. Durch die Heterogenität der Testkollektionen und der Retrievalszenarien wurden stets neue Anforde-rungen an das Xtrieval Framework sichtbar, die zur Reifung des Framework beitrugen.

4.1.2.1 ImageCLEF 2006

Wie in Wilhelm und Eibl (2006) beschrieben, lag der Fokus für die erste Teilnahme am ImageCLEF Photographic Retrieval Task auf der Entwicklung eines zukunftsfähigen Systems zur Durchführung und Evaluation von Infor-mation-Retrieval-Versuchen. Die Testkollektion basierte auf dem IAPR TC-12

107

Benchmark, der 20.000 touristische Fotografien mit Annotationen in den Sprachen Englisch, Deutsch und Spanisch umfasst (vgl. Grubinger, Clough, Müller & Deselaers, 2006). Die Annotationen beinhalteten einen Titel, eine textuelle Beschreibung des Bildinhalts und bei einigen Bildern Hintergrund-informationen zu enthaltenen Sehenswürdigkeiten. Die 60 Suchanfragen lagen in insgesamt 16 verschiedenen Sprachen vor, darunter waren auch die drei Sprachen der Dokumente. Für die ersten Tests mit dem neuen System wurden nur monolinugale Experimente in Englisch durchgeführt.

Das Baseline-Experiment „tucEEANT“ verwendete den StandardTokenizer von Lucene, den Snowball-Stemmer für Englisch und die entsprechenden Stoppwörter aus dem Snowball-Projekt. Das Topicfeld „title“ wurde in den Dokumentfeldern „title“, „location“, „description“ und „notes“ gesucht, das Topicfeld „narr“ nur in den Dokumentfeldern „description“ und „notes“.

Für das Experiment „tucEEAFT“ wurde zusätzlich ein einfaches Blind-Rele-vance-Feedback-Verfahren implementiert, das auf der Basis von Kennzahlen des Lucene Index zusätzliche Terme zur Suchanfrage hinzufügte. Hierfür wurden die ersten 20 Ergebnisse pro Suchanfrage verwendet. Nach einer Wiederholung der Suche mit den erweiterten Suchanfragen lagen die endgül-tigen Ergebnisse vor.

Das Experiment „tucEEAFT2“ fügte einen weiteren Query-Expansion-Schritt vor dem eben beschriebenen Feedback ein. Für diese Query-Expansion wurde die Tatsache ausgenutzt, dass die zu jeder Topic gegebenen Beispiel-bilder im Korpus enthalten waren. Es wurden die drei Beispielbilder im Index gesucht und aus ihnen möglicherweise relevante Terme extrahiert und für die Query-Expansion verwendet. Nach einem ersten Suchdurchlauf wurde das gleiche Feedback wie bei „tucEEAFT“ angewendet.

Als letztes eingereichtes Experiment wurden für „tucENAFTI“ Farbhisto-gramme (Hue, Saturation, Brightness) für alle im Korpus enthaltenen Bilder erstellt und im Index in einer Textrepräsentation hinterlegt. Da ein Vergleich

108

aller 20.000 Bilder mit den drei Beispielbildern mit den eingesetzten Metho-den sehr zeitaufwendig gewesen wäre, wurde nur ein Reranking der bereits durch die Textsuche gefundenen Dokumente vorgenommen. Als Vergleichs-maß diente die euklidische Distanz zwischen zwei Farbhistogrammen. Der errechnete Wert ging mit einer Gewichtung von 30% in den Gesamtscore der Dokumente ein.

Die Ergebnisse der vier Experimente sind in Tabelle 4.3 zu finden. Das Ergebnis des Experiments tucEEAFT2 mit Query-Expansion und Blind-Re-levance-Feedback zeigte eine klare Verbesserung gegenüber der Baseline. Bei dem Experiment tucEEAFT mit einfachem Blind-Relevance-Feedback ist der Anstieg weniger ausgeprägt, aber dennoch sichtbar. Dass zusätzlich ein Reranking der Suchergebnisse erfolgte, wie es in tucEEAFTI vorgenommen wurde, zeigt nur noch eine Verbesserung an der dritten Nachkommastelle und ist angesichts des hohen Verarbeitungs- und Zeitaufwands nicht praktikabel.

Rank EN-EN

Rank ALL

Bezeichnung Modalität Feedback Query Expansion

MAP

5 16 tucEEAFT2 Text ja ja 0,2417

17 33 tucEEAFTI Mixed ja nein 0,1856

18 34 tucEEAFT Text ja nein 0,1830

23 47 tucEEANT Text nein nein 0,1708

Tabelle 4.3: Übersicht der Ergebnisse bei ImageCLEF 2006 (Wilhelm & Eibl, 2006)

Als Fazit wurde festgestellt, dass die bildbasierte Komponente weiterentwi-ckelt und verbessert werden muss.

4.1.2.2 ImageCLEF 2007

Im darauffolgenden Jahr setzten Wilhelm, Kürsten und Eibl (2007) mehrere neue Techniken ein, jedoch ist die Evaluation nicht umfassend genug, um auf

109

deren Wirkungsgrad gesicherte Rückschlüsse zu ziehen. Außerdem wurden 2007 neben monolingualen Experimenten in Englisch auch weitere Sprachen hinzugefügt und darüber hinaus bilinguale Experimente durchgeführt. Der ImageCLEF 2008 Photografic Retrieval Task war vor allem durch die Entfer-nung des Description-Feldes aus dem Korpus gekennzeichnet. Es enthielt eine umfassende, textuelle Beschreibung des Bildes und hatte deshalb auch einen hohen Stellenwert für das Textretrieval.

Dieser Verlust an wertvollen Informationen sollte durch eine Query-Ex-pansion auf der Basis eines Thesaurus ausgeglichen werden. Für alle drei Korpussprachen (Englisch, Deutsch und Spanisch) wurde der OpenOffice.org Thesaurus verwendet, um verwandte Begriffe zu bestimmen. Um dies effizient durchzuführen, wird zu Beginn ein Index für den Thesaurus erstellt, der dann bei der Verarbeitung der Suchanfragen verwendet wird, um diese zu erweitern.

Anstatt der Farbhistogramme von 2007 wurden MPEG-7-Deskriptoren aus dem Caliph & Emir Projekt von Lux, Klieber und Granitzer (2004) eingesetzt, um die Bilder besser miteinander vergleichen zu können. Die durch Caliph & Emir berechneten Deskriptoren wurden ebenso im Lucene Index gespeichert und bei der Suche mit den Deskriptoren der Beispielbilder verglichen. Um die Deskriptoren im Index ablegen zu können, war jeweils eine textuelle Reprä-sentation notwendig, die Caliph & Emir bei folgenden Deskriptoren liefern konnten: Edge Histogram und Scalable Color. Der Dominant Color Deskriptor konnte zwar mittels Caliph & Emir berechnet, aber nicht als Text gespeichert und rekonstruiert werden.

Im Gegensatz zu 2006 waren die Beispielbilder nicht mehr im Korpus enthal-ten, sodass deren Annotationen nicht für eine Query-Expansion verwendet werden konnten. Da dieser Ansatz aber im vorherigen Jahr zu den besten Ergebnissen geführt hatte, wurde er für 2007 an die vorliegenden Bedin-gungen angepasst. Anstatt ungeprüft die ersten 20 Suchergebnisse für das Feedback zu verwenden, wurde auf ein manuelles Feedback gesetzt. D.h. die

110

Benutzungsoberfläche des Xtrieval Frameworks wurde so angepasst, dass unter den ersten 20 Suchergebnissen alle relevanten Bilder ausgewählt und in einem zweiten Suchlauf für die Erweiterung der Suchanfragen eingesetzt wurden. Diese Query Expansion führte z.B. bei der Suchanfrage 39: „people in bad weather“ (auf deutsch: „Leute in schlechtem Wetter“) zu einer Er-weiterung mit „rain coat“, was für diese Suchanfrage zu einer signifikanten Verbesserung der Ergebnisse führte.

Die monolingualen Experimente zeichneten bereits ein überraschendes Bild (siehe Tabelle 4.4). Für die englische Sprache waren die Ergebnisse signifi-kant schlechter als für Deutsch oder Spanisch, wobei Spanisch das beste monolinguale Experiment-Ergebnis erzielte, mit einer beinahe doppelt so hohen Mean Average Precision wie bei der englischen Sprache.

Experiment MAP P@20 Platzierung

cut-ES2ES 0,2772 0,3708 12

cut-DE2DE 0,1991 0,2992 40

cut-EN2EN 0,1515 0,2383 142

Tabelle 4.4: Monolinguale Experimente ohne Feedback bei ImageCLEF 2007 (Wilhelm, Kürsten & Eibl, 2007)

Tabelle 4.4 zeigt die deutliche Verbesserung der Ergebnisse durch das manuelle Feedback. Beim Experiment cut-EN2EN-F20 wurden die ersten 20 Bilder der Ergebnisliste von Hand bewertet, bei cut-EN2EN-F50 die ersten 50 Bilder. Die Überprüfung der ersten 20 Ergebnisbilder einer Suchanfrage auf relevante Treffer dauert nur wenige Sekunden und trägt dennoch stark zum Ergebnis bei. Der Sprung von 20 bewerteten Bildern zu 50 ist hingegen nicht mehr so signifikant und steht in keinem guten Verhältnis zum dafür notwen-digen Mehraufwand.

111

Experiment MAP P@20 Platzierung

cut-EN2EN-F50 0,3175 0,4592 1

cut-EN2EN-F20 0,2846 0,4025 5

cut-EN2EN 0,1515 0,2383 142

Tabelle 4.5: Monolinguale Experimente in Englisch mit und ohne Feedback bei ImageCLEF 2007 (Wilhelm, Kürsten & Eibl, 2007)

Die Ergebnisse der sechs bilingualen Experimente sind in Tabelle 4.5 zu sehen. Als Baseline ist hier das Experiment „cut-EN2EN-F20“ angegeben. Es steht für die Verwendung der englischen Suchanfrage auf einen englischen Index mit einem manuellen Feedback für die ersten 20 Ergebnisbilder. Bei allen anderen Experimenten wurden die Suchanfragen mithilfe von Google Translate28 in die jeweilige Sprache des verwendeten Korpus bzw. Index übersetzt. Alle vier Experimente, die die englische Dokumentensammlung verwendeten, erzielten passable Ergebnisse mit Mean Average Precisions von 0,2690 (chinesische Kurzzeichen) bis 0,2432 (französisch). Der Unter-schied zum monolingualen Experiment liegt hier lediglich bei 0,0414 bzw. bei einer Reduktion um 14,5%.

Für die beiden anderen Experimente mit jeweils einmal einem deutschen und einem spanischen Korpus fehlen entsprechende Baseline-Experimente. Sie können nur mit den entsprechenden Experimenten ohne manuellem Feed-back verglichen werden. Bei der Kombination von englischen Suchanfragen und spanischem Korpus liegt das Ergebnis auf dem gleichen Niveau, wie das monolinguale, spanische Experiment. Für das Experiment mit franzö-sischen Suchanfragen und den deutschen Dokumenten war eine deutliche Verschlechterung festzustellen. Tabelle 4.6 zeigt, dass die Mean Average Precision von 0,1991 (monolinual, deutsch) auf 0,1640 (französische Suchanfragen, deutsche Dokumente) fiel.

28 https://translate.google.com/ (4. Januar 2015)

112

Experiment MAP P@20 Platzierung

cut-EN2EN-F20 0,2846 0,4025 5

cut-EN2ES-F20 0,2770 0,3767 13

cut-ZHS2EN-F20 0,2690 0,4042 19

cut-DE2EN-F20 0,2565 0,3650 22

cut-IT2EN-F20 0,2495 0,3633 28

cut-FR2EN-F20 0,2432 0,3583 31

cut-FR2DE-F20 0,1640 0,2367 100

Tabelle 4.6: Bilinguale Experimente bei ImageCLEF 2007 (Wilhelm, Kürsten & Eibl, 2007)

Insgesamt konnte bei der Teilnahme bei ImageCLEF 2007 gezeigt werden, dass das Xtrieval Framework geeignet war, eine Vielzahl an Experimenten effizient zu konfigurieren und durchzuführen. Vor allem die unkomplizierte Wiederverwendbarkeit der Komponenten ermöglichte ein breites Spekt-rum an Experimenten. Durch die grafische Benutzungsoberfläche wurde die Möglichkeit für ein manuelles Feedback geschaffen, was in der Praxis einen Aufwand von wenigen Sekunden verursacht, dafür aber einen hohen Gewinn für die Mean Average Precision bedeutet. Die tatsächliche Leis-tungsfähigkeit der Thesaurus-Komponente konnte nicht ermittelt werden, da die Baseline-Experimente für die einzelnen Sprachen fehlten. Dies ist der Tatsache geschuldet, dass nur eine begrenzte Anzahl an Experimenten zur Einreichung zugelassen war und darüber hinaus keine weiteren Experimente durchgeführt wurden.

4.1.2.3 ImageCLEF 2008

Im Jahr 2008 wurden bei ImageCLEF zwei ähnliche Tasks durchgeführt: der Photographic Retrieval Task und der Wikimedia MM Task. Der Pho-tographic Retrieval Task entspricht weitestgehend dem aus dem Jahr 2007 und befasst sich mit gut annotierten Fotos aus einem touristischen Kontext. Im Wikimedia MM Task wird ein größerer Korpus mit Bildern mit

113

unterschiedlichen Themen verwendet. Sie sind meist nicht so gut und aus-führlich annotiert wie die des Photographic Retrieval Tasks und erfordern deshalb ein anderes Vorgehen.

Photographic Retrieval Task

Der ImageCLEF Photographic Retrieval Task war im Jahr 2008 wieder durch eine drastische Reduktion der Daten gekennzeichnet. In diesem Jahr stan-den nur noch ein englisches und ein deutsch/englisch-gemischtes Korpus und eine reduzierte Teilmenge (39 von ursprünglich 60) der englischen Suchanfragen zur Verfügung.

Um die Ergebnisse der Vorjahre weiter zu verbessern und das System zu beschleunigen, speicherten Wilhelm, Kürsten und Eibl (2008a) die mittels Caliph & Emir (vgl. Lux, Klieber & Granitzer, 2004) berechneten MPEG-7-De-skriptoren nicht mehr im Lucene-Index, sondern in einer PostgreSQL-Daten-bank. Neben einer effizienteren Verarbeitung, konnte auf diese Weise auch der Dominant-Color-Deskriptor verwendet werden, da die entsprechenden Variablen der Java-Klasse in PostgreSQL repräsentiert werden konnten. Um die Suche weiter zu beschleunigen, wurden Vergleichsfunktionen als Stored Procedures direkt in PostgreSQL implementiert. Diese Stored-Procedures konnten dank eines direkten Zugriffs auf die Datenbank mehr Datensätze in kürzerer Zeit verarbeiten, als eine entsprechende Java-Implementierung, die jeden Datensatz über eine API aus der Datenbank lesen musste.

Die Ergebnisse (siehe Tabelle 4.7) zeigen ein ähnliches Bild wie 2006. Die Einbeziehung der Bildinformationen im Ranking führen zu einer allgemeinen Verbesserung der Mean Average Precision. Ebenso führt die Anwendung der Query Expansion auf Basis des OpenOffice.org Thesaurus zu einer Verbes-serung der Mean Average Precision und Geometric Mean Average Precision. Jedoch ist die Verbesserung nicht im gleichen Maße in Kombination mit den MPEG-7-Deskriptoren sichtbar. Hier führt die Query Expansion sogar zu einer

114

niedrigeren Mean Average Precision als bei der alleinigen Anwendung der MPEG-7-Deskriptoren.

Experiment Modalität Query Expansion

MAP GMAP

cut-txt Text nein 0,0998 0,0162

cut-txt-qe Text ja 0,1081 0,0300

cut-mix Text & Bild nein 0,1364 0,0177

cut-mix-qe Text & Bild ja 0,1140 0,0275

Tabelle 4.7: Ergebnisse ImageCLEF 2008 Photographic Retrieval Task (Wilhelm, Kürsten & Eibl, 2008a)

Wikipedia MM Task

Der ImageCLEF 2008 Wikipedia MM Task ist dem Photographic Retrieval Task sehr ähnlich. Das Korpus ist größer und umfasst etwa 150.000 Bilder mit unterschiedlichen Thematiken. Diese Bilder sind mit XML-Daten anno-tiert, die jedoch keiner festgelegten Struktur folgen. Zusätzlich wurde zu jedem Bild ein 120-dimensionaler Feature-Vektor erzeugt und eine Klassifi-zierung in Konzepte vorgenommen.

Wie bereits im Photographic Retrieval Task wurde von Wilhelm, Kürsten und Eibl (2008b) das Xtrieval Framework mit seiner neuen Komponente für den Zugriff auf eine PostgreSQL-Datenbank eingesetzt. Ebenso wurden für alle Bilder die MPEG-7-Deskriptoren mithilfe von Caliph & Emir (vgl. Lux, Klieber & Granitzer, 2004) berechnet und zusammen mit dem 120-dimensionalen Vek-tor in der Datenbank gespeichert. Die Annotationen und die zugeordneten Konzepte wurden in einem Apache Lucene Index abgelegt.

Alle Annotationen waren in englischer Sprache. Zur Vorverarbeitung der Annotationen kamen eine Stoppwort-Entfernung und der Snowball-Stemmer zum Einsatz. Die Suchanfragen wurden ebenso vorverarbeitet. Zusätzlich

115

wurde die Query Expansion aus den Experimenten für den Photographic Retrieval Task basierend auf dem OpenOffice.org Thesaurus verwendet.

Experiment Modalität Query Expansion

MAP

cut-txt-a Text nein 0,2166

cut-mix Text, Bild nein 0,2138

cut-mix-qe Text, Bild ja 0,2195

cut-mix-concepts Text, Bild, Konzepte

nein 0,2048

Tabelle 4.8: Ergebnisse ImageCLEF 2008 Wikipedia MM Task (Wilhelm, Kürsten & Eibl, 2008b)

Wie Tabelle 4.8 zeigt, hat die Verwendung der MPEG-7-Deskriptoren und des 120-dimensionalen Vektors das Ergebnis negativ beeinflusst. Wahr-scheinlich sind die Bilder in diesem Korpus für einen so einfachen Ansatz zu heterogen. Die ausgeprägten Unterschiede zwischen relevanten Bildern zu einer Suchanfrage sind bereits bei der Durchführung der Relevanzbewertung aufgefallen.

Die Verwendung der Query Expansion mithilfe des Thesaurus führte zur ein-zigen Verbesserung im Ergebnis. Der Anstieg der Mean Average Precision von 0,2138 auf 0,2195 ist jedoch nur sehr gering.

4.1.2.4 CLEF-IP 2011

Im Jahr 2011 bildeten die Technische Universität Chemnitz und die Univer-sität Hildesheim ein Team für die Teilnahme am CLEF Intellectual Property Track (CLEF-IP). Die Zusammenarbeit ist in Becks et al. (2011) dokumentiert und wird im Folgenden zusammengefasst wiedergegeben.

116

Das Ziel beim Prior Art Candidate Search Task ist das Auffinden von bereits registrierten Patenten, die einen Patentantrag betreffen oder die Neuwertig-keit der darin beschriebenen Erfindung in Frage stellen könnten. Als Korpus wurden Auszüge aus dem MAREC Dataset verwendet. Zusammen ergeben die 1,3 Millionen Patente des European Patent Office (EPO) in englischer, deutscher und französischer Sprache und weitere Dokumente der World Intellectual Property Organization (WIPO) über 2,6 Millionen durchsuchbare Dokumente. Die Topics setzen sich aus Patentanträgen ohne deren Patent-literatur zusammen. Es wurden zwei Topicsets zur Verfügung gestellt: Ein Trainings-Set bestehend aus etwa 300 Topics und deren Relevanzbewertun-gen und ein Test-Set bestehend aus über 3000 Topics. Beide Sets enthielten jeweils in gleichen Anteilen deutsche, englische und französische Dokumen-te. Alle Dokumente lagen in Form von XML-Dokumenten in einem ZIP-Archiv vor.

Es wurde wieder das Xtrieval Framework zur Zusammenstellung der Expe-rimente verwendet. Der Umfang des Korpus machte weitere Optimierungen beim Einlesen von XML-Dokumenten notwendig. Die in Kapitel 4.1.1.4 beschriebenen Tests zur Auswahl eines geeigneten XML-Parsers und einer geeigneten XPath-Implementierung wurden anhand des CLEF-IP Korpus durchgeführt, da hier die Geschwindigkeit der Indizierung ein entscheidender Faktor bei der Optimierung der Komponentenparameter war.

Obwohl alle in den Dokumenten enthaltenen Felder mit einer Sprache an-notiert waren, war diese Angabe nicht immer korrekt. Deshalb wurde diese Zuordnung beim Indizieren mithilfe der Language Detection Library for Java von Shuyo (2010) überprüft. Falls die Detektion mit einer hohen Sicherheit eine andere Sprache anzeigte, wurde die annotierte Sprache entsprechend angepasst. Dies war notwendig, da bei der weiteren Verarbeitung sprachab-hängige Komponenten, wie z.B. eine Stoppwort-Entfernung und ein regelba-siertes Stemming, verwendet wurden.

117

Durch vorherige Experimente haben Becks, Womser-Hacker, Mandl und Kölle (2009) und Becks, Mandl und Womser-Hacker (2010) bereits die Notwen-digkeit einer umfassenden Stoppwortliste festgestellt. Vor allem Wörter wie „Patent“ und „Erfindung“ sind in allen Dokumenten enthalten und führen bei einer Suche zu vielen Treffern, die die Ergebnisliste unnötig verlängern. Des-halb wurde zusätzlich zu einer allgemeinen Stoppwortliste eine speziell für das Patentretrieval entwickelte Stoppwortliste eingesetzt. Sie basierte auf den Erfahrungen, die die Hildesheimer Forschergruppe bei ihrer Teilnahme in den Vorjahren sammeln konnte. Als Stemming-Komponenten kamen die für die jeweilige Sprache passenden Snowball-Stemmer zum Einsatz.

Ein weiterer Ansatz um die Retrievaleffektivität, aber auch -effizienz zu erhö-hen, war die an der Universität Hildesheim entwickelte Phrasenextraktion auf Grundlage einer lexikonunabhängigen Analysekomponente basierend auf Apache UIMA29 und Apache OpenNLP30. Für die Teilnahme an CLEF-IP 2011 stand diese Phrasenextraktion nur für die englische Sprache zur Verfügung. Durch die Verwendung von Phrasen anstatt der vollständigen Dokumente für die Generierung der Suchanfragen wird die Verarbeitungszeit für die Suche drastisch reduziert. Wie in Becks et al. (2011) aufgeführt entsprach die Ausführungszeit für das umfangreichste Experiment (bow-desc) etwa 11 Stunden. Im Gegensatz dazu benötigten die Suchen basierend auf der Phrasenextraktion durchschnittlich nur eine Stunde.

Jedes Patent und jeder Patentantrag ist mit einem oder mehreren IPC Codes (International Patent Classification31) versehen, welche die unterschiedlichen Fachrichtungen, wie z.B. Chemie oder Physik, und die unterschiedlichen Technologiebereiche spezifizieren. Da die IPC eine sehr feingliedrige Klassifi-zierung ist, wurden lediglich die ersten Ebenen genutzt, um Patente in grobe Technologiebereiche einzuteilen. Diese grobe Klassifizierung diente bei der

29 https://uima.apache.org/ (1. Dezember 2015)30 https://opennlp.apache.org/ (1. Dezember 2015)31 http://www.wipo.int/classifications/ipc/en/preface.html (1. Dezember 2015)

118

Suche als vorgelagerter Filter, der den Suchraum einschränkt und so zu einer Beschleunigung des Suchvorgangs beiträgt.

Es wurden insgesamt sieben Experimente eingereicht (siehe Tabelle 4.9). Vier Experimente basierten auf den Verfahren, die seit 2006 an der TU Chemnitz entwickelt worden waren. Hierbei wurden alle drei Sprachen be-rücksichtigt, die im Korpus Verwendung fanden. Drei Experimente nutzten die Phrasenextraktion der Universität Hildesheim für die Formulierung der Suchanfrage. Hierbei wurden ausschließlich die englischen Bestandteile der Dokumente verwendet. Alle Experimente verwendeten den selben Index und unterschieden sich nur in der Erzeugung der Suchanfragen.

Die Experimentbezeichner setzen sich wie folgt zusammen:

– bow: Es wird ein Bag of Words Ansatz verwendet, d.h. abstract, title und claims werden in einem Indexfeld abgelegt.

– desc: Das Feld description wurde zusätzlich in das Bag of Words Indexfeld übernommen.

– ipcr: Ein Teil des IPC Codes wird im Index ge-speichert und bei der Suche verwendet.

– en-abstract: Für die Suche werden Terme aus dem Feld description des Patents bzw. Patentantrages extrahiert und verwendet.

– en-p: Aus den Feldern abstract und title wer-den Phrasen für die Suche extrahiert.

– en-p-abstract: Bei der Suche wird ein Kombina-tion aus en-p und en-abstract verwendet.

Beim Patentretrieval gehört der Recall (Vollständigkeit) zu den wichtigsten Metriken. Zur Prüfung eines Patentantrages müssen alle relevanten Patente gefunden werden, da ein nicht gefundenes Patent möglicherweise genau das Patent sein kann, das den Antrag auf Grund von Prior Art ungültig wer-den lässt. Das Experiment „bow“ erzielt hierbei einen besseren Recall, aber eine schlechtere Mean Average Precision als das Experiment „bow-desc“,

119

das zusätzlich das Beschreibungsfeld (description) für die Formulierung der Suchanfrage verwendet.

Experiment Recall MAP P@5 P@10

bow 0,4318 0,0824 0,1028 0,0751

bow-desc 0,3993 0,0914 0,1170 0,0833

bow-desc-ipcr 0,3993 0,0914 0,1170 0,0833

bow-ipcr 0,4318 0,0824 0,1028 0,0751

bow-en-abstract 0,4303 0,0580 0,0717 0,0541

bow-en-p 0,1899 0,0208 0,0282 0,0209

bow-en-p-abstract 0,3694 0,0446 0,0562 0,0428

Tabelle 4.9: Ergebnisse CLEF-IP 2011 Prior Art Candidate Search Task (Becks et al., 2011)

Die Verwendung des Beschreibungsfeldes (description) verändert die Ge-schwindigkeit der Suche drastisch, von knapp 2 Stunden auf 11 Stunden für alle 4000 Suchanfragen. Durch die Filterung anhand der IPC Codes kann diesem Effekt etwas entgegengewirkt werden. So dauerte die Suche durch die Kombination von IPC Codes und Beschreibung vier Stunden. Die einfache Suche ohne Beschreibung war die schnellste mit 17 Minuten.

Becks et al. (2011) vermuten, dass der Abstrakt nicht besonders gut für die Phrasenextraktion geeignet ist, da hier tendenziell störende Wörter vorkom-men, die das Patent weniger scharf beschreiben. Da die Experimente, die die Beschreibung (description) verwenden, eine bessere Mean Average Preci-sion als alle anderen Experimente erzielt haben, könnten Phrasen, die auf der Beschreibung (description) basieren, möglicherweise bessere Ergebnisse erzielen.

120

4.1.2.5 CLEF-IP 2012

Im folgenden Jahr wurde beim CLEF-IP Claims to Passage Task der Schwie-rigkeitsgrad erhöht, indem es nicht mehr nur darum ging, das entsprechende Patent zu identifizieren, sondern auch die betreffende Passage zu benennen. Das Ziel von Wilhelm, Kürsten und Eibl (2012) für die Teilnahme in diesem Jahr war vor allem, das Xtrieval Framework weiter zu entwickeln, insbeson-dere die Geschwindigkeit, aber auch die Konfiguration von Komponenten und deren Evaluation zu verbessern und zu vereinfachen.

Aus diesem Grund waren die Experimente nur wenig komplex und enthielten keine ungewöhnlichen und neuen Komponenten. Um einzelne, relevante Passagen zu identifizieren, wurde ein ähnliches Verfahren wie von Schmidt, Körner, Heinich und Wilhelm (2011) eingesetzt, das auf zwei Retrieval-Schrit-ten basierte. Neben einem Index, der die vollständigen Patentdokumente umfasste, wurde ein weiterer Index angelegt, der jede einzelne Passage als separates Dokument behandelte.

Die Problematik der mit falscher Sprache annotierten Felder wurde ähnlich wie im Vorjahr mithilfe der Spachenerkennung von Shuyo (2010) gelöst, jedoch wurde die Menge der unterstützten Sprachen auf Englisch, Deutsch, Französisch, Russisch, Italienisch und Spanisch erweitert. Für jede dieser Sprachen gab es eine separate Verarbeitungskette mit sprachspezifischen Komponenten. Die Verarbeitungsketten bestanden aus den folgenden Komponenten:

– StandardTokenizer von Apache Lucene (zerlegt Zeichenketten in Tokens/Wörter)

– LowerCaseFilter von Apache Lucene (wandelt Großbuchstaben in Kleinbuchstaben um)

– RemoveShortWordsFilter (entfernt alle Wörter mit weniger als drei Buchstaben)

121

– StopFilter von Apache Lucene (entfernt Stoppwörter basierend auf den Stoppwortlisten des Snowball Projekts32)

– RemoveNumbersFilter (entfernt verschiedene Formate von Zahlen, jedoch keine Zahlwörter)

– SnowballFilter von Apache Lucene (führt eine Wortstammreduzie-rung mithilfe der Snowball-Stemming-Programme entsprechend der erkannten Sprache durch)

Es wurden drei Experimentabläufe implementiert und getestet. Sie unter-scheiden sich im Zugriff auf die Indizes und in der Reihenfolge des Zugriffs.

– Nur Passagen (Bezeichnung: p)Es wurde ausschließlich im Index mit den Passagen als Dokumen-ten gesucht. Da diese Konfiguration die einfachste ist und auf die wenigsten Ressourcen zugreift, ist sie die Baseline und alle anderen Konfigurationen müssen sich an ihr messen lassen.

– Dokumente und Passagen parallel (Bezeichnung: dp)Nach der Suche in beiden Indizes wurden beide Ergebnislisten zum Endergebnis zusammengeführt.

– Erst Dokumente, dann Passagen (Bezeichnung: d2-p)Vergleichbar mit den zwei Schritten, die von Schmidt, Körner, Heinich und Wilhelm (2011) für Sprach-Transkripte und die darin enthalte-nen Äußerungen verwendet wurden. Es werden zuerst relevante Dokumente identifiziert und für einen weiteren Suchdurchgang für die Passagen verwendet.

Um der Mehrsprachigkeit des Korpus Rechnung zu tragen, wurden alle Top-ic-Dokumente in die Sprachen Deutsch, Englisch und Französisch übersetzt. Das Korpus enthält zwar darüber hinaus viele weitere Sprachen, jedoch ist

32 http://snowball.tartarus.org/ (3. Dezember 2015)

122

ein Großteil aller Dokumente in einer dieser drei Sprachen verfasst. Für die Übersetzung wurde im Vorfeld Google Translate verwendet. Die Übersetzun-gen wurden gespeichert, sodass sie bei allen Experimenten identisch sind.

Experiment Dokumentsuche Absatzsuche

PRES@100 Recall@100 MAP MAP(D) Precision(D)

tuc-d2-p 0,1599 0,2094 0,0663 0,0385 0,0490

tuc-p 0,1430 0,1941 0,0501 0,0314 0,0522

tuc-dp 0,1363 0,1854 0,0424 0,0254 0,0383

tuc-dpmt 0,1363 0,1854 0,0424 0,0254 0,0383

tuc-d2-pmt 0,1218 0,1599 0,0614 0,0257 0,0297

tuc--pmt 0,0936 0,1428 0,0246 0,0167 0,0323

Tabelle 4.10: Ergebnisse CLEF-IP 2012 Claims to Passage Task (Wilhelm, Kürsten & Eibl, 2012)

Die Ergebnisse in Tabelle 4.10 zeigen, dass die Baseline, also die einfachste Konfiguration, das zweitbeste Ergebnis geliefert hat. Lediglich das Experi-ment, in dem erst nach den Dokumenten und im zweiten Schritt nach den Passagen gesucht wurde, konnte bei der Dokumentensuche und bei der Mean Average Precision der Passagensuche besser abschneiden. Die Pre-cision auf Passagenebene war dennoch bei dem Baseline-Experiment am besten. Die Übersetzung der Topic-Dokumente hat zu keiner Verbesserung der Ergebnisse geführt.

Verglichen mit allen anderen Teilnehmern war das Ergebnis dennoch sehr zufriedenstellend, da die besten Experimente nur von den Experimenten der Fachhochschule Westschweiz (Genf) übertroffen wurden (vgl. Piroi, 2012). Weitere Teilnehmer waren die Universität Hildesheim, die Università della Svizzera italiana (Lugano), die University of Macedonia (Thessaloniki) und die Technische Universität Wien.

123

4.1.2.6 CHiC 2013

Im Zuge der Integration von Apache Solr in das Xtrieval Framework testeten Wilhelm-Stein, Schürer und Eibl (2013) die verschiedenen Stemmer, die in Apache Solr zur Verfügung stehen, im CHiC (Cultural Heritage in CLEF) 2013 Track. Das CHiC-Korpus zeichnet sich durch die Vielfalt an Sprachen, die in ihm enthalten sind, aus. Außerdem lagen die Suchanfragen in 13 verschie-denen Sprachen vor. Die Organisatoren von CHiC 2013 wiesen ausdrücklich darauf hin, dass eine maschinelle Übersetzung der Suchanfragen nicht not-wendig ist und alle 13 Sprachen gleichzeitig verwendet werden dürfen (vgl. Petras, Bogers, Ferro und Masiero, 2013).

Da die Sprache (wie auch bei CLEF-IP 2011 und 2012) eine wichtige Rolle spielt, wurde wieder die Komponente zur Sprachenerkennung nach Shuyo (2010) eingesetzt, um ggf. falsch zugeordnete Sprachattribute zu erkennen und zu korrigieren. Neben dem Test der Integration von Apache Solr war es das Ziel, einen guten Stemmer bzw. eine gute Stemmer-Sammlung für mög-lichst viele Sprachen zu identifizieren. Deshalb wurden die in Apache Solr verfügbaren Stemmer in vier bzw. fünf Kategorien eingeteilt:

– Apache Solr Standard-Stemmer (std)– Snowball-Stemmer33 (sb)– HunSpell-Stemmer34 (hs)– Less-Aggressive-Stemmer (la)– kein Stemmer (no)

Problematisch war jedoch, dass nicht alle Stemmer für alle Sprachen zur Ver-fügung standen. Folgende Sprachen wurden dabei nicht von allen Stemmern unterstützt oder es traten Probleme bei der Durchführung der Experimente auf:

33 http://snowball.tartarus.org/ (3. Dezember 2015)34 https://wiki.apache.org/solr/HunspellStemFilterFactory (3. Dezember 2015)

124

– Niederländisch: kein Less-Aggressive-Stemmer– Finnisch: kein HunSpell-Stemmer– Französisch: sehr langsamer HunSpell-Stemmer– Polnisch: langsamer HunSpell-Stemmer, kein Snowball- und

Less-Aggressive-Stemmer– Slowenisch: langsamer HunSpell-Stemmer, kein Standard-, Snow-

ball- und Less-Aggressive-Stemmer, d.h. es ist gar kein Stemming möglich

– Italienisch: langsamer HunSpell-Stemmer– Griechisch: kein Snowball- und Less-Aggressive-Stemmer, außer-

dem gab es Probleme mit dem Zeichensatz (trotz Unterstützung von UTF-8 usw.)

Bei folgenden Sprache entsprach der Standard-Stemmer von Apache Solr dem Snowball-Stemmer: Niederländisch, Finnisch, Spanisch, Schwedisch, Norwegisch und Ungarisch. Nur für die italienische Sprache war es der Less-Aggressive-Stemmer. Falls ein zu testender Stemmer für eine bestimm-te Sprache nicht verfügbar war, so wurde der Standard-Stemmer von Apache Solr verwendet.

Stemmer MAP GMAP BPref R-Precision

Solr Standard 0,2583 0,1603 0,3538 0,3329

Less Aggressive 0,2590 0,1552 0,3686 0,3253

HunSpell 0,2466 0,1314 0,2914 0,3160

Snowball 0,2604 0,1591 0,3576 0,3360

kein Stemmer 0,2684 0,1587 0,3031 0,3444

kein Stemmer undohne Stoppwort-Entfernung 0,1597 0,0621 0,2251 0,2297

Tabelle 4.11: Ergebnisse der zusätzliche Experimente CHiC 2013 Multilingual Task

Die Ergebnisse in Tabelle 4.11 zeigen, dass die Verwendung eines Stemmers keine Vorteile bietet. Dies ist jedoch nicht in der Leistungsfähigkeit der ein-zelnen Stemmer begründet, sonder hängt viel mehr mit dem verwendeten

125

Korpus zusammen. Das CHiC-Korpus setzt sich vor allem aus Namen und Titeln von Kunstwerken zusammen. Diese Namen durch ein Stemming zu verändern, erhöht nur die Unschärfe bei der Suche und führt ganz natürlich zu schlechteren Ergebnissen. Trotz des schwierigen Korpus hat sich eine Komponente als außerordentlich effektiv erwiesen: die Stoppwortentfer-nung. In Tabelle 4.11 ist ebenfalls das Ergebnis ohne die Verwendung eines Stemmers und ohne die Entfernung der Stoppwörter enthalten.

4.1.2.7 Weitere Anwendungsfälle

Neben den oben beschriebenen Anwendungsfällen kam das Xtrieval Frame-work bei zahlreichen anderen Experimenten zum Einsatz, die nicht primär vom Verfasser dieser Arbeit durchgeführt wurden, aber dennoch das Xtrieval Framework verwendeten. Der Domain-Specific Track und TEL@CLEF sind klassische Retrievalprobleme mit dem Zusatz der Mehrsprachigkeit. Die ASR Klassifizierung im VideoCLEF Track und die Teilnahme am Question Answer-ing on Speech Transcriptions Track wichen von diesem klassischen Retrieval bereits ab, bereicherten aber das Xtrieval Framework. Und für die erste Teil-nahme an CHiC (siehe auch Kapitel 4.1.2.6) wurde eine Komponente für eine semantische Anreicherung (Semantic Enrichment) entwickelt.

Domain-Specific Track von CLEFBasierend auf dem GIRT-4 Korpus (vgl. Kluck, 2002) wurden zahlreiche, mehrsprachige Experimente von Kürsten und Eibl (2007a, 2007b) und Kürs-ten, Wilhelm und Eibl (2007, 2008, 2009b) durchgeführt.

TEL@CLEFDie Integration von Lemur (Kapitel 3.1.4) und eine neue Übersetzungskom-ponente für das Xtrieval Framework wurden von Kürsten, Wilhelm und Eibl (2009a) und Kürsten (2009) in 69 Experimenten getestet.

126

Question Answering on Speech Transcriptions (QAst) Track von CLEFMit vier eingereichten Experimenten erzielten Kürsten, Kundisch und Eibl (2008) eine Genauigkeit von etwa 20%, jedoch war dabei der Anteil unbeant-worteter Fragen zu hoch.

VideoCLEF Track: ASR ClassificationNachdem im Vorjahr Kürsten, Richter und Eibl (2009) nur mäßige Ergebnisse erzielten, konnten Kürsten und Eibl (2010) mithilfe des Xtrieval Frameworks und der Interpretation der Klassifizierung als Information Retrieval Problem gute Ergebnisse erzielen.

Cultural Heritage in CLEF (CHiC)Durch die semantische Anreicherung der Suchanfragen konnten Kürsten, Wilhelm, Richter und Eibl (2012) die Ergebnisse nicht verbessern.

Unterstütztung des Content-Based Image Retrievals durch EmotionenIn ihrer Dissertation entwickelte Schneider (o.J.) eine Software zur Annota-tion von Bildern mit Daten zu Emotionen, die aus den Bildinhalten abgeleitet werden. Anhand mehrerer Experimente mit dem Datensatz des ImageCLEF Photographic Retrieval Tasks konnte eine leichte Verbesserung der Retrieval -ergebnisse durch die Einbeziehung der Emotionsdaten festgestellt werden. Diese Verbesserung war bei gleichzeitiger Verwendung der MPEG-7 Deskrip-toren (vgl. Kapitel 4.1.2.2) sogar signifikant.

4.1.3 Fazit

Die große Anzahl von Konfigurationen, die Kürsten (2012) verwendete, war nur durch eine Automatisierung des Xtrieval Frameworks möglich. Der Berechnungs- und Zeitaufwand für die Durchführung aller Experimente ist dennoch sehr hoch. Ein Rechenbeispiel: 13.000 Konfigurationen, die jeweils etwa eine Minute für die Erstellung und die Suche in einem Index benötigen, schlagen in der Summe mit etwa 9 Tagen Laufzeit zu Buche. Auch wenn

127

Kürsten diese Zeit reduzieren konnte, da mehrere Konfigurationen mit dem selben Index arbeiteten, besteht dennoch ein hoher Zeitaufwand, um alle Konfigurationen zu evaluieren.

Eine vergleichbare Evaluation anhand der CLEF-IP-Testkollektion mit dem Ziel, die beste Kombination aus Stemmer und Retrievalmodell zu bestim-men, würde etwa 36 Tage dauern (6 Stemmer und 12 Retrievalmodelle entsprechen 72 Konfigurationen bei 12 Stunden pro Experiment). Eine Über-prüfung der Feedbackmechanismen ist bei dieser Aufstellung noch gar nicht enthalten.

Es ist indessen nicht immer notwendig, alle möglichen Konfigurationen zu testen. Zum einen geben die Experimente von Kürsten (2012), aber auch viele andere Veröffentlichungen, die auf der Verwendung spezieller Korpora basieren, Hinweise, welche Konfigurationen mehr oder weniger gut geeignet sein können. Zum anderen können einzelne Experimente bereits Indizien liefern, wie eine Komponente insgesamt abschneidet, sodass nicht alle mög-lichen Kombinationen überprüft werden müssen. Etwas Fingerspitzengefühl auf der Seite des Experimentators könnte hier einen Unterschied machen. Dieser Prozess sollte durch ein Werkzeug unterstützt werden, das die Fle-xibilität des Xtrieval Frameworks und Visualisierungen zur Exploration der Ergebnisse besitzt.

4.2 Xtrieval Web Lab

Das Xtrieval Web Lab ist eine Webanwendung, die basierend auf dem Xtrieval Framework den Experimentier- und Evaluationsprozess so vereinfachen soll, dass er auch ohne Programmierkenntnisse angepasst und durchgeführt werden kann. Mithilfe der Weboberfläche können Experimente aus Kompo-nenten zusammengestellt und parametriert werden. Eine Vorschau der ver-arbeiteten Daten unterstützt den Nutzer bei der korrekten Parametrierung. Nachdem ein Experiment vollständig zusammengestellt wurde, werden alle

128

Einstellungen an den Server übertragen, der das Experiment dann ausführt und die Ergebnisse zurück an die Weboberfläche schickt. Durch unterschied-liche Visualisierungen kann der Nutzer die Ergebnisse explorieren. Anschlie-ßend können die Parameter erneut vom Nutzer verändert werden, um durch einen Vergleich der Ergebnisse Erkenntnisse über die Auswirkungen der Komponenten zu gewinnen.

Folgende Anforderungen werden an das Xtrieval Web Lab gestellt:

– Experimente werden aus Komponenten zusammengestellt.– Komponenten sind parametrierbar.– Eine Vorschau zeigt anhand eines Beispieldokuments,

wie die Komponenten die Daten manipulieren.– Vollständige, parametrierte Experimente werden durch-

geführt und die Ergebnisse übersichtlich angezeigt.

Darüber hinaus sollte das Xtrieval Web Lab folgende Eigenschaften besitzen:

– Die Durchführung von Experimenten ist so schnell, dass die Nutzer kontinuierlich mit der Webanwendung arbeiten können, damit der Experimentierfluss nicht unterbrochen wird.

– Möglichst viele Elemente der Simulation sollen flexibel angelegt sein, sodass durch einen geschulten Nutzer Anpassungen vorge-nommen werden können. Auch neue Inhalte sollen so erstellt wer-den können.

– Es ist auch auf kleinen Bildschirmen, z.B. von Smartphones oder Tablets, bedienbar.

Die Entwicklung des Xtrieval Web Labs ist durch die agile Softwareent-wicklung geprägt. Das Ziel der agilen Softwareentwicklung ist ein flexibler und effizienter Entwicklungsprozess, der mehr Wert auf die Entwicklung als iterativen Prozess legt, als auf detaillierte Planung. Die folgenden vier Stichpunkte geben die zentralen Werte des Manifesto for Agile Software

129

Development von Beck et al. (2001) wieder. Sie beschreiben das Ungleich-gewicht zwischen einem erstrebenswerten Zustand auf der einen Seite und dem damaligen Normzustand auf der anderen Seite:

– Individuals and interactions over processes and tools,– Working software over comprehensive documentation,– Customer collaboration over contract negotiation, and– Responding to change over following a plan. (Beck et al., 2001)

Dieser Entwicklungsprozess ist weiterhin durch eine flexible Planung und kurze Zyklen gekennzeichnet. Mithilfe von zahlreichen Prototypen wird der aktuelle Stand kontinuierlich mit den Wünschen der Auftraggeber und der Anwender abgeglichen.

4.2.1 Basistechnologien

Das Xtrieval Web Lab basiert ausschließlich auf Open-Source-Software. Im Sinne einer agilen Entwicklung wurden in zahlreichen Iterationen neben den im Folgenden aufgeführten Werkzeugen und Bibliotheken auch andere Lösungen getestet, die sich entweder als nicht geeignet herausstellten oder sich nicht in die bestehende Architektur einfügten.

Folgende Werkzeuge wurden zur Entwicklung des Xtrieval Web Labs verwendet:

– Java Development Kit 835 (OpenJDK, GNU GPL mit Linking Exception)Das JDK 8 ist die Vorraussetzung für viele verwendete Werkzeuge, darunter Gradle und Apache Lucene. Deshalb ist auch das Backend in Java implementiert.

35 http://openjdk.java.net/projects/jdk8/ (5. Dezember 2015)

130

– Gradle36 (Apache License 2.0)Das sehr flexible Buildsystem Gradle ermöglicht den Zugriff auf eine Vielzahl von externen Resourcen und Funktionen.

– Gretty37 (MIT License)Dieses Gradle-Plugin ermöglicht es, Webanwendungen komforta-bel in einem Java-Servlet-Kontainer (Jetty oder Apache Tomcat) auszuführen und bei Änderungen am Quellcode einen Redeploy durchzuführen.

– Gradle-mongo-plugin38 (sourcemuse, Apache License 2.0)Durch die Integration von MongoDB in den Buildprozess von Grad-le wird die Datenbank bei Bedarf automatisch zusammen mit der Webanwendung gestartet und beendet. Falls MongoDB nicht instal-liert ist, wird die für das Betriebssystem passende Version herunter-geladen und ausgeführt.

– Gradle-node-plugin39 (moowork, Apache License 2.0)Vergleichbar mit dem MongoDB Gradle-Plugin stellt dieses Plugin sicher, dass Node.js installiert ist oder lädt es selbstständig herun-ter. Unter Linux wird jedoch nur die Verfügbarkeit überprüft.

– Node.js40 (inkl. NPM41, MIT License)Der Paketmanager NPM von Node.js wird benötigt, um Bower und Less.js auszuführen.

36 http://gradle.org/ (5. Dezember 2015)37 https://github.com/akhikhl/gretty (5. Dezember 2015)38 https://github.com/sourcemuse/GradleMongoPlugin (5. Dezember 2015)39 https://github.com/srs/gradle-node-plugin (5. Dezember 2015)40 https://nodejs.org/en/ (5. Dezember 2015)41 https://www.npmjs.com/ (5. Dezember 2015)

131

– Bower42 (MIT License)Mittels Bower werden externe Abhängigkeiten (JavaScript- und CSS-Bibliotheken) des Frontends aufgelöst und installiert.

– Less�js43 (inkl. autoless44 und autoprefixer45, Apache License 2.0)Änderungen am LESS-Stylesheet des Frontends werden durch Less.js und den autoprefixer automatisch in CSS umgewandelt. Notwen-dige Prefixe für die letzten beiden Versionen der aktuellen Browser werden automatisch hinzugefügt.

– MongoDB46 (GNU AGPL v3.0)Als NoSQL-Datenbank ermöglicht MongoDB die persistente Spei-cherung von JSON-Objekten. Da sowohl das Frontend, als auch das Backend JSON für die Kommunikation und die Repräsentation der Daten verwenden, sind hier keine weiteren Schritte zur Umwandlung notwendig. Darüber hinaus kann durch elaborierte Datenbankab-fragen einfach auf die reichhaltigen Datenstrukturen zugegriffen werden.

Das Xtrieval Web Lab ist als Java-Servlet47 angelegt und besteht aus einem serverseitigen Teil und einer Weboberfläche. Auf der Serverseite wird mittels Jersey eine RestFUL API bereitgestellt, die der Weboberfläche den Zugriff auf Inhalte der Datenbank und zu den Experiment gewährt.

42 http://bower.io/ (5. Dezember 2015)43 http://lesscss.org/ (5. Dezember 2015)44 https://github.com/jgonera/autoless (5. Dezember 2015)45 https://github.com/postcss/autoprefixer (5. Dezember 2015)46 https://www.mongodb.org/ (5. Dezember 2015)47 http://www.oracle.com/technetwork/java/index-

jsp-135475.html (2. Januar 2016)

132

Zur Laufzeit des Xtrieval Web Labs werden serverseitig folgende Softwarebi-bliotheken verwendet:

– Project Nashorn48 (Bestandteil des OpenJDK 8)Dieser neue Bestandteil des JDK 8 unterstützt das Ausführen von JavaScript innerhalb der Java Runtime. Durch eine Kompilierung des JavaScript-Codes in Java Bytecode können die Optimierungen der Java Runtime in vollem Umfang ausgenutzt werden. Mehr zur Integration von Nashorn ist in Kapitel 4.2.3 nachzulesen.

– Java Stream API49 (Bestandteil des OpenJDK 8)Mithilfe der Java Stream API wurde die Verarbeitungskette, die die Grundlage für alle Experimente ist, implementiert. Weitere Informati-onen zur Verarbeitungskette sind in Kapitel 4.2.2 zu finden.

– Apache Lucene50 (Apache License 2.0)Auf der Basis der Erfahrungen aus den Vorjahren wurde Apache Lucene als erstes Retrievalsystem integriert. Vor allem die Ge-schwindigkeit und die vorhandenen Komponenten haben hierfür den Ausschlag gegeben. Mehr zu Apache Lucene ist in Kapitel 3.1.2 nachzulesen.

– Jersey51 (CDDL Version 1.1 und GPL v2 License)Mittels Jersey wird das Backend als RESTful Web Service unter-stützt. Neben einer einfachen Überführung von Java-Klassen und Methoden in eine RESTful API werden auch Datenumwandlungen - insbesondere von JSON in Java-Objekte und umgekehrt - transpa-rent durchgeführt.

48 http://openjdk.java.net/projects/nashorn/ (5. Dezember 2015)49 https://docs.oracle.com/javase/8/docs/api/java/util/

stream/package-summary.html (5. Dezember 2015)50 https://lucene.apache.org/ (5. Dezember 2015)51 https://jersey.java.net/ (5. Dezember 2015)

133

– Jongo52 (Apache License 2.0)Diese Bibliothek stellt eine komfortable Verbindung zur MongoDB her. Anfragen und Befehle können in der Mongo Anfragesyntax formuliert werden. Ebenso wird wie bei Jersey eine Konvertierung von Java-Objekten in JSON, also Mongo-Objekte, überführt werden. Umgekehrt werden die Daten aus der Datenbank als Java-Objekte zurückgeliefert und können so direkt verarbeitet werden.

– Nimbus Jose JWT53 (Apache License 2.0)Die Authentifizierung der Nutzer wird mittels JSON Web Tokens54 sichergestellt. Ein Token enthält neben der Identifizierung des Benutzers auch seine Berechtigungen. Der Inhalt des Tokens kann von jedem gelesen, aber nicht verändert werden. Da das Token vom Ausgeber signiert ist, kann nur dieser den Inhalt ändern und auch feststellen, ob der Inhalt unverändert ist.

– Jaxen55 (Apache-like License)Mithilfe von Jaxen können XML-Bäume anhand von XPath-Ausdrü-cken effizient in Java durchsucht werden. Diese Bibliothek besitzt einen erheblichen Geschwindigkeitsvorteil gegenüber der Stan-dard-Implementierung in Java (vgl. Kapitel 4.1.1.4).

Die Weboberfläche präsentiert sich als Singe-Page-Application, d.h. es wird eine einzelne Webseite geladen, die mittels JavaScript neue Inhalte nachlädt und zwischen ihnen wechselt. Die Anzeige bestimmter Inhalte wird intern als Zustand repräsentiert. Zwischen diesen Zuständen kann der Benutzer durch Interaktionen mit der Oberfläche wechseln. Dabei gibt es eine Hierarchie

52 http://jongo.org/ (5. Dezember 2015)53 https://bitbucket.org/connect2id/nimbus-jose-

jwt/wiki/Home (5. Dezember 2015)54 http://jwt.io/ (12. Dezember 2015)55 http://jaxen.org/ (5. Dezember 2015)

134

der Zustände, die beschreibt, wie einzelne Zustände auf Eigenschaften aus anderen Zuständen zugreifen können (siehe Abbildung 4.3).

Abbildung 4.3: Interne Zustände bzw. Ansichten der Weboberfläche und deren Vererbungshierarchie

Für die Weboberfläche wurden folgende JavaScript- oder CSS-Bibliotheken eingesetzt:

– CardinalCSS56 (MIT License)Als ein CSS Framework bildet es eine Grundlage für die Entwicklung eigener CSS Designs. Es ist modular aufgebaut und richtet sich nach dem Mobile First Gedanken, der auch in das Xtrieval Web Lab eingeflossen ist.

56 http://cardinalcss.com/ (5. Dezember 2015)

135

– AngularJS57 (MIT License)Dies ist ein JavaScript Framework zur Entwicklung von Webanwen-dungen. Es ist zentraler Bestandteil des Frontends.

– Angular UI Router58 (basierend auf AngularJS, MIT License)Der Angular UI Router ist ein Routing Framework für AngularJS, das auf dem Konzept von Zuständen basiert. Der Wechsel von einer Sei-te bzw. Ansicht zu einer anderen ist mit der Änderung des aktuellen Zustands verbunden.

– Angular UI CodeMirror59 (basierend auf CodeMirror60 und Angular-JS, MIT License)Komponenten, Metriken und Achievements arbeiten mit Java-Script-Code, der in der Weboberfläche bearbeitet werden kann. Um die Bearbeitung zu erleichtern, wird CodeMirror eingesetzt. Es un-terstützt neben Syntaxhighlighting auch das Einrücken von Blöcken.

– N3 Line Chart61 (basierend auf D3.js62 und AngularJS, MIT License)Zur Visualisierung der Ergebnisse wird diese Bibliothek eingesetzt. Sie ermöglicht vielfältige Diagramme, deren Darstellung zu einem hohen Grad angepasst werden kann.

– JSDiff63 (BSD License, 3-clause)Um Unterschiede zwischen einzelnen Verarbeitungsschritten her-vorzuheben, wurde diese JavaScript Implementierung eines Algo-rithmus nach Myers (1986) eingesetzt.

57 https://angularjs.org/ (5. Dezember 2015)58 https://github.com/angular-ui/ui-router (5. Dezember 2015)59 https://github.com/angular-ui/ui-codemirror (5. Dezember 2015)60 http://codemirror.net/ (5. Dezember 2015)61 https://github.com/n3-charts/line-chart (5. Dezember 2015)62 http://d3js.org/ (12. Dezember 2015)63 https://github.com/kpdecker/jsdiff (5. Dezember 2015)

136

4.2.2 Verarbeitungskette

Die in Abbildung 4.4 skizzierte Verarbeitungskette des Xtrieval Web Labs zeigt die Komponenten und Verbindungen zwischen diesen Komponenten innerhalb eines Experiments. Ein Experiment besteht aus einer geordneten Menge von Lanes, vergleichbar mit einer Fertigungsstraße. Jede Lane be-steht wiederum aus einer geordneten Menge von Komponenten, wobei die erste und die letzte Komponente spezielle Funktionen erfüllen. Jede Kompo-nente definiert einen Verarbeitungsschritt, d.h. durch eine Komponente wer-den Daten empfangen, verändert und an die nächste Komponente weiterge-geben. Für die Verarbeitung kann die Komponente auf Konfigurationsdaten und auf das Experiment selbst zugreifen.

Abbildung 4.4: Übersicht zum Aufbau der Verarbeitungsketten für ein Experiment im Xtrieval Web Lab

Die erste Komponente in einer Lane ist stets ein Supplier. Ein Supplier ist eine Quelle für Dokumente, Suchanfragen oder andere Daten. Dazu kann

137

er auf die Datasets aus der Datenbank zugreifen und alle darin enthaltenen Daten weitergeben, z.B. die Dokumente des Korpus oder die Suchanfragen aus einem Topicset.

Jede Lane wird durch einen Collector abgeschlossen. Er bündelt alle Daten, die bei ihm ankommen, in eine Ausgabe, die in einem Zwischenspeicher (Output) abgelegt wird. Alle Komponenten in nachfolgenden Lanes können auf die Daten im Zwischenspeicher zugreifen und sie für die Verarbeitung verwenden.

Am Beispiel des einfachen Information Retrieval Prozesses werden in der ersten Lane alle Dokumente in einen Index überführt, der in den Zwischen-speicher gelegt wird. Die zweite Lane bereitet die Suchanfragen vor und im letzten Schritt werden diese Suchanfragen auf den Index aus dem Zwischen-speicher ausgeführt. Das Ergebnis wird wieder in den Zwischenspeicher abgelegt.

Experimente können nur durchgeführt werden, wenn mindestens eine Lane mit einem Collector abgeschlossen ist. Wenn ein unvollständiges Experi-ment durchgeführt wird, werden die Ergebnisse aller vollständigen Lanes berechnet und zurückgegeben. D.h. bei einer vollständigen ersten Lane für die Indizierung kann bereits der Index erzeugt und inspiziert werden, ohne dass die zweite Lane für die Suche vollständig definiert sein muss.

Diese Organisation soll es ermöglichen, dass Xtrieval Web Lab zukünftig um eine oder mehrere Relevanzfeedback-Schleifen zu erweitern. Die Ausführung vollständiger Lanes bei unvollständigen Experimenten könnte ebenso die Grundlage für ein manuelles Relevanzfeedback bilden.

Nachdem ein Experiment vollständig ausgeführt wurde, werden die Metriken berechnet. Die Funktionen zur Berechnung der Metriken können dafür auf das gesamte Experiment zugreifen, insbesondere auf den Zwischenspei-cher (Output). Die finale Ergebnisliste ist ebenfalls als letztes Element im

138

Zwischenspeicher (Output) enthalten. Neben der Ergebnisliste werden von vielen Metriken auch die Relevanzbewertungen benötigt. Deshalb kann die Funktion zur Berechnung der Metrik auch auf das Dataset und ggf. auf das Topicset zugreifen.

Der letzte Schritt beim Ausführen eines Experiments ist die Berechnung der Achievements für einen Benutzer (User). Für jedes Achievement ist eine Funktion hinterlegt, die anhand des Experiments, dessen Konfiguration, des Zwischenspeichers (Output) und der berechneten Metriken bestimmt, ob und ggf. zu welchem Grad ein Achievement erreicht wurde. Diese Funktion wird jedoch nur ausgeführt, wenn ein Achievement noch gar nicht erreicht oder noch nicht der höchste Grad des Achievements erreicht wurde. Durch die Verwendung einer Funktion zur Bestimmung des Achievement-Gra-des können auch komplexe Zusammenhänge modelliert werden. Das Stopword-Achievement führt z.B. das Experiment ein zweites Mal mit deaktivierter Stopword-Removal-Komponente aus und vergleicht die Mean Average Precision mit der des ursprünglichen Experiments. Nur wenn der Unterschied zwischen beiden Werten einen bestimmten Schwellenwert über-steigt, werden die verschiedenen Stufen des Achievements freigeschaltet.

Achievement-Funktionen können weiterhin Daten über die Fortschritte eines Benutzers (Users) speichern und für spätere Überprüfungen verwenden. Z.B. wird die Stufe des Stemming-Achievements jedes Mal erhöht, wenn ein neuer Stemmer eingesetzt wird und die Mean Average Precision sich durch diesen Stemmer verbessert. Um zu vermeiden, dass die Verwendung des gleichen Stemmers mehrmals belohnt wird, werden bereits verwendete Stemmer in einer Liste gespeichert, um sie nicht noch einmal zu bewerten.

Der eben beschriebene Ablauf ist in Abbildung 4.5 als Sequenzdiagramm dargestellt. Es beginnt mit einer Änderung durch einen Anwender und endet mit der Übermittlung der Ergebnisse an ihn.

139

Abbildung 4.5: Sequenzdiagramm - Nutzer nimmt eine Änderung an einem Experiment vor

4.2.3 Flexible Komponenten durch JavaScript

Die Verwendung von Project Nashorn ermöglicht die Implementierung und Anwendung von Komponenten zur Laufzeit. Das heißt, alle Komponenten, die im Xtrieval Web Lab zur Verfügung gestellt werden, sind nicht im Pro-gramm selbst definiert, sondern in der Datenbank. Eine Komponente besteht hierbei aus einem Programm in Form von JavaScript und weiteren Eigen-schaften, die z.B. das Ein- und Ausgabeformat der Komponente beschreiben. In der Administrationsoberfläche können neue Komponenten angelegt oder

140

bestehende Komponenten bearbeitet werden, ohne dass das Xtrieval Web Lab neu gestartet werden muss.

JavaScript bietet sich zu diesem Zweck an, da es durch Project Nashorn sehr gut in die Java VM integriert ist und dort mit einer hohen Geschwindigkeit ausgeführt wird. Der Zugriff auf Klassen kann mit Project Nashorn effizient eingeschränkt werden, sodass nur Klassen verwendet werden können, die von der Anwendung explizit freigegeben wurden. Außerdem ist durch die hohe Verbreitung (vgl. Schmidt, 2014) anzunehmen, dass ein Administrator mit JavaScript bereits in Kontakt gekommen ist.

Um die Erstellung von Komponenten zu vereinfachen, wurden spezielle Helferklassen erstellt, die eine Einbindung von Komponenten aus Apache Lucene erlauben und effiziente Parser für XML zur Verfügung stellen. Der Zugriff auf einen Index von Apache Lucene wurde ebenfalls abstrahiert, um eine direkte Manipulation des Dateisystems zu verhindern.

Die Flexibilität der Komponenten ist so weitreichend, dass ebenfalls Kom-ponenten möglich sind, die direkt in der Benutzungsoberfläche der Verarbei-tungskette programmiert werden können. D.h. Benutzer können so ad hoc Komponenten entwickeln und testen. Diese Möglichkeit, eigene Komponen-ten zu erstellen, setzt jedoch ein großes Verständnis für die verfügbaren Programmierschnittstellen voraus.

Neben der Implementierung von Komponenten kommt das serverseitige JavaScript auch bei der Berechnung der Metriken, der Überprüfung der Achievements und der Zusammenstellung der Leaderboards zum Einsatz. Darüber hinaus wird JavaScript auch bei der Überprüfung des Status von Aufgaben in Assignments angewendet. In diesem Fall wird es jedoch nicht vom Server ausgeführt, sondern läuft im Browser.

141

4.2.4 Spielemechaniken

Im Xtrieval Web Lab werden durch die Anwendung von Spielemechaniken (vgl. Kapitel 2.2.4) insbesondere zwei Ziele erreicht: Zum einen wird durch die Verwendung eines Levelsystems, in dem ein Nutzer nach dem Erreichen bestimmter Ziele aufsteigen kann, die Komplexität des Systems zu Beginn niedrig gehalten. Mit einem zunehmenden Leistungsniveau steigt die Komplexität an, bis schließlich alle Komponenten freigeschaltet sind und verwendet werden können. Zum anderen sollen die Nutzer über einen poten-tiellen Kenntniszuwachs hinaus motiviert werden, so viele Komponenten zu verwenden und zu verstehen wie möglich.

4.2.4.1 Assignments

Assignments (siehe Kapitel 2.2.4.4) stellen Aufgabenkomplexe innerhalb der Anwendung dar. Ein Assignment besteht aus mehreren Teilaufgaben, die der Reihe nach erfüllt werden müssen. Wenn alle Teilaufgaben erfüllt sind, ist das gesamte Assignment erfüllt. Sie beginnen mit einem freien Text, der in die Thematik des Assignments einführt und die Grundlagen für die Erfüllung des Assignments erklärt. Im Anschluss folgen die Teilaufgaben. Hierbei werden jedoch nur erfüllte Teilaufgaben angezeigt und die erste nicht erfüllte Teilaufgabe. Sobald diese erfüllt ist, wird die nächste Teilaufgabe eingeblen-det. Dieses Vorgehen soll die Reihenfolge, in der die Teilaufgaben bearbeitet werden, sicher stellen und die verfügbaren Informationen auf das aktuell Notwendige beschränken.

Das Ziel der Teilaufgaben ist nicht ausschließlich die Einforderung von Handlungen, sondern ebenfalls die Vermittlung von Wissen. Erklärende Text-abschnitte und Hinweise sollen Aspekte der Aufgabenstellung, aber auch die Benutzungsoberfläche erklären (siehe Abbildung 4.6).

142

Abbildung 4.6: Xtrieval Web Lab - Experimentieroberfläche mit aktivem Assignment

Nachdem ein Assignment vollständig erfüllt ist, werden zudem Vorschläge unterbreitet, wie das aktuelle Experiment weiter verbessert werden kann. Für diese Verbesserung stehen jedoch keine zusätzlichen Komponenten zur Verfügung. Falls für das aktuelle Assignment ein Nachfolger definiert ist, wird eine Schaltfläche angezeigt, die bei Betätigung ein neues Experiment mit dem nächsten Assignment anlegt.

4.2.4.2 Achievements

Achievements - auf Deutsch: Erfolge - entsprechen Abzeichen, die beim Er-reichen bestimmter Meilensteine an den Benutzer verliehen werden (siehe Kapitel 2.2.4.3). Diese Meilensteine sind primär von durchgeführten Experi-menten abhängig, können sich aber auch auf Attribute beziehen, die mit dem Benutzer assoziiert sind. Meilensteine können das Erreichen eines bestimm-ten Ergebnisses oder die Anwendung von Komponenten zur Verbesserung des Ergebnisses sein.

143

Die Summe aller erhaltenen Achievements ergibt das Leistungsniveau bzw. Level, das ein Benutzer erreicht hat. Durch den Erwerb von Achievements können Benutzer ihr Level erhöhen und damit weitere Komponenten frei-schalten, die für den Erwerb weiterer Achievements notwendig sind.

In einer von Montola, Nummenmaa, Lucero, Boberg und Korhonen (2009) durchgeführten Studie wurden Achievements eingesetzt, um die User Expe-rience einer Foto-Sharing-Anwendung zu verbessern. Die Ergebnisse waren gemischt. Ein Teil der Probanden empfand die Achievements als Fremd-körper und lehnte sie ab. Vor allem der Modus der Achievements, dass sie sich einfach nur nach der Menge der eingestellten Fotos richteten, stieß auf Ablehnung. Eine Ausrichtung auf die Qualität der Fotos wäre unter Um-ständen besser angenommen worden. Andere Probanden empfanden die Achievements als Motivation und nutzten daraufhin die Anwendung inten-siver. Montola et al. (2009) ziehen zwei Schlüsse aus ihren Beobachtungen: Zum einen, dass die Benachrichtigung, dass ein Achievement erreicht wurde, unmittelbar stattfinden sollte. Zum anderen, dass Achievements nicht wahl-los vergeben werden, sondern vor allem gewünschtes Verhalten bzw. eine gewünschte Nutzung der Software belohnen und in Folge dessen verstärken sollten.

Domínguez et al. (2013) führten eine vergleichende Studie im E-Learning-Um-feld durch und kamen zu einem ähnlichen Ergebnis. Wenn Achievements auf einer rein quantitativen Basis vergeben werden, kann dies dazu führen, dass die Benutzer resignieren und diese Achievements nicht mehr als Belohnung wahrnehmen. Eine qualitative Prüfung der Vorraussetzung für ein Achie-vement muss durchgeführt werden und im Idealfall automatisierbar sein, damit eine Benachrichtigung ohne Zeitverzögerung stattfinden kann.

144

4.2.4.3 Leaderboards

Leaderboards entsprechen Ranglisten, wie sie z.B. im Sport üblich sind (vgl. Kapitel 2.2.4.2). Dort ermöglichen sie einen Vergleich der Leistungen von Sportlern. Sie sind öffentlich zugänglich und zeigen den Namen und den aktuellen Punktestand.

In einer Studie zur Gamification im E-Learning haben Domínguez et al. (2013) verschiedene Spielelemente und Spielemechaniken auf ihre Wirksamkeit untersucht. Sie stellten fest, dass Leaderboards im Allgemeinen die Moti-vation steigerten, da die Probanden ihre Leistungen öffentlich präsentieren konnten. Jedoch wollten einige Probanden auf dieser öffentlichen Plattform nicht sichbar sein, da sie in keinen Wettkampf mit ihren Kommilitonen treten wollten. Wie bereits bei den Achievements ist ein wichtiger Aspekt die Ange-messenheit der Leaderboards: Was wird verglichen und wie gliedert es sich in die E-Learning-Umgebung ein?

Im Xtrieval Web Lab werden Leaderboards dynamisch erzeugt und basieren auf dem aktuellen Zustand aller Experimente und Benutzer in der Datenbank. Aus diesen beiden Quellen können die unterschiedlichsten Leaderboards zusammengestellt werden, z.B. ein Leaderboard, das die besten Experi-mente entsprechend der erzielten Mean Average Precision beinhaltet (siehe Abbildung 4.7), oder eines, das die Benutzer mit den meisten Achievements auflistet.

145

Abbildung 4.7: Xtrieval Web Lab - Leaderboard: Top 100 User

4.2.5 Prototypen und Gestaltung

Die Benutzungsoberfläche wurde anhand von verschiedenen Prototypen während des gesamten Entwicklungsprozesses evaluiert und kontinuierlich weiterentwickelt. Für diese Evaluationen wurden sowohl Personen aus der Zielgruppe, d.h. ehemalige Hörer der Vorlesung Medienretrieval, als auch Experten aus dem Bereich Information Retrieval herangezogen. In diesem iterativen Entwicklungsprozess gab es jedoch stets nur kleine Änderungen an der Benutzungsoberfläche.

Nach der Entwicklung mehrerer Prototypen, deren Fokus auf die Funktionali-täten ausgerichtet war, wurden zwei Workshops in einem Abstand von einer Woche abgehalten, in denen die Benutzungsoberfläche neu gestaltet wurde. Das Ziel des ersten Workshops war der Entwurf eines Konzeptes, das die bereits existierenden Funktionen sinnvoll und für die Zielgruppe verständlich

146

organisiert. Im zweiten Workshop sollte dieser Entwurf verifiziert und vervoll-ständigt werden. Der Aufbau der Workshops orientierte sich am Vorgehen von Memmel, Reiterer und Holzinger (2008) und schafft eine Verbindung zwischen agiler Softwareentwicklung und Usability Engineering.

Zu beiden Workshops waren neben dem Entwickler vier Studierende, die in einem vorherigen Semester die Vorlesung und Übung besucht hatten, und zwei wissenschaftliche Mitarbeiter anwesend. Einige Teilnehmer hatten bereits vor dem Workshop selbstständig mit dem System experimentiert, die anderen Teilnehmer kannten das System und dessen Funktionen nur aus Vorführungen.

Im Laufe des Workshops wurde von den Teilnehmern Folgendes angesprochen:

– Der Einstieg ist sehr schwer, da die Oberfläche nicht selbsterklärend gestaltet ist und auch kein Ziel vorgegeben war. Das Fehlen eines Ziels führt ebenfalls dazu, dass der Fortschritt des Nutzers schwer nachzuvollziehen ist.

– Die Anordnung der beiden Lanes (vgl. Kapitel 4.2.2) nebeneinander war problematisch (siehe Abbildung 4.9). Beide Lanes laufen de facto nacheinander ab und nicht parallel, so wie es die Darstellung vermuten lässt.

– Die Schaltfläche zum Einfügen neuer Komponenten in die Verar-beitungskette war zu versteckt. Sie war erst sichtbar, nachdem der Mauszeiger über dem Zwischenraum zwischen zwei Komponenten stand.

– Die Aufteilung der Experimentkonfiguration, der Indexanalyse und der Ergebnisse in drei separate Ansichten unterbrach den Fluss beim Experimentieren. Es musste stets zwischen den Ansichten

147

gewechselt werden, nachdem eine Einstellung verändert und die neuen Ergebnisse übermittelt wurden.

Im Workshop selbst wurde mit Papier und Stift ein Prototyp erarbeitet, da es sich besonders gut für ein schnelles Prototyping eignet (vgl. Memmel et al., 2008, S. 457). Dazu wurden vorhandene Funktionseinheiten auf einzel-nen Abschnitten skizziert und von den Teilnehmern neu angeordnet. Nach dem Workshop wurden anhand der Papierprototypen Wireframes64 mit NinjaMock65 erstellt, die als Grundlage für die Validierung und Weiterentwick-lung im zweiten Workshop dienten.

Die größte Veränderung, die im Zuge des Workshops vorgenommen wurde, war die Integration von Assignments (vgl. Kapitel 4.2.4.1). Durch Assign-ments sollen die Benutzungsoberfläche erklärt und die Lernumgebung bzw. die Lerninhalte strukturiert werden. Vor der Einführung von Assignments war ein Lernender völlig frei im Experimentieren. Um das System effektiv nutzen zu können, war eine kontinuierliche Anleitung von einem Tutor notwendig. Dank der Assignments wird der Tutor nur noch für tiefgehende Fragen und Probleme herangezogen. Die Bedienung der Benutzungsoberfläche und die ersten Schritte können durch Assignments erklärt werden. Ein freies Experi-mentieren ist nach wie vor möglich, wenn vom Nutzer ein Experiment ohne ein Assignment angelegt wird.

Folgende wesentliche Änderungen wurden im Rahmen des Workshops für die Gestaltung des Systems vorgeschlagen und implementiert:

– Das Menü, das zuvor auf der linken Bildschirmseite angeordnet war, ist nun am oberen Bildschirmrand (vgl. Abbildungen 4.9, 4.10 und 4.6). Untermenüs werden als Dropdown-Menüs dargestellt und der

64 Ein Wireframe ist eine Art digitale Skizze, die den Aufbau einer Webseite wiedergibt, siehe z.B. Abbildung 4.9 und 4.11.

65 https://ninjamock.com/ (7. Januar 2016)

148

angemeldete Benutzer inklusive der Anzahl seiner erreichten Achie-vements wird auf der rechten Seite des Menüs angezeigt.

– Der Platz auf der linken Bildschirmseite, der vorher vom Menü ein-genommen wurde, wird für die Anzeige des Assignments verwendet (siehe Abbildung 4.10). Jede Aufgabe in einem Assignment ist an definierte Bedingungen gekoppelt. Wenn eine Aufgabe erfüllt ist, wird dies durch einen grünen Haken kenntlich gemacht.

– Die Verarbeitungskette wird nun als solche dargestellt. D.h. die La-nes werden nicht mehr nebeneinander präsentiert (siehe Abbildung 4.9), sondern nacheinander (siehe Abbildungen 4.6 und 4.10). Durch vertikales Scrollen kann so die Verarbeitungskette Schritt für Schritt nachvollzogen werden.

– Die Preview wurde auf die rechte Seite der Komponenten verscho-ben, da dort, durch die neue Anordnung der Lanes, genügend Frei-raum war (siehe Abbildungen 4.6 und 4.10). Auf kleinen Bildschir-men wird die Preview wieder unter jeder Komponente angezeigt.

– Neue Komponenten können wie im Prototyp mittels einer Schaltflä-che eingefügt werden, jedoch ist diese Schaltfläche nun permanent sichtbar (siehe Abbildung 4.10).

– Nach jeder Lane werden nun die Ergebnisse der entsprechenden Lane angezeigt. Die Ergebnisanzeige ist so besser in die Verarbei-tungskette integriert und ein Nutzer muss nicht mehr zwischen verschiedenen Ansichten umschalten (siehe Abbildung 4.12).

– Die einzelnen Schritte innerhalb der Verarbeitungskette sind num-meriert, um ihre sequenzielle Abfolge hervorzuheben (siehe Abbil-dungen 4.6 und 4.10).

149

– Neue Einstellungsmöglichkeiten für die Preview erlauben die Her-vorhebung von Veränderungen durch die Komponenten oder das Ausblenden von unerwünschten Feldern.

– Evaluationsmetriken und daraus abgeleitete Diagramme werden zeitgleich mit der Ergebnisliste angezeigt. Durch das Anklicken ei-nes Eintrags in der Ergebnisliste wird das entsprechende Dokument geladen und angezeigt. Sowohl in der Topic-Auswahl, als auch in der Ergebnisliste, werden die jeweiligen Titel angezeigt, um die Ausgabe für den Nutzer verständlicher zu gestalten.

Abbildung 4.8: Xtrieval Web Lab - Ansicht der Ergebnisse eines Experiments

150

Abbildung 4.9: Xtrieval Web Lab (Prototyp) - Ansicht eines Experiments mit Komponenten und Preview

Abbildung 4.10: Xtrieval Web Lab (Wireframe) - Ansicht eines Experiments mit Assignment, Komponenten und Preview

151

Abbildung 4.11: Xtrieval Web Lab (Prototyp) - Ansicht der Ergebnisse eines Experiments

Abbildung 4.12: Xtrieval Web Lab (Wireframe) - Ansicht eines Experiments und der Ergebnisse zusammen mit den Komponenten

153

5 Evaluation

Das in vorhergehenden Kapitel beschriebene Xtrieval Web Lab wird in die-sem Kapitel in einer Studie auf seine Eignung zur Unterstützung der Lehre im Bereich Information Retrieval überprüft. Dafür werden basierend auf der Ziel-stellung und der Zielgruppe Aufgaben formuliert, die von den Studierenden zu bearbeiten sind. Speziell geschaffene Achievements und Leaderboards nehmen Bezug auf die Lerninhalte und sollen die Studierenden motivieren. Zum Schluss werden die Ergebnisse vorgestellt und ausgewertet.

5.1 Zielstellung und Zielgruppe

Das Xtrieval Web Lab wurde in erster Linie für Studierende ohne Informa-tikhintergrund entwickelt, da es keine Programmierkenntnisse vorraussetzt. Darüber hinaus richtet es sich an Hörer einer Vorlesung mit dem Thema Information Retrieval. Vor allem Studiengänge wie Bibliotheks- und Informa-tionswissenschaft (Library and information science), aber auch Medienkom-munikation oder Informatik für Geistes- und Sozialwissenschaftler, wie sie an der Technischen Universität Chemnitz vorkommen, sind hierbei inbegriffen.

Das Einsatzszenario für die Webanwendung ist eine Präsenzübung, in der die Lernenden von einem Tutor bei der Benutzung der Anwendung angelei-tet und unterstützt werden können. Die Inhalte der Anwendung sollen im Rahmen der Übung hinterfragt und diskutiert werden können. Eine spätere Wiederholung der Inhalte außerhalb der Übung soll ebenso möglich sein.

Folgende Forschungsfragen sollen im Rahmen der Evaluation beantwortet werden:

1. Können Studierende (Informatik und Nicht-Informatik) etwas aus der praktischen Arbeit mit dem System lernen?

154

2. Welche Probleme haben die Studierenden bei der Arbeit mit dem System?

3. Sehen die Studierenden eine Vorteil in der Arbeit mit dem System?

5.2 Aufbau und Lerninhalte

Für die Evaluation der Webanwendung wurden insgesamt fünf Assignments (Aufgaben) ausgearbeitet, die der Reihe nach bearbeitet werden sollen. Bei jedem Assignment wird bei einer vollständigen Bearbeitung mindestens ein Achievement vergeben, das die notwendigen Komponenten für das nächste Assignment freischaltet. Die Assignments bauen thematisch aufeinander auf, müssen aber bei vorhandenem Vorwissen nicht sequenziell abgearbei-tet werden.

Nachdem alle fünf Assignments bearbeitet wurden, können die Lernenden weitere Experimente ohne ein Assignment anlegen. Hierbei gelten die Be-schränkungen, die einzelne Assignments für die Verwendung bestimmter Komponenten vorgeben, nicht mehr und zusätzliche Komponenten können zur Verbesserung der Retrieval Ergebnisse verwendet werden.

5.2.1 Komponenten

Folgende Komponenten standen den Probanden während der Evaluation zur Verfügung:

– Dataset (XML)Die Dataset-Komponente liest XML-Dokumente aus den Dateien des Korpus ein und wandelt sie in die interne Dokumentenrepräsentati-on (JSON) um. (siehe Kapitel 2.1.1.1)

155

– Lucene TokenizerDer Tokenizer aus dem Apache Lucene Projekt zerlegt die Inhalte der Felder eines Dokuments in einzelne Tokens bzw. Wörter, damit diese von den folgenden Komponenten verarbeitet werden können. (siehe Kapitel 2.1.1.2)

– Lucene IndexAm Ende der Verarbeitungskette zur Indizierung werden die Do-kumente in einen Apache Lucene Index eingefügt. (siehe Kapitel 2.1.1.5)

– TopicsetDie Topicset-Komponente ist mit der Dataset-Komponente ge-koppelt und stellt die mit dem Dataset verknüpften Topicsets zur Auswahl. Nachdem ein Topicset ausgewählt ist, gibt die Kompo-nente die im Topicset enthaltenen Suchanfragen aus. (siehe Kapitel 2.1.2.3)

– Lucene SearchDiese Komponente verwendet die ankommenden Dokumente als Suchanfragen für den von der Komponente „Lucene Index“ erstell-ten Index. Dabei werden die Inhalte der Felder des Dokuments in den gleichnamigen Feldern im Index gesucht. (siehe Kapitel 2.1.1.6)

– Bag of WordsDa die Komponente „Lucene Search“ nur in gleichnamigen Feldern sucht, können mithilfe dieser Komponente Felderinhalte von einem Feld in ein anderes Feld verschoben werden. So ist es möglich, alle Inhalte im Feld „title“ zu bündeln.

156

– Lowercase FilterDiese Komponente wandelt alle Buchstaben in Kleinbuchstaben um, sodass die Groß- und Kleinschreibung das Matching nicht mehr beeinflusst.

– n-Gram StemmerDer n-Gram Stemmer bildet n-Grams, wie es in Kapitel 2.1.1.4 be-schrieben ist. Dabei kann der Nutzer die Größe von n festlegen. Sie muss mindestens 1 betragen und kann in ganzzahligen Schritten vergrößert werden. Die Standardeinstellung für n ist 5, die bereits ein gutes Ergebnis liefert, aber noch nicht das beste.

– Snowball StemmerBeim regelbasierten Snowball Stemmer kann der Nutzer zwischen vier Snowball-Programmen auswählen: Deutsch, Englisch, Spanisch und Porter. Da der Korpus für die Assignments in englischer Sprache vorliegt, sind nur Englisch und Porter zweckmäßige Möglichkeiten. (siehe Kapitel 2.1.1.4)

– Stopword FilterDer Stopword Filter entfernt alle vom Nutzer eingetragenen Stoppwörter (siehe Kapitel 2.1.1.3). Der Nutzer kann diese entweder durch eine Analyse des Index bestimmen oder mittels einer Inter-netsuchmaschine eine allgemeine Stoppwortliste ausfindig machen und verwenden.

– Krovetz Stemmer (nur beim freien Experimentieren verfügbar)Der Krovetz Stemmer ist ein spezieller Stemmer für die englische Sprache (siehe Kapitel 2.1.1.4). Er reduziert die Wörter ähnlich wie der Porter-Stemmer auf ihren Wortstamm, geht dabei jedoch we-niger aggressiv vor und stellt sicher, dass das Ergebnis wieder ein korrektes englisches Wort ist. Aus diesem Grund kann er mehrmals hintereinander und vor anderen Stemmern angewendet werden. Er

157

kann, im Gegensatz zum Snowball und n-Gram Stemmer, auch vor dem Stopword Filter angewendet werden.

– Number Filter (nur beim freien Experimentieren verfügbar)Mit dem Number Filter können alle Ziffern aus den Feldinhalten ent-fernt werden. Diese Komponente entstand im Rahmen von CLEF-IP (siehe Kapitel 4.1.2.4 und 4.1.2.5).

5.2.2 Assignments

Ein Assignment ist aus einem einleitenden Text und einer Reihe von Aufga-ben zusammengesetzt. Der einleitende Text beschreibt kurz die Konzepte, die im Assignment behandelt werden, und formuliert eine Zielstellung. Einzelne Aufgaben enthalten stets eine Anweisung, die von den Lernenden befolgt werden muss. Sobald eine Anweisung umgesetzt wurde, wird die nächste Aufgabe eingeblendet. Zusätzliche Informationen zu Aspekten der Anweisung können auch enthalten sein. Wenn eine Aufgabe erfolgreich bearbeitet wurde, können zusätzliche Informationen zur Aufgabe, aber auch zur Benutzungsoberfläche eingeblendet werden. Anweisungen geben vor, welche Komponenten im Experiment eingesetzt werden sollen, an welcher Position diese im Experiment zu stehen haben und welche Parameter für bestimmte Komponenten einzustellen sind. Die vollständige Wiedergabe der Assignments inklusive aller Aufgaben und Erklärungen ist in Anhang A zu finden.

5.2.2.1 Ein einfaches Experiment

Das erste Assignment „Ein einfaches Experiment“ etabliert ein minimales Ex-periment. Dieses Experiment enthält die Komponenten, die für die Erzeugung eines Index und die Suche in diesem Index unbedingt notwendig sind. Dieser

158

Minimal-Aufbau wird bei allen folgenden Assignments als erste Aufgabe wiederholt, um einen Grundaufbau zu etablieren.

Ein weiteres Ziel des ersten Assignments ist es, den Benutzer mit der Ober-fläche und den Werkzeugen vertraut zu machen. Während er das Experiment Schritt für Schritt zusammenstellt, wird er auf Bedienelemente hingewiesen und die verschiedenen Ausgaben des Systems werden ihm erklärt.

Die folgenden Komponenten können verwendet werden:

– Dataset (XML)– Topicset– Tokenizer– Lucene Index– Lucene Search

Weitere Komponenten stehen an diesem Punkt nicht zur Verfügung. Dieses Assignment ist so angelegt, dass bei jedem Einfügeschritt nur eine einzige Komponente ausgewählt werden kann. Diese Einschränkung soll den Fokus auf die grundlegenden Schritte zur Zusammenstellung eines Experiments legen und Verwirrungen oder Ablenkungen durch eine zu große Auswahl an Komponenten vermeiden.

5.2.2.2 Felder & Filter

Durch das Assignment „Felder & Filter“ sollen die zentralen Konzepte der Felder und der Filter vermittelt werden. Felder stehen hierbei für Dokument-felder, wie z.B. der Titel oder das Erstellungsdatum. Filter sind hierbei alle Komponenten, die keine Quelle (Source) und keine Senke (Collector) sind. Die Bezeichnung orientiert sich an dem für Apache Lucene gängigen TokenFilter.

159

Folgende Komponenten können für das Experiment zusätzlich zu denen aus dem einfachen Experiment (siehe Kapitel 5.2.2.1) eingesetzt werden:

– Bag of Words– Lowercase Filter

5.2.2.3 Stemming (1)

Das dritte Assignment betrifft das n-Gram-Stemming. Wenn der Lernende den Anweisungen folgt, erhält er jedoch nur ein sehr schwaches Ergebnis. Im Zuge des Assignments werden einige Charakteristiken des n-Gram-Stem-mings herausgearbeitet, wie z.B. die Eignung für die Trennung zusammen-gesetzter Wörter und die Sprachunabhängigkeit. Ebenfalls werden die Lernenden dazu ermutigt, mit unterschiedlichen Längen der n-Grams zu experimentieren.

Da beim n-Gram-Stemming alle Wörter entfallen, die kürzer als das eingestell-te n sind, fungiert dieser Stemmer gleichzeitig als eine Art Stoppwort-Ent-fernung. Aus diesem Grund sind die Ergebnisse von vornherein besser als mit dem Snowball-Stemmer. Mit einer entsprechenden Stoppwort-Ent-fernung funktioniert der Snowball-Stemmer in der Regel besser als das n-Gram-Stemming.

Die folgende Komponente wird zur Erfüllung dieses Assignments zusätzlich benötigt:

– n-Gram Stemmer

160

5.2.2.4 Stemming (2)

Dieses Assignment setzt die Thematik des Stemming fort und befasst sich mit dem Snowball-Stemmer. Dieser regelbasierte Stemmer arbeitet mit einer eigenen Programmiersprache, die explizit für die Erstellung von Stem-ming-Algorithmen entwickelt wurde. Mithilfe eines Snowball-Compilers kann ein Snowball-Skript in ein C oder Java-Programm übersetzt werden (vgl. Kapitel 2.1.1.4).

Nach einer unreflektierten Umsetzung der Aufgaben des Assignments erhält der Benutzer ein schlechteres Ergebnis als beim n-Gram-Stemmer. Hier ist es um so wichtiger, dass die Hinweise auf mögliche Verbesserungen am Ende des Assignments befolgt werden, um das Ergebnis zu verbessern. Obwohl das n-Gram-Stemming durch die Entfernung aller Wörter, die weniger als n Buchstaben haben, ähnlich einer Stoppwortliste funktioniert, erreicht der Snowball-Stemmer auch ohne die Entfernung von Stoppwörtern eine bessere Mean Average Precision, wenn zusätzlich das „description“-Feld durchsucht wird und vorher alle Buchstaben in Kleinbuchstaben transformiert werden.

Um dieses Assignment erfolgreich zu beenden ist deshalb die folgende Komponente zusätzlich notwendig:

– Snowball Stemmer

5.2.2.5 Stoppwörter

Das letzte Assignment behandelt Stoppwörter. Im Rahmen der Aufgaben soll wieder ein einfaches Experiment angelegt werden, das zusätzlich einen Stoppwortfilter zum Entfernen von Stoppwörtern enthält. Zu Beginn des Assignments wird das Konzept von Stoppwörtern kurz erklärt, aber es wird nicht vorgegeben, welche Wörter entfernt werden sollen. Die Komponente zum Entfernen der Stoppwörter erlaubt die freie Eingabe beliebiger Wörter.

161

Die Benutzer werden aber darauf hingewiesen, dass mithilfe der Index-Ana-lyse besonders häufig auftretende Wörter identifiziert werden können oder dass durch eine Recherche im Internet eine allgemeingültige Stoppwortliste gefunden und verwendet werden kann.

Um das Assignment erfolgreich abzuschließen, müssen mindestens zehn Stoppwörter eingetragen werden und die Mean Average Precision muss mindestens einen Wert von 0,6 erreichen. D.h. eine wahllose Eingabe von Wörtern ist in der Regel nicht zielführend.

Da am Ende dieses Assignments bereits die wichtigsten Komponenten zur Verfügung stehen, können durch die Anwendung von Komponenten aus den vorherigen Assignments besonders gute Ergebnisse erzielt werden. Eine weitere Verbesserung ist nur noch durch die zusätzlichen Komponenten möglich, die bei einem Experiment ohne Assignment zur Verfügung stehen.

Für dieses letzte Assignment wird zudem folgende Komponente benötigt:

– Stopword Filter

5.2.3 Achievements

Für die Evaluation wurden insgesamt sechs Achievements angelegt. Drei davon sind einfache Achievements und drei verfügen über jeweils drei Leistungsniveaus (ein bis drei Sterne), die abhängig von verschiedenen Kriterien vergeben werden. Jeder Lernende kann sich im Hauptmenü über den aktuellen Stand seiner Achievements informieren. Weiterhin sind alle noch nicht freigeschalteten Achievements sichtbar, aber ausgegraut, um zur weitergehenden Nutzung des Systems zu motivieren.

162

First ExperimentDieses Achievement wird für das erste vollständige, durchge-führte Experiment verliehen.

Bag of WordsWenn die Bag-of-Words-Komponente verwendet und eine Mean Average Precision von mehr als 0,1 (10%) erzielt wurde, wird dieses Achievement freigeschaltet.

PrecisionDieses Achievement wird in drei Stufen verliehen. Bei einer Mean Average Precision von mehr als 0,13 (13%), 0,19 (19%) und 0,22 (22%).

StemmingFür jeden Stemmer, der eine Verbesserung der Mean Average Precision bewirkt, wird eine weitere Stufe dieses Achieve-ments verliehen. Es werden maximal drei Stemmer belohnt.

StopwordsDas Stopwords-Achievement prüft ähnlich dem Stem-ming-Achievement, ob die Stopwords-Removal-Komponente zu einer Verbesserung der Mean Average Precision führt. Jedoch muss die Differenz zwischen aktivierter und deakti-vierter Komponente folgende Schwellenwerte übersteigen: 0,02 (2%), 0,04 (4%) und 0,08 (8%)

Easy as PieDieses Achievement wird verliehen, wenn in einem Experi-ment ohne Assignment, d.h. ohne Anleitung oder Hinweise, eine Mean Average Precision von mindestens 0,22 (22%) erreicht wurde.

163

5.3 Fragebogen

Die Evaluierung wurde mithilfe eines Online-Fragebogens durchgeführt. Alle Teilnehmer sollten vor und nach der Benutzung des Systems verschiedene Fragen zu ihrem Studiengang, zu ihren Erfahrungen mit dem System und zu Lehrinhalten aus der Vorlesung und der Webanwendung beantworten.

Die Fragen zu den Lehrinhalten waren in zwei Teile gegliedert: Es gab neun Wissensfragen, z.B. was eine höhere Mean Average Precision für die vom System zurückgelieferten Dokumente bedeutet oder welcher Stemmer das Wort „Bäume“ in „Bäu äum ume“ transformiert. Des Weiteren gab es sechs Einschätzungsfragen, z.B. sollte geschätzt werden, wie viele Stoppwörter für eine deutliche Verbesserung des Ergebnisses notwendig sind oder in welchem Maße die verschiedenen Komponenten das Ergebnis verbessern können.

Es wurden vor allem Themen abgefragt, die durch die Assignments von den Studierenden bearbeitet wurden, d.h. Stoppwörter und die Stemmingverfah-ren n-Gram-Stemmer und Snowball-Stemmer, zu dem auch der Porter-Stem-mer gehört. Alle Themen wurden ebenfalls in der Vorlesung behandelt, jedoch wurden trotzdem die Konzepte zu Beginn der Assignments kurz wiederholt. Diese Wiederholung gab aber bei weitem nicht die tiefen, theore-tischen Einblicke, die die Vorlesung leistete.

Zum Abschluss des Fragebogens wurden allgemeine Fragen zur Bedienung und zur Eignung des Systems als Ergänzung zur Vorlesung gestellt. Die Fragen zur Bedienung zielten vor allem darauf, gute, aber auch schlechte Erfahrungen einzusammeln. Eine vollständige Wiedergabe des Fragebogens ist im Anhang B zu finden.

164

5.4 Durchführung

Durch Pretests wurde die Qualität des Fragebogens sichergestellt. Eine ausgewählte Gruppe wurde wiederholt mit dem Test konfrontiert, um die Formulierungen der Fragen und der Antworten so verständlich und eindeutig wie möglich zu gestalten.

Folgende Personen wurden bei den Pretests wiederholt befragt:

– drei Hörer der Vorlesung aus vorhergehenden Semestern,– ein wissenschaftlicher Mitarbeiter, der eben-

falls die Vorlesung gehört hatte,– der Professor, der die Vorlesung hält und– eine außenstehende Person, die jedoch

mit der Thematik vertraut war.

Durch die Pretests kam es zu mehreren Änderungen an den Fragestellungen, den Antwortmöglichkeiten und am allgemeinen Aufbau des Fragebogens. So waren zu Beginn die Fragen auf wenigen Seiten verteilt. Beim Pretest ist jedoch aufgefallen, dass einige Antworten korrigiert wurden, nachdem spätere Fragen gelesen wurden. Um dies zu verhindern, wurden die Fragen stärker in einzelne Sektionen bzw. Seiten unterteilt.

Ebenso war eine Frage vorgesehen, in der die Lernenden die Komponenten nach ihrem Vermögen, das Retrieval Ergebnis zu verbessern, sortieren soll-ten. Zum einen war die Fragestellung nicht jedem Testkandidaten klar, zum anderen gab es bei den Antwortmöglichkeiten Probleme, da eine gegebene Antwort nicht revidiert werden konnte.

Am finalen Pretest nahmen noch einmal insgesamt sieben Personen teil, darunter waren wissenschaftliche Mitarbeiter und Hilfskräfte der Professur Medieninformatik. Dabei wurden keine weiteren Mängel festgestellt.

165

Die Studie fand vom 25. bis zum 30. November 2015 im Rahmen der Übung Medienretrieval an der Technischen Universität Chemnitz statt. Dieser enge Zeitplan hing mit der parallel stattfindenden Vorlesung zusammen. Alle Tests sollten zwischen zwei Vorlesungseinheiten durchgeführt werden, um diese als Quelle für unterschiedliches Vorwissen zu eliminieren.

Die Vorlesung richtet sich an eine Vielzahl unterschiedlicher Studiengänge, darunter ein Großteil der Studiengänge der Fakultät für Informatik, aber auch die Studiengänge der Wirtschaftswissenschaften und Philosophie. Der Studiengang Master Informatik für Geistes- und Sozialwissenschaftler (IGS) nimmt hierbei eine besondere Stellung ein. Studierende dieses Studiengangs haben vorher etwas Nicht-Technisches studiert und sind in gewisser Weise Quereinsteiger.

Die Studie wurde an insgesamt neun Terminen durchgeführt. Zu jedem Termin wurden maximal acht Studierende, die sich für die Vorlesung Medien-retrieval eingeschrieben hatten, als Probanden eingeladen. Pro Termin waren 90 Minuten veranschlagt. Zu Beginn wurde alle anwesenden Probanden über die Studie und deren Ablauf aufgeklärt. Die Teilnahme war für alle Studie-renden freiwillig und hatte keinen direkten Einfluss auf eine Klausurnote. Weiterhin wurde herausgestellt, dass eine Nichtteilnahme oder ein Abbruch keine negativen Auswirkungen hat. Jeder Proband erhielt eine Probanden-information und eine Einwilligungserklärung, die zu unterzeichnen war. Die Probanden hatten die Möglichkeit, die Probandeninformation und die Einwil-ligungserklärung für ihre Unterlagen mitzunehmen.

Sie wurden ebenfalls darüber informiert, dass während der Benutzung der Webanwendung der Bildschirminhalt aufgezeichnet wird. Die Bearbeitung des Fragebogens war explizit von dieser Aufzeichnung ausgeschlossen. Jedem Studierenden wurde die Möglichkeit gegeben, die Aufzeichnung im Anschluss zu vernichten oder nicht teilzunehmen.

166

5.5 Ergebnisse

An der Studie nahmen insgesamt 50 Probanden teil. Die Hälfte der Teilneh-mer studierte nach eigenen Angaben im Master Informatik für Geistes- und Sozialwissenschaftler (IGS). Weitere 14 Teilnehmer studierten andere Studiengänge der Informatik, darunter mehrheitlich in einem Bachelor- und einige in einem Master-Studiengang. Die restlichen 11 Teilnehmer gaben an, Business Intelligence & Analytics (BI) im Master zu studieren. Von den 50 Teilnehmern haben 46 über die Aufgaben der Assignments hinaus expe-rimentiert und bessere Ergebnisse erzielt. Von diesen haben wiederum 17 Teilnehmer ein freies Experiment angelegt, indem sie ohne Assignment, also völlig selbstständig, ein eigenes Experiment zusammenstellten.

vorhernachher

Informatik IGS BI0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

Ante

il ric

htig

bea

ntw

orte

ter F

rage

n

51.6%

79.4%

60.4%68.4%

77.8%82.8%

Abbildung 5.1: Diagramm über den Anteil richtig beantworteter Fragen vor und nach der Benutzung des Systems nach Studiengang

Die Ergebnisse der Wissenfragen vor und nach der Verwendung des Systems variieren überraschend stark zwischen den Studiengängen (siehe. Abbildung 5.1). Die Gruppe der Informatiker beantwortete vorher nur 51,6% der Fragen richtig, danach 79,4%. Für den Studiengang IGS war der Ausgangswert mit 60,4% viel höher, jedoch war der Endwert mit 68,4% bei weitem nicht so hoch, wie bei den Informatikern. Die dritte Gruppe, der Studiengang BI, zeigt ein anderes Bild. Die Anzahl richtig beantworteter Fragen vor der Verwendung

167

des Systems lag bereits sehr hoch, viel besser als beim Studiengang IGS. Sie verbesserten dennoch auf den Spitzenwert 82,8%. Obwohl dies der geringste Zuwachs war, war es dennoch das beste Ergebnis insgesamt.

Insgesamt haben 27 der 50 Teilnehmer (54%) mehr Fragen richtig beantwor-tet, nachdem sie mit dem System experimentierten. Acht von den verbleiben-den Teilnehmern (16%) haben nach der Verwendung des Systems weniger Fragen richtig beantwortet. Bei den restlichen 15 Teilnehmen (30%) war die Anzahl der korrekt beantworteten Fragen identisch (siehe Abbildung 5.2).

BI

IGS

Informatik

-3 -2 -1 0 1 2 3 4 5 6 70

5

10

15

Differenz der Anzahl richtig beantworteter Fragen

Anza

hl Pro

banden

Abbildung 5.2: Histogramm der Differenz der Anzahl richtig beantworteter Fragen vor und nach der Benutzung des Systems

Vor allem die Frage „Welches Stemming-Verfahren passt zu der jeweiligen Form von ‘Bäume’?“ mit den beiden Varianten „Bäu äum ume“ und „Baum“ wurde nach dem Experimentieren zunehmend falsch beantwortet. Die Frage „Welche Mean Average Precision (MAP) ist am besten?“, in der die Beste der angegebenen Mean Average Precisions ausgewählt werden sollte, wurde nach der Verwendung tendenziell öfter korrekt beantwortet. Ebenfalls ver-mehrt korrekt war die Zuordnung verschiedener Beispielausgaben für den Tokenizer.

168

Die Ergebnisse bezüglich der Anzahl richtiger Antworten vor und nach der Verwendung des Systems wurden mittels Wilcoxon-Test (vgl. Bortz & Schuster, 2010, S. 133ff.) und t-Test für Beobachtungspaare (vgl. Bortz et al., 2010, S. 124f.) auf deren Signifikanz geprüft. Mit einem Signifikanzniveau von 5% (α=0,05) wurden folgende Hypothesen verwendet:

H0: Die Anzahl richtiger Antworten ist gleich geblieben oder gesunken.

H1: Die Anzahl richtiger Antworten ist gestiegen.

Diese Hypothesen wurden für die einzelnen Studiengänge und die Gesamt-heit aller Teilnehmer überprüft, wobei durch die Unterteilung in die Studien-gänge die Stichprobengrößen relativ klein werden.

Informatik IGS BI Gesamt

Wilcoxon-Test 0,0027 0,0475 W=12, n=8 0,0005

t-Test 0,0015 0,0385 0,1704 0,0002

Tabelle 5.1: Signifikanztests zur Anzahl richtiger Antworten vor und nach der Benutzung des Systems

Außer für den Studiengang BI wird bei beiden Signifikanztests (Wilcoxon und t-Test) die Nullhypothese H0 widerlegt. Für den Studiengang BI ist die Situation schwierig, da die Stichprobe klein und die Verbesserung gering ist. Dem entsprechend liefert der Wolcoxon-Test bei n=8 ein W=12, das nicht für die Widerlegung der Nullhypothese H0 ausreicht. Bei einer Stichprobegröße von n=8 und einem Signifikanzniveau von 5% beträgt der kritische Wert der unterschritten werden müsste W=5.

Die Studierenden sollten auf der einen Seite einschätzen, wieviele Stoppwör-ter für eine nennenswerte Verbesserung des Retrievalergebnissen notwen-dig sind, und auf der anderen Seite möglichst viele Stoppwörter frei aus dem Gedächtnis aufschreiben. In Abbildung 5.3 sind die entsprechenden Mediane

169

dargestellt. Auf der Webseite von Savoy (2014) werden Stoppwortlisten für viele verschiedene Sprachen bereitgestellt. Die Anzahl von enthaltenen Wör-tern reicht von etwa 100 für Marathe, eine in West- und Zentralindien gespro-chene Sprache, bis etwa 747 für Finnisch. Von den Studierenden wurde vor der Benutzung des Systems geschätzt, dass 50 Wörter notwendig wären, wobei es Angaben von fünf bis 2000 Wörtern gab. Nach der Benutzung des Systems schätzen sie, dass nur 20 Wörter für eine signifikante Verbesserung notwendig sind. Dem gegenüber stehen die tatsächlich aufgeschriebenen Stoppwörter. Deren Anzahl lag vor der Benutzung des Systems bei sieben und danach bei elf. Im Mittel konnten die Studierenden nach der Benutzung vier Stoppwörter mehr angeben. Hierbei ist jedoch anzumerken, dass das Stoppwort-Assignment das letzte Assignment war.

vorhernachher

0 15 30 45 60

geschätzt

tatsächlich

50

7

20

11

Anzahl Stoppwörter

Abbildung 5.3: Geschätzte Anzahl notwendiger Stoppwörter für ein gutes Ergebnis gegenüber der Anzahl tatsächlich gewusster und eingegebener

Stoppwörter vor und nach der Benutzung des Systems

Weiterhin sollten die Studierenden die fünf Komponenten, die in den Assign-ments behandelt werden, auf ihr Vermögen hin einschätzen, das Retrieval -ergebnis zu verbessern (siehe Tabelle 5.2). Für die Einschätzung stand eine Skala von 1 (sehr hohe Verbesserung) bis 5 (sehr geringe bzw. keine Verbesserung) zur Verfügung. Es gibt für diese Fragen keine exakt korrekten

170

Antworten, jedoch sollte eine gewisse Tendenz sichtbar werden. Die Klein-schreibung sollte hierbei am schlechtesten abschneiden und die Entfernung der Stoppwörter am besten.

Sowohl die Antworten vor als auch nach der Verwendung des Systems wei-sen diese Tendenz auf. Jedoch sinkt die Varianz bei den Antworten nach der Verwendung des Systems, was eine höhere Sicherheit bei den individuellen Antworten anzeigt.

Komponentedavor danach

Median Mittel-wert Varianz Median Mittel-

wert Varianz

Kleinschreibung 3 3,2 1,1 2 2,4 0,7

Bag of Words 3 2,9 1,1 2 1,8 0,6

n-Gram-Stemmer 2 2,5 0,6 2 2,4 0,6

Porter/Snow-ball-Stemmer 2 2,3 0,5 2 2,1 0,6

Stoppwörter entfernen 2 2,1 1,4 1 1,5 0,7

Tabelle 5.2: Einschätzung der Komponenten bezüglich deren Verbesserung des Retrieval-Ergebnisses durch die Teilnehmer

Alle Teilnehmer empfanden das System als sinnvolle Ergänzung zur Vor-lesung. Die praktische Anwendung der theoretischen Grundlagen aus der Vorlesung war für viele ein positiver Aspekt. Die schnelle Anzeige der Ergeb-nisse wurde ebenfalls sehr geschätzt. Einige Teilnehmer fanden insbesonde-re die Spielemechaniken, d.h. die Achievements und die Leaderboards, am interessantesten.

Problematisch für einige Teilnehmer (6 von 50) war es, einen Einstieg zu fin-den. Manche Schaltflächen wurden nicht als solche erkannt, was zu Beginn für Verunsicherung sorgte. Nach einigen Hinweisen durch den Tutor haben sich aber alle Teilnehmer zurechtgefunden. Bestimmte Bezeichnungen und

171

Beschriftungen waren ebenfalls nicht eindeutig und wurden nicht gleich verstanden.

Folgende Probleme wurden während der Studie von den Lernenden berichtet:

– Ein Lernender meldete sich und wollte die Aufgaben erklärt haben, da er deren Inhalt nicht verstand. Auf Nachfrage äußerte er jedoch, die Vorlesung gar nicht bzw. nicht oft besucht zu haben. Er setzte sich dennoch mit dem Programm und den Aufgaben auseinander und hat alle fünf Aufgaben beendet.

– Im Dialog zur Auswahl der Komponenten, die in die Verarbeitungs-kette eingefügt werden sollen, fehlte ein Hinweis auf die Möglich-keit, die Komponenten anzuklicken, um diese auszuwählen. Zwei Lernende wussten nicht, wie sie an dieser Stelle fortfahren sollten.

– Mehrere Teilnehmer stellten Fragen zur Bedeutung der Reihenfolge der Komponenten für das Retrieval-Ergebnis. Daraufhin wurde angemerkt, dass die Reihenfolge sicher einen Einfluss hat und sie wurden ermutigt, dies selbst auszuprobieren. Sie wurden auch auf die Funktion zur Veränderung der Reihenfolge der Komponenten hingewiesen.

– Wenn beim n-Gram-Stemmer unterschiedliche Längen für n einge-geben wurden, war das Ergebnis leer bzw. die Mean Average Preci-sion gleich 0. Einige wenige Teilnehmer waren darüber verwundert, haben aber nach einer kurzer Erklärung durch den Tutor den Sach-verhalt und die Gründe für das Ergebnis verstanden.

– Es gab auch verschiedene Anmerkungen und Wünsche an die Benutzungsoberfläche: Die Komponenten sollten z.B. zusammen-klappbar sein, damit man ggf. nicht so viel hin- und herscrollen

172

muss. Die Anzeige der Mean Average Precision war nicht immer gut zugänglich und eine Art Historie wäre hilfreich.

– Einige Teilnehmer nutzten aktiv die Preview-Settings, die in den ersten beiden Assignments vorgestellt werden. Der erhoffte Vorteil durch eine bessere Darstellung von Unterschieden in den Vorschau-ergebnissen wurde jedoch von vielen nicht wahrgenommen bzw. genutzt. Im Bezug auf die Preview schlug ein Teilnehmer vor, die Feldauswahl, d.h. die Beschränkung der Anzeige auf ein einziges Feld, zu lockern und eine Mehrfachauswahl zuzulassen. Dadurch könnten unwichtige Felder ausgeblendet werden und alle wichtigen Felder bleiben sichtbar.

– Nachdem die Teilnehmer ermutigt wurden, sich auszutauschen und sich gegenseitig zu helfen, wurde diese Möglichkeit ausgiebig genutzt. Es wurden Ergebnisse verglichen und Einstellungen von Komponenten ausgetauscht.

– Bei der Bearbeitung des letzten Assignments wurde beobachtet, dass die Teilnehmer mithilfe einer Internetsuchmaschine nach englischen Stoppwörtern suchten. Das wurde so auch im Assign-ment vorgeschlagen. Jedoch wurde nach „stoppwortliste englisch“ gesucht, anstatt nach „stopwords english“, was wahrscheinlich bessere Aussichten auf Erfolg gehabt hätte.

– Zwei Teilnehmer stießen auf einen störenden Fehler: Wenn beim n-Gram-Stemmer nach der Eingabe einer neuen Zahl die Enter-Taste betätigt wird, wird die Komponente einen Schritt nach oben verscho-ben, unabhängig davon ob dies möglich bzw. erlaubt ist. Damit kann das Experiment zerstört werden und die entsprechende Lane (Ver-arbeitungskette) muss geleert und neu zusammengestellt werden.

173

Schlussendlich gab es eine große Menge an Teilnehmern, die die Oberfläche als benutzerfreundlich beschrieben, aber auch einige Teilnehmer, die von gegenteiligen Erlebnissen berichteten.

Nach der Auswertung der Evaluation können die Forschungsfragen aus Kapi-tel 5.1 wie folgt beantwortet werden:

1� Können Studierende (Informatik und Nicht-Informatik) etwas aus der praktischen Arbeit mit dem System lernen?

Diese Frage kann mit ja beantwortet werden. Nach der Benutzung des Systems werden signifikant mehr Fragen richtig beantwortet als davor. Dabei war die Baseline das Wissen, das die Studieren-den ohne zusätzlichen Lerneinsatz aus den Vorlesungen behalten haben.

Für die Studiengänge Informatik für Geistes- und Sozialwissen-schaftler und Business Intelligence & Analytics fielen die Unter-schiede weniger groß aus, als bei den restlichen Informatikern. Hier wird vermutet, dass es zum einen an dem höheren Ausgangswert liegt und zum anderen die Informatiker intensiver mit dem System arbeiteten. Diese Hypothese sollte in weiteren Experimenten über-prüft werden.

Die reduzierte Varianz bei der Einschätzung der Leistungsfähigkeit der Komponenten lässt ein besseres Verständnis der Komponenten vermuten, da hier nach der Verwendung des Systems weniger Unsi-cherheit auftrat.

174

2� Welche Probleme haben die Studierenden bei der Arbeit mit dem System?

Das größte Hindernis für die Studierenden war die Benutzungsober-fläche. Sie hatten zu Beginn Schwierigkeiten sich zurechtzufinden und manche Beschriftungen waren nicht aussagekräftig genug. Ebenso wurde die Sichtbarkeit und die Vergleichbarkeit des Ergeb-nisses bemängelt.

3� Sehen die Studierenden eine Vorteil in der Arbeit mit dem System?

Die Verwendung des Systems wurde von allen Studierenden als gute Ergänzung zur Vorlesung gewertet. Vor allem die praktische Anwendung der Theorie aus der Vorlesung wurde von vielen Stu-dierenden hervorgehoben. Einige Studierende waren auch den spielerischen Aspekten zugetan. Dabei haben manche versucht, alle Achievements freizuschalten, andere wollten eine Spitzenposition im Leaderboard erreichen.

175

6 Fazit

Dieses abschließende Kapitel fasst die Ergebnisse der vorliegenden Arbeit zusammen und gibt einen Ausblick auf Verbesserungsmöglichkeiten und weitere Forschungsvorhaben, die sich anschließen könnten.

6.1 Diskussion

Mit dem Xtrieval Web Lab wurde eine Lernumgebung geschaffen, die es Lernenden ermöglicht, reale Information Retrieval Experimente auf der Basis von parametrierbaren Komponenten durchzuführen. Aufbauend auf dem Xtrieval Framework, das seine Leistungsfähigkeit und Flexibilität bereits in mehreren Evaluationskampagnen unter Beweis gestellt hat, profitiert das Xtrieval Web Lab von diesen Softwarekomponenten. Obwohl beide Systeme ähnliche Werkzeuge benutzen, repräsentiert das Xtrieval Web Lab einen qua-litativen Ansatz. Es wurde für ein manuelles Experimentieren konzipiert, das von einem Lernenden überwacht und gesteuert wird. Das Xtrieval Frame-work hingegen repräsentiert einen quantitativen Ansatz, da es primär für die Durchführung von unüberwachten Experimenten mit vielen verschiedenen Konfigurationen entwickelt wurde (vgl. Kürsten, 2012).

Das Xtrieval Web Lab zeichnet sich durch eine große Flexibilität in der Ge-staltung des Retrievalprozesses und eine hohe Benutzerfreundlichkeit aus. Nutzer ohne Kenntnis einer Programmiersprache können selbstständig aus praxisnahen Komponenten ein Retrievalsystem zusammenstellen und mit realen Datensätzen evaluieren.

Mittels Assignments (Aufgabenstellungen mit Handlungsanweisungen und Erläuterungen) werden die Lernenden mit der Benutzungsoberfläche vertraut gemacht und in ihrem ersten Experimentieren angeleitet, die vorhandenen Möglichkeiten zur Beeinflussung des Retrievalergebnisses kennenzulernen.

176

Auch ein freies Experimentieren ohne Assignment ist möglich. Hierbei ste-hen zusätzliche Komponenten zur Verfügung, während Handlungsanweisun-gen und Erläuterungen fehlen. Durch das zeitnahe Feedback während des Aufbaus eines Experiments kann die Wirkungsweise jeder Komponente di-rekt beobachtet werden. Nach der Durchführung eines Experiments können alle Ergebnisse und Zwischenergebnisse untersucht und im weiteren Verlauf die Komponenten und deren Parameter angepasst werden. Achievements (Erfolge) informieren über das Erreichen bestimmter Meilensteine, geben den Zugriff auf weitere Komponenten frei und motivieren zum fortgesetzten Experimentieren. In Leaderboards können die Experimentergebnisse und die Leistungen der Anwender miteinander verglichen werden.

Die Art und Weise der Implementierung der Verarbeitungskette und die Mög-lichkeit, jederzeit neue Komponenten zu erstellen, erlauben weitere Anwen-dungen. So sind Anwendungen auf anderen Gebieten, wie z.B. der Bildverar-beitung, denkbar. Ausgehend von einem Ausgangsbild werden verschiedene Transformationen, wie z.B. ein Gauß-Filter oder eine Fouriertransformation, angewendet, um ein definiertes Zielbild zu erhalten. Zu jedem Schritt zeigt eine Vorschau die Veränderungen am Bild an. Da nur zulässige Komponen-ten eingefügt werden können, steht am Ende der Verarbeitungskette immer ein valides Ergebnis, das nur noch bezüglich seiner Qualität geprüft werden muss.

Aufgrund zahlreicher, kontinuierlicher Benutzungstest wurde die Benut-zungsoberfläche fortlaufend weiterentwickelt, um die Benutzerfreundlichkeit zu optimieren. In zwei zusätzlichen Workshops mit potentiellen Anwendern wurden Ideen und Entwürfe für eine Umgestaltung der Weboberfläche entwi-ckelt, die im Anschluss integriert wurden.

Eine Untersuchung mit 50 Studierenden aus der Vorlesung Medienretrieval hat ergeben, dass sich unabhängig von der Studienrichtung ein Lernerfolg eingestellt hat. Mittels Wissens- und Schätzfragen wurde gezeigt, dass die Teilnehmer diese nach der Verwendung des Systems besser und

177

konsistenter beantworteten. Die Teilnehmer wurden ebenfalls nach positiven und negativen Erfahrungen mit dem System gefragt, wobei die positiven Eindrücke überwogen. Das System wurde übereinstimmend als sinnvolle Ergänzung zur Vorlesung bewertet.

6.2 Ausblick

Weitere Untersuchungen einzelner Aspekte der Lernumgebung, wie z.B. Achievements, Leaderboards oder Zielfreiheitseffekt (vgl. Rey, 2009, S. 112), könnten deren Einfluss auf den Lernerfolg bei Studierenden exakter bestimmen. In diesem Zusammenhang könnten solche Aspekte innerhalb der Lernumgebung weiter ausgebaut werden, die nachweislich zu einer Verbesserung führen. Ebenso könnten soziale Aspekte, wie z.B. das gemein-same Erstellen von Experimenten, implementiert und auf ihre Wirkung hin untersucht werden.

Durch eine Reintegration von Terrier bzw. eine Integration weiterer Retrieval-modelle, die bei Apache Lucene ab Version 4.0 möglich sind, können diese Modelle im Rahmen eines Assignments ausprobiert und verglichen werden. Darüber hinaus gibt es weitere Komponenten, die für neue Assignments ein-gesetzt werden können, z.B. Komponenten für das Relevance Feedback (vgl. Kürsten, 2012, S. 172ff. und S. 279ff.)

Erste Tests mit einer vom Benutzer programmierbaren Komponente wurden bereits durchgeführt, sind aber noch nicht ausreichend stabil für einen Ein-satz in der Lehre. Vor allem die Sicherheit gegenüber schadhaften Kompo-nenten wurde noch nicht näher untersucht. Zwar werden alle Komponenten innerhalb einer überwachten Laufzeitumgebung ausgeführt und lediglich vordefinierte Schnittstellen bereit gestellt, jedoch sind Sicherheitslücken bei der Verwendung externer Softwarebibliotheken, die für dieses Einsatzszena-rio nicht entwickelt wurden, wie z.B. Apache Lucene, nicht auszuschließen.

178

Ebenfalls denkbar sind Komponenten, die andersartige Anwendungsfälle bzw. Assignments ermöglichen, z.B. für ein Training zur Verbesserung von Suchanfrageformulierungen, wie es auch mit dem IR Game (siehe Kapitel 3.3.2) möglich ist.

Durch die Integration eines Dashboards könnten die Lernenden besser ihren Fortschritt überwachen und die folgenden Informationen auf einem Blick erfassen: „Wo stehe ich gerade?“, „Wo will ich hin?“ und ggf. „Wie komme ich dort hin?“ Diese Informationen können dazu beitragen, die Lernenden gezielter auf die Assignments und letztendlich die Lehrinhalte aufmerksam zu machen.

179

Literaturverzeichnis

Adcock, M., Haberfelde, M. & Szydlowski, A. (2007). Usability Study, IR Toolbox, TC 517. Lecture, University of Washington, Seattle, WA. Abgerufen am 4. Januar 2016, von http://michaeladcock.info/MLIS/papers/TC%20517%20Assignment%203.pdf

Amati, G. & Van Rijsbergen, C. (2002). Probabilistic models of information retrieval based on measuring the divergence from randomness. ACM Transactions on Information Systems, 20(4), 357-389. doi:10.1145/582415.582416

Baccini, A., Dejean, S., Lafage, L. & Mothe, J. (2011). How many performance measures to evaluate information retrieval systems?. Knowledge and Information Systems, 30(3), 693-713. doi:10.1007/s10115-011-0391-7

Baeza-Yates, R. & Ribeiro-Neto, B. (1999). Modern information retrieval. New York, NY, USA: ACM Press.

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Manifesto for Agile Software Development. Agilemanifesto.org. Abgerufen 29 April 2015, von http://www.agilemanifesto.org/

Becks, D., Eibl, M., Jü rgens, J., Kü rsten, J., Wilhelm, T. & Womser-Hacker, C. (2011). Does Patent IR Profit from Linguistics or Maximum Query Length?. CLEF 2011 Labs and Workshop, Notebook Papers, 19-22 September 2011, Amsterdam, The Netherlands, CEUR Workshop Proceedings, 1177.

180

Becks, D., Mandl, T. & Womser-Hacker, C. (2010). Phrases or Terms? The Impact of Different Query Types. CLEF 2010 LABs and Workshops, Notebook Papers, 22-23 September 2010, Padua, Italy, CEUR Workshop Proceedings, 1176.

Becks, D., Womser-Hacker, C., Mandl, T. & Kö lle, R. (2009). Patent Retrieval Experiments in the Context of the CLEF IP Track 2009. Multilingual Information Access Evaluation I. Text Retrieval Experiments, Lecture Notes in Computer Science, 6241, 491-496. doi:10.1007/978-3-642-15754-7_59

Blumenfeld, P., Kempler, T. & Krajcik, J. (2005). Motivation and Cognitive Engagement in Learning Environments. The Cambridge Handbook of the Learning Sciences, 475-488. doi:10.1017/cbo9780511816833.029

Bollmann-Sdorra, P. & Raghavan, V. (1993). On the delusiveness of adopting a common space for modeling IR objects: Are queries documents?. Journal of the American Society for Information Science, 44(10), 579-587. doi:10.1002/(sici)1097-4571(199312)44:10<579::aid-asi3>3.0.co;2-b

Boole, G. (1854). An investigation of the laws of thought. New York, NY, USA: Dover Publications.

Bortz, J. & Schuster, C. (2010). Statistik fur Human- und Sozialwissenschaftler. Berlin: Springer.

Buckley, C. & Voorhees, E. (2000). Evaluating Evaluation Measure Stability. Proceedings of the 23rd Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘00, 33-40. doi:10.1145/345508.345543

181

Buckley, C. & Voorhees, E. (2004). Retrieval evaluation with incomplete information. Proceedings of the 27th Annual International Conference on Research and Development in Information Retrieval - SIGIR ‘04. doi:10.1145/1008992.1009000

Calado, P., Cardoso-Cachopo, A. & Oliveira, A. (2007a). IR-BASE: An integrated framework for the research and teaching of information retrieval technologies. In Proceedings of the First international conference on Teaching and Learning of Information Retrieval - TLIR’07. Swinton, UK: British Computer Society.

Calado, P., Cardoso-Cachopo, A. & Oliveira, A. (2007b). IR-BASE: An Integrated Framework for the Research and Teaching of Information Retrieval Technologies. Presentation, First International Workshop on Teaching and Learning of Information Retrieval (TLIR 2007), London, UK. Abgerufen am 29. Juni 2015, von http://web.ist.utl.pt/acardoso/docs/2007-TLIR-IR-BASE-handout.pdf

Callan, J., Croft, W. & Harding, S. (1992). The INQUERY Retrieval System. Database and Expert Systems Applications, 78-83. doi:10.1007/978-3-7091-7557-6_14

Cleverdon, C. & Keen, M. (1966). Factors Determining the Performance of Indexing Systems: ASLIB Cranfield Research Project. Volume 2, Test results. Abgerufen von http://hdl.handle.net/1826/863

Cleverdon, C., Mills, J. & Keen, M. (1966). Factors Determining the Performance of Indexing Systems: ASLIB Cranfield Research Project. Volume 1, Design; Part 1, Text. Abgerufen von http://hdl.handle.net/1826/861

182

Cooper, W. (1971). A definition of relevance for information retrieval. Information Storage and Retrieval, 7(1), 19-37. doi:10.1016/0020-0271(71)90024-6

Croft, W., Metzler, D. & Strohman, T. (2010). Search engines - Information Retrieval in Practice. Boston: Addison-Wesley.

Jong, T. de & Joolingen, W. van (1998). Scientific Discovery Learning with Computer Simulations of Conceptual Domains. Review of Educational Research, 68(2), 179-201. doi:10.3102/00346543068002179

Demartini, G. & Mizzaro, S. (2006). A Classification of IR Effectiveness Metrics. Advances in Information Retrieval, Lecture Notes in Computer Science, 3936, 488-491. doi:10.1007/11735106_48

Derr, R. L. (1983). A conceptual analysis of information need. Information Processing & Management, 19(5), 273-278. doi:10.1016/0306-4573(83)90001-8

Deterding, S., Dixon, D., Khaled, R. & Nacke, L. (2011). From Game Design Elements to Gamefulness: Defining „Gamification“. Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments, MindTrek ‘11, 9-15. doi:10.1145/2181037.2181040

Domínguez, A., Saenz-de-Navarrete, J., De-Marcos, L., Fernández-Sanz, L., Pages, C. & Martínez-Herráiz, J. (2013). Gamifying learning experiences: Practical implications and outcomes. Computers & Education, 63, 380-392. doi:10.1016/j.compedu.2012.12.020

183

Downs, J., Holbrook, M., Sheng, S. & Cranor, L. (2010). Are your participants gaming the system?. Proceedings of the 28th International Conference on Human Factors in Computing Systems - CHI ‘10, 2399-2402. doi:10.1145/1753326.1753688

Eskola, A. (1988). Non-active role-playing: some experiences. Blind Alleys in Social Psychology. A Search for Ways out. Advances in Psychology, 48, 239-311.

Efthimiadis, E., Callan, J. & Larson, R. (2007). Approaches to teaching & learning information retrieval. Proceedings of the American Society for Information Science and Technology, 44(1), 1-3. doi:10.1002/meet.1450440136

Efthimiadis, E. & Freier, N. (2007). IR-Toolbox: An Experiential Learning Tool for Teaching IR. Proceedings of the 30th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘07, 914. doi:10.1145/1277741.1277982

Eibl, M. & Kü rsten, J. (2009). The Importance of being Grid: Chemnitz University of Technology at Grid@CLEF. Working Notes for CLEF 2009 Workshop co-located with the 13th European Conference on Digital Libraries (ECDL 2009), Corfu , Greece, September 30 - October 2, 2009., CEUR Workshop Proceedings, 1175.

Engler, D. & Proebsting, T. (1994). DCG: An efficient, retargetable dynamic code generation system. Proceedings of the Sixth International Conference on Architectural Support for Programming Languages and Operating Systems - ASPLOS-VI. doi:10.1145/195473.195567

184

Fang, H., Wu, H., Yang, P. & Zhai, C. (2014). VIRLab: A web-based virtual lab for learning and studying information retrieval models. Proceedings of the 37th International ACM SIGIR Conference on Research & Development in Information Retrieval - SIGIR ‘14, 1249-1250. doi:10.1145/2600428.2611178

Fang, H. & Zhai, C. (2014). VIRLab: A Platform for Privacy-Preserving Evaluation for Information Retrieval Models. In Proceedings of the 1st International Workshop on Privacy-Preserving IR: When Information Retrieval Meets Privacy and Security - PIR 2014, 37.

Fernández-Luna, J., Huete, J., MacFarlane, A. & Efthimiadis, E. (2009). Teaching and learning in information retrieval. Information Retrieval, 12(2), 201-226. doi:10.1007/s10791-009-9089-9

Fernández-Luna, J., Huete, J., Olvera, P., Peña, A., Del Carmen Rodríguez-Hernández, M. & Rodríguez-Cano, J. (2012). SulaIR: una plataforma de apoyo a la enseñanza y al aprendizaje de la recuperación de información. In II Congreso Español de Recuperación de Información (CERI 2012). Valencia, Spanien. Abgerufen am 7. Januar 2016, von http://users.dsic.upv.es/grupos/nle/ceri/papers/ceri2012_luna_sulair.pdf

Fernández-Luna, J., Huete, J., Rodríguez-Cano, J. & Rodríguez, M. (2012). Teaching and Learning Information Retrieval Based on a Visual and Interactive Tool: SulaIR. EDULEARN12 Proceedings, 6634-6642.

Fuhr, N. & Klas, C. (2014). Information uber die Fachgruppe - Fachgruppe Information Retrieval. Gesellschaft fur Informatik. Abgerufen am 6. August 2015, von http://fg-retrieval.gi.de/startseite/information-ueber-die-fachgruppe.html

185

Grubinger, M., Clough, P., Müller, H. & Deselaers, T. (2006). The IAPR Benchmark: A New Evaluation Resource for Visual Information Systems. In International Conference on Language Resources and Evaluation. Genua, Italien. Abgerufen von http://ir.shef.ac.uk/Cloughie/papers/ontoimage2006-2.pdf

Halttunen, K. & Järvelin, K. (2005). Assessing learning outcomes in two information retrieval learning environments. Information Processing & Management, 41(4), 949-972. doi:10.1016/j.ipm.2004.02.004

Halttunen, K. & Sormunen, E. (2000). Learning Information Retrieval through an Educational Game. Is Gaming sufficient for learning?. Education for Information, 18(4), 289-311.

Harman, D. (1993). Overview of the First TREC Conference. Proceedings of the 16th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘93, 36-47. doi:10.1145/160688.160692

Harman, D. (1995). Overview of the Second Text Retrieval Conference (TREC-2). Proceedings of the Second Conference on Text Retrieval Conference - TREC-2, 271-289. doi:10.1016/0306-4573(94)00047-7

Hendry, D. (2007). History places: A case study for relational database and information retrieval system design. ACM Journal of Educational Resources in Computing, 7(1). doi:10.1145/1227846.1227849

Hendry, I., Willett, P. & Wood, F. (1986a). INSTRUCT: a teaching package for experimental methods in information retrieval. Part I. The users view. Program: Electronic Library and Information Systems, 20(3), 245-263. doi:10.1108/eb046940

186

Hendry, I., Willett, P. & Wood, F. (1986b). INSTRUCT: a teaching package for experimental methods in information retrieval. Part II. Computational aspects. Program: Electronic Library and Information Systems, 20(4), 382-393. doi:10.1108/eb046949

Hiemstra, D. (2009). Information Retrieval Models. In A. Goker & J. Davies, Information Retrieval. Chichester, UK: John Wiley and Sons.

Hjørland, B. (2010). The foundation of the concept of relevance. Journal of the American Society for Information Science and Technology, 61(2), 217-237. doi:10.1002/asi.21261

Järvelin, K., Kekäläinen, J. (2000). IR Evaluation Methods for Retrieving Highly Relevant Documents. Proceedings of the 23rd Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘00, 41-48. doi:10.1145/345508.345545

Järvelin, K. & Kekäläinen, J. (2002). Cumulated gain-based evaluation of IR techniques. ACM Transactions on Information Systems, 20(4), 422-446. doi:10.1145/582415.582418

Jenkins, M. & Smith, D. (2005). Conservative stemming for search and indexing. Abgerufen am 9. Dezember 2015, von http://lemur.cmp.uea.ac.uk/Research/stemmer/stemmer25feb.pdf

Jung, S. & Lawrance, J. (2011). Web information retrieval and filtering course to undergraduates using open source programming. ACM Inroads, 2(3), 47. doi:10.1145/2003616.2003634

187

Jurjevic, D., Stö cklin, N. & Hartmann, W. (2009). Informationskompetenz: Ein Thema fü r den Informatikunterricht. Zukunft braucht Herkunft: 25 Jahre „INFOS - Informatik und Schule“. 13. GI-Fachtagung „Informatik und Schule“, 21. bis 24. September 2009 an der Freien Universita t Berlin, LNI, 316-327.

Kirchhoff, S., Kuhnt, S., Lipp, P. & Schlawin, S. (2010). Der Fragebogen: Datenbasis, Konstruktion und Auswertung. doi:10.1007/978-3-531-92050-4

Kluck, M. (2002). GIRT - Mono- and Cross-Language Domain-Specific Information Retrieval (GIRT4). Cross-Language Evaluation Forum. Abgerufen am 1. Januar 2016, von http://clef.isti.cnr.it/2003/GIRT2003/girt4.html

Krovetz, R. (1993). Viewing morphology as an inference process. Proceedings of the 16th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘93, 191-202. doi:10.1145/160688.160718

Kuhlen, R. (1990). Zum Stand pragmatischer Forschung in der Informationswissenschaft. In 1. Internationalen Symposiums fur Informationswissenschaft, ISI 1990 (S. 13-18). Konstanz: Univ.-Verl. Konstanz.

Kuhlen, R. (2013). Information – Informationswissenschaft. In R. Kuhlen, W. Semar & D. Strauch, Grundlagen der praktischen Information und Dokumentation (6. Auflage, S. 1-24). Berlin: Walter de Gruyter.

188

Kü rsten, J. (2009). Chemnitz at CLEF 2009 Ad-Hoc TEL Task: Combining Different Retrieval Models and Addressing the Multilinguality. Working Notes for CLEF 2009 Workshop co-located with the 13th European Conference on Digital Libraries (ECDL 2009), Corfu , Greece, September 30 - October 2, 2009., CEUR Workshop Proceedings, 1175.

Kürsten, J. (2012). A generic approach to component-level evaluation in information retrieval (Dr.-Ing.). Technische Universität Chemnitz.

Kü rsten, J. & Eibl, M. (2007a). Domain-Specific Cross Language Retrieval: Comparing and Merging Structured and Unstructured Indices. Working Notes for CLEF 2007 Workshop co-located with the 11th European Conference on Digital Libraries (ECDL 2007), Budapest, Hungary, September 19-21, 2007., CEUR Workshop Proceedings, 1173.

Kürsten, J. & Eibl, M. (2007b). Monolingual Retrieval Experiments with a Domain-Specific Document Corpus at the Chemnitz University of Technology. Evaluation of Multilingual and Multi-Modal Information Retrieval, Lecture Notes in Computer Science, 4730, 178-185. doi:10.1007/978-3-540-74999-8_26

Kürsten, J. & Eibl, M. (2010). Video Classification as IR Task: Experiments and Observations. Multilingual Information Access Evaluation II. Multimedia Experiments, Lecture Notes in Computer Science, 6242, 377-384. doi:10.1007/978-3-642-15751-6_49

Kü rsten, J., Kundisch, H. & Eibl, M. (2008). QA Extension for Xtrieval: Contribution to the QAst track. Working Notes for CLEF 2008 Workshop co-located with the 12th European Conference on Digital Libraries (ECDL 2008), Aarhus, Denmark, September 17-19, 2008., CEUR Workshop Proceedings, 1174.

189

Kürsten, J., Richter, D. & Eibl, M. (2009). VideoCLEF 2008: ASR Classification with Wikipedia Categories. Evaluating Systems for Multilingual and Multimodal Information Access, Lecture Notes in Computer Science, 5706, 931-934. doi:10.1007/978-3-642-04447-2_123

Kü rsten, J. & Wilhelm, T. (2008). Extensible Retrieval and Evaluation Framework: Xtrieval. LWA 2008 - Workshop-Woche: Lernen, Wissen & Adaptivitä t, Wü rzburg, 6.-8. Oktober 2008, Proceedings, Technical Report, 107-110.

Kü rsten, J., Wilhelm, T. & Eibl, M. (2007). The XTRIEVAL Framework at CLEF 2007: Domain-Specific Track. Advances in Multilingual and Multimodal Information Retrieval, Lecture Notes in Computer Science, 5152, 174-181. doi:10.1007/978-3-540-85760-0_23

Kü rsten, J., Wilhelm, T. & Eibl, M. (2008). CLEF 2008 Ad-Hoc Track: On-line Processing Experiments with Xtrieval. Working Notes for CLEF 2008 Workshop co-located with the 12th European Conference on Digital Libraries (ECDL 2008), Aarhus, Denmark, September 17-19, 2008., CEUR Workshop Proceedings, 1174.

Kü rsten, J., Wilhelm, T. & Eibl, M. (2009a). CLEF 2008 Ad-Hoc Track: Comparing and Combining Different IR Approaches. Evaluating Systems for Multilingual and Multimodal Information Access, Lecture Notes in Computer Science, 5706, 75-82. doi:10.1007/978-3-642-04447-2_8

Kürsten, J., Wilhelm, T. & Eibl, M. (2009b). The Xtrieval Framework at CLEF 2008: Domain-Specific Track. Evaluating Systems for Multilingual and Multimodal Information Access, Lecture Notes in Computer Science, 5706, 215-218. doi:10.1007/978-3-642-04447-2_27

190

Kü rsten, J., Wilhelm, T. & Eibl, M. (2011). Vergleich von IR-Systemkonfigurationen auf Komponentenebene. Information und Wissen: global, sozial und frei? Proceedings des 12. Internationalen Symposiums fu r Informationswissenschaft, ISI 2011, Hildesheim, Germany, 9.-11. Ma rz 2011., Schriften zur Informationswissenschaft, 47-59.

Kü rsten, J., Wilhelm, T., Richter, D. & Eibl, M. (2012). Chemnitz at the CHiC Evaluation Lab 2012: Creating an Xtrieval Module for Semantic Enrichment. CLEF 2012 Evaluation Labs and Workshop, Online Working Notes, Rome, Italy, September 17-20, 2012, CEUR Workshop Proceedings, 1178.

Larson, R. (2010). Multilingual Query Expansion for CLEF Adhoc-TEL. Multilingual Information Access Evaluation I. Text Retrieval Experiments, Lecture Notes in Computer Science, 6241, 86-89. doi:10.1007/978-3-642-15754-7_9

Ló pez-Garcí a, R. & Cacheda, F. (2011). A Technical Approach to Information Retrieval Pedagogy. Teaching and Learning in Information Retrieval, The Information Retrieval Series, 31, 89-105. doi:10.1007/978-3-642-22511-6_7

Luhn, H. P. (1958). The Automatic Creation of Literature Abstracts. IBM Journal of Research and Development, 2(2), 159-165. doi:10.1147/rd.22.0159

Lux, M., Klieber, W. & Granitzer, M. (2004). Caliph & Emir: Semantics in Multimedia Retrieval and Annotation. In Proceedings of the 19th International CODATA Conference, 64-75.

191

Manning, C., Raghavan, P. & Schütze, H. (2008). Introduction to Information Retrieval. New York: Cambridge University Press. doi:10.1017/cbo9780511809071

Maron, M. & Kuhns, J. (1960). On Relevance, Probabilistic Indexing and Information Retrieval. Journal of the ACM, 7(3), 216-244. doi:10.1145/321033.321035

Martens, R., Gulikers, J. & Bastiaens, T. (2004). The impact of intrinsic motivation on e-learning in authentic computer tasks. Journal of Computer Assisted Learning, 20(5), 368-376. doi:10.1111/j.1365-2729.2004.00096.x

Martínez-Comeche, J. & Cacheda, F. (2011). Information Retrieval Systems Evaluation: Learning and Teaching Process. Teaching and Learning in Information Retrieval, The Information Retrieval Series, 31, 123-135. doi:10.1007/978-3-642-22511-6_9

McCown, F. (2010). Teaching web information retrieval to undergraduates. Proceedings of the 41st ACM Technical Symposium on Computer Science Education - SIGCSE ‘10. doi:10.1145/1734263.1734294

Memmel, T., Reiterer, H. & Holzinger, A. (2008). Agile Methods and Visual Specification in Software Development: A Chance to Ensure Universal Access. Universal Access in Human-Computer Interaction, Lecture Notes in Computer Science, 4554, 453-462. doi:10.1007/978-3-540-73279-2_51

Mizzaro, S. (1997). Relevance: The whole history. Journal of the American Society for Information Science, 48(9), 810-832. doi:10.1002/(sici)1097-4571(199709)48:9<810::aid-asi6>3.0.co;2-u

192

Mizzaro, S. (1998). How many relevances in information retrieval?. Interacting with Computers, 10(3), 303-320. doi:10.1016/S0953-5438(98)00012-5

Moffat, A. & Zobel, J. (2008). Rank-biased precision for measurement of retrieval effectiveness. ACM Transactions on Information Systems, 27(1), 2:1-2:27. doi:10.1145/1416950.1416952

Mohd, M. (2011). Development of Search Engines using Lucene: An Experience. Procedia - Social and Behavioral Sciences, 18, 282-286. doi:10.1016/j.sbspro.2011.05.040

Montola, M., Nummenmaa, T., Lucero, A., Boberg, M. & Korhonen, H. (2009). Applying Game Achievement Systems to Enhance User Experience in a Photo Sharing Service. Proceedings of the 13th International MindTrek Conference: Everyday Life in the Ubiquitous Era, MindTrek ‘09, 94-97. doi:10.1145/1621841.1621859

Myers, E. (1986). An O(ND) difference algorithm and its variations. Algorithmica, 1(1-4), 251-266. doi:10.1007/bf01840446

Ounis, I., Amati, G., Plachouras, V., He, B., Macdonald, C. & Lioma, C. (2006). Terrier: A High Performance and Scalable Information Retrieval Platform. In Second International Workshop on Open Source Information Retrieval - OSIR 2006. Seattle, WA, USA.

Peters, C. (2001). Introduction. Cross-Language Information Retrieval and Evaluation, 1-6. doi:10.1007/3-540-44645-1_1

Petras, V., Bogers, T., Ferro, N. & Masiero, I. (2013). Cultural Heritage in CLEF (CHiC) 2013 - Multilingual Task Overview. Working Notes for CLEF 2013 Conference, Valencia, Spain, September 23-26, 2013., CEUR Workshop Proceedings, 1179.

193

Piroi, F., Lupu, M., Hanbury, A., Sexton, A., Magdy, W. & Filippov, I. (2012) CLEF-IP 2012: Retrieval Experiments in the Intellectual Property Domain. Abgerufen am 3. Dezember 2015, von http://www.clef-initiative.eu/documents/71612/c30f390b-dec6-4ba0-a423-daea1a30f256

Porter, M. (1980). An algorithm for suffix stripping. Program: Electronic Library and Information Systems, 14(3), 130-137. doi:10.1108/eb046814

Porter, M. (2006). Porter Stemming Algorithm. Abgerufen am 21. Januar 2016, von http://tartarus.org/martin/PorterStemmer/

Rey, G. (2009). E-Learning : Theorien, Gestaltungsempfehlungen und Forschung. Bern, Schweiz: Huber.

Robertson, S. (2004). Understanding inverse document frequency: on theoretical arguments for IDF. Journal of Documentation, 60(5), 503-520. doi:10.1108/00220410410560582

Robertson, S. (2006). On GMAP: And Other Transformations. Proceedings of the 15th ACM International Conference on Information and Knowledge Management - CIKM ‘06, 78-83. doi:10.1145/1183614.1183630

Robertson, S. (2012). On Smoothing Average Precision. Advances in Information Retrieval, Lecture Notes in Computer Science, 7224, 158-169. doi:10.1007/978-3-642-28997-2_14

Robertson, S. & Spärck Jones, K. (1976). Relevance weighting of search terms. Journal of the American Society for Information Science, 27(3), 129-146. doi:10.1002/asi.4630270302

194

Ruthven, I., Elsweiler, D. & Nicol, E. (2008). Designing for users: an holistic approach to teaching Information Retrieval. In Second International Workshop on Teaching and Learning of Information Retrieval (TLIR 2008). Swinton, UK: British Computer Society.

Ryan, R. & Deci, E. (2000). Intrinsic and Extrinsic Motivations: Classic Definitions and New Directions. Contemporary Educational Psychology, 25(1), 54-67. doi:10.1006/ceps.1999.1020

Salton, G. (1991). The smart document retrieval project. Proceedings of the 14th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘91, 356-358. doi:10.1145/122860.122897

Salton, G., Fox, E. & Wu, H. (1983). Extended Boolean information retrieval. Communications of the ACM, 26(11), 1022-1036. doi:10.1145/182.358466

Salton, G. & Harman, D. (2003). Information Retrieval. In Encyclopedia of Computer Science, 858-863. Chichester, UK: John Wiley and Sons.

Salton, G. & Lesk, M. (1965). The SMART automatic document retrieval systems---an illustration. Communications of the ACM, 8(6), 391-398. doi:10.1145/364955.364990

Salton, G. & McGill, M. (1983). Introduction to modern information retrieval. New York, NY, USA: McGraw-Hill.

Sanderson, M. (2010). Test Collection Based Evaluation of Information Retrieval Systems. Foundations and Trends in Information Retrieval, 4(4), 247-375. doi:10.1561/1500000009

195

Saracevic, T. (1975). RELEVANCE: A review of and a framework for the thinking on the notion in information science. Journal of the American Society for Information Science, 26(6), 321-343. doi:10.1002/asi.4630260604

Savoy, J. (2014). IR Multilingual Resources at UniNE. Abgerufen am 4. Dezember 2015, von http://members.unine.ch/jacques.savoy/clef/

Schmidt, J. (2014). Programmiersprachen-Ranking: Java und JavaScript besonders stark. Abgerufen am 12. Dezember 2015, von http://heise.de/-2096697

Schmidt, K., Korner, T., Heinich, S. & Wilhelm, T. (2011). A Two-step Approach to Video Retrieval based on ASR transcriptions. Working Notes Proceedings of the MediaEval 2011 Workshop, Santa Croce in Fossabanda, Pisa, Italy, September 1-2, 2011, CEUR Workshop Proceedings, 807.

Schneider, A. Farbeinflussfaktoren zur emotionalen Bildwirkung und ihre Bedeutung fur das Retrieval von Tourismusbildern (unveröffentlichte Dissertation). Technische Universität Chemnitz, Fakultät für Informatik. 192-197.

Schulmeister, R. (2002). Taxononomie der Interaktivität von Multimedia- Ein Beitrag zur aktuellen Metadaten-Diskussion. It - Information Technology, 44(4/2002), 193-199. doi:10.1524/itit.2002.44.4.193

Shuyo, N. (2010). Language Detection Library for Java. Abgerufen am 29. November 2015, von https://github.com/shuyo/language-detection

196

Sormunen, E. (2002). Liberal relevance criteria of TREC -: counting on negligible documents? Proceedings of the 25th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR ‘02, 324-330. doi:10.1145/564376.564433

Sormunen, E., Hokkanen, S., Kangaslampi, P., Pyy, P. & Sepponen, B. (2002). Query performance analyser - a web-based tool for IR research and instruction. In 25th ACM/SIGIR International Conference on Research and Development in Information Retrieval (S. 450). New York, NY, USA: ACM. doi:10.1145/564376.564491

Sormunen, E., Laaksonen, J., Keskustalo, H., Kekäläinen, J., Kemppainen, H., Laitinen, H., … & Järvelin, K. (1998). The IR Game-A Tool for Rapid Query Analysis in Cross-Language IR Experiments. In PRICAI’98 Workshop on Cross Language Issues in Artificial Intelligence, 22-32.

Spärck Jones, K. (1973). Index term weighting. Information Storage and Retrieval, 9(11), 619-633. doi:10.1016/0020-0271(73)90043-0

Spärck Jones, K., Walker, S. & Robertson, S. (2000). A probabilistic model of information retrieval: development and comparative experiments. Information Processing & Management, 36(6), 779-808. doi:10.1016/s0306-4573(00)00015-7

Spärck Jones, K. & Willett, P. (1997). Readings in information retrieval. San Francisco, CA, USA: Morgan Kaufman.

Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285. doi:10.1016/0364-0213(88)90023-7

197

SwissEduc. (2014). SwissEduc - Informatik - Soekia – eine didaktische Suchmaschine. Abgerufen am 26. Januar 2016, von http://www.swisseduc.ch/informatik/soekia/screenshots.html

Wilhelm, T. (2008). Entwurf und Implementierung eines Frameworks zur Analyse und Evaluation von Verfahren im Information Retrieval (Dipl.-Inf.). Technische Universität Chemnitz, Fakultät für Informatik.

Wilhelm, T. & Eibl, M. (2006). ImageCLEF 2006 Experiments at the Chemnitz Technical University. Evaluation of Multilingual and Multi-modal Information Retrieval, Lecture Notes in Computer Science, 4730, 739-743. doi:10.1007/978-3-540-74999-8_93

Wilhelm, T., Kü rsten, J. & Eibl, M. (2007). Experiments for the ImageCLEF 2007 Photographic Retrieval Task. Working Notes for CLEF 2007 Workshop co-located with the 11th European Conference on Digital Libraries (ECDL 2007), Budapest, Hungary, September 19-21, 2007., CEUR Workshop Proceedings, 1173.

Wilhelm, T., Kü rsten, J. & Eibl, M. (2008a). The Xtrieval Framework at CLEF 2008: ImageCLEF Photographic Retrieval Task. Working Notes for CLEF 2008 Workshop co-located with the 12th European Conference on Digital Libraries (ECDL 2008), Aarhus, Denmark, September 17-19, 2008., CEUR Workshop Proceedings, 1174.

Wilhelm, T., Kü rsten, J. & Eibl, M. (2008b). The Xtrieval Framework at CLEF 2008: ImageCLEF Wikipedia MM task. Working Notes for CLEF 2008 Workshop co-located with the 12th European Conference on Digital Libraries (ECDL 2008), Aarhus, Denmark, September 17-19, 2008., CEUR Workshop Proceedings, 1174.

198

Wilhelm, T., Kü rsten, J. & Eibl, M. (2011). A tool for comparative IR evaluation on component level. Proceeding of the 34th International ACM SIGIR Conference on Research and Development in Information Retrieval - SIGIR 2011, 1291-1292. doi:10.1145/2009916.2010165

Wilhelm, T., Kü rsten, J. & Eibl, M. (2012). Chemnitz at CLEF IP 2012: Advancing Xtrieval or a Baseline Hard to Crack. CLEF 2012 Evaluation Labs and Workshop, Online Working Notes, Rome, Italy, September 17-20, 2012, CEUR Workshop Proceedings, 1178.

Wilhelm-Stein, T. & Eibl, M. (2013). A Quantitative Look at the CLEF Working Notes. Information Access Evaluation. Multilinguality, Multimodality, and Visualization, Lecture Notes in Computer Science, 8138, 13-16. doi:10.1007/978-3-642-40802-1_2

Wilhelm-Stein, T. & Eibl, M. (2015). A Tool for Enhancing the Understanding of Information Retrieval System Components for Educational Purposes. Re:inventing Information Science in the Networked Society. Proceedings of the 14th International Symposium on Information Science, ISI 2015, Zadar, Croatia, May 19-21, 2015, Schriften zur Informationswissenschaft, 55, 590-592.

Wilhelm-Stein, T., Schü rer, B. & Eibl, M. (2013). Identifying the Most Suitable Stemmer for the CHiC Multilingual Ad-hoc Task. Working Notes for CLEF 2013 Conference, Valencia, Spain, September 23-26, 2013., CEUR Workshop Proceedings, 1179.

Yang, P. (2015). Welcome to Virtual IR Lab (VIRLab). Virtual IR Lab. Abgerufen am 7. Januar 2016, von http://infolab.ece.udel.edu:8008/

Yu, C. & Salton, G. (1976). Precision Weighting - An Effective Automatic Indexing Method. Journal of the ACM, 23(1), 76-88. doi:10.1145/321921.321930

199

Zichermann, G. & Cunningham, C. (2011). Gamification by design. Sebastopol, CA, USA: O’Reilly Media.

201

Anhang A: Assignments

Ein einfaches Experiment

Ein Experiment zur Evaluation eines Information Retrieval Systems besteht aus zwei Teilen: Der Erstellung eines Indexes, auch Indizierung 1 genannt, und der Suche 3 in diesem Index.

Beide Teile setzen sich aus je drei wesentlichen Schritten zusammen: De-finition/Auswahl einer Datenquelle, Verarbeitung der Daten in eine interne Repräsentation und die Verarbeitung der internen Repräsentation zu einem Ergebnis (z.B. dem Index bei der Indizierung).

In dieser Aufgabe wird zuerst ein Index erstellt, der dann anhand von vorgegebenen Suchanfragen (sogenannten Topics) durchsucht wird.

– Die Indizierung [1] beginnt mit einem Dataset (XML). Als Dataset soll die englische Fassung von ImageCLEF verwendet werden. Diese besteht aus 20.000 annotierten, touristischen Fotos, die vor allem in Südamerika entstanden sind. Füge die entsprechende Komponente jetzt ein und wähle als Dataset “ImageCLEF (en)” aus.

– Hinweis: Rechts neben der Dataset-Komponente erscheint nach der Auswahl des Korpus die Vorschau eines Dokuments. Mit Hilfe der “Preview Settings” (rechts oben) kannst du die Vorschau anpassen und so den Fokus auf den Titel (title) legen.

– Füge als nächste Komponente den “Lucene Tokenizer” ein. Er zer-legt zusammenhängende Textblöcke in einzelne Wörter, die in den folgenden Schritten weiterverarbeitet werden können.

202

– Hinweis: Neben jeder Komponente wird der Zustand eines Vor-schaudokumentes nach der Verarbeitung durch die Komponente angezeigt. In den “Preview Settings” gibt es auch eine Einstellung um Veränderungen hervorzuheben (Highlight changes).

– Schließe die Indizierung mit der Komponente “Lucene Index” ab. Diese erzeugt einen Index, der später für die Suche verwendet wer-den kann.

– Hinweis: Nachdem du alle Komponenten für den Index ausgewählt hast, wird der Index sofort erstellt und einige statistische Daten über ihn unter dem Punkt “Index Analysis” [2] angezeigt. Hier kannst du neben der Anzahl indizierter Dokumente und der Größe des Index auch die Häufigkeiten verschiedener Wörter im Index untersuchen.

– Die Suche [3] beginnt mit der Komponente “Topicset”. Ein Topicset besteht aus mehreren vordefinierten Suchanfragen (Topics), die auf das Dataset abgestimmt sind und verschiedene Themen und Schwierigkeitsgrade umfassen. Dies soll die Vergleichbarkeit von verschiedenen Retrieval Systemen sicherstellen.

Wähle nun das Topicset “2006 (en)” aus. Es umfasst 60 Suchan-fragen in englischer Sprache, z.B. “accomodation with swimming pool”, “animal swimming” oder “church with more than two towers”.

– Hinweis: Auch hier wird neben der Komponente eine Vorschau einer Suchanfrage aus dem Topicset angezeigt.

– Im Allgemeinen werden auf die Suchanfrage die gleichen Verarbei-tungsschritte, wie bei der Indizierung angewendet, da nur so ein sinnvolles Matching (Vergleich) möglich ist. Ausnahmen sind z.B. Synonyme, die nur einmal bei der Indizierung oder bei der Suche angewendet werden sollten.

203

Es folgt also der gleiche Tokenizer wie bei der Indizierung [1].

– Schließe die Suche [3] mit der “Lucene Search” ab. Die verarbeiteten Suchanfragen werden hier im Index [2] gesucht und eine Ergebnis-liste erstellt.

Hinweis: In “Search Results” [4] erscheinen nach der Indizierung und der Suche die Evaluationsergebnisse. Diese bestehen aus zwei Teilen:

Im oberen Teil sind die Evaluationsmetriken zu finden: Ein Standard-maß ist die Mean Average Precision (kurz MAP). Sie kann Werte von 0 bis 1 annehmen. Je größer die MAP, desto besser ist das System.

Im unteren Teil ist links eine Liste mit allen Suchanfragen (Topics). Rechts daneben findest du eine Übersicht der ersten 100 Ergebnis-se geordnet nach der vom System berechneten Relevanz (score). Die oben eingerahmten Ergebnisse werden darunter detailiert angezeigt. Tatsächlich relevante Ergebnisse sind grün hervorgeho-ben. Die ausgewählte Topic “1 accomodation with swimming pool” enthält noch keine relevanten Ergebnisse. Dies sieht für die Topics “8 host family posing for a photo” oder “21 accomodation provided by host families” deutlich besser aus.

Dieses Experiment ist nun unsere “Baseline”. D.h. alle Verbesserun-gen müssen sich an ihr messen lassen.

Felder & Filter

Dokumente bestehen meist aus mehreren Felden, d.h. aus verschiedenen Teilen, die mit einer Bezeichnung versehen sind. Z.B. haben Dokumente

204

häufig einen Titel, ein Erstellungsdatum und einen Inhalt. Nicht jeder Doku-mentteil ist für eine Suche nützlich und sollte deshalb nicht indiziert werden.

Filter im Rahmen dieser Übung sind als Vorverarbeitungsschritte zu ver-stehen. Durch sie werden Tokens, die durch den Tokenizer erzeugt werden, verändert, entfernt oder ergänzt. Hier soll ein einfacher Filter zur Kleinschrei-bung aller Buchstaben angewendet werden.

– Der Ausgangspunkt ist unser einfaches Experiment. Füge folgende Komponente für die Indizierung [1] ein: Dataset (XML) mit “ImageC-LEF (en)”, Lucene Tokenizer und Lucene Index.

– Folgende Komponenten gehören in die Suche [3]: Topicset mit “2006 (en)”, Lucene Tokenizer und Lucene Search.

– Hinweis: Nachdem Indizierung [1] und Suche [3] erfolgreich zusam-mengestellt wurden, erscheint erst einmal das gleiche Ergebnis [4] wie beim einfachen Experiment. Diese “Baseline” soll nun durch zusätzliche Komponenten und Einstellungen verbessert werden.

– Zur Zeit wird lediglich das Feld “title” durchsucht. Um auch andere Felder durchsuchen zu können, kann deren Inhalt mit der “Bag of Words”-Komponente in das Feld “title” übertragen werden.

Füge die “Bag of Words”-Komponente bei der Indizierung [1] zwi-schen Tokenizer und Index ein. Nun wähle das Feld “description” aus. Es enthält eine ausführliche Beschreibung der Fotos und sollte so die Suche nach bestimmten Inhalten verbessern.

– Füge bei der Indizierung [1] den “Lowercase Filter” vor dem Index ein. Er verändert alle Großbuchstaben in Kleinbuchstaben, so dass Unterschiede in der Groß- bzw. Kleinschreibung keinen Einfluss mehr auf das Ergebnis haben.

205

– Manche Filter müssen auch bei der Suche angewendet werden, damit die Form der Suchanfragen zur Form der Dokumente passt. Falls im Index alle Wörter klein geschrieben sind und eine Suchan-frage Großbuchstaben enthält, werden keine Dokumente gefunden.

Füge bei der Suche [3] den “Lowercase Filter” direkt vor der Lucene Suche ein. Die Ergebnislisten enthalten nun mehr relevante (grün hervorgehobene) Dokumente als zuvor.

– Die Güte der Ergebnisse können neben der MAP auch mit Hilfe des Precision/Recall-Graphen untersucht werden. Hier gilt: Je höher die Linie verläuft, desto besser ist das Ergebnis.

Du kannst jetzt mit der nächsten Aufgabe fortfahren oder versuchen die Feldauswahl des “Bag of Words” zu verändern um bessere Er-gebnisse zu erzielen.

– Folgende Erfolge/Achievements sind möglich:

– Precision (1 Stern)

Stemming (1)

In der deutschen Sprache können sich Wörter durch ihren Kontext verändern. So werden aus einem “Baum” mehrere “Bäume” oder jemand “sang” gestern und “singt” heute. Diese Flexionen sind oft durch Suffixe gekennzeichnet, können ein Wort aber auch tiefgreifend verändern. Andere Sprachen nutzen ebenso Flexionen. So wird zum Beispiel im Englischen aus “you do” bei ei-nem Wechsel der Person “he does”.

Im Information Retrieval können Flexionen beim Vergleich von Suchan-frage und Dokumenten hinderlich sein. Das sogenannte Stemming ist ein

206

Verfahren, um Wörter, die durch Flexion verändert wurden, auf eine Stamm-form zu reduzieren. Wenn nun nach “Baum” gesucht wird, werden auch Dokumente die “Bäume” enthalten gefunden.

– Der Ausgangspunkt ist unser einfaches Experiment. Füge folgende Komponente für die Indizierung [1] ein: Dataset (XML) mit “ImageC-LEF (en)”, Lucene Tokenizer und Lucene Index.

– Folgende Komponenten gehören in die Suche [3]: Topicset mit “2006 (en)”, Lucene Tokenizer und Lucene Search.

– Hinweis: Nachdem Indizierung [1] und Suche [3] erfolgreich zusam-mengestellt wurden, erscheint erst einmal das gleiche Ergebnis [4] wie beim einfachen Experiment. Diese “Baseline” soll nun durch zusätzliche Komponenten und Einstellungen verbessert werden.

– Als erstes Stemming-Verfahren wollen wir n-Grams anwenden. Dazu fügen wir in [1] vor dem “Lucene Index” die Komponente “n-Gram Stemmer” ein.

– Hinweis: Beim n-Gram Stemming werden Wörter in sich überlappen-de Teilwörter mit der Länge n zerlegt. Bei n=3 wird z.B. aus “Trees” wird “Tre”, “ree”, “ees”. Diese Zerlegung kann unabhängig von der verwendeten Sprache vorgenommen werden und ist vor allem bei zusammengesetzten Worten nützlich.

– Das “n-Gram Stemming” muss ebenso bei der Suche [3] angewen-det werden, damit das Matching korrekt durchgeführt werden kann. Füge also die Komponente in die Suche [3] direkt vor der “Lucene Suche” ein.

– Ein Blick auf die Ergebnisse zeigt eine signifikante Verbesserung. Die Mean Average Precision (MAP) liegt nun bei etwa 0.06 (vorher

207

0.04). Durch folgende Maßnahmen kannst du das Ergebnis weiter verbessern:

– Veränderung der Wortlänge n des “n-Gram Stemmers”– Verwendung des “Bag of Words” und des “Lowercase

Filters”

– Folgende Erfolge/Achievements sind möglich:

– Stemming (1 Stern)

Stemming (2)

Eine andere Art von Stemmern (neben n-Gram Stemmern) sind Regel-basier-te Stemmer. Das Ziel von Regel-basierten Stemmern ist nicht den korrekten Wortstamm zu bestimmen, sondern verschiedene Flexionen auf einen glei-chen “Wortstamm” zu reduzieren um das Matching zu gewährleisten.

– Der Ausgangspunkt ist erneut unser einfaches Experiment beste-hend aus: [1] Dataset (XML) mit “ImageCLEF (en)”, Lucene Tokeni-zer, Lucene Index und [3] Topicset mit “2006 (en)”, Lucene Tokenizer, Lucene Search.

– Ein Regel-basierte Stemming-Komponete ist der Snowball Stemmer. Anhand verschiedener Regeln entfernt dieser Suffixe. Der bekannte Porter Stemmer ist auch im Snowball Stemmer verfügbar. Füge in [1] vor dem Index die Komponente “Snowball Stemmer” ein und wähle “Porter” aus.

– Auch dieser Stemmer muss auf die Suchanfragen bei der Suche [3] angewendet werden. Füge ihn vor der “Lucene Search” ein und wähle auch hier “Porter” aus.

208

– Durch folgende Maßnahmen kannst du das Ergebnis weiter verbessern:

– Verwendung des “Bag of Words” und des “Lowercase Filters”

– Auswahl eines anderen Stemmer-Programms

– Folgende Erfolge/Achievements sind möglich:

– Stemming (2 Sterne)– Precision (2 Sterne)

Stoppwörter

Stoppwörter sind Wörter, die keine signifikanten Informationen tragen, son-dern vielmehr Wörter miteinander verbinden. Sie treten wiederholt auf und lassen sich deshalb an ihrer Häufigkeit im Text gut erkennen. Bei der Indizie-rung kann es von Vorteil sein diese Wörter zu entfernen. Das Wort “und” im Index eines Buches würde wahrscheinlich jede Seite des Buches auflisten und somit nutzlos für eine Suche sein.

Das Entfernen von Stoppwörtern kann auch nachteilig sein. Das bekannte Zitat “To be or not to be” besteht ausschließlich aus Stoppwörtern und hätte deshalb keine Repräsentation im Index.

Ein Stoppwort-Filter arbeitet mit einer vordefinierten Liste von Wörtern, die bei der Vorverarbeitung entfernt und deshalb nicht indiziert werden. Für viele Sprachen gibt es allgemeine Stoppwortlisten. Eine korpusspezifische Stoppwortliste ist jedoch oft einer allgemeinen Liste überlegen.

– Der Ausgangspunkt ist erneut unser einfaches Experiment be-stehend aus: [1] Dataset (XML) mit “ImageCLEF (en)”, Lucene

209

Tokenizer, Lucene Index und [3] Topicset mit “2006 (en)”, Lucene Tokenizer, Lucene Search.

– Nachdem Indizierung [1] und Suche [3] erfolgreich zusammenge-stellt wurden, erscheint erst einmal das gleiche Ergebnis [4] wie beim einfachen Experiment. Diese “Baseline” soll nun durch zusätz-liche Komponenten und Einstellungen verbessert werden.

– Füge nun bei der Indizierung [1] den “Stopwords Filter” vor dem “Lucene Index” ein.

– Nun müssen in die Komponente alle Stopwörter eingegeben werden, die bei der Indizierung entfernt werden sollen. Trage mindestens 10 Stopwärter ein um die MAP auf 0.05 zu steigern.

Es gibt verschiedene Möglichkeiten diese Stopwörter zu bestimmen: Du kannst die Stopwörter selbst mit Hilfe der “Index Analyse” her-aussuchen oder eine Standardliste im Internet suchen und einfügen.

– Durch folgende Maßnahmen kannst du das Ergebnis weiter verbessern:

– Verwendung der “Bag of Words” und des “Lowercase Filters”

– Verwendung eines Stemmers

– Folgende Erfolge/Achievements sind möglich:

– Stopwords (2 Sterne)– Precision (3 Sterne)

211

Xtrieval Web Lab* Erforderlich

1. Welchen Studiengang studierst Du?Markieren Sie nur ein Oval.

Bachelor Angewandte Informatik (B_AI)

Master Angewandte Informatik (M_AI)

Master Business Intelligence & Analytics (M_BI)

Master Digitale Medien­ und Kommunikationskulturen (M_DK)

Master Informatik für Geistes­ und Sozialwissenschaftler (M_IG)

Master Informatik (M_In)

Master Web Engineering (M_WE)

Sonstiges:

2. Falls es ein Master­Studiengang ist: Welchen Abschluß besitzt Dubereits?Markieren Sie nur ein Oval.

Bachelor of Arts (B.A.)

Bachelor of Science (B.Sc.)

Bachelor of Laws (LL.B.)

Bachelor of Education (B.Ed.)

Bachelor of Engineering (B.Eng.)

3. Wie schätzt Du Deine Kenntnisse über den Information RetrievalProzess ein, bevor Du die Vorlesung gehört hast?Markieren Sie nur ein Oval.

1 2 3 4 5

Ich kenne michsehr gut aus.

Ich habedavonnoch niegehört.

Anhang B: Fragebogen

212

4. Wie schätzt Du Deine Kenntnisse über den Information RetrievalProzess ein, nachdem Du die Vorlesung gehört hast?Markieren Sie nur ein Oval.

1 2 3 4 5

Ich kenne michsehr gut aus.

Ich habedavonnoch niegehört.

5. Welche Komponenten sind für ein einfaches IR Systemnotwendig?Gemeint sind keine Komponenten zur Verbesserung eines Systems,sondern Komponenten, damit es überhaupt funktioniert, kurz: dieBaseline.

6. Welche Mean Average Precision (MAP) ist am besten?Markieren Sie nur ein Oval.

0.0500

0.2200

1.5000

7. Was bedeutet eine höherer MAP für das Ergebnis?Markieren Sie nur ein Oval.

Es wurden mehr Dokumente gefunden.

Mehr gefundene Dokumente sind relevant.

8. Was macht ein Tokenizer aus folgendem Text: “Am Anfang wardas Wort”Markieren Sie nur ein Oval.

“am anfang war das wort”

“Anf”, “nfa”, “fan”, “ang”, “war”, “das”, “Wor”, “ort”

“Anfang Wort”

“Am”, “Anfang”, “war”, “das”, “Wort”

213

9. Welches Stemming­Verfahren passt zu der jeweiligen Form von“Bäume”?Markieren Sie nur ein Oval pro Zeile.

n­Gram Stemmer Porter/Snowball Stemmer

Bäu äum umeBaum

10. Auf welches Stemming­Verfahren trifft die Aussage zu?Markieren Sie nur ein Oval pro Zeile.

n­GramStemmer

Porter/SnowballStemmer

Es funktioniert nur abhängigvon der Sprache.Es eignet sich für dieZerlegungzusammengesetzer Wörter.Es erzeugt einen kleinerenIndex.Es ist einfach zuimplementieren.

11. Was schätzt Du wievieleStoppwörter für eine deutlicheVerbesserung des RetrievalErgebnisses notwendig sind?

12. Nenne so viele englische Stoppwörter, wie Dir gerade einfallen.

Bewerte folgende Komponenten bezüglichihres Vermögens zur Verbesserung derRetrievalergebnisses.

214

13. KleinschreibungAlle Texte werden in Kleinbuchstaben umgewandelt.Markieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

14. Bag of WordsVerschiedene Inhalte werden in einem Feld gebündelt.Markieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

15. n­Gram StemmerMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

16. Porter/Snowball StemmerMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

17. Stoppwörter entfernenMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

STOP! Hier kommt der Test.Logge Dich bitte per Schalter "TU Chemnitz" ein und beginne ein neues Experiment ("New Experiment") mit dem Assignment "Ein einfaches Experiment". Nachdem du dich eingeloggt hast, beginnt die Aufnahme automatisch.

215

https://medien.informatik.tu­chemnitz.de/weblab/

Nachdem du alle Assignments bearbeitetet hast ("Stoppwörter" ist das Letzte), logge dich bitte aus und schließe den Tab.

18. Hast Du alle 5 Assignments bearbeitet, die Aufnahme beendet undalle anderen Tabs geschlossen? *Wählen Sie alle zutreffenden Antworten aus.

Ja

19. Welche Komponenten sind für ein einfaches IR Systemnotwendig?Gemeint sind keine Komponenten zur Verbesserung eines Systems,sondern Komponenten, damit es überhaupt funktioniert, kurz: dieBaseline.

20. Welche Mean Average Precision (MAP) ist am besten?Markieren Sie nur ein Oval.

0.0500

0.2200

1.5000

21. Was bedeutet eine höherer MAP für das Ergebnis?Markieren Sie nur ein Oval.

Es wurden mehr Dokumente gefunden.

Mehr gefundene Dokumente sind relevant.

22. Was macht ein Tokenizer aus folgendem Text: “Am Anfang wardas Wort”Markieren Sie nur ein Oval.

“Anfang Wort”

“Anf”, “nfa”, “fan”, “ang”, “war”, “das”, “Wor”, “ort”

“am anfang war das wort”

“Am”, “Anfang”, “war”, “das”, “Wort”

216

23. Welches Stemming­Verfahren passt zu der jeweiligen Form von“Bäume”?Markieren Sie nur ein Oval pro Zeile.

n­Gram Stemmer Porter/Snowball Stemmer

Bäu äum umeBaum

24. Auf welches Stemming­Verfahren trifft die Aussage zu?Markieren Sie nur ein Oval pro Zeile.

n­GramStemmer

Porter/SnowballStemmer

Es funktioniert nur abhängigvon der Sprache.Es eignet sich für dieZerlegungzusammengesetzer Wörter.Es erzeugt einen kleinerenIndex.Es ist einfach zuimplementieren.

25. Was schätzt Du wievieleStoppwörter für eine deutlicheVerbesserung des RetrievalErgebnisses notwendig sind?

26. Nenne so viele englische Stoppwörter, wie Dir gerade einfallen.

Bewerte folgende Komponenten bezüglichihres Vermögens zur Verbesserung derRetrievalergebnisses.

217

27. KleinschreibungAlle Texte werden in Kleinbuchstaben umgewandelt.Markieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

28. Bag of WordsVerschiedene Inhalte werden in einem Feld gebündelt.Markieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

29. n­Gram StemmerMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

30. Porter/Snowball StemmerMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

31. Stoppwörter entfernenMarkieren Sie nur ein Oval.

1 2 3 4 5

sehr großeVerbesserung

keineVerbesserung

218

32. Was hat Dich bei der Bearbeitung der Aufgaben gestört bzw.behindert?

33. Was fandest Du am interessantesten bzw. lehrreichsten?

34. Würdest Du Dir ein ähnliches Lernwerkzeug auch für andereVorlesungen wünschen? Wenn ja, für welche?

35. Findest Du das Xtrieval Web Lab eine gute Ergänzung zurVorlesung?Markieren Sie nur ein Oval.

Ja

Nein

36. Warum?

219

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

Anhang C: Auswertung

220

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

221

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

222

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

Wissensfragen

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher DifferenzWelche Mean Average Precision (MAP) istam besten? 23 37 +14 7 11 +4 10 18 +8 6 8 +2Was bedeutet eine höherer MAP für dasErgebnis? 42 47 +5 11 13 +2 20 23 +3 11 11 0Was macht ein Tokenizer aus folgendemText: “Am Anfang war das Wort” 22 33 +11 3 10 +7 9 14 +5 10 9 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Bäu äum ume] 38 39 +1 9 12 +3 18 17 -1 11 10 -1Welches Stemming-Verfahren passt zu derjeweiligen Form von “Bäume”? [Baum] 34 38 +4 7 12 +5 17 16 -1 10 10 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es funktioniert nur abhängigvon der Sprache.] 29 37 +8 6 11 +5 17 17 0 6 9 +3Auf welches Stemming-Verfahren trifft dieAussage zu? [Es eignet sich für die Zerlegungzusammengesetzer Wörter.] 26 32 +6 7 10 +3 14 16 +2 5 6 +1Auf welches Stemming-Verfahren trifft dieAussage zu? [Es erzeugt einen kleinerenIndex.] 29 32 +3 6 9 +3 14 14 0 9 9 0Auf welches Stemming-Verfahren trifft dieAussage zu? [Es ist einfach zuimplementieren.] 35 41 +6 9 12 +3 17 19 +2 9 10 +1

Anteil richtiger Antworten 61.8% 74.7% +12.9% 51.6% 79.4% +27.8% 60.4% 68.4% +8.0% 77.8% 82.8% +5.1%

Mittelwert 5.6 6.7 1.2 4.6 7.1 2.5 5.4 6.2 0.7 7.0 7.5 0.5

Varianz 6.3 4.2 4.8 7.2 5.7 6.6 6.4 4.0 3.8 2.8 2.3 2.3

Differenzen vorher � nachher

Q0/Min 0 0 -3 0 0 0 0 2 -3 3 4 -2

Q1 4 6 0 2.25 6.25 0.25 4 5 0 6.5 7 0

Q2/Median 6 7 1 5 7.5 1.5 6 6 0 7 8 1

Q3 7.75 8.75 2 6.75 9 4.5 7 7 2 8 8.5 1

Q4/Max 9 9 7 8 9 7 9 9 5 9 9 3

Stoppwörter

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

geschätzt 50 20 -30 175 35 -140 30 10 -20 50 75 +25

tatsächlich 7 11 +4 7 11 +4 7.5 10.5 +3 6 11 +5

Komponenten

vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz vorher nachher Differenz

Kleinschreibung 3.2 (1.1) 2.4 (0.7) -0.8 3.2 (0.9) 2.5 (0.4) -0.7 3.2 (0.9) 2.3 (0.8) -0.9 3 (2.2) 2.4 (0.7) -0.6

Bag of Words 2.9 (1.1) 1.8 (0.6) -1.1 3 (1) 1.8 (0.6) -1.2 2.8 (0.8) 1.9 (0.7) -0.9 2.7 (1.8) 1.5 (0.5) -1.2

n-Gram Stemmer 2.5 (0.6) 2.4 (0.6) 1.7 2.8 (0.7) 2.5 (0.9) -0.3 2.5 (0.5) 2.4 (0.4) -0.1 2.4 (0.5) 2.3 (0.8) -0.1

Porter/Snowball Stemmer 2.3 (0.5) 2.1 (0.6) -0.2 2.2 (0.5) 2.2 (0.5) 0 2.5 (0.5) 2 (0.7) -0.5 2 (0.6) 2 (0.4) 0

Stoppwörter entfernen 2.1 (1.4) 1.5 (0.7) -0.6 1.9 (1) 1.8 (1) -0.1 2.6 (1.7) 1.5 (0.6) -1.1 1.4 (0.5) 1.3 (0.4) -0.1

Alle (50) Informatik (14) Informatik für Geistes- und Sozialw. (25) Business Intelligence & Analytics (11)

Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten Anzahl richtiger Antworten

Median Median Median Median

Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz) Mittelwert (Varianz)

Dissertationen der Medieninformatik

(1) Kürsten, Jens (2012)A Generic Approach to Component-Level Evaluation in Information RetrievalISBN 978-3-941003-68-2Volltext: http://nbn-resolving�de/urn:nbn:de:bsz:ch1-qucosa-96344

(2) Berger, Arne (2014)Prototypen im Interaktionsdesign : Klassifizierung der Dimensionen vonEntwurfsartefakten zur Optimierung der Kooperation von Design undInformatikISBN 978-3-944640-00-6Volltext: http://nbn-resolving�de/urn:nbn:de:bsz:ch1-qucosa-126344

(3) Ritter, Marc (2014)Optimierung von Algorithmen zur Videoanalyse :Ein Analyseframework für die Anforderungen lokaler FernsehsenderISBN 978-3-944640-09-9Volltext: http://nbn-resolving�de/urn:nbn:de:bsz:ch1-qucosa-133517

(4) Kurze, Albrecht (2016)Modellierung des QoS-QoE-Zusammenhangs für mobile Dienste undempirische Bestimmung in einem Netzemulations-TestbedISBN 978-3-944640-60-0Volltext: http://nbn-resolving�de/urn:nbn:de:bsz:ch1-qucosa-195066

(5) Wilhelm-Stein, Thomas (2016)Information Retrieval in der Lehre - Unterstützung des Erwerbs vonPraxiswissen zu Information Retrieval Komponenten mittels realerExperimente und SpielemechanikenISBN 978-3-944640-82-2Volltext: http://nbn-resolving.de/urn:nbn:de:bsz:ch1-qucosa-199778