Semantic Weblog

Das Tool Textduplikate finden erhielt ein rudimentäres Update.

Unter Erkennung von Textduplikaten könnt Ihr nun neben der Sprache auch angeben, nach wievielen Zweiwort-Phrasen, Dreiwort-Phrasen oder einzelnen Wörtern gesucht werden soll. Damit wird die Wahrscheinlichkeit zum auffinden eines Textduplikates wesentlich erhöht. Die hier voreingestellten Standardwerte sind ein ganz guter Anfang, ihr könnt aber auch gerne andere Zahlen ausprobieren.

Die einzige Beschränkung ist die auf 250 Zeichen Suchstring. Habt Ihr zuviele Wörter zur Suche ausgewählt, findet Semager nichts, da Ihr eventuell die Länge des Queries überschritten habt. Das Tool gibt euch jedoch eine Warnmeldung heraus, fall das der Fall sein sollte.

Ebenfalls verbessert wurde die Sprachauswahl. Ihr könnt nun zwischen Deutsch, Englisch, Französisch, Spanisch und Italienisch auswählen. Die letzten 3 Sprachen sind aber noch in der Anfangsphase und wurden deshalb als Alpha gekennzeichnet.

Viel Erfolg beim Finden von Dieben…

PS: Natürlich läßt sich das Tool auch automatisiert nutzen. In dem Fall schickt doch bitte einfach eine Nachricht über Kontaktformular.

Mal angenommen Sie suchen nach “Döner Berlin”, wie berechnet Semager dann die Semantik dieses Queries?

Nun, eines der Probleme dabei ist, die Wörter zu filtern, welche zu weit weg von dem Thema sind. Ein derzeit verwendeter Ansatz dazu ist der Verbreitungsgrad. So hat das Wort “Döner” beispielsweise den Grad “406″ und Berlin “131.962″. Berlin ist also sehr viel beliebter als Döner (was auch immer das bedeuten mag .

Würde man nur nach “Döner” suchen, würde Berlin ausgefilter werden, da es ganz offensichtlich in einer ganz anderen Größenordnung spielt. Sucht man hingegen nach “Deutschland” wird Berlin nicht ausgefiltert, da Deutschland einen Verbreitungsgrad in der gleichen Größenordnung (178.851) wie Berlin hat.

Was aber passiert bei “Döner Berlin”? Hier treffen zwei Wörter aufeinander die in komplett unterschiedlichen Größenordnungen liegen. Ich habe damit viel herum experimentiert. So kann man den Mittelwert berechnen, auf logarythmischer Basis arbeiten oder mit linearen Gleichungen, um den Wert zu berechnen, ab dem andere Wörter “zu weit weg” sind.

Schlussendlich nehm ich jetzt einfach nur noch den größten Faktor des Queries als Schwellenwert an. Um ein wievielfaches nun ein verwandtes Wort den Schwellenwert überschreiten muss und ob es dann gelöscht oder abgewertet wird und um wieviel, ist aber eine andere Frage.

Tatsache ist, das ein solcher Filter absolut notwendig ist, um das Ergebnis qualitativ aufzuwerten. Den – wenn man es nicht macht – beinhalten die Keywordlisten bei jedem Query höchstwahrscheinlich immer mehr oder weniger die beliebtesten Keywords im allgemeinen und weniger die semantisch Interessanten.

TOP 20 der “verbreitesten Keywords”:
1) suche 223.232
2) deutschland 178.851
3) suchen 145.714
4) berlin 131.962
5) e mail 124.109
6) software 123.281
7) internet 121.459
zeit 121.301
9) shop 119.490
10) archiv 116.930
11) newsletter 116.376
12) nachrichten 113.278
13) bilder 110.287
14) jahre 108.632
15) search 105.083
16) musik 104.611
17) navigation 104.045
18) blog 102.885
19) jahr 102.798
20) leben 97.037

PS: Die Liste ist nicht ganz auf dem neuesten Stand. Auf den Live-Servern gibt es etwas andere Ergebnisse. Im großen und ganzen passt es aber.

Unter der Seite URL-Analyse gibt es einige neue Updates. Zum einen ist die Geschwindigkeit erheblich gesteigert worden. Dies liegt an einem viel schnelleren Algorithmus zur Erkennung der Sprache. Außerdem wurde ein Fehler ausgemerzt der mich schon lange “gefuchst” hat (für den PHP Programmierer: ein non-breaking space ist kein Leerzeichen –> der trim funktioniert nicht. Hilfestellung: $string = str_replace(“\xA0″, ‘ ‘, $string) ).

Weiterhin findet Ihr neben den gemessenen Wörtern nun ein kleines Fragezeichen. Fahrt Ihr darüber, wird euch angezeigt wo und teilweise auch wie oft das Wort gesehen wurde. Ganz hilfreich bei der Analyse von fremden Seiten, um zu sehen wie diese programmiert worden sind.

Durch die SES Hamburg angeregt, habe ich beschlossen das LSO Tool endlich online zu bringen. Rechts neben den Keywords findet Ihr nun drei Boxen. Die Inhalte der Boxen sind noch in Bearbeitung. Es wird aber nicht lange dauern bis dort die ersten Ergebnisse erscheinen. Ich vermute das ich Anfang nächster Woche bereits die zweite Box befüllen kann.

1) LSO Optimierungsgrad
2) Keywords die aus semantischer Sicht ergänzt werden könnten
3) Keywords die aus semantischer Sicht gelöscht werden könnten

In jeder Box gibt es oben rechts ein großes Fragezeichen. Fahrt Ihr darüber wird euch dazu eine Erklärung angezeigt.

Zu erkennen in welcher Sprache ein Dokument geschrieben ist, hat es wirklich in sich. Ich denke aber ich habe das Problem nun soweit in den Griff bekommen. Die größte Schwierigkeit ist, alles zunächst in einen gemeinsamen Zeichensatz (hier UTF-8) zu bringen. Anschließend fällt die Spracherkennung wesentlich einfacher.

Insgesamt werden mehrere Parameter erkannt und mit einem Punktesystem verschieden stark gewichtet. Am Ende werden alle Punkte addiert und abwärts sortiert. Die Sprache mit der höchsten Punktzahl gewinnt.

1) HTTP-Response Header
Bei manchem Webserver wird die verwendete Sprache schon im HTTP-Header mit übergeben. Da dies aber nicht immer stimmen muss gibt es hier nur 5 Punkte.

2) Meta-Tag Language
Bei vielen Webseiten befindet sich unter den Meta-Tags auch eine Sprachangabe. Diese wird in den meisten Fällen manuell gesetzt und ist daher relativ Glaubwürdigkeit. In einigen Fällen, wie z.B. bei Shops oder Content-Management-Systemen sind diese jedoch auch wiederum schon mal falsch. So kann es sein das ein englischer Shop auch Produkte auf Deutsch verkauft, die Sprachangabe aber trotzdem auf Englisch gesetzt ist. 25 Punkte.

3) Sprachwahrscheinlichkeit laut Zeichensatz
Hat man mal einmal den Zeichensatz einer Seite identifiziert kann man daraus ableiten, wie hoch die Wahrscheinlichkeit für bestimmte Sprachen ist. So ist es z.B. unmöglich mit einem westeuropäischen Zeichensatz (ISO-8859-1) chinesische Schriftzeichen darzustellen. Umgekehrt gilt dann genauso, dass z.B. der Zeichensatz WINDOWS-1251 mit höherer Wahrscheinlichkeit Russisch oder Ukrainisch sein könnte. 1-15 Punkte, in Abhängigkeit von der Sprachwahrscheinlichkeit.

4) Sprache nach Stoppwortliste
In jeder Sprache gibt es Wörter die sehr häufig verwendet werden. Im Deutschen sind das z.B. “der, die, das, von, zu, auf, ..”. Sammelt man diese Wörter von jeder Sprache und vergleicht diese anschließend mit den tatsächlich im Dokument vorkommenden Worten, erhält man eine Schnittmenge pro Sprache (oder auch nicht). Sortiert nach den Schnittmengen ergibt sich eine Wahrscheinlichkeit für diese Sprache. 5-100 Punkte, je nach Trefferhäufigkeit.

5) Standort des Servers laut IP-Adresse
Wird nicht verwendet. Wenn es z.B. in Frankreich einen billigen Webhoster gibt, heißt das noch lange nicht, dass alle Webseiten auf diesen Servern auch auf Französisch sind. 0 Punkte.

6) Sprache laut Top-Level-Domain
Wird nicht verwendet. Es soll ja auch z.B. .de-Domains geben die englischsprachige Inhalte anbieten. 0 Punkte.

Dank Python und dem Universal Encoding Detector funktioniert nun auch die Erkennung der Webseiten-Encodierung. Zugegeben es ist ein bißchen “tricky” in PHP eingebunden und nicht gerade sauberer Programmierstil. Aber es klappt ganz gut. Sobald dann die PECL-Erweitung Python in Version 0.8.1 erscheint, sollte es auch möglich sein, die Python Klasse direkt aus der PHP Umgebung aufzurufen.

Folgende Codierungen werden nun erkannt:

• Big5, GB2312, GB18030, EUC-TW, HZ-GB-2312 und ISO-2022-CN (traditionelles und vereinfachtes Chinesisch)
• EUC-JP, SHIFT_JIS und ISO-2022-JP (Japanisch)
• EUC-KR und ISO-2022-KR (Koreanisch)
• KOI8-R, MacCyrillic, IBM855, IBM866, ISO-8859-5 und WINDOWS-1251 (Russisch)
• ISO-8859-2 und WINDOWS-1250 (Ungarisch)
• ISO-8859-5 und WINDOWS-1251 (Bulgarisch)
• WINDOWS-1252
• ISO-8859-7 und WINDOWS-1253 (Griechisch)
• ISO-8859-8 und WINDOWS-1255 (visuelles und logisches Hebräisch)
• TIS-620 (Thai)
• UTF-32, BE, LE, 3412-sortiert oder 2143-sortiert (mit BOM)
• UTF-16, BE oder LE (mit BOM)
• UTF-8 (mit oder ohne BOM)
• ASCII