Søren in Norwegen

Beim letzten Mal erwaehnte ich interne Wikipediaseiten und dass ich die nicht in die Analyse mit einbeziehen will. Aber was ist das ueberhaupt? Zum Glueck ist das allgemeine Konzept erstmal ganz einfach zu erklaeren. Das sind bspw. Seiten wie diese hier, die Artikel zu spezifischen Kategorien auflisten. Das sind Entwuerfe von (nocht nicht publizierten) Artikeln oder Vorlagen zu bestimmten nuetzlichen Konzepten oder immer wiederkehrenden Dingen auf Wikipedia; diese Seite ist ein Beispiel fuer Letzteres. Das kønnen auch „Metawiki“-Seiten wie diese sein, die oft interne Diskussionen enthalten. Andere interne Links gehen bspw. zu Nutzern, zu Dateien, zum Mediawiki und sehr vielen anderen … øhm … Dingen.

Und alle diese Dinge will ich nicht mit dabei haben. Kein einziges davon faellt unter die Kategorie „Weltwissen und wie dieses verknuepft ist“. Blosz weil ich meine LaTeX Vorlagen toll finde, heiszt das noch lange nicht, dass das Weltwissen ist. Nicht mal dann, wenn andere die nuetzliche finden wuerden. Das Gleiche gilt fuer Dokumente die neue Angestellten einer Firma lesen muessen, um sich mit den Interna vertraut zu machen. Und all so’n Kram sind diese internen Seiten.
Manche Sachen sind nicht ganz so eindeutig (bspw. interne Links zum wiktionary) aber man kann auch da diskutieren, warum das allerhøchstens mittelbar mit dem Weltwissen verknuepft ist. Deswegen habe ich micht entschieden auch solche Grenzfaelle wegzulassen … … … aber ach, im Eifer eile ich zu weit voraus … denn eine genaue und (ziemlich) vollstaendige Untersuchung was denn nun wirklich alles zu internen Seiten gehørt geschah erst zu einem spaeteren Zeitpunkt.

Im wesentlichen war ich immer noch dabei zu schauen, ob die Analyse ueberhaupt durchgefuehrt werden kann. Deswegen entschied ich mich nur jene Links zu internen Seiten auszuschlieszen, ueber deren Schluesselwørter (bsw. Category, Template, User, Help etc.) ich bisher gestolpert bin. Der Hintergrund ist, dass wenn ich bereits in den „Voruntersuchungen“ ueber diese stolperte, denn muessen die sehr oft vorkommen.

Gluecklicherweise haben alle Links zu internen Seiten ein Erkennungszeichen, dass ihnen gemein ist: einen Doppelpunkt im Titel und davor das bereits erwaehnte Schluesselwort. Die waren also einigermaszen leicht auszumachen.

Zu meiner groszen Ueberraschung gibt es in der Wikipedia sehr viel intern zu besprechen, denn ich konnte die Anzahl der zu untersuchenden Seiten von 11,435,116 auf nur 6,212,285 reduzieren. AHA! Jetzt kommen wir in die Regionen, die als offizielle Anzahl aller Wikipediaseiten angegeben ist. Die Zahl der Links in diesen Seiten konnte betraechtlich reduziert werden auf 191,289,820 (von vorher 267,204,162).
Der grosze Sprung nach unten fuer Letzteres ist natuerlich dadurch zu erklaeren, dass Links doppelt wegfallen. Zum einen „fehlen pløtzlich“ alle Links auf den internen Seiten selbst (da Letztere komplett nicht weiter in Betracht gezogen werden). Zum anderen „fehlen“ dann damit die Links zu internen Seiten in normalen Wikipediaartikeln. Andererseits ist der Sprung auch nicht soooo grosz. Besagt die Verminderung um ca. 75 Millionen Links doch nur, dass jede interne Wikipediaseite im Durchschnitt 14 Links enthielt. Und Letzteres kann ich mir durchaus vorstellen.

Zum Abschluss noch die Zahlen wie sich die Grøsze der Daten mit dieser „Løschaktion“ entwickelt haben.

In Textform betrug die Grøsze vormals 5.6 GB und das konnte auf 3.5 GB reduziert werden. Die Grøsze der strukturierten Daten wurde verringert von ehemaligen 8.2 GB auf 5.2 GB.
WOHOO!!! Durch die Entfernung internen Krams konnte endlich die Anzahl der zu untersuchenden Seiten soweit reduziert werden, dass eine Analyse in einem schaffbaren Zeitrahmen stattfinden kann. Auszerdem wurde die Menge der zu untersuchenden Daten so klein, dass ich das endlich alles in den Arbeitsspeicher bekomme.

Damit endeten meine Voruntersuchungen und ich wusste, dass das Projekt prinzipiell durchfuehrbar ist. Jetzt machte ich mich an die Details, um sicherzustellen, dass die Rohdaten tatsaechlich nur das enthalten, was sie im Sinne der Problemstellung (die Vernetzung des Weltwissens) enthalten sollen.
Aber genug fuer heute, mehr dazu beim naechsten Mal.

Die letzten Beitraege in dieser Reihe und die folgenden waren/werden relativ technisch und gingen/gehen sehr ins Detail. Normalerweise wuerde ich nicht so sehr ins Detail gehen, wie ich die Daten fuer eine Analyse aufbereite und hantiere. Dieses Mal ist das anders, weil daran die Durchfuehrbarkeit des kompletten Projekts haengt. Hinzu kommt, dass dies insgesamt ein schønes Beispiel ist, wie aus einer komplexen „das geht ueberhaupt nicht“-Problemstellung  eine „das kønnte tatsaechlich was werden“-Løsung wird.
Aber der Reihe nach.

Aus den Rohdaten ziehe ich (ohne Bearbeitung) ca. 21 Millionen Titel in denen ca. 328 Millionen Links vorkommen. Man kann sich das also leicht vorstellen, dass selbst ein moderner Computer ein bisschen Zeit braucht um fuer nur _eine_ Wikipediaseite das komplette Netzwerk zu erforschen.
Fuer die Ueberlegungen wieviel Zeit das braucht, kann man leider nicht wirklich die Taktfrequenz des Prozessors nehmen. Denn die sagt nur aus, wie schnell der ein Bit „bearbeitet“ (im uebertragenen Sinne). Eine menschliche Anweisung sind aber viele interne Anweisungen und benøtigen viele Prozessorzyklen. Bspw. 1 + 1 = 2 ist im Prozessor: lies Inhalt an Speicherplatz A, lies Inhalt an Speicherplatz B, addiere die Werte, schreibe zu Speicherplatz C das Resultat, gib das ganze auf dem Schirm aus. Und DAS ist auch wieder nur eine vereinfachte Darstellung und besteht an und fuer sich wieder aus mehreren internen Schritten.

Eine Ueberschlagsrechnung was zu erwarten ist, kann man dennoch durchfuehren und das ist mglw. deutlich anschaulicher als abstrakte Instruktionen im Prozessor.
Die Rohdaten beinhalten ca 1,2 Milliarden Zeilen mit Text. Die Verarbeitung einer Zeile beinhaltet (ganz grob) das Lesen der Zeile, die Verarbeitung der Information und Entscheidungen ob da Zeug drin ist was ich haben will oder nicht. Ein Durchgang durch die kompletten Rohdaten benøtigt ca. 6000 Sekunden. Das bedeutet, dass das Pythonprogram ca. 200,000 Zeilen pro Sekunde verarbeiten kann.
Auch wenn die Erforschung des Linknetzwerks eine ganz andere Aufgabe ist, so ist der „Rechenaufwand“ sicherlich aehnlich und der folgende Vergleich ist durchaus aussagekraeftig.
Ich nehme also an, dass ich 200,000 Links pro Sekunde „verfolgen“ kann. Mit den oben erwaehnten 328 Millionen Links bedeutet dies, dass die Erforschung des Linknetzwerks nur EINER Seite ca. 1600 Sekunden dauert. Bei 21 Millionen Wikipediaseiten sind das dann fast 1100 Jahren die die komplette Analyse braucht.

Nun gebe ich zu, dass der Vergleich nicht ganz ok ist. Denn Input/Output (vulgo: lesen und schreiben auf die Festplatte/den Bildschirm) gehøren zu den Sachen die am laengsten bei der Datenverarbeitung dauern. Dies illustriert im Uebrigen auch sehr schøn, warum ich so darauf rumhacke, dass ich alles in den Arbeitsspeicher bekomme. Eben damit ich genau diesen „Flaschenhals“ vermeiden kann.
Nehmen wir also an, dass alles im Arbeitsspeicher ist und damit die Rechenzeit nur 1/100 betraegt (was schon in der richtigen Grøszenordnung liegt). Dann dauert die gesamte Analyse immer noch fast elf Jahre. Diese elf Jahre muss der Rechner durchgehend laufen.
Nehmen wir nun weiter an, dass nur ein Viertel der Webseiten analysiert werden muss (ca. 6 Millionen) und insgesamt nur 200 Millionen Links darin verlinkt sind. Dann braucht die Analyse des Linknetzwerks einer Webseite nur 10 Sekunden (wenn alles im Arbeitsspeicher ist) und alles kann in zwei Jahren fertig sein.

Zwei Jahre? DAS ist ein realistischer Zeitrahmen! Und wenn ich den Code optimiere und das auf mehreren Rechnern laufen lasse, dann brauche ich noch weniger Zeit.

So, nun wisst ihr, meine lieben Leserinnen und Leser beide Hauptgruende warum mir so sehr am Verstaendnis der Daten liegt. Die Menge der zu verarbeitenden Daten entscheidet darueber ob das Projekt durchfuehrbar ist oder nicht. Und den ganzen irrelevanten Kram muss ich auch deswegen rausbekommen, damit mir das nicht die Ergebnisse verfaelscht (das erwaehnte ich beim letzten Mal).

Die Erwaehnung irrelevanten Krams bringt mich nun endlich zu dem worueber ich eigentlich Schreiben wollte: Umleitungen … oder auf englisch: redirects.

Umleitungen sind (beinahe) unsichtbar. Nehmen wir als Beispiel wieder Sprevane vom letzten Mal. Das kann man in der Wikipediasuche auch mit einem „w“ anstelle eines „v“ schreiben. Man landet dennoch direkt bei der Seite die ich verlinkt habe. Wenn man auf diese Art und Weise dort hingelangt, dann sieht man zusaetzlich:

Drueckt man dort dann auf den Link, landet man hier …

… und erfaehrt, warum man nicht dort sondern bei der Seite mit der anderen Schreibweise gelandet ist. Dies passiert alles intern und der Nutzer bekommt davon (fast) nix mit. Umleitungen sind somit nicht Teil des Weltwissens, wenn dieses denn (auf der Wikipedia) besprochen wird. Im Quellcode existieren diese natuerlich trotzdem, denn auch wenn das intern geschieht, so muss das ja doch irgendwo stehen, damit die Maschine weisz, was sie intern machen muss.

Das ist aber gut, denn es bedeutet, dass ich alle Titel die eine Umleitung sind entfernen kann. Damit fallen dann auch alle Links weg die auf diesen Umleitungsseiten stehen.
Es ist aber natuerlich zu beachten, dass ich bei den verbleibenden Links dann auch alle Umleitungsseiten mit den richtigen „Zielen“ ersetzen muss.

Umleitungen sind im Quellcode auch leicht zu erkennen, denn diese haben eine spezielle Markierung. Gut wa! Da kann ich also die Umleitungen unabhaengig von den anderen Sachen einsammeln.

Normalerweise gibt es auf der Umleitungsseite nur einen Link; den zur richtigen Seite. Manchmal steht da aber auch mehr. Nehmen wir als Beispiel Abdul Alhazred. Dort gibt es (verstaendlicherweise) diese beim letzten Mal erwaehnten Abschnitte nicht, welche als Markierung dienen um das Einsammeln von Daten am Ende einer Seite zu unterbinden.
Deswegen sammle ich die Links in der Box …

… auch mit ein. Das war unerwartet aber gut, denn es machte mich auf eine andere Sache aufmerksam die ich nicht brauche: Categories … oder allgemeiner: interne Wikipediaseiten. Dazu aber mehr beim naechsten Mal.

Insgesamt gibt es 9,385,391 Seiten in der Wikipedia die Umleitungen sind … o.O … das ist jetzt _deutlich_ mehr als ich erwartet habe. Das ist aber voll toll, denn dadurch reduziert sich die Anzahl der zu untersuchenden Wikipediaseiten auf 11,435,116 welche 267,204,162 Links beinhalten. Supergut!
Ach ja, verfolgt man meine genauen Zahlenangaben, dann sieht man, dass ich 23 Seiten zu viel habe (unter der Annahme, dass ich alle Umleitungen løsche). Das ist jetzt zwar doof, aber der Fehler ist so klein, dass ich das nicht weiter verfolgt habe. Die Wikipedia ist von Menschen gemacht und da erwarte ich (Schreib)Fehler.

Die Grøsze der Daten in Textform reduziert sich von 6.0 GB auf nur 5.6 GB und die Grøsze der strukturierten Daten geht runter auf 8.2 GB (von vormals 8.9 GB).

Waehrend ich mich darum kuemmerte, stolperte ich darueber, dass es im Quellcode Kommentare gibt und dass diese auch Links beinhalten kønnen … *seufz* menschengemachte Daten *doppelseufz* …
Kommentare haben zum Glueck auch eine Markierung im Quelltext und somit ist es relativ einfach die herauszufiltern. Mit nur 1363 Links die deswegen wegfallen handelt es sich dabei aber (unerwarteterweise) um kein groszes Problem. Die Anzahl der Titel veraendert sich dadurch natuerlich nicht und bei nur so ein paar weniger Links aendert sich auch die Grøsze der Daten nicht wirklich.

Aber genug fuer heute. Beim naechsten Mal mehr :) .

[…] understanding the surrounding scenes is not merely a task of image classification or object recognition. To perform actual tasks, it is critical for the robot to have a functional understanding of the visual scene.

Dieses Zitat ist aus dem Artikel „What can i do around here? Deep functional scene understanding for cognitive robots“ (*hust*) von Ye, C. et al. in 2017 IEEE International Conference on Robotics and Automation (ICRA), Singapore, 2017, pp. 4604–4611.

Diese beiden Aussagen druecken das aus, was die meisten Menschen vom Potential der Roboter halten. Mich duenkt insbesondere diejenigen, die von sich denken, dass sie informiert waeren.
Oder anders: „Jaja, Bilderkennung geht ja mittlerweile doch schon manchmal, aber das ist nicht relevant … und schon gar nicht fuer mich persønlich (!) … denn wenn das Bild nur ein bisschen anders ist, dann wird das Buttermesser als Elefant kategorisiert und mit ’nem Elefanten kann man kein Brot schmieren.“
Und das stimmt. Das ist ein ganz groszes Problem, wenn immer mehr Aufgaben von Robotern uebernommen werden. Ein Butterbrot illustriert die Schwere dieses Problems nicht, aber Geschichten davon, dass man bspw. keinen Kredit bekommt, weil man im falschen Stadtteil wohnt, oder dass man als potentieller Krimineller eingestuft wird, blosz weil man die falsche Hautfarbe hat, sind ja bekannt. Auch DIES ist nicht falsch zu verstehen, denn solche Sachen passierten lange bevor es Computer gab und passieren auch heute noch, selbst wenn keine Computer in den Entscheidungen involviert sind.
Worauf ich hinaus will, ich gebe den Kritikern durchaus recht. Gleichzeitig meine ich aber auch, dass dies eine Kopf-in-den-Sand-Methode ist. Die Menschheit arbeitet an diesem harten Problem und im oben zitierten Artikel sind die Autoren schon ein gutes Stueck voran gekommen.

Dort werden Kuechen als komplexe und interaktive Szenen genommen. Ein Beispiel fuer funktionelles Verstehen ist

[…] a round knoblike object indicates that an action of spherical grasping and perhaps turning could be applied to it […].

Und als Menschen erkennen wir …

[…] such functional areas in our daily environments with vision, so we can perform different actions and tasks.

Da muss man erstmal drauf kommen. Hørt sich leicht an, aber wir machen das ueberhaupt nicht bewusst. Wo ist der Unterschied zwischen einer Schuessel und einer Bratpfanne? Ist das Øffnen der Mikrowelle in der selben Aktionskategorie wie das Øffnen des Besteckfachs? Warum ist mein Gehirn ueberhaupt nicht damit beschaeftigt das auseinander zu klamuesern sondern macht das einfach? Nun ja, streng genommen klamuesert mein Gehirn das auseinander, aber das geschieht eben automatisch und unterbewusst nachdem wir das gelernt haben.

Und die Autoren des Artikels haben sich daran gemacht und versucht einem Computer beizubringen unterschiedliche Objekte in einer Kueche funktional zu erkennen.

Ihr bestes Modell hat Zeug zwar in nur ca. 32 % aller Faelle den richtigen Kategorien zuordnen kønnen, aber bei der Vielzahl von verschiedenen Aktionskategorien in einer Kueche, finde ich das schon bemerkenswert. So bemerkenswert, dass ich besagte Kopf-in-den-Sand-Strategie fuer all zu gefaehrlich halte. Natuerlich sind Resultate wie …

[…] a bulb […] is recognized as a “spherical grasp to open” functional area […]

… eine Bestaetigung genau dessen was ich oben schrieb. Aber wenn man bedenkt, dass …

[…] the bulb [was] not labeled with any specific functionality in the training data

… dann ist das kein Fehlschlag, sondern ein Erfolg! Genauso wie Kinder die Sandkuchen essen kein Fehlschlag sind, sondern nur eine von der Evolution als (meistens) erfolgreich erkannte und erprobte Strategie anwenden um zu lernen. Und trotz des Fehlschlags (Sand ist schlieszlich objektiv nicht essbar) erlauben wir den jungen Menschen nach ein paar Jahren Kuechenchef zu werden, Auto zu fahren oder neuen jungen Menschen Dinge beizubringen.

Und auf der Stufe sind (trainierte) Computer — Kleinkinder … und die werden auch mal grosz und kønnen dann alles was auch wir kønnen. Toll wa!

Beim letzten Mal bin ich einen groszen Teil der fuer die Bearbeitung der Problemstellung irrelevanten Information losgeworden. Anstatt die kompletten Texte der Wikipedia in die Betrachtungen einzubeziehen habe ich nur alle Titel und die dazugehørigen Links aus den Daten herausgezogen. Es stellte sich dann heraus, dass das immer noch eine zu grosze Datenmenge war um die zu bearbeiten. Auszerdem stimmte die Anzahl der Wikipediatitel mit fast 21 Millionen nicht ueberein mit den offiziellen ca. 6 Millionen.

Letzteres machte mich stutzig und ich schaute mir die verbliebenen Daten mal genauer an. Als allererstes vielen mir zwei Dinge auf. Vor dem eigentlichen Titel gibt es im Code jeder Wikipedia noch mehr „Steuerelemente“. Dort kønnen prinzipiell auch Links auftauchen. Ebenso muss nach dem Titel nicht direkt der Text der eigentlichen Seite anfangen. Und in diesem Teil kønnen prinzipiell auch Links auftauchen.
Dieses Problem war einfach zu løsen denn das eigentliche Textfeld beginnt immer mit diesem Steuerelement:

<text bytes=

Da konnte ich also einfach sagen, dass Links erst dann aufgenommen werden sollen, wenn diese Markierung passiert ist.

Die zweite Sache die mir auffiel war … mhm … schwerwiegender und weniger einfach zu løsen. Als Beispiel soll der Artikel ueber die Sprevane dienen. Ganz am Ende, nach dem eigentlichen Artikel findet sich diese weiterfuehrende Infobox:

Solche Infoboxen gibt es auf vielen Seiten und zu vielen Themen. Das ist zwar gut und soll da auch stehen, aber fuer die Problemstellung ist das eher irrefuehrend. Ich wollte wissen, wie man aus den eigentlichen Texten von einer Wikipediaseiten zu jeder anderen kommt. Solche Infoboxen fuehlen sich da an wie „schummeln“, weil man damit ja gleich ganz total woanders „hinspringen“ kann.
Lange Rede kurzer Sinn, die wollte ich also nicht dabei haben. Dummerweise haben die keine Markierung im Quellcode.

Zur Hilfe kam mir eine andere Sache, die ich auch nicht dabei haben wollte (und zwar von Anfang an nicht). Im obigen Beispiel ist es der mit „See also“ bezeichnete Abschnitt. Das ist thematisch zwar auch immer passend, aber ebenso eine „unerlaubte Abkuerzung“.
Nun haben aber nicht alle Artikel solche einen Abschnitt. Anstatt dessen gibt es andere, aehnliche Paragraphen, die in die selbe Kategorie fallen. Diese sind „References“, „Further reading“, „‚External links“ und „Sources“. In den allerallermeisten Faellen ist eins davon immer dabei. Und diese Abschnitte stehen (zumindest bei den vielen hunderten Stichproben die ich gemacht habe im Laufe des Projekts) auch immer ganz am Ende (vor møglichen Infoboxen). Wenn doch ein paar ein paar ganz wenige „durchgehen“, entweder weil so ein Abschnitt doch nicht auftaucht, oder weil der nicht ganz am Ende steht, dann ist das auch nicht soo schlimm. Ist halt so bei Daten aus der echten Welt … das geht dann in den immer angenommenen 10-Prozent-Fehler. Ist ja schlieszlich keine Bruecke die ich hier baue.
Und welche Blueten das treiben kann, kann man an diesem Beispiel, welches alle fuenf „Endabschnitte“ und gar sekundaere und tertiaere Quellenangaben hat o.O .

Somit hatte ich also meine Markierung; ich hørte einfach auf Links mit dazuzunehmen, wenn einer von den obigen fuenf Abschnitten erreicht war.

Die Anzahl der Titel blieb mit 20,820,530 natuerlich die Selbe, aber die Anzahl aller in Betracht gezogenen Links reduzierte sich um ueber 15 % von urspruenglich 327,784,045 auf 277,321,420.

Ich mache dies alles so im Detail, weil ich genau wissen møchte, was meine Daten die ich letztlich analysieren werde eigentlich beinhalten. Denn das wird die Resultate beeinflussen!

Ach ja, die Grøsze der Daten in Textform reduziert sich durch diesen Schritt nochmals betraechtlich von 7.5 GB auf nur 6.0 GB. Die (relevante) Grøsze der strukturierten Daten geht runter auf 8.9 GB (von ehemals 10.8 GB). Toll wa! Bald bin ich in Bereichen, wo ich alles gleichzeitig im Arbeitsspeicher halten kann :) .

Vor einiger Zeit kaufte ich mir eine Playstation 4. Am Anfang ist die noch ganz jungfraeulich. Trotz lanjaehrigen Zockens (das muesste ich auch mal aktualisieren) auf der Playstation 3 wurde ich (verstaendlicherweise) so begrueszt:

Und als ich mir meine Pokale anschauen wollte wurde mir gesagt:

Gut zu wissen.

Zum Glueck (???) sind meine Pokale „auf dem Server“ gespeichert. Die Information konnte also schwuppdiwupps runtergeladen werden und dann war mein System auf dem aktuellen Stand.
Ich fand das ein bisschen witzig, denn „0 Trophies“ sehe ich nicht so oft.

Høhø! Voll lustig so’n Markow-Ketten-Generator. Sieht man doch wohl voll, dass das totaler Murks wird, wenn das naechste Wort nach einer Wahrscheinlichkeit berechnet wird.
Diese Domaene ist den Menschen vorbehalten, denn laengere, zusammenhaengende Texte zu schreiben erfordert ein ordentliches Textverstaendnis.

Nun ja, der heisze Scheisz ist seit ein paar Monaten GPT-3.

Hier sind etliche Beispiele fuer Dialoge, Horoskope, Gedichte, Kritiken etc. pp. zu finden.

Ganz toll ist auch, dass man GPT-3 sagen kann, dass es die Antwort in einem bestimmten Stil schreiben soll. Und dann kann man sich von Marie Curie Strahlung erklaeren lassen, H.G. Well zur Inspiration fuer seine Buecher befragen, oder Leibniz‘ Meinung bzgl. des wahren Entdeckers der Infinitesimalrechnung in Erfahrung bringen. Letzteres lohnt sich wirklich zu lesen. Aber Achtung, er hat da eine sehr spezifische Meinung und laeszt sich nicht die Butter vom Brot nehmen. Und wem das nicht reicht, der kann den Hulk fragen, warum er denn immer alles zerschmettern will.

Zur Zeit ist es noch so, dass eine Zusammenarbeit zwischen GPT-3 und einem Menschen (als Redakteur) die besten Ergebnisse liefert. Hier kann man eine Kurzgeschichte als Produkt einer solchen Kollaboration lesen.

Bei den Beispielen kønnte man ja jetzt sagen: „Ach das ist ja nur Quatsch, da ist das nicht so schlimm; richtige Informationen die auch in der Zeitung stehen sind auszer Reichweite von Maschinen“.
Ja, kønnte man sagen … aber dann empfehle ich diesen kurzen Artikel im Guardian dazu … lohnt sich zu lesen. Nicht des Inhalts, sondern der Implikationen wegen!

Beim letzten Mal schrieb ich, dass die Wikipedia Rohdaten ca. 75 GB (75.4 GB um genauer zu sein) grosz sind. Das ist viel zu viel um das im Arbeitsspeicher zu haben.
Und selbst wenn man so viel Arbeitsspeicher haette, ist das meiste davon Information, die nicht relevant ist fuer die eigentliche Problemstellung.

Mein erstes Ziel war somit Information loszuwerden die ich garantiert nicht brauche.
Im Wesentlichen bedeutete dies, den Text und die „Steuerelemente“ loszuwerden. Letztlich ist ja ALLES Text und deswegen ist Letzteres so wichtig. Denn das ist der Code, der dem Browser klarmacht, dass bspw. ein Wort fett oder kursiv sein soll, an welche Stelle ein Bild kommt, was ein Link ist oder das eine Sequenz von Wørtern eigentlich der Titel sind (und vieles, vieles mehr).

Und die letzten beiden Sachen sind die einzigen Dinge an denen ich interessiert bin.

Und hier kommt eine andere Sache ins Spiel, die vøllig normal fuer einen Datascientist (aber oft nicht fuer einen Dataanalyst) ist: sich die Rohdaten anschauen um herauszufinden wie die Information darin ueberhaupt strukturiert ist.
In diesem Falle war das einfach, weil ich ja den „Quellcode“ der Wikipedia hatte. Das war also alles schon super toll durchstrukturiert, denn eine Maschine muss ja im Stande sein das zu interpretieren und richtig darzustellen. So schøn anzusehen Bilderhandschriften sind, so ist das nicht von Webbrowsern (ohne Weiteres) interpretierbar. Da sitzt erstmal ein Mensch und „uebersetzt“ die in einer solchen Seite vorhandene Struktur in allgemeine (maschineninterpretierbare) Regeln.

Dieser Prozess ist oft ermuedend und langweilig. Aber nicht minder oft lerne ich dabei auch ’ne ganze Menge … insb. natuerlich bei diesem Projekt, da die Rohdaten die Wikipedia sind … hach, was hab ich alles gelesen :) .
Oft fasst man sich auch an’n Kopp oder rauft sich die Haare (nicht nur im bildlichen Sinne!). Das beinhaltet dann meist von sog. „Nutzern“ erstellte Daten. Und davon hatte ich hier auch ’ne ganze Menge.

Wieauchimmer, ich will also den Titel einer Seite und die im Text vorhandenen Links.
Der „Code“ einer Wikipediaseite ist sehr sehr aehnlich dem HTML-Quelltext jeder anderen Webseite. Letzteren bekommt man in Firefox angezeigt, wenn man < CTRL + U > drueckt.
Das ist gut, denn bedeutet dies doch, dass der Titel leicht zu finden ist, denn dieser befindet sich immer zwischen diesen beiden „Markierungen“:

<title>  TitelDerWikipediaseite  </title>

Das meine ich mit Struktur und warum das kleine (aber starke) Wort „immer“ im vorherigen Satz steht.

Links sind etwas komplizierter und ich werde auch an anderer Stelle nochmal auf diese zurueck kommen. In HTML sehen Links so aus:

<a href="LinkZurSeite" title="NameDerSeite">Das was im Text steht und blau und unterstrichen ist</a>

Im Code der Wikipedias ist das deutlich kuerzer. Links befinden sich dort in doppelten eckigen Klammern:

[[TitelDerWikipediaseite | blauer, unterstrichener Text ]]

Der Teil rechts von der „Pipe“ (keine Ahnung wie < | > im dtsch. heiszt) ist optional. Links davon kann auch eine URL einer externen Seite stehen. Das kommt vor aber nicht so haeufig.
Wichtig ist, dass die Struktur (wieder) immerzu das Gleiche ist.

Wenn man den ganzen Text weg laeszt und nur den Titel einer Seite und die Links behaelt, kann ich die Datenmenge um 90 Prozent (!) reduzieren von 75.4 GB auf nur 7.5 GB.
Dummerweise ist das in Textform. Als Rohdaten ist Textform super. Bei der Datenanalyse kønnte ich auch direkt mit Text arbeiten, dass ist aber schwerfaellig. Es ist besser die Information in Datenstrukturen zu „verpacken“, sogenannte Zuordnungstabellen. Das ist eine Art „Metastruktur“ und erleichtert die Handhabung der Daten immens! Handhabung bedeutet hier, lesen und schreiben von Daten.
Das bedeutet ich muss nicht jedes Mal durch jede Zeile eines Textdokuments durchgehen, bis ich eine spezifische Seite (und deren Links) gefunden habe. Innerhalb der „Metastruktur“ sage ich dann bspw. nur …

Ich habe hier einen gewissen Titel; gib mir alle dazugehørigen Links an

… und das wird dann direkt gefunden. In einer Bibliothek wuerde ich sozusagen die Nummer des Buecherregals nehmen (als „Titel“)  und alle Buecher darin entsprechen den Links.

(Beinahe) dito, wenn ich etwas mit den Links machen muss (Spoiler: dazu mehr in einem spaeteren Artikel):

Ich habe hier einen gewissen Titel; løsche alle Links die ein "A" enthalten

Das Problem ist nun, dass die interne Praesentation der Metastruktur Platz braucht. Ich erkaufe also Nuetzlichkeit mit Speicher. So wie ein Buecherregal und die Luft zwischen den Buechern mehr Platz braucht als wenn man Buecher einfach nur auf dem Boden stapelt. Da frage ich mich doch, wieviel weniger Platz die (nicht digitalen) Dokumente (also auch sowas wie Bilder und chiesische Vasen, etc. pp.) dieser Welt brauchen wuerden, wenn das nicht in Regalen (und aehnlichem) sortiert waere. Das sieht man ja bspw. wenn beim Umzug alles in ein paar Kartons dicht gepackt ist. Und darauf folgt dann die Frage, wie grosz die Effizienzsteigerung der Verwaltung ist (sei es beim Staat, bei der Schule oder im eigenen Haushalt) eben durch die Nutzung von Metastrukturen/Buecherregalen.

Wieauchimmer, durch den erhøhten Speicherbedarf ist die obigen Angabe etwas irrefuehrend. Klar, die Information an sich braucht nur 7.5 GB. Damit ich damit aber was (vernuenftiges) machen kann, brauche ich besagte Datenstrukturen und dadurch erhøht sich der Speicherbedarf auf 10.8 GB.
Wenn ich im weiteren Angaben zur „Grøsze der Daten“ mache, dann meine ich damit ab sofort immer inklusive der Anordnung in Datenstrukturen.

So, das war ein ganz schøn technischer Abstecher. Die 10.8 GB sind immer noch zu viel um das alles gleichzeitig im Speicher zu behalten. Zum Glueck (irgendwie) enthaelt die reduzierte Information (die aussoprtierten Titel und Links, ohne den Text und Steuerelemente) noch ’ne ganze Menge „Zeug“ welches nicht gebraucht wird zur Bearbeitung des Problems gebraucht wird (oder gar zu nicht ganz richtigen Resultaten fuehren wuerde). Dazu aber mehr im naechsten Artikel.

Ach ja, in den reduzierten Daten habe ich 20,820,530 Titel und diese beinhalten insgesamt 327,784,045 Links.
Moment 20,820,530 Titel und jeder Titel entspricht einer Wikipediaseite? Ich sagte doch ganz am Anfang, dass es nur 6 Millionen gibt. Nun ja, beides ist richtig, aber mehr zur Løsung dieses Raetsels in einem der folgenden Artikel.

Als „Rohdaten“ ist natuerlich die (englische) Wikipedia zu verstehen. Und JA, die kann man _komplett_ runterladen … also ohne Bilder und Videos und sowas … aber wenn man wuenscht, kann man das auch von den offiziellen Quellen nachladen … aber das wuensche ich nicht fuer dieses Projekt.

Zunaechst einmal ist es supercool, dass das ueberhaupt geht … soviel wusste ich … und dann ging’s auch schon los mit der Frage: Wie komme ich an die Daten die ich brauche um die Fragestellung zu bearbeiten?
Das ist uebrigens total normal fuer Data_scientists_. Uns werden Fragen gestellt und wir kønnen dann zusehen, wie wir die beantworten. Ist wie bei normaler Wissenschaft.
Data_analysts_ hingegen kriegen die (oft schon gut vorbereiteten) Daten gegeben und muessen die dann „nur“ analysieren.
Im Laufe der Serie werde ich ein bisschen mehr darauf eingehen, worin ich die Unterschiede sehe zwischen diesen beiden Berufen. Das soll nicht falsch zu verstehen sein. Dataanalysts haben oft ziemliche hohe Kompetenzen in der Datenanalyse die ich nicht habe. Aber Hinz und Kunz die ’n Fragebogen erstellen, dann die paar hundert Antworten ’ner regulaeren statistischen Analyse unterziehen und das ganze oft in einem bekannten Tabellenkalkulationsprogramm oder mit gekaufter proprietaerer Software, ohne zu wissen oder zu reflektieren was dahinter steckt (nicht nur bei der Software, sondern auch bei den Modellen), bezeichnen sich heutzutage so. Und ’s geht mir gegen den Strich, dass ich mit besagten Hinz und Kunz (nicht mit denen die wirkliche Kompetenz haben) in einen Topf geworfen werde. Und ja, ich rege mich hier ueber Kollegen einer anderen Zweigstelle auf … aber das mache ich nur wegen meiner Eitelkeit und weil ich eingebildet bin. Deswegen versuche ich das auf ein Minimum zu reduzieren.

Ich schwoff ab.

Zunaechst wusste ich zwar, dass man die Wikipedia runterladen kann, aber ich wusste nicht wo.
Schritt Null war dann eine allgemeine Suche im Internet und das lesen von ein paar Weblogartikeln. Dabei fand ich die offizielle Wikiepedia-komplett-runterladen-Seite.
Dort navigierte ich fix zum Abschnitt „Where do I get it?“ und das fuehrte mich hierhin, wo ich begrueszt wurde von diesem spartanischen Design …

… … … … wait what? … und war erstmal verwirrt. Es brauchte ein bisschen vorwaerts / rueckwaerts / seitwaerts klicken um immer wieder hier zu landen. Das war also richtig.

Ich nahm das Backup vom 2020-12-20 was mich mich auf die naechste Seite fuehrte (ich frage mich, ob es die in einem Jahr noch gibt). Die Information dort war dann VIEL mehr und ich musste erstmal herrausfinden worum es sich bei all diesen Sachen handelt.
Nachdem ich mich ein bisschen informiert (und probiert) hatte, entschied ich mich fuer die Datei mit dem leicht zu merkenden Namen „enwiki-20201201-pages-articles-multistream.xml.bz2“.

Toll wa! Das Wissen der Welt ist komprimiert und ohne Bilder nur 17.7 GB grosz. … Unkomprimiert sind es ca. 75 GB. Das ist zwar deutlich mehr, aber jetzt auch nicht soooo viel. Schon krass, wie gut Komprimierungsalgorithmen sind. Ist ja bei mp3 oder den Videocodecs nicht anders. Menschlicher Einfallsreichtum par excellence.

Nun hatte ich was ich wollte und war einen Schritt naeher an der Beantwortung der Frage. Zu dem Zeitpunkt ahnte ich noch nicht, dass es noch ziemlich viele Schritte werden bis ich die Antwort in den Haenden halten konnte.
Eine Sache war mir aber klar: die 75 GB; das konnte ich nicht alles gleichzeitig im Arbeitsspeicher behalten. Geschweige denn sich „kreuzende“ Berechnungen ueber alles auf alles daran zu machen. Wie ich dieses Problem (schrittweise) løste, stelle ich in den kommenden Artikeln vor.

In dreifacher Hinsicht. Zum Einen bereitet die Botschaft eines Artikels in der New York Times mit dem Titel „The Age of Electric Cars Is Dawning Ahead of Schedule“ gute Laune. Wenn man den Ladevorgang (Wortspielkasse!) der Seite abbricht , dann kommt auch nicht dieses Dingens was einem vom Lesen des Artikels abhaelt … manchmal frage ich mich, was fuer Leute diese „Schutz“mechanismen programmieren und warum das keinem auffaellt wie leicht das zu umgehen ist. Das ist ja noch einfacher als damals, als der Spiegel seine Seiten „verschluesselt“ hat, damit die keiner lesen kann, wo die „Verschluesselung“ dann aber einfach darin bestand im HTML-Code der Seite alle Buchstaben eins nach rechts zu schieben … *lol* … das ist dann der zweite Grund fuer gute Laune … dass man den Artikel trotzdem lesen kann.

Der dritte Grund ist persønlicher Natur … ’s ist doch immer schøn, wenn man Recht hat und es dann sogar mal um eine positive Sache geht :)

Das Konzept der Erdős Nummer ist ja bekannt … wenn nicht, dann empfehle ich diesen XKCD … tihihi.
Meine Erdős Nummer ist vermutlich 7. Es ist aber auch nicht allzuweit hergeholt dass es eine 5 ist. Und unter ganz guenstigen Umstaenden kønnte es sogar eine 4 sein, das bezweifle ich aber.

Das Erweiterte Konzept der Six degrees of separation, ist vermutlich bekannter. In kurz besagt dieses, dass im Durchschnitt jeder Mensch mit jedem anderen Menschen ueber nur 6 andere Leute verbunden ist.
Ich bspw. bin ueber nur 4 Verbindungen mit Fidel Castro verbunden. Ich habe mal jemanden getroffen deren Sohn (oder war’s der Bruder?) zusammen mit Fidels Bruder an einem Agrarprojekt gearbeitet hat.
Noch besser ist meine Verbindung zu TOOL. Dorthin huepfe ich ueber nur drei Verbindungen, denn eine Bekannte von mir hat mal direkt mit dieser Dame zusammengearbeitet. Toll wa!

Die Studien zu diesem Phaenomen deuten zwar in die Richtung dass die Annahme vermutlich schon stimmt, sind aber im Wesentlichen auch nicht ganz eindeutig. Dies liegt daran, weil das schwer zu testen ist (denn solche Ketten muss man ja nachvollziehen). Oder es steckt viel Voreingenommenheit mit drin, weil bspw. Prominente haeufiger auf den sog. „sozialen Kanaelen“ zu finden sind als Leute wie ich.

Six Degrees of Kevin Bacon ist das gleiche Konzept wie die Erdős Nummer … das ist so gleich, dass man direkt sagen kønnte, dass es das Selbe ist (nur mit Kevin Bacon) … und daher kommt auch der Name dieser Miniserie (weil ich’s lustig finde).

Dieses Spiel kann man beliebig fortsetzen, bspw. mit der Erdős-Bacon Nummer oder noch eins drauf mit der Erdős-Bacon-Sabbath Nummer.

In eine allgemeinere Richtung geht Six Degrees of wikipedia.
Allgemeiner deswegen, weil es nicht nur schaut, wie Personen miteinander verknuepft sind, sonder wie im wesentlichen die gesamte Welt (streng genommen gar das gesamte uns bekannte Universum) miteinander verknuepft ist.
Zugegeben, das ist sehr zentriert auf die sog. „westliche Welt“, weil das nunmal der „Ort“ ist, in dem die Wikipedia geschrieben wird. Aber das tat dem keinen Abbruch, dass mich diese Idee faszinierte. Wie kommt man von Trondheim zu Kevin Bacon? (Via Monty Python geht’s zu Tom Hanks und dann direkt zu Kevin.)

Fuer so ein paar konkrete Fragen war dieses Spielzeug ganz nett. Aber ich wollte mehr wissen. Ich wollte wissen, wie alles mit allem anderen zusammenhaengt.
Mein Interesse wurde noch gesteigert, als ich nach mehreren Versuchen immer drei Verbindungen (in seltenen Faellen zwei oder vier) erhielt.

Die meisten Leute sind dann sicherlich den kuerzesten und laengsten Verbindung interessiert (bzw. nach den Wikipediaseiten die gar keine Verbindung haben) und begnuegen sich mit ein paar Beispielen.
Beispiele sind fuer mich aber nur sowas wie Anekdoten und ich fragte mich, wie wohl die Verteilung der Verbindungen ALLER Wikipediaseiten aussieht. Da dies im wesentlichen die (komplette) Statistik der Verlinkungen ist, beinhaltet das natuerlich die obigen zwei (drei) Faelle … ’s ist aber grøszer angelegt … so grosz, dass ich mir dachte: Jawoll! Ich schau mal ob ich das komplette (interne) Wikipedialinknetzwerk analysiert bekomme … als von _jeder_ Seite zu _jeder_anderen Seite.

Um eine Vorstellung von der Wahnwitzigkeit dieser Idee zu bekommen, møge man mal sechs Millionen mal sechs Millionen ausrechnen. Es gibt naemlich ca. 6 Millionen Wikipediaseiten und alles ist mit allem verbunden. Nur ich will halt nicht nur diese Zahl wissen, sondern das auch noch aufgeteilt auf die „Stufe der Verlinkung“, oder das „Linklevel“ wie ich’s nenne.

Und ueber diese „Reise“ handelt diese Miniserie. Weil ich’s so toll (und oft genug auch frustrierend) fand. Weil ich total viel gelernt habe (nicht nur durch das Lesen vieler, vieler Wikipediaseiten sondern auch durch das Programmieren der dafuer nøtigen Werkzeuge). Und weil ich total viel Freude an all den tollen Sachen hatte ueber die ich in der Wikipedia gestolpert bin.

Ich versuche an den Schritten die ich gehen musste (und die ich in den Artikel im groben nachvollziehen werde) ein bisschen deutlich zu machen, wie denn mein „Arbeitsalltag“ als sog. „Datascientist“ so aussieht. Was es bedeutet, (viele) Daten zu analysieren … denn die Analyse an sich steht meist erst ganz am Ende und macht nur ca. 20 % der eigentlichen Arbeit aus … auch wenn das dann das Einzige ist, was man rumzeigt.
Dadurch werden die kommenden Artikel aber zum Teil relativ technisch und die bunten Graphen gibt’s erst ganz am Ende. Ehrlich gesagt, waehrend ich dies schreibe sind die bunten Graphen noch in weiter Ferne, denn die Analyse des kompletten Linknetzwerks der wikipedia dauert mehrere Wochen (siehe die 36 Millionen Millionen Verbindungen die ich oben erwaehnte) … und das obwohl ich das gerade auf 4 Rechnern gleichzeitig rechnen lasse.