History: DanielKinzler Chapter 8: Analyse des Wiki-Textes

Source of version: 1 (current)

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).