HUMBOLDT-UNIVERSITÄT ZU BERLIN. Seminararbeit. Deep Web. Timo Mika Gläßer * 1. Februar betreut durch Prof. Dr. Felix Naumann

Transkript

1 HUMBOLDT-UNIVERSITÄT ZU BERLIN Seminararbeit Deep Web Timo Mika Gläßer * 1. Februar 2005 betreut durch Prof. Dr. Felix Naumann * uni@datanomisch.de

2 Inhaltsverzeichnis Inhaltsverzeichnis... 2 Deep Web Was ist das?... 3 Kurzvorstellung des Inhalts... 4 Beispiele aus dem Deep Web... 4 PubMed.com... 4 AllMusic.com... 4 Statistiken zu Surface/Shallow und Deep Web... 4 Wie könnte eine einfache Suchmaschine für das Deep Web aussehen?... 5 Automatisierungsmöglichkeiten für die Suche im Deep Web... 7 Auffinden von potentiellen Quellen ([BC04], [WM04], [RG04])... 7 Anforderung an Deep Web Formulare ([BC04], [WM04])... 7 Anfragesprache der Quelle lernen ([BC04], [BC03b])... 8 Operatoren der Anfragesprache... 8 Syntax der Operatoren... 8 Suchproblem... 9 Lernen des Klassifikators Schlußbemerkung Referenzen Skripte im Internet Internetseiten Seite 2 von 14

3 Deep Web Was ist das? Eine Definition für das Deep bzw. Invisible Web habe ich einem Tutorial der Universität Berkley entnommen: The "visible web" is what you see in the results pages from general web search engines. It's also what you see in almost all subject directories. The "invisible web" is what you cannot retrieve ("see") in the search results and other links contained in these types of tools. [UCB] Zunächst fällt auf, daß das Deep Web als das Komplement des sichtbaren Webs definiert wurde. Das sichtbare Web seien dagegen alle Seiten, die in Indizes von Suchmaschinen enthalten sind und über Anfragen gegen diese gefunden werden können. Dieser Definition möchte ich mich hier nicht vollständig anschließen, da Suchmaschinen viele Seiten aus politischen und moralischen Gründen aus Ihrem Index ausschließen. Diese Seiten gehören aber trotzdem zum Visible Web. Außerdem gehen die Autoren des Tutorials noch davon aus, daß Seiten, die einen HTTP-Anfrageoperator (?search=deep%20web ) in der URL enthalten von Suchmaschinen ausgeschlossen werden. Das entspricht heute nicht mehr dem technischen Stand der Dinge. Das World Wide Web wird von vielen Wissenschaftlern in drei Bereiche hinsichtlich Ihrer Durchsuchbarkeit eingeteilt: Surface Web bzw. Visible Web, Shallow Web und Deep Web. Von Surface Web Seiten spricht man, wenn es sich um statische HTML-Seiten handelt, die über Hyperlinks miteinander verbunden sind. Diese Seiten können von Suchmaschinen leicht gecrawled und indiziert werden. Das Shallow Web setzt sich dagegen aus Seiten zusammen, die dynamisch (z.b. aus Datenbanken) erzeugt werden. Meistens kann man in den URLs von Shallow Web Seiten ein? finden. Dahinter stehen die Parameter, die bestimmen welchen Inhalt die zugenerierende Seite haben soll. Eine Gefahr für Suchmaschinen beim verfolgen von Shallow Web Seiten ist, daß sie Seiten crawlen die rekursive immer neue Seiten erzeugen: Spider Traps. Das Problem wir aber in der Regel dadurch gelöst, daß Suchmaschinen nur bis zu einer Tiefe N (N ist sehr klein) in solch einen Baum absteigen. Dokumente des Deep Web schließlich sind (fast) nie über Links erreichbar: die Inhalte von Websites des Deep Web sind hinter Formularen verborgen, die erst ausgefüllt und abgeschickt werden müssen. Das stellt die eigentliche technische Hürde dar: der Robot einer Suchmaschine ist nicht in der Lage herauszufinden, was in das Formularfeld eingegeben werden muß und welche Checkboxen eventuell noch angeklickt werden müssen, damit die Anfrage zu einem sinnvollem Resultat führt. Viele Deep Web Quellen sind thematisch stark spezialisiert und bieten für bestimmte Bereiche hochrelevante Ergebnisse: eine Patentdatenbank zum Beispiel. Durch die Fähigkeit diese Quellen zu finden und durchsuchen zu können, kann eine Firma unter Umständen jahrelange Arbeit und viel Geld sparen! Entsprechend gibt es seit einigen Jahren ein reges Interesse in der Forschungskommunität Deep Web Quellen automatisch zu finden, zu klassifizieren und durchsuchbar zu machen. In dieser Arbeit werde ich nur noch vom Deep Web sprechen. Die Begriffe, die man in vielen Arbeiten findet (Hidden, Invisible, usw. Web) sind aber weitestgehend synonym zu verwenden. Der Begriff Deep Web ist allerdings nicht zu verwechseln mit dem Begriff Dark Web : zum Dark Web gehören Server, die in keinem DNS Server eingetragen und auf die keine Referenzen existieren. Seite 3 von 14

4 Kurzvorstellung des Inhalts Ich werde in dieser Arbeit versuchen einige Probleme (und natürlich auch einige Lösungsansätze) aufzeigen, die sich bei der manuellen und automatischen Akquisition von Deep Web Quellen stellen. Etwas tiefer werde ich auf das Thema eingehen, wie die Anfragesprache einer Deep Web Quelle gelernt werden kann. Im wesentlich beruht die Darstellung auf einem Paper von André Bergholz und Boris Chidlovskii [BC04]. Beide sind zur Zeit am XEROX Research Center Europe in Frankreich tätig. Beispiele aus dem Deep Web PubMed.com PubMed ist eine Literaturdatenbank der National Library of Medicine (USA). Der Index enthält über 15 Millionen biomedizinische Artikel - zu vielen sind Referenzen auf die Volltextversionen verfügbar. Suchbegriffe können mit booleschen Ausdrücken verbunden werden. Gruppierung (Klammerung) von Termen wird unterstützt. AllMusic.com AllMusic ist zur Zeit die wahrscheinlich bestgepflegte Musikdatenbank. Der Index enthält circa Alben und Namen von Musikern (zu immerhin gibt es ausführliche Biographien). Die Musiker, Alben und Songs sind über ein Suchfeld abfragbar. In einem geschützten Bereich wird noch eine Detailsuche für registrierte Benutzer angeboten. Es sind nur einfache Suchbegriffe und Phrasen zugelassen. Einige Sonderzeichen werden gelöscht. Allerdings könnte AllMusic auch über herkömmliche Links untersucht werden: die Redakteure von AllMusic verwalten Abbildung 1 : AllMusic [AM] eine sehr detaillierte Taxonomie in der musikalische Werke nach Richtung, Stimmung, Thema, Nationalität und Instrumenten eingeordnet werden. Um diese Möglichkeit zu nutzen muß man sich allerdings registrieren. Statistiken zu Surface/Shallow und Deep Web Zur Zeit der Erstellung dieser Arbeit sind in Google circa Dokumente aus dem Surface/Shallow Web indiziert und abfragbar. die Suchmaschine AllTheWeb kommt auf die gleiche Anzahl, wobei nicht klar ist, wie groß der Schnitt zwischen den beiden ist. Im hand-kurierten Verzeichnis von Yahoo! sind etwa Webseiten indiziert. Das ist ein 2500stel des Index von Google bzw. AllTheWeb. Spekulationen über die Gesamtzahl der Surface/Shallow Dokumente belaufen sich auf Nach einer Studie von BrightPlanet [BM01] ist das Deep Web etwa 400 bis 550 größer als das Surface/Shallow Web besteht aber nur aus Websites. Eine Studie von He, Patel et al. [HP04] schätzt den Faktor auf etwa 500 mit einem Wachstumsfaktor von 3-7 über die Jahre Nach [HP04] umfaßt das Deep Web circa Websites, Datenbanken und Suchmasken. Seite 4 von 14

5 Allerdings hat der Survey [HP04] auch ergeben, daß bereits etwas ein Drittel des Deep Webs in den großen, herkömmlichen Suchmaschinen auftaucht. Verantwortlich dafür dürfte sein, daß auf Anbieter von Information ein gewisser Druck herrscht, Ihre Daten sichtbar zu machen, um die Sichtbarkeit zu steigern und finanziellen Erfolg zu erlangen. Daher werden oft alternative Navigationsformen wie z.b. Taxonomien (AllMusic) angeboten. Diese Pfade können von den traditionellen Suchmaschinen verfolgt werden. Wie könnte eine einfache Suchmaschine für das Deep Web aussehen? Im einfachsten Fall kann man für jede Datenbank aus dem Deep Web einen Wrapper schreiben, in dem festegelegt wird, welche Sprachen unterstützt werden, welche Syntax zu benutzen ist und wie Anfragen, die der Syntax nicht entsprechen gegebenenfalls in eine korrekte Anfrage transformiert werden können. Jede Quelle teilt man entsprechend einer Taxonomie in eine Kategorie ein. Eine übergeordnete Komponente Anfrageverwaltung verteilt Anfragen an die Wrapper, kümmert sich um Zeitüberschreitungen und vereinigt die Ergebnisse. Wünschenswert wäre es natürlich auch, daß die strukturierten oder semistrukturierten Ergebnisse einer Anfrage aus der Quelle extrahiert und geeignet aufbereitet / integriert vielleicht sogar ein Matching für Schemata der Ergebnisse verschiedener Quellen gemacht wird. Im folgenden stelle ich kurz durch ein paar Programmfragmente dar, wie solch ein Wrapper aussehen könnte. In dem JAVA-Programm wir ein Paket org.apache.commons.httpclient referenziert. Dies ist - wie der Name schon andeutet Teil des Apache Jakarta Commons Projekts und kann unter [AJC] bezogen werden. In Listing 1 package de.glaesser.deepweb.allmusic; ist dargestellt, wie das import java.io.*; Suchformular von import java.util.regex.*; AllMusic [AM], daß import org.apache.commons.httpclient.*; import org.apache.commons.httpclient.methods.*; sich auf der Startseite in unter dem Titel befindet gekapselt werden kann. Das Formular verwendet zum Übermitteln der Daten von Client zum Server die HTTP- Methode POST und enthält auch einige versteckte Felder. Das Eingabefeld für die Anfrage trägt den Namen SQL und die Drop-Down-Liste heißt OPT1. Dabei stehen die Zahlen von public class AllMusic { private static void search(string query) throws IOException { PostMethod postmethod = new PostMethod(" NameValuePair[] data = { new NameValuePair("SQL", query), new NameValuePair("OPT1", "1"), // 1=Name, 2=Album, 3=Song new NameValuePair("Submit", "GO"), new NameValuePair("P", "amg") }; postmethod.setrequestbody(data); httpclient.executemethod(postmethod); /* of course we have to handle errors etc. pp. */ String html = postmethod.getresponsebodyasstring(); postmethod.releaseconnection(); parseresult(html) } /* */ } Listing 1 : Wrapper für Suche in AllMusic [AM] 1-3 und 55 für Suche nach Künstlernamen, Album, Song oder Klassischem Werk. In dem Beispiel wird nur nach Künstlernamen gesucht. Seite 5 von 14

6 Das sieht doch eigentlich ganz einfach aus aber woher weiß man nun wie die entsprechenden Felder heißen und welches Feld, welche Bedeutung hat? Die erste Frage läßt sich sehr leicht beantworten. In jedem Browser gibt es eine Funktion Seitenquelltext anzeigen!, der die Seite nicht in der gerenderten Form sondern in der ursprünglichen Form als HTML darstellt. Wenn man Formulare sucht, muß man nach FORM- Tags suchen. Das kann man zum Beispiel mit dem folgenden regulären Ausdruck machen: <FORM.*?>.*?</FORM>. Der HTML-Quelltext gewünschte Formular bei [AM] ist in zu Listing 3 sehen. Darin sind mehrere INPUT-Tags zu finden, sowie ein SELECT-Tag und eine JavaScript-Funktion die beim Abschicken des Formulars aus dem Browser heraus ausgeführt wird. Diese lassen sich sehr einfach herausparsen und in einer Datenbank speichern. Die Namen der jeweiligen Felder sind den NAME-Attributen des jeweiligen Tags zu entnehmen. <form name="simplesearchform" id="simplesearchform" method="post" action="/cg/amg.dll" onsubmit="savesearchsimplecriteria();"><span id="homelabel" class="outside"><a href="/cg/amg.dll?p=amg">home</a></span><span id="searchlabel" class="outside">search</span><input class="juvbox" type="text" name="sql" id="simplesearchtext" /><img src="/i/spacer.gif" width="3" height="2" alt="" /><select class="juvdrop" name="opt1" style="width:112px;" id="simplesearchtype"><option value="1" selected="selected">name</option><option value="2">album</option><option Listing 3 : HTML-Quelltext für Formular aus [AM] Die andere Frage, wie man den Feldern automatisch einen Inhalt / Sinn zuordnen kann, läßt sich nicht so leicht beantworten oder zu leicht: gar nicht! Grundsätzlich gibt es zum jetzigen Zeitpunkt noch kein Verfahren, daß für komplexere Suchmasken (komplex heißt mehr als ein INPUT-Tag) den Eingabefeldern eine Semantik zuordnen kann. Das ist zum einen durch die Größe des Suchraums bedingt, zum anderen lassen sich Falscheingaben manchmal nur sehr schwer erkennen, weil fast immer eine ganz normale HTML-Seite als Antwort selbst auf eine fehlerhafte Anfrage geliefert wird. Zum anderen wäre zum Beispiel im Falle von [AM] von einem Computer gar nicht feststellbar, was die JavaScript-Funktion savesearchsimplecriteria() überhaupt macht, die vorm abschicken des Formulars aufgerufen wird. Transformiert sie womöglich die eingegebene Anfrage und muß daher von unserem Wrapper ausgeführt werden? Wenn ja, dann bräuchte unser AllMusic-Wrapper noch eine Engine, um JavaScript interpretieren zu können! Wow wir bauen jetzt unseren eigenen Browser. Die Aufgabe ein komplexes Formular zu verstehen ist zur Zeit nur von Menschen zu bewältigen! Eine gutes Beispiel für den oben skizzierten Weg ist die Website CompletePlanet [CP]: über Datenbanken aus dem Deep Web sind in Kategorien eingeteilt worden und über eine einheitliche Suchmaske abfragbar. Für jede Datenbank wurde ein Wrapper geschrieben, der die Eigenschaften der Quelle kennt. Die Software wurde von BrightPlanet [BP] entwickelt. Ihr Kern ist der Anfragemanager (DQM: Deep Query Manager), der es ermöglicht die Datenbanken effizient abfragen zu können. Für jede Quelle detaillierte Statistiken gespeichert, die vom Anfragemanager benutzt werden können, um die erwartete Ergebnisgröße, die Kosten für die Anfrage etc. zu berechnen ganz wie in einem herkömmlichen DBMS. Hört sich das nicht ganz schön aufwendig an? Fragt man sich als Informatiker nicht sofort: geht das auch irgendwie automatisch? Ja, geht es! Allerdings mit einigen Problemen. Seite 6 von 14

7 Automatisierungsmöglichkeiten für die Suche im Deep Web Ich möchte in den folgenden Absätzen Ideen skizzieren, wie Deep Web Quellen gefunden werden können, welche Anforderungen an die Schnittstelle (das Eingabeformular) der Quelle gestellt wird und wie die Anfragesprache, welche von der Quelle implementiert ist, effizient erkannt werden kann. Auffinden von potentiellen Quellen ([BC04], [WM04], [RG04]) Jeder der ab und zu das Internet benutzt wird eine handvolle oder vielleicht ein paar mehr Datenbanken / Dokumentsammlungen aus dem Kopf nennen können: Google, TVToday, AllMusic, WikiPedia, Amazon aber wie kann man möglichst viele solcher Quellen finden? Eine Möglichkeit besteht darin, sich selbst eine abgespeckte Suchmaschine zu programmieren und mit einer Menge von Start-URLs, die z.b. aus dem OpenDirectory (DMOZ) gewonnen wurden, das Internet zu durchsuchen. Alle gefundenen Seiten kann man dann nach Formularen durchsuchen (parsen mit regulären Ausdrücken z.b. <FORM.*?>.*?</FORM> ) und im Falle eines Treffers die Einzelheiten des Formulars in eine Datenbank zu schreiben. Nun ist aber klar, daß das obenskizzierte Verfahren sehr bandbreiten intensiv ist. Eine Verbesserung bzw. Vereinfachung läßt sich dadurch erreichen, daß man für bestimmte Suchbegriffe, die thematisch zu einer bestimmten Klasse von Quellen passen, eine Suche in Google startet. Das ist bei Google über deren WebService-API in weniger als 1 Minute zuschaffen. Aber natürlich kann man auch jede andere Suchmaschine oder mehrere parallel abfragen. Jetzt braucht man nur noch die gefundenen WebSeiten untersuchen und nicht in einem enormen Krafttakt das gesamte Internet auseinanderzunehmen. Anforderung an Deep Web Formulare ([BC04], [WM04]) Aus Gründen der Kombinatorik sind Formulare, die automatisch erschlossen werden sollen zunächst darauf beschränkt, daß sie lediglich ein Eingabefeld enthalten [BC04], [WM04]. Diese Forderung ist sehr leicht zu verstehen. Solange keine semantische Beschreibung zusätzlicher Eingabefelder vorhanden ist, müßte ein automatisches Verfahren mit roher Gewalt alle Kombinationen von Eingaben durchprobieren. Für zwei einfache DropDown- Felder mit je 10 Elementen währen das schon Anfragen. Will man dann noch ein Eingabefeld mit sagen wir mal konservativen 1000 Begriffen füllen, müßte man schon =10 13 Anfragen stellen. Das würde selbst bei einer exzellenten Anbindung des Ziels Ewigkeiten dauern. Ein recht eindrucksvolles Beispiel für eine Suchmaske kann man sich unter [SRS], einer Bioinformatik Datenquelle, anschauen, wenn man auf zuerst auf Library Page klickt, Datenbanken aussucht und dann unter Query Form seine Anfrage eingibt. Man kann N viele Datenbanken auswählen. Ein automatisches Verfahren müßte also alle Kombinationen von Datenbanken durchprobieren: Anzahl der Anfragen = Anzahl Anfrageterme 2 Anzahl Datenbanken. Uff! Seite 7 von 14

8 Anfragesprache der Quelle lernen ([BC04], [BC03b]) Führen wir uns noch einmal unsere Ausgangsituation klar vor Augen: unsere Aufgabe sei es eine Suchmaschine für das Deep Web zu bauen und möglichst für alle (fiktiven) Suchmasken einen Wrapper zu erstellen, die Parameter (arbeitet nach dem Booleschen Modell, versteht Boolesche Ausdrücke (ganz/in Teilen), versteht regulären Ausdrücke (ganz/in Teilen), arbeitet nach dem Vector-Space Model, ) der Anfragesprache zu definieren. Von Hand bedeutet das sicher eine Menge Überstunden! Ganz zu schweigen davon, daß oft gar nicht rauszufinden ist, welche Eigenschaften die Anfragesprache einer Quelle eigentlich hat: oft gibt es keine Hilfe/FAQ oder ähnliches, die vorhandene Hilfe ist veraltet oder fehlerbehaftet. In so einem Fall müßte man dann durch gezieltes Probieren rausfinden, was geht und was nicht. Abbildung 2: Suchergebnis für "Rammstein" in [AM] In [BC04] beschreiben Bergholz und Chidlovskii wie diese Arbeit automatisch gemacht werden kann. Das dort vorgestellte Verfahren funktioniert allerdings nur wie oben bereits erwähnt für eine Untermenge aller Deep Web Formulare: die Suchmaske darf nur aus genau einem Textfeld zur Eingabe einer Anfrage bestehen. Operatoren der Anfragesprache Nach Bergholz und Chidlovskii ist die Menge der am häufigsten in web-basierten Anfragesprachen vorkommenden Operatoren O={Case, Stem, Phrase,,, }. Wobei,, für die booleschen Verknüpfungen stehen. Der Operator wird so die Autoren im Kontext des Internets häufig als und nicht interpretiert. In [BC04] ist daher ein binärer Operator. Der Operator Case steht dabei für die Sensitivität gegenüber Groß- /Kleinschreibung, Stem ersetzt einen Term aus der Anfrage durch sein Lexem 1 und Phrase interpretiert mehrere Terme (inklusive Leerzeichen) als zusammengehörendes Ganzes. Natürlich ist noch eine Menge anderer Operatoren denkbar: wie das Beispiel auf der rechten Seite zeigt ist zum Beispiel in [AM] eine Spielart von SoundEx ( das gesuchte Wort klingt so wie -Suche) implementiert. Syntax der Operatoren Für die Umsetzung der obengenannten Operatoren und deren Syntax gibt es eine Vielzahl von Möglichkeiten. So kann zum Beispiel je nachdem in welchem Sprachkreis man sich gerade bewegt der Operator durch UND (dt.), AND (engl.) ET (frz.) oder JA (fin.) dargestellt werden. 1 Ein Lexem ist die ungebeugte Grundform des Wortes oder der Wortstamm. Zum Beispiel ist schreib das Lexem von schreiben, schriebst, schrieben aber auch von Schreiberling, Geschriebenes und vorschreiben. Seite 8 von 14

9 Wie oben bereits erwähnt wird von vielen Quellen nur in Verbindung mit einem anderen Term akzeptiert und als und nicht interpretiert. Suchmaschinenprodukte wie FAST Data Search oder Google Search Appliance erlauben das nicht anders. Wenn allerdings die Eingabe einer Suchmaske auf Anfragen gegen eine SQL-Datenbank abgebildet wird, gibt es die Möglichkeit mit dem SQL Operatoren NOT und IN oder mit dem Vergleichoperator!= zuarbeiten. Dann muß also der Operator keineswegs die Arität zwei haben. Nicht selten treten durch unterschiedliche Interpretationen der Operatoren Anomalien auf: in [BC04] sind die Anfragen A 1 = Casablanca, A 2 = Bogart und A 3 = Casablanca AND Bogart gegen Google und gegen die IMDb (Internet Movie Database) geschickt worden. Die Anzahl der Ergebnisdokumente ist in Tabelle 1 dargestellt. Die IMDb interpretiert AND als sein Literal, wogegen Google AND als Operator interpretiert. Ähnliches läßt sich A 1 A 2 A 3 Google IMDb Tabelle 1 : Anomalie durch Unterschiede in der Syntax der Anfragesprache auch für [AM] beobachten. Die Situation ist dort allerdings wegen der SoundEx-Suche noch etwas komplizierter. Die Autoren Bergholz und Chidlovskii betrachten in [BC04] nur die Syntaxmenge S={TermsOnly, *,, AND, +, OR, NOT, -, "" }. Um auch darstellen zu können, daß einzelne Quellen z.b. die Darstellung der Booleschen Operatoren als z.b. AND, OR, NOT als Literale interpretieren, einige Wörter wie z.b. Artikel, Konjunktionen und andere häufig vorkommende Wörter ( Stop-Words ) ignorieren oder aber einige Anfragen schlichtweg nicht handhaben können, wurde die Menge O der Operatoren erweitert um O ={Literal, Unknown, Ignored}. Suchproblem Das eigentliche Problem, dem man jetzt gegenüber steht, ist für jede Quelle ein Menge I S O der Interpretationen der Operationen über der Syntax zu finden, die die Funktionalität der Quelle beschreibt. Anders gesagt: I kann als Zielfunktion aufgefaßt werden, die jeder Syntax eine Operation zuordnet I: S O. Dieses Suchproblem haben die Autoren folgendermaßen gelöst: es wurde eine Menge von Anfragetemplates erstellt in denen Variablen für Suchbegriffe enthalten waren. Die Variablen wurden mit konkreten Suchbegriffen gefüllt, woraufhin die Anfrage an die Quelle geschickt wurde. Als Ergebnis wurde die Anzahl der Ergebnisdokumente notiert. Anschließend wurde für je zwei Anfragen notiert, ob die Anfrage 1 kleiner, größer oder gleich Anfrage 2 war. Das Ergebnis ist eine Menge von drei-wertigen Merkmalsausprägungen. Mit Techniken aus dem Machine-Learning kann so eine Annäherung an die gesuchte Zielfunktion gelernt werden. Alternativ zur kleiner, größer, gleich -Normalisierung haben Bergholz und Chidlovskii auch versucht die Ergebnisgröße mit der Gesamtzahl der Dokumente in der Quelle zu skalieren. kleiner, größer, gleich erwies sich aber im Nachhinein als der beste Ansatz, weshalb ich im folgenden nur diesen Ansatz Darstellen werde. Seite 9 von 14

10 Ich werde in den nächsten Absätzen kurz die Details des Verfahrens beschreiben und anhand eines eigenen Beispiels verdeutlichen. Gruppe Zunächst ein paar Worte zur Aufteilung von Ein-Wort- Anfragetemplates und über das Lexikon für die Anfragen Anfragen. Die Templates waren in drei Gruppen aufgeteilt: Ein-, Zwei- und Dreit-Wort-Anfragen. Die Templates sind in Tabelle 2 dargestellt. Die Variablen in den Templates wurden mit Werten aus drei Gruppen gebunden, die nach der Ausprägung ihrer Co-Occurrence ( Zusammenauftauchendheit ) eingeteilt wurden. Co-Occurrence ist ein Begriff aus dem Information Retrieval. Ob zwei Begriffe Nirvana und Cobain zur Gruppe phrase-cooccurence, high co-occurrence oder low-cooccurence gehören, wird anhand von Funktionen über Zwei-Wor- Anfragen Drei-Wort- Anfragen Templates A, B, UpperCase(A), A*, Stem(A) A B, B A, A B, B A, +A +B, +B +A, A B, A AND, A OR, A NOT A AND B, B AND A, A OR B, B OR A, A NOT B, B NOT A Tabelle 2 : Anfragetemplates nach [BC04] ihrer document frequency (Häufigkeit des Vorkommens in verschiedenen Dokumenten) gemessen. Die Begriffe Nirvana und Cobain gehören intuitiv zur Gruppe high cooccurence. Ob sie in Bezug auf eine bestimmte Kollektion auch dort eingeordnet werden ist natürlich ungewiß. Ein Beispiel für phrase-co-occurrence ist Data Warehouse. Auf die Funktionen möchte ich allerdings hier nicht näher eingehen. Sie sind in [BC04] nachzulesen. Für das klassifizieren der Begriffe in Bezug auf co-occurrence wurde in [BC04] Google benutzt. Für jedes der Wörter aus dem Wörterbuch wurde eine Anfrage gestartet und für jedes Ergebnisdokument gezählt wie oft die anderen Begriffe aus dem Wörterbuch darin vorkommen. Im folgenden möchte ich kurz ein Beispiel vorstellen für welches ich die Anfragetemplates mit zwei Begriffen gefüllt habe, denen ich intuitiv als selten zusammenauftauchend charakterisieren würde. Die Anfragen wurden an die Quelle AllMusic [AM] geschickt. Hier zunächst die Ergebnisse der Anfragen mit ihren Kardinalitäten: Seite 10 von 14

11 A=Nirvana, B=Information A=Nirvana, B=Information A=Nirvana, B=Information A=Nirvana, B=Information A B UpperCase(A) A* Stem(A) A B B A A B B A +A +B +B +A A -B A AND A OR A NOT A AND B B AND A A OR B B OR A A NOT B B NOT A Tabelle 3 : Ergebnis-Kardinalitäten der 21 Anfragen mit A=Nirvana und B=Information an [AM] Was sofort auffällt ist das für eine Menge von Anfragen die Ergebnisgröße immer 75 ist. Ich würde das als eine Ausgabelimitierung interpretieren. Außerdem haben die meisten der Zwei- Wort-Templates eine Ergebnisgröße von 59 unabhängig davon, ob als Phrasen, mit + oder - geschrieben. Wahrscheinlich ignoriert [AM] diese Sonderzeichen. Der nächste Schritt nach Bergholz und Chidlovskii wäre nun für je zwei Unterschiedliche Anfragen zu schauen, ob die A1 größer, kleiner oder gleich A2 ist. Also die folgende Menge zu bilden: TrainingSet={( Nirvana, Information, <), ( NIRVANA, Nirvana, =), }. Wenn man diese Menge gebildet hat, kann sie einem mit einem Machine-Learning-Verfahren gelernten Klassifikator vorgesetzt werden, der dann die Eigenschaften der Sprache erkennt. Hoffentlich! Für [AM] sollten die Menge I folgendermaßen aussehen: I={(Wort Case), (* Ignored), (Space Phrase), ("" Phrase), (AND Literal), (OR Literal), (NOT Literal), (+ Ignored), (- Ignored), (,,, Unknown)}. Eine Interpretation, die der Algorithmus in der jetzigen Zeit nicht finden würde lautet (Wort SoundEx). Das stellt in sofern ein Problem dar, weil durch die Unscharfe Suche mit SoundEx eventuell auch andere Interpretation falsch klassifiziert werden könnten. das läßt sich aber leider ohne den Trainingsatz / Klassifikator von Bergholz und Chidlovskii nicht feststellen. Ein etwas mächtigere Anfragesprache stellt Google bereit: I={(Wort Case), (Wort Stem), ( (* Ignored), (Space ), ("" Phrase), (AND ), (OR ), (NOT Ignored), (+ ), (- ), ( Literal, Unknown)}. Lernen des Klassifikators Was ist überhaupt ein Klassifikator? Ein Klassifikator ordnet aufgrund einer Abbildungsvorschrift die Eingaben (z.b. Terme wie kalt UND regenerisch ) gewünschten Ausgaben (z.b. dann schneit es ) zu. Im Bereich des Machine Learnings gibt es Seite 11 von 14

12 verschiedene Verfahren. Die meisten Klassifikatoren müssen vorher mit Beispieleingaben und -ausgaben trainiert werden. In [BC04] wurden verschiedene Klassifikatoren verwendet: K Nearest Neighbour (KNN), support vector machines (SVM) und decision trees (DT). Für eine genauere Erläuterung zu diesen Verfahren empfehle ich zum Beispiel das Skript zur Vorlesung Maschinelles Leren und Data Mining [SB04]. Die drei verschiedenen Klassifikatoren wurden mit 36 handverlesenen Quellen trainiert! Jede dieser Quellen hatte eine eindeutige Syntax. Die Menge I der Interpretationen wurde für jede Menge von Hand gebildet. Für jede der Quellen mußten Anfragen entsprechend der 21 Templates gestellt und das TrainingSet (s.o.) gebildet werden. Die so gelernten Klassifikatoren hatten in der Regel eine mittlere Genauigkeit von über 60%. Schlußbemerkung Der oben vorgestellte Ansatz erleichtert (zumindest teilweise) die Akquisition der Anfragesprache von Deep Web Quellen. Welche anderen Aufgaben müßten noch gelöst werden, um eine voll-automatische Deep Web Query Engine zu bauen? Nun, zunächst sollte man vielleicht in der Lage sein, Quellen hinsichtlich ihres Inhaltes in einer Taxonomie (Yahoo!-artiges Verzeichnis) einzuordnen: man muß bestimmen, welchen Inhaltes die Ergebnisse der Quelle sind. Mit dem klassifizieren befassen sich Ipeirotis et. al. in [IGS01]. Beim Klassifizieren der Quelle kann man dann auch gleich Statistiken über die Quellen sammeln: Wie gut werden Themenbereiche abgedeckt? Wie häufig kommt ein Wort in den Dokumenten der Quelle vor? Wie ist die Antwortzeit der Quelle? Wieviele gleichzeitige Anfragen unterstützt sie? Diese Daten hat jedes Datenbank-System in seienm Katalog gespeichert, um vorauszuberechen wie teuer (in Bezug auf CPU, IO oder Zeit) eine Anfrage ungefähr wird für Anfragen an das Deep Web ist das natürlich nicht minder wichtig. Das erstellen von Statistiken beschreiben ebenfalls Ipeirotis et. al. in [IG02]. Außerdem muß natürlich noch das Problem gelöst werden, welche Anfragesprache eine Deep Web Query Engine haben kann: die kleinste gemeinsame Schnittmenge aller Quellen oder eine Obermenge? Wenn sie eine Obermenge der Anfragesprachen implementiert ist die Frage zu klären, wie komplexe Anfragen an die Quellen verteilt werden, um die Semantik der gestellten Anfrage zu simulieren. Keines der oben-genannten Themen ist bisher abschließend und vollkommen zufriedenstellend geklärt worden. Dennoch empfehle ich einen Blick in die Literaturliste zu werfen und einige Paper genauer unter die Lupe zunehmen es lohnt sich auf jeden Fall. Besonders empfehlen kann ich die Projekte MetaQuerier [MQ] und QProber [QP]. Auf den Seiten findet man neben Demoversionen auch eine ausführliche Beschreibung der Verfahren. Seite 12 von 14

13 Referenzen [CH05] [ZH04] [RG04] [BC04] [HP04] [IG04] [WM04] [BC03b] [BC03a] [BM03] [GIS03] [IG02] K. C.-C. Chang, B. He, et al. (2005). Toward Large Scale Integration: Building a MetaQuerier over Databases on the Web. Conference on Innovative Data Systems Research (CIDR 2005), Asilomar, California. Z. Zhang, B. He, et al. (2004). Understanding Web query interfaces: best-effort parsing with hidden syntax. SIGMOD '04: Proceedings of the 2004 ACM SIGMOD international conference on Management of data, ACM Press: D. C. Reis, P. B. Golgher, et al. (2004). Automatic web news extraction using tree edit distance. WWW '04: Proceedings of the 13th international conference on World Wide Web, ACM Press: A. Bergholz, B. Chidlovskii (2004). Learning Query Languages of Web Interfaces. SAC2004: Proceedings of the 2004 ACM symposium on Applied computing, ACM Press: B. He, M. Patel, et al. (2004). Accessing the Deep Web: A Survey, Department of Computer Science, UIUC. P. G. Ipeirotis, L. Gravano (2004). When one Sample is not Enough: Improving Text Database Selection Using Shrinkage. SIGMOD Conference Proceedings: Z. Wu, D. Mundluru, et al. (2004). Automatically Detecting Boolean Operations Supported by Search Engines, Towards Search Engine Query Language Discovery. Proceedings of the 2nd International Workshop on Web-based Support Systems: A. Bergholz, B. Chidlovskii (2003). Using Query Probing to Identify Query Language Features on the Web. Distributed Multimedia Information Retrieval, SIGIR 2003, Workshop on Distributed Information Retrieval. Springer. 2924: A. Bergholz, B. Chidlovskii (2003). Crawling for Domain-Specific Hidden Web Resources. 4th International Conference on Web Information Systems Engineering (WISE 2003), Rome, Italy, IEEE Computer Society. M. K. Bergman (2003). Guid to Effective Searching of the Internet, BrightPlanet. L. Gravano, P. G. Ipeirotis, M. Sahami. (2003). QProber: A system for automatic classification of hidden-web databases. ACM Trans. Inf. Syst. 21(1): P. Ipeirotis, L. Gravano (2002). Distributed search over the hidden web: Hierarchical database sampling and selection. Seite 13 von 14

14 [RGM01] [IGS01] [BM01] S. Raghavan, H. Garcia-Molina (2001). Crawling the Hidden Web. Proceedings of the 27th International Conference on Very Large Data Bases, Morgan Kaufmann Publishers Inc.: P. G. Ipeirotis, L. Gravano, M. Sahami (2001). Probe, count, and classify: categorizing hidden web databases. SIGMOD '01: Proceedings of the 2001 ACM SIGMOD international conference on Management of data, ACM Press: M. K. Bergman (2001). The Deep Web: Surfacing Hidden Value, BrightPlanet. Skripte im Internet [SB04] Prof. Dr. T. Scheffer, S. Bickel, Maschinelles Lernen und Data Mining, Internetseiten [UCB] [MQ] [QP] [CP] [BP] [PM] [AM] [SRS] [IMDB] [AZ] [AJC] Universität Berkley The MetaQuerier Project. The QProber Project. CompletePlanet. BrightPlanet. PubMed AllMusic. EMBL EBI. IMDb. Amazon. Apache Jakarta Commons HTTPClient Seite 14 von 14