Normal-Suchen oder Semantisch-Suchen?
Semager hat endlich das lang ersehnt Auswahlfeld integriert. Von nun an könnt Ihr mit einem Mausklick bestimmen, ob ihr exakt nach dem sucht was ihr eingegeben habt, oder lieber die semantische Suchfunktion nutzen möchtet.
Bei der Websuche findet Ihr jetzt neben dem Suchbutton noch zwei weitere Buttons:
“Genau nach Eingabe” und “Semantische Suche“.
Bei letzterer Auswahl wird eure Suche automatisch erweitert und so wird aus einer Suche nach “immobilien köln” eine Suche nach:
- köln ODER kölner ODER koeln UND
- immobilien ODER häuser ODER wohnungen
Viel Spaß beim finden..
Neuausrichtung auf Semantic Business
Semager richtet sich neu aus. Die Entscheidung fiel aufgrund der Tatsache, dass es sehr viel schwieriger ist, sich im Suchmaschinenmarkt auch nur mit kleinsten Anteilen zu behaupten als bisher angenommen.
Stattdessen wird zukünftig verstärkt auf Semantic Business gesetzt. Da Semager über hunderte Gigabyte semantischer Daten verfügt, dutzende Module zur Textanalyse und jeder Menge Know-How in der Entwicklung semantischer Technologien, wird zukünftig mehr auf den Verkauf dieser Daten und des Know-Hows gesetzt, als auf die Besucher der Suchmaschine als Haupteinnahmequelle.
Natürlich ist die Suchmaschine nicht vom Tisch und es wird auch weiter daran gearbeitet, allerdings nur noch an zweiter Stelle. An erster Stelle steht die weitere Analyse von Texten und die semantische Ordnung von Information, sowie diese als eigenständige Dienste anzubieten. Semager selbst soll primär zum testen von Technologien verwendet werden, Anwender können sich in Zukunft also auf neue MashUps und Funktionen freuen.
Um Ihnen einen Überblick über die bestehenden Strukturen zu verschaffen, folgende Seite: Semantic Business bei Semager
Spracherkennung Teil 2
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.
Nimm Python, dann klappts auch mit dem Encoding
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
Unstimmigkeiten beim encoding von Webseiten
Es ist gar nicht so einfach die richtige Codierung einer Webseite automatisiert erkennen zu lassen. Das Problem dabei ist, das sich die verwendeten Beschreibungen mitunter wiedersprechen. So gibt es Webseiten die im HTTP-Response Header und im MetaTag einen westeuropäischen Zeichensatz angeben (ISO-8859-1), der Inhalt der Webseite dann aber in einem generischen Zeichensatz (UTF-8) codiert ist. Wem soll man glauben schenken?
Außerdem ist es gar nicht so einfach den verwendeten Zeichensatz im Inhalt wirklich richtig zu erkennen. Zwar ist es einfach, aus dem Header und den MetaTags die Angaben zu extrahieren, beim Inhalt sieht aus aber anders aus. Es gibt viele verschiedene Zeichensätze die im Grunde alle gesondert behandelt werden müssten (siehe Tabelle am Ende von List_Encoding). Eine einzelner Funktionsaufruf, um mal schnell den richtigen davon zu finden gibt es leider nicht. Und so müssen dann Schritt für Schritt alle abgearbeitet werden. Das könnte noch ein weilchen dauern…
Wenn Jemand einen Vorschlag hat wie man das in PHP realisieren kann, bitte um einen Kommentar. DANKE.
| « ältere Einträge |



