\chapter{Verarbeitung}
\label{ch:import}\label{ch:verarbeitung}

Im Kapitel \nr{ch:framework} (\rr{ch:framework}) wurde erklärt, wie WikiWord aufgebaut ist und wie der Import-Prozess als Ganzes abläuft, in \nr{ch:analyse} (\rr{ch:analyse}) 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. 

\section{Import von Wiki-Seiten}
\label{transform:import} \label{sec:ImportConcepts}
\label{sec:import-aus-wikitext}

Der Import von Wiki-Seiten in den lokalen Datensatz (das \nom{Konzeptmodell}) wird von der Methode \javaid{handlePage} in der Klasse \javaid{ConceptImporter} gesteuert: sie initiiert die Umwandlung der Wiki-Textes in ein Ressourcenobjekt vom Typ \javaid{WikiPage}  (siehe \rr{entwurf:analyse} \bzw \rr{transform:analyse} und \rr{model:ressourcenmodell}) 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 \javaid{LocalConceptStoreBuilder} modelliert wird (siehe \rr{sec:LocalConceptStoreBuilder}). 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 \zB \rr{sec:link-table} und \rr{sec:broader-table}): 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. \label{p:extraction-rules}Die Regeln sind in der Enumeration \javaid{ExtractionRule} definiert; sie werden in diesem Kapitel an den betreffenden Stellen genannt.

Bei der Interpretation der Ressourceneigenschaften werden unter anderem die folgenden Aspekte betrachtet:

\begin{description}
  \item[Kategorisierung:] \label{p:import:kategorisierung}Von den Wiki-Links der Seite (\rr{sec:analyzer:links}) werden diejenigen betrachtet, deren \javaid{magic} Property den Wert \javaid{LinkMagic.CATEGORY} hat (\rr{sec:analyzer:links}, \rr{sec:wikitext:links}). 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 \q{WP:KAT} sowie die in \rr{sec:stand:thesaurus} vorgestellten Arbeiten, insbesondere \qqq{Voss2006tt}{Ponzetto2007tax}{GregorowiczKramer2006}). Für jeden dieser Links wird die Methode \javaid{LocalConceptStore.storeConceptBroader} aufgerufen (\rr{sec:LocalConceptStoreBuilder}), um diese Zuordnung im lokalen Datenmodell festzuhalten (Regel \javaid{ExtractionRule.BROADER_FROM_CAT}).
  
  Die Zuordnung von übergeordneten Konzepten wird unter Umständen im Nachbereitungsschritt noch überarbeitet (\rr{transform:import-finish}), insbesondere werden Kategorisierungs-Aliase aufgelöst (siehe \rr{sec:cat-alias}).
  
  
  Ein Problem, das bei der Interpretation der Kategoriestruktur von Wikipedia auftreten kann, sind so genannte \nom{Wartungskategorien}, die sich nicht auf den Inhalt (das Konzept) der Seite beziehen, sondern auf die Seite selbst --- zum Beispiel die Kategorie \wikipage{Kategorie:Wikipedia:Lückenhaft} \q{Voss2006tt}. 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, tauchen Wartungskategorien in den von WikiWord gefundenen Wiki-Links gar nicht auf.

  \label{p:navigationskategorien}Eine weitere Art von Kategorie, die für einen Thesaurus von zweifelhaftem Wert sind, sind \nom{Navigationskategorien} \qq{GregorowiczKramer2006}{Hammwoener2007Prem}. Das sind häufig sogenannte \nom{Schnittmengenkategorien}, die solche Artikel enthalten, denen zwei Eigenschaften gemein sind, zum Beispiel \wikipage{Kategorie:Fluss\_in\_Bayern} oder \wikipage{Kategorie:Politiker\_(19.\_Jahrhundert)}. Oder es handelt sich um \nom{Metakategorien}, die Kategorien mit ähnlicher Struktur zusammenfassen, zum Beispiel \wikipage{Kategorie:Fluss\_nach\_Staat} oder \wikipage{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 der Wikipedia soll zwar per Konvention (\nospell{poly-})hierarchisch sein, diese Anforderung wird aber von MediaWiki nicht geprüft. So kann die Struktur insbesondere auch Zyklen enthalten \q{Hammwoener2007Prem}. Diese werden von WikiWord während der Nachbereitung entfernt (\rr{p:finish-finish}).
  
  \item[Link-Text Terme:] \label{p:import:link-text}Es werden alle Wiki-Links der Seite betrachtet (\rr{sec:analyzer:links}) und für jeden Link per \javaid{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 \rr{sec:analyzer:terme}). 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 \qq{WP:V}{Mihalcea2007} sowie \qqq{craswell:esf}{Eiron2003at}{Kraft2004at}): zum Beispiel würde \wikitext{[[Vereinigte Staaten|USA]]} dafür sorgen, dass der Term \wwterm{USA} dem Konzept \wwconcept{Vereinigte\_Staaten} zugeordnet wird. Diese Extraktionsregel wird mit \javaid{ExtractionRule.TERM_FROM_LINK} identifiziert. 
  
  Links, deren \javaid{magic}-Property nicht \javaid{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 \javaid{ResourceType.ARTICLE} handele. Im Nachbereitungsschritt (\rr{transform:import-finish}) werden dann Links auf Weiterleitungsseiten aufgelöst (\javaid{DatabaseLocalConceptStoreBuilder.finishAliases}), sowie alle Links auf andere Typen von Ressourcen, insbesondere auf Begriffsklärungen und als "`schlecht"' markierte Seiten, entfernt (\javaid{DatabaseLocalConceptStoreBuilder.finishBadLinks}). 

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 \rr{sec:stand:disambig}): Querverweise zwischen Artikeln werden mit der Methode \javaid{LocalConceptStore.storeLink} gespeichert, die sowohl die Bedeutungszuweisung als auch die Assoziation von Konzepten berücksichtigt (vergleiche \rr{sec:link-table}). Diese Information wird später vor allem zur Bestimmung der semantischen Verwandtheit verwendet (\rr{p:finish-relations}).

  \item[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 \javaid{WikiPage.getPageTerms} (siehe \rr{sec:analyzer:terme}), Termzuordnungen auf dieser Basis werden mit \javaid{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 \javaid{WikiPage.getPageTerms} zusätzlich Terme, die mit Hilfe des \lingo{Magic Words} \wikitext{DISPLAYTITLE} angegeben wurden (\rr{sec:wikitext:magicwords}). 
\end{description}

Während der Verarbeitung werden die Konzeptnamen, Terme und Definitionstexte (Glossen) \lingo{Sanity Checks} unterzogen, um zu verhindern, dass fehlerhafte Daten in den Thesaurus aufgenommen werden. Im Einzelnen werden geprüft:
\begin{enumerate}
  \item Die Länge von Konzeptnamen und Ressourcennamen. Sie muss zwischen den Werten liegen, die durch \javaid{WikiConfiguration.minNameLength} und \javaid{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. \javaid{DatabaseLocalStoreBuilder} verlangt zusätzlich, dass Namen in UTF-8-kodierter Form \qs{UNICODE}{103} nicht länger als 255 Byte sein dürfen, sonst werden sie abgeschnitten\footnote{Dabei 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.}. Diese Beschränkung ergibt sich aus den technischen Vorgaben der Datenbankstruktur (\rr{sec:datenbankstruktur}).
  \item Die Länge von Termen. Es gelten dieselben Beschränkungen wie für Konzeptnamen, nur dass gegen die Werte von \javaid{WikiConfiguration.minTermLength} und \javaid{WikiConfiguration.maxTermLength} geprüft wird. Auch die Begrenzung auf maximal 255 Byte effektive Länge gilt für Terme.
  \item Die Länge von Definitionstexten. \javaid{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.
  \item Terme und Konzeptnamen dürfen kein Markup enthalten, sonst werden sie übergangen --- geprüft wird das mit Hilfe eines \javaid{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 legitimem, aber "`verdächtigem"' Inhalt übergangen werden --- das ist jedoch recht selten. Definitionstexte, die Markup enthalten, sind erlaubt, lösen aber eine Warnung aus. \later{zahl von "`schlechten"' texten, zahl von false positives}
\end{enumerate}

Die Interpretation der Eigenschaften der Ressource, repräsentiert durch ein \javaid{WikiPage}-Objekt, hängt stark vom Typ der Ressource ab, wie er von \javaid{WikiTextAnalyzer} bestimmt wurde (siehe \rr{sec:ressourcenklassifikation}). Die Verarbeitung beginnt in jeden Fall damit, dass in der Tabelle \sqlid{resource} ein Eintrag für diese Ressource (\bzw Wiki-Seite) gespeichert wird. Das weitere Vorgehen ist für die einzelnen Ressourcetypen wie folgt definiert:

\begin{description}
\item[Kategorieseiten (\javaid{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 \rr{sec:cat-alias}). Existiert keine solche Artikelseite, so wird im Nachbereitungsschritt \javaid{finishMissingRessources} ein Konzepteintrag vom Typ \javaid{ConceptType.UNKNOWN} für das Kategorie-Konzept erstellt (\rr{transform:import-finish}), allerdings erst nachdem alle Kategorisierungsaliase aufgelöst wurden (\rr{sec:cat-alias}).

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 \q{hammwohner:iaw}. Die Auswertung dieser Information wurde hier jedoch aufgrund technischer Schwierigkeiten nicht weiter verfolgt und verbleibt als Gegenstand zukünftiger Forschung\future{}.

\item[Artikelseiten (\javaid{ARTICLE}):] Da Artikelseiten per Definition stets ein Konzept beschreiben, wird zuerst die Methode \javaid{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 (\rr{sec:analyzer:glossen}) und mittels \javaid{LocalConceptStore.storeDefinition} im lokalen Datenmodell abgelegt. 

Als nächstes werden alle Wiki-Links der Seite bestimmt (\rr{sec:analyzer:links}). Auf dieser Grundlage werden die Link-Text-Terme gespeichert und die Kategorisierung bestimmt, wie oben beschrieben. Zusätzlich werden noch die folgenden Aspekte betrachtet:
 
\begin{enumerate}
  \item Querverweise zwischen Artikeln werden als \nom{Referenzbeziehung} \bzw \nom{Assoziation} zwischen Konzepten interpretiert. Daher wird beim Speichern der Link-Text-Terme statt der Methode \javaid{LocalConceptStore.storeReference} die Methode \javaid{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 \rr{sec:link-table}). Diese Daten dienen unter anderem der Berechnung der semantischen Verwandtheit zwischen Termen (\rr{p:finish-relations}).
  \item Wiki-Links können auch auf \emph{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 (\rr{sec:anker}).
  \item Bei der Kategorisierung angegebene \lingo{Sort-Keys} werden verwendet, um dem Konzept, auf das sich der Artikel bezieht, per \javaid{LocalConceptStore.storeReference} weitere Terme zuzuordnen (\javaid{ExtractionRule.TERM_FROM_SORTKEY}). So würde zum Beispiel die Angabe \wikitext{[[Kategorie:Pazifist|Einstein, Albert]]} auf der Seite \wikipage{Albert\_Einstein} dafür sorgen, dass der Term \wwterm{Einstein, Albert} dem Konzept \wwconcept{Albert\_Einstein} zugeordnet wird (\rr{sec:wikitext:links}). Der \lingo{Sort-Key} wird ebenfalls berücksichtigt, wenn er über das Magic Word \wikitext{DEFAULTSORT} angegeben wurde (zugänglich über die Methode \javaid{PlainTextAnalyzer.getDefaultSortKey}, siehe auch \rr{sec:wikitext:magicwords}).
  \item Bei der Bestimmung der Kategorisierung des Artikels kann der Artikel als \nom{Hauptartikel} der betreffenden Kategorie erkannt werden, also als der Artikel, der das Konzept definiert, auf das sich die Kategorie bezieht: siehe \rr{sec:cat-alias}. In diesem Fall wird zusätzlich der Name der Kategorie als Term für das Konzept des Artikels gespeichert (\javaid{ExtractionRule.TERM_FROM_CAT_NAME}).
  \item Language-Links, also Wiki-Links, die den \javaid{magic}-Wert \javaid{LinkMagic.LANGUAGE} haben, werden als Verweise auf eine Beschreibung desselben oder eines ähnlichen Konzeptes in einer anderen Sprache interpretiert (siehe \rr{sec:wikitext:links} sowie \q{WP:INTERLANG}). Diese Verweise werden mittels \javaid{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 (\rr{sec:Merging}).
\end{enumerate}
  
\item[Begriffsklärungsseiten (\javaid{DISAMBIG}):] Zunächst werden die Link-Text-Terme auf der Seite interpretiert, wie oben beschrieben.

Dann werden alle Disambiguierungslinks bestimmt (\rr{sec:analyzer:disambig}), also Verweise auf Artikel, die eine der Bedeutungen definieren, die zum Titel der Begriffsklärungsseite passen. Jeder dieser Bedeutungen wird nun mittels \javaid{LocalConceptStore.storeReference} der Name der Begriffsklärungsseite als Bezeichnung zugewiesen (\javaid{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 \q{WP:BKL} beschrieben ist (vergleiche auch \qq{Strube2006}{GregorowiczKramer2006}). 

\item[Weiterleitungsseiten (\javaid{REDIRECT}):] \label{p:import:redirect}Über die Methode \javaid{WikiPage.getRedirect} wird die Zielseite der Weiterleitung bestimmt. Mittels \javaid{LocalConceptStore.storeReference} wird dann der Name der Weiterleitungsseite als Bezeichnung für das Konzept registriert, auf das die Weiterleitung zeigt (\javaid{ExtractionRule.TERM_FROM_REDIRECT}). Dabei kann es durchaus vorkommen, dass der Name der Weiterleitung 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 \rr{sec:eval-termzuordnung}. 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 \javaid{LocalConceptStore.storeConcept} ein vorläufiger Konzepteintrag vom Typ \javaid{ALIAS} angelegt und per  \javaid{LocalConceptStore.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 \javaid{LocalConceptStore.finishAliases} zur Auflösung von Referenzen auf die Weiterleitungsseite verwendet und dann gelöscht (siehe \rr{transform:import-finish}).

\item[Listen (\javaid{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 \textit{Liste von \wwconcept{X}} würden dann als \textit{\wwconcept{X} untergeordnet} interpretiert. Dabei ergeben sich allerdings zwei Probleme:

\begin{enumerate}
  \item 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, \zB für Titel der Form \wikipage{Liste\_der\_X} --- bei manchen Titeln würde das aber fehlschlagen, \zB bei der Seite \wikipage{Comicformat}, einer Auflistung unterschiedlicher Comic-Formate. Eine Zuordnung zu dem entsprechenden Artikel, der dieses Konzept beschreibt, kann aber bei mehrdeutigen Namen schwierig sein.
  \item 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 (\zB bei den Seiten \wikipage{Marientitel} und \wikipage{Präfixe\_von\_Schiffsnamen}\footnote{Beides nebenbei auch Beispiele für schwer zu interpretierende Titel.}). 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. \later{versuche in der literatur? evaluation?}
  \item Ein Problem mit der Erkennung von Listenartikeln ist, dass zum Teil Seiten als Listen klassifiziert werden, die selbst keine Liste \emph{sind}, sondern eine Liste \emph{beschreiben}, zum Beispiel \wikipage{Rote\_Liste\_gefährdeter\_Arten}. In manchen Fällen trifft sogar beides zu: der Artikel beschreibt eine Liste \emph{und} enthält die Liste selbst --- was eine Unterscheidung vollends unmöglich macht.
\end{enumerate}

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.

\item[Schlechte Seiten (\javaid{BAD}):] Seiten, die zur Löschung vorgeschlagen wurden \q{WP:LR} oder anderweitig als problematisch markiert sind, werden ignoriert.
\end{description}

\subsection{Konzepte aus Abschnitten}
\label{sec:anker}
MediaWiki erlaubt (genau wie HTML) Verknüpfungen auf "`Anker"' \q{W3C:HTML}, also auf bestimmte Stellen \emph{innerhalb} eines Artikels \bzw, in URI-Terminologie, auf Dokument-Fragmente \q{RFC:3986}. In MediaWiki erzeugt jede Überschrift  einen Anker, es ist also möglich, Wiki-Links direkt auf einzelne Abschnitte von Artikeln zu setzen (siehe auch \rr{sec:analyzer:links} und \rr{sec:wikitext:links}). 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 \zB der Wiki-Link \wikitext{[[Myanmar\#Geschichte|Burmesische Geschichte]]} auftreten: er verweist unter dem Term \wwterm{Burmesische Geschichte} auf das Konzept \wwconcept{Myanmar\#Geschichte}, welches im Abschnitt \wikipage{Geschichte} im Artikel \wikipage{Myanmar} behandelt wird --- wir gehen davon aus, dass es sich dabei um ein Konzept handelt, das auf irgendeine Art ein "`Teil"' des Konzeptes \wwconcept{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 (\rr{sec:section-table}) und dann in der Nachbereitung des Imports als Konzepteinträge von unbekanntem Typ (\javaid{ConceptType.UNKNOWN}) erzeugt und ihrem Oberkonzept zugeordnet (\rr{sec:import-nachbereitung}).

\subsection{Kategorien und Konzepte}
\label{p:Hauptartikel}\label{sec:cat-alias}
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 \nom{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:

\begin{enumerate}
  \item Es gibt einen Artikel (also eine Seite mit dem Typ \javaid{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. 
  \item 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. 
  \item Es wurde kein zu der Kategorie passender Artikel gefunden. In diesem Fall wird während der Nachbereitung im Schritt \javaid{finishMissingConcepts} ein "`leeres"' Konzept vom Typ \javaid{ConceptType.UNKNOWN} für die Kategorie erstellt. Die einzige Information, die über dieses 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.
\end{enumerate}

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 \nospell{Sort-Keys}: Per Konvention ist der Hauptartikel einer Kategorie dieser direkt zugeordnet und zwar unter Verwendung eines speziellen \nospell{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 \nom{Kollationsreihenfolge} vor den alphanumerischen Zeichen stehen. Welche \nospell{Sort-Keys} als Markierung für Hauptartikel interpretiert werden, wird von \javaid{WikiConfiguration.mainArtikeMarkerPattern} festgelegt --- per Default wird der reguläre Ausdruck \startregex^[- !_*$@#+~/%]?$ \endregex  verwendet \q{WP:KAT}.  

Allerdings erhält nicht unbedingt ausschließlich der Hauptartikel einer Kategorie so einen speziellen \nospell{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 \wikipage{Frühmittelalter} und \wikipage{Spätmittelalter} in \wikipage{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-Ähnlichkeit\footnote{Die normierte Levenshtein-Distanz nach \q{levenshtein1966bcc}, wie durch \javaid{DefaultLinkSimilarityMeasure.calculateLevenshteinSimilarity} implementiert; vergleiche \rr{p:levenshtein-similarity}} bestimmt. Nur wenn der Ähnlichkeitswert über dem Wert liegt, den \javaid{WikiConfiguration.maxWordFormDistance} festlegt (per Default \var{\slantfrac{1}{3}}), wird der Artikel als Hauptartikel der Kategorie in Betracht gezogen. Dieser Vergleich ist in der Methode \javaid{WikiTextAnalyer.mayBeFormOf} implementiert.

Ein Artikel wird dementsprechend (vorläufig) als Hauptartikel einer Kategorie angesehen, wenn er der Kategorie unter Verwendung eines speziellen \nospell{Sort-Keys} zugeordnet ist und sein Titel dem Titel der Kategorie lexikographisch hinreichend ähnlich ist. In diesem Fall wird die Zuordnung per \javaid{LocalConceptStoreBuilder.storeConceptAlias} registriert, unter Verwendung des \sqlid{scope}-Wertes \javaid{AliasScope.BROADER}, um anzuzeigen, dass es sich um einen Alias bezüglich der Kategorisierung handelt: so wird ein \nom{Kategorisierungsalias} definiert.

Um nun die Eigenschaften der Kategorie --- nämlich ihre Einordnung in die Subsumtionsrelation --- auf den Konzepteintrag des Hauptartikel zu übertragen, werden im Nachbereitungsschritt \javaid{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 \javaid{finishBadLinks} der Nachbereitung werden einige Kategorisierungsaliase wieder gelöscht, und zwar nach folgenden Regeln:

\begin{enumerate}
  \item 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 \wikipage{Kategorie:Mittelalter} der Fall: \wikipage{Frühmittelalter} und \wikipage{Spätmittelalter} sind mögliche Hauptartikel der Kategorie, da jedoch der Artikel \wikipage{Mittelalter} existiert, wird dieser als Hauptartikel bestimmt und alle Kategorisierungsaliase für \wwconcept{Mittelalter} werden gelöscht.
  
  \item 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 \emph{untergeordnet} und die Kategorie sollte somit einen eigenen Konzepteintrag erhalten. 
  
  Zum Beispiel ist das für \wikipage{Kategorie:Arbeit} der Fall: die Seite \wikipage{Arbeit} existiert zwar, ist aber eine Begriffsklärung\footnote{Dass der Titel einer Kategorie mit dem Titel einer Begriffsklärung zusammenfällt, kommt recht häufig vor.}; Kandidaten für Hauptartikel der Kategorie sind \wikipage{Arbeit\_(Sozialwissenschaften)}, \wikipage{Arbeit\_(Philosophie)} und \wikipage{Arbeiter}. Da die Zuweisung eines Hauptartikels aber nicht eindeutig ist, werden alle Kategorisierungsaliase für \wwconcept{Arbeit} wieder gelöscht und \wwconcept{Arbeit} als eigenes Konzept eingeführt, das den Konzepten \wwconcept{Arbeit\_(Sozialwissenschaften)}, \wwconcept{Arbeit\_(Philosophie)} und \wwconcept{Arbeiter} übergeordnet ist.
\end{enumerate}

Für eine Evaluation der hier beschriebenen Heuristiken siehe \rr{sec:eval-subsumtion}.

\subsection{Nachbereitung}
\label{transform:import-finish} 
\label{sec:import-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 \javaid{LocalConceptStoreBuilder} definiert und in \javaid{DatabaseLocalConceptStoreBuilder} implementiert sind:

\begin{description}
\item[\javaid{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 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 (\rr{sec:cat-alias}) gelöscht. Im einzelnen bedeutet das:

  \begin{enumerate}
    \item Es werden aus der Tabelle \sqlid{link} (\rr{sec:link-table}) alle Einträge gelöscht, deren \sqlid{target_name} auf einen Eintrag in der Tabelle \sqlid{resource} (\rr{sec:resource-table}) verweist, der einen der folgenden Typen hat: \javaid{ResourceType.DISAMBIG}, \javaid{ResourceType.LIST} oder \javaid{ResourceType.BAD}. Verweise auf Ressourcen mit dem Typ \javaid{ResourceType.REDIRECT} bleiben zunächst erhalten, diese werden im Schritt \javaid{finishAliases} aufgelöst.
    \item Aus der Tabelle \sqlid{alias} (\rr{sec:alias-table}) werden ebenfalls die Einträge gelöscht, die über \sqlid{target_name} auf eine "`schlechte"' Ressource verweisen, nur dass hier zusätzlich zu den Ressourcen mit den Typen \javaid{ResourceType.DISAMBIG}, \javaid{ResourceType.LIST} oder \javaid{ResourceType.BAD} auch die mit Typ \javaid{ResourceType.REDIRECT} als "`schlecht"' betrachtet werden --- auf diese Weise werden Weiterleitungen auf Weiterleitungen entfernt; solche mehrfachen Weiterleitungen werden von MediaWiki nicht unterstützt und sind daher als Fehler in der Datenbasis anzusehen.
    \item Aus der Tabelle \sqlid{alias} werden alle die Einträge gelöscht, deren \sqlid{scope} \javaid{AliasScope.BROADER} ist und deren Feld \sqlid{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 \rr{sec:cat-alias}).
    \item Aus der Tabelle \sqlid{alias} werden außerdem all die Einträge gelöscht, deren \sqlid{scope} \javaid{AliasScope.BROADER} ist und deren Feld \sqlid{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 \rr{sec:cat-alias}).
    \item Aus der Tabelle \sqlid{section} (\rr{sec:section-table}) werden alle Einträge gelöscht, deren \sqlid{concept_name} auf einen Eintrag in der Tabelle \sqlid{resource}  verweist, der einen der folgenden Typen hat: \javaid{ResourceType.DISAMBIG}, \javaid{ResourceType.LIST} oder \javaid{ResourceType.BAD}. Das bedeutet, dass Konzepte aus Abschnitten (\rr{sec:anker}) nur für "`richtige"' Artikelseiten definiert sind.
    \item Aus der Tabelle \sqlid{section} werden alle Einträge gelöscht, deren Feld \sqlid{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.
    \end{enumerate}
  
\item[\javaid{finishSections}:]  Dieser Schritt dient der Verarbeitung der Artikelabschnitte, die als Link-Ziele vorkommen und daher als Konzepte modelliert werden sollen (vergleiche \rr{sec:anker}). 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:

  \begin{enumerate}
    \item Für jeden Eintrag in der Tabelle \sqlid{section} (\rr{sec:section-table}) wird ein Eintrag in der Tabelle \sqlid{concept} (\rr{sec:concept-table}) angelegt, wobei \sqlid{concept.name} auf den Wert von \sqlid{section.concept_name} gesetzt wird und \sqlid{concept.type} auf \javaid{ConceptType.UNKNOWN}.
  \item Für jeden Eintrag in der Tabelle \sqlid{section} wird ein Eintrag in der Tabelle \sqlid{broader} (\rr{sec:broader-table}) vorgenommen, so dass der Wert des Feldes \sqlid{broader.broad_name} dem Wert von \sqlid{section.concept_name} entspricht und der Wert des Feldes \sqlid{broader.narrow_name} dem von \sqlid{section.section_name}. Die verwendete Regel wird als \javaid{ExtractionRule.BROADER_FROM_SECTION} angegeben.
  \end{enumerate}

\item[\javaid{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 \rr{sec:cat-alias}). Für solche Konzepte ohne eigene Wiki-Seite wird ein Eintrag mit dem Typ \javaid{ConceptType.UNKNOWN} angelegt. Im Einzelnen:
  \begin{enumerate}
    \item Für jeden Wert von \sqlid{link.target_name} (\rr{sec:link-table}), der nicht auf ein existierendes Konzept zeigt, wird ein Konzepteintrag mit dem entsprechenden Namen in der Tabelle \sqlid{concept} angelegt.
    \item Als Vorbereitung für den nächsten Teilschritt werden nun die Kategorisierungsaliase aufgelöst: In der Tabelle \sqlid{broader} (\rr{sec:broader-table}) werden alle Werte in den Feldern \sqlid{broad} und \sqlid{broad_name} \bzw \sqlid{narrow} und \sqlid{narrow_name}, für die es einen passenden Eintrag in der  Tabelle \sqlid{alias} (\rr{sec:alias-table}) mit einem \sqlid{scope} von \javaid{AliasScope.BROADER} gibt, mit den entsprechenden Werten von \sqlid{alias.target} und \sqlid{alias.target_name} ersetzt.
    \item Für jeden Wert der Felder \sqlid{broad_name} sowie \sqlid{narrow_name} in der Tabelle \sqlid{broader} (\rr{sec:broader-table}), der nicht auf ein existierendes Konzept zeigt, wird ein Konzepteintrag angelegt. Das sind vor allem Navigationskategorien, zu denen es keinen entsprechenden Artikel gibt.
  \end{enumerate}
\item[\javaid{finishIdReferences}:] \label{p:resolve-ids} 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 \sqlid{link} (\rr{sec:link-table}) und \sqlid{broader} (\rr{sec:broader-table})). 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 \sqlid{NULL}. In diesem Schritt der Nachbereitung werden nun die fehlenden Werte in den Referenzfeldern, die sich auf die Konzept-ID beziehen, nachgetragen. Im Einzelnen:
  \begin{enumerate}
    \item In der Tabelle \sqlid{link} werden fehlende IDs in der Spalte \sqlid{target} anhand der Konzeptnamen in der Spalte \sqlid{target_name} nachgetragen. Die Zuordnung von IDs zu Namen wird der Tabelle \sqlid{concept} entnommen.
    \item In der Tabelle \sqlid{broader} werden fehlende IDs in den Spalten \sqlid{broad} \bzw \sqlid{narrow} anhand der Konzeptnamen in den Spalten \sqlid{broad_name} \bzw \sqlid{narrow_name} nachgetragen.
    \item In der Tabelle \sqlid{alias} (\rr{sec:alias-table}) werden fehlende IDs in der Spalte \sqlid{target} anhand der Konzeptnamen in der Spalte \sqlid{target_name} nachgetragen.
  \end{enumerate}
  
\label{p:id-manager} 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 \nom{Agenda}-Objekts zu erlauben). 

Dieser Modus kann über den \nom{Tweak}-Wert \javaid{dbstore.idManager = true} aktiviert werden, wobei darauf zu achten ist, dass der Java VM über den Parameter \cli{-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 Gigabyte\footnote{Zur Speicherung der Abbildung wird die Standard-Klasse \javaid{java.util.HashMap} verwendet. Der Platzaufwand ließe sich eventuell durch die Verwendung einer geeigneten Implementation eines Trie oder DAWG reduzieren (vergleiche \qs{heyer2006wrt}{68}).}. Wird keine ID-Map im Speicher gehalten, so sind 512 Megabyte für den Import von Wikis aller Größen ausreichend.
  
\item[\javaid{finishAliases}:] \label{p:finish-aliases}In diesem Schritt werden Aliase aufgelöst (vergleiche \rr{sec:wikitext:magicwords} und \rr{p:features:weiterleitung}) --- das heißt, in sämtlichen Tabellen werden Referenzen auf solche Konzepte vom Typ \javaid{ConceptType.ALIAS} durch diejenigen ersetzt, auf die der betreffende Alias-Eintrag in der Tabelle \sqlid{alias} (\rr{sec:alias-table}) verweist. Im Einzelnen:
  \begin{enumerate}
    \item In der Tabelle \sqlid{link} werden Aliase für Werte in den Spalten \sqlid{target} und \sqlid{target_name} aufgelöst: Einträge, die zu Werten in \sqlid{alias.source} \bzw \sqlid{alias.source_name} passen, werden durch die entsprechenden Werte von \sqlid{alias.target} \bzw \sqlid{alias.target_name} ersetzt.
    \item In der Tabelle \sqlid{broader} werden die Spalten \sqlid{narrow} und \sqlid{narrow_name} sowie \sqlid{broad} und \sqlid{broad_name} entsprechend den Einträgen in der \sqlid{alias} Tabelle angepasst.
    \item Aus der Tabelle \sqlid{concept} (\rr{sec:concept-table}) werden alle Einträge mit dem Typ \javaid{ConceptType.ALIAS} gelöscht.
    \item Aus der Tabelle \sqlid{link} werden alle Einträge gelöscht, deren Feld \sqlid{target} auf kein existierendes Konzept mehr verweist --- das heißt solche Links, die auf fehlerhafte Weiterleitungen verwiesen. 
    \item Für jeden Wert der Felder \sqlid{broad_name} sowie \sqlid{narrow_name} in der Tabelle \sqlid{broader} (\rr{sec:broader-table}), der nicht auf ein existierendes Konzept zeigt, wird ein Konzepteintrag angelegt. Diese Wiederholung aus dem Schritt \javaid{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 werden\footnote{Das tritt nur ein, wenn es sich um einen "`schlechten"' Alias gehandelt hat, \zB einen, der auf eine Begriffsklärung zeigte und deshalb keinen Eintrag in der der \sqlid{alias}-Tabelle hatte. Ansonsten wurden die entsprechenden Einträge in der \sqlid{broader}-Tabelle bereits angepasst.}.
   \end{enumerate}
\item[\javaid{finishRelations}:] \label{p:finish-relations} In diesem Schritt werden semantische Verwandtheit und Ähnlichkeit zwischen Konzepten bestimmt und in die Tabelle \sqlid{relation} (\rr{sec:relation-table}) eingetragen. Genauer:
  \begin{enumerate}
    \item Alle Paare von Konzepten, die einen gemeinsamen Language-Link haben (die also Einträge in der Tabelle \sqlid{langlink} (\rr{sec:langlink-table}) haben, die bezüglich der Felder \sqlid{language} und  \sqlid{target} übereinstimmen), werden im Feld \sqlid{langmatch} markiert. Solche Konzepte werden als \nom{ähnlich} angesehen, da Language-Links per Konvention immer auf Artikel mit gleichem oder sehr ähnlichem Gegenstand verweisen (vergleiche \rr{sec:Merging} und \q{WP:INTERLANG}). Wie viele Konzepte es gibt, die in diesem Sinne als ähnlich erkannt werden, hängt stark von der \nom{Granularität} des Wikis ab: in einem Wiki 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 andere Wiki eine geringere Granularität hat (siehe \rr{sec:eval-aehnlichkeit} für die Evaluation).
    
Bei der Bestimmung der Ähnlichkeit von \emph{globalen}, sprachübergreifenden Konzepten wird zusätzlich das Feld \sqlid{langref} verwendet (siehe \rr{sec:global-nachbreitung}). Es modelliert die Ähnlichkeit von Konzepten, die sich gegenseitig \emph{direkt} über einen Language-Link referenzieren (siehe \rr{sec:Merging}). Die so bestimmte Ähnlichkeit von Termen wird in \rr{sec:eval-aehnlichkeit} evaluiert.

    \item Alle Paare von Konzepten, die sich gegenseitig referenzieren (die also jeweils einen Eintrag in der Tabelle \sqlid{link} haben, der auf das andere Konzept verweist), werden im Feld \sqlid{bilink} markiert. Solche Konzepte werden als \nom{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 \nom{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 \emph{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 \q{GregorowiczKramer2006}. Die so bestimmte Verwandtheit von Termen wird in \rr{sec:eval-verwandtheit} evaluiert.
  \end{enumerate}
  
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 \qq{biemann2004lim}{Biemann05cooc}. Dieser Möglichkeit wurde im Rahmen der vorliegenden Arbeit aufgrund des zusätzlichen Aufwands an Programmlogik, Rechenzeit und Speicherplatz nicht nachgegangen\future{}. Im Rahmen des Wortschatzprojektes \qq{quasthoff1998pdw}{Wortschatz} hat \person{Matthias Richter} Versuche zur Kookkurrenzanalyse der Verknüpfungsstruktur der deutschsprachigen Wikipedia durchgeführt\footnote{Keine Publikation bekannt, eine experimentelle Web-Schnittstelle zu den Ergebnissen befindet sich auf \uref{http://wortschatz.uni-leipzig.de/WP/}.}.
  
\item[\javaid{buildTermsForMissingConcepts}:] In diesem Schritt, der im Gegensatz zu den anderen aus technischen Gründen in der Klasse \javaid{ConceptImporter} implementiert ist, wird für jedes Konzept mit dem Typ \javaid{ConceptType.UNKNOWN} (also jedem Konzepteintrag, zu dem es keinen Artikel gibt) der Titel-Term bestimmt und gespeichert. Genauer wird der "`Basisname"' des Konzeptes bestimmt (\rr{sec:analyzer:terme}) und dieser dann per \javaid{LocalConceptStore.storeReference} in die Tabelle \sqlid{link} eingetragen.

\item[\javaid{finishMeanings}:] \label{p:finish-meanings}In diesem Schritt wird die \nom{Bedeutungsrelation} zwischen Termen und Konzepten berechnet. Diese stellt ein Kernstück des Thesaurus dar, das dazu dient, die \lingo{Semantic Gap} zwischen Text und Inhalt zu überbrücken \qqq{GregorowiczKramer2006}{Mihalcea2007}{gabrilovich2006obb}. Die Termzuordnung über die Bedeutungsrelation wird in \rr{sec:eval-termzuordnung} evaluiert.

Die Bedeutungsrelation wird durch die Tabelle \sqlid{meaning} (\rr{sec:meaning-table}) repräsentiert. Diese Tabelle wird nun befüllt, indem die Einträge in der Tabelle \sqlid{link} über die Felder \sqlid{target} und \sqlid{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 \sqlid{target} und \sqlid{term_text}, das Gruppen-Maximum des Codes im Feld \sqlid{rule} mit in die Tabelle \sqlid{meaning} übernommen. Da der Code für die Regel \javaid{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 (\rr{sec:eval-termzuordnung}). 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 (\rr{export:cutoff}).

\item[\javaid{finishFinish}:] \label{p:finish-finish}Dies ist der letzte Schritt der Nachbereitung, er dient dazu, letzte Inkonsistenzen zu beseitigen. Er besteht aus den folgenden Operationen:
  \begin{enumerate}
    \item Entfernen aller Schleifen aus der Verknüpfungsrelation, also alle Einträge aus der  Tabelle \sqlid{link}, deren \sqlid{anchor}- und \sqlid{target}-Felder denselben Wert haben.
    \item Entfernen aller Schleifen aus der Subsumtionsrelation, also alle Einträge aus der  Tabelle \sqlid{broader}, deren \sqlid{broad}- und \sqlid{narrow}-Felder denselben Wert haben.
    \item Entfernen aller Zyklen aus dem Graphen, der durch die Subsumtionsrelation definiert ist. Hierfür wird der in \rrr[Anhang]{ch:zyklen} beschriebene Algorithmus verwendet. Dies ist notwendig, da die Kategoriestruktur der Wikipedia zwar per Konvention ein zusammenhängender, azyklischer Graph ist \q{WP:KAT}, die MediaWiki Software diese Eigenschaften aber nicht erzwingt, Zyklen in der Struktur also durchaus auftreten können \q{Hammwoener2007Prem}. Die Semantik der Subsumtionsrelation verlangt aber, dass sie eine \nom{Halbordnung} bildet und somit azyklisch sein muss.
   \end{enumerate}
\end{description}

Das Ergebnis der Nachbereitung ist ein vollständiger \nom{lokaler Datensatz}, der einen monolingualen Thesaurus repräsentiert. Die  Konzepte und Relationen in diesem Thesaurus werden in \rr{ch:eval-analyse} evaluiert. Der nächste Abschnitt beschreibt, wie die lokalen Datensätze für unterschiedliche Sprachen zu einem multilingualen Thesaurus zusammengefasst werden können.

\section{Zusammenführen des multilingualen Thesaurus}
\label{transform:zusammenfuehren} 
\label{sec:BuildThesaurus}
 
Das Zusammenführen der einzelnen lokalen Datensätze zu einem globalen Datensatz ist die Aufgabe des Programms \javaid{BuildThesaurus}.  Die einzelnen Schritte der Zusammenführung sind in \javaid{DatabaseGlobalConceptStoreBuilder} implementiert und werden im Folgenden näher erläutert.

\label{p:language-bits} 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 \sqlid{language_bits} in der Tabelle \sqlid{concept} gespeichert (\rr{sec:concept-table}).

\subsection{Import der Konzepte}
\label{sec:global-import}

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:

\begin{description}
\item[\javaid{importOrigins}:] In diesem Schritt wird für jedes Konzept aus dem lokalen Datensatz in der Tabelle \sqlid{origin} (\rr{sec:origin-table}) 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 \sqlid{concept} des globalen Datensatzes verwendet wird. Die Tabelle \sqlid{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.
\item[\javaid{importConcepts}:] In diesem Schritt werden die globalen Konzepteinträge für die Tabelle \sqlid{concept} erzeugt (\rr{sec:concept-table}). Dafür wird die in der Tabelle \sqlid{origin} definierte globale Konzept-ID verwendet, der Konzepttyp (\rr{sec:konzeptklassifikation}) 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.
\item[\javaid{importLanglinks}:] Um die Language-Links der Konzepte aus verschiedenen lokalen Datensätzen vergleichen zu können, werden sie in diesem Schritt in die Tabelle \sqlid{langlink} des globalen Datensatzes übernommen (\rr{sec:langlink-table}). Die IDs der lokalen Konzepte werden dabei über die \sqlid{origin} in die IDs der globalen Konzepteinträge umgewandelt.
\end{description}

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:

\begin{description}
  \item[\javaid{resolveLanglinkAliases}:] In der Tabelle \sqlid{langlink} (\rr{sec:langlink-table}) werden für diejenigen Einträge, deren \sqlid{target}-Feld zu dem Sprachcode des gerade betrachteten lokalen Datensatzes passt, die Werte in der Spalte \sqlid{target} anhand der Tabelle \sqlid{alias} (\rr{sec:alias-table}) aus diesem lokalen Datensatz angepasst. Zum Beispiel wird während der Verarbeitung der Daten für den \someid{en}-Datensatz (also des englischsprachigen Thesaurus) der Language-Link von \wwconcept{de:3-SAT} auf \wwconcept{en:3-SAT} angepasst und auf \wwconcept{en:Boolean\_satisfiability\_problem} geändert, da in der englischsprachigen Wikipedia die Seite \wikipage{3-SAT} eine Weiterleitung auf \wikipage{Boolean\_satisfiability\_problem} ist.
  \item[\javaid{deleteAliasedLanglinks}:] In diesem Schritt werden aus der Tabelle \sqlid{langlink} sämtliche Einträge entfernt, die noch auf ein Konzept verweisen, das in der Tabelle \sqlid{alias} als Alias vermerkt ist. Damit werden doppelte Weiterleitungen ignoriert.
\end{description}

\subsection{Aufbau der sprachübergreifenden Konzepte}
\label{sec:Merging}

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:

\begin{enumerate}
  \item Die Language-Links in einem Artikel verweisen auf Artikel in einer anderen Sprache, die dasselbe oder zumindest ein ähnliches Konzept zum Gegenstand haben \q{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 \q{hammwohner:iaw} näher untersucht.
  \item Pro Sprache kann es in einem Artikel nur einen (ausgehenden) Language-Link geben\footnote{Per 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.}. Umgekehrt jedoch können mehrere Artikel aus einer Sprache auf denselben Artikel in einer anderen Sprache verweisen, es kann also pro Artikel mehrere \emph{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.
  \item Referenzieren sich zwei Artikel aus unterschiedlichen Sprachen \emph{gegenseitig} über Language-Links, so beschreiben sie \emph{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 \rr{p:finish-relations} genutzten Annahme, dass zwei Artikel, die sich gegenseitig referenzieren, verwandte Konzepte beschreiben, wie von \q{GregorowiczKramer2006} vorgeschlagen.
  
  \item Es gibt pro Sprache nur einen Artikel für jedes Konzept\footnote{Wieder per Konvention \q{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.} --- zwei Artikel aus derselben Wikipedia sollten also niemals demselben sprachunabhängigen Konzept zugewiesen werden. 
  \later{zahlen: duplikate/redundante artikel!}
  \item Sollten zwei Artikel derselben Sprache aufgrund der gegenseitigen Verknüpfung mit Artikeln in anderen Sprachen als äquivalent gelten, so wird diese Situation als \nom{Konflikt} bezeichnet (siehe Evaluation in \rr{sec:eval:thesaurus}) --- diese Situation kann dann auftreten, wenn die folgende Verweisstruktur von Language-Links besteht: \nospell{$A_1 \leftrightarrow B \leftrightarrow C \leftrightarrow A_2$}. Dann stehen \var{A_1} und \var{A_2} in Konflikt zueinander: sie können als \nom{sehr ähnlich} gelten, dürfen aber nicht demselben sprachunabhängigen Konzept zugewiesen werden.
  \item 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.
\end{enumerate}

Vor dem eigentlichen Zusammenführen von Konzepten müssen zunächst Paare von ähnlichen Konzepten aus unterschiedlichen Sprachen identifiziert werden. Die Methode \javaid{prepareGlobalConcepts} füllt dazu die Tabelle \sqlid{relation} (\rr{sec:relation-table}) in den folgenden zwei Schritten:

  \begin{description}
    \item[\javaid{buildLangMatch}:] In die Spalte \sqlid{langmatch} der Tabelle \sqlid{relation} wird für Paare von Konzepten, die \emph{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.
    \item[\javaid{buildLangRef}:] In die Spalte \sqlid{langref} der Tabelle \sqlid{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 \nospell{$(A, B)$} wie auch für das Paar \nospell{$(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.
  \end{description}

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 \rrr[Anhang]{alg:Merging} detailliert beschrieben, die Ergebnisse werden in \rr{sec:eval:thesaurus} 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 \nom{Featurevektor} zu betrachten \q{salton75vector}. 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 \emph{Ä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\future{}.

\subsection{Nachbereitung}
\label{sec:global-nachbreitung}

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 \javaid{finishGlobalConcepts} importiert zunächst aus jedem lokalen Datensatz die verbleibenden relevanten Relationen, im Einzelnen:

  \begin{enumerate}
    \item Die Tabelle \sqlid{link} wird unter Verwendung der ID-Abbildung in der Tabelle \sqlid{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. 
    \item Ebenso unter Verwendung der Tabelle \sqlid{origin} wird die Tabelle \sqlid{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.
  \end{enumerate} 
  
Auf diese Weise werden die verschiedenen Beziehungen aus den einzelnen lokalen Datensätzen zusammengeführt. Nachdem alle Relationen so importiert wurden, führt \javaid{finishGlobalConcepts} schließlich die folgenden Schritte aus:

  \begin{enumerate}
    \item Entfernen aller Schleifen aus der Verknüpfungsrelation, also alle Einträge aus der  Tabelle \sqlid{link} (\rr{sec:link-table}), deren \sqlid{anchor}- und \sqlid{target}-Felder denselben Wert haben.
    \item Entfernen aller Schleifen aus der Subsumtionsrelation, also alle Einträge aus der  Tabelle \sqlid{broader} (\rr{sec:broader-table}), deren \sqlid{broad}- und \sqlid{narrow}-Felder denselben Wert haben.
    \item Entfernen aller Zyklen aus dem Graphen, der durch die Subsumtionsrelation definiert ist. Hierfür wird der in \rrr[Anhang]{ch:zyklen} 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 \q{hammwohner:iaw} wird vorgeschlagen, die Kategoriestruktur verschiedener Wikipedias 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\future{}.
     
    \item 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 \sqlid{link} haben, der auf das andere Konzept verweist), werden im Feld \sqlid{bilink} der Tabelle \sqlid{relation} (\rr{sec:relation-table}) markiert. 
    \item Die Spalte \sqlid{langref} in der Tabelle \sqlid{relation} wurde bereits in \rr{sec:Merging} für Konzepte befüllt, die sich über einen Eintrag in der Tabelle \sqlid{langlink} (\rr{sec:langlink-table}) referenzieren. In diesem Schritt wird diese bislang asymmetrische Beziehung nun symmetrisch ergänzt: für jeden Eintrag mit \nospell{$langref(A, B) > 0$} wird \nospell{$langref(B, A) \gets langref(B, A) + langref(A, B)$} gesetzt. Dabei ergibt sich genau für jene Paare, die sich gegenseitig referenzieren, ein Wert \nospell{$>1$} --- das sind genau solche Paare, deren Konzepte sich \nom{sehr ähnlich} sind, die aber nicht verschmolzen wurden, weil sie zueinander in Konflikt stehen (siehe \rr{sec:Merging}). Für Paare mit \nospell{$langref(A, B) = 1$} wird eine einfache Ähnlichkeit angenommen (\rr{sec:eval:thesaurus}).
\later{check numbers in DB}
   \end{enumerate}

\section{Aufbau der statistischen Daten}
\label{sec:BuildStatistics}

Das Programm \javaid{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 \javaid{DatabaseLocalConceptStoreBuilder.DatabaseLocalStatisticsStoreBuilder} \bzw \javaid{DatabaseGlobalConceptStoreBuilder.DatabaseGlobalStatisticsStoreBuilder} in der Methode \javaid{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:

\begin{description}
\item[\lingo{indegree},] der Knotengrad bezüglich eingehender Verweise, wird aus der Tabelle \sqlid{link} (\rr{sec:link-table}) bestimmt und im Feld \sqlid{in_degree} der Tabelle \sqlid{degree} (\rr{sec:link-table}) gespeichert; der Rang bezüglich dieses Wertes wird im Feld \sqlid{in_rank} abgelegt.
\item[\lingo{outdegree},] der Knotengrad bezüglich ausgehender Verweise, wird aus der Tabelle \sqlid{link} bestimmt und im Feld \sqlid{out_degree} der Tabelle \sqlid{degree} gespeichert; der Rang bezüglich dieses Wertes wird im Feld \sqlid{out_rank} abgelegt.
\item[\lingo{linkdegree},] der Knotengrad bezüglich der Summe von eingehenden und ausgehenden Verweisen, wird aus der Tabelle \sqlid{link} bestimmt und im Feld \sqlid{link_degree} der Tabelle \sqlid{degree} gespeichert; der Rang bezüglich dieses Wertes wird im Feld \sqlid{link_rank} abgelegt.
\item[\lingo{idf}] ist die \lingo{Inverse Document Frequency} bezüglich der Anzahl der Konzepte, die über die Tabelle \sqlid{link} auf ein gegebenes Konzept verweisen. Dieser Wert ist, angelehnt an \q{Salton:86}, definiert als 

\nospell{$$ idf(c_i) = log \left ( \frac{|C|}{indegree(c_i)} \right ) $$}

Der IDF-Wert dient zur Abschätzung der \nom{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 \sqlid{idf_rank} abgelegt.
\item[\lingo{lhs}] ist der \lingo{Local Hierarchy Score} nach \q{muchnik2007sekt} bezüglich eingehender und ausgehender Verweise, wie sie durch die Tabelle \sqlid{link} definiert sind. Dieser Wert ist definiert als 

\nospell{$$ lhs(c_i) = \frac{indegree(c_i) \cdot \sqrt{indegree(c_i)}}{indegree(c_i) + outdegree(c_i)} $$}\\

Dabei wird die von \q{muchnik2007sekt} vorgeschlagene symmetrische Ergänzung nicht verwendet, da diese eine Anpassung für ungerichtete Graphen darstellt. Der LHS-Wert dient zur Abschätzung der \nom{Zentralität} eines Konzeptes, also des Grades, zu dem es zur \nom{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 LHS-Wertes wird in der Spalte \sqlid{lhs_rank} abgelegt.

\item[\lingo{freq},] die Termfrequenz für die einzelnen Terme, wird aus der Tabelle \sqlid{link} bestimmt und im Feld \sqlid{freq} der Tabelle \sqlid{term} gespeichert; der Rang bezüglich dieses Wertes wird im Feld \sqlid{rank} abgelegt. Der Rang eines Terms kann auch als eine eindeutige ID für diesen Term verwendet werden (vergleiche \qs{heyer2006wrt}{59}).
\end{description}

Für die Knotengrade sowie die Termfrequenzen wird eine Verteilung gemäß dem Zipfschen Gesetz \q{zipf35pbl} erwartet (und in \rr{sec:verteilungen} \bzw \rr{sec:verteilungen:knotengrade} auch bestätigt). In Hinblick darauf werden in der Methode \javaid{DatabaseWikiWordConceptStoreBuilder.buildDistributionStats} für jede dieser Verteilungen die folgenden Werte erhoben und in der Tabelle \sqlid{stats} (\rr{sec:stats-table}) abgelegt:

\begin{description}
  \item[\lingo{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 \var{t}.
  
  \item[\lingo{total token occurrences}:] Die Anzahl der "`Tokens"' \var{N}, also die Summe der Verwendungen \bzw Referenzen \var{V} der einzelnen Terme \bzw Konzepte \var{x_i}: 
  
 \nospell{$$N = \sum_i{V(x_i)}$$}
 
  \item[\lingo{average type value}:] Die durchschnittliche Anzahl der Verwendungen jedes Typs (also jedes Terms \bzw Konzeptes) \var{\bar{v}}: 
  
  \nospell{$$\bar{v} = \frac{N}{t}$$}
  
  \item[\lingo{average type value x rank}:] Der durchschnittliche Wert des Rang-Wert-Produkts, \var{k}: Sei \var{R(x)} der Rang des Typs \var{x}, und \var{V(x)} die Anzahl der Verwendungen von \var{x}, so ist dieser Wert gegeben durch 
  
  \nospell{$$k = \frac{\sum_i{R(x_i) \cdot  V(x_i)}}{t}$$}
  
    Nach dem Zipfschen Gesetz wird nun erwartet, dass für alle \var{x_i} gilt: 
    
    \nospell{$$R(x_i) \cdot V(x_i) \approx k$$}
  
  \item[\lingo{characteristic fitting}:] Die normierte durchschnittliche Anzahl der Verwendungen jedes Typs: 
  
 \nospell{$$c = \frac{k}{N} = \frac{\sum_i{R(x_i) \cdot  V(x_i)}}{t \cdot N}$$}
 
 Dieser Wert ist der charakteristische \nom{Anpassungskoeffizient} des Korpus.
  
  \item[\lingo{deviation from char. fit.}:] Die Standardabweichung des Rang-Wert-Produktes: 
  
  \nospell{$$d_k = \sqrt{\frac{\sum_i{\left(c - \frac{R(x_i) \cdot  V(x_i)}{N}\right)^2}}{t}}
  				 = \sqrt{\frac{\sum_i{\left(k - R(x_i) \cdot  V(x_i)\right)^2}}{t \cdot N^2}}$$}
  Dieser Wert gibt Auskunft darüber, wie genau die Verteilung dem Zipfschen Gesetz folgt.
    
\end{description}

Die einzelnen Verteilungen und ihre statistischen Eigenschaften für konkrete Daten werden in \rr{sec:verteilungen} und \rr{sec:verteilungen:knotengrade} diskutiert.

\section{Vorbereitung von Konzeptdaten für den schnellen Zugriff}
\label{sec:BuildConceptInfo}\label{p:property-cache}

Das Programm \javaid{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 "`\lingo{Property Cache}"'). Gespeichert werden diese vorausberechneten Listen in den Tabellen \sqlid{concept_info} und \sqlid{concept_description} (siehe \rr{sec:concept-info-table} und \rr{sec:concept-description-table}). Die Berechnung ist implementiert in den Klassen \javaid{DatabaseLocalConceptStoreBuilder.DatabaseLocalConceptInfoStoreBuilder} \bzw \javaid{DatabaseGlobalConceptStoreBuilder.DatabaseGlobalConceptInfoStoreBuilder} in der Methode \javaid{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 \nom{ID}, \nom{Name}, \nom{Frequenz} und \nom{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 "`\lingo{Unit Separator}"'-Zeichen des ASCII-Standards \q{ISO:646} (Hex-Code \texttt{\nospell{1F}}), es ist in \javaid{ConceptInfoStoreSchema.referenceFieldSeparator} definiert und kann über den Tweak-Wert \javaid{dbstore.cacheReferenceFieldSeparator} konfiguriert werden (siehe \rr{sec:tweaks}). Analog ist das Trennzeichen für die Tupel untereinander das "`\lingo{Record Separator}"'-Zeichen des ASCII-Standards (Hex-Code \texttt{\nospell{1E}}), es ist in \javaid{ConceptInfoStoreSchema.referenceSeparator} definiert und kann über den Tweak-Wert \javaid{dbstore.cacheReferenceSeparator} konfiguriert werden. Des Weiteren ist die Gesamtlänge der serialisierten Daten pro Feld beschränkt --- die Maximallänge kann über den Tweak-Wert \javaid{dbstore.listBlobSize} angepasst werden und liegt per Default bei 65025 Bytes.

Die vorberechneten Relationen sind die Basis für die Klassen \javaid{GlobalConcept} und \javaid{LocalConcept} für Transferobjekte (siehe \rr{sec:transferobjekte}). Jeder Eintrag in einer solchen Liste wird typischerweise durch ein Transferobjekt vom Typ \javaid{GlobalConceptReference}, \javaid{GlobalConceptReference} \bzw \javaid{TermReference} repräsentiert. Die Deserialisierung ist entsprechend in \javaid{WikiWordReference.parseList} implementiert.
