8. Analyse des Wiki-Textes
Dieses Kapitel beschreibt, wie der Wiki-Text analysiert wird, um alle für WikiWord relevanten
Eigenschaften (Features) zu extrahieren und wie diese Eigenschaften im Ressourcenmodell
repräsentiert werden. Relevante Eigenschaften sind unter anderem die Wiki-Links (inklusive
Kategorisierung, Language-Links etc., siehe .A.3), der Einleitungssatz (Glosse) und die verwendeten
Vorlagen und ihre Parameter (.A.5).
Die Logik zur Analyse von Wiki-Text (und, soweit notwendig, von natürlicher Sprache),
sind im Java Package de.brightbyte.wikiword.analyzer implementiert. Das Package de.
brightbyte.wikiword.wikis enthält Klassen, die das sprach- bzw. projektspezifische Wissen
repräsentieren, das notwendig ist, um denWiki-Text zu analysieren. Die in diesen Packages implementierten
Regeln und Muster basieren auf Informationen darüber, wieWiki-Text im Allgemeinen
und Wikipedia-Seiten im Speziellen aufgebaut sind. Insbesondere repräsentieren sie:
1. Die Wiki-Text Markup Syntax, wie von MediaWiki festgelegt (Anhang A). Diese Regeln
sind, soweit sie für WikiWord relevant sind, fest in PlainTextAnalyzer kodiert.
2. Die Konventionen und Richtlinien der einzelnen Wiki-Projekte, die zum Beispiel festlegen,
wie Artikel strukturiert werden WP:ARTIKEL, wie Kategorien zu verwenden sind
WP:KAT oder wann und wie Begriffsklärungsseiten anzulegen sind WP:BKL. Diese Regeln
sind, soweit sie für WikiWord relevant sind, zumeist in der projektspezifischen Subklasse
von WikiConfiguration definiert, zum Teil aber auch fest in WikiTextAnalyzer kodiert.
3. Beobachtungen darüber, wann bestimmte Textmuster auftreten oder wie das Wiki-Text-
Markup verwendet wird. Das sind zum Beispiel die Menge der in einer Sprache häufig
auftretenden Abkürzungen, wichtig für das Erkennen des Endes der Glosse — diese
Information ist als sprachspezifisches Wissen in der betreffenden Subklasse von
LanguageConfiguration abgelegt. Ein anderes Beispiel sind Vorlagen, die häufig inline
im Text verwendet werden und daher vor der Verarbeitung aufgelöst werden sollten.
Sie sind mit den anderen projektspezifischen Informationen in einer Subklasse von
WikiConfiguration definiert.
Zu beachten ist, dass WikiWord ad-hoc-Heuristiken nach Möglichkeit vermeidet und statt dessen
versucht, direkt explizite Konventionen zu modellieren. So profitiert WikiWord stärker von
der Intention der Autoren des Wiki-Textes und ist weniger auf die Intuition des Programmierers
angewiesen.
8.1. Klassen
Dieser Abschnitt beschreibt die Klassen, die für die Analyse des Wiki-Textes und eine
Übertragung in das Ressourcenmodell wichtig sind.
8. Analyse des Wiki-Textes 41
PlainTextAnalyzer: Die Klasse PlainTextAnalyzer bietet einfache Funktionen zur Analyse
natürlichsprachlicher Texte, insbesondere eine Methode zur Extraktion des ersten Satzes
aus einem Text, und eine Funktion zur Extraktion einzelner Wörter aus einer Zeichenkette.
Instanzen von PlainTextAnalyzer sollten über die Methode getPlainTextAnalyzer
erzeugt werden: Sie lädt die für die gegebene Sprache passende Implementation und
Konfiguration. Die Default-Implementation funktioniert bei entsprechender Konfiguration
über eine LanguageConfiguration für die meisten europäischen Sprachen.
LanguageConfiguration: Die Klasse LanguageConfiguration repräsentiert eine
Konfiguration von PlainTextAnalyzer für eine bestimmte Sprache. Die wichtigste
sprachspezifische Information, die diese Klasse kapselt, ist ein Muster für
häufig verwendete Abkürzungen dieser Sprache, das bei der Satzgrenzenerkennung
verwendet wird. Für Deutsch und Englisch sind Konfigurationen im Package
de.brightbyte.wikiword.wikis definiert, für weitere Sprachen wie Französisch,
Niederländisch und Norwegisch ist eine rudimentäre Basiskonfiguration vorhanden.
WikiTextAnalyzer: Die Klasse WikiTextAnalyzer enthält Logik für die Verarbeitung vieler
Aspekte des von MediaWiki verwendeten Wiki-Text-Markups (.A). Insbesondere bietet
sie Methoden für den Zugriff auf Wiki-Links, Vorlagen und Artikelabschnitte, sowie
Funktionalität zum Entfernen von Wiki-Markup, um „einfachen“ Text zur weiteren
Verarbeitung zu erzeugen. Instanzen von WikiTextAnalyzer sollten über die Methode
getWikiTextAnalyzer erzeugt werden: Sie lädt die für den gegebenen Korpus passende
Implementation und Konfiguration.
WikiTextAnalyzer.WikiPage: Die Klasse WikiTextAnalyzer.WikiPage repräsentiert eine
Seite imWiki und implementiert damit das Ressourcenmodell vonWikiWord (.4.1). Sie bietet
Zugriff auf die verschiedenen Eigenschaften der Seite, wie sie von WikiTextAnalyzer
erkannt wurden. Diese sind im Anhang D.1 beschrieben.
WikiConfiguration: Die Klasse WikiConfiguration repräsentiert eine Konfiguration von
WikiTextAnalyzer für ein bestimmtes Wiki-Projekt. Sie enthält Wissen über diverse
Konfigurationen und Konventionen für das betreffende Wiki. Konfigurationen sind im
Package de.brightbyte.wikiword.wikis vorhanden für die deutschsprachige (de.
wikipedia.org) und die englischsprachige Wikipedia (en.wikipedia.org) sowie rudimentär
angelegt für die französischsprachige (fr.wikipedia.org), niederländischsprachige
(nl.wikipedia.org) und norwegischsprachige (no.wikipedia.org).
WikiTextSniffer: Die Klasse WikiTextSniffer erlaubt es, typische Elemente vonWiki-Text
zu erkennen. Das ist nützlich für Sanity-Checks: so sollten zum Beispiel Konzeptnamen und
Terme, die ausWiki-Links extrahiert wurden, keinenWiki-Text mehr enthalten. Tun sie das
doch, werden sie ignoriert. Das sollte nur dann auftreten, wennWiki-Markup auf inkorrekte
oder sehr ungewöhnliche Weise verwendet wurde.
Die Klassen und Dateien, die zur Konfiguration Wiki-spezifischer Werte und Muster verwendet
werden, sind in Anhang B.7 beschrieben.
8. Analyse des Wiki-Textes 42
8.2. Mechanismen
Zur Verarbeitung des Wiki-Textes werden verschiedene Techniken verwendet, hauptsächlich aber
Mustererkennung (Pattern Matching), wobei die Muster nicht unbedingt direkt auf den vollen
Wiki-Text angewendet werden, sondern zum Teil auf schon vorverarbeiteten Text oder Textstücke.
Um die verschiedenen Muster und Regeln in WikiConfiguration zu definieren, werden vor
allem die folgenden Klassen verwendet:
Pattern: Ein regulärer Ausdruck, in Javas eigener Implementation JAVA:RE. Wird für einfache
Mustererkennung im Text verwendet.
AbstractAnalyzer.Mangler: Ein Interface für Klassen, die Text manipulieren, also
Ersetzungen irgendeiner Form durchführen. Standard-Implementationen dieses Interfaces
sind WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen
aus Wiki-Text .8.3, WikiTextAnalyzer.EntityDecodeManger zum Auflösen
von HTML Character References W3C:HTML (1999) und AbstractAnalyzer.
RegularExpressionMangler, der beliebige Textersetzungen auf der Basis von regulären
Ausdrücken vornimmt.
AbstractAnalyzer.SuccessiveMangler: Ebenfalls ein Interface für Klassen, die Text manipulieren.
SuccessiveMangler hat dabei zusätzlich die Eigenschaft, dass er den gegebenen
Text nicht unbedingt bis zum Ende verarbeitet und dass die Verarbeitung dort fortgesetzt
werden kann, wo sie unterbrochen wurde. So kann der Text sukzessive verarbeitet werden,
genau so weit, wie das Ergebnis tatsächlich benötigt wird. Die bereits erwähnte Klasse
WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen ausWiki-Text
implementiert dieses Interface zusätzlich zu AbstractAnalyzer.Mangler — das ist insbesondere
für das Aufspüren des ersten Absatzes eines Artikels nützlich.
AbstractAnalyzer.Armorer: Interface für Klassen, die Teile des Textes durch Platzhalter ersetzen,
um sie so vor weiteren Verarbeitungsschritten zu schützen. Das ist insbesondere für
Abschnitte imWiki-Text sinnvoll, die als verbatim markiert sind, auf die also die Regeln des
Wiki-Markup nicht angewendet werden sollen (.8.3). Das sind insbesondere Kommentare
sowie Text in <nowiki>- und <pre>-Tags (siehe .A). Die Standard-Implementation dieses Interfaces ist AbstractAnalyzer.RegularExpressionArmorer — sie identifiziert zu schützende Teile des Wiki-Textes mit Hilfe eines regulären Ausdrucks. WikiTextAnalyzer.Sensor: Interface für Klassen, die eine WikiPage auf Grund einer ihrer Eigenschaften klassifizieren: die Methode sense gibt zurück, ob der Sensor zu der gegebenen WikiPage passt; die Methode getValue liefert den Wert, der der Seite gegebenenfalls zugeordnet werden soll. Für dieses Interface gibt es eine ganze Reihe von Implementationen: HasCategorySensor: Stellt fest, ob die Seite zu einer bestimmten Kategorie gehört. HasCategoryLikeSensor: stellt fest, ob die Seite zu einer Kategorie gehört, deren Name zu einem bestimmten regulären Ausdruck passt. 8. Analyse des Wiki-Textes 43 HasSectionSensor: Stellt fest, ob die Seite einen Abschnitt mit einem bestimmten Namen hat. HasSectionLikeSensor: stellt fest, ob die Seite einen Abschnitt hat, dessen Name zu einem bestimmten regulären Ausdruck passt. HasTemplateSensor: Stellt fest, ob die Seite eine bestimmte Vorlage verwendet. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass diesem Parameter ein bestimmter Wert zugewiesen wurde. HasTemplateLikeSensor: Stellt fest, ob wenn die Seite eine Vorlage verwendet, deren Name zu einem bestimmten regulären Ausdruck passt. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass der Wert, der diesem Parameter zugewiesen wurde, zu einem bestimmten regulären Ausdruck passt. RegularExpressionCleanedTextSensor: Stellt fest, ob der bereinigte Text der Seite (.8.3) zu einem bestimmten regulären Ausdruck passt. RegularExpressionTitleSensor: Stellt fest, ob der Titel der Seite zu einem bestimmten regulären Ausdruck passt. Sensoren dieser Art werden vornehmlich für die Klassifikation von Ressourcen und Konzepten verwendet (siehe .8.5 bzw. .8.6). Mit diesen Mitteln lassen sich die Eigenheiten eines Wikipedia-Projektes ausdrücken und in einer Subklasse von WikiConfiguration festhalten, auf die WikiTextAnalyzer bei der Analyse von Wiki-Text zurückgreifen kann. 8.3. Bereinigen Für die Verarbeitung von Wiki-Text ist es nützlich, bestimmte Arten oder Aspekte des Wiki- Markups vorab zu entfernen. Wie in .D.1 erwähnt, kennt WikiWord vier Versionen des Wiki- Textes: text: der unveränderte Wiki-Text. cleanedText: der Wiki-Text ohne störende Elemente, nach Anwendung von WikiTextAnalyzer.stripClutter. Diese Form des Textes ist die Basis für die weitere Analyse (Extraktion von Vorlagen, Links, Kategorien etc). flatText: der Wiki-Text ohne Blöcke, nach Anwendung von WikiTextAnalyzer. stripBoxes. Diese Form des Textes ist die Basis für die weitere Analyse auf der Textebene (Extraktion der Glosse, von Absätzen etc.). plainText: der Text nach dem Entfernen sämtlicher Markup-Elemente, also nach Anwendung von WikiTextAnalyzer.stripMarkup. Diese Form des Textes kann für eine weitere Verarbeitung auf der Ebene natürlicher Sprache verwendet werden. 8. Analyse des Wiki-Textes 44 Die einzelnen Methoden zum Bereinigen des Textes werden im Folgenden näher erläutert: WikiTextAnalyzer.stripClutter: Diese Methode entfernt oder transformiert alle solchen Wiki-Text-Elemente, die für die Analyse im Rahmen dieser Arbeit unnötig oder störend sind, und ruft dann WikiTextAnalyzer.resolveMagic auf. Alle anderen Analysemethoden werden auf den so bereinigten Text angewendet (oder auf eine weiter bereinigte Version). Vollständig entfernt werden <gallery>-Blöcke, alle eingebundenen Bilder (also Wiki-Links in den Image-Namensraum) MW:IMAGES (.A.3) sowie alle Optionen der Form .*? MW:MAGIC (.A.6). Definiert werden diese Ersetzungen durch WikiConfiguration.stripClutterManglers. Ebenfalls durch WikiConfiguration.stripClutterManglers werden Ersetzungen definiert, die wohlbekannte, wikispezifische Vorlagen ersetzen, insbesondere Formatierungshilfen, die inline im Text verwendet werden. Für die englischsprachige Wikipedia werden zum Beispiel unter Anderem folgende Ersetzungen vorgenommen: {{dot}} durch „·“ (Unicode U+00B7), {{sub|xxx}} durch „xxx“ und {{frac|a|b}} durch „a/b“. Zudem wird eine Vielzahl von Vorlagen einfach entfernt, zum Beispiel {{fact}}, das in der englischen Wikipedia auf eine unbelegte Aussage hinweist. Wichtig ist auch, dass in diesem Schritt Vorlagen ersetzt werden, die Teile von Markup-Konstrukten enthalten, die für die weitere Verarbeitung benötigt werden: In der englischsprachigen Wikipedia muss zum Beispiel die Vorlage {{wrapper}} durch „{|“ (Tabellenanfang) und {{end}} durch „|}“ (Tabellenende) ersetzt werden. Einige Arten von Wiki-Text-Konstrukten werden nicht einfach entfernt oder umgewandelt, sondern durch einen Platzhalter ersetzt, so dass sie zwar von der weiteren Verarbeitung ausgeschlossen sind, aber später wieder eingefügt werden können (Armoring): das ist vor allem für Blöcke der Fall, in denen Wiki-Text-Markup keine Anwendung findet, per Default also bei Kommentaren (<!.*?>) sowie bei <nowiki>- und <pre>-Blöcken (.A). Diese
Blöcke werden durch WikiConfiguration.stripClutterArmorers festgelegt.
WikiTextAnalyzer.resolveMagic: Diese Methode ersetzt einige Magic Words durch ihren
konkreten Wert MW:MAGIC: sie verwendet den in WikiConfiguration.magicPattern
definierten regulären Ausdruck, um solche Magic Words zu finden, und ruft dann
WikiTextAnalyzer.evaluateMagic auf, um ihren Wert zu ermitteln. Ersetzt werden
solche Magic Words, die als Variablen für verschiedene Versionen des Seitentitels oder
des Namensraumes der Seite funktionieren, konkret solche, die zu folgendem regulären
Ausdruck passen: \{\{\s*((FULL|SUB|BASE)?PAGENAMEE?|NAMESPACEE?)\s*\}\} .
Andere Magic Words werden später genau wie Vorlagen behandelt (wenn sie der
Vorlagen-Syntax folgen, siehe .8.4), oder wurden vorher bereits von WikiTextAnalyzer.
stripClutter entfernt (im Fall von Optionen wie NOTOC).
WikiTextAnalyzer.stripBoxes: Diese Methode liefert den „eigentlichen“ Inhalt der Wiki-
Seite (den Fließtext), ohne Bilder, Tabellen, Infoboxen, Hinweise und dergleichen, aber
noch mit Markup zur Textformatierung sowie Wiki-Links. Die Ersetzungen, die anzuwenden
sind, um das zu erreichen, werden von WikiConfiguration.stripBoxesManglers
8. Analyse des Wiki-Textes 45
definiert. Als Eingabe wird Text erwartet, der bereits durch WikiTextAnalyzer.
stripClutter bereinigt wurde.
Per Default enthält stripBoxesManglers genau einen Mangler, nämlich eine Instanz
von WikiTextAnalyzer.BoxStripMangler: Er entfernt alle expliziten Blockstrukturen,
also Tabellen, Vorlagen (soweit nicht bereits ersetzt) sowie <div>- und <center>-
Blöcke; diese werden in der Wikipedia fast nie im Fließtext des Artikels verwendet,
sondern nur für „Kästen“ (Floats), Warnungen, Hinweise, usw. (<p>-Blöcke dagegen
kommen manchmal im Fließtext vor, und werden eher selten für Floats verwendet).
Das Entfernen der Blockstrukturen erfolgt durch rekursives Parsen anhand der öffnenden
und schließenden Elemente der einzelnen Strukturen, implementiert als Kellerautomat in
WikiTextAnalyzer.BoxStripMangler.mangle.
WikiTextAnalyzer.stripMarkup: Diese Methode entfernt alle Markup-Elemente aus einem
Text — als Eingabe wird Text erwartet, der bereits durch WikiTextAnalyzer.
stripBoxes bereinigt wurde. Die Ersetzungen, die anzuwenden sind, um das zu erreichen,
werden von WikiConfiguration.stripMarkupManglers definiert.
Per Default werden folgende Ersetzungen durchgeführt:
• Zeilen, die nur aus bestehen, definieren horizontale Trennlinien; sie werden entfernt.
• Alle Wiki-Links werden durch ihren Link-Text ersetzt.
• Alle externen Links werden durch ihren Link-Text ersetzt oder, wenn kein Link-Text
angegeben ist, durch die URL, auf die sie verweisen.
• Doppelpunkte am Anfang einer Zeile werden durch eine entsprechende Anzahl Tabs
ersetzt (Unicode U+0009).
• Alle Gruppen von zwei oder drei aufeinanderfolgenden Apostrophen (Unicode
U+0027) werden entfernt.
• Alle verbleibenden XML-artigen Tags werden entfernt—dabei bleibt gegebenenfalls
der Text zwischen Start- und End-Tag erhalten.
• Alle HTML-artige Entity-Referenzen werden unter Verwendung von
WikiTextAnalyzer.EntityDecodeMangler.mangle dekodiert W3C:HTML
(1999).
8.4. Extraktion von Vorlagen
WikiWord analysiert auch die Verwendung von Vorlagen (Templates) auf Wiki-Seiten (.A), vornehmlich,
weil diese einen guten Anhaltspunkt für die Klassifikation der Seite bzw. des Konzeptes
bietet. Die Verarbeitung der Vorlagen ist in WikiTextAnalyzer.extractTemplates implementiert;
sie ist konzeptionell als Kellerautomat umgesetzt, wobei allerdings verschachtelt auftretende
Vorlagen lediglich gezählt werden. Nur die Verwendung auf der „obersten“ Ebene wird registriert
und gespeichert.
8. Analyse des Wiki-Textes 46
Die Vorlagen, die auf einer Wiki-Seite verwendet werden, werden als Datenstruktur vom Typ
java.util.Map repräsentiert; die Schlüssel in der Map sind die normalisierten Namen der verwendeten
Vorlagen, die den Schlüsseln zugeordneten Werte sind selbst wieder Maps, die die
Parameter der Vorlage als Schlüssel-Wert-Paare enthalten; unbenannte (positionale) Parameter
werden, wie in MediaWiki selbst, mit 1 beginnend durchnummeriert. Die Repräsentation in einer
Map hat zur Folge, dass, sollte eine Vorlage auf derselben Seite mehrfach verwendet werden,
nur das letzte Auftreten der Vorlage beachtet wird. Zwar kommt es recht häufig vor, dass Vorlagen
mehrfach verwendet werden, jedoch trifft dies kaum auf die Art von Vorlage zu, die vonWikiWord
von Interesse für die Klassifikation der Seite wäre — oder es ist für die Klassifikation zumindest
unerheblich, wie oft die Vorlage auf der Seite vorkommt.
Vorlagen, deren Name mit „#“ beginnt, werden als Parser Functions erkannt und übergangen.
Vorlagen, deren Namen einen Doppelpunkt „:“ enthält, werden daraufhin untersucht, ob der
Teil vor dem Doppelpunkt der Name eines relevanten Magic Words ist (WikiTextAnalyzer.
getMagicTemplateId) — falls das der Fall ist, wird der Schlüssel auf den kanonischen Namen
des Magic Words gesetzt und der Teil des ursprünglichen Namens, der auf den Doppelpunkt
folgt, als Parameter mit dem Namen „0“ interpretiert. Auf diese Wiese lässt sich insbesondere die
Verwendung von {{DISPLAYTITLE:...}} und {{DEFAULTSORT:...}} festhalten (siehe .A.6);
diese Information kann später zur Bestimmung der Bezeichnungen für ein Konzept beitragen (siehe
.8.9 und .9.1).
8.5. Ressourcenklassifikation
Die Methode WikiTextAnalyzer.determineResourceType bestimmt den ResourceType:
Das heißt, sie weist einerWiki-Seite (Ressource) einen Typ aus einer fest vorgegebenen Menge zu
(vergleiche .4.1). Von diesem Typ hängt die weitere Verarbeitung der Seite ab, siehe .9.1.
Die Zuweisung wird in WikiConfiguration.resourceTypeSensors definiert, die Regeln sind
im Allgemeinen Wiki-spezifisch. Die folgenden Typen werden verwendet:
ARTICLE: Die Ressource ist ein Artikel, das heißt, sie beschreibt ein Konzept. Solche Seiten liefern
den eigentlichen enzyklopädischen Inhalt der Wikipedia. Dieser Typ wird allen Seiten
zugewiesen, die zu keinem der anderen Typen passen.
REDIRECT: Die Ressource definiert eine Weiterleitung auf eine andere Seite (also einen Alias
für das entsprechende Konzept). Dieser Typ wird allen Seiten zugeordnet, die zu dem in
WikiConfig.redirectPattern festgelegten Muster passen.
DISAMBIG: Die Ressource ist eine Begriffsklärungsseite, das heißt, sie führt verschiedene
Bedeutungen eines Terms auf (.8.10). Seiten dieses Typs lassen sich meist an der
Verwendung einer speziellen Vorlage erkennen: in der deutschsprachigen Wikipedia zum
Beispiel wird dieser Typ allen Seiten zugewiesen, die die Vorlage {{Begriffsklärung}}
enthalten.
LIST: Die Ressource ist eine explizite Liste von Seiten (und damit Konzepten) mit einer bestimmten
Eigenschaft. Seiten dieses Typs lassen sich meist an ihrem Titel oder einer ihrer
8. Analyse des Wiki-Textes 47
Kategorien erkennen: in der deutschsprachigen Wikipedia zum Beispiel wird dieser Typ allen
Seiten zugewiesen, die in einer Kategorie sind, die Liste heißt oder deren Name mit
Liste_ beginnt.
CATEGORY: Die Ressource ist eine Kategorie, das heißt, eine Sammlung von Seiten bzw.
Konzepten, die dem Konzept, das die Kategorie selbst repräsentiert, untergeordnet sind.
Dieser Typ wird allen Seiten aus dem Kategorie-Namensraum zugewiesen, das heißt, sie
werden an ihrem Titel erkannt.
BAD: Die Seite ist als problematisch markiert; das betrifft vor allem so genannte Löschkandidaten
WP:LR, also Seiten, die aus irgendeinem Grund zur Löschung aus der Wikipedia vorgeschlagen
wurden. Seiten dieses Typs lassen sich meist über die Verwendung einer speziellen
Vorlage erkennen: in der deutschsprachigen Wikipedia zum Beispiel wird dieser Typ unter
Anderem allen Seiten zugewiesen, die die Vorlage {{Löschen}} enthalten.
8.6. Konzeptklassifikation
Konzepten wird während des Imports ein ConceptType aus einer fest vorgegebenen Menge
von Typen zugewiesen. Diese Konzepttypen sind unabhängig von der Sprache und dem Wiki
(bzw. Korpus) und dienen einer groben Filterung der Konzepte je nach Anwendungsbereich,
insbesondere für die Named Entity Recognition DAKKA UND CUCERZAN (2008), TORAL UND MUNOZ
(2006). Sie werden von der Methode WikiTextAnalyzer.determineConceptType unter
Verwendung der Sensoren in WikiConfiguration.conceptTypeSensors bestimmt. Die folgenden
Konzepttypen sind definiert:
UNKNOWN: Unbekannter Typ — wird verwendet, wenn der Konzepttyp nicht bestimmt werden
konnte, weil es keine beschreibende Ressource (also keine Wiki-Seite) zu dem Konzept
gibt. Das kommt insbesondere für solche Konzepte vor, die im Wiki zwar referenziert, aber
nicht erklärt werden (insbesondere also „rote Links“ und Navigationskategorien, .9.1).
PLACE: Orte, Regionen, geografische Einheiten. Solche Einträge könnten für den Aufbau bzw.
die Erweiterung eines Gazetteers verwendet werden und sind besonders für Aufgaben
wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines
Wörterbuches dagegen können Orte gegebenenfalls ausgelassen werden.
PERSON: Natürliche Personen. Solche Einträge könnten für den Aufbau bzw. die Erweiterung
eines Personenregisters verwendet werden und sind ebenfalls besonders für Aufgaben
wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines
Wörterbuches dagegen sollten Personen in der Regel nicht aufgenommen werden.
ORGANISATION: Organisationen wie Firmen, Regierungs- und Nichtregierungsorganisationen
(NGOs), etc. Auch solche Einträge sind besonders für Aufgaben wie Named Entity
Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines Wörterbuches dagegen
sollten Organisationen meist nicht aufgenommen werden.
8. Analyse des Wiki-Textes 48
NAME: Vor- oder Nachnamen an sich (nicht die betreffenden Personen). Solche Einträge könnten
für den Aufbau bzw. die Erweiterung eines Namenslexikons verwendet werden und sind
unter Umständen für Aufgaben wie Named Entity Recognition und damit Topic-Tracking
nützlich. Beim Aufbau eines Wörterbuches dagegen können Namen im Allgemeinen ausgelassen
werden.
TIME: Zeitperioden (wie z. B. 15. JAHRHUNDERT) oder auch ein wiederkehrendes Datum (wie z. B.
6. APRIL). Solche Einträge könnten für den Aufbau bzw. die Erweiterung eines Almanachs
verwendet werden. Beim Aufbau eines Wörterbuches dagegen sollten sie nicht verwendet
werden.
NUMBER: Zahlen an sich. Diese können beim Aufbau eines Wörterbuches in der Regel übergangen
werden.
LIFEFORM: Lebensformen, also biologische Taxa, Klassen, Familien, Rassen usw. von Tieren und
Pflanzen. Diese können beim Aufbau eines Wörterbuches unter Umständen ausgelassen
werden.
OTHER: Sonstige Konzepte—alle, denen keiner der oben angegebenen Typen zugeordnet werden
konnte.
ALIAS: Pseudo-Konzept für Aliase; wird nur aus technischen Gründen vorübergehend benötigt
(.A.6) und sollte im fertigen Thesaurus nicht vorkommen.
Die Zuordnung von Konzepttypen wird in .12.1 evaluiert.
8.7. Links
Wiki-Links (.A.3) sind eine reiche Informationsquelle: sie bieten Zugang zu menschlichem Urteil
darüber, welche Konzepte für das Verständnis eines anderen Konzeptes relevant sind (durch
Querverweise, WP:V sowie ZESCH U. A. (2007A), PONZETTO UND STRUBE (2007C), GREGOROWICZ UND KRAMER
(2006)), sowie welche Bezeichnung (Term) für welches Konzept geeignet ist (durch den Link-
Text, MIHALCEA (2007) sowie CRASWELL U. A. (2001), EIRON UND MCCURLEY (2003), KRAFT UND ZIEN (2004)).
Die Methode WikiTextAnalyzer.extractLinks extrahiert alleWiki-Links aus dem gegebenen
Text. Der Text sollte bereits mit stripClutter bereinigt worden sein. Der genaue Algorithmus
ist in Anhang E.1 beschrieben.
Die WikiLink-Objekte, die dabei erzeugt werden, haben insbesondere die folgenden
Eigenschaften (vergleiche .A.3):
interwiki: der Präfix für Interwiki-Links (null, falls der Link kein Interwiki-Link ist).
namespace: die ID des Namensraumes, in den der Link verweist, wie von WikiTextAnalyzer.
getNamespaceId geliefert (siehe auch .B.7).
8. Analyse des Wiki-Textes 49
page: der Titel der Seite, auf die der Link zeigt (ohne Namensraum, Interwiki-Präfix, Abschnitt,
etc.) in normalisierter Form (also mit Unterstrichen statt Leerzeichen und dem ersten
Buchstaben als Großbuchstaben).
section: der Abschnitts-Anker (bzw. das „Dokumentenfragment“ nach der URL-Spezifikation)
auf der Zielseite in normalisierter Form (oder null, wenn auf keinen Abschnitt verwiesen
wird).
text: der verwendete Link-Text (Label). Falls nicht explizit ein Link-Text angegeben wurde, so
wird der Text, der zur Angabe des Link-Zieles verwendet wurde, als Link-Text angenommen
und gegebenenfalls der Link-Trail angehängt. Ist der Link ein Kategorisierungslink, hat also
die Eigenschaft magic den Wert CATEGORY, so gibt die Eigenschaft text den Sort-Key für
die Kategorisierung an.
impliedText: ist true genau dann, wenn der Text nicht explizit angegeben wurde, sondern aus
dem Link-Ziel geschlossen wurde.
magic: gibt an, inwiefern der Link „magisch“ ist, dass heißt, ob er eine spezielle Semantik hat.
Die möglichen Werte werden von WikitextAnalyzer.LinkMagic definiert:
NONE: „normaler“ Wiki-Link, keine „Magic“.
CATEGORY: Zuweisung einer Kategorie an die Seite, die den Link enthält.
IMAGE: Einbinden eines Bildes; da Bilder schon von stripClutter entfernt werden, sollte
das hier nicht vorkommen.
LANGUAGE: Verknüpfung mit einer (semantisch) äquivalenten Seite in einer anderen
Sprache.
Dabei ist zu beachten, dass z. B. ein Link in den Kategorie-Namensraum auch ohne die
Kategorisierungssemantik vorkommen kann, nämlich genau dann, wenn er mit einem führenden
Doppelpunkt definiert wurde, also in der Form [[:Category:Baum]]. Dasselbe
gilt analog für Links in den Image-Namensraum und auch für Links mit Interwiki-Präfix
(siehe auch .A.3).
Die so extrahierten Links dienen, je nach ihrer magic, zur Bestimmung der semantischen
Verwandtheit von Konzepten (.9.1.3), dem Zusammenführen von äquivalenten Konzepten aus unterschiedlichenWikipedias
(.9.2.2), dem Aufbau der Subsumtionsrelation oder, unter Verwendung
des Link-Textes, der Zuordnung von Termen zu Konzepten (.9.1). Sie sind damit von zentraler
Bedeutung für den Aufbau des Thesaurus, da sie nahezu alle betrachteten Relationen direkt oder
indirekt definieren.
8.8. Extraktion von Glossen
Definitionssätze (Glossen) können in einem Artikel recht einfach gefunden werden: per
Konvention WP:WSIGA definiert der erste Satz immer den Gegenstand des Artikels. Den
8. Analyse des Wiki-Textes 50
ersten Satz zu finden, ist allerdings nicht ganz trivial: aus dem bereinigten Text (nach
WikiTextAnalyzer.stripClutter) wird zunächst der erste Absatz extrahiert, also der
Text bis zur ersten leeren Zeile, oder der ersten Überschrift. Diese Arbeit erledigt die
Methode WikiTextAnalyzer.extractFirstParagraph, welche auf WikiConfiguration.
extractParagraphMangler zurückgreift. Per Default ist das eine speziell konfigurierte Instanz
von WikiTextAnalyzer.BoxStripMangler, die nach Entfernen aller Blöcke (siehe .8.3) nur
den ersten Absatz liefert—der Rest des Textes wird aus Effizienzgründen nicht weiter behandelt.
Der so gewonnene erste Absatz wird dann mittels WikiTextAnalyzer.stripMarkup weiter
bereinigt, so dass nur noch reiner Text ohne Markup übrig bleibt. Zusätzlich werden weitere
Elemente mittels LanguageConfiguration.sentenceManglers entfernt, per Default insbesondere
alle geklammerten Teilsätze. Aus dem bereinigten ersten Absatz wird dann der erste Satz
als Glosse extrahiert. Der Algorithmus für diese Aufgabe ist in Anhang E.2 detailliert beschrieben.
Bei den so extrahierten Sätzen handelt es sich fast immer um Definitionssätze der Form „X ist/sind/
war (ein) Y“; allerdings kommt es vor, dass die Aussagekraft der Definition zu wünschen übrig
lässt — zum Beispiel lautet der Einleitungssatz für den Artikel Weltoffenheit1: „Weltoffenheit
ist ein Begriff aus der philosophischen Anthropologie.“ — dieser Satz beschreibt nicht, was
WELTOFFENHEIT ist, sondern lediglich, welcher Fachbereich sie untersucht. Aber selbst diese Art
der Ungenauigkeit ist verhältnismäßig selten (.12). Eine mögliche Lösung wäre es, den ganzen
ersten Absatz als Definition zu verwenden oder zumindest zusätzlich vorzuhalten, wie es in der
Literatur vorgeschlagen wurde (vergleiche die Arbeiten in .2.4, z. B. STRUBE UND PONZETTO (2006)).
Im Falle des Artikels Weltoffenheit wäre das zielführend, der Absatz lautet als Ganzes:
Weltoffenheit ist ein Begriff aus der philosophischen Anthropologie. Er bezeichnet
die Entbundenheit des Menschen von organischen Zwängen (Trieben) und seiner unmittelbaren
Umwelt und betont seine Öffnung hin zu einer von ihm selbst hervorgebrachten
kulturellen Welt. Hiermit einher geht, dass der Mensch ohne festgelegte
Verhaltensmuster geboren wird und sich Verhaltenssicherheit in der Welt immer erst
erwerben muss.
Der erste Absatz enthält aber fast immer auch Text, der nicht Teil der Definition des
Artikelgegenstandes ist: der zweite Satz in obigem Beispiel vervollständigt die Definition, der dritte
jedoch ist schon eine Einlassung, die über eine bloße Definition hinausgeht. Immer den gesamten
Absatz zu verwenden würde also das Signal-Rausch-Verhältnis in Bezug auf die Forderung,
eine Definition des Konzeptes zu finden (.5.1), verschlechtern.
Das oben beschriebene Verfahren zur Extraktion von Glossen wird in .12.6 evaluiert.
8.9. Terme
Terme, die als Bezeichnungen für ein bestimmtes Konzept dienen, werden aus verschiedenen
Quellen bestimmt, zum Beispiel aus dem Link-Text (siehe .8.7, vergleiche MIHALCEA (2007)),
1In der deutschsprachigen Wikipedia, zum Zeitpunkt des Erstellens dieser Arbeit:
<http://de.wikipedia.org/w/index.php?title=Weltoffenheit&oldid=44584462>
8. Analyse des Wiki-Textes 51
aus Weiterleitungen (siehe .8.5) oder aus Begriffsklärungen (siehe .8.10). Aber auch aus dem
Artikel selbst können schon Bezeichnungen gewonnen werden: das ist die Aufgabe der Methode
PlainTextAnalyzer.determinePageTerms (bzw. PlainTextAnalyzer.getPageTerms).
Sie bestimmt Bezeichnungen für das Konzept des Artikels per Default aus zwei Quellen:
1. Aus dem „Basisnamen“ des Artikels, wie er von PlainTextAnalyzer.
determineBaseName zurückgegeben wird. Der „Basisname“ ist der Titel des
Artikels, der mittels der Muster in WikiConfiguration.titleSuffixPattern
und WikiConfiguration.titlePrefixPattern bereinigt wurde — per Default wird
dabei insbesondere der geklammerte Suffix vom Titel entfernt, falls vorhanden: aus
Leiter_(Gerät) wird also „Leiter“. Um die entsprechenden Terme zu erhalten, werden
außerdem alle Unterstriche durch Leerzeichen ersetzt, aus Albert_Einstein wird also
„Albert Einstein“.
2. Aus dem Magic Word DISPLAYTITLE, das eine alternative Bezeichnung für das Konzept
definiert (siehe auch .A.6). Diese Magic Words werden bei der Extraktion der Vorlagen
evaluiert (siehe .8.4).
Zusätzliche Terme können aus den Sort-Keys bestimmt werden, die bei der Kategorisierung
der Seite verwendet wurden (zugänglich über die Methode WikiPage.getCategories) sowie
aus der Verwendung des Magic Words DEFAULTSORT (zugänglich über die Methode
PlainTextAnalyzer.getDefaultSortKey), siehe .A.3 und .A.6.
Der Analyzer definiert außerdem eine Methode zur Bestimmung „schlechter“ Terme, nämlich
WikiTextAnalyzer.isBadTerm. Per Default ist das lediglich ein „Sanity-Check“ der Länge
des Terms: diese wird mit WikiConfiguration.minTermLength und WikiConfiguration.
maxTermLength verglichen.
8.10. Begriffsklärungsseiten
Begriffsklärungsseiten (Disambiguierungen) dienen in der Wikipedia dazu, die möglichen
Bedeutungen eines Terms aufzuzählen WP:BKL. Um daraus eine Liste von Konzepten zu erzeugen,
müssen aus dem Wiki-Text der Begriffsklärungsseite alle Wiki-Links (und damit alle
Konzepte) ausgelesen werden, die auf einen Artikel verweisen, der eine der möglichen
Bedeutungen beschreibt. Das Problem besteht darin, dass Begriffsklärungsseiten noch weitere
Wiki-Links enthalten können, insbesondere Querverweise und Links auf Kontext-Begriffe (vergleiche
die in .2.4 beschriebenen Arbeiten, insbesondere DAKKA UND CUCERZAN (2008), ZESCH U. A.
(2007A), PONZETTO UND STRUBE (2007C)).
Diejenigen Links auf der Begriffsklärungsseite zu finden, die auf die einzelnen Bedeutungen verweisen,
ist Aufgabe der Methode WikiTextAnalyzer.extractDisambigLinks. Der Standard-
Ansatz macht dabei zwei wesentliche Annahmen:
• die Begriffsklärungsseite enthält eine Liste von Bedeutungen derart, dass in jeder (relevanten)
Zeile (höchstens) ein Link steht, der auf eine Bedeutung des zu klärenden Terms zeigt.
8. Analyse des Wiki-Textes 52
• enthält eine Zeile mehr als einen Link, so ist der Link mit der größten lexikographischen
Ähnlichkeit zu dem zu klärenden Term auch der, der auf eine Bedeutung dieses Terms verweist.
Auf Basis dieser Annahmen wurde der Algorithmus zur Extraktion der Bedeutungslinks aus der
Begriffsklärungsseite entwickelt, der in .E.3 beschrieben ist. Die Ergebnisse dieses Verfahrens
werden in .13 evaluiert.
Auf diese Weise werden aus Wiki-Seiten diejenigen Eigenschaften extrahiert, die für den Aufbau
eines (zunächst monolingualen) Thesaurus relevant sind. Diese Eigenschaften werden durch ein
WikiPage-Objekt repräsentiert und von der Klasse ConceptImporter dann hinsichtlich ihrer
Bedeutung für das Thesaurusmodell interpretiert (siehe .9.1). Die so gewonnenen Entitäten und
Relationen werden in einem lokalen Datensatz abgelegt (siehe .C.1 und .C.4).
Dieses Kapitel beschreibt, wie der Wiki-Text analysiert wird, um alle für WikiWord relevanten
Eigenschaften (Features) zu extrahieren und wie diese Eigenschaften im Ressourcenmodell
repräsentiert werden. Relevante Eigenschaften sind unter anderem die Wiki-Links (inklusive
Kategorisierung, Language-Links etc., siehe .A.3), der Einleitungssatz (Glosse) und die verwendeten
Vorlagen und ihre Parameter (.A.5).
Die Logik zur Analyse von Wiki-Text (und, soweit notwendig, von natürlicher Sprache),
sind im Java Package de.brightbyte.wikiword.analyzer implementiert. Das Package de.
brightbyte.wikiword.wikis enthält Klassen, die das sprach- bzw. projektspezifische Wissen
repräsentieren, das notwendig ist, um denWiki-Text zu analysieren. Die in diesen Packages implementierten
Regeln und Muster basieren auf Informationen darüber, wieWiki-Text im Allgemeinen
und Wikipedia-Seiten im Speziellen aufgebaut sind. Insbesondere repräsentieren sie:
1. Die Wiki-Text Markup Syntax, wie von MediaWiki festgelegt (Anhang A). Diese Regeln
sind, soweit sie für WikiWord relevant sind, fest in PlainTextAnalyzer kodiert.
2. Die Konventionen und Richtlinien der einzelnen Wiki-Projekte, die zum Beispiel festlegen,
wie Artikel strukturiert werden WP:ARTIKEL, wie Kategorien zu verwenden sind
WP:KAT oder wann und wie Begriffsklärungsseiten anzulegen sind WP:BKL. Diese Regeln
sind, soweit sie für WikiWord relevant sind, zumeist in der projektspezifischen Subklasse
von WikiConfiguration definiert, zum Teil aber auch fest in WikiTextAnalyzer kodiert.
3. Beobachtungen darüber, wann bestimmte Textmuster auftreten oder wie das Wiki-Text-
Markup verwendet wird. Das sind zum Beispiel die Menge der in einer Sprache häufig
auftretenden Abkürzungen, wichtig für das Erkennen des Endes der Glosse — diese
Information ist als sprachspezifisches Wissen in der betreffenden Subklasse von
LanguageConfiguration abgelegt. Ein anderes Beispiel sind Vorlagen, die häufig inline
im Text verwendet werden und daher vor der Verarbeitung aufgelöst werden sollten.
Sie sind mit den anderen projektspezifischen Informationen in einer Subklasse von
WikiConfiguration definiert.
Zu beachten ist, dass WikiWord ad-hoc-Heuristiken nach Möglichkeit vermeidet und statt dessen
versucht, direkt explizite Konventionen zu modellieren. So profitiert WikiWord stärker von
der Intention der Autoren des Wiki-Textes und ist weniger auf die Intuition des Programmierers
angewiesen.
8.1. Klassen
Dieser Abschnitt beschreibt die Klassen, die für die Analyse des Wiki-Textes und eine
Übertragung in das Ressourcenmodell wichtig sind.
8. Analyse des Wiki-Textes 41
PlainTextAnalyzer: Die Klasse PlainTextAnalyzer bietet einfache Funktionen zur Analyse
natürlichsprachlicher Texte, insbesondere eine Methode zur Extraktion des ersten Satzes
aus einem Text, und eine Funktion zur Extraktion einzelner Wörter aus einer Zeichenkette.
Instanzen von PlainTextAnalyzer sollten über die Methode getPlainTextAnalyzer
erzeugt werden: Sie lädt die für die gegebene Sprache passende Implementation und
Konfiguration. Die Default-Implementation funktioniert bei entsprechender Konfiguration
über eine LanguageConfiguration für die meisten europäischen Sprachen.
LanguageConfiguration: Die Klasse LanguageConfiguration repräsentiert eine
Konfiguration von PlainTextAnalyzer für eine bestimmte Sprache. Die wichtigste
sprachspezifische Information, die diese Klasse kapselt, ist ein Muster für
häufig verwendete Abkürzungen dieser Sprache, das bei der Satzgrenzenerkennung
verwendet wird. Für Deutsch und Englisch sind Konfigurationen im Package
de.brightbyte.wikiword.wikis definiert, für weitere Sprachen wie Französisch,
Niederländisch und Norwegisch ist eine rudimentäre Basiskonfiguration vorhanden.
WikiTextAnalyzer: Die Klasse WikiTextAnalyzer enthält Logik für die Verarbeitung vieler
Aspekte des von MediaWiki verwendeten Wiki-Text-Markups (.A). Insbesondere bietet
sie Methoden für den Zugriff auf Wiki-Links, Vorlagen und Artikelabschnitte, sowie
Funktionalität zum Entfernen von Wiki-Markup, um „einfachen“ Text zur weiteren
Verarbeitung zu erzeugen. Instanzen von WikiTextAnalyzer sollten über die Methode
getWikiTextAnalyzer erzeugt werden: Sie lädt die für den gegebenen Korpus passende
Implementation und Konfiguration.
WikiTextAnalyzer.WikiPage: Die Klasse WikiTextAnalyzer.WikiPage repräsentiert eine
Seite imWiki und implementiert damit das Ressourcenmodell vonWikiWord (.4.1). Sie bietet
Zugriff auf die verschiedenen Eigenschaften der Seite, wie sie von WikiTextAnalyzer
erkannt wurden. Diese sind im Anhang D.1 beschrieben.
WikiConfiguration: Die Klasse WikiConfiguration repräsentiert eine Konfiguration von
WikiTextAnalyzer für ein bestimmtes Wiki-Projekt. Sie enthält Wissen über diverse
Konfigurationen und Konventionen für das betreffende Wiki. Konfigurationen sind im
Package de.brightbyte.wikiword.wikis vorhanden für die deutschsprachige (de.
wikipedia.org) und die englischsprachige Wikipedia (en.wikipedia.org) sowie rudimentär
angelegt für die französischsprachige (fr.wikipedia.org), niederländischsprachige
(nl.wikipedia.org) und norwegischsprachige (no.wikipedia.org).
WikiTextSniffer: Die Klasse WikiTextSniffer erlaubt es, typische Elemente vonWiki-Text
zu erkennen. Das ist nützlich für Sanity-Checks: so sollten zum Beispiel Konzeptnamen und
Terme, die ausWiki-Links extrahiert wurden, keinenWiki-Text mehr enthalten. Tun sie das
doch, werden sie ignoriert. Das sollte nur dann auftreten, wennWiki-Markup auf inkorrekte
oder sehr ungewöhnliche Weise verwendet wurde.
Die Klassen und Dateien, die zur Konfiguration Wiki-spezifischer Werte und Muster verwendet
werden, sind in Anhang B.7 beschrieben.
8. Analyse des Wiki-Textes 42
8.2. Mechanismen
Zur Verarbeitung des Wiki-Textes werden verschiedene Techniken verwendet, hauptsächlich aber
Mustererkennung (Pattern Matching), wobei die Muster nicht unbedingt direkt auf den vollen
Wiki-Text angewendet werden, sondern zum Teil auf schon vorverarbeiteten Text oder Textstücke.
Um die verschiedenen Muster und Regeln in WikiConfiguration zu definieren, werden vor
allem die folgenden Klassen verwendet:
Pattern: Ein regulärer Ausdruck, in Javas eigener Implementation JAVA:RE. Wird für einfache
Mustererkennung im Text verwendet.
AbstractAnalyzer.Mangler: Ein Interface für Klassen, die Text manipulieren, also
Ersetzungen irgendeiner Form durchführen. Standard-Implementationen dieses Interfaces
sind WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen
aus Wiki-Text .8.3, WikiTextAnalyzer.EntityDecodeManger zum Auflösen
von HTML Character References W3C:HTML (1999) und AbstractAnalyzer.
RegularExpressionMangler, der beliebige Textersetzungen auf der Basis von regulären
Ausdrücken vornimmt.
AbstractAnalyzer.SuccessiveMangler: Ebenfalls ein Interface für Klassen, die Text manipulieren.
SuccessiveMangler hat dabei zusätzlich die Eigenschaft, dass er den gegebenen
Text nicht unbedingt bis zum Ende verarbeitet und dass die Verarbeitung dort fortgesetzt
werden kann, wo sie unterbrochen wurde. So kann der Text sukzessive verarbeitet werden,
genau so weit, wie das Ergebnis tatsächlich benötigt wird. Die bereits erwähnte Klasse
WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen ausWiki-Text
implementiert dieses Interface zusätzlich zu AbstractAnalyzer.Mangler — das ist insbesondere
für das Aufspüren des ersten Absatzes eines Artikels nützlich.
AbstractAnalyzer.Armorer: Interface für Klassen, die Teile des Textes durch Platzhalter ersetzen,
um sie so vor weiteren Verarbeitungsschritten zu schützen. Das ist insbesondere für
Abschnitte imWiki-Text sinnvoll, die als verbatim markiert sind, auf die also die Regeln des
Wiki-Markup nicht angewendet werden sollen (.8.3). Das sind insbesondere Kommentare
sowie Text in <nowiki>- und <pre>-Tags (siehe .A). Die Standard-Implementation dieses Interfaces ist AbstractAnalyzer.RegularExpressionArmorer — sie identifiziert zu schützende Teile des Wiki-Textes mit Hilfe eines regulären Ausdrucks. WikiTextAnalyzer.Sensor: Interface für Klassen, die eine WikiPage auf Grund einer ihrer Eigenschaften klassifizieren: die Methode sense gibt zurück, ob der Sensor zu der gegebenen WikiPage passt; die Methode getValue liefert den Wert, der der Seite gegebenenfalls zugeordnet werden soll. Für dieses Interface gibt es eine ganze Reihe von Implementationen: HasCategorySensor: Stellt fest, ob die Seite zu einer bestimmten Kategorie gehört. HasCategoryLikeSensor: stellt fest, ob die Seite zu einer Kategorie gehört, deren Name zu einem bestimmten regulären Ausdruck passt. 8. Analyse des Wiki-Textes 43 HasSectionSensor: Stellt fest, ob die Seite einen Abschnitt mit einem bestimmten Namen hat. HasSectionLikeSensor: stellt fest, ob die Seite einen Abschnitt hat, dessen Name zu einem bestimmten regulären Ausdruck passt. HasTemplateSensor: Stellt fest, ob die Seite eine bestimmte Vorlage verwendet. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass diesem Parameter ein bestimmter Wert zugewiesen wurde. HasTemplateLikeSensor: Stellt fest, ob wenn die Seite eine Vorlage verwendet, deren Name zu einem bestimmten regulären Ausdruck passt. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass der Wert, der diesem Parameter zugewiesen wurde, zu einem bestimmten regulären Ausdruck passt. RegularExpressionCleanedTextSensor: Stellt fest, ob der bereinigte Text der Seite (.8.3) zu einem bestimmten regulären Ausdruck passt. RegularExpressionTitleSensor: Stellt fest, ob der Titel der Seite zu einem bestimmten regulären Ausdruck passt. Sensoren dieser Art werden vornehmlich für die Klassifikation von Ressourcen und Konzepten verwendet (siehe .8.5 bzw. .8.6). Mit diesen Mitteln lassen sich die Eigenheiten eines Wikipedia-Projektes ausdrücken und in einer Subklasse von WikiConfiguration festhalten, auf die WikiTextAnalyzer bei der Analyse von Wiki-Text zurückgreifen kann. 8.3. Bereinigen Für die Verarbeitung von Wiki-Text ist es nützlich, bestimmte Arten oder Aspekte des Wiki- Markups vorab zu entfernen. Wie in .D.1 erwähnt, kennt WikiWord vier Versionen des Wiki- Textes: text: der unveränderte Wiki-Text. cleanedText: der Wiki-Text ohne störende Elemente, nach Anwendung von WikiTextAnalyzer.stripClutter. Diese Form des Textes ist die Basis für die weitere Analyse (Extraktion von Vorlagen, Links, Kategorien etc). flatText: der Wiki-Text ohne Blöcke, nach Anwendung von WikiTextAnalyzer. stripBoxes. Diese Form des Textes ist die Basis für die weitere Analyse auf der Textebene (Extraktion der Glosse, von Absätzen etc.). plainText: der Text nach dem Entfernen sämtlicher Markup-Elemente, also nach Anwendung von WikiTextAnalyzer.stripMarkup. Diese Form des Textes kann für eine weitere Verarbeitung auf der Ebene natürlicher Sprache verwendet werden. 8. Analyse des Wiki-Textes 44 Die einzelnen Methoden zum Bereinigen des Textes werden im Folgenden näher erläutert: WikiTextAnalyzer.stripClutter: Diese Methode entfernt oder transformiert alle solchen Wiki-Text-Elemente, die für die Analyse im Rahmen dieser Arbeit unnötig oder störend sind, und ruft dann WikiTextAnalyzer.resolveMagic auf. Alle anderen Analysemethoden werden auf den so bereinigten Text angewendet (oder auf eine weiter bereinigte Version). Vollständig entfernt werden <gallery>-Blöcke, alle eingebundenen Bilder (also Wiki-Links in den Image-Namensraum) MW:IMAGES (.A.3) sowie alle Optionen der Form .*? MW:MAGIC (.A.6). Definiert werden diese Ersetzungen durch WikiConfiguration.stripClutterManglers. Ebenfalls durch WikiConfiguration.stripClutterManglers werden Ersetzungen definiert, die wohlbekannte, wikispezifische Vorlagen ersetzen, insbesondere Formatierungshilfen, die inline im Text verwendet werden. Für die englischsprachige Wikipedia werden zum Beispiel unter Anderem folgende Ersetzungen vorgenommen: {{dot}} durch „·“ (Unicode U+00B7), {{sub|xxx}} durch „xxx“ und {{frac|a|b}} durch „a/b“. Zudem wird eine Vielzahl von Vorlagen einfach entfernt, zum Beispiel {{fact}}, das in der englischen Wikipedia auf eine unbelegte Aussage hinweist. Wichtig ist auch, dass in diesem Schritt Vorlagen ersetzt werden, die Teile von Markup-Konstrukten enthalten, die für die weitere Verarbeitung benötigt werden: In der englischsprachigen Wikipedia muss zum Beispiel die Vorlage {{wrapper}} durch „{|“ (Tabellenanfang) und {{end}} durch „|}“ (Tabellenende) ersetzt werden. Einige Arten von Wiki-Text-Konstrukten werden nicht einfach entfernt oder umgewandelt, sondern durch einen Platzhalter ersetzt, so dass sie zwar von der weiteren Verarbeitung ausgeschlossen sind, aber später wieder eingefügt werden können (Armoring): das ist vor allem für Blöcke der Fall, in denen Wiki-Text-Markup keine Anwendung findet, per Default also bei Kommentaren (<!
