Søren in Norwegen

Urspruenglich dachte ich mir, dass ich bei meinen Betrachtungen einfach alles klein schreibe. Der Grund ist, dass Menschen dazu tendieren, Grosz- und Kleinschreibung wild durcheinander zu wuerfeln und auf diese Art und Weise wollte ich diese Fehlerquelle vermeiden.

Die Suchfunktion in Wikipedia kuemmert das nicht. Aber bei meiner Analyse ist das wichtig in Betracht zu ziehen, damit ein verlinkter Link richtig einem Titel zugeordnet werden kann.

Doch dann stolperte ich ueber JoAn Wood der ueberhaupt nichts mit Joan Wood zu tun hat … Oder war es der Unterschied zwischen UMBEL und Umbel? … Ach nein, mich duenkt es war Testing the waters vs. Testing the Waters … *seufz*.
Davon gibt es nicht viele Faelle, weniger als 2200. Aber schon einer haette gereicht um meine obige Annahme als nicht brauchbar hinzustellen. Somit musste ich also doch das (ungleich schwerere) Problem der Nutzerschludrigkeiten løsen.

Meine erste Idee war, dass ich mir den Hamming-Abstand zunutze machen kønnte. Dieser misst …

[…] the minimum number of substitutions required to change one string into the other […].

Die oben erwaehnten ca. 2200 Beispiele wo das-Gleiche-blosz-anders richtig ist, sind mir bekannt. Die kann ich also einfach auslassen bei der Berechnung des Hamming Abstands (damit da nix falsch gemacht wird).
Ich programmierte das dann fix und zunaechst schien das auch zu funktionieren. Bspw. erkannte der Algorithmus, dass „Takashi Fujiwara“ vermutlich eigentlich „Takeshi Fujiwara“ sein soll. Doch dann stolperte ich ueber Voss IL, welches zu Moss IL werden sollte. Ich bemerkte das natuerlich nur, weil ich „lokales Wissen“ habe, denn ich wohne in Norwegen. Voss und Moss sind Ortsnamen und „IL“ bedeutet „idrettslag“ — Sportverein. Zwar hat nur Moss IL eine Seite in Wikipedia, aber Voss IL wird hier zumindest erwaehnt.
Ein anderes (lustiges) Beispiel warum der Hamming-Abstand fuer meine Zwecke nicht brauchbar ist, ist die Umwandlung von „Macon, Ohio“. Dies kønnte entweder „Mason, Ohio“ werden oder „Bacon, Ohio„. Welches ist richtig?
Satz mit ‚X‘: das war wohl nix … *seufz*.

Der Grund warum mir das so am Herzen liegt ist folgender. Ganz am Ende werde ich alle Links die keiner echten Wikipediaseite entsprechen rausschmeiszen. Und die hier beschriebenen Faelle wuerden alle faelschlicherweise als „gibt’s nicht“ erkannt und damit zu Unrecht ausgespart werden.

Ich machte mich nun also (wieder einmal) daran (semi-)manuell zu schauen, was Nutzer denn falsch schreiben kønnten und Heuristiken zu finden die dies verallgemeinern.
Den ganz oben beschriebenen Fall der falschen Grosz- und Kleinschreibung konnte ich mit genau der Methode (Vergleich mit Wikipediatiteln wenn alles klein geschrieben ist) auch løsen.
Ein weiterer Fall war, dass anstelle eines Leerzeichens ein Untersrich < _ > verwendet wurde. Und ein letzter Fall war, dass Leerzeichen vor oder nach dem eigentlichen Link folgten.
All diese Faelle (insb. Letzterer) werden vom menschlichen Gehirn sofort und (meist) ohne Weiteres erkannt und dem eigentlichen Fall zugeordnet. Aber wenn man einer Maschine das nicht sagt, dann ist fuer diese < FooBar > etwas ganz anderes als < Foo Bar >, < foobar > oder < foo_bar >.
Das ist ein schøn einfaches Beispiel, welches einen wichtigen Teil meiner Arbeit beschriebt. Dieser Teil besteht darin, dass ich die parallelen Prozesse im Gehirn in ihre fundamentalen Einzelteile „zerpfluecke“. Diese werden dann linearisiert, damit der Gesamtprozess von einer Maschine ausgefuehrt werden kann. Und das ist genau das was ich als Physiker gelernt habe: Modellbildung.

Dies ist eine gute Gelegenheit, mal wieder ueber den Unterschied zwischen Data Scientists und (vielen) Data Analysts herzuziehen. Ich als Data Scientist sehe es als integralen Bestandteil meiner Arbeit an immer und immer wieder durch die Rohdaten durchzugehen um diese zu verstehen. Letzteres hilft mir Muster zu erkennen um dann verallgemeinerte Modelle zu erstellen, die besagte Rohdaten beschreiben (und nicht vom Quatsch der Nutzer verwirrt werden). Diese Modelle muessen dann in langer (semi-)manueller Arbeit getestet, erweitert und verfeinert werden. Und all dies bevor ueberhaupt eine einzige Analyse stattgefunden hat. Analyse in dem Sinne, wie es der Auftraggeber (vulgo: die Chefin) versteht. All dies erfordert natuerlich meist selbstgeschriebene Programme.
Data Analysts hingegen bekommen die Rohdaten und wenden dann die bekannten Modelle darauf an. Letztere wurden bspw. im Studium erlernt oder sind in der benutzten Software eingebaut.
Der Unterschied ist also, dass ich nicht weisz was ich habe und das erstmal beschreiben muss. Data Analysts hingegen haben bereits eine (mindestens ungefaehre) Vorstellung davon was die Rohdaten beschreiben und finden dann halt „nur“ die Parameter der beschreibenden Modelle die am besten zu den Rohdaten passen.
Bitte nicht missverstehen, das kann auch super komplex sein. Ist aber eine fundamental andere Herangehensweise an Problemstellungen, die sich fuer normale Menschen erstmal voll gleich anhøren.

Aber genug dazu … ach so, beinhae haette ich vergessen es zu sagen. Die letzten beiden Faelle wurden dann auch noch fuer den alles-ist-klein-geschrieben Fall untersucht.

Ein Problem verblieb: Sonderzeichen … (die schon wieder *seufz*). Ihr, meine lieben Leserinnen und Leser, møget bei Wikipedia doch mal nach „Zaprezyn“ suchen. Dort werdet ihr dann direkt auf die Seite von „Zaprężyn“ umgeleitet (man beachte den Haken unter dem „e“ und dem Punkt ueber dem „z“). Umleitungen hatte ich vor einer Weile behandelt, es ist also alles richtig und dieses spezifische Beispiel ist auch kein Problem. Das Problem besteht fuer solche Falle wo die Falschschreibung keine Umleitung hat. Denn „Kringel unter dem e“ kønnte ich zwar fuer diesen speziellen Fall programmieren, aber nicht fuer alle møglichen Sonderzeichen.
Nun ja, wieder einmal musste ich auf das alte Statstikmantra zurueckfallen: wenn-das-haeufig-vorkommen-wuerde-dann-waere-ich-viel-øfter-drueber-gestolpert-aber-so-kann-ich-diese-Faelle-einfach-nicht-beachten-und-in-den-Fehler-druecken. … Bin ich froh, dass es dieses Mantra gibt ;) .

Zum Abschluss seien die konkreten Zahlen genannt. Insgesamt hatte ich anfangs 189,887,300 Links. Davon wurden ca. 71% erkannt (134,489,097 um genau zu sein). Die waren also richtig geschrieben. Mit den oben beschriebenen Methoden konnten weitere 16,909,568 Links richtig zugeordnet werden. Damit fallen die dann am Ende nicht weg. Toll wa! Mal wieder kann ich sagen: Science to the Rescue :)

Aber Moment … da fehlen doch noch 38,488,635 um auf die erwaehnte Gesamtzahl der Links zu kommen. Ein Grund fuer die Diskrepanz ist, dass nach der Korrektur 1,109,340 weniger Links vorhanden waren. Es war zu erwarten, dass es ab und zu vorkommt, dass ein Link von einer Seite einmal richtig und ein anderes Mal „falsch“ geschrieben ist. Vor der Korrektur wird das als zwei unterschiedliche Links angesehen und danach ist das ein und dasselbe und wird somit nur einmal gezaehlt. Fuer den Rest … Nun ja, diese Miniserie ist ja auch noch nicht beendet :P

Ach ja, als Letztes sei gesagt, dass dadurch die Grøsze der (strukturierten) Rohdaten ein kleines bisschen auf 4.9 GB reduziert wurde. Das ist doch auch was :)

Und als Allerletztes sei gesagt: alle „Takashi / Takeshi“ Faelle konnte ich damit natuerlich nicht finden und musste sie dem alle Reste verschlingenden Fehler uebergeben.