Überblick

Im letzten Milestone wurden die Grundlagen dafür erstellt, mit den Daten der Wikipedia effektiv arbeiten zu können. Ihr System ist nun in der Lage Wikipedia-Seiten, deren Kategorien und Verbindungen in einer Datenbank zu repräsentieren und über eine Java API verfügbar zu machen. In diesem Milestone steht nun der eigentliche Mehrwert im Vordergrund: Die Extraktion und Aufbereitung von Information aus den Basisdaten. Dazu werden zum einen neue Klassen analog zu Page eingeführt, zum einen werden Extraktionsaufgaben als "Tasks" beschrieben welche der Reihe nach ausgeführt werden können.

Erweiterung des Datenmodells

Erweitern Sie Ihr Datenmodell welches ja bereits Wikipedia-Seiten und deren Relationen enthält um weitere Klassen und Beziehungen. Die folgenden Klassen werden im Weiteren zusammenfassend auch als Entitäten Klassen (Entity-Classes) bezeichnet:

Person
City (Ort)
Monument (Denkmal)
Objekte dieser Klassen stehen für Personen, Orte und Denkmäler welche Sie auf Grundlage der importierten "Page"-Objekte extrahieren und in Ihrer Datenbank repräsentieren. Auf den ersten Blick scheint es naheliegend, zusätzliche und Typ-spezifische Informationen wie etwa Vor- und Nachname einer Person, oder die Einwohnerzahl eines Ortes einfach mit in den Datenbank-Knoten der Page zu schreiben. Für eine Trennung sprechen folgende Gründe:

Nicht jede Seite repräsentiert wirklich eine Person oder einen Ort- auch wenn es laut Kategorisierung in der Wikipedia so sein sollte.
Es kann nicht ausgeschlossen werden, dass ein Wikipedia-Artikel mehre Klassen gleichzeitig repräsentiert (z.B. eine Person und ein Denkmal).
Es ist sauberer die Datengrundlage von den extrahierten Informationen zu trennen. Möglicherweise kommen später weitere Datenquellen hinzu welche Informationen zu Personen und Orten liefern- aber eben keine Wikipedia-Artikel sind.
Die spezifischen Attribute und Relationen welche die Entitäten-Klassen abbilden sollen ergeben sich aus der weiteren Spezifikation dieses Milestones. Allen gemein ist jedoch, dass Sie eine Verknüpfung zum Wikipedia-Artikel-Objekt beinhalten müssen. Es soll also stets möglich sein, von einem Objekt der Klasse Person, City oder Monument zur Page zu kommen. Umgekehrt soll es auch möglich sein von einer Page die Menge aller Entities (Person, City, Monument) zu bekommen, welche aufgrund dieser Page extrahiert wurden.

Wie bereits bei der Modellierung der Klasse Page achten Sie darauf, die Datenbankschicht vor dem Benutzer Ihrer API zu "verstecken". D.h. die Klasse Person etwa sollte Methoden zur Abfrage des Geburtsdatums, des Namens usw. enthalten. Die Abfrage der Page auf der ein Personen-Objekt basiert soll ein Page-Objekt zurückgeben und nicht etwa ein Neo4J-Node-Objekt.

Task-Modell

Allen bisherigen und geplanten Operationen ist gemein, dass sie bestimmte Änderungen auf der Datenbank durchführen: HTML-Seiten importieren, Kategorien-Links extrahieren usw. Meistens geschieht dies auf Grundlage eines vorher durchgeführten Schrittes: Zum Beispiel müssen zuerst die HTML-Seiten in Page-Objekte importiert worden sein, bevor daraus Links extrahiert werden können. Alle Aufgaben (Tasks) müssen also so in eine Reihenfolge gebracht werden, dass alle Informationen in der Datenbank verfügbar sind sobald sie benötigt werden. Das kann darüber geregelt werden, dass für jede Aufgabe die Vor- und Nachbedingungen definiert sind.

Spätestens an diesem Punkt (gern auch schon an anderer Stelle) kommt das Prinzip von abstrakten Klassen und der Vererbung zum tragen. Jeder Task besitzt Attribute und Methoden die von allen denkbaren Ausprägungen wie Import, Extraktion von Links usw. benötigt werden:

Ein Task sollte eine Beschreibung seiner Funktion zurückgeben können. Dazu genügt eine Methode welche einen String zurück gibt (z.B. getDescription()).
Welche Vorbedingungen hat der Task? D.h. welche Bedingungen müssen durch vorher gelaufene Tasks erfüllt sein? Dazu eignet sich eine Methode welche eine Menge welche die Vorbedingungen als Strings oder als Elemente einer Enumeration (enum) enthalten.
Welche Nachbedingungen hat dieser Task- was stellt er also für andere Tasks bereit?
Ein Task muss durch Aufruf einer Methode ausgeführt werden können.
Bei der Erstellung dieser abstrakten Klasse "Task" können für alle diese Methoden noch konkreten Implementierungen geschrieben werden. Es wird nur definiert welche Methoden es gibt, welche Parameter sie haben und was ggf. ihr Rückgabewert ist. Sie bleiben abstrakt und werden erst durch diejenigen Klassen implementiert, die davon erben.

Sie schreiben also für jede Aufgabe (siehe unten) eine Klasse welche von Task erbt und die abstrakten Methoden entsprechend der zu erfüllenden Aufgabe überschreibt. Einer der wichtigen Vorteile: Sie können jede Implementierung als Task betrachten der eine Methode zur Ausführung hat. Sie können diese Methode aufrufen um den Task auszuführen, egal ob es sich dabei um den Import von HTML oder die Extraktion von Links handelt.

TaskScheduler

Alle Tasks eines Programmablaufs werden in einem TaskScheduler, einer eigenen Klasse, gesammelt. Dieser verwaltet auszuführende Tasks in einer Liste. Der TaskScheduler muss keine Details über die unterschiedlichen Implementierungen der abstrakten Klasse Task wissen. Es genügt zu wissen:

Welche Tasks sollen in welcher Reihenfolge ausgeführt werden?
Sind für alle Tasks die Vorbedingungen erfüllt, sobald die an der Reihe sind?
Wie kann ich einen Task ausführen?
Der TaskScheduler muss für einen Benutzer zumindest folgende Funktionen erfüllen:

Tasks hinzufügen
Abfragen ob alle Vorbedingungen der enthaltenen Tasks erfüllt sind
Liste der Tasks auf die Konsole ausgeben
Tasks ausführen
Tipp: Sie können für die Implementierung des TaskScheduler von einer Listen-Implementierung von Java erben, z.B. ArrayList.

Tasks

1) HTMLDumpImport

Den Import haben Sie bereits geschrieben. Kapseln Sie ihn nun in einen Task, sodass er als Teil einer Prozesskette durch den TaskScheduler gestartet werden kann. Als Ergebnis liegen die Wikipedia-Artikel in der Datenbank vor. Achten Sie darauf, den Namen des zu importierenden HTML-Dumps als Parameter zu verarbeiten und nicht fest in de Code zu schreiben.

2) CategoryLinkExtraction

Auch diese Funktion ist bereits implementiert. Kapseln Sie die Extraktion der Kategorien-Links aus den HTML Quelltexten und deren Einfügung als Relationships in die Datenbank als eigenständigen Task.

3) ArticleLinkExtraction

Kapseln Sie analog zur CategoryLinkExtraction die Extraktion und Repräsentation der Artikel (also nur Namespace-ID 0) untereinander.

4) EntityBaseExtraction und Entity-Links

Prüfen Sie für alle Wikipedia-Artikel in Ihrer Datenbank welche direkt oder indirekt der Kategorie "Person", "Ort" bzw. "Denkmal" angehören. Definieren und dokumentieren Sie ggf. weitere Regeln für die Erkennung von Personen, Orten und Denkmälern, falls die Kategorienzugehörigkeit allein nicht präzise genug sein sollte (und z.B. Personenlisten als "Person" erkannt werden). Erzeugen Sie dann für jede Belegstelle über Ihre API ein entsprechendes-Objekt in der Datenbank. Extrahieren Sie für alle Entitäten zumindest folgende Basis-Informationen:

SourceWikipediaPage - Referenz auf den Wikipedia-Artikel (als Datenbank-Objekt) welcher dieser Entität zugrundeliegt.
Methoden um alle verlinkten Entitäten vom Typ Person, City oder Monument abzufragen (eingehend und ausgehend).
Das Ergebnis diesen Schrittes sind also neue Datenbank-Objekte, analog zur Page-Klasse: Person, Ort und Denkmal. Diese Klassen enthalten noch keine spezifischen Informationen wie Vornamen oder Einwohnerzahlen. Diese werden in einem separaten Schritt extrahiert und in die Datenbank eingetragen.

Beachten Sie bei der Extraktion, dass nicht aus jedem Artikel zwangsläufig eine Person-, Ort- oder Denkmal-Entität entstehen muss. Es gibt Artikel welche z.B. als "Person" kategorisiert sind, aber keine konkrete Person benennen sondern nur Listen von Personen oder verwandte Themen. Versuchen Sie also über die Kategorieninformation hinaus einzugrenzen, ob es sich dabei wirklich um eine Person handelt oder nicht. Wie sie dabei vorgehen ist, wie bei der Extraktion der übrigen Attribute, ganz ihrer Kreativität überlassen. Es wird jedoch nicht negativ gewertet, wenn Sie pauschal alle Artikel der Kategorie "Person" auch als Person-Entität extrahieren. Sie haben dann lediglich einen Anteil von Entitäten zu denen Sie keine sinnvollen Attribute extrahieren können.

Auch wenn Attribute wie Vornamen und Einwohnerzahlen in diesem Schritt noch nicht explizit betrachtet und extrahiert werden, so werden in diesem Schritt doch bereits die Links zwischen den Entity-Objekten extrahiert und eingetragen: Angenommen Sie haben für die Artikel "Frankfurt" und "Hanau" (Page-Objekte), welche durch Article-Links verbunden sind, je eine City-Entität erstellt. Dann soll auch zwischen den entsprechenden Entitäten ein Link engefügt werden. Verwenden Sie dazu einen eigenen RelationShip-Typ (z.B. EntityLink). Die Entity-Links leiten sich also unmittelbar von den Article-Links ab.

5) PersonExtraction
Extrahieren Sie auf Grundlage der in der EntityBaseExtraction erhobenen Daten soweit möglich zumindest folgende Informationen:

Vorname(n)*
Nachname*
Geburtsname*
Geburtstag*
Todestag*
Geburtsort (als String)*
Letzter Wohnort (als String)
allgemein verlinkte Orte, Personen, Denkmäler (sofern Sie in der Datenbank enthalten sind) als entsprechende Objekte (City, Person, Monument)
6) CityExtraction
Extrahieren Sie auf Grundlage der in der EntityBaseExtraction erhobenen Daten soweit möglich zumindest folgende Informationen:

Name*
Land*
Einwohnerzahl*
Jahr der Gründung oder ersten urkundlichen Erwähnung
allgemein verlinkte Orte, Personen, Denkmäler (sofern Sie in der Datenbank enthalten sind) als entsprechende Objekte (City, Person, Monument)
7) MonumentExtraction
Extrahieren Sie auf Grundlage der in der EntityBaseExtraction erhobenen Daten soweit möglich zumindest folgende Informationen:

Name*
Stadt bzw. nächstgelegene Ortschaft (sofern sie in der Datenbank enthalten ist)*
Jahr der Einweihung*
Geehrte Person (sofern sie in der Datenbank enthalten ist) als Person-Objekt
allgemein verlinkte Orte, Personen, Denkmäler (sofern Sie in der Datenbank enthalten sind) als entsprechende Objekte (City, Person, Monument)
Konsolenprogramm

Schreiben Sie eine kleine Schnittstelle für die Kommandozeile welche die nachfolgend beschriebenen Funktionen ermöglicht. Sie können die Funktionalität der Aufrufe aus Milestone 2 gern übernehmen- es ist jedoch nicht zwingend erforderlich. Halten Sie sich bei der Lösung für diesen Milestone jedoch streng an die folgenden Parameter:

1) Erzeugung der Datenbank und Durchführung aller Tasks gemäß der Aufgabenstellung inklusive Reset der Datenbank:

WikiXtractor <Database-Directory> createdb <HTML-Input-File>

Stellen Sie sicher, dass der Aufrufer über die Log-Ausgaben weiss, woran gerade gerechnet wird und wie weit der Fortschritt ist. Für diesen Aufruf können Sie die Abfolge der Tasks im Code festschreiben.

Erweiterung für Gruppen ohne LA-Beteiligung:

WikiXtractor <Database-Directory> executetasks <Task-File>

Das Programm soll eine Folge von Tasks ausführen die in einer Textdatei, dem "Task-File" beschrieben sind. Jede Zeile im Task-File steht für einen Task und, sofern benötigt, seine Parameter. Beispiel:

HTMLDumpImport data/wikipedia_de_prgpr_subset.txt
CategoryLinkExtraction
ArticleLinkExtraction
EntityBaseExtraction
PersonExtraction
CityExtraction
MonumentExtraction

Ihr Programm liest also die Text-Datei aus um in Ihrem TaskScheduler die Tasks zusammenzustellen, die dann ausgeführt werden sollen. Beachten Sie, dass der TaskScheduler vor der Ausführung noch einmal prüfen soll, ob alle Vorbedingungen erfüllt sind. Wenn z.B. laut Task-File eine ArticleLinkExtraction durchgeführt werden soll, aber vorher noch kein HTML importiert wurde, soll eine entsprechende Fehlermeldung ausgegeben werden.

2) Abfrage von Informationen

WikiXtractor <Database-Directory> queryentity <Artikel-Title>

Beispielaufruf: WikiXtractor datatabase queryentity "Hermannsdenkmal"

Aufgrund des angegebenen Wikipedia-Artikels (z.B. Hermannsdenkmal) soll geprüft werden, ob ein damit verknüpftes Entity-Objekt (Person, City oder Monument) existiert. Im positiven Fall sollen alle verfügbaren Informationen über dieses Objekt auf der Konsole ausgegeben werden.

Evaluation

Sie haben aufgrund von Regeln Informationen extrahiert. In hoffentlich vielen Fällen wird dies gut gelingen- es wird jedoch sicherlich auch Fehler in der Extraktion geben. Um abschätzen zu können, wie gut Ihre Regeln sind führen Sie eine Evaluation wie folgt durch:

Wählen Sie von jeder Klasse (Person, Ort, Denkmal) zufällig je 20 Artikel aus. Ermitteln Sie dann für jede mit einem (*) markierte Eigenschaft der Extraktionsaufgaben die absolute Anzahl der richtigen Fälle. Geben Sie darauf basierend desweiteren das Verhältnis der richtigen Fälle zur Gesamtheit der Fälle an. Damit ergibt sich eine Tabelle der Form:

Attribut	Absolut richtig	Genauigkeit
Person.Nachname	18	0.9
Person.Geburtsort	15	0.75
...	...	...
Gehen Sie bei der Wahl der zufälligen Artikel ehrlich vor. Es geht nicht darum, dass eine 1.0 in der Tabelle steht, sondern darum, dass Sie sich mit dem Vorgehen zur Prüfung der eigenen Arbeit vertraut machen.

Regelung nach Zusammensetzung des Teams

Für Teams mit mehr >=50% LA-Studierenden:

Die Objektorientierte Programmierung der Tasks mit einer abstrakten Klasse als Grundlage entfällt.
Jeder Task soll in seiner eigenen Klasse implementiert sein, aber die Reihenfolge der Ausführung darf fest im Code programmiert sein. Vor- und Nachbedingungen müssen nicht erfasst und nicht geprüft werden. Es wird kein TaskScheduler benötigt.
Die Modellierung und Extraktion der Klassen City und Monument entfällt. Entsprechend können diese Entitäten auch nicht evaluiert werden. Die Klasse Person soll aber umgesetzt und evaluiert werden. Personen sollen auf die Seite verlinken aus der sie extrahiert wurden. Links zwischen Entities müssen aber nicht modelliert werden (auch nicht zwischen Personen).
Für Teams mit 0<x<50% LA-Studierenden:

Die Objektorientierte Programmierung der Tasks mit einer abstrakten Klasse als Grundlage entfällt.
Jeder Task soll in seiner eigenen Klasse implementiert sein, aber die Reihenfolge der Ausführung darf fest im Code programmiert sein. Vor- und Nachbedingungen müssen nicht erfasst und nicht geprüft werden. Es wird kein TaskScheduler benötigt.
Die Modellierung und Extraktion der Klasse City entfällt. Entsprechend kann diese Entität auch nicht evaluiert werden. Die Klassen Person und Monument sollen aber umgesetzt und evaluiert werden. Links auf Orte entfallen- Links zwischen Personen und Denkmälern sollen aber berücksichtigt werden.
Abgabe und Bewertung

Die Abgabefrist für diesen Milestone ist am 18. Januar um 23:59. Gültig ist der Stand der Versionsverwaltung zu diesem Zeitpunkt.

Grundvoraussetzungen für die Bewertung:

Alle notwendigen Dokumente im Subversion Repository.
Autorenschaft(en) der Klassen mit JavaDoc dokumentieren
Erstellung eines jar-Archivs Ihres Projekts um die Ausführung für Dritte zu erleichtern. Das Projekt sollte über den Aufruf (Beispiel) java -Xmx2g -jar WikiXtractor.jar gestartet werden können.
Erstellung einer Datei "Milestone3_README.txt" im Wurzelverzeichnis Ihres SVN-Repositories in welcher Sie Ihre Abgabe für den Tutor kommentieren. Die Beschreiben sollte zumindest enthalten:
wie die Berechnung ausgeführt werden kann (Beispielaufruf(e) auf der Konsole)
wo die Ergebnisdatei(en) liegen
wer woran gearbeitet hat
welche bekannten Probleme ggf. noch bestehen
Bewertungskriterien (Teams ohne LA Studierende):

Entwicklung
(8 Punkte) Erweiterung des Datenmodells um die Klassen Person, City, Monument
(8 Punkte) Implementierung des TaskSchedulers sowie der abstrakten Klasse Task mit den darauf basierenden Implementierungen.
(6 Punkte) Aufgabenteil 1 (HTMLDumpImport).
(6 Punkte) Aufgabenteil 2 (CategoryLinkExtraction)
(6 Punkte) Aufgabenteil 3 (ArticleLinkExtraction)
(8 Punkte) Aufgabenteil 4 (EntityBaseExtraction)
(8 Punkte) Aufgabenteil 5 (PersonExtraction)
(8 Punkte) Aufgabenteil 6 (CityExtraction)
(8 Punkte) Aufgabenteil 7 (MonumentExtraction)
(8 Punkte) Konsolenprogramm
(10 Punkte) Evaluation
(8 Punkte) Kommentierung aller Klassen, Methoden und Attribute mit JavaDoc (kurze Beschreibung, Autore(n), Parameter, Rückgabewert)
(8 Punkte) Logging von Exceptions und dem Programmfortschritt über log4j auf die Konsole sowie in eine Log-Datei.
Bewertungskriterien (Teams mit 0<x<50% LA-Studierenden):

Entwicklung
(10 Punkte) Erweiterung des Datenmodells um die Klassen Person, City, Monument
Implementierung des TaskSchedulers sowie der abstrakten Klasse Task mit den darauf basierenden Implementierungen.
(7 Punkte) Aufgabenteil 1 (HTMLDumpImport).
(7 Punkte) Aufgabenteil 2 (CategoryLinkExtraction)
(7 Punkte) Aufgabenteil 3 (ArticleLinkExtraction)
(10 Punkte) Aufgabenteil 4 (EntityBaseExtraction)
(10 Punkte) Aufgabenteil 5 (PersonExtraction)
Aufgabenteil 6 (CityExtraction)
(10 Punkte ) Aufgabenteil 7 (MonumentExtraction)
(10 Punkte) Konsolenprogramm
(11 Punkte) Evaluation
(9 Punkte) Kommentierung aller Klassen, Methoden und Attribute mit JavaDoc (kurze Beschreibung, Autore(n), Parameter, Rückgabewert)
(9 Punkte) Logging von Exceptions und dem Programmfortschritt über log4j auf die Konsole sowie in eine Log-Datei.
Bewertungskriterien (Teams mit mehr >=50% LA-Studierenden):

Entwicklung
(11 Punkte) Erweiterung des Datenmodells um die Klassen Person, City, Monument
Implementierung des TaskSchedulers sowie der abstrakten Klasse Task mit den darauf basierenden Implementierungen.
(8 Punkte) Aufgabenteil 1 (HTMLDumpImport).
(8 Punkte) Aufgabenteil 2 (CategoryLinkExtraction)
(8 Punkte) Aufgabenteil 3 (ArticleLinkExtraction)
(11 Punkte) Aufgabenteil 4 (EntityBaseExtraction)
(11 Punkte) Aufgabenteil 5 (PersonExtraction)
Aufgabenteil 6 (CityExtraction)
Aufgabenteil 7 (MonumentExtraction)
(11 Punkte) Konsolenprogramm
(12 Punkte) Evaluation
(10 Punkte) Kommentierung aller Klassen, Methoden und Attribute mit JavaDoc (kurze Beschreibung, Autore(n), Parameter, Rückgabewert)
(10 Punkte) Logging von Exceptions und dem Programmfortschritt über log4j auf die Konsole sowie in eine Log-Datei.
Für die Gewichtung des Milestones in der Gesamtbewertung werden 4 Wochen angesetzt.