DanielKinzler Chapter 9: Verarbeitung

9. Verarbeitung
Im Kapitel FRAMEWORK (.7) wurde erklärt, wie WikiWord aufgebaut ist und wie der Import-
Prozess als Ganzes abläuft, in ANALYSE DES WIKI-TEXTES (.8) wurde gezeigt, wie Informationen
aus dem Wiki-Text extrahiert werden. Dieses Kapitel soll nun erläutern, wie aufgrund dieser
Informationen ein Thesaurus aufgebaut werden kann.
9.1. Import von Wiki-Seiten
Der Import von Wiki-Seiten in den lokalen Datensatz (das Konzeptmodell) wird von der Methode
handlePage in der Klasse ConceptImporter gesteuert: sie initiiert die Umwandlung der Wiki-
Textes in ein Ressourcenobjekt vom Typ WikiPage (siehe .4.1 bzw. .8 und .D.1) und interpretiert
anschießend die Eigenschaften des Ressourcenobjekts, um daraus die Relationen eines
Thesaurus aufzubauen. Diese werden dann im lokalen Datenmodell abgelegt, das durch
ein Datenzugriffsobjekt vom Typ LocalConceptStoreBuilder modelliert wird (siehe .C.4).
Diese Interpretation der Ressourceneigenschaften als Informationen über die Konzepte, Terme
und Relationen eines Thesaurus soll nun hier genauer erklärt werden.
Vorab ist zu bemerken, dass Relationen im Datenmodell zum Teil mit Metainformationen über
ihre Herkunft versehen sind (vergleiche z. B. .C.2 und .C.2): insbesondere wird häufig die ID
der Ressource (Wiki-Seite) gespeichert, aus der eine Beziehung abgeleitet wurde, sowie in einigen
Fällen zusätzlich die Regel, nach der die Relation extrahiert wurde. Die Regeln sind in
der Enumeration ExtractionRule definiert; sie werden in diesem Kapitel an den betreffenden
Stellen genannt.
Bei der Interpretation der Ressourceneigenschaften werden unter anderem die folgenden Aspekte
betrachtet:
Kategorisierung: Von den Wiki-Links der Seite (.8.7) werden diejenigen betrachtet,
deren magic Property den Wert LinkMagic.CATEGORY hat (.8.7, .A.3). Diese
Kategorisierungslinks auf der Seite werden als Angabe von Konzepten interpretiert, die dem
Konzept, das von der Seite selbst repräsentiert wird, übergeordnet sind: sie sind also eine
Manifestation der Subsumtionsrelation (vergleiche WP:KAT sowie die in .2.4 vorgestellten
Arbeiten, insbesondere VOSS (2006), PONZETTO UND STRUBE (2007B), GREGOROWICZ UND KRAMER (2006)).
Für jeden dieser Links wird die Methode LocalConceptStore.storeConceptBroader
aufgerufen (.C.4), um diese Zuordnung im lokalen Datenmodell festzuhalten (Regel
ExtractionRule.BROADER_FROM_CAT).
Die Zuordnung von übergeordneten Konzepten wird unter Umständen im
Nachbereitungsschritt noch überarbeitet (.9.1.3), insbesondere werden Kategorisierungs-
Aliase aufgelöst (siehe .9.1.2).
Ein Problem, das bei der Interpretation der Kategoriestruktur von Wikipedia auftreten
kann, sind so genannte Wartungskategorien, die sich nicht auf den Inhalt (das
9. Verarbeitung 54
Konzept) der Seite beziehen, sondern auf die Seite selbst — zum Beispiel die Kategorie
Kategorie:Wikipedia:Lückenhaft VOSS (2006). Solche Kategorien sind für einen Thesaurus
nicht von Belang und können sogar irreführend sein, da sie inhaltliche Verwandtschaft suggerieren,
wo keine solche existiert. WikiWord umgeht dieses Problem auf einfache Weise:
Wartungskategorien werden so gut wie nie direkt einem Artikel zugewiesen, sie stammen
fast immer aus einer Vorlage, die zur Markierung des Artikels verwendet wurde. Da
WikiWord den Inhalt von Vorlagen aber nicht auswertet, tauchenWartungskategorien in den
von WikiWord gefundenen Wiki-Links gar nicht auf.
Eine weitere Art von Kategorie, die für einen Thesaurus von zweifelhaftem
Wert sind, sind Navigationskategorien GREGOROWICZ UND KRAMER (2006),
HAMMW¨OHNER (2007). Das sind häufig sogenannte Schnittmengenkategorien, die solche
Artikel enthalten, denen zwei Eigenschaften gemein sind, zum Beispiel
Kategorie:Fluss_in_Bayern oder Kategorie:Politiker_(19._Jahrhundert). Oder es handelt
sich um Metakategorien, die Kategorien mit ähnlicher Struktur zusammenfassen, zum
Beispiel Kategorie:Fluss_nach_Staat oder Kategorie:Person_nach_Epoche. Solche
Navigationskategorien werden von WikiWord als vollwertige Konzepte behandelt — zwar
sind sie als eigenständige Begriffe eher ungebräuchlich oder gar künstlich, dennoch liefern
sie über ihre Zuordnung von über- und untergeordneten Konzepten Informationen über
die semantischen Verwandtheitsbeziehungen und können überdies auch im Thesaurus der
Navigation dienen.
Die Kategoriestruktur derWikipedia soll zwar per Konvention (poly-)hierarchisch sein, diese
Anforderung wird aber von MediaWiki nicht geprüft. So kann die Struktur insbesondere
auch Zyklen enthalten HAMMW¨OHNER (2007). Diese werden von WikiWord während der
Nachbereitung entfernt (.9.1.3).
Link-Text Terme: Es werden alle Wiki-Links der Seite betrachtet (.8.7) und für jeden Link per
LocalConceptStore.storeReference wird ein Eintrag im lokalen Datenmodell vorgenommen,
der das Konzept, auf das der Link verweist, als Bedeutung mit dem verwendeten
Link-Text verbindet (siehe auch .8.9). Die Verwendung eines Link-Textes für eine Referenz
auf einen bestimmten Artikel wird also als Zuordnung einer Bezeichnung an das Konzept interpretiert,
das der Ziel-Artikel beschreibt (vergleiche WP:V, MIHALCEA (2007) sowie CRASWELL
U. A. (2001), EIRON UNDMCCURLEY (2003), KRAFT UND ZIEN (2004)): zum Beispiel würde [[Vereinigte
Staaten|USA]] dafür sorgen, dass der Term „USA“ dem Konzept VEREINIGTE_STAATEN zugeordnet
wird. Diese Extraktionsregel wird mit ExtractionRule.TERM_FROM_LINK identifiziert.
Links, deren magic-Property nicht LinkMagic.NONE ist oder die in einen anderen
Namensraum oder gar auf ein anderes Wiki verweisen, werden dabei übergangen. Für
alle anderen Link-Ziele wird zunächst angenommen, dass es Artikel sind, die Konzepte
beschreiben, es sich also um Seiten mit dem Typ ResourceType.ARTICLE handele.
Im Nachbereitungsschritt (.9.1.3) werden dann Links auf Weiterleitungsseiten aufgelöst
(DatabaseLocalConceptStoreBuilder.finishAliases), sowie alle Links auf andere
Typen von Ressourcen, insbesondere auf Begriffsklärungen und als „schlecht“ markierte
Seiten, entfernt (DatabaseLocalConceptStoreBuilder.finishBadLinks).
9. Verarbeitung 55
Neben der Nutzung der Zuordnung von Link-Text zu Link-Ziel zum Aufbau der
Bedeutungsrelation dienen Wiki-Links auch dazu, den semantischen Kontext von
Konzepten zu definieren (siehe auch .2.3): Querverweise zwischen Artikeln werden
mit der Methode LocalConceptStore.storeLink gespeichert, die sowohl die
Bedeutungszuweisung als auch die Assoziation von Konzepten berücksichtigt (vergleiche
.C.2). Diese Information wird später vor allem zur Bestimmung der semantischen
Verwandtheit verwendet (.9.1.3).
Seitennamen: Eine Wiki-Seite selbst definiert bereits Terme, die als Bezeichnung
für das Konzept der Seite dienen. Diesen Term zu bestimmen, ist Aufgabe von
WikiPage.getPageTerms (siehe .8.9), Termzuordnungen auf dieser Basis werden
mit ExtractionRule.TERM_FROM_TITLE identifiziert. Der erste Term wird
aus dem Seitentitel bestimmt, gegebenenfalls bereinigt von einem Klammerzusatz.
Falls nicht nur ein Titel, sondern ein ganzer Artikel zur Verfügung steht, liefert die
Methode WikiPage.getPageTerms zusätzlich Terme, die mit Hilfe des Magic Words
DISPLAYTITLE angegeben wurden (.A.6).
Während der Verarbeitung werden die Konzeptnamen, Terme und Definitionstexte (Glossen)
Sanity Checks unterzogen, um zu verhindern, dass fehlerhafte Daten in den Thesaurus aufgenommen
werden. Im Einzelnen werden geprüft:
1. Die Länge von Konzeptnamen und Ressourcennamen. Sie muss zwischen den Werten
liegen, die durch WikiConfiguration.minNameLength und WikiConfiguration.
maxNameLength liegen (gemessen in Zeichen) — Terme und Namen, die zu kurz oder
zu lang sind, werden übergangen. Per Default liegt der Minimalwert bei 1 und der
Maximalwert bei 128. DatabaseLocalStoreBuilder verlangt zusätzlich, dass Namen in
UTF-8-kodierter Form UNICODE (2007), S. 103 nicht länger als 255 Byte sein dürfen, sonst
werden sie abgeschnitten1. Diese Beschränkung ergibt sich aus den technischen Vorgaben
der Datenbankstruktur (.C.1).
2. Die Länge von Termen. Es gelten dieselben Beschränkungen wie für Konzeptnamen,
nur dass gegen die Werte von WikiConfiguration.minTermLength und
WikiConfiguration.maxTermLength geprüft wird. Auch die Begrenzung auf maximal
255 Byte effektive Länge gilt für Terme.
3. Die Länge von Definitionstexten. DatabaseLocalStoreBuilder verlangt, dass der Name
in UTF-8-kodierter Form nicht länger sein als 8192 Byte (8KB) sein darf — längere Texte
werden abgeschnitten.
4. Terme und Konzeptnamen dürfen kein Markup enthalten, sonst werden sie übergangen —
geprüft wird das mit Hilfe eines WikiTextSniffer-Objektes. Die Prüfung ist insbesondere
darauf ausgelegt, auch Markup-Teile zu erkennen, die aus fehlerhafter Verwendung
der Wiki-Text-Syntax herrühren. So kann es vorkommen, dass Konzepte und Terme mit
1Dabei ist zu beachten, dass jedes Zeichen in UTF-8 bis zu vier Bytes benötigt. Für lateinische Buchstaben wird jedoch
nur ein Byte pro Zeichen benötigt, für Umlaute und andere in Europa übliche diakritische Zeichen typischerweise
zwei.
9. Verarbeitung 56
legitimem, aber „verdächtigem“ Inhalt übergangen werden — das ist jedoch recht selten.
Definitionstexte, die Markup enthalten, sind erlaubt, lösen aber eine Warnung aus.
Die Interpretation der Eigenschaften der Ressource, repräsentiert durch ein WikiPage-Objekt,
hängt stark vom Typ der Ressource ab, wie er von WikiTextAnalyzer bestimmt wurde (siehe
.8.5). Die Verarbeitung beginnt in jeden Fall damit, dass in der Tabelle resource ein Eintrag für
diese Ressource (bzw. Wiki-Seite) gespeichert wird. Das weitere Vorgehen ist für die einzelnen
Ressourcetypen wie folgt definiert:
Kategorieseiten (CATEGORY): Für Kategorieseiten wird lediglich der Kategorisierungsaspekt
der Seite betrachtet, wie oben beschrieben.
Zu beachten ist dabei, dass für die Kategorie zunächst kein Konzepteintrag angelegt wird,
obwohl Kategorien grundsätzlich als Konzepte interpretiert werden. Der Grund ist, dass es
eine Artikelseite geben könnte, die dieses Konzept beschreibt (siehe dazu .9.1.2). Existiert
keine solche Artikelseite, so wird im Nachbereitungsschritt finishMissingRessources
ein Konzepteintrag vom Typ ConceptType.UNKNOWN für das Kategorie-Konzept erstellt
(.9.1.3), allerdings erst nachdem alle Kategorisierungsaliase aufgelöst wurden (.9.1.2).
Eine weitere Information in Kategorieseiten, deren Verarbeitung vielversprechend ist,
sind die Language-Links. Sie referenzieren Kategorien in anderen Wikis (also in anderen
Sprachen) und könnten die Verknüpfungen zwischen den Artikeln unterschiedlicher
Sprachen ergänzen HAMMW¨OHNER (2007B). Die Auswertung dieser Information wurde
hier jedoch aufgrund technischer Schwierigkeiten nicht weiter verfolgt und verbleibt als
Gegenstand zukünftiger Forschung.
Artikelseiten (ARTICLE): Da Artikelseiten per Definition stets ein Konzept beschreiben, wird
zuerst die Methode LocalConceptStore.storeConcept aufgerufen, um einen Eintrag
für das betreffende Konzept anzulegen. Der volle Seitentitel dient dabei als eindeutiger
Bezeichner des Konzeptes. Dann wird die Definition des Konzeptes (die Glosse) aus dem
Artikeltext extrahiert (.8.8) und mittels LocalConceptStore.storeDefinition im lokalen
Datenmodell abgelegt.
Als nächstes werden alle Wiki-Links der Seite bestimmt (.8.7). Auf dieser Grundlage werden
die Link-Text-Terme gespeichert und die Kategorisierung bestimmt, wie oben beschrieben.
Zusätzlich werden noch die folgenden Aspekte betrachtet:
1. Querverweise zwischen Artikeln werden als Referenzbeziehung bzw. Assoziation
zwischen Konzepten interpretiert. Daher wird beim Speichern der Link-Text-
Terme statt der Methode LocalConceptStore.storeReference die Methode
LocalConceptStore.storeLink verwendet, die, zusätzlich zu der Beziehung zwischen
Link-Text und Ziel-Konzept, eine Beziehung zwischen dem im Artikel beschriebenen
Quell-Konzept und dem Ziel-Konzept herstellt (vergleiche .C.2). Diese
Daten dienen unter anderem der Berechnung der semantischen Verwandtheit zwischen
Termen (.9.1.3).
2. Wiki-Links können auch auf Teile von Seiten verweisen — solche Abschnitte, die als
Verweis-Ziele dienen, werden als eigene Konzepte interpretiert, die dem Konzept, das
vom Gesamtartikel beschrieben wird, untergeordnet sind (.9.1.1).
9. Verarbeitung 57
3. Bei der Kategorisierung angegebene Sort-Keys werden verwendet, um dem Konzept,
auf das sich der Artikel bezieht, per LocalConceptStore.storeReference weitere
Terme zuzuordnen (ExtractionRule.TERM_FROM_SORTKEY). So würde zum
Beispiel die Angabe [[Kategorie:Pazifist|Einstein, Albert]] auf der Seite
Albert_Einstein dafür sorgen, dass der Term „Einstein, Albert“ dem Konzept
ALBERT_EINSTEIN zugeordnet wird (.A.3). Der Sort-Key wird ebenfalls berücksichtigt,
wenn er über das Magic Word DEFAULTSORT angegeben wurde (zugänglich über die
Methode PlainTextAnalyzer.getDefaultSortKey, siehe auch .A.6).
4. Bei der Bestimmung der Kategorisierung des Artikels kann der Artikel als
Hauptartikel der betreffenden Kategorie erkannt werden, also als der Artikel, der das
Konzept definiert, auf das sich die Kategorie bezieht: siehe .9.1.2. In diesem Fall wird
zusätzlich der Name der Kategorie als Term für das Konzept des Artikels gespeichert
(ExtractionRule.TERM_FROM_CAT_NAME).
5. Language-Links, also Wiki-Links, die den magic-Wert LinkMagic.LANGUAGE haben,
werden als Verweise auf eine Beschreibung desselben oder eines ähnlichen
Konzeptes in einer anderen Sprache interpretiert (siehe .A.3 sowie WP:INTERLANG).
Diese Verweise werden mittels LocalConceptStore.storeLanguageLink im lokalen
Datenmodell abgelegt. Sie dienen der Berechnung der semantischen Ähnlichkeit
zwischen Termen sowie dem Zusammenführen von sprachspezifischen zu sprachübergreifenden
Konzepten (.9.2.2).
Begriffsklärungsseiten (DISAMBIG): Zunächst werden die Link-Text-Terme auf der Seite interpretiert,
wie oben beschrieben.
Dann werden alle Disambiguierungslinks bestimmt (.8.10), also Verweise auf Artikel, die
eine der Bedeutungen definieren, die zum Titel der Begriffsklärungsseite passen. Jeder
dieser Bedeutungen wird nun mittels LocalConceptStore.storeReference der Name
der Begriffsklärungsseite als Bezeichnung zugewiesen (ExtractionRule.TERM_FROM_
DISAMBIG). Der Name der Begriffsklärungsseite wird also als Bezeichnung für diejenigen
Konzepte interpretiert, die die Begriffsklärung als mögliche Bedeutungen auflistet. Das entspricht
genau der Intention von Begriffsklärungsseiten, wie sie in WP:BKL beschrieben ist
(vergleiche auch STRUBE UND PONZETTO (2006), GREGOROWICZ UND KRAMER (2006)).
Weiterleitungsseiten (REDIRECT): Über die Methode WikiPage.getRedirect wird die
Zielseite der Weiterleitung bestimmt. Mittels LocalConceptStore.storeReference
wird dann der Name der Weiterleitungsseite als Bezeichnung für das Konzept registriert,
auf das dieWeiterleitung zeigt (ExtractionRule.TERM_FROM_REDIRECT). Dabei kann es
durchaus vorkommen, dass der Name derWeiterleitung eigentlich für ein Konzept steht, das
dem Zielkonzept untergeordnet ist—das kann aber bei der Interpretation von Link-Text genauso
geschehen; auch scheint diese Art von Fehlern keinen allzu problematischen Einfluss
auf das Ergebnis zu haben, siehe .12.5. Häufig tritt dieser Fall zum Beispiel für Stadtteile
auf, die keinen eigenen Artikel haben, sondern in dem Artikel beschrieben werden, der sich
mit der Stadt als Ganzes befasst.
Zusätzlich wird mittels LocalConceptStore.storeConcept ein vorläufiger
Konzepteintrag vom Typ ALIAS angelegt und per LocalConceptStore.
9. Verarbeitung 58
storeConceptAlias als Alias für das Zielkonzept registriert. Der vorläufige
Konzepteintrag ist aus technischen Gründen notwendig, er wird in der Nachbereitungsphase
von der Methode LocalConceptStore.finishAliases zur Auflösung von Referenzen
auf die Weiterleitungsseite verwendet und dann gelöscht (siehe .9.1.3).
Listen (LIST): Für Listen werden lediglich die Link-Text-Terme interpretiert.
Konzeptionell könnten aus Listenartikeln auch Einträge für die Subsumtionsrelation gefolgert
werden: Einträge in einer Liste von X würden dann als X untergeordnet interpretiert.
Dabei ergeben sich allerdings zwei Probleme:
1. Das übergeordnete Konzept, zu dem die Liste gehört, müsste namentlich identifiziert
und gegebenenfalls mit der Liste assoziiert werden. Die Extraktion des
Konzeptnamens aus dem Listentitel wäre für einfache Fälle machbar, z. B. für Titel
der Form Liste_der_X — bei manchen Titeln würde das aber fehlschlagen, z. B.
bei der Seite Comicformat, einer Auflistung unterschiedlicher Comic-Formate. Eine
Zuordnung zu dem entsprechenden Artikel, der dieses Konzept beschreibt, kann aber
bei mehrdeutigen Namen schwierig sein.
2. Listenartikel sind sehr unterschiedlich formatiert. Einfache Aufzählungen könnten
leicht verarbeitet werden, Listenartikel sind aber häufig in Abschnitte gegliedert.
Zum Teil sind Listen auch als Tabellen formatiert, bei denen die Bedeutung einzelner
Spalten nicht automatisch zu erkennen ist (z. B. bei den Seiten Marientitel
und Präfixe_von_Schiffsnamen2). Manchmal sind die Auflistungen hierarchisch, mit
Über- und Untereinträgen. Alles in allem gibt es, anders als bei Begriffsklärungsseiten,
keine einheitliche Struktur für Listenartikel, so dass es schwierig ist, sie sinnvoll zu
verarbeiten.
3. Ein Problem mit der Erkennung von Listenartikeln ist, dass zum Teil Seiten als Listen
klassifiziert werden, die selbst keine Liste sind, sondern eine Liste beschreiben, zum
Beispiel Rote_Liste_gefährdeter_Arten. In manchen Fällen trifft sogar beides zu: der
Artikel beschreibt eine Liste und enthält die Liste selbst — was eine Unterscheidung
vollends unmöglich macht.
Da es parallel zu einem Listenartikel in der Regel auch eine Kategorie mit ähnlichem
Umfang gibt, lohnt sich der Versuch, die Listenartikel zu interpretieren, kaum. In der vorliegenden
Implementation von WikiWord wird deshalb die Verknüpfungsstruktur von Seiten,
die als Liste erkannt wurden, nicht untersucht.
Schlechte Seiten (BAD): Seiten, die zur Löschung vorgeschlagen wurden WP:LR oder anderweitig
als problematisch markiert sind, werden ignoriert.
9.1.1. Konzepte aus Abschnitten
MediaWiki erlaubt (genau wie HTML) Verknüpfungen auf „Anker“ W3C:HTML (1999), also auf
bestimmte Stellen innerhalb eines Artikels bzw., in URI-Terminologie, auf Dokument-Fragmente
2Beides nebenbei auch Beispiele für schwer zu interpretierende Titel.
9. Verarbeitung 59
RFC:3986 (2005). In MediaWiki erzeugt jede Überschrift einen Anker, es ist also möglich, Wiki-
Links direkt auf einzelne Abschnitte von Artikeln zu setzen (siehe auch .8.7 und .A.3). Solche
Verknüpfungen auf Abschnitte werden vor allem dann verwendet, wenn auf ein spezielles Konzept
verwiesen werden soll, das in diesem Abschnitt beschrieben ist und keinen eigenen Artikel hat; dabei
handelt es sich in der Regel um ein dem Thema des Gesamtartikels untergeordnetes Konzept.
So könnte z. B. der Wiki-Link [[Myanmar#Geschichte|Burmesische Geschichte]] auftreten:
er verweist unter dem Term „Burmesische Geschichte“ auf das Konzept MYANMAR#GESCHICHTE,
welches im Abschnitt Geschichte im Artikel Myanmar behandelt wird — wir gehen davon aus,
dass es sich dabei um ein Konzept handelt, das auf irgendeine Art ein „Teil“ des Konzeptes
MYANMAR ist, diesem also über die Subsumtionsrelation untergeordnet ist.
Allerdings ist es schwierig, über ein solches Konzept, das aus einem Seitenabschnitt entstanden ist,
mehr zu sagen, als dass es dem Konzept, das der Gesamtartikel beschreibt, untergeordnet ist: ein
solcher Abschnitt enthält in der Regel keinen Definitionssatz und er kann auch nicht einzeln kategorisiert
werden; selbst die Zuordnung von Templates wäre schwierig. So wird auf eine weitere
Analyse des Abschnitts verzichtet: Konzepte, die sich aus Verweisen auf Abschnitte ergeben, werden
lediglich vorgemerkt (.C.2) und dann in der Nachbereitung des Imports als Konzepteinträge
von unbekanntem Typ (ConceptType.UNKNOWN) erzeugt und ihrem Oberkonzept zugeordnet
(.9.1.3).
9.1.2. Kategorien und Konzepte
Wie oben beschrieben, versteht WikiWord Kategorien zwar als Konzepte in so fern, als dass
die Kategorisierung als eine Unterordnung eines Konzepts unter ein anderes im Sinne der
Subsumtionsrelation interpretiert wird. Jedoch erzeugt WikiWord für Kategorie-Seiten zunächst
keinen eigenen Konzepteintrag, da es einen Artikel geben könnte, der das Konzept näher beschreibt—
ein solcher Artikel wird Hauptartikel der Kategorie genannt.
Es ist nun wünschenswert, die Kategorie und ihren Hauptartikel als Repräsentationen desselben
Konzeptes zu interpretieren und ihre Eigenschaften zu vereinigen. Dabei sind drei Fälle zu unterscheiden:
1. Es gibt einen Artikel (also eine Seite mit dem Typ ARTICLE), der genau den gleichen Titel
hat wie die Kategorie (ohne Namensraum-Präfix, aber gegebenenfalls mit Klammerzusatz).
Dann geht WikiWord davon aus, dass dieser Artikel der Hauptartikel der Kategorie ist,
das heißt, dass sie sich auch auf dasselbe Konzept beziehen. Da der Titel als eindeutiger
Bezeichner für das Konzept dient, zeigen in diesem Fall alle Verknüpfungen der Kategorie
automatisch auf das betreffende Konzept, es ist keine weitere Anpassung notwendig.
2. Es gibt einen Hauptartikel für die Kategorie, aber er hat einen anderen Titel. Dies ist der
kritische Fall, der unten näher betrachtet wird.
3. Es wurde kein zu der Kategorie passender Artikel gefunden. In diesem Fall wird während
der Nachbereitung im Schritt finishMissingConcepts ein „leeres“ Konzept vom Typ
ConceptType.UNKNOWN für die Kategorie erstellt. Die einzige Information, die über dieses
9. Verarbeitung 60
Konzept bekannt ist, ist seine Position in dem durch die Subsumtionsrelation beschriebenen
Unterordnungsgraphen. Das ist besonders für Navigationskategorien der Fall, kann aber
auch dann auftreten, wenn die Heuristik zur Bestimmung eines passenden Artikels fehlschlägt
oder ein solcher Artikel einfach fehlt.
Der kritische Fall ist nun der, dass es zwar einen Hauptartikel für die Kategorie gibt, der Titel
dieses Artikels aber von dem Titel der Kategorie verschieden ist. Besonders häufig kommt
dies in Projekten vor, die per Konvention für Kategorien den Plural verwenden, während für
Artikel der Singular benutzt wird — das ist zum Beispiel in der englischsprachigen Wikipedia
der Fall. Ansonsten tritt dieses Problem oft dann auf, wenn der Titel des Hauptartikels einen
Klammerzusatz trägt, die Kategorie aber nicht (die Seite mit dem entsprechenden Titel ohne
Klammerzusatz im Hauptnamensraum ist dann in der Regel eine Begriffsklärungsseite).
Es gilt nun einerseits, diesen Fall zu erkennen, also Artikel korrekt als Hauptartikel von Kategorien
zu identifizieren und entsprechend zuzuordnen, und andererseits, die durch die Unterschiedlichkeit
der Titel verursachte Inkonsistenz in den Relationen zu beseitigen: das bedeutet, den Titel der
Kategorie als Alias für das Konzept des Hauptartikels zu behandeln.
Die Heuristik, um Hauptartikel von Kategorien zu erkennen, basiert auf den zur Kategorisierung
verwendeten Sort-Keys: Per Konvention ist der Hauptartikel einer Kategorie dieser direkt zugeordnet
und zwar unter Verwendung eines speziellen Sort-Keys, der dafür sorgt, dass der Artikel
in der Kategorie ganz vorne, vor allen anderen Seiten aufgeführt wird; konkret werden dafür
einzelne Sonderzeichen verwendet, die in der Kollationsreihenfolge vor den alphanumerischen
Zeichen stehen. Welche Sort-Keys als Markierung für Hauptartikel interpretiert werden, wird von
WikiConfiguration.mainArtikeMarkerPattern festgelegt — per Default wird der reguläre
Ausdruck ^- !_*$@#+~/%?$ verwendet WP:KAT.
Allerdings erhält nicht unbedingt ausschließlich der Hauptartikel einer Kategorie so einen speziellen
Sort-Key: es können weitere Artikel auf diese Weise markiert sein, die für die Kategorie besonders
wichtig sind oder anderweitig vom „normalen“ Inhalt der Kategorie abgesetzt werden sollen,
zum Beispiel Frühmittelalter und Spätmittelalter in Kategorie:Mittelalter. Daher werden nur
solche Artikel als Hauptartikel in Betracht gezogen, deren Titel dem Titel der Kategorie lexikographisch
ausreichend ähnlich ist: die beiden Titel werden von Klammerzusätzen und Großschreibung
befreit und dann ihre Levenshtein-Ähnlichkeit3 bestimmt. Nur wenn der Ähnlichkeitswert über
dem Wert liegt, den WikiConfiguration.maxWordFormDistance festlegt (per Default 1/3),
wird der Artikel als Hauptartikel der Kategorie in Betracht gezogen. Dieser Vergleich ist in der
Methode WikiTextAnalyer.mayBeFormOf implementiert.
Ein Artikel wird dementsprechend (vorläufig) als Hauptartikel einer Kategorie angesehen, wenn
er der Kategorie unter Verwendung eines speziellen Sort-Keys zugeordnet ist und sein Titel dem
Titel der Kategorie lexikographisch hinreichend ähnlich ist. In diesem Fall wird die Zuordnung per
LocalConceptStoreBuilder.storeConceptAlias registriert, unter Verwendung des scope-
Wertes AliasScope.BROADER, um anzuzeigen, dass es sich um einen Alias bezüglich der
Kategorisierung handelt: so wird ein Kategorisierungsalias definiert.
3Die normierte Levenshtein-Distanz nach LEVENSHTEIN (1966), wie durch DefaultLinkSimilarityMeasure.
calculateLevenshteinSimilarity implementiert; vergleiche .E.3
9. Verarbeitung 61
Um nun die Eigenschaften der Kategorie — nämlich ihre Einordnung in die Subsumtionsrelation
— auf den Konzepteintrag des Hauptartikel zu übertragen, werden im Nachbereitungsschritt
finishMissingConcpets in der Subsumtionsrelation sämtliche Referenzen auf die Kategorie
durch Referenzen auf das Konzept des Hauptartikels ersetzt.
Bevor die Kategorisierungsaliase so angewendet und aufgelöst werden können, müssen sie zunächst
noch bereinigt werden: im Schritt finishBadLinks der Nachbereitung werden einige
Kategorisierungsaliase wieder gelöscht, und zwar nach folgenden Regeln:
1. Ein Kategorisierungsalias ist zu löschen, wenn es einen Artikel gibt, der den exakt gleichen
Titel wie die betreffende Kategorie hat — dieser Artikel ist dann automatisch der
Hauptartikel der Kategorie, ohne dass eine Auflösung von Aliasen notwendig wäre, selbst
dann, wenn es andere Artikel gibt, die als Hauptartikel in Betracht kämen. Das ist zum
Beispiel für Kategorie:Mittelalter der Fall: Frühmittelalter und Spätmittelalter sind mögliche
Hauptartikel der Kategorie, da jedoch der Artikel Mittelalter existiert, wird dieser als
Hauptartikel bestimmt und alle Kategorisierungsaliase für MITTELALTER werden gelöscht.
2. Ein Kategorisierungsalias ist zu löschen, wenn es mehr als einen Artikel gibt, der als
Hauptartikel in Betracht käme. In diesem Fall sind die Konzepte der einzelnen Artikel vermutlich
dem Konzept der Kategorie untergeordnet und die Kategorie sollte somit einen
eigenen Konzepteintrag erhalten.
Zum Beispiel ist das für Kategorie:Arbeit der Fall: die Seite Arbeit existiert zwar,
ist aber eine Begriffsklärung4; Kandidaten für Hauptartikel der Kategorie sind
Arbeit_(Sozialwissenschaften), Arbeit_(Philosophie) und Arbeiter. Da die Zuweisung
eines Hauptartikels aber nicht eindeutig ist, werden alle Kategorisierungsaliase für
ARBEIT wieder gelöscht und ARBEIT als eigenes Konzept eingeführt, das den Konzepten
ARBEIT_(SOZIALWISSENSCHAFTEN), ARBEIT_(PHILOSOPHIE) und ARBEITER übergeordnet ist.
Für eine Evaluation der hier beschriebenen Heuristiken siehe .12.2.
9.1.3. Nachbereitung
Die Nachbereitung des Konzeptimports dient dazu, die gewonnenen Daten zu bereinigen und
zu konsolidieren. Das erfolgt vor allem durch Operationen direkt auf der Datenbank, eine
programmatische Verarbeitung der Daten wird weitgehend vermieden. Die Nachbereitung ist
in die folgenden Schritte gegliedert, die in LocalConceptStoreBuilder definiert und in
DatabaseLocalConceptStoreBuilder implementiert sind:
finishBadLinks: Dieser Schritt dient dazu, Verknüpfungen zu löschen, die für die Erstellung
eines Thesaurus nutzlos oder irreführend wären — das sind insbesondere solche Links
oder Kategorisierungen, die auf eine Seite zeigen, die kein Konzept repräsentiert — also
vor allem Begriffsklärungsseiten. Verweise auf Begriffsklärungsseiten können nicht als
4Dass der Titel einer Kategorie mit dem Titel einer Begriffsklärung zusammenfällt, kommt recht häufig vor.
9. Verarbeitung 62
Beziehungen zwischen Konzepten (oder zwischen Termen und Konzepten) interpretiert
werden, da unklar ist, welches Konzept als Ziel gemeint ist. Daher ist es besser, sie vollständig
zu ignorieren.
Neben solchen „ungültigen“ Wiki-Links werden in diesem Schritt auch unerwünschte
Kategorisierungen, Weiterleitungen und Kategorisierungsaliase (.9.1.2) gelöscht. Im einzelnen
bedeutet das:
1. Es werden aus der Tabelle link (.C.2) alle Einträge gelöscht, deren target_name
auf einen Eintrag in der Tabelle resource (.C.2) verweist, der einen der folgenden
Typen hat: ResourceType.DISAMBIG, ResourceType.LIST oder ResourceType.
BAD. Verweise auf Ressourcen mit dem Typ ResourceType.REDIRECT bleiben zunächst
erhalten, diese werden im Schritt finishAliases aufgelöst.
2. Aus der Tabelle alias (.C.2) werden ebenfalls die Einträge gelöscht, die über
target_name auf eine „schlechte“ Ressource verweisen, nur dass hier zusätzlich
zu den Ressourcen mit den Typen ResourceType.DISAMBIG, ResourceType.LIST
oder ResourceType.BAD auch die mit Typ ResourceType.REDIRECT als „schlecht“
betrachtet werden—auf dieseWeise werdenWeiterleitungen aufWeiterleitungen entfernt;
solche mehrfachenWeiterleitungen werden von MediaWiki nicht unterstützt und
sind daher als Fehler in der Datenbasis anzusehen.
3. Aus der Tabelle alias werden alle die Einträge gelöscht, deren scope AliasScope.
BROADER ist und deren Feld source_name auf ein existierendes Konzept verweist. So
werden alle Kategorisierungsaliase für diejenigen Kategorien entfernt, für die es einen
Hauptartikel mit gleichem Namen gibt (vergleiche .9.1.2).
4. Aus der Tabelle alias werden außerdem all die Einträge gelöscht, deren scope
AliasScope.BROADER ist und deren Feld source_name nicht eindeutig ist, also
mehrfach vorkommt. So findet keine Zuweisung eines Hauptartikels statt, wenn mehrere
Artikel als Hauptartikel der gleichen Kategorie in Frage kommen (vergleiche
.9.1.2).
5. Aus der Tabelle section (.C.2) werden alle Einträge gelöscht, deren concept_name
auf einen Eintrag in der Tabelle resource verweist, der einen der folgenden Typen
hat: ResourceType.DISAMBIG, ResourceType.LIST oder ResourceType.BAD.
Das bedeutet, dass Konzepte aus Abschnitten (.9.1.1) nur für „richtige“ Artikelseiten
definiert sind.
6. Aus der Tabelle section werden alle Einträge gelöscht, deren Feld concept_name
nicht auf ein existierendes Konzept verweist. Das bedeutet, dass Wiki-Links ignoriert
werden, die auf einen Abschnitt in einem Artikel verweisen, den es gar nicht gibt.
finishSections: Dieser Schritt dient der Verarbeitung der Artikelabschnitte, die als Link-Ziele
vorkommen und daher als Konzepte modelliert werden sollen (vergleiche .9.1.1). Für jeden
Abschnitt wird ein Konzepteintrag angelegt und dem Konzept des Artikels, von dem der
Abschnitt ein Teil ist, im Sinne der Subsumtionsbeziehung untergeordnet. Konkret bedeutet
das:
9. Verarbeitung 63
1. Für jeden Eintrag in der Tabelle section (.C.2) wird ein Eintrag in der Tabelle
concept (.C.2) angelegt, wobei concept.name auf den Wert von section.
concept_name gesetzt wird und concept.type auf ConceptType.UNKNOWN.
2. Für jeden Eintrag in der Tabelle section wird ein Eintrag in der Tabelle broader
(.C.2) vorgenommen, so dass der Wert des Feldes broader.broad_name dem
Wert von section.concept_name entspricht und der Wert des Feldes broader.
narrow_name dem von section.section_name. Die verwendete Regel wird als
ExtractionRule.BROADER_FROM_SECTION angegeben.
finishMissingConcpets: In diesem Schritt werden Einträge für Konzepte erzeugt, auf die es
Referenzen gibt, zu denen aber kein beschreibender Artikel existiert. Das sind vor allem
Einträge für Wiki-Links auf noch nicht existierende Artikel („rote“ Links) sowie Einträge
für Kategorien, die keinen Hauptartikel haben, also vornehmlich Navigationskategorien
(vergleiche .9.1.2). Für solche Konzepte ohne eigene Wiki-Seite wird ein Eintrag mit dem
Typ ConceptType.UNKNOWN angelegt. Im Einzelnen:
1. Für jeden Wert von link.target_name (.C.2), der nicht auf ein existierendes
Konzept zeigt, wird ein Konzepteintrag mit dem entsprechenden Namen in der Tabelle
concept angelegt.
2. Als Vorbereitung für den nächsten Teilschritt werden nun die Kategorisierungsaliase
aufgelöst: In der Tabelle broader (.C.2) werden alleWerte in den Feldern broad und
broad_name bzw. narrow und narrow_name, für die es einen passenden Eintrag in
der Tabelle alias (.C.2) mit einem scope von AliasScope.BROADER gibt, mit den
entsprechenden Werten von alias.target und alias.target_name ersetzt.
3. Für jeden Wert der Felder broad_name sowie narrow_name in der Tabelle broader
(.C.2), der nicht auf ein existierendes Konzept zeigt, wird ein Konzepteintrag angelegt.
Das sind vor allem Navigationskategorien, zu denen es keinen entsprechenden Artikel
gibt.
finishIdReferences: In vielen Fällen werden in der Datenstruktur von WikiWord Referenzen
redundant über den Namen eines Konzeptes sowie die ID des Konzepts geführt (zum
Beispiel in den Tabellen link (.C.2) und broader (.C.2)). Einer der Gründe dafür ist,
dass so Referenzen gespeichert werden können, ohne dass die laufende ID für das betreffende
Konzept bekannt sein oder ermittelt werden muss — das Feld, dass sich auf die ID
bezieht, bleibt dann vorerst NULL. In diesem Schritt der Nachbereitung werden nun die fehlenden
Werte in den Referenzfeldern, die sich auf die Konzept-ID beziehen, nachgetragen.
Im Einzelnen:
1. In der Tabelle link werden fehlende IDs in der Spalte target anhand der
Konzeptnamen in der Spalte target_name nachgetragen. Die Zuordnung von IDs
zu Namen wird der Tabelle concept entnommen.
2. In der Tabelle broader werden fehlende IDs in den Spalten broad bzw. narrow anhand
der Konzeptnamen in den Spalten broad_name bzw. narrow_name nachgetragen.
9. Verarbeitung 64
3. In der Tabelle alias (.C.2) werden fehlende IDs in der Spalte target anhand der
Konzeptnamen in der Spalte target_name nachgetragen.
Es ist auch möglich, alle Relationen direkt mit numerischen IDs aufzubauen und damit
den zusätzlichen Aufwand dieses Nachbereitungsschritts zu vermeiden: Eine Abbildung
von Konzeptnamen zu IDs wird dafür im Arbeitsspeicher gehalten (und zusätzlich in einer
Datei gespeichert, um nach einer Unterbrechung eine Fortsetzung des Imports mit Hilfe
des Agenda-Objekts zu erlauben).
Dieser Modus kann über den Tweak-Wert dbstore.idManager=true aktiviert werden,
wobei darauf zu achten ist, dass der Java VM über den Parameter -Xmx ausreichend Platz
auf dem Heap zugewiesen wurde, um die ID-Map im Arbeitsspeicher zu halten: Für jeden
Eintrag in der Map ist mit einem Overhead von mindestens 150 Byte zu rechnen, in der
Praxis hat es sich als sinnvoll herausgestellt, inklusive aller Puffer und interner Strukturen
mit insgesamt einem Kilobyte Speicherbedarf pro Konzept zu rechnen, wobei alle „unbekannten“
(artikellosen) Konzepte mitgezählt werden. Für die Verarbeitung der englischsprachigen
Wikipedia mit acht Millionen Konzepten ergibt sich damit ein Speicherbedarf von
bis zu acht Gigabyte5. Wird keine ID-Map im Speicher gehalten, so sind 512 Megabyte für
den Import von Wikis aller Größen ausreichend.
finishAliases: In diesem Schritt werden Aliase aufgelöst (vergleiche .A.6 und .1.2) —
das heißt, in sämtlichen Tabellen werden Referenzen auf solche Konzepte vom Typ
ConceptType.ALIAS durch diejenigen ersetzt, auf die der betreffende Alias-Eintrag in der
Tabelle alias (.C.2) verweist. Im Einzelnen:
1. In der Tabelle link werden Aliase für Werte in den Spalten target und target_
name aufgelöst: Einträge, die zuWerten in alias.source bzw. alias.source_name
passen, werden durch die entsprechenden Werte von alias.target bzw. alias.
target_name ersetzt.
2. In der Tabelle broader werden die Spalten narrow und narrow_name sowie broad
und broad_name entsprechend den Einträgen in der alias Tabelle angepasst.
3. Aus der Tabelle concept (.C.2) werden alle Einträge mit dem Typ ConceptType.
ALIAS gelöscht.
4. Aus der Tabelle link werden alle Einträge gelöscht, deren Feld target auf kein
existierendes Konzept mehr verweist — das heißt solche Links, die auf fehlerhafte
Weiterleitungen verwiesen.
5. Für jeden Wert der Felder broad_name sowie narrow_name in der Tabelle broader
(.C.2), der nicht auf ein existierendes Konzept zeigt, wird ein Konzepteintrag angelegt.
Diese Wiederholung aus dem Schritt finishMissingConcpets dient unter anderem
dazu, Konzepte neu zu erzeugen, die gelöscht wurden, weil sie als Alias markiert waren,
die aber als Teil der Subsumtionsrelation noch benötigt werden6.
5Zur Speicherung der Abbildung wird die Standard-Klasse java.util.HashMap verwendet. Der Platzaufwand ließe
sich eventuell durch die Verwendung einer geeigneten Implementation eines Trie oder DAWG reduzieren (vergleiche
HEYER U. A. (2006), S. 68).
6Das tritt nur ein, wenn es sich um einen „schlechten“ Alias gehandelt hat, z. B. einen, der auf eine Begriffsklärung
zeigte und deshalb keinen Eintrag in der der alias-Tabelle hatte. Ansonsten wurden die entsprechenden Einträge
in der broader-Tabelle bereits angepasst.
9. Verarbeitung 65
finishRelations: In diesem Schritt werden semantische Verwandtheit und Ähnlichkeit zwischen
Konzepten bestimmt und in die Tabelle relation (.C.2) eingetragen. Genauer:
1. Alle Paare von Konzepten, die einen gemeinsamen Language-Link haben (die also
Einträge in der Tabelle langlink (.C.2) haben, die bezüglich der Felder language
und target übereinstimmen), werden im Feld langmatch markiert. Solche Konzepte
werden als ähnlich angesehen, da Language-Links per Konvention immer auf Artikel
mit gleichem oder sehr ähnlichem Gegenstand verweisen (vergleiche .9.2.2 und
WP:INTERLANG). Wie viele Konzepte es gibt, die in diesem Sinne als ähnlich erkannt
werden, hängt stark von der Granularität desWikis ab: in einemWiki mit hoher
Granularität (also vielen spezialisierten Einträgen) ist die Wahrscheinlichkeit hoch,
dass mehrere spezielle Artikel auf denselben, allgemeineren Artikel in einem anderen
Wiki verweisen, wenn das andereWiki eine geringere Granularität hat (siehe .12.3 für
die Evaluation).
Bei der Bestimmung der Ähnlichkeit von globalen, sprachübergreifenden Konzepten
wird zusätzlich das Feld langref verwendet (siehe .9.2.3). Es modelliert die
Ähnlichkeit von Konzepten, die sich gegenseitig direkt über einen Language-Link referenzieren
(siehe .9.2.2). Die so bestimmte Ähnlichkeit von Termen wird in .12.3
evaluiert.
2. Alle Paare von Konzepten, die sich gegenseitig referenzieren (die also jeweils einen
Eintrag in der Tabelle link haben, der auf das andere Konzept verweist), werden im
Feld bilink markiert. Solche Konzepte werden als verwandt angesehen: wenn ein
Konzept für die Erläuterung eines anderen relevant ist und daher in dem entsprechenden
Artikel erwähnt und verlinkt wird, kann das als inhaltliche Assoziation verstanden
werden. Diese Art der Assoziation ist allerdings oft zu allgemein: zum Beispiel wird
in sehr vielen Artikeln auf Maßeinheiten und Jahreszahlen verwiesen, ohne dass ein
inhaltlicher, thematischer Zusammenhang zu den Maßen oder Jahren bestünde — die
Verknüpfungen dienen lediglich der Navigation. Ist die Assoziation aber gegenseitig,
ist also jeweils das eine Konzept relevant für die Erläuterung des anderen, so ist es
wahrscheinlich, dass beide Konzepte zu einem gemeinsamen Thema gehören und eine
(unspezifizierte) semantische Beziehung zueinander haben GREGOROWICZ UND KRAMER
(2006). Die so bestimmte Verwandtheit von Termen wird in .12.4 evaluiert.
Eine weitere interessante Informationsquelle für die Bestimmung von semantischer
Verwandtheit zwischen Konzepten wäre sicherlich die Untersuchung von (signifikanten)
Kookkurrenten bezüglich der Linkstruktur sowie von Ähnlichkeiten der
Kookkurrenzmengen, also der Untersuchung von Kookkurrenten höherer Ordnung
BIEMANN U. A. (2004), MAHN UND BIEMANN (2005). Dieser Möglichkeit wurde im Rahmen
der vorliegenden Arbeit aufgrund des zusätzlichen Aufwands an Programmlogik,
Rechenzeit und Speicherplatz nicht nachgegangen. Im Rahmen des Wortschatzprojektes
QUASTHOFF (1998), WORTSCHATZ hat Matthias Richter Versuche zur Kookkurrenzanalyse der
Verknüpfungsstruktur der deutschsprachigen Wikipedia durchgeführt7.
7Keine Publikation bekannt, eine experimentelle Web-Schnittstelle zu den Ergebnissen befindet sich auf <http:
//wortschatz.uni-leipzig.de/WP/>.
9. Verarbeitung 66
buildTermsForMissingConcepts: In diesem Schritt, der im Gegensatz zu den anderen aus
technischen Gründen in der Klasse ConceptImporter implementiert ist, wird für jedes
Konzept mit dem Typ ConceptType.UNKNOWN (also jedem Konzepteintrag, zu dem
es keinen Artikel gibt) der Titel-Term bestimmt und gespeichert. Genauer wird der
„Basisname“ des Konzeptes bestimmt (.8.9) und dieser dann per LocalConceptStore.
storeReference in die Tabelle link eingetragen.
finishMeanings: In diesem Schritt wird die Bedeutungsrelation zwischen Termen und
Konzepten berechnet. Diese stellt ein Kernstück des Thesaurus dar, das dazu dient,
die Semantic Gap zwischen Text und Inhalt zu überbrücken GREGOROWICZ UND KRAMER
(2006), MIHALCEA (2007), GABRILOVICH UND MARKOVITCH (2006). Die Termzuordnung über die
Bedeutungsrelation wird in .12.5 evaluiert.
Die Bedeutungsrelation wird durch die Tabelle meaning (.C.2) repräsentiert. Diese Tabelle
wird nun befüllt, indem die Einträge in der Tabelle link über die Felder target und term_
text gruppiert und die Einträge pro Gruppe gezählt werden: so wird bestimmt, welcher
Term wie oft als Bezeichnung für welches Konzept verwendet wird.
Dabei wird für jede Bedeutungszuordnung, also für jedes Paar von Werten für target
und term_text, das Gruppen-Maximum des Codes im Feld rule mit in die Tabelle
meaning übernommen. Da der Code für die Regel ExtractionRule.TERM_FROM_
LINK kleiner ist als die Codes der anderen Regeln, lässt sich so bestimmen, ob eine
Bedeutungszuweisung ausschließlich aufgrund von Link-Texten vorgenommen wurde. Der
Hintergrund ist, dass explizite Zuordnungen von Termen zu Konzepten, wie sie durch
Seitentitel, Weiterleitungen, Begriffsklärungen etc. definiert werden, zuverlässiger sind als
solche, die ausschließlich auf Link-Texten beruhen (.12.5). Es kann also nützlich sein, für
Bedeutungszuordnungen, die nur auf Link-Texten beruhen, zusätzliche Bedingungen zu definieren,
zum Beispiel eine Mindestfrequenz von zwei oder drei Wiederholungen (.10.4).
finishFinish: Dies ist der letzte Schritt der Nachbereitung, er dient dazu, letzte Inkonsistenzen
zu beseitigen. Er besteht aus den folgenden Operationen:
1. Entfernen aller Schleifen aus der Verknüpfungsrelation, also alle Einträge aus der
Tabelle link, deren anchor- und target-Felder denselben Wert haben.
2. Entfernen aller Schleifen aus der Subsumtionsrelation, also alle Einträge aus der
Tabelle broader, deren broad- und narrow-Felder denselben Wert haben.
3. Entfernen aller Zyklen aus dem Graphen, der durch die Subsumtionsrelation definiert
ist. Hierfür wird der in Anhang E.5 beschriebene Algorithmus verwendet. Dies
ist notwendig, da die Kategoriestruktur der Wikipedia zwar per Konvention ein zusammenhängender,
azyklischer Graph ist WP:KAT, die MediaWiki Software diese
Eigenschaften aber nicht erzwingt, Zyklen in der Struktur also durchaus auftreten können
HAMMW¨OHNER (2007). Die Semantik der Subsumtionsrelation verlangt aber, dass sie
eine Halbordnung bildet und somit azyklisch sein muss.
Das Ergebnis der Nachbereitung ist ein vollständiger lokaler Datensatz, der einen monolingualen
Thesaurus repräsentiert. Die Konzepte und Relationen in diesem Thesaurus werden in .12 evalu9.
Verarbeitung 67
iert. Der nächste Abschnitt beschreibt, wie die lokalen Datensätze für unterschiedliche Sprachen
zu einem multilingualen Thesaurus zusammengefasst werden können.
9.2. Zusammenführen des multilingualen Thesaurus
Das Zusammenführen der einzelnen lokalen Datensätze zu einem globalen Datensatz ist die
Aufgabe des Programms BuildThesaurus. Die einzelnen Schritte der Zusammenführung sind
in DatabaseGlobalConceptStoreBuilder implementiert und werden im Folgenden näher erläutert.
Zur schnelleren Verarbeitung in globalen Datensätzen wird jedem lokalen Datensatz (bzw. jeder
Sprache) eine Zahl zwischen 1 und 32 zugewiesen (mehr als 32 Sprachen können nicht zusammengefasst
werden). Entsprechend diesem Code ist jeder Sprache auch eine Bit-Maske zugeordnet, in
der genau das Bit mit dieser Nummer gesetzt ist - die Sprache mit dem Code 1 hätte also Maske
1, die Sprache mit dem Code 2 hätte die Maske 2, die Sprache mit dem Code 3 hätte die Maske
4, die Sprache mit dem Code 4 hätte die Maske 8 und so weiter — dieser Wert wird in dem Feld
language_bits in der Tabelle concept gespeichert (.C.2).
9.2.1. Import der Konzepte
Zunächst müssen die Basisdaten aus den lokalen Datensätzen in das globale Datenmodell übernommen
werden, damit sie gemeinsam betrachtet und verarbeitet werden können. Dabei wird
zunächst jedes lokale Konzept aus jedem lokalen Datensatz als eigener globaler Konzepteintrag
in den globalen Datensatz aufgenommen. Dazu werden für jeden lokalen Datensatz die folgenden
Schritte ausgeführt, die direkt auf der Datenbank implementiert sind:
importOrigins: In diesem Schritt wird für jedes Konzept aus dem lokalen Datensatz in der
Tabelle origin (.C.2) des globalen Datensatzes ein Eintrag angelegt. Dieser Eintrag weist
dem Konzept aus dem lokalen Datensatz eine ID zu, die für einen Eintrag in der Tabelle
concept des globalen Datensatzes verwendet wird. Die Tabelle origin assoziiert also ein
Paar aus Sprachcode und lokaler ID mit der ID eines globalen Konzepteintrags — diese
Abbildung wird im Folgenden immer dann benutzt, wenn zwischen dem lokalen und dem
globalen Datensatz eine Verbindung hergestellt werden muss.
importConcepts: In diesem Schritt werden die globalen Konzepteinträge für die Tabelle
concept erzeugt (.C.2). Dafür wird die in der Tabelle origin definierte globale Konzept-
ID verwendet, der Konzepttyp (.8.6) wird aus dem lokalen Datensatz übernommen, wie
auch der Name des Konzeptes, dem allerdings noch der Sprachcode vorangestellt wird,
um ihn eindeutig zu machen. Dabei ist zu beachten, dass der Name der globalen Konzepte
keinerlei Bedeutung für die Verarbeitung oder Interpretation hat — er wird lediglich zur
Kontrolle mitgeführt.
9. Verarbeitung 68
importLanglinks: Um die Language-Links der Konzepte aus verschiedenen lokalen
Datensätzen vergleichen zu können, werden sie in diesem Schritt in die Tabelle langlink
des globalen Datensatzes übernommen (.C.2). Die IDs der lokalen Konzepte werden dabei
über die origin in die IDs der globalen Konzepteinträge umgewandelt.
Die in den globalen Datensätzen importierten Language-Links verweisen nun zum Teil auf
Konzepte, die ebenfalls in den globalen Datensatz aufgenommen wurden. Um diese Zuordnung
korrekt auswerten zu können, müssen aber auch auf dieser Relation Aliase ausgewertet werden.
Für jeden lokalen Datensatz werden deshalb die folgenden Schritte ausgeführt:
resolveLanglinkAliases: In der Tabelle langlink (.C.2) werden für diejenigen Einträge,
deren target-Feld zu dem Sprachcode des gerade betrachteten lokalen Datensatzes
passt, die Werte in der Spalte target anhand der Tabelle alias (.C.2) aus diesem
lokalen Datensatz angepasst. Zum Beispiel wird während der Verarbeitung der
Daten für den en-Datensatz (also des englischsprachigen Thesaurus) der Language-Link
von DE:3-SAT auf EN:3-SAT angepasst und auf EN:BOOLEAN_SATISFIABILITY_PROBLEM geändert,
da in der englischsprachigen Wikipedia die Seite 3-SAT eine Weiterleitung auf
Boolean_satisfiability_problem ist.
deleteAliasedLanglinks: In diesem Schritt werden aus der Tabelle langlink sämtliche
Einträge entfernt, die noch auf ein Konzept verweisen, das in der Tabelle alias als Alias
vermerkt ist. Damit werden doppelte Weiterleitungen ignoriert.
9.2.2. Aufbau der sprachübergreifenden Konzepte
Ein Hauptgegenstand dieser Arbeit sowie eine der Kernaufgaben von WikiWord ist der Aufbau
von sprachunabhängigen Konzepten. Praktisch besteht die Aufgabe darin, Gruppen von äquivalenten
Konzepten aus unterschiedlichen Sprachen zu identifizieren und zu einem sprachunabhängigen
Konzept zusammenzuführen. Die folgenden Postulate bilden dabei die Grundlage für den
Vereinigungsalgorithmus:
1. Die Language-Links in einem Artikel verweisen auf Artikel in einer anderen Sprache, die
dasselbe oder zumindest ein ähnliches Konzept zum Gegenstand haben WP:INTERLANG.
Wenn zwei Artikel per Language-Link auf denselben dritten Artikel verweisen, so beschreiben
daher auch diese beiden Artikel ein ähnliches, oder das gleiche Konzept. Konzepte, die
aus diesen Gründen als ähnlich gelten können, sollten im Thesaurus auch durch eine entsprechende
Relation miteinander verknüpft sein. Die Qualität von Language-Links wurde
in HAMMW¨OHNER (2007B) näher untersucht.
2. Pro Sprache kann es in einem Artikel nur einen (ausgehenden) Language-Link geben8.
Umgekehrt jedoch können mehrere Artikel aus einer Sprache auf denselben Artikel in einer
8Per Konvention. Diese Einschränkung wird von MediaWiki nicht erzwungen, jedoch werden mehrere Language-
Links für dieselbe Sprache auf einer Seite nicht korrekt unterstützt.
9. Verarbeitung 69
anderen Sprache verweisen, es kann also pro Artikel mehrere eingehende Language-Links
pro Sprache geben. Das ist besonders dann häufig der Fall, wenn die beiden Wikipedias in
dem betreffenden Bereich sehr unterschiedliche Granularität besitzen, meist bedingt durch
die Gesamtgröße der Wikipedia in der jeweiligen Sprache.
3. Referenzieren sich zwei Artikel aus unterschiedlichen Sprachen gegenseitig über Language-
Links, so beschreiben sie dasselbe Konzept, oder zumindest eines, das in Bezug auf die Ziele
dieser Arbeit hinreichend ähnlich ist, um als äquivalent angesehen zu werden. Diese beiden
Artikel sollten also nach Möglichkeit demselben sprachunabhängigen Konzept zugewiesen
werden.
Dieses Postulat ist die Hauptvoraussetzung für die Effektivität des vorgeschlagenen
Algorithmus. Es ist analog zu der in .9.1.3 genutzten Annahme, dass zwei Artikel, die sich
gegenseitig referenzieren, verwandte Konzepte beschreiben, wie von GREGOROWICZ UND KRAMER
(2006) vorgeschlagen.
4. Es gibt pro Sprache nur einen Artikel für jedes Konzept9 — zwei Artikel aus derselben
Wikipedia sollten also niemals demselben sprachunabhängigen Konzept zugewiesen werden.
5. Sollten zwei Artikel derselben Sprache aufgrund der gegenseitigen Verknüpfung mit
Artikeln in anderen Sprachen als äquivalent gelten, so wird diese Situation als Konflikt
bezeichnet (siehe Evaluation in .11.3) — diese Situation kann dann auftreten, wenn die
folgende Verweisstruktur von Language-Links besteht: A1 $ B $ C $ A2. Dann stehen
A1 und A2 in Konflikt zueinander: sie können als sehr ähnlich gelten, dürfen aber nicht
demselben sprachunabhängigen Konzept zugewiesen werden.
6. Sprachunabhängige Konzepte werden als eine Menge von sprachspezifischen Konzepten
modelliert, die so ausgewählt sind, dass sie sich untereinander möglichst ähnlich, idealerweise
äquivalent sind; jedes sprachunabhängige Konzept enthält aus jeder Sprache höchstens
ein sprachspezifisches Konzept. Die Eigenschaften und Beziehungen der sprachunabhängigen,
globalen Konzepte ergeben sich aus der Vereinigung der Eigenschaften und
Beziehungen der sprachspezifischen Konzepte.
Vor dem eigentlichen Zusammenführen von Konzepten müssen zunächst Paare von ähnlichen
Konzepten aus unterschiedlichen Sprachen identifiziert werden. Die Methode
prepareGlobalConcepts füllt dazu die Tabelle relation (.C.2) in den folgenden zwei
Schritten:
buildLangMatch: In die Spalte langmatch der Tabelle relation wird für Paare von
Konzepten, die gemeinsame Language-Links haben, ein Eintrag eingefügt. Diese (schwache)
Art von Ähnlichkeit wird zwar für den fertigen Thesaurus, nicht jedoch für das
Vereinigen von Konzepten verwendet.
9Wieder per Konvention WP:RED. Es kommt vor, dass zwei Seiten zum selben Thema angelegt werden, das wird
aber innerhalb der Wikipedia als zu behebender Fehler angesehen und ist selten genug, um für die Zwecke dieser
Arbeit nicht ins Gewicht zu fallen.
9. Verarbeitung 70
buildLangRef: In die Spalte langref der Tabelle relation wird für Paare von Konzepten ein
Eintrag eingefügt, wenn das eine Konzept über einen Language-Link direkt auf das andere
verweist. Ist diese Beziehung gegenseitig, existiert also ein Eintrag dieser Art sowohl für
das Paar (A, B) wie auch für das Paar (B, A), so wird, wie oben erklärt, davon ausgegangen,
dass diese Artikel dasselbe Konzept beschreiben. Diese Information wird dann für das
Zusammenfassen von lokalen zu sprachunabhängigen Konzepten verwendet.
Der Aufbau der sprachübergreifenden Konzepte geschieht dann dadurch, dass Paare von
Konzepten, die sich gegenseitig über Language-Links referenzieren aber keine Überlappung in den
Sprachen haben, die sie bereits abdecken, sukzessive vereinigt werden, so lange, bis es kein solches
Paar mehr gibt. Dieser Algorithmus ist in Anhang E.4 detailliert beschrieben, die Ergebnisse
werden in .11.3 analysiert.
Zum Vergleich wäre es interessant, alternative Algorithmen für das Finden und Zusammenfassen
von „äquivalenten“ Konzepten zu erproben. Eine mögliche Alternative zur Nutzung von gegenseitigen
Language-Links, wie sie oben beschrieben ist, wäre es, die Language-Links eines Artikels
als Featurevektor zu betrachten SALTON U. A. (1975). Die Idee dabei ist, kontinuierlich diejenigen
Konzeptgruppen miteinander zu vereinigen, die die meisten Language-Links gemeinsam haben,
aber sich bezüglich der von ihnen abgedeckten Sprachen nicht überlappen. Der Algorithmus wäre
also ähnlich wie der oben vorgestellte, nur dass statt gegenseitiger Referenzierung über Language-
Links die Ähnlichkeit bezüglich des durch die Language-Links definierten Featurevektoren entscheidend
wäre. Dieser Ansatz konnte hier jedoch aufgrund seiner höheren Komplexität und des
größeren Rechenaufwands nicht umgesetzt werden. Seine Implementation und Untersuchung verbleibt
als Gegenstand zukünftiger Forschung.
9.2.3. Nachbereitung
Nachdem die Konzepte in das globale Datenmodell importiert und zusammengeführt wurden,
verbleibt noch die Aufgabe, die verschiedenen Beziehungen aus den einzelnen lokalen
Datensätzen ebenfalls in den globalen Datensatz zu überführen und zu konsolidieren. Die Methode
finishGlobalConcepts importiert zunächst aus jedem lokalen Datensatz die verbleibenden relevanten
Relationen, im Einzelnen:
1. Die Tabelle link wird unter Verwendung der ID-Abbildung in der Tabelle origin aus dem
lokalen Datensatz in den globalen Datensatz kopiert. Dabei wird lediglich die Information
übernommen, welches Konzept auf welches verweist, nicht aber der Link-Text, da dieser ja
sprachspezifisch ist.
2. Ebenso unter Verwendung der Tabelle origin wird die Tabelle broader, also die
Subsumtionsrelation, übernommen. Zyklen, die eventuell durch die Vereinigung mit den
Subsumtionsrelationen aus anderen lokalen Datensätzen entstehen, werden im nächsten
Schritt aufgelöst.
Auf diese Weise werden die verschiedenen Beziehungen aus den einzelnen lokalen
Datensätzen zusammengeführt. Nachdem alle Relationen so importiert wurden, führt
finishGlobalConcepts schließlich die folgenden Schritte aus:
9. Verarbeitung 71
1. Entfernen aller Schleifen aus der Verknüpfungsrelation, also alle Einträge aus der Tabelle
link (.C.2), deren anchor- und target-Felder denselben Wert haben.
2. Entfernen aller Schleifen aus der Subsumtionsrelation, also alle Einträge aus der Tabelle
broader (.C.2), deren broad- und narrow-Felder denselben Wert haben.
3. Entfernen aller Zyklen aus dem Graphen, der durch die Subsumtionsrelation definiert ist.
Hierfür wird der in Anhang E.5 beschriebene Algorithmus verwendet. Es ist notwendig,
dies nach dem Zusammenführen der Subsumtionen aus den einzelnen lokalen Datensätzen
noch einmal zu tun, da dabei ja wieder Zyklen entstanden sein können.
In HAMMW¨OHNER (2007B) wird vorgeschlagen, die Kategoriestruktur verschiedenerWikipedias
zu vergleichen und auf diese Weise Fehler in den Kategorisierungsstrukturen zu erkennen
und zu beseitigen. Ein entsprechendes Verfahren könnte an dieser Stelle ohne weiteres eingefügt
werden, diese Möglichkeit weiter zu untersuchen, geht jedoch über den Rahmen
dieser Arbeit hinaus und bietet sich als Gegenstand künftiger Forschung an.
4. Wie schon zuvor für die einzelnen lokalen Datensätze, wird nun die Verwandtheit von
Konzepten bestimmt: Alle Paare von Konzepten, die sich gegenseitig referenzieren (die also
jeweils einen Eintrag in der Tabelle link haben, der auf das andere Konzept verweist),
werden im Feld bilink der Tabelle relation (.C.2) markiert.
5. Die Spalte langref in der Tabelle relation wurde bereits in .9.2.2 für Konzepte befüllt,
die sich über einen Eintrag in der Tabelle langlink (.C.2) referenzieren. In diesem Schritt
wird diese bislang asymmetrische Beziehung nun symmetrisch ergänzt: für jeden Eintrag
mit langre f (A, B) > 0 wird langre f (B, A) B langre f (B, A) + langre f (A, B) gesetzt. Dabei
ergibt sich genau für jene Paare, die sich gegenseitig referenzieren, einWert > 1—das sind
genau solche Paare, deren Konzepte sich sehr ähnlich sind, die aber nicht verschmolzen
wurden, weil sie zueinander in Konflikt stehen (siehe .9.2.2). Für Paare mit langre f (A, B) =
1 wird eine einfache Ähnlichkeit angenommen (.11.3).
9.3. Aufbau der statistischen Daten
Das Programm BuildStatistics dient dazu, statistische Daten über einen (lokalen oder
globalen) Datensatz zu erstellen. Insbesondere werden dabei die Verteilungen der Knotengrade
im Term-Konzept-Graphen berechnet. Die Routinen zur Berechnung dieser Werte sind in
DatabaseLocalConceptStoreBuilder.DatabaseLocalStatisticsStoreBuilder bzw.
DatabaseGlobalConceptStoreBuilder.DatabaseGlobalStatisticsStoreBuilder
in der Methode buildStatistics implementiert. Diese Statistiken sind einerseits für die
Evaluation von WikiWord nützlich, andererseits dienen sie aber auch der Gewichtung der
Konzepte nach verschiedenen Kriterien für unterschiedliche Aufgaben. Im Einzelnen werden die
folgenden Statistiken erstellt:
indegree, der Knotengrad bezüglich eingehender Verweise, wird aus der Tabelle link (.C.2) bestimmt
und im Feld in_degree der Tabelle degree (.C.2) gespeichert; der Rang bezüglich
dieses Wertes wird im Feld in_rank abgelegt.
9. Verarbeitung 72
outdegree, der Knotengrad bezüglich ausgehender Verweise, wird aus der Tabelle link bestimmt
und im Feld out_degree der Tabelle degree gespeichert; der Rang bezüglich dieses
Wertes wird im Feld out_rank abgelegt.
linkdegree, der Knotengrad bezüglich der Summe von eingehenden und ausgehenden
Verweisen, wird aus der Tabelle link bestimmt und im Feld link_degree der Tabelle
degree gespeichert; der Rang bezüglich dieses Wertes wird im Feld link_rank abgelegt.
idf ist die Inverse Document Frequency bezüglich der Anzahl der Konzepte, die über die Tabelle
link auf ein gegebenes Konzept verweisen. Dieser Wert ist, angelehnt an SALTON UND MCGILL
(1986), definiert als
id f (ci) = log |C|
indegree(ci) !
Der IDF-Wert dient zur Abschätzung der Selektivität eines Konzeptes: Konzepte mit einem
hohen IDF-Wert sind stark selektiv, also eher spezialisiert, während Konzepte mit niedrigem
IDF-Wert eher allgemeiner Natur sind. Die Verknüpfung eines Konzeptes mit einem anderen
stark selektiven Konzept sagt also mehr über die thematische Zusammengehörigkeit der
Konzepte aus, als eine Verknüpfung mit einem schwach selektiven Konzept. Der Rang jedes
Konzeptes bezüglich seines IDF-Wertes wird in der Spalte idf_rank abgelegt.
lhs ist der Local Hierarchy Score nach MUCHNIK U. A. (2007) bezüglich eingehender und ausgehender
Verweise, wie sie durch die Tabelle link definiert sind. Dieser Wert ist definiert als
lhs(ci) =
indegree(ci) · pindegree(ci)
indegree(ci) + outdegree(ci)
Dabei wird die von MUCHNIK U. A. (2007) vorgeschlagene symmetrische Ergänzung nicht verwendet,
da diese eine Anpassung für ungerichtete Graphen darstellt. Der LHS-Wert dient zur
Abschätzung der Zentralität eines Konzeptes, also des Grades, zu dem es zur Konnektivität
des gesamten Verweisnetzwerkes beiträgt, soweit sich das lokal bestimmen lässt: Konzepte
mit einem hohen LHS-Wert sind eher allgemeiner Natur, sie eignen sich zur Kategorisierung
bzw. als Zentren thematischer Cluster. Der Rang jedes Konzeptes bezüglich seines LHSWertes
wird in der Spalte lhs_rank abgelegt.
freq, die Termfrequenz für die einzelnen Terme, wird aus der Tabelle link bestimmt und im Feld
freq der Tabelle term gespeichert; der Rang bezüglich dieses Wertes wird im Feld rank
abgelegt. Der Rang eines Terms kann auch als eine eindeutige ID für diesen Term verwendet
werden (vergleiche HEYER U. A. (2006), S. 59).
Für die Knotengrade sowie die Termfrequenzen wird eine Verteilung gemäß dem Zipfschen
Gesetz ZIPF (1935) erwartet (und in .11.4 bzw. .11.5 auch bestätigt). In Hinblick darauf werden in
der Methode DatabaseWikiWordConceptStoreBuilder.buildDistributionStats für jede
dieser Verteilungen die folgenden Werte erhoben und in der Tabelle stats (.C.2) abgelegt:
9. Verarbeitung 73
total distinct types: Die Anzahl der „Typen“, also unterschiedlicher Terme (für die Verteilung
der Termfrequenzen) bzw. Konzepte (für die Verteilung der Knotengrade), auf die sich die
Verteilung bezieht, im Folgenden t.
total token occurrences: Die Anzahl der „Tokens“ N, also die Summe der Verwendungen bzw.
Referenzen V der einzelnen Terme bzw. Konzepte xi:
N =Xi
V(xi)
average type value: Die durchschnittliche Anzahl der Verwendungen jedes Typs (also jedes
Terms bzw. Konzeptes) —v:
—v =
N
t
average type value x rank: Der durchschnittliche Wert des Rang-Wert-Produkts, k: Sei R(x)
der Rang des Typs x, und V(x) die Anzahl der Verwendungen von x, so ist dieser Wert
gegeben durch
k = Pi R(xi) · V(xi)
t
Nach dem Zipfschen Gesetz wird nun erwartet, dass für alle xi gilt:
R(xi) · V(xi)  k
characteristic fitting: Die normierte durchschnittliche Anzahl der Verwendungen jedes Typs:
c =
k
N = Pi R(xi) · V(xi)
t · N
Dieser Wert ist der charakteristische Anpassungskoeffizient des Korpus.
deviation from char. fit.: Die Standardabweichung des Rang-Wert-Produktes:
dk = vtPi c - R(xi)·V(xi)
N 2
t = sPi (k - R(xi) · V(xi))2
t · N2
Dieser Wert gibt Auskunft darüber, wie genau die Verteilung dem Zipfschen Gesetz folgt.
Die einzelnen Verteilungen und ihre statistischen Eigenschaften für konkrete Daten werden in
.11.4 und .11.5 diskutiert.
9. Verarbeitung 74
9.4. Vorbereitung von Konzeptdaten für den schnellen Zugriff
Das Programm BuildConceptInfo bereitet Konzeptdaten für einen schnellen Zugriff vor. Der
Hintergrund ist, dass zu den Informationen, die für die Konzepte im Thesaurus relevant sind, vor
allem ihre Relationen zu anderen Konzepten und zu Termen gehören. Diese Informationen manifestieren
sich in Form von Listen, zum Beispiel in den Listen aller übergeordneter oder aller ähnlicher
Konzepte. Bei einer rein relationalen Speicherung der Beziehungen zwischen den Konzepten
ist für jede derartige Liste für jedes Konzept eine eigene Datenbankabfrage notwendig — das ist
sehr aufwändig, besonders wenn diese Eigenschaften für mehr als ein Konzept abgefragt werden
sollen.
Die Lösung für dieses Problem besteht darin, diese Listen im Vorhinein für jedes Konzept
zu berechnen und serialisiert als einzelne Werte in der Datenbank abzulegen (als „Property
Cache“). Gespeichert werden diese vorausberechneten Listen in den Tabellen concept_info und
concept_description (siehe .C.2 und .C.2). Die Berechnung ist implementiert in den Klassen
DatabaseLocalConceptStoreBuilder.DatabaseLocalConceptInfoStoreBuilder bzw.
DatabaseGlobalConceptStoreBuilder.DatabaseGlobalConceptInfoStoreBuilder in
der Methode buildConceptInfo.
Die jeweilige Liste von Konzepten oder Termen hat für jeden Eintrag mehrere Werte, die bei der
Serialisierung berücksichtigt werden müssen: Möglich sind ID, Name, Frequenz und Relevanz
— für jede Eigenschaft ist im Voraus bekannt, welche dieser Werte verwendet werden. Zu serialisieren
ist also eine Folge von Wert-Tupeln. Dazu werden die Werte (Felder) jedes Tupels unter
Verwendung eines Trennzeichens konkateniert und alle Tupel werden ihrerseits unter Verwendung
eines anderen Trennzeichens konkateniert. Zahlenwerte werden in Dezimaldarstellung repräsentiert.
Das Trennzeichen für die Werte eines Tupels ist das „Unit Separator“-Zeichen des
ASCII-Standards ISO:646 (1991) (Hex-Code 1F), es ist in ConceptInfoStoreSchema.
referenceFieldSeparator definiert und kann über den Tweak-Wert dbstore.
cacheReferenceFieldSeparator konfiguriert werden (siehe .B.5). Analog ist das
Trennzeichen für die Tupel untereinander das „Record Separator“-Zeichen des ASCII-Standards
(Hex-Code 1E), es ist in ConceptInfoStoreSchema.referenceSeparator definiert und kann
über den Tweak-Wert dbstore.cacheReferenceSeparator konfiguriert werden. DesWeiteren
ist die Gesamtlänge der serialisierten Daten pro Feld beschränkt — die Maximallänge kann über
den Tweak-Wert dbstore.listBlobSize angepasst werden und liegt per Default bei 65025
Bytes.
Die vorberechneten Relationen sind die Basis für die Klassen GlobalConcept und
LocalConcept für Transferobjekte (siehe .D.2). Jeder Eintrag in einer solchen Liste
wird typischerweise durch ein Transferobjekt vom Typ GlobalConceptReference,
GlobalConceptReference bzw. TermReference repräsentiert. Die Deserialisierung ist
entsprechend in WikiWordReference.parseList implementiert.
10. Export
Um die von WikiWord gewonnenen Informationen für andere Systeme verfügbar zu machen,
müssen sie in ein standardisiertes Modell überführt und in einem wohlbekannten Datenformat
repräsentiert werden. In Hinblick auf die Kompatibilität mit einer möglichst großen Zahl von
existierenden Systemen wurde RDF (Resource Description Framework, W3C:RDF (2004)) als
die Basis des Datenmodells gewählt. RDF ist eine Empfehlung des W3C, die als flexibles
Modell zur Datenrepräsentation im Semantic Web entworfen wurde. RDF ist weit verbreitet für
die Darstellung von Faktenwissen in Wissensorganisationssystemen (Knowledge Organisation
Systems, KOS) wie Thesauri, Taxonomien, Ontologien und ähnlichem, unter anderem auch im
Bereich Information Retrieval und Automatische Sprachverarbeitung (siehe zum Beispiel AUER
U. A. (2007) und GREGOROWICZ UND KRAMER (2006), vergleiche auch VAN ASSEM U. A. (2006)).
Das Datenmodell, das RDF zugrunde liegt, basiert auf sogenannten Aussagen (Statements), die
als Tripel von Subjekt, Prädikat und Objekt dargestellt werden. Subjekte und Prädikate sind
Ressourcen, die eindeutig durch eine URI identifiziert sind. Das Objekt kann entweder auch eine
solche Ressource sein, oder ein Literal, also ein atomarer Wert. Literalen kann, zusätzlich zu ihrem
textuellenWert, eine Sprache zugeordnet sein, so dass im Kontext unterschiedlicher Sprachen
verschiedene Werte gewählt werden können. Des weiteren kann ihnen ein Datentyp zugewiesen
sein, der seinerseits eine (durch eine URI identifizierte) RDF-Ressource ist — auf diese Weise
lässt sich angeben, wie das Literal zu interpretieren ist, zum Beispiel als Text (String), als Zahl,
als Datumsangabe, usw.
Fest definierte RDF-Ressourcen, die in einem logischen Zusammenhang stehen, bilden zusammen
ein sogenanntes Vokabular. Typischerweise definiert ein Vokabular Prädikate und Klassen
zur Beschreibung bestimmter Arten (Domänen) von Objekten und ihrer Beziehungen. Die URIs
der Ressourcen eines Vokabulars haben meist einen gemeinsamen Präfix—um diesen nicht ständig
wiederholen zu müssen, kann er, nach vorheriger Festlegung, durch eine Abkürzung ersetzt
werden; so entsteht aus der URI ein sogenannter QName (also ein qualifizierter Name), was in
etwa der Verwendung von Namensräumen in XML entspricht W3C:XML (2006), W3C:N3 (2006).
Zum Beispiel kann so die URI http://www.w3.org/1999/02/22-rdf-syntax-ns#type als
rdf:type geschrieben werden — rdf:type ist ein in RDF vordefiniertes Prädikat, das einer
Ressource einen Typ zuweist, also aussagt, dass das Subjekt eine Instanz derjenigen Klasse ist, die
von dem Objekt der Aussage repräsentiert wird.
Für RDF sind verschiedene Datenformate (Serialisierungen) definiert, insbesondere N3 (Notation
3 W3C:N3 (2006), mit den Varianten Turtle BACKETT (2007) und N-Triples W3C:NTRIPLES (2004)) sowie
RDF/XML W3C:RDF/XML (2004). WikiWord verwendet per Default Turtle für die Ausgabe
von RDF. Für die Konvertierung zwischen diesen Repräsentationen steht eine Vielzahl von
Werkzeugen zur Verfügung, zum Beispiel rapper aus der Redland-Bibliothek von Dave Beckett1.
Im Folgenden wird erläutert, wieWikiWord-Datensätze auf das Datenmodell von RDF abgebildet
werden können. Das Vorgehen folgt dabei im Wesentlichen W3C (2005) und orientiert sich weiter
an GREGOROWICZ UND KRAMER (2006) sowie VAN ASSEM U. A. (2006).
1<http://librdf.org/>, Versionen vor 1.4.17 haben unter Umständen Probleme mit bestimmten Escape-
Sequenzen in URIs