diplom-M-Hilberer.pdf

(1)

Development of Algorithms for Web

Spam Detection based on Structure

and Link Analysis

von

Michael Hilberer

Betreuer:

Prof. Hendrik Speck

(2)

Gliederung

Kapitel Seite

1. Einleitung 1

1-1

2 Search Engine Technologie und SEO 2.1 Search Engine Technologie

2.2 Rankingalgorithmen und Web Spam 2.3 Techniken des SEO

2.4 Geschäftsmodelle des SEO

2 2-1 2-2 2-3 2-4

3. Charakteristiken des World Wide Web aufgrund seiner Graphstruktur

3.1 Clustering

3.2 Degree Distribution 3.3 Degree Correlations 3.4 Betweenness Centrality 3.5 Efficiency

3.6 Lower Order Clustering Coefficient oder Reciprocity 3.7 Diameter

3.8 Average Minimum Path Length

3 3-1 3-3 3-4 3-5 3-5 3-6 3-6 3-6

4. Umsetzung in JAVA 4.1 VALHALLA Framework 4.2 HEIMDALL

4.3 Testumgebung 4.4 GraphML

4.5 Umsetzung der netzwerktheoretischen Funktionen 4.6Aufruf der Analysefunktionen

4.7 Speichern der Datensätze 4.8 finale GUI

4.9 Heimdall.app – Graphanalyse unter Mac OS X

4 4-1 4-3 4-5 4-7 4-11 4-15 4-17 4-17 4-20

5 Testszenarien und Aufbauen der Datensätze 5.1 JWebSpinner

5.2 Web Spam Szenarien 5.3 Ideelles Web Szenarien 5.4 Datensätze 5 5-1 5-2 5-5 5-9

6. Charakteristiken eines ideellen im Gegensatz zum spambelasteten Web

6.1 Charakteristiken des ideellen Webs

6.2 Charakteristiken des spambelasteten Webs

6 6-4 6-5

(3)

Kapitel Seite

7. Vorschläge zur Entwicklung von Spam Detection Algorithmen 7.1 Wertebereiche

7.2 Shortest Path Berechnung 7.3 Vorschlag eines Algorithmus 7.4 Ausblick

7 7-1 7-2 7-3 7-3

8. Bewertung 8

8-1

9. Referenzen 9

9-1 / 9-2 / 9-3 10. Anhänge

10.1 Quelltexte

10.2 Beispiel Datensatz “Web Spam Modell” 10.3 CD-ROM

10

11. Ehrenwörtliche Erklärung 11

(4)

1. Einleitung

Anfang der 90er Jahre entwickelte Tim Berners Lee am europäischen Kernforschungszentrum CERN ein Hypertextsystem, um Wissenschaftlern das kollaborative Arbeiten an komplexen Themen zu erleichtern [33]. Das World Wide Web war geboren. Heute ist das www, eine unüberschaubare Ansammlung an Hypertext Dokumenten und verschiedensten Mediendateien und es wächst bereits seit Jahren exponentiell. Was in der Schweiz mit wenigen Textdokumenten begann, erwuchs bis heute zu einer multimedialen Sammlung von geschätzten 20 Milliarden Seiten. Damit einher entstand das Problem aus dieser ungeheuren Anzahl von digitalen Datensätzen brauchbare Informationen zu gewinnen.

In den ersten Jahren war dies noch mit einem manuell gepflegten Indexsystem [31], ähnlich einem Bibliothekssystem, möglich, doch das schnelle Wachstum des Mediums machte dies bald schon unmöglich. Die nächste Generation der Information Retrieval Tools im Internet entstand, die automatisierte Suchmaschine. Diese erste Generation führte bereits grundlegende Techniken ein, wie den Webcrawler [12], ein Programm, das ausgehend von einigen URLs, hier Seed-URLs genannt, den Hyperlinks folgend, automatisch das Web bereist und die besuchten Seiten in einer Datenbank indiziert. Ebenso wurde ein Webfrontend entworfen, das es dem Benutzer ermöglicht, eine Suchabfrage nach Schlüsselwörtern (engl. Keywords) durchzuführen, und aufgrund der Eingabe eine Antwort aus der Datenbank generiert.

Die simplen Bewertungskriterien dieser Generation von Suchmaschinen waren rein semantischer Natur, z.B. nach Häufung der Keywords in den Meta-Tags einer Webpage, und erwiesen sich schon bald als wenig zuverlässig und leicht manipulierbar.

Eine deutliche Verbesserung der Qualität der Suchergebnisse brachte die Einführung der so genannten "citation based ranking algorithms", also von Algorithmen, die an Hand der Anzahl von Dokumenten, die auf ein Zieldokument linken, die Wichtigkeit des Zieldokumentes ermitteln. Hierbei werden wiederum iterativ Links von wichtigeren Dokumenten höher bewertet, als solche von unwichtigeren, seltener zitierten Dokumenten.

Aktuelle Suchmaschinen benutzen immer eine Mischform aus semantischen Techniken, mit denen sie eine Auswahl der zu einer Suchanfrage passenden Webseiten zusammenstellen und einer Ranking Technik, die die Reihenfolge bestimmt, in der die Suchergebnisse angezeigt werden.

Der Firma Google Inc. Gelang es mit einem solchen Bewertungsverfahren, dem PageRank [4], innerhalb kürzester Zeit Marktführer der Suchmaschinen zu werden. Doch auch dieser Algorithmus wird inzwischen von professionellen Spammern getäuscht, etwa durch das Erstellen künstlicher Strukturen von scheinbar unabhängigen Webseiten, so genannten „link farms“, die nur dazu dienen den PageRank, also die Bewertung der Wichtigkeit einer Zielseite zu erhöhen. Seit einigen Jahren kann man eine Art „Wettrüsten“ zwischen den Suchmaschinenbetreibern, die immer neue Formen von Spamfiltern entwickeln, und den Web Spammern, die immer ausgefeiltere Methoden zur Täuschung der Ranking Algorithmen entwickeln, beobachten.

In diesem Bereich muss man die Ausnahmestellung Googles im Markt hervorheben; als Markt- und Technologieführer stellt Google das beliebteste und lukrativste Angriffsziel für Web Spammer dar. Spricht man heute von

(5)

Suchmaschinenoptimierung, so wäre meist der Ausdruck „Google-Optimierung“ angebrachter. Allerdings führen Web Spam-Methoden, die zu einem besseren Ranking bei Google verhelfen meist auch zu einem besseren Ranking bei der Mehrzahl der aktuellen Suchmaschinen.

Um ein Maximum an Wirkung in den Ranking – Verfahren zu erreichen müssen die Spammer die Linkstruktur ihrer Seiten auf bestimmte Arten gestalten. In erster Linie bedeutet dies, die Struktur so zu gestalten, dass der PageRank einer Zielseite maximiert wird. Daher – so unserer Arbeitshypothese - unterscheiden sich diese künstlichen Linkstrukturen von „natürlich gewachsenen“ Netzwerkstrukturen, wie sie durch das übliche fortschreitenden Einsetzen von HTML-Dokumenten im Internet entstehen. Um mathematisch unterscheidbare Kriterien zu erhalten, wird im Rahmen dieser Diplomarbeit, eine Reihe von netzwerktheoretischen Eigenschaften des World Wide Web an archetypischen Beispielen untersucht. Um dies zu bewerkstelligen, wird eine Software entwickelt, die einen Webcrawl durchführen kann, aus den gewonnen Informationen einen Graph aufbaut und diesen analysiert.

Eine Sammlung von Hochschulwebseiten dient als im Vergleich ideelle Struktur mit einer sehr niedrigen Spamdurchdringung, wogegen an Hand eines theoretischen Modells, das auf die oben genannte Maximierung von PageRank angelegt ist, eine Sammlung von für Web Spam typischen Charakteristika gefunden werden soll. Zusätzlich werden diese Ergebnisse, quasi in „freier Wildbahn“, an echtem Web Spam überprüft. Hierzu werden wir Suchergebnisse bedeutender Suchmaschinen zu hart umkämpften Schlüsselwörtern aus dem Bereich der Fort- und Weiterbildung untersuchen und offensichtliche Spamseiten mit unserer Software analysieren.

Mögliche Bereiche für weiterführende Betrachtungen wären die Reiseindustrie, Online Casinos oder Erwachsenenentertainment, welche üblicherweise einen hohen Anteil an Spam enthalten.

Im folgenden werden wir auf die Technik aktueller Suchmaschinen und deren Rankingalgorithmen näher eingehen und einige Grundbegriffe des Web Spammings näher erläutern. Ein weiteres Kapitel wird sich mit den grundlegenden netzwerktheoretischen Eigenschaften des WWW beschäftigen, im Anschluss widmet sich ein Kapitel explizit der Umsetzung verschiedener Analysefunktionen in der Software Heimdall und des Aufbaus der Hilfssoftware JWebSpinner, deren Aufgabe es ist, das angesprochene Web Spam-Modell zu generieren.

Folgerichtig werden wir im anschließenden Kapitel näher auf unsere Testszenarien und die daraus gewonnen Datensätze eingehen. Ausgehend von diesen Datensätzen, erarbeiten wir die unterschiedlichen Charakteristiken des ideellen Webs im Gegensatz zu denen des spambelasteten Webs.

Es folgen Vorschläge zur Entwicklung eines Algorithmus zur Erkennung von Web Spam, so wie eine finale Bewertung der durchgeführten Arbeiten.

(6)

2. Search Engine Technologie und SEO

Bevor wir uns den komplexeren mathematischen Analysemethoden widmen, erfolgt in diesem Kapitel eine kurze Einführung in die Technologie aktueller Suchmaschinen und in den Bereich der Search Engine Optimization, kurz SEO.

2.1 Search Engine Technologie

Suchmaschinen bestehen grundsätzlich aus drei sich in ihrer Funktion unterscheidenden Teilen: (1) einem Web Crawler oder Robot, der automatisch Weblinks folgt, Dokumente und Seiten in einer Datenbank abspeichert (auch Bilder, Videos, etc.); (2) einer logischen Einheit, die aus den gespeicherten Dokumenten einen Index erstellt, der semantisch kategorisierbar ist und zusätzlich eine, heute üblicherweise vom Inhalt der Seiten weitestgehend unbeeinflusste, Bewertung der Wichtigkeit des Dokumentes (Bildes, etc.). Aus einer Kombination der semantischen Relevanz und des, üblicherweise linkstrukturbasierten, Rankings ergibt sich die Stellung einer Seite auf den Resultpages, sofern die Seite zuvor nicht von verschiedenartigen Spamfiltern ausgeschlossen wurde.

Die Resultpage generiert ein Web Service (3) als User-Front-End zu jeder Suchanfrage aus der Datenbank [11].

Das Ziel der Search Engine Optimization, kurz SEO, ist folgerichtig das möglichst hohe Erscheinen einer betreuten Seite auf den Resultpages zu ausgewählten Begriffen, im Jargon als Keywords bezeichnet. Da es für einen Optimierer nicht nur sehr schwierig, sondern auch strafrechtlich relevant wäre, die Suchmaschine durch einen direkten Angriff zu manipulieren, verbleibt für ihn lediglich die Möglichkeit, das Web seinen Bedürfnissen anzupassen. So lange diese Anpassungen auf der eigenen Website des Betreffenden von statten gehen und lediglich dazu führen, dass diese Seite bei relevanten Suchanfragen hoch gelistet werden, so erscheint dies, als erweiterte Technik des Webmastering und Webdesign moralisch unbedenklich und wird auch von Suchmaschinenbetreibern geduldet, so lange dem Websurfer kein anderer Content, als dem Webcrawler vorgespielt wird [29]. Allerdings hat sich im Schatten der Suchmaschinen eine florierende SEO Industrie entwickelt, in der eben auch schwarze Schafe ihr Unwesen treiben, so genannte Web Spammer.

In Übereinstimmung mit Garcia-Molina und Gyöngyi in ihrer Arbeit “Web Spam Taxonomy” [5], definieren wir daher Web Spam, als Webseiten und Strukturen, die Benutzer von Suchmaschinen absichtlich auf Seiten führen sollen, die keinen oder kaum zu Ihrer Suchanfrage relevanten Content enthalten. Allerdings muss berücksichtigt werden, dass Garcia-Molina und Gyöngyi in ihrer Darstellung der Eigenschaften von Web Spam, so weit gehen, dass auch anerkannte Techniken des Webmastering in den Bereich von Web Spam gerückt werden, so etwa die Link Campaign oder das Architecturing der Sitestructure. Da diese Arten von Optimierung aber moralisch und ethisch kaum bedenklich erscheinen und darüber

(7)

hinaus algorithmisch schwerlich determinierbar sein dürften, beschränkt sich die Forschungsarbeit dieser Diplomarbeit auf groß angelegte Linkstrukturen, die die Rankingalgorithmen gängiger Suchmaschinen täuschen sollen.

Eine zu strenge Auslegung der Kriterien von Web Spam auf Seitenoptimierungsstrategien könnte außerdem dazu führen, dass Accessability-und Usability - Optimierungen dem Web Spam zugerechnet werden könnten Accessability-und im Umkehrschluss dazu, dass Webmaster auf diese Techniken verzichten, was wiederum nicht im Interesse des Internetnutzers sein kann.

2.2 Rankingalgorithmen und Web Spam

Doch zurück zu den Suchmaschinen. Der Erfolg der Suchmaschine Google und damit der Erfolg der Rankingalgorithmen PageRank [4] und später auch Trustrank [32] führte dazu, dass viele Wettbewerber ähnliche Rankingmethoden, sogenannte

popularity based algorithms, einführten. Alle Algorithmen dieser Art basieren darauf, aus der Linkstruktur des WWW Informationen über die Wichtigkeit der Webseiten zu erlangen. Alle basieren auf dem Grundprinzip, Dokumenten mit höherer Linkpopularität, und damit einer angenommenen höheren Relevanz im Vergleich zu semantisch ähnlichen Seiten mit weniger in-Links, ein höheres Ranking zuzuweisen.

Will ein Web Spammer diese Algorithmen zu seinem Vorteil ausnutzen, muss er eine Linkstruktur aufbauen, die diese Algorithmen maximal ausbeutet. Hierauf richten wir unsere Forschung aus.

Aufgrund der Markt- und Technologieführerschaft der Suchmaschine Google erscheint es opportun, sich in erster Linie an deren PageRank Algorithmus zu orientieren. Nachforschungen im Milieu der Optimierer und Web Spammer haben ergeben, dass sich diese ohnehin an dieser Suchmaschine orientieren.

Um den PageRank Algorithmus zu täuschen bedienen sich Spammer gerne der Technik sogenannte Link Farms aufzusetzen, deren einziger Zweck darin besteht, die Linkpopularität einer Zielseite zu erhöhen. Doch betrachten wir zuerst einmal das World Wide Web aus den Augen eines Web Spammers. Dieser wird wohl drei verschiedene Arten von Webseiten unterscheiden:

(1)Webseiten, die ihm nicht gehören und auf die er keinen Zugriff hat. Auf diesen Seiten kann er keinen Content verändern und keinen Link platzieren.

(2)Webseiten, die dem Spammer auch nicht gehören, auf denen es ihm jedoch möglich ist, den Content zu verändern und Links zu platzieren.

(Typischerweise wären dies Gästebücher, Foren, offene Directories, Wiki Wiki Websysteme, etc.)

(3)Webseiten, die dem Spammer gehören und über die er die vollständige Kontrolle hat.

(8)

Abbildung 1 zeigt anschaulich, welche Struktur ein Web Spammer aufbauen würde um den PageRank einer Zielseite zu maximieren. Wir verwenden hierbei das Modell aus [5].

Abbildung 1: Link Struktur zum Boosten von PageRank

Die Zielseite t wird in diesem Aufbau eine starke Erhöhung des PageRanks erfahren, da der Spammer den PageRank der für ihn erreichbaren Seiten ausbeutet, und gleichzeitig seine eigenen Seiten dazu benutzt, den PageRank zu verstärken und gleichzeitig ein Absenken durch fehlende ausgehende Links zu verhindern. Obwohl die Suchmaschinen keine detaillierten Ausführungen über das komplexe Zusammenspiel ihrer Einzelalgorithmen veröffentlichen, zeigen aktuelle Forschungsarbeiten [7,8], dass der finale PageRank einer Seite generell auf vier Faktoren beruht und in einer vergleichsweise einfachen Formel ausgedrückt werden kann:

rtotal=rstatic+rin- rout- rsink,

dabei bezeichnet:

rtotal das Ergebnis der Berechnung und damit den PageRank, der der Seite im

Ranking zugewiesen wird,

rstatic einen Anfangswert für die Berechnung, der der Seite zugewiesen wird (Der

random jump aus [4]). Dieser pendelt sich bei den Iterationen des PageRank – Algorithmus auf einen Wert ein, abhängig von der Menge der Seiten.

rinden PageRank, der der Seite durch in-Links zufließt,

routden Verlust von PageRank der Seite über out-Links,

rsink den Verlust von PageRank durch sogenannte Sink Pages, also Pages, ohne

ausgehende Links.

Suchmaschinenoptimierer [9] und in besonderem Maße Web Spammer haben diese Formel quasi verinnerlicht und benutzen PageRank Rechner wie [10] oder ähnliche Tools, um Strategien für “die optimale” Linkstruktur aufzubauen.

(9)

Da ein Spammer nicht beliebig über fremde Seiten im Netz gebieten kann, ist er darauf angewiesen, selbst verlinkte Strukturen aufzubauen. Gerade im schnelllebigen Geschäft des Spammings ist das Aufbauen genügend großer Strukturen nur mit automatisierten Tools möglich. Innerhalb dieser Diplomarbeit soll aufgezeigt werden, dass sich diese automatisch generierten Strukturen ebenso automatisch erkennen lassen, Dazu wird das nächste Kapitel zuerst einmal allgemein die netzwerktheoretischen Eigenschaften des World Wide Web aufzeigen.

2.3 Geschäftsmodelle des SEO

Was veranlasst einen Suchmaschinenoptimierer überhaupt, Web Spamming zu betreiben? - Gerade auf dem britischen und amerikanischen Markt ist die Konkurrenz unter den Optimierern groß – entsprechend vielfältig fallen die Motivationen der Optimierer aus. Generell kann man davon ausgehen, das Web Spam kurzfristig hohen Erfolg durch vertretbare Investitionen sichert. Allerdings besteht jederzeit die Gefahr, dass ein neuer Spamfilter, oder auch ein menschlicher Editor, bei den großen Suchmaschinen den Web Spam identifiziert und die Seite aus den Suchergebnissen verbannt wird. Einsetzen von Web Spam kann also schnell zu hohen Besucherzuwächsen führen, birgt allerdings auch immer das Risiko der Entdeckung und Sanktion.

Betrachtet man den Markt der Suchmaschinenoptimierer, kann man in etwa drei verschiedene Gruppen unterscheiden. Die erste Gruppe versucht durch die Weitervermittlung von Kunden an andere Anbieter Provisionen zu verdienen. Das funktioniert entweder durch „affiliate networks“, beispielsweise das Verkaufen von Büchern, die der Optimierer auf der eigenen Seite bewirbt, über Amazon, oder mit „pay per click“ einfach für das Weiterleiten der Websurfer auf eine zahlende Zielseite, der Optimierer verdient dabei an jedem Anklicken eines externen Links; oder über „pay per view“, hier verdient der Optimierer an jedem Websurfer, der seine Seite und damit die Werbung eines Dritten lädt. In diesen Bereichen treffen wir oft auf Web Spam, da Seiten hier problemlos geopfert und durch neue ersetzt werden können, wenn ein neuer Spamfilter die alten aus den Suchergebnissen ausschließt.

Die zweite Gruppe besteht meist aus Webmastern, die Methoden des SEO benutzen, um ihre eigene Website zu promoten. Hinter dieser Gruppen können ganz unterschiedliche Geschäftsmodelle stecken, vom freiberuflichen Fotograf, bis hin zum Delikatessen Webshop – meist geht es aber darum Kunden für die eigenen Webauftritte zu gewinnen. Web Spam Methoden verwenden diese Leute meist eher aus Unwissenheit, da sie üblicherweise auf die Einnahmen aus ihren Geschäftsmodellen angewiesen sind und das Risiko eines Banns durch die Suchmaschinen nicht tragen können.

Schließlich gibt es noch die Gruppe der professionellen Optimierer, die im Auftrag ihrer Kunden eine Website promoten. Diese Gruppe arbeitet meist mit den ausgefeiltesten Methoden, oft langfristig planend und selten mit kurzlebigen Spammethoden, aber aufgrund des Konkurrenzdrucks in der Branche gibt es auch hier schwarze Schafe, die Spamming betreiben.

(10)

3. Charakteristiken des World Wide Web aufgrund seiner

Graphstruktur

In den vergangen Jahren erlebt die mathematische Graphentheorie eine kleine Renaissance und damit gab es auch verschiedenste Ansätze, das Web in seinen netzwerktheoretischen Eigenschaften zu beschreiben. [1, 2, 3]

Eine essentielle Eigenschaft von HTML Dokumenten ist ihre Referenzierung mittels Hyperlinks. Diese Eigenschaft ermöglicht es, über Links verbundene HTML Dokumente als einen Graphen im Sinne der Netzwerktheorie zu betrachten. In diesem Fall spricht man von den Dokumenten als Ecken (engl. vertex) und den Hyperlinks als Kanten (engl. edge). Entsprechend bildet das World Wide Web einen gerichteten Graphen gigantischen Ausmaßes.

Um die Eindeutigkeit der Begriffe zu wahren und eine bessere Vergleichbarkeit mit englischsprachigen Publikationen zu ermöglichen, werden wir die Begriffe aus der Netzwerktheorie entsprechend der angloamerikanischen Nomenklatur verwenden.

Wie oben bereits erwähnt werden im Weiteren vertices (webpages) und directed edges (Links) und deren Beziehungen untereinander behandelt. Sollte es sich bei einer edge, um eine undirected edge handeln, so wird dies eindeutig im Text vermerkt sein.

3.1 Clustering

Von besonderem Interesse bei der Betrachtung des www als Netzwerk ist das Vorkommen so genannter Cluster. Cluster entstehen, wenn in einem Graphen die erhöhte Wahrscheinlichkeit besteht, dass eine vertex v1- die mit einer vertex v2 verbunden ist, welche wiederum mit einer vertex v3 verbunden ist - ebenfalls mit v3 verbunden ist. Um diese Wahrscheinlichkeit bestimmen zu können, bildet man den Clustering Koeffizienten,clustering coefficient C:

(1)

Eine alternative Definition des clustering coefficient von Watts und Strogatz benutzt [14] einen lokalen Wert, bezogen auf eine vertex vi.

(2)

(11)

Sollte dabei die betrachtete vertex i vom Grad 0 oder 1 sein, so wird Ci = 0 gesetzt. Entsprechend lässt sich auch hiermit ein clustering coefficient für das gesamte Netzwerk ermitteln:

(3)

Allerdings muss man an dieser Stelle anmerken, dass obige Definition Werte hervorbringt, die von den Ergebnissen der erst genannten signifikant abweichen. Das liegt daran, dass vertices von niedrigerem Grad hier wesentlich stärker ins Gewicht fallen, da diese kleinere Werte im Nenner aufweisen. Trotzdem ist diese Art der Berechnung heute die häufiger verwandte, nicht zuletzt, da sie sich gut für eine Berechnung im Computer eignet. Entsprechend wird sie auch in dieser Diplomarbeit benutzt. Die Beispielrechnung zum Graph in Abbildung 2 verdeutlicht noch einmal die Unterschiede der Berechnungsmethoden.

Abb. 2 Beispiel -clustering coefficient

Der Graph in Abbildung 2 stellt ein Netzwerk aus 5 vertices, die 8 Tripel und ein Dreieck bilden dar. Entsprechend obiger Gleichungen ergeben sich folgende Werte für denclustering coefficient:

C1:

(12)

C2:

C3:

Bildet man den clustering coefficient eines webgraph, so erhält man einen Wert, der einem Auskunft darüber gibt, wie stark die einzelnen Webpages über Verlinkungen miteinander in Gruppen verbunden sind. Einzelne vertices mit einem hohen lokalen clustering coefficient können als populäre Seite im Sinne der Ranking Algorithmen angesehen werden. Wie erwähnt benutzen wir zur Berechnung des lokalen clustering coefficient die Gleichung 2, entsprechend für den globalen clustering coefficient die Gleichung 3.

3.2 Degree Distribution

Die Degree Distribution beschreibt die Verteilung der degrees über die vertices des Graphen. Der degree, im Deutschen Grad, einer vertex ist ein Wert gleich der Summe der edges, die mit dieser verbunden sind. Bei directed edges kann man zusätzlich zwischen indegree und outdegree unterscheiden, wobei der indegree gleich der Anzahl der auf die vertex gerichteten Edges ist und der outdegree gleich der Anzahl der aus ihr heraus zeigenden. Aus der Verteilung der degrees ergibt sich auch die Wahrscheinlichkeit, mit der 2 beliebigevertices eines Graphen eine gemeinsameedgeaufweisen.

Wir definieren pk als Teilmenge der vertices eines Netzwerkes mit degree k. Entsprechend drückt pkdie Wahrscheinlichkeit aus, dass eine zufällig ausgewählte vertexaus dem Netzwerk einendegreevon k aufweist.

Fertigt man ein Balkendiagramm der degree-Werte jedervertexeines Netzwerkes an, so erhält man die Verteilung der Werte, die degree distribution. Während degree distributions in random graphs [15, 16, 17] binominale oder Poisson Verteilungen aufweisen, trifft dies für natürliche Netzwerke, zu denen man auch das World Wide Web zählt, nicht zu. Betrachtet man deren Histogramme, erkennt man eine stark abgeflachte Kurve, da es bei ihren degrees immer einige, wenige Extremwerte gibt. Abbildung 3 zeigt ein einfaches Histogramm einer degree distribution eines natürlichen Netzwerkes.

(13)

Abb. 3 einfaches Histogramm einer degree distribution

Eine weitere Möglichkeit zur Analyse besteht darin, die degree distributions von Clustern, anstelle von ganzen Graphen zu vergleichen. Zu einem Cluster zählt man in diesem Fall alle vertices des Graphen, deren clustering coefficient in einem bestimmten Bereich liegen und die nicht zu viele Kantensprünge voneinander entfernt sind. Nachdem man einzelne Cluster ausfindig gemacht hat, lässt sich beispielsweise auch überprüfen, wie viele Links aus dem Cluster heraus (outdegree), bzw. in den Cluster hinein (indegree) führen.

3.3 Degree Correlations

Die degree correlations beschreiben die Beziehung verschiedener vertices zueinander, unter Betrachtung ihres degrees. Also beispielsweise ob sich vertices von hohem degree eher mit ebensolchen oder mit welchen, die einen niedrigeren aufweisen, verbinden. Gerade in Spamnetzwerken, die eine Seite pushen wollen könnten auffällige Beziehungen bestehen. Neben einem Ansatz von Maslovet al., diese Beziehungen durch Projektionen in ein zweidimensionales Histogramm zu analysieren [18, 19], kalkulierten Pastor-Satorraset al. [20, 21] mit Bezug auf das Internet die mean degree benachbarter vertices einer vertex des Netzwerkes als eine Funktion desdegrees kdieservertex.

Das Ergebnis lässt sich bis auf eine einzelne Zahl herab kalkulieren, beispielsweise durch das Berechnen desPearson correlation coefficientan beiden Enden einer edge. [22, 23] Man erhält also eine Art Edge – degree. Allerdings werden wir in dieser Arbeit auf dieses spezielle Modell nicht eingehen, da wir auf gewichtete edges verzichten. In einer möglichen Fortführung dieser Forschungsarbeit mag sich in solchen Beziehungen aber durchaus noch Potential verbergen, daher wurde sie hiermit erwähnt.

(14)

3.4 Betweenness Centrality

Die Anzahl der geodesic pathes zwischen allen anderen vertices, die durch eine dritte vertex i verlaufen, bezeichnet man alsBetweenness Centrality BCdervertex i. [24]

Eingeodesic path ist der kürzeste Weg (Weg mit den wenigstenedges) von einer vertexzu einer anderen, wobei es oft mehr als einen geodesic path zwischen zwei vertices gibt. Der geodesic path wird in der Literatur auch oft als shortest path bezeichnet, oder kurz als dij.

Diebetweenness centrality ist ein lokaler Wert, der auf eine vertexbezogen wird. Entsprechend der Definition [24] betrachtet man die Anzahl dergeodesic pathesC (i,j) zwischen 2verticesi, j. Weiterhin betrachtet man auch die Anzahl derjenigen geodesic patheszwischen i und j, die durch einevertexk verlaufen Ck(i,j). Daraus lässt sich wiederum ein Wert gk(i,j) berechnen mit

gk(i,j)=Ck(i,j)/C(i,j). Schließlich definiert man damit die betweenness centrality BC für k als Summe von gk(i,j) aller Vertexpaare mit einem geodesic path, BC=gk:

Die Betweenness Centrality eignet sich ähnlich dem PageRank auch als Ranking Algorithmus, da er Vertices, durch die viele shortest pathes zu anderen vertices verlaufen, einen hohen BC–Wert zuordnet. Somit zeigt dieser Wert die Wichtigkeit der Vertex als Verbindung zwischen anderen an. Ein Grundproblem eines solchen Ranking Algorithmus ist allerdings der hohe Rechenaufwand zum Berechnen der shortest pathes.

3.5 Efficiency

Latora und Marchiori [25] schlagen vor, ein Netzwerk anhand eines Effizienzfaktors zu bewerten, der efficiency of a network. Dieser Wert soll die Effizienz der Kommunikation zwischen denverticesrepräsentieren. Sie definieren die Efficiency über die harmonic mean distance zwischen einer vertex und jeder anderen innerhalb des Graphen und beschreiben entsprechend die efficiency einer Verbindung zwischen 2 vertices i und j als invers-proportional zum shortest path di,j:

Falls überhaupt keine Verbindung zwischen i und j bestehen sollte, dann gilt für dij = +∞ und entsprechend

(15)

Small World – Netzwerke [14] erweisen sich übrigens sowohl auf globaler, als auch auf lokaler Ebene als sehr efficient.

3.6 Lower Order Clustering Coefficient oder Reciprocity

Gerade bei einer Graphdarstellung des World Wide Web, das ja einen directed graph bildet, liegt das Vorkommen von reziproken Verbindungen, also Schleifen der Länge 2, zwischen den Dokumenten nahe, diesereciprocal edgeswerden beim www auch als link und backlink oder einfach colinks [26] bezeichnet. In der Literatur wählt man auch oft die englische Bezeichnung loops und daher das Zeichen L, bzw. l(v) für die Menge aller Loops, die mit einer Vertex v verbunden sind. In Übereinstimmung mit dem clustering coefficient, der bekanntlich die Schleifendichte an Tripeln aufzeigt, bezeichnet man die Schleifendichte für Schleifen der Länge 2 als lower order clustering coefficientoder eben reciprocity des Graphen.

Rv := |l(v)|

Im weiteren Verlauf der Arbeit werden wir sehen, dass gerade der reciprocity beim Erkennen von Web Spam eine besondere Bedeutung zukommt, macht doch gerade sie eine eindeutige Aussage über den Grad der seitenübergreifenden Verlinkung.

3.7 Diameter

Der diameter , also Durchmesser, eines Graphen ist die Länge der kürzesten Strecke zwischen den beiden am weitesten voneinander entfernten vertices, also der längste geodesic path.

DG= max(dij)

Als absolute Größe betrachtet, hat der Diameter wenig Aussagekraft beim Vergleich verschiedener Graphen. Setzt man ihn allerdings in Relation zu anderen Werten, wie etwa der Menge der Vertices und Edges oder der Average Minimum Path Length (siehe 3.8), dann können wir daraus Rückschlüsse auf die Anatomie des Graphen ziehen. Ein interessanter Punkt könnte auch die Abschätzung des Diameters im Vergleich zu den nächst kürzeren Geodesic Pathes sein, in der Art einer Geodesic Path Distribution – allerdings werden wir auch hierauf in dieser Arbeit nicht mehr näher eingehen können.

3.8 Average Minimum Path Length

Die Average Minimum Path Length tritt häufig in Betrachtungen so genannter „Small – World - Networks“ [14] auf. Es handelt sich dabei um die Länge der geodesic pathes in einem Graphen über alle Vertexpaare gemittelt.

(16)

Interessant an diesem Wert ist, dass er anzeigt, über wie viele Sprünge durchschnittlich jede Vertex mit jeder anderen im Graphen verbunden ist. Berühmtheit erlangten Betrachtungen dieser Art übrigens durch Milgrams Arbeit „The Small World Problem“ [34].

(17)

4. Umsetzung in JAVA

Im Rahmen früherer Projekte entstand an der Fachhochschule eine Sammlung von JAVA Klassen, um grundlegende Aufgaben im Bereich des Information Architecture, programmiertechnisch zu lösen [30]. Leider zeigte sich im Laufe der Bearbeitung dieser Diplomarbeit, dass eine Neuordnung der Struktur und damit erste Schritte in Richtung Aufbau eines richtigen Frameworks nötig waren.

4.1 VALHALLA Framework

Im folgenden wird der Aufbau des VALHALLA Information Architecture Frameworks, wie er zu Beginn des Projektes vorgefunden wurde skizziert.

1. Webcrawler and basic Analyzerodin • packageodin.data

• Imagedata.java(class for an image-object (name, alt, url)) • Linkdata.java(class for an link-object (text, anchor, url,...)) • OdinVector.java(standard Vector with sort algorithms) • SpiderData.java(data collection of the whole crawl) • WordCounterData.java(class for WordCounter data) • packageodin.frames (GUI)

• ImageDetailFrame.java • infoFrame.java

• OdinAboutBox.java • OdinMainFrame.java • URLDetailFrame.java • packageodin.threads

• ImageCheckThread.java(check Server Header for image-links) • SpiderConnThread.java(grab HTML from given URL)

• SpiderParseThread.java(parses HTML) • packageodin.tools

• ColoredTableCellRenderer.java(GUI) • ColoredTableModel.java(GUI) • ColoredTreeCellRenderer.java(GUI)

• ConnectionTools.java(Http Connection functions)

• Html2Text.java(remove tags -> output: Content as String) • ImageTools.java(prints image width and heights to command

line)

• ParserTools.java(functions to get data out of HTML (metas,

title, links, text,...))

• SpiderParserTools.java(functions to get data out of an crawled

URL (images, frame-links, links))

• TableMap.java(GUI) • TableSorter.java(GUI) • TableTools.java(GUI)

• TreeTools.java(builds tree structure of link relations / GUI)

(18)

• classOdin.java(main-class, GUI starter) • classSiteSpider.java(crawl process controller)

2. SearchEngine Connectorprchecker

• Alltheweb.java(Requesting BackLinks, How often is the Site listed,...) • BrowserLexer.java(locally opens Browserwindow)

• BrowserOpener.java(locally opens Browserwindow) • Citeseer.java(requesting citeseer for number of query)

• ClearTitles.java(unescape HTML-special characters to unicode) • DateTools.java(input: Sting date, output: JAVA date)

• Dmoz2univ.java(requesting DMOZ for .edu Domains putting them into

Oracle DB)

• FillDatabaseWitchContent.java(Main Class, requesting google for

universities info, putting them into Oracle DB)

• Findaschool_Parser.java(requesting findaschool for universities,

feeding Oracle DB)

• Google.java(Requesting BackLinks, How often is the Site listed, and

more...)

• PRChecker.java(old method for PR Checking, using local Browser) • PRCheckerThread.java(old method for PR Checking, using local

Browser)

• UniversityParser.java(like findaschool.java, for other URL) • URLTools.java(de-and encode URLs)

• Whois.java(JAVA whois-function)

• WhoisEDU.java(JAVA whois-function for edu Domains)

3. DMOZ RDF Parser, Feeding Oracle DB and Access to Oracle DBthor • DmozDatabaseTool.java(writing DMOZ RDF Dump into Oracle DB) • DmozQuery.java(Requesting DMOZ in Oracle DB)

• DmozRdfParser.java(Analysis of the RDF Dump)

4. future server component for the packagevalhalla • Valhalla.java(base to future changes)

• ValhallaThread.java(base to future changes)

5. unterstützendeexterne Klassen

• packagecern.colt.*(mathematical numbers and functions) • packagecorejava

• Format.java(for C-like number formatting that follows ''printf''

conventions)

• packageedu.uci.ics.jung(graph analysis classes) • packagehep.aida.*(for Drawing of Histograms)

• packageorg.apache.commons.collections.*(superior collection classes

for big data sets)

6. Server Surveillance and basic Logfile Analyzersg(currently uncontinued)

Die Grundidee bei der Ursprünglichen Konzeption des Valhalla-Frameworks bestand darin, eine Toolsammlung zu bauen, die in einzelnen Programmen wie Odin oder Thor läuft. Je nach gewünschter Anwendung startet man dabei eines der Programme, durch die jeweilige Hauptklasse des Paketes. Trotzdem benutzen die einzelnen Programme Klassen und Funktionen paketübergreifend.

(19)

Leider ist diese Struktur nicht konsequent durch das gesamte Framework implementiert. Auch die Trennung zwischen Anwendungsfunktionen und Benutzeroberfläche sind teilweise aufgelöst. Schließlich sind weite Passagen des Quelltextes nicht oder unvollständig kommentiert.

4.2 HEIMDALL

Unabhängig davon würde eine komplette Überarbeitung der Struktur allein eine Diplomarbeit ausfüllen. Also wurde für diese Arbeit ein Kompromiss eingegangen: Die Graphanalysekomponenten werden über ein neues Programm/Paket “Heimdall” nachgerüstet.

Notwendige Funktionsaufrufe in andere Klassen werden, falls die Funktionen konsequent implementiert sind, einfach benutzt. Falls dies jedoch nicht der zutrifft, werden die Funktionen in den früheren Paketen an passender Stelle implementiert und kommentiert.

Dadurch mag teilweise doppelter Code entstehen, aber die älteren Programme bleiben lauffähig und es wird eine solide Basis für eine zukünftige Konsolidierung des Quellcodes gelegt.

Im folgenden ist der Aufbau des Paketes Heimdall dargestellt, entsprechend des obigen Codelistings als Punkt 7:

7. Graph AnalyzerHeimdall • package heimdall.data

• HeimdallGraph.java (erweiterte DirectedSparseGraph

Datenklasse)

• Heimdallvertex.java (erweiterte DirectedSparsevertex

Datenklasse)

• HeimdallGraphMetaData.java (Datenklasse, die verschiedenste

Informationen über den Graph speichert)

• package heimdall.frames

• HeimdallMainframe.java (GUI) • package heimdall.io

• FileWriter.java (schreibt Textfiles lokal auf die Festplatte) • package heimdall.tools (Funktionsaufrufe der tool-Klassen wird weiter

unten ausführlich beschrieben)

• package heimdall.tools.filters

• XMLFileFilter.java (dient der Filterung des XML File

Typus im FileChooser Dialog)

• HeimdallAverageMinimumPathLength.java (berechnet die

durchschnittliche Länge der shortest pathes im Graph)

• HeimdallBetweennessCentrality.java (berechnet die lokale

Betweenness Centrality einer vertex im Graph)

• HeimdallClusterAnalysis.java (Berechnet den clustering

coefficient)

• HeimdallDegreeCorrelation.java (unvollständig implementiert)

(20)

• HeimdallDegreeDistribution.java (berechnet die degree

disribution im Graph)

• HeimdallRanker.java (erstellt PageRank und Betweenness

Centrality Ranking für alle vertices des Graphen)

• HeimdallGraphDiameter.java (berechnet den Diameter des

Graphen)

• HeimdallGraphEfficiency.java (berechnet die Efficiency) • HeimdallGraphReciprocity.java (berechnet die reciprocity) • HeimdallShortestPath.java (berechnet die Shortest Pathes für

jedes vertexpaar des Graphen)

• Heimdall.java (Hauptklasse, startet das Programm)

Nach dieser ersten Analyse, drängt sich die Frage nach einer Lösung der oben genannten Codedesign Probleme auf. Um einerseits die Arbeitsfähigkeit der vorhandenen Tools zu gewährleisten aber andererseits langfristig eine Trennung des Codes nach Funktionalitäten zu ermöglichen, wurde ein neues Package eingefügt. Das Package Crawler, das zwar redundant Funktionen des Packages Odin wieder implementiert, jedoch sauber von der GUI getrennt. In einer späteren Phase der Code Revision kann auch Odin soweit umgeschrieben werden, um Funktionen aus Crawler zu benutzen. Es folgt eine schematische Darstellung des Packages Crawler:

8. Crawling Component Crawler

• SiteSpider.java

• SpiderConnThread.java • SpiderParserTools.java • SpiderParseThread.java

Der ursprüngliche Code von Sven Wagenhöfer und Frédèrik Thiele wurde im Laufe dieser Diplomarbeit stark modifiziert. Neben dem Entfernen der

eingewobenen GUI, ruft der Crawler auch direkt Methoden aus dem Heimdall-Package auf, um den Graph aufzubauen. Lediglich in den Grundfunktionen des Crawlens entspricht der Code noch weitgehend der ursprünglichen Version. Da es schwierig wäre, die Analysefunktionen, die im Rahmen dieser Arbeit entwickelt werden, in einem “nackten” Framework zu testen, war es unerlässlich eine Testsoftware zu entwickeln. Diese “Heimdall” - Software bietet bequemen Zugriff auf die neuen Funktionen des Heimdall – Packages über eine JAVA -Swing Oberfläche.

(21)

4.3 Testumgebung

Um den neuen Code zu testen, wurde im Labor ein Webserver aufgesetzt, auf dem zunächst eine sehr einfache Website abgelegt war. In Abbildung 3 ist die Seite als Graph dargestellt.

Die Kreise repräsentieren die vertices, in diesem Fall HTML – Dokumente und die Pfeile die edges, hier Hyperlinks.

Abbildung 3 – Testsite

Diese überschaubare Graphstruktur ermöglicht das manuelle Nachvollziehen der Programmschritte. Entsprechend ist es möglich bereits anhand dieser Struktur die neue Crawler Implementierung durch eine Ausgabe auf der Kommandozeile zu testen:

Site spidering started.

http://balder.ds.fh-kl.de/~admin/index.html linkt auf: http://balder.ds.fh-kl.de/~admin/v2.html

http://balder.ds.fh-kl.de/~admin/index.html

kl.de/~admin/v2.html linkt auf: http://balder.ds.fh-kl.de/~admin/v3.html

http://balder.ds.fh-kl.de/~admin/v2.html

http://balder.ds.fh-kl.de/~admin/v5.html http://balder.ds.fh-kl.de/~admin/index.html

(22)

http://balder.ds.fh-kl.de/~admin/v8.html spidering ended

Diese Ausgabe zeigt, dass sowohl alle HTML-Dokumente erfasst, als auch deren Links erkannt wurden. Im nächsten Schritt wird anhand dieser Informationen ein Graph aufgebaut. Auch hier dient die Kommandozeilenausgabe als Kontrolle.

Site spidering started.

spidering ended

Heimdall found the following edges:

E0(V0,V1)http://balder.ds.fh-kl.de/~admin/index.html -> http://balder.ds.fh-kl.de/~admin/v2.html

E1(V1,V2)kl.de/~admin/v2.html -> http://balder.ds.fh-kl.de/~admin/v3.html

E2(V0,V2)http://balder.ds.fh-kl.de/~admin/index.html -> http://balder.ds.fh-kl.de/~admin/v3.html

Das Ergebnis zeigt anschaulich, dass alle Links des testgraph gefunden wurden und alle Beziehungen richtig in die Graphstruktur der Software übernommen. Die in der Testsoftware implementierte Visualisierung zeigt dies auf anschauliche Weise. (siehe Abb. 4)

Heimdall bietet auch die Möglichkeit, einen Snapshot der Visualisierung als JPEG–Datei zu speichern.

(23)

Abbildung 4 – Screenshot der Visualisierung mit Heimdall

4.4 GraphML

Für die weitere Bearbeitung und Analyse des webgraph ist es unerlässlich eine zuverlässige Speicherstruktur für diesen bereitzustellen. Um eine Interoperabilität mit anderen Softwaretools zu erreichen, wurde das XML Format “GraphML” [13] gewählt. In der GraphML Schreibweise kann ein einfacher Graph so aussehen:

<?xml version="1.0" encoding="UTF-8"?>

<graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns

http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> <graph id="G" edgedefault="directed">

</graphml>

Bevor wir auf die einzelnen Elemente des obigen XML – Dokumentes genauer eingehen, lenken wir unser Augenmerk auf den beschriebenen Graphen G: Dabei handelt es sich um einen Graphen mit 4 vertices n0 – n3 und 4 edges, sowie deren Verknüpfungen miteinander, nämlich n0 und n1 mit n2, n2 mit n3 und n3

(24)

wiederum mit n1. Außerdem können wir dem Dokument entnehmen, dass es sich bei dem beschriebenen Graphen G um einen directed Graph handelt.

In einem komplexeren Beispiel werden wir zeigen, wie weitere Informationen in einem GraphML – Dokument untergebracht werden, nun werfen wir zuerst noch einen Blick auf die einzelnen Elemente des Dokuments und beginnen folgerichtig mit dem Header:

Obige Zeile definiert, dass es sich bei dem nachfolgenden Dokument um ein nach UTF-8 Standard kodiertes XML 1.0 Dokument handelt. UTF-8 ist das Standard Encoding für XML – Dokumente.

Die zweite Zeile enthält das root-element eines GraphML Dokumentes, eben das

<graphml element. Genau wie alle anderen GraphML – Elemente gehört dieses

zum danach angegebenen namespace

http://graphml.graphdrawing.org/xmlns, entsprechend wird der

namespace durch das XML Attribut

xmlns="http://graphml.graphdrawing.org/xmlns" angegeben. Es

folgen noch zwei weitere XML – Elemente nach, um das XML Schema zu spezifizieren: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" definiert xsi als XML Schema namespace. Das zweite Attribut xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns

http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"

definiert den Ort des XML Schemas für alle Elemente des GraphML namespaces.

Die hierauf folgende Beschreibung des Graphen, wird durch das graph – Element

<graph> denotiert. Innerhalb des graph – Elementes werden die vertices und

edges deklariert. Eine vertex wird mit einem <node> Element, eine edge mit

einem <edge> Element deklariert. Die Elemente source="x" target="y"

innerhalb des edge – Elementes geben die Ausgangs- bzw. Zielvertex der edge an. Da in einem GraphML – Graph sowohl directed als auch undirected edges vorkommen können, wird innerhalb des edge – Elementes die direction folgendermaßen angegeben: directed=”true” bzw. directed=”false”.

Liegt keine Deklaration dieser Art vor, wird für die edge die edgedefault

-Deklaration des Graphen angenommen.

Das XML Attributid, das bei den Nodes als obligatorischer Identifier dient, kann

optional auch auf den Graphen oder die edges angewendet werden.

(25)

Neben diesen grundsätzlichen Elementen gibt es weitere GraphML – Attribute, die in einem entsprechenden XML – Dokument benutzt werden dürfen. Wir betrachten dazu folgendes, etwas komplexeres Beispiel.

<graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns

http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> <key id="d0" for="node" attr.name="color" attr.type="string">

<default>yellow</default> </key>

<node id="n0"> <data key="d0">green</data> </node> <node id="n1"/> <node id="n2"> <data key="d0">blue</data> </node> <node id="n3"> <data key="d0">red</data> </node> <node id="n4"/> <node id="n5"> <data key="d0">turquoise</data> </node>

</edge>

</graph> </graphml>

Wir sehen, das weitere Elemente hinzugekommen sind: Allgemein werden GraphML - Attribute durch ein key element, dasidentifier,name,typeunddomain

des Attributs spezifiziert, definiert.

Der Identifier wird mit Hilfe des XML - Attributs id spezifiziert und wird genutzt, um eine Beziehung zu einem GraphML - Attribut innerhalb des Dokumentes herzustellen.

Während der name des Attributs durch das XML - Attribut attr.name spezifiziert wird und unique sein muss im Bezug auf alle GraphML – Attribute, die in dem Dokument deklariert werden. Mit Hilfe des name – Attributs können Applikationen die Bedeutung des Attributs erschließen. Deshalb wird der name des Attributs innerhalb des Dokumentes auch nicht mehr benutzt, sondern nur noch der identifier.

(26)

Der type des GraphML – Attributs kann verschiedene Typen darstellen, nämlich: boolean, int, long, float, double oder string. Diese Datentypen entsprechen ihren Äquivalenten in der the Java - Programmiersprache.

Die domain des GraphML – Attributs spezifiziert, für welche Graph Elemente das GraphML - Attribute deklariert ist. Möglich wären hier etwa: graph, node, edge oder all. Die Deklaration eines GraphML – Attributs sieht dann folgendermaßen aus:

Des weiteren ist es möglich einen default – Wert für das Attribut zu deklarieren:

<default>yellow</default> </key>

Möchte man dann einem GraphML – Attribut einen Wert zuweisen, so benutzt man dazu ein data – Element, eingebettet innerhalb des entsprechenden Graph-Elementes.

</edge>

Natürlich muss der darin deklarierte Wert dem type entsprechen, der in der korrespondierenden key Definition angegeben wurde.

Die Testsoftware Heimdall implementiert als zusätzlichen Datenwert zu jeder vertex eine URL, die der URL des HTML – Dokumentes entspricht, die sie repräsentiert. Entsprechend stellt sich eine GraphML – Repräsentation der Testsite dar:

<graphml xmlns="http://graphml.graphdrawing.org/xmlns/graphml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns/graphml" >

<key id="url" for="node" attr.name="url" attr.type="string"></key> <graph edgedefault="directed"

StringLabeller.LabelDefaultKey="edu.uci.ics.jung.graph.decorators.

StringLabeller@4d556e" >

<data key=”url”>http://balder.ds.fh-kl.de/~admin/v8.html <data/>

</node>

(27)

<data key=”url”>http://balder.ds.fh-kl.de/~admin/index.html

<data/>

</graphml>

Alle relevanten Informationen aus dem Crawl werden also in der GraphML – Darstellung wiedergegeben.

Durch diese Funktionen sind wir nun in der Lage, einen Crawl durchzuführen, aus den daraus gewonnenen Daten einen gerichteten Graphen im Sinne der Netzwerktheorie aufzubauen und diesen in einem nichtflüchtigen Format zu speichern. Nun ist es an der Zeit, diese Daten zu analysieren, um Erkenntnisse über die im Crawl erfassten Daten zu gewinnen. Deshalb soll der gespeicherte Graph auf die Charakteristiken hin untersucht werden, die im vorherigen Kapitel aufgeführt wurden.

4.5 Umsetzung der netzwerktheoretischen Funktionen

Beginnen wir mit dem Shortest Path. Die Klasse HeimdallShortestPath.java wird mit einem Graphen aufgerufen und berechnet daraufhin die Länge des Shortest Path für jedes vertexpair innerhalb des Graphen. In unserem Beispiel sieht das folgendermaßen aus:

Shortest Path from http://balder.ds.fh-kl.de/~admin/v8.html to http://balder.ds.fh-kl.de/~admin/v5.html

2.0

4.0

null

1.0

(28)

3.0

Shortest Path from http://balder.ds.fh-kl.de/~admin/v8.html to http://balder.ds.fh-kl.de/~admin/index.html

null

3.0

2.0

[...]

Shortest Path from http://balder.ds.fh-kl.de/~admin/index.html to http://balder.ds.fh-kl.de/~admin/v6.html

4.0

1.0

6.0

1.0

3.0

Übersichtlicher ist jedoch die Darstellung in einer Matrix. Die Werte innerhalb der Matrix repräsentieren die Länge des Shortest Path von der Ausgangsvertex (Zeile) zur Zielvertex (Spalte).

Der Graph hat 8 vertices 8 x 8 matrix

1 2 3 4 5 6 7 8 ____________________

1 |0 3 1 6 1 4 2 5 2 |0 0 1 3 0 1 2 2 3 |0 2 0 5 0 3 1 4 4 |0 0 0 0 0 0 0 0 5 |0 3 1 6 0 4 2 5 6 |0 4 2 2 0 0 3 1 7 |0 1 2 4 0 2 0 3 8 |0 3 1 1 0 4 2 0

8 ist http://balder.ds.fh-kl.de/~admin/v8.html 7 ist http://balder.ds.fh-kl.de/~admin/v5.html 6 ist http://balder.ds.fh-kl.de/~admin/v6.html 5 ist http://balder.ds.fh-kl.de/~admin/v2.html 4 ist http://balder.ds.fh-kl.de/~admin/v7.html 3 ist http://balder.ds.fh-kl.de/~admin/v3.html 2 ist http://balder.ds.fh-kl.de/~admin/v4.html 1 ist http://balder.ds.fh-kl.de/~admin/index.html

Entsprechend berechnet die Klasse HeimdallBetweennessCentrality.java aus einem Graphen die Betweenness Centrality jeder einzelnen vertex. In unserem Beispiel entsteht dabei das folgende Bild:

(29)

Rank 1: 16.000000 vertex Id: 6 (http://balder.ds.fh-kl.de/~admin/v3.html)

Rank 5: 9.000000 vertex Id: 1

(http://balder.ds.fh-kl.de/~admin/v8.html)

(http://balder.ds.fh-kl.de/~admin/index.html)

Die Zahl hinter dem “Rank” gibt hierbei die Betweenness Centrality der vertex an, als die Anzahl der geodesischen Pfade, die durch die vertex verlaufen.

Etwas umfangreicher präsentiert sich da schon die Klasse

HeimdallDegreeDistribution.java, die verschiedene Werte der degree distribution innerhalb eines Graphen berechnen kann. So lässt sich etwa getrennt die in- und outdegree Distribution berechnen, oder ein Ranking der vertices nach Degree erstellen:

(http://balder.ds.fh-kl.de/~admin/index.html) Total: 1.000000

Die Klasse HeimdallGraphDiameter.java wird ebenfalls mit einem

HeimdallGraphen als Argument aufgerufen und gibt als double-Wert die Länge des shortest path zwischen den beiden am weitesten entfernten vertices des Graphen zurück, also den Diameter des Graphen. In der Kommandozeile kann man sich das Ergebnis entsprechend ausgeben lassen:

Der Diameter des Graphen beträgt: 6.0

Die Heimdallsoftware ermittelt aus der Shortest Path Matrix den längsten der shortest pathes – dessen Länge ist gleich dem Diameter des Graphen.

Die Klasse HeimdallAverageMinimumPathLength.java wird ebenfalls mit dem HeimdallGraphen aufgerufen und benutzt auch die Shortest Path Matrix, um aus

(30)

den darin enthaltenen Werten die durchschnittliche Geodesische Pfadlänge zu ermitteln. Im Rahmen unseres Beispiels erhalten wir das folgende Ergebnis:

8 x 8 matrix

0 3 1 6 1 4 2 5 0 0 1 3 0 1 2 2 0 2 0 5 0 3 1 4 0 0 0 0 0 0 0 0 0 3 1 6 0 4 2 5 0 4 2 2 0 0 3 1 0 1 2 4 0 2 0 3 0 3 1 1 0 4 2 0

Average Minimum Path Length: 2.772727272727273

Die Vielzahl der Einzelinformationen aus den obigen Berechnungen werden in der Klasse HeimdallGraphMetaData.java gespeichert, um eine umfassende Analyse der mathematischen Eigenschaften und deren Vergleichbarkeit in weiteren Analysen zu ermöglichen.

(31)

4.6 Aufruf der Analysefunktionen

Beim Aufruf der Klasse HeimdallGraphMetaData.java werden automatisch die verschiedenen Analysefunktionen aufgerufen und entweder in der Klasse oder direkt in den Heimdallvertices gespeichert. Daneben gibt es noch Informationen, die nur im Bezug auf vertexpairs sinnvoll sind. In der folgenden Übersicht sind die aus dem webgraph erzielbaren Informationen noch einmal nach diesen Kriterien aufgeschlüsselt. Klasse benennt die Klasse, in der die Information erzeugt wird, Aufruf benennt den Funktionsaufruf, der die Information zur Anzeige bringt.

Informationen, die sich auf denkompletten Graphbeziehen.

Information Formel /

Symbol Klasse HeimdallGraphMetaDataAufruf aus Anzahl der vertices v HeimdallGrap

h .getNumberOfVertices()_int

Anzahl der edges e HeimdallGrap

h .getNumberOfEdges()_int

Anzahl der Schleifen L HeimdallGrap

hReciprocity .getNumberOfLoops()_int

Diameter des

Graphen DG= max(dij) HeimdallGraphDiameter .getGraphDiameter()_double

Efficiency des

Graphen HeimdallGraphEfficiency .getGraphEfficiency()_double

durchschnittlicher

indegree HeimdallDegreeDistribution .getAverageInDegree()_double

durchschnittlicher

outdegree HeimdallDegreeDistribution .getAverageOutDegree()_double

Average Minimum

Path Length HeimdallAverageMinimum PathLength

.getAverageMinimumPath Length()

double Betweenness

Centrality

HeimdallBetw eennessCentra lity

.getAverageBetweennessC entrality()

double

(32)

Informationen, die sich aufvertexpairsbeziehen.

Symbol

Klasse Aufruf aus

HeimdallGraphMetaData Länge des shortest

path

di,j HeimdallShort

estPath

.getShortestPath (HeimdallVertex from, HeimdallVertex to) double

Efficiency der

Verbindung Ei,j= 1/di,j HeimdallGraphEfficiency .getEfficiency(HeimdallVertex from, HeimdallVertex to) double

Informationen, die sich aufeinzelne verticesbeziehen.

Symbol Klasse HeimdallvertexAufruf aus durchschnittlicher

indegree der nachfolgenden

vertices ViЄ

{Nachfolger von v}

DirectedSpars

evertex .getSuccesorAverageInDegree() double

lokaler Clustering

Coefficient Siehe Kapitel3.1, Gleichung 2

Heimdall vertex

.getClusteringCoefficient() double

lokale Betweenness Centrality

gk(i,j) =

Ck(i,j) / C(i,j)

Heimdall vertex

.getBetweenessCentrality() double

lokale Reciprocity Rv := |l(v)| Heimdall vertex

.getLocalReciprocity() int

(33)

4.7 Speichern der Datensätze

Neben der Möglichkeit, den Graph, so wie er nach dem Crawlen erstellt wird, in der GraphML Notation zu speichern, und der Funktion, die Visualisierung des Graphen als JPEG Bild zu sichern, sollen natürlich auch die Ergebnisse der Analyse gespeichert werden. Gerade aufgrund des hohen Rechenaufwands, insbesondere der Shortest Path-Berechnungen, ist eine Speicherung der Ergebnisse geradezu obligatorisch. Um es vorweg zu nehmen, ideal wäre eine Speicherung in einer Datenbank. Da jedoch auch hierfür zu wenig Zeit zur Verfügung stand, werden die Daten, etwas unkonventionell im HTML – Format gespeichert. Dieses Vorgehen hat den Vorteil, dass in einer späteren Version der Software die Daten einfach wieder mit dem schnellen Parser des Frameworks eingelesen werden und in einer Datenbank gespeichert werden können.

Die Datensätze sind auf der beiliegenden CD gespeichert und können in jedem Standardwebbrowser betrachtet werden, allerdings kann es dabei, aufgrund der Größe der Dateien, zu längeren Ladezeiten kommen.

4.8 finale GUI

Die fertige Software lässt sich recht einfach bedienen. Über 4 Tabs wählt man die Funktionen “Crawl”, “Analyze Graph”, “Draw Graph” oder “Ranking Analysis” an. Statt mit dem Crawl zu beginnen, kann man auch ein GraphML XML File laden und mit diesem Graph weiterarbeiten.

Im Tab “Crawl”kann man eine URL, oder mehrere durch Semikolons getrennte URLs, eingeben und die gewünschte Crawltiefe wählen. Drückt man auf den Button “start crawl” beginnt ein Crawl mit den eingegebenen Seed – URLs.

Abbildung 5 – Tab 1

(34)

Im Tab “Analyze Graph” kann man die Analyse starten und das Ergebnis als HTML – Dokument speichern.

Der Tab “Draw Graph” bietet die Möglichkeit eine einfache Visualisierung zu rendern und diese als Bild im JPEG – Format zu speichern.

(35)

Damit verbleibt noch der letzte Tab “Ranking Analysis”, hier kann man den Ranker starten und das Ergebnis, ein Ranking der vertices nach PageRank und Betweenness Centrality, wiederum als HTML – Dokument speichern.

(36)

4.9 Heimdall.app – Graphanalyse unter Mac OS X

An dieser Stelle drängt sich die Frage auf, weshalb man eine

plattformunabhängige JAVA – Anwendung in eine native Anwendung für ein Betriebssystem umwandeln sollte. Es sind es drei gute Gründe, die in diesem Fall dafür sprechen. Zuerst einmal hat Apple eine der besten Umsetzung der JAVA Virtual Machine, zweitens kann gerade eine sehr speicherintensive Anwendung, wie sie Heimdall darstellt, von der robusten und performanten Speicherverwaltung unter Mac OS X profitieren. Und schließlich gibt es unter Mac OS X eine elegante Möglichkeit, dem Programm mehr Speicher zuzuweisen. Man muss dazu lediglich ein XML – File, die so genannte Property List, editieren:

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<key>CFBundleExecutable</key>

<string>JavaApplicationStub</string> <key>CFBundleGetInfoString</key>

<key>CFBundleInfoDictionaryVersion</key> <string>6.0</string>

<key>CFBundleIconFile</key> <string>Heimdall.icns</string> <key>CFBundleIdentifier</key> <string>valhalla</string> <key>CFBundleName</key> <string>Heimdall</string> <key>CFBundlePackageType</key> <string>APPL</string>

<key>CFBundleSignature</key> <string>????</string>

<key>CFBundleVersion</key> <string>1.0.1</string> <key>Java</key>

<dict>

<key>JVMVersion</key> <string>1.4*</string> <key>MainClass</key>

<string>net.heimdall.Heimdall</string> <key>Arguments</key>

<key>ClassPath</key>

<string>$JAVAROOT/jar_0.jar</string> <key>VMOptions</key>

</dict> </plist>

Nach diesem kleinen Eingriff kann das Programm 768 MB des Hauptspeichers nutzen. Darüber hinaus bestünde auch die Möglichkeit, über die Cocoa Schnittstelle in Mac OS X Programmfunktionen von Heimdall für andere Anwendungen nutzbar zu machen.

(37)

5. Testszenarien und Aufbauen der Datensätze

Innerhalb des relativ kurzen Zeitraumes, der zur Bearbeitung einer Diplomarbeit an einer Fachhochschule vorgesehen ist, war es leider nicht möglich, umfangreiche Crawls in spambelasteten Webbereichen durchzuführen, wie ursprünglich durchaus angedacht war. Um dennoch aussagekräftige Datensätze zu erhalten, wurden archetypische Stichproben gewählt und zusätzlich, für den Bereich des Web Spams, mit JWebSpinner ein kleines JAVA Programm geschrieben, das eine modellhafte Form einer Web Spam Struktur erstellt.

5.1 JWebSpinner

Dieses kleine Java Tool, dass übrigens auch in einer nativen Mac OS X Anwendung umgesetzt ist, erstellt automatisiert HTML – Dokumente und verlinkt diese so, dass eine Linkstruktur entsteht, die dafür ausgelegt ist, den PageRank einer Zielseite, hier “target.html”, zu pushen. Es wählt die Parameter dabei in einer Art, dass ein Struktur, entsprechend den Erkenntnissen aus [5] generiert wird:

Innerhalb der Struktur unterscheidet man drei verschiedene Kategorien von Webpages. Die erste sind Seiten im Web, die dem Spammer nicht gehören und auf die er keinen Zugriff hat; diese werden in unserem Modell nicht weiter berücksichtigt, da sie für den Algorithmus selbst keine Rolle spielen. Sie erzeugen lediglich PageRank durch ihre Verlinkung mit den Seiten der zweiten Kategorie, nämlich Seiten, die dem Spammer auch nicht gehören, auf die er aber in so fern Zugriff hat, als dass er Links auf ihnen platzieren kann. Dies ist etwa bei Gästebüchern der Fall, oder in Foren, Wiki Wiki Websystemen [27], oder Weblogs [28]. Auf Seiten aus dieser Kategorie platziert der Spammer Links, die auf seine Zielseite linken. WebSpinner simuliert diese Seiten, indem er 150 HTML Dokumente erstellt, die alle auf die Zielseite linken und zusätzlich zwischen 0 und 39, über eine Zufallsfunktion ausgewählte, Links enthalten, die wiederum auf zufällig ausgewählte Dokumente aus der eigenen Kategorie linken. Schließlich gibt es noch die Kategorie von Seiten, die dem Spammer gehören und über die er entsprechend uneingeschränkt verfügen kann. Zu diesen Seiten gehört die Zielseite und eben die Linkfarm. Der Spammer linkt nun von seiner Zielseite auf jede Seite der Linkfarm und zurück. WebSpinner simuliert diese Konstellation dadurch, dass er auf der Zielseite 500 Links erzeugt, die auf 500 HTML-Dokumente linken, die er ebenfalls erzeugt hat und die jeweils auf die Zielseite zurück linken.

Nun stellt sich die Frage, weshalb ein Webspammer gerade eine solche Struktur aufbauen sollte, um den PageRank seiner Zielseite zu erhöhen. Dazu betrachten wir noch einmal die Formel zum Errechnen des PageRanks r.

rtotal= rstatic+ rin– rout– rsink

Der Spammer wird alle Seiten der Linkfarm benutzen, um rstatic möglichst hoch zu

halten. Durch die Links aus den Seiten der zweiten Kategorie maximiert er rin. Da

er keine Links zulassen wird, die aus der Linkfarm heraus linken, nivelliert er